菜单
唐氏深度研究法（Tang Deep Research）。迭代式深度研究工作流，通过多轮「发散→收敛」循环对复杂问题进行系统化深入分析。适用于投资机会挖掘、问题本质探究、技术调研、方案选型等需要深度思考的任务。触发词：唐氏深度研究、深度研究、深度调研、迭代研究、深入分析、投资研究、deep research、iterative research。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | deep-research |
| description | 唐氏深度研究法（Tang Deep Research）。迭代式深度研究工作流，通过多轮「发散→收敛」循环对复杂问题进行系统化深入分析。适用于投资机会挖掘、问题本质探究、技术调研、方案选型等需要深度思考的任务。触发词：唐氏深度研究、深度研究、深度调研、迭代研究、深入分析、投资研究、deep research、iterative research。 |
| argument-hint | 描述你要研究的问题 |
由算法工程师唐玉宾提出的一种迭代式深度研究工作方法。核心思路：发散 → 收敛 → 发散 → 收敛 → … → 最终结论。
每一轮探索都会带来新的信息、新的线索、新的视角，这些新发现又会驱动下一轮更有针对性的发散探索。通过反复的发散-收敛循环，不断拓展认知边界，最终形成深入且全面的结论。
这套方法的精髓不是一开始就把整条研究路线规划得非常死板，而是在大方向正确的前提下，根据研究过程中不断累积的新信息随机应变，动态调整后续的研究方向、任务设计和推进方式。
不适合：能直接回答的简单问题。
深度研究支持 1-100 级的研究深度，深度级别决定了发散-收敛循环的迭代轮数。
在当前工作目录下创建一个归档文件夹，用于存放整个研究过程的所有文件。
如果当前环境是 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 已经写完，准备进入下一轮或确认已完成全部轮次。这个动作会原子完成：
全部轮次完成且 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.mddeep_research_session 的 advance-round / finalize 完成生命周期跳转，不要手工编辑 00_meta.json 推进轮次或收尾在 OpenClaw 中，启动或激活研究会话后，进入任何真实研究动作前必须先读取以下文件，并以它们作为唯一权威协议：
templates/01_seed_clues.jsontemplates/02_task_registry.jsontemplates/04_delta_report.jsonscripts/check_deep_research_archive.pyscripts/deep_research_state_machine.py约束如下：
SKILL.md 只负责解释方法论，不是 schema 权威来源文件夹命名：research_<日期>_<主题关键词>/，例如 research_20260411_api-gateway/
初始化阶段不是可选建议，而是继续研究前的前置条件。Agent 必须先完成以下归档骨架，才能进入任务拆解：
00_research_brief.md：记录用户原始问题、研究目标、约束条件、预期交付物00_meta.json：记录机器可读元数据，至少包含 topic、target_depth、depth_mode、current_round、statusscripts/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"
}
根据用户的需求（以及上一轮总结中发现的新线索），把问题拆解成若干个可独立执行的探索任务。
这里要避免在研究一开始就把后面所有轮次的任务一次性规划死。深度研究只需要先把当前这一轮拆好，后续轮次应该由当前轮的发现来决定。
拆解时思维要足够发散。 不是只有"确定需要"的任务才值得做。任何有一点可能性的方向、甚至看起来关联不大的探索角度，都可以作为任务加进来。这一步的目标是尽可能拓宽视野，防止研究过早收敛到浅显或片面的状态。
可以刻意加入一些"野生"任务——看似边缘甚至随机的探索方向。很多时候，意外的发现恰恰来自这些非常规的探索路径。主线任务保证研究的基本覆盖，野生任务负责制造惊喜和突破。
从这一阶段开始，Agent 必须先写归档文件，再开始任何搜索、抓取、读文件、运行程序等探索动作。每一轮至少产出以下文件：
round_N/01_seed_clues.json：本轮切入线索。第 1 轮来自原始问题，第 N 轮（N > 1）必须显式引用上一轮 04_delta_report.json 中的线索 IDround_N/02_task_registry.json：任务登记表，是本轮唯一合法的任务清单拆解要点：
02_task_registry.json 中的每个任务至少要包含以下字段：
task_id：本轮唯一 ID，例如 R01-T03title：任务标题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 必须先重写任务登记表并重新检查，禁止带着失败结果进入执行探索。
逐个执行拆解出来的探索任务。如果 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 IDGoalExecuted ActionsKey EvidenceFindingsOpen QuestionsNext Leads一个合格的单任务研究至少满足以下标准：
key_question 不一致，应判定为无效任务如果本轮任务文件未全部完成，或者检查器报告缺失任务文件、任务内容不合规，则该轮不得进入阶段总结。
把本轮所有任务的结果综合起来，进行一轮总结分析。总结保存到归档文件夹。
每轮执行完成后，必须新增以下两个文件，然后才能判断是否进入下一轮：
round_N/03_round_summary.md：面向人的轮次总结round_N/04_delta_report.json：面向检查器的增量发现报告总结的重点：
04_delta_report.json 至少应包含：
round：当前轮次new_findings：至少 3 条新增发现，每条都有唯一 IDcontradictions：本轮暴露的矛盾点或冲突点carry_forward_clues：传递到下一轮的线索 ID 列表coverage_assessment：当前回答原始问题的覆盖程度如果没有形成新增发现、矛盾点、可传递线索，而只是把已有内容换个说法重写，则该轮应视为无效轮次。
在写完 03_round_summary.md 和 04_delta_report.json 后，如果仓库中存在检查器，Agent 必须立即运行检查器读取结果：
PASS：才允许更新 00_meta.json 中的轮次状态，并进入下一轮，或在所有轮次都完成后进入独立的最终综合阶段FAIL：必须先修复失败项，再重新运行检查器；禁止跳过失败项继续研究deep_research_session 的 advance-round，因为它会把“校验当前轮 + 更新 meta + 必要时起下一轮”作为一个原子动作完成；如果任务报告只是空壳，advance-round 会直接拒绝通过如果用户指定了研究深度（如"深度 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失败处理流程是强约束，不是建议：
FAILPASS 才允许继续严禁以下行为：
如果用户明确指定了轮数，Agent 不得使用“已经足够全面”“结论已明确”“边际收益不大”等理由提前收尾。若某轮信息增益不足，应扩大视角或引入对抗性任务，而不是提前结束。
所有研究轮次都完成后，进入一个独立于各轮之外的最终综合阶段：综合全部研究信息，生成最终研究报告，保存到归档文件夹。
这一阶段不是“最后一轮的总结扩写版”。最后一轮和前面各轮一样，职责仍然是完成本轮探索与收敛；只有当最后一轮的 03_round_summary.md 和 04_delta_report.json 也通过检查后，才允许开始最终综合。
报告要回答用户的原始问题，给出明确的结论和建议。包含：
最终目标不是把研究越做越窄，而是在充分吸收多轮研究结果之后，形成一个既有广度、又有深度、并且足够干货的结论。收敛是为了提炼高价值判断，不是为了把研究面越收越小、最后只剩单一路径。
最终报告阶段的前置条件：
00_meta.json 中的 current_round 必须等于 target_depth00_meta.json 必须先进入“已完成所有轮次、等待最终综合”的状态，再开始撰写真实的 final_report.mdfinal_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
counterevidence 或 wildcard 任务，避免整轮任务都在重复验证同一假设OpenClaw 的子代理是 push-based 架构：spawn 后子代理在后台运行，完成后 completion event 会作为下一条消息推送给主 agent。为了减少丢消息和半成品归档，建议主 agent 正确等待：
sessions_yield{ "action": "sessions_yield", "message": "等待子代理完成" }
这会结束当前 turn，让 completion event 作为下一条消息到达。
建议在 spawn 后尽快 yield：spawn → sessions_yield 越紧密，越不容易出现主会话继续跑但子任务结果尚未到达的状态。
子代理完成事件到达后，主 agent 被唤醒，此时必须：
02_task_registry.json 中的 task_id 逐一验证 task report 文件被唤醒后仍有子代理在运行，建议再次 yield：如果某个子代理完成（成功或失败）唤醒了主 agent，但主 agent 检查发现同一批次中还有其他子代理未完成，则主 agent 在处理完已完成子代理的结果后，建议再次调用 sessions_yield 等待剩余 completion event 到达。
{ "action": "sessions_yield", "message": "等待剩余子代理完成" }
多批次执行：如果一轮 task 数量较多（>2 个），分批次 spawn（每批 2 个），每批都遵循 spawn → sessions_yield → 验证文件的流程。
避免：