multi-ai-research（多 AI 研究）

Multi-AI Research（并行多 AI 交叉验证）

核心价值：能力乘法，不是加法。Claude（主脑）+ grok（X 社区/实时）+ gemini（Google 生态/结构化）+ N 个内部 sub-agent = N+3 个 agent 并行处理同一个研究问题。

关键洞察（2026-04-08 实战验证）：两个独立外部 AI 的共识信号 强于 任何单个 AI 的深度。"更深度" < "更少错"。

和 ask-opencli 的关系：

• ask-opencli = 单次 grok 或 gemini 调用（日常 second opinion）
• multi-ai-research = 完整调研工作流，并行多 AI + 内部数据 + 交叉验证 + 自动仲裁

如果用户只是想"问 grok 一个问题"，用 ask-opencli。如果用户要做"深度调研"或"交叉验证多个维度"，用这个 skill。

何时触发

✅ 适合

• 深度研究任务（手动做 >30 分钟）
• 行业机制问题（算法规则、产品决策、社区共识）
• 需要外部共识加权的内部数据推断
• 时效性问题（grok 有实时 X 数据，gemini 有最新 web 索引）
• 反转既有假设（数据 vs 理论冲突时仲裁）
• 新工具/新做法的可行性调研

❌ 不适合

• 纯代码推理（单个 Claude 足够）
• 需要深度项目 context 的任务（外部 AI 不了解你的代码库）
• 快速事实问答（<30 秒能解决，并行开销不值）
• 创意生成（单家强模型即可）

工作流（7 Phase）

Phase 1：问题分解（Claude 自动 + 用户可覆盖）

从用户的一个研究问题，自动拆分成：

1. 内部数据查询（1-5 个 sub-agent 并行）

- 数据分布/量化分析 - 内容对比/质性分析 - 多维度切分 - 时序/趋势分析 - （按需增加）

1. 外部理论查询（2 个 Bash 并行）

- grok：侧重实时/社区/X 信号 - gemini：侧重结构化/框架/长推理

默认分解策略：

• 3 个内部 agent + 2 个外部 AI = 5 个并行任务
• 如果用户问题偏理论 → 减少内部 agent 到 1-2 个，加大外部 AI 权重
• 如果用户问题偏数据 → 加到 4-5 个内部 agent，只跑 2 个外部 AI 做交叉

用户可覆盖：用户明确说"只问 grok 和 gemini"或"只派内部 agent"时按用户指令。

Phase 2：Prompt 自动生成

对每个并行任务，自动生成具体 prompt：

内部 agent prompt 模板

你的任务是**只读数据分析**，不要修改任何文件。

## 背景
{{研究问题的 2-3 句背景描述}}

## 数据源
{{数据库路径或文件列表}}

## 任务
{{具体要查的维度，1-5 个 task}}

## 输出格式
- 结构化 markdown 报告
- 每个结论标注 n（样本数）和 置信度
- 3 屏幕内
- 纯文本返回，不要尝试写文件

grok / gemini prompt 模板

{{研究问题的精简描述，≤300 字}}

具体问：
(1) {{子问题 1}}
(2) {{子问题 2}}
...

请基于 2026 年上半年真实情况/最新数据回答，要具体可引用。

关键要求：问 grok 和 gemini 的 prompt 必须一致（独立对比的前提）。

Phase 3：并行派发（一条消息多个工具调用）

Tool 1: Agent (general-purpose)  run_in_background=true  [内部数据 agent A]
Tool 2: Agent (general-purpose)  run_in_background=true  [内部数据 agent B]
Tool 3: Agent (general-purpose)  run_in_background=true  [内部数据 agent C]
Tool 4: Bash run_in_background=true  [OPENCLI_BROWSER_COMMAND_TIMEOUT=300 opencli grok ask "..." --timeout 300 -f json]
Tool 5: Bash run_in_background=true  [opencli gemini ask "..." --format plain]

必须在 Claude 的同一条 assistant 消息里一次性调用多个工具，才能真正并行。

Phase 4：等待（不要 poll）

Background agent / Bash 任务完成会自动通知。在等的时候，Claude 可以：

• 读现有 docs / memory 获取更多 context
• 准备输出结构
• 做初步的 Phase 5/6 分析框架

明确禁止：

• 不要 sleep + 轮询任务状态
• 不要主动 Read output 文件（除非收到完成通知）
• 不要抢跑做结论

Phase 5：交叉验证 + 自动置信度分级（大版本核心）

所有结果回来后，按 4 层分类规则自动仲裁每个发现：

分类规则矩阵

仲裁原则（自动执行）

原则 1：样本量门槛

• n ≥ 20：可作为高置信度依据
• 10 ≤ n < 20：中置信度，小幅改动
• n < 10：仅观察，不作为结论
• n < 5：完全忽略

原则 2：数据 vs 理论冲突时

• 内部数据 n ≥ 20 → 优先内部数据（除非外部 AI 双方都独立反对）
• 内部数据 n < 10 → 优先外部 AI 共识（双方一致时）
• 内部数据 n < 5 → 结论待定，标为 open question

原则 3：外部 AI 可疑概念识别

• gemini 有时会给出疑似幻觉的概念（如"Phoenix 架构"等具体命名）
• 规则：概念名只在 gemini 单家出现且无 grok 交叉 → 标为 "potential hallucination"，不采纳
• grok 引用的社区数据（"用户反馈说..."）→ 中等可信度

原则 4：反直觉发现的特别处理

• 如果 n ≥ 20 数据和常识/理论相反（如"小帖 > 大爆款"）
• 且外部 AI 共识支持
• 标注 "⚠️ 反直觉但强共识"，需要在后续跟进验证

Phase 5.5：外部 AI 案例二次验证（大版本新增）

外部 AI 有时会给出具体的"案例"（如 @morsyxbt 100→1600/月），这类"单家独有案例"需要二次验证：

验证方式（按优先级）：

1. 用户工具直接验证：如果是 X 账号 → 用 twitter -c user <handle> 查是否真实存在
2. 反向问另一家 AI：问 gemini "你听说过 @morsyxbt 吗？" 看是否有交叉记忆
3. Web search 验证：让用户手动搜或用额外 web 工具

2026-04-09 实战案例：

• Grok 独家提到 @morsyxbt 100→1600/月
• Gemini 没提
• 用 twitter -c user morsyxbt 验证：真实账号，10.2k followers, verified
• 结论：账号真实，但"100→1600/月"的具体数字仍需 morsyxbt 本人 tweet 确认
• Tier：从 "单家可疑" 升级到 "单家可信案例"

潜在幻觉的识别：

• 如果验证失败（账号不存在/数字对不上）→ 标记为 hallucination，从 report 删除
• 如果部分验证（账号存在但数字未证）→ 标记为 partial verified，保留但降低权重

Phase 6：自动生成改动清单（tiered action items）

输出结构：

## Action Items (auto-generated, tiered)

### 🔴 极高置信度必做（Strong consensus，可直接落地）
1. [action] — 依据：{数据来源 + AI 共识} — 预期效果：{具体可衡量}
   - Rollback：{怎么撤销}
   - Verify：{24-48h 后如何验证}
2. ...

### 🟡 高置信度建议做（Partial consensus）
1. [action] — 依据：{单侧支持} — 前提假设：{什么条件下才成立}
2. ...

### ⚪ 待验证假设（Insufficient data）
1. [hypothesis] — 需要：{什么数据才能确认} — 建议：{A/B 测试设计}
2. ...

### 🚫 不做（Conflict / 反对证据强）
1. [originally planned action] — 反对依据：{为什么不做}

Phase 7：Artifact 保存

保存到 .omx/artifacts/multi-ai-research-<slug>-<YYYYMMDD-HHMMSS>.md

必须包含：

1. 原始研究问题（用户的一句话）
2. Phase 1 问题分解（每个任务的具体 prompt）
3. Phase 3 并行任务列表（task id + 命令）
4. 每个 agent 的 raw response（N 个内部 + 2 个外部）
5. Phase 5 交叉验证矩阵（每个发现的置信度判定）
6. Phase 6 改动清单（tiered action items）
7. 用时 + 任务数（metadata）

⚠️ 命令速查（防呆，最先看这个）

grok 和 gemini 的有效子命令只有这些，其他都是错的：

# ✅ Grok —— 只有一个子命令 ask
OPENCLI_BROWSER_COMMAND_TIMEOUT=300 opencli grok ask "问题" --timeout 300 -f json

# ✅ Gemini —— 5 个子命令，最常用是 ask
opencli gemini ask "问题" --format plain         # 最常用（单次问答）
opencli gemini new                               # 开新对话
opencli gemini deep-research "问题"              # Deep Research
opencli gemini deep-research-result              # 取 Deep Research 结果
opencli gemini image "画一个..."                 # 生图

❌ 常见错误命令（运行会直接报 unknown command）：

记忆锚点：ask 是两家唯一的"问一次"命令。不是 chat，不是 query，不是 prompt。

如果不确定，跑 opencli grok --help 或 opencli gemini --help 看完整子命令列表。

首次使用：安装 opencli（5 分钟一次性）

官方仓库：https://github.com/jackwener/opencli npm 包：@jackwener/opencli (npmjs) 作者：jackwener License：Apache-2.0

环境要求

• Node.js ≥ 20.0.0
• Chrome 或 Chromium 浏览器
• macOS / Linux / Windows 均支持

一、安装 opencli CLI

npm install -g @jackwener/opencli

验证：

opencli --version

二、安装 Browser Bridge 扩展

opencli 通过一个轻量的 Chrome 扩展 + 本地 daemon 复用你浏览器已登录的 session。首次运行会自动引导安装：

opencli doctor

按提示把扩展加载到 Chrome（通常是 chrome://extensions → 开发者模式 → 加载已解压的扩展，路径 doctor 会告诉你）。

三、登录目标 AI 网站

用装了扩展的那个 Chrome profile 打开并登录：

• https://grok.com（Premium/Premium+ 订阅）
• https://gemini.google.com（Advanced 订阅）

登录一次就行，session 会被 opencli 长期复用。

四、设置环境变量（必须）

# 加到 ~/.zshrc 或 ~/.bashrc
export OPENCLI_BROWSER_COMMAND_TIMEOUT=300

为什么必须：opencli 的默认 browser command timeout 是 60 秒（runtime.js:25），对 grok 复杂问题不够。不设这个 grok 会报 timed out after 60s。这是血泪教训。

五、可选：安装 opencli 的 AI skills

opencli 自己提供了几个 AI skill，也可以装：

npx skills add jackwener/opencli

（这些 skill 和 multi-ai-research 不冲突，是互补的。）

六、验证全链路

OPENCLI_BROWSER_COMMAND_TIMEOUT=300 opencli grok ask "请只回复：OK" --timeout 300 -f json
opencli gemini ask "请只回复：OK" --format plain

两个都返回 OK 就代表全链路通了。

Phase 0: Pre-flight Prerequisites（强制检查）

运行前必须按顺序检查，任一失败停止流程并向用户报告：

0.1 CLI 可用性

# opencli 存在
which opencli || echo "🔴 opencli 未安装"
opencli --version 2>&1 | head -1

# twitter-cli 存在（如果任务涉及 X 数据）
which twitter 2>&1

0.2 环境变量（grok 必需）

echo "OPENCLI_BROWSER_COMMAND_TIMEOUT=${OPENCLI_BROWSER_COMMAND_TIMEOUT:-未设置}"

如果未设置：

• 不要静默跳过，否则 grok 会 60s 硬截断
• 在每次 Bash 调用时强制前置：OPENCLI_BROWSER_COMMAND_TIMEOUT=300 opencli grok ask...
• 或提示用户在 shell rc 加 export OPENCLI_BROWSER_COMMAND_TIMEOUT=300

0.3 登录状态（手动）

首次运行时提醒用户确认：

• grok.com 在 Chrome 已登录（Premium/Premium+）
• gemini.google.com 在 Chrome 已登录（Advanced）

0.4 Claude Code Agent 工具可用

• 当前 session 能调 general-purpose subagent（用于内部数据任务）
• 能用 run_in_background=true 参数

0.5 数据源健康检查（针对 domain 特定场景）

如果研究问题涉及内部数据分析，先跑数据健康检查：

示例：X reply 场景

# 检查 reply_tracking 数据完整度
import sqlite3
conn = sqlite3.connect('/path/to/tracker.db')

# Pending 堆积（collector bug 指示）
stale = conn.execute("""
    SELECT COUNT(*) FROM reply_tracking
    WHERE check_stage='pending'
      AND posted_at < datetime('now', '-24 hour')
""").fetchone()[0]

# 关键字段覆盖率
by_type = conn.execute("""
    SELECT type, COUNT(*) as total,
           SUM(CASE WHEN check_stage='pending' THEN 1 ELSE 0 END) as pending
    FROM reply_tracking
    GROUP BY type
""").fetchall()

# 硬阈值判断
if stale > 50:
    print("🔴 >50 条 reply 永久 pending，疑似 collector bug，先修再 research")
for t in by_type:
    if t[1] > 10 and t[2] / t[1] > 0.5:
        print(f"🔴 type={t[0]} 的 pending 率 >50%，可能 collector 只覆盖部分 type")

教训（2026-04-09 实测发现）：@your-account 的 collector 只追踪 reply/quote 不追 post，导致 N 条 post 全部 pending 被当成"0 views"。Phase 0 的 data health check 能提前暴露这种 bug，避免"拿污染数据做调研"。

判定规则

命令参考

并行 Bash 调用（grok + gemini）

在 Claude Code 里通过 Bash 工具启动，run_in_background=true，一条消息里多个 tool call：

# Bash call 1 (background)
OPENCLI_BROWSER_COMMAND_TIMEOUT=300 opencli grok ask "{{PROMPT}}" --timeout 300 -f json

# Bash call 2 (background)
opencli gemini ask "{{PROMPT}}" --format plain

两个 Bash 调用 必须在同一条 assistant 消息里调用，否则会串行。

并行 Agent 派发（内部数据）

使用 Agent 工具，run_in_background=true，一条消息里多个 tool call：

Agent 1: subagent_type=general-purpose, description=...
Agent 2: subagent_type=general-purpose, description=...
Agent 3: subagent_type=general-purpose, description=...

每个 agent 的 prompt 独立且完整（Phase 2 生成）。

可选：更多 AI 并行（未来扩展）

opencli 还支持其他 AI 服务（perplexity 等，持续扩展），未来可加入：

opencli perplexity ask "{{PROMPT}}" --format plain

Error handling

grok 超时（60s 截断）

• 根因：OPENCLI_BROWSER_COMMAND_TIMEOUT 没设
• 修复：export OPENCLI_BROWSER_COMMAND_TIMEOUT=300
• 不要靠缩短 prompt 绕开（用户 2026-04-08 反馈：不要改问题改超时）

grok 返回 "Not logged in"

• 停止，让用户在浏览器手动打开 grok.com 登录
• 不要自动重试

gemini 返回可疑概念（Phoenix 架构等）

• Phase 5 自动标为 "potential hallucination"
• 不采纳，需要 grok 交叉验证后才能采用

内部 agent timeout

• 缩小 agent 任务范围（分解成 2 个小 agent）
• 或者改用直接 Bash SQL 替代

部分任务失败

• 如果 grok 失败但 gemini 成功 → 降级到单外部 AI
• 如果 2 个外部都失败 → 降级到"仅内部数据"调研，标注报告为 "internal only"
• 不要掩盖失败

2026-04-08 实战案例（此 skill 的设计来源）

研究问题：X reply deboost 机制是什么？为什么有的 reply 有流量有的没有？

Phase 1 分解：

• Agent A：reply views 分布分层（n=1079）
• Agent B：高/低流量 reply 内容对比（A组 10 条 vs B组 10 条）
• Agent C：时序 × 作者 × 骨架 × 热度 多维切分
• Grok：2026 Reply Guy 模式机制
• Gemini：同上（独立对比）

Phase 3 并行派发：5 个任务同时启动，Claude 在等的时候继续读 docs

Phase 4 等待：5 个任务在 5-10 分钟内陆续完成（Agent B 最慢）

Phase 5 自动交叉验证：

Phase 6 自动改动清单：

• 🔴 必做：CN:EN 10:1 / 踩坑预警首选 / 禁顶满 / 作者白黑名单 / 时段加权
• 🟡 建议：原帖热度甜区软约束 / HVC 机制
• ⚪ 待验证：long 回复效果（需 A/B 测试）
• 🚫 不做：基于 Phoenix 架构的假设（不采纳单侧幻觉）

结果：30 分钟从"有困惑"到"SKILL.md v8.2 → v8.3 完整改动清单"。

和其他 skill 的关系

• ask-opencli：单次 grok/gemini 调用，日常 second opinion。本 skill 包含 ask-opencli 的能力但扩展为多 AI 编排。
• x-learn-reply v2：domain-specific 版本，专门做 X reply 策略优化。内部 Phase 4/5（交叉验证 + 改动清单）复用了本 skill 的方法论。
• cognitive-portrait：参考了本 skill 的"主 agent 派发 sub-agent 并行"模式，但场景是单人认知画像分析。

如果你的场景是 domain-specific 优化（如 X reply / X post），优先用 domain 版本。如果是通用深度调研，用本 skill。

禁止事项

• ❌ 不跳过 Phase 0 prerequisites 检查
• ❌ 不串行调 grok 和 gemini（必须同一消息并行）
• ❌ 不 poll 等待 background task（等通知）
• ❌ 不跳过 Phase 5 置信度分级（直接把 AI 回答当结论）
• ❌ 不把单家 AI 的独有概念当事实（可能是幻觉）
• ❌ 不采纳样本 n<10 的内部数据作为高置信度依据
• ❌ 不跳过 Phase 7 artifact 保存

Task: {{ARGUMENTS}}