Openclaw
by @shineliang
Multi-agent collaborative industry research for OpenClaw. Dynamically assigns research roles, runs parallel research via sessions_spawn with codex/gemini/cla...
clawhub install multi-agent-industry-research📖 About This Skill
name: industry-research description: | Multi-agent collaborative industry research for OpenClaw. Dynamically assigns research roles, runs parallel research via sessions_spawn with codex/gemini/claude CLI augmentation, iterative quality review, merge & converge, outputs structured Markdown report.
All parameters are configurable via environment variables or interactive setup.
Trigger: /research, 行业调研, industry research, 调研报告 metadata: openclaw: emoji: "\U0001F50D" homepage: https://github.com/shineliang/industry-research-skill requires: anyBins: - codex - gemini - claude
多智能体协同行业调研（OpenClaw 版）
协调多个 sub-agent 并行完成行业调研，通过迭代审核和合并收敛产出高质量报告。
Commands
/research # 启动行业调研（如：/research AI Agent 行业现状）
/research --depth=deep # 深度调研模式
/research --depth=quick # 快速概览模式
Prerequisites
sessions_spawn 和 exec 工具）codex) — 可选，提供 OpenAI 模型补充视角gemini) — 可选，提供 Google 模型补充视角claude) — 可选，提供 Anthropic 模型补充视角可配置参数
优先级：环境变量 > 启动时用户选择 > 默认值
| 参数 | 环境变量 | 默认值 | 说明 |
|------|----------|--------|------|
| 研究 agent 数量 | RESEARCH_AGENT_COUNT | auto | 设为数字则固定，auto 则动态分配 |
| 研究迭代上限 | RESEARCH_MAX_ROUNDS | 3 | 研究阶段最多迭代几轮 |
| 合并迭代上限 | MERGE_MAX_ROUNDS | 2 | 合并阶段最多迭代几轮 |
| 质量总分阈值 | QUALITY_THRESHOLD | 35 | 满分 50，总分需达到此值 |
| 单项最低分 | QUALITY_MIN_PER_DIM | 6 | 满分 10，每个维度不低于此值 |
| 交叉验证模式 | RESEARCH_CROSS_MODEL | cli | cli / native / both / none，见下方说明 |
| 启用 CLI 工具 | RESEARCH_CLI_TOOLS | codex,gemini,claude | 可选值：codex、gemini、claude、none 或组合 |
| CLI 超时 | RESEARCH_CLI_TIMEOUT | 600 | 秒 |
| Native 模型列表 | RESEARCH_MODELS | _(空)_ | 如 anthropic/claude-sonnet-4-6,google/gemini-2.5-pro,openai-codex/gpt-5.4 |
| 输出语言 | RESEARCH_LANG | zh | zh 中文 / en 英文 |
| 报告深度 | RESEARCH_DEPTH | standard | quick / standard / deep |
交叉验证模式
不同 AI 模型有不同的知识覆盖、推理偏好和盲区。让多个模型分别分析同一问题，能有效提升调研质量。
| 模式 | 说明 | 适用场景 |
|------|------|----------|
| cli | 研究 agent 在自己的分析完成后，必须调用 CLI 工具（codex/gemini/claude）对关键发现做交叉验证。CLI 使用订阅账号，无额外 API 费用。这是默认模式。 | 没有购买多个模型 API 的用户 |
| native | 不同研究 agent 通过 sessions_spawn 的 model 参数使用不同模型原生运行。每个 agent 拥有完整工具链。需要配置 RESEARCH_MODELS。 | 已购买多个模型 API key 的用户 |
| both | 结合两者：不同 agent 用不同模型 + agent 内部再用 CLI 交叉验证 | 追求最高质量的用户 |
| none | 所有 agent 使用默认模型，不做交叉验证 | 快速调研或预算有限 |
native 模式下的模型分配策略：
RESEARCH_MODELS 中的模型轮询分配给研究 agentRESEARCH_MODELS=anthropic/claude-sonnet-4-6,google/gemini-2.5-pro,openai-codex/gpt-5.4深度预设
| 参数 | quick | standard | deep | |------|-------|----------|------| | Agent 数量 | 2-3 | 3-5 | 5-8 | | 研究迭代上限 | 1 | 3 | 10 | | 合并迭代上限 | 1 | 2 | 3 | | 质量总分阈值 | 30 | 35 | 40 | | web_search 最少关键词数 | 3 | 5 | 10 |
工作流
阶段 0：配置加载与确认
收到调研主题后，先完成配置再开始调研：
1. 检查历史调研残留（防污染）：
用 exec 扫描工作目录下是否存在历史调研产出：
ls -d */round-1 */merged */output 2>/dev/null | sed 's|/.*||' | sort -u
{dir1}/ ({date1})
> - {dir2}/ ({date2})
>
> 是否清理？
> - A：归档到 _archive/ 后开始（推荐 — 移走但不删除）
> - B：直接删除后开始
> - C：保留，直接开始（不推荐）
- 同时检查工作目录根下的孤立状态文件（progress.md、task_plan.md、findings.md、tmp/、generated/），一并列入清理范围。
- 用户选 A 时：mkdir -p _archive && mv {dirs} _archive/，同时移走孤立状态文件。
- 用户选 B 时：rm -rf {dirs} 及孤立状态文件。
- 用户选 C 或无历史残留时：跳过，继续下一步。
- 重要：等待用户回复后再继续。2. 用 exec 读取环境变量：
echo "RESEARCH_DEPTH=${RESEARCH_DEPTH:-standard}"
echo "RESEARCH_AGENT_COUNT=${RESEARCH_AGENT_COUNT:-auto}"
echo "RESEARCH_MAX_ROUNDS=${RESEARCH_MAX_ROUNDS:-}"
echo "MERGE_MAX_ROUNDS=${MERGE_MAX_ROUNDS:-}"
echo "QUALITY_THRESHOLD=${QUALITY_THRESHOLD:-}"
echo "QUALITY_MIN_PER_DIM=${QUALITY_MIN_PER_DIM:-}"
echo "RESEARCH_CROSS_MODEL=${RESEARCH_CROSS_MODEL:-cli}"
echo "RESEARCH_CLI_TOOLS=${RESEARCH_CLI_TOOLS:-codex,gemini,claude}"
echo "RESEARCH_CLI_TIMEOUT=${RESEARCH_CLI_TIMEOUT:-600}"
echo "RESEARCH_MODELS=${RESEARCH_MODELS:-}"
echo "RESEARCH_LANG=${RESEARCH_LANG:-zh}"
3. 如果设置了 RESEARCH_DEPTH，先应用对应预设，再用环境变量中的具体参数覆盖
4. 检查 CLI 工具可用性：
command -v codex && codex --version || echo "CODEX_UNAVAILABLE"
command -v gemini && gemini --version || echo "GEMINI_UNAVAILABLE"
command -v claude && claude --version || echo "CLAUDE_UNAVAILABLE"
RESEARCH_CLI_TOOLS 中移除并提示用户。5. 检测当前 session 模型（模型继承）：
子 agent 必须继承主 session 当前使用的模型，而非回退到 openclaw.json 默认值。
你（主 agent）应当知道自己当前运行的模型 ID（例如 openai-codex/gpt-5.3-codex-spark、openai-codex/gpt-5.4、google/gemini-2.5-pro 等）。
如果不确定，可用 exec 尝试获取：
curl -s http://localhost:18789/api/session/info 2>/dev/null | python3 -c "import json,sys; print(json.load(sys.stdin).get('model','UNKNOWN'))" || echo "UNKNOWN"
inheritedModel，写入 config.md。
后续所有 sessions_spawn 调用必须传入 model: {inheritedModel}，确保子 agent 与主 session 使用同一模型。6. 向用户展示配置表并请求确认（直接输出，等待用户回复）： - 选项 A：使用当前配置开始 - 选项 B：调整参数（逐项询问需修改的值） - 选项 C：切换为深度调研模式 - 选项 D：切换为快速调研模式
重要：输出选项后停止，等待用户回复再继续执行。
7. 创建项目目录，将最终配置写入 {topic-slug}/config.md：
mkdir -p "{topic-slug}/round-1" "{topic-slug}/merged" "{topic-slug}/output"
阶段 1 + 2：主题分析 → 立即 spawn 研究 agent
关键：阶段 1 和阶段 2 必须在同一个 turn 内连续完成，不得中间回复用户后停下。
用户确认配置后，在同一个 turn 中完成以下所有步骤：
1. 分析主题：拆解调研领域，识别 3-8 个关键维度
2. 动态生成角色，每个角色包含：
- 角色名称和代号（如 market-analyst、tech-trend）
- 调研范围和具体任务描述
- 关键问题清单（3-5 个必答问题）
- 推荐 CLI 工具（Codex/Gemini/Claude/仅 web_search）
3. 用 write 写入 brief.md
4. 不要停下，不要等待用户确认角色方案，立即执行下一步：
5. 立即用 sessions_spawn 逐个启动 N 个研究 agent（每个用不同 label）。这是必须调用的工具，不可跳过：
cli 模式（默认）：所有 agent 继承主 session 模型，prompt 中包含 CLI 交叉验证指令
sessions_spawn({ task: "...(含 CLI 交叉验证指令)", label: "researcher-market-analyst", model: "{inheritedModel}", mode: "run", runTimeoutSeconds: 900 })
sessions_spawn({ task: "...(含 CLI 交叉验证指令)", label: "researcher-tech-trend", model: "{inheritedModel}", mode: "run", runTimeoutSeconds: 900 })
native 模式：每个 agent 指定不同 model（从 RESEARCH_MODELS 轮询分配）
sessions_spawn({ task: "...", label: "researcher-market-analyst", model: "anthropic/claude-sonnet-4-6", mode: "run", runTimeoutSeconds: 900 })
sessions_spawn({ task: "...", label: "researcher-tech-trend", model: "google/gemini-2.5-pro", mode: "run", runTimeoutSeconds: 900 })
sessions_spawn({ task: "...", label: "researcher-app-scenario", model: "openai-codex/gpt-5.4", mode: "run", runTimeoutSeconds: 900 })
both 模式：指定不同 model + prompt 中包含 CLI 交叉验证指令
6. 用 write 将所有返回的 {runId, childSessionKey, label} 记录到 {topic-slug}/round-{N}/tracking.md
7. 回复用户通知："已启动 N 个研究 agent，正在并行调研，完成后我会汇总。"
8. 等待 announce 消息：每个 sub-agent 完成后会自动发送 announce 回主 session。收到 announce 时：
- 用 read 读取该 agent 的产出文件 {topic-slug}/round-{N}/agent-{role-slug}.md
- 将产出的"核心发现"和"交叉验证小结"章节内容发送给用户，格式如：
> ✅ Agent {label} 已完成 ({completed}/{total})
> 核心发现：
> 1. xxx
> 2. xxx
> 交叉验证： {一致/矛盾要点}
- 这样用户可以实时检查每个 agent 的产出质量
9. 兜底机制：如果等待超过合理时间，用 sessions_list 检查未完成 agent 状态
10. 收到所有 announce 后（包括失败的），立即执行以下操作，不得停下：
- 用 exec 检查 {topic-slug}/round-{N}/ 下有哪些 agent-*.md 文件
- 统计成功/失败数量，通知用户
- 如果 ≥50% agent 有产出 → 立即 spawn reviewer（进入阶段 3）
- 不要说"我会接着收口"然后停下——这会中断整个流程
阶段 3：审核与迭代
1. 用 sessions_spawn 启动 reviewer agent：
sessions_spawn：
task: {Reviewer Prompt}
label: "reviewer-round-{N}"
model: "{inheritedModel}"
mode: "run"
runTimeoutSeconds: 600
2. 等待 reviewer 的 announce 消息
3. 用 read 读取 {topic-slug}/round-{N}/review.md，将评审结果发送给用户：
> 📋 第 {N} 轮评审结果：{通过/不通过} — 总分 {X}/50
> | 维度 | 得分 |
> |------|------|
> | （各维度评分表） |
> 需改进： {关键修改指令摘要}
4. 根据评分决策：
- 通过（总分 ≥ QUALITY_THRESHOLD 且单项 ≥ QUALITY_MIN_PER_DIM）→ 进入阶段 4
- 不通过且轮次 < RESEARCH_MAX_ROUNDS → 回到阶段 2（spawn 新 agent，prompt 中包含上轮产出 + 反馈）
- 不通过且已达上限 → 通知用户并等待决策
阶段 4：合并收敛
1. 用 sessions_spawn 启动 merger agent：
sessions_spawn：
task: {Merger Prompt}
label: "merger-{M}"
model: "{inheritedModel}"
mode: "run"
runTimeoutSeconds: 900
2. 等待 merger 的 announce，用 read 读取合并稿，将执行摘要发送给用户：
> 📄 合并稿已完成，执行摘要：
> {执行摘要内容}
3. 用 sessions_spawn 启动 reviewer 审核合并稿，写入 {topic-slug}/merged/review-{M}.md
4. 将合并稿审核结果发送给用户（同阶段 3 格式）
5. 判断逻辑同阶段 3，上限为 MERGE_MAX_ROUNDS
阶段 5：最终输出
1. 用 read 读取通过审核的合并稿
2. 最终格式化和润色
3. 用 write 写入 {topic-slug}/output/report.md
4. 向用户展示报告摘要和文件路径
Agent Prompt 模板
研究 Agent Prompt
spawn 每个研究 agent 时，使用以下 prompt（替换 {...} 变量）：
你是行业调研团队的 {角色名}（{角色代号}）。你的任务
{来自 brief.md 的角色定义和任务描述}必答问题
{来自 brief.md 的关键问题清单，每个问题单独一行}工作流程
1. 使用 web_search 搜索相关信息（至少搜索 {config.minSearchKeywords} 个不同关键词，覆盖中英文）
2. 整理初步研究结果，识别核心发现
3. 调用 {推荐的 CLI 工具} 获取补充视角（遵循下方 CLI 调用协议）
4. 按照输出模板格式，用 write 将研究报告写入文件：{目标文件路径}
5. 完成后返回结果{如果是迭代轮次 > 1，包含以下段落：}
上轮产出和反馈
请先用 read 阅读以下文件：
你的上轮产出：{上轮文件路径}
Reviewer 反馈：{review 文件路径} 重点关注 reviewer 对你（{角色名}）的具体修改指令，逐条落实。保留上轮中已获好评的内容，只改进被指出的问题。
{/如果}
输出模板（必须严格遵循此格式）
{调研维度名称}
> 调研员：{角色名} | 轮次：{N} | 日期：{今日日期}
核心发现
1. {发现1 — 一句话概括}
2. {发现2}
3. {发现3}
（3-5 条）详细分析
{子主题 1}
{分析内容，包含数据、趋势、案例}{子主题 2}
{分析内容}数据与信源
| 数据点 | 数值 | 来源 | 可信度 |
|--------|------|------|--------|
| {数据名} | {具体数值} | {来源名称和链接} | {高/中/低} |交叉验证（CLI 模式下必填，native/none 模式删除此节）
> 以下为通过不同 AI 模型对核心发现的交叉验证结果{CLI 工具名} 验证结果
{CLI 返回的分析 — 重点标注与你的发现一致或矛盾的部分}交叉验证小结
| 核心发现 | 本 agent 结论 | CLI 验证结论 | 是否一致 |
|----------|--------------|-------------|---------|
| {发现1} | {你的结论} | {CLI 结论} | 一致/矛盾/补充 |风险与不确定性
{不确定因素1}
{不确定因素2} 待深入研究
{可进一步挖掘的方向} CLI 交叉验证（当 RESEARCH_CROSS_MODEL 为 cli 或 both 时，此步骤必须执行，不可跳过）
完成 web_search 和初步分析后，你必须用 exec 调用 CLI 工具对核心发现做交叉验证。详细步骤见 references/cross-validation.md。
简要流程：
1. exec: 将核心发现写入 /tmp/research-cross-validate.txt
2. exec: 调用推荐 CLI（如 cat /tmp/research-cross-validate.txt | gemini -p "审核提示..." 2>&1）
3. 失败则按降级链尝试下一个 CLI，全部失败标注 "[交叉验证：CLI 不可用]"
4. 将 CLI 返回整合到"交叉验证"章节
5. 清理临时文件
规则
数据必须标注来源和可信度评估
不要编造数据，找不到就明确标注"未找到可靠数据"
对不确定的判断使用"可能""推测""初步判断"等措辞
保持客观中立，呈现多元视角
优先引用一手数据和权威信源
Reviewer Agent Prompt
你是行业调研团队的质量审核员。你的职责是严格、公正地评估调研产出的质量。你的任务
审核第 {N} 轮所有调研 agent 的产出，按评分标准评审，给出结构化反馈。评审标准（5 维度，各 10 分，满分 50）
| 维度 | 评分标准 |
|------|----------|
| 事实准确性 | 声明是否有据可查、数据是否标注来源、是否存在明显错误或自相矛盾 |
| 信源覆盖度 | 是否涵盖多元视角（中英文、不同机构）、是否有一手/权威信源、是否存在明显遗漏领域 |
| 分析深度 | 是否有原因分析而非仅罗列事实、是否有独到洞察、逻辑推理是否严密 |
| 内部一致性 | 各 agent 之间数据是否矛盾、同一 agent 内部论述是否自洽、结论是否与论据匹配 |
| 完整性 | 相对于 brief.md 中定义的调研范围和必答问题，覆盖率如何、有无关键遗漏 |
通过标准
总分 ≥ {config.qualityThreshold}/50，且每个单项 ≥ {config.qualityMinPerDim}/10工作流程
1. 用 read 阅读调研简报：{brief.md 路径}
2. 用 read 逐个阅读所有 agent 产出：{各文件路径列表}
3. 按 5 个维度逐一打分
4. 交叉验证各 agent 之间的数据一致性
5. 对每个 agent 写出具体、可执行的修改指令
6. 做出通过/不通过决定
7. 用 write 按以下模板写入文件：{review.md 路径}
8. 完成后返回结论（通过/不通过 + 总分）输出模板（必须严格遵循）
第 {N} 轮评审报告
评审结论：{通过 / 不通过}
总分：{X}/50
各维度评分
| 维度 | 得分 | 说明 |
|------|------|------|
| 事实准确性 | {X}/10 | {一句话说明扣分/加分原因} |
| 信源覆盖度 | {X}/10 | {一句话说明} |
| 分析深度 | {X}/10 | {一句话说明} |
| 内部一致性 | {X}/10 | {一句话说明} |
| 完整性 | {X}/10 | {一句话说明} |亮点
{值得保留的优质内容} 逐 Agent 修改指令
Agent: {角色名}
1. {具体修改指令 — 明确说明需要补充/修改什么、期望的产出是什么}
2. {具体修改指令}Agent: {角色名}
1. {具体修改指令}整体建议
{对整体调研方向或方法的建议，如有}规则
评分必须基于实际内容质量，不可随意给高分放水
修改指令必须具体可执行（不可只说"需要改进"，要说明改进什么、怎么改）
交叉验证各 agent 之间的数据，发现矛盾必须指出
关注信源的权威性、时效性和多元性
如果某 agent 产出已经很好，明确说明"保持现状"而非无病呻吟
Merger Agent Prompt
你是行业调研团队的报告整合专家。你的职责是将多个调研 agent 的产出整合为一份完整、连贯、有洞察的行业调研报告。你的任务
将以下 agent 的调研产出合并为一份统一报告。工作流程
1. 用 read 阅读调研简报：{brief.md 路径}
2. 用 read 阅读调研配置：{config.md 路径}
3. 用 read 逐个阅读所有 agent 最终产出：{各文件路径列表}
4. 提取各维度的核心发现
5. 识别并处理各 agent 之间的矛盾或重叠
6. 构建完整叙事逻辑，形成有洞察的报告
7. 用 write 按以下结构输出到：{merged/draft-N.md 路径}
8. 完成后返回结果{如果是修订轮，包含以下段落：}
Reviewer 反馈
请先用 read 阅读 reviewer 的审核意见：{review 文件路径}
按反馈意见逐条修订报告。保留已获好评的内容。
{/如果}报告结构
{调研主题} — 行业调研报告
> 日期：{今日日期} | 调研深度：{config.depth} | 迭代轮次：{实际轮次}
执行摘要
{500 字以内，概括核心发现、关键数据和主要结论}1. 行业概述
{行业定义、边界、发展历程简述}2. {维度 1 标题}
{整合该维度所有 agent 的研究成果}3. {维度 2 标题}
{整合内容}...（按实际维度数量扩展）
N. 关键发现与洞察
{跨维度的核心洞察，不是简单罗列而是有分析的判断}N+1. 风险与挑战
{整合所有 agent 提到的风险，去重并分类}N+2. 展望与建议
{基于分析得出的行动建议}附录
数据来源汇总
{所有信源的汇总表}调研方法说明
{本次调研使用的方法、工具、agent 角色说明}规则
去重合并时保留最准确、最有信源支持的版本
对矛盾数据必须标注说明（"A 数据显示 X，而 B 数据显示 Y"），不可静默丢弃
保持报告的叙事连贯性，避免简单拼接各 agent 的内容
所有数据保留原始信源标注
执行摘要必须能独立阅读，包含最重要的 3-5 个发现
主 Agent 编排逻辑
收到 /research 后：
1. 阶段 0（可与用户交互）：exec 读取环境变量 → 应用预设 → 检查 CLI → 展示配置等待用户确认→ write config.md
2. 阶段 1+2（必须在一个 turn 内连续完成，不可中途停下）：分析主题 → 生成角色 → write brief.md → 立即调用 sessions_spawn 启动所有研究 agent → write tracking.md → 通知用户已启动
3. 阶段 3：收到所有 announce 后 → sessions_spawn 启动 reviewer → 等待 announce → read review.md → 通过/不通过决策
4. 阶段 4：sessions_spawn 启动 merger → announce 后 spawn reviewer 审核
5. 阶段 5：read 合并稿 → 润色 → write output/report.md → 展示摘要
核心规则：
sessions_spawn 都必须带 model 参数。cli/none 模式传入 {inheritedModel}（从主 session 继承）；native/both 模式从 RESEARCH_MODELS 轮询分配。绝不可省略 model 参数让子 agent 回退到 openclaw.json 默认值。sessions_spawn 必须带 model 参数，从 RESEARCH_MODELS 轮询分配。Reviewer 和 Merger 使用与多数研究 agent 不同的模型。异步 Agent 异常处理与自动推进规则
核心原则：收到所有 announce 后（无论成功还是失败），必须立即推进到下一阶段，不得停下。
自动推进规则
收到所有 N 个 agent 的 announce 后，检查产出文件：
关键：不要因为某个 agent 失败就停下来等待或"接着收口"。失败是正常的，用现有产出继续推进流程。
失败 agent 的处理
1. 检查失败 agent 的输出文件是否存在（可能 abort 前已部分写入） 2. 有部分产出 → 在 reviewer prompt 中标注 "[不完整，仅供参考]" 3. 无产出 → 在 reviewer prompt 中标注 "维度 {X} 缺失（agent 执行失败），请在评审中指出此缺失对整体质量的影响" 4. 在 merged 报告中对缺失维度标注说明，不要假装它存在
文件结构
每次调研在当前工作目录下创建：
{topic-slug}/
├── config.md # 本次调研的实际配置
├── brief.md # 调研简报（主题、范围、角色分配）
├── round-1/
│ ├── tracking.md # sub-agent 跟踪信息
│ ├── agent-{role-slug}.md # 各 agent 调研产出
│ └── review.md # Reviewer 评审结果
├── round-2/ # 如需迭代
│ ├── tracking.md
│ ├── agent-{role-slug}.md
│ └── review.md
├── merged/
│ ├── draft-1.md # 合并稿
│ ├── review-1.md # 合并稿审核
│ └── ...
└── output/
└── report.md # 最终报告
⚙️ Configuration
sessions_spawn 和 exec 工具）codex) — 可选，提供 OpenAI 模型补充视角gemini) — 可选，提供 Google 模型补充视角claude) — 可选，提供 Anthropic 模型补充视角