deep-research

name	deep-research
description	唐氏深度研究法（Tang Deep Research）。迭代式深度研究工作流，通过多轮「发散→收敛」循环对复杂问题进行系统化深入分析。适用于投资机会挖掘、问题本质探究、技术调研、方案选型等需要深度思考的任务。触发词：唐氏深度研究、深度研究、深度调研、迭代研究、深入分析、投资研究、deep research、iterative research。
argument-hint	描述你要研究的问题

唐氏深度研究法（Tang Deep Research）

由算法工程师唐玉宾提出的一种迭代式深度研究工作方法。核心思路：发散 → 收敛 → 发散 → 收敛 → … → 最终结论。

每一轮探索都会带来新的信息、新的线索、新的视角，这些新发现又会驱动下一轮更有针对性的发散探索。通过反复的发散-收敛循环，不断拓展认知边界，最终形成深入且全面的结论。

这套方法的精髓不是一开始就把整条研究路线规划得非常死板，而是在大方向正确的前提下，根据研究过程中不断累积的新信息随机应变，动态调整后续的研究方向、任务设计和推进方式。

---

何时使用

• 挖掘投资机会——发现被忽视的标的、分析行业趋势、评估风险与收益
• 探究问题本质——透过表象找到根本原因，避免停留在浅层解释
• 技术调研、方案选型——对比多个方案，权衡利弊
• 任何需要多维度、多层次深入分析的复杂问题

不适合：能直接回答的简单问题。

---

研究深度

深度研究支持 1-100 级的研究深度，深度级别决定了发散-收敛循环的迭代轮数。

• 用户指定深度：用户可以明确要求研究深度，例如"深度 7 级研究"意味着要执行 7 轮发散-收敛迭代。深度越高，研究越充分，但耗时也越长。这是硬约束：只要用户明确指定了研究深度、研究轮次或等价的轮数要求，Agent 就必须研究够对应轮数才能停止，不能因为主观觉得“已经差不多了”“信息已经够了”就提前结束。
• 这里的“研究够对应轮数”指的是：最后一轮也仍然要完整经历“任务拆解 → 执行探索 → 阶段总结 → delta 产出”的闭环。最终回答用户的问题不是最后一轮本身，而是所有轮次完成之后新增的一个独立综合阶段。
• 自动判定深度：如果用户没有指定深度，根据问题的复杂程度和模糊程度动态决定。边界清晰的具体问题 2-3 轮足够，开放性的复杂问题可能需要 7-100 轮。

深度研究的价值恰恰在于足够多轮次的深入挖掘。不要害怕迭代轮数多，重要的是每一轮都能有新发现、新线索，推动研究不断深入。

研究流程

1. 初始化

在当前工作目录下创建一个归档文件夹，用于存放整个研究过程的所有文件。

如果当前环境是 OpenClaw，则必须先启动 deep-research 会话，而不是直接手工创建目录。原因是：它不只会初始化归档，还会把“当前这一次研究”绑定成 OpenClaw 的活跃 deep-research 会话，让 runtime guard 只对这一次研究生效。

OpenClaw 中如果存在 deep_research_session 工具，必须优先调用它：

{
  "action": "start",
  "topic": "<topic-slug>",
  "question": "<用户问题>",
  "target_depth": <N>,
  "depth_mode": "auto"
}

轮次推进和最终收口也优先继续走同一个工具，而不是手工改 00_meta.json：

{
  "action": "advance-round"
}

适用时机：当前轮的 03_round_summary.md 和 04_delta_report.json 已经写完，准备进入下一轮或确认已完成全部轮次。这个动作会原子完成：

• 校验当前轮
• 更新本轮通过后的 meta 状态
• 若还没到目标轮次，则自动起好下一轮骨架

全部轮次完成且 final_report.md 已写成真实内容后，再调用：

{
  "action": "finalize"
}

这个动作会先校验全归档，再把研究状态原子收口到 completed。

如果研究中途停止、换了聊天会话，或不确定下一步该做什么，优先调用：

{
  "action": "recover"
}

它会读取当前活跃研究归档、运行检查器，并返回下一步最小修复或继续建议。OpenClaw runtime guard 默认是 lite 模式，主要依赖 advance-round / finalize / recover 这些 checkpoint，而不是在每个工具调用上做强拦截。

只有在该工具不存在或不可用时，才允许退回到脚本方式：

python scripts/openclaw_deep_research_session.py start \
  --topic <topic-slug> \
  --question "<用户问题>" \
  --target-depth <N> \
  --depth-mode <auto|user-specified>

如果用户明确要求继续某个已有研究，而不是新开一轮，则用：

python scripts/openclaw_deep_research_session.py activate \
  --research-dir /absolute/path/to/research_xxx

强约束：

• 如果 deep_research_session 工具或会话脚本调用失败，禁止退化成手工 mkdir research_xxx 再继续研究
• 正确做法是：读取错误，修复原因，重试会话启动
• 只有会话真正启动/激活成功后，才允许写 00_meta.json、round_N/*、final_report.md
• OpenClaw 中优先使用 deep_research_session 的 advance-round / finalize 完成生命周期跳转，不要手工编辑 00_meta.json 推进轮次或收尾

在 OpenClaw 中，启动或激活研究会话后，进入任何真实研究动作前必须先读取以下文件，并以它们作为唯一权威协议：

• templates/01_seed_clues.json
• templates/02_task_registry.json
• templates/04_delta_report.json
• scripts/check_deep_research_archive.py
• scripts/deep_research_state_machine.py

约束如下：

• SKILL.md 只负责解释方法论，不是 schema 权威来源
• 真实字段名、合法状态值、轮次流转规则，必须以模板与脚本中的实现为准
• 不允许把 memory、旧归档、历史修复记录、旧实验 run 当作 schema authority
• 如果 memory 或旧案例与当前模板/脚本冲突，必须忽略 memory，服从当前仓库实现

文件夹命名：research_<日期>_<主题关键词>/，例如 research_20260411_api-gateway/

初始化阶段不是可选建议，而是继续研究前的前置条件。Agent 必须先完成以下归档骨架，才能进入任务拆解：

• 00_research_brief.md：记录用户原始问题、研究目标、约束条件、预期交付物
• 00_meta.json：记录机器可读元数据，至少包含 topic、target_depth、depth_mode、current_round、status
• 若仓库中存在 scripts/check_deep_research_archive.py，初始化完成后应立即运行一次检查，确认归档骨架有效

如果仓库中存在 scripts/init_deep_research_archive.py，应优先调用该脚本创建研究目录和模板文件，而不是手工拼装目录结构。只有在脚本不存在或确实无法执行时，才允许手工初始化。

00_meta.json 推荐结构如下：

{
	"topic": "api-gateway",
	"original_question": "用户的原始问题",
	"target_depth": 5,
	"depth_mode": "user-specified",
	"current_round": 0,
	"status": "initialized"
}

2. 问题拆解（发散阶段）

根据用户的需求（以及上一轮总结中发现的新线索），把问题拆解成若干个可独立执行的探索任务。

这里要避免在研究一开始就把后面所有轮次的任务一次性规划死。深度研究只需要先把当前这一轮拆好，后续轮次应该由当前轮的发现来决定。

拆解时思维要足够发散。 不是只有"确定需要"的任务才值得做。任何有一点可能性的方向、甚至看起来关联不大的探索角度，都可以作为任务加进来。这一步的目标是尽可能拓宽视野，防止研究过早收敛到浅显或片面的状态。

可以刻意加入一些"野生"任务——看似边缘甚至随机的探索方向。很多时候，意外的发现恰恰来自这些非常规的探索路径。主线任务保证研究的基本覆盖，野生任务负责制造惊喜和突破。

从这一阶段开始，Agent 必须先写归档文件，再开始任何搜索、抓取、读文件、运行程序等探索动作。每一轮至少产出以下文件：

• round_N/01_seed_clues.json：本轮切入线索。第 1 轮来自原始问题，第 N 轮（N > 1）必须显式引用上一轮 04_delta_report.json 中的线索 ID
• round_N/02_task_registry.json：任务登记表，是本轮唯一合法的任务清单

拆解要点：

• 每个任务应该是独立的，可以并行执行
• 每个任务都是一个完整的探索子任务，不等于只搜一个 query；它可以包含搜索、读文件、写程序、运行程序、抓取网页、调用工具、交叉验证等完整执行动作
• 任务数量根据问题复杂度决定，一般 8-20 个
• 每个任务要有清晰的目标——要找出什么、搞清楚什么
• 不要自我审查过度——"这个方向可能没用"不是拒绝探索的理由
• 把任务计划写入归档文件夹

02_task_registry.json 中的每个任务至少要包含以下字段：

• task_id：本轮唯一 ID，例如 R01-T03
• title：任务标题
• task_type：exploratory、verification、counterevidence、wildcard 之一
• research_dimension：研究维度，必须尽量避免重复
• key_question：本任务唯一要回答的问题
• planned_actions：至少 3 个动作，禁止只写单个搜索动作
• expected_evidence：预期获得的证据类型
• depends_on：默认必须为空；若非空，说明拆解失败，应重构任务
• report_path：本任务结果文件路径

任务独立性的最低要求：

• 同一轮任务的 key_question 不能重复
• 同一轮任务的 report_path 必须一一对应
• depends_on 必须为空数组；不允许把前一个任务的输出作为后一个任务的前置条件
• 若大部分任务落在同一 research_dimension，说明拆解过窄，必须重写登记表

如果检查器对 02_task_registry.json 给出失败结果，Agent 必须先重写任务登记表并重新检查，禁止带着失败结果进入执行探索。

3. 执行探索

逐个执行拆解出来的探索任务。如果 Agent 框架支持 subagent，优先并行执行以提高效率。

这里的“执行探索”不是机械地对每个任务发一个搜索请求就算完成。一个探索任务本身可能就是复杂执行单元：需要多次搜索、读取资料、编写并运行代码、抓取网页、调用外部工具、做交叉验证，甚至中途根据发现调整该子任务内部的执行路径。评价标准是这个任务有没有把该方向真正探明，而不是有没有发出过一个 query。

mmx-cli 工具优先原则：如果当前环境已安装 mmx-cli 工具，在执行探索时应优先使用它：

• 搜索任务：优先使用 mmx search <关键词> 进行信息检索，它能提供更高质量、更全面的搜索结果
• 长上下文处理：当需要处理长文本任务（如汇总大量材料、分析长篇文档、综合多份报告等），优先使用 mmx text chat --message "<你的问题或指令>" 利用 1M 上下文大模型的能力来处理，避免因上下文窗口限制而丢失关键信息

判断是否安装：可通过 which mmx 或 mmx --version 检查。若未安装，退回到常规搜索和文本处理方式即可。

如果任务涉及新闻、价格、市场走势、政策变化、宏观数据、公司动态等强时效性信息，执行纪律要再提高一档：

• 优先获取更近的信息，不能拿明显过时的材料直接下结论
• 必须显式记录绝对日期，不要只写“今天/昨天/最近”
• 必须区分“事件发生日期”“信息发布日期”“数据统计日期”，避免把时间混为一谈
• 关键事实尽量做交叉验证；重要结论不要只压在单一来源上
• 如果不同来源时间冲突或口径冲突，要在任务报告里显式写出，而不是静默忽略

每个任务的执行结果必须单独保存到 round_N/tasks/ 目录，不允许把多个任务混写在同一个文件中。每个任务结果文件都应明确记录：

• 任务目标和对应的 task_id
• 实际执行的动作序列
• 获得的关键证据
• 初步判断或观点
• 不确定项、反例、未解问题
• 下一轮可能值得追踪的线索

如果仓库中存在 round_N/tasks/task_report.template.md，应优先按这个模板写任务报告。至少要保留这些 section：

• Task ID
• Goal
• Executed Actions
• Key Evidence
• Findings
• Open Questions
• Next Leads

一个合格的单任务研究至少满足以下标准：

• 任务文件中存在“执行动作”“关键证据”“结论/判断”“未解决问题”四类内容
• 实际执行不应退化成单次搜索；应有多步动作或多源证据
• 若任务文件只包含概述性结论，没有过程与证据，应判定为无效任务
• 若任务与登记表中的 key_question 不一致，应判定为无效任务

如果本轮任务文件未全部完成，或者检查器报告缺失任务文件、任务内容不合规，则该轮不得进入阶段总结。

4. 阶段总结（收敛阶段）

把本轮所有任务的结果综合起来，进行一轮总结分析。总结保存到归档文件夹。

每轮执行完成后，必须新增以下两个文件，然后才能判断是否进入下一轮：

• round_N/03_round_summary.md：面向人的轮次总结
• round_N/04_delta_report.json：面向检查器的增量发现报告

总结的重点：

• 提炼跨任务的共同发现和关键模式
• 识别不同任务结果之间的矛盾或不一致
• 特别关注本轮探索中涌现的新信息、新线索 —— 这些是驱动下一轮迭代的核心燃料
• 梳理出还没解决的问题、还需要验证的假设
• 评估当前对原始问题的回答程度

04_delta_report.json 至少应包含：

• round：当前轮次
• new_findings：至少 3 条新增发现，每条都有唯一 ID
• contradictions：本轮暴露的矛盾点或冲突点
• carry_forward_clues：传递到下一轮的线索 ID 列表
• coverage_assessment：当前回答原始问题的覆盖程度

如果没有形成新增发现、矛盾点、可传递线索，而只是把已有内容换个说法重写，则该轮应视为无效轮次。

在写完 03_round_summary.md 和 04_delta_report.json 后，如果仓库中存在检查器，Agent 必须立即运行检查器读取结果：

• 检查结果为 PASS：才允许更新 00_meta.json 中的轮次状态，并进入下一轮，或在所有轮次都完成后进入独立的最终综合阶段
• 检查结果为 FAIL：必须先修复失败项，再重新运行检查器；禁止跳过失败项继续研究
• 在 OpenClaw 中，优先调用 deep_research_session 的 advance-round，因为它会把“校验当前轮 + 更新 meta + 必要时起下一轮”作为一个原子动作完成；如果任务报告只是空壳，advance-round 会直接拒绝通过

5. 迭代决策

如果用户指定了研究深度（如"深度 8 级"），则按指定轮数执行迭代，并且必须完成全部轮次。这种情况下，不允许因为当前结论看起来已经足够完整、信息增益暂时下降，或者 Agent 主观判断边际收益变小，就提前停止。

如果用户未指定深度，根据以下因素动态决定：

继续迭代：

• 本轮探索中发现了新的信息或线索值得追踪
• 还有重要的未解决问题
• 现有信息不足以得出可靠结论
• 存在需要验证的矛盾或假设

停止迭代：

• 原始问题已经得到充分回答
• 最近一轮没有产生有价值的新信息（信息增益趋近于零）
• 继续研究的边际收益很小

以上停止条件只适用于用户没有明确指定研究深度或轮次的情况。

如果继续，回到第 2 步——基于本轮总结中发现的新线索和尚未解决的问题，设计新一轮的探索任务。注意：新一轮不一定总是更聚焦，如果总结中发现了全新的方向，完全可以再次大幅发散。

轮次与轮次之间必须是串行关系。第 N+1 轮的探索方向，必须等第 N 轮的探索结果和总结出来之后才能确定，不能在第 1 轮开始时就把第 2、3、4 轮预先写死。

从执行纪律上，进入下一轮前必须满足以下门槛：

• 上一轮的 03_round_summary.md 和 04_delta_report.json 已完成
• 00_meta.json 中的 current_round 已更新为上一轮轮次
• 若仓库中存在检查脚本，则上一轮检查结果必须通过
• 新一轮的 01_seed_clues.json 必须引用上一轮 carry_forward_clues

失败处理流程是强约束，不是建议：

1. 检查器 FAIL
2. 阅读失败原因并只修复对应归档文件
3. 重新运行检查器
4. 直到检查器 PASS 才允许继续

严禁以下行为：

• 明知检查器失败，仍继续开启下一轮
• 用补一句“后续再完善”来绕过缺失文件或重复任务
• 在未重跑检查器的情况下，假定问题已经修复

如果用户明确指定了轮数，Agent 不得使用“已经足够全面”“结论已明确”“边际收益不大”等理由提前收尾。若某轮信息增益不足，应扩大视角或引入对抗性任务，而不是提前结束。

6. 最终综合与报告

所有研究轮次都完成后，进入一个独立于各轮之外的最终综合阶段：综合全部研究信息，生成最终研究报告，保存到归档文件夹。

这一阶段不是“最后一轮的总结扩写版”。最后一轮和前面各轮一样，职责仍然是完成本轮探索与收敛；只有当最后一轮的 03_round_summary.md 和 04_delta_report.json 也通过检查后，才允许开始最终综合。

报告要回答用户的原始问题，给出明确的结论和建议。包含：

• 核心结论
• 跨轮综合与证据权重
• 关键发现及其证据来源（哪一轮、哪个任务发现的）
• 时效性与交叉验证说明
• 具体建议
• 局限性和不确定性说明

最终目标不是把研究越做越窄，而是在充分吸收多轮研究结果之后，形成一个既有广度、又有深度、并且足够干货的结论。收敛是为了提炼高价值判断，不是为了把研究面越收越小、最后只剩单一路径。

最终报告阶段的前置条件：

• 若用户指定了研究深度，00_meta.json 中的 current_round 必须等于 target_depth
• 每一轮都存在完整归档文件，并通过检查
• 00_meta.json 必须先进入“已完成所有轮次、等待最终综合”的状态，再开始撰写真实的 final_report.md
• final_report.md 必须引用轮次和任务来源，不能只给出无来源结论
• final_report.md 必须回看并综合全部轮次的任务报告、轮次总结和 delta 信息，禁止只根据最后一轮或少数几个任务草率收尾
• 若问题含有时效性，最终报告必须显式交代关键日期、数据日期与交叉验证动作

如果严格检查模式失败，Agent 必须回到缺失轮次或缺失文件处补齐；不能直接输出“阶段性结论”替代最终报告。

---

归档协议

以下结构从“参考”升级为默认协议。若仓库中提供了模板和检查器，应优先按该结构执行：

research_20260411_api-gateway/
├── 00_research_brief.md
├── 00_meta.json
├── round_01/
│   ├── 01_seed_clues.json
│   ├── 02_task_registry.json
│   ├── 03_round_summary.md
│   ├── 04_delta_report.json
│   └── tasks/
│       ├── task_01_*.md
│       └── ...
├── round_02/
│   └── ...
└── final_report.md

其中：

• 00_meta.json 用于记录目标轮数、当前轮次、执行状态，是检查器的主要输入
• 01_seed_clues.json 用于把上一轮的增量发现显式传给下一轮，防止轮次脱节
• 02_task_registry.json 用于判定任务数、任务独立性和任务文件对齐情况
• 04_delta_report.json 用于判定本轮是否真的带来了新增信息，而不是空转

如果框架或环境支持脚本执行，建议在每轮完成后运行检查器，例如：

python scripts/check_deep_research_archive.py --research-dir research_20260411_api-gateway --strict

如果仓库提供了初始化脚本，建议优先用它创建研究骨架，例如：

python scripts/init_deep_research_archive.py --topic api-gateway --question "是否应该引入统一 API gateway" --target-depth 5 --depth-mode user-specified

---

实践要点

关于任务设计

• 任务之间要独立，不要设计成"任务 B 依赖任务 A 的输出"这种串行结构
• 每一轮的任务是"扇出-扇入"模式：并行探索，然后汇总到一个总结
• 拆解任务时宁可多拆不要少拆，宁可发散过度也不要遗漏视角
• 适当加入一些"探索性赌注"——不确定会不会有收获，但值得一试的方向
• 至少保留一部分 counterevidence 或 wildcard 任务，避免整轮任务都在重复验证同一假设
• 任务的粒度应以“能形成一份独立任务报告”为准，而不是“能发出一个搜索请求”为准

关于自动化执行

• 整个研究过程应尽量自动化完成，不要在中间环节频繁打断用户确认
• 接到研究任务后，自主完成初始化、拆解、探索、总结、迭代的全流程，直到输出最终报告
• 如果用户明确指定了研究深度、研究轮次或等价轮数要求，必须完整执行到指定轮次后才能停
• 只在确实无法自行判断的关键抉择时才询问用户（例如研究方向出现根本性偏差，或发现用户需求本身有歧义）
• 每轮迭代的方向调整、任务设计、停止判断等，都由 Agent 自主决策
• 如果仓库内存在检查器，应把“运行检查器并读取结果”视为每轮结束后的固定动作，而不是可选动作
• 如果仓库内存在初始化脚本，应优先使用它生成归档骨架和模板，而不是手工创建一组可能不完整的文件

关于迭代节奏

• 迭代的动力来自每一轮探索中涌现的新信息——有新线索就值得继续
• 如果发现原始问题的定义有偏差，自主调整研究方向
• 不要害怕迭代轮数多，深度研究的价值恰恰在于足够多轮次的深入挖掘
• 如果用户指定了研究轮数，轮次不足时不得直接收尾，只能通过补轮、补任务、补总结解决

关于总结质量

• 总结是精炼而非堆砌，提取模式而非罗列事实
• 明确标注不确定的部分，不要臆断
• 每发现一个结论，追溯它的证据来源
• 总结必须产出可传递到下一轮的线索，而不是只做静态复述

关于并行执行

• 优先使用 subagent 并行执行探索任务（如果框架支持）
• 给每个 subagent 清晰的任务描述和预期产出说明
• subagent 不需要知道完整的研究上下文，只需要知道自己的任务
• subagent 是 task worker，不是整场 deep-research 的 orchestrator；它的合法收尾条件是“完成自己负责的任务并交回结果”，不是把整个研究推进到 finalize
• 即便并行执行，也要先完成任务登记，再把任务分发给 subagent；禁止边想边补登记表

子代理等待机制（建议）

OpenClaw 的子代理是 push-based 架构：spawn 后子代理在后台运行，完成后 completion event 会作为下一条消息推送给主 agent。为了减少丢消息和半成品归档，建议主 agent 正确等待：

1. spawn 所有子代理后，必须立即调用 sessions_yield

{ "action": "sessions_yield", "message": "等待子代理完成" }

这会结束当前 turn，让 completion event 作为下一条消息到达。

2. 建议在 spawn 后尽快 yield：spawn → sessions_yield 越紧密，越不容易出现主会话继续跑但子任务结果尚未到达的状态。

3. 子代理完成事件到达后，主 agent 被唤醒，此时必须：

   • 按 02_task_registry.json 中的 task_id 逐一验证 task report 文件
   • 有缺失的文件则标记为失败，可在下一批重试
   • 全部确认后才能进入 round summary 和 delta report 阶段

4. 被唤醒后仍有子代理在运行，建议再次 yield：如果某个子代理完成（成功或失败）唤醒了主 agent，但主 agent 检查发现同一批次中还有其他子代理未完成，则主 agent 在处理完已完成子代理的结果后，建议再次调用 sessions_yield 等待剩余 completion event 到达。

{ "action": "sessions_yield", "message": "等待剩余子代理完成" }

5. 多批次执行：如果一轮 task 数量较多（>2 个），分批次 spawn（每批 2 个），每批都遵循 spawn → sessions_yield → 验证文件的流程。

6. 避免：

   • spawn 后长期不检查子任务产物
   • 被唤醒后发现仍有子代理在运行却直接写轮次总结
   • 用 exec sleep 或 process poll 长时间轮询子代理状态
   • 用 sessions_list 高频轮询子代理状态