[agent] Deep Research
Link: You Can Learn Deep Research AI Agent Design & Launch In 25 Min | Kimi K2 0905, LangChain, OpenSource
看看国内外博主对同一个主题的讲解有没有不同~
Background Knowledge
Deep Research 流程
很多次并行搜索，可以分配 multi agents 并行处理。
下面这个代表了multi agent模式。
Deep Research和Deep Search的区别在于，Deep Research模式之下，系统会在回答用户的问题的时候，会先构建一个系统的提纲，然后在回答每一级提纲的内容的时候，都走一遍Deep Search的流程。
如何实现？
需要涉及以下的技术。
| 工具名称 | 类型 | 主要功能 | 在 Deep Research 案例中的作用 |
|---|---|---|---|
write_todos |
规划工具 | 将复杂任务分解为结构化待办事项列表 | 研究任务分解、进度跟踪、防止注意力漂移 |
task |
委派工具 | 将子任务委派给子智能体执行 | 上下文隔离、专业化分工、并行处理 |
还是得先了解 Deep Agents。先转移到：
- [sdk] 01 - AI Agent Orchestration - DeepAgents
- [sdk] 02 - Deep Agents Middleware
- [sdk] 03 - Deep Agents - Memory and Filesystem
- [sdk] 04 - Deep Agents - Arch and SubAgent
有了一定基础，再继续本篇的主线~
知乎-深入浅出LangChain 智能体开发与B站的适合互补交叉学习。
如何定制化？为企业内部？类似的开源？大量资料mem的问题？
细节太多，先过一遍，如下。
From: 一文读懂：大模型 Deep Research 背后的技术原理
2025年，该产品 of 各家 集体上线的一年
MiroThinker-1.7 模型：开始发现“步步验证”的重要性
Planning 只是其中一部分。更重要的是把整个 长链 Research 行为训练得更稳定，包括：怎么拆任务、什么时候搜索、搜索后怎么根据新证据调整方向、什么时候继续搜、什么时候停止、怎么验证前面结论、怎么避免几十步以后跑偏。
有点RL的意思。但我直接调用GPT，预训练后训练的部分对我没有价值。：）
MiroThinker-1.7 Tools ├── 1. Information Retrieval │ ├── google_search │ │ ├── 功能：提交结构化查询，返回候选网页 │ │ ├── 示例输入： │ │ │ “苏轼 字号 出生地 生平 主要作品” │ │ └── 示例输出： │ │ ├── 百度百科：苏轼 │ │ ├── Wikipedia：苏轼 │ │ ├── 中国文学网：苏轼生平简介 │ │ └── 其他相关网页 │ │ │ └── scrape_and_extract_info │ ├── 功能：打开指定网页，并提取任务相关信息 │ ├── 示例输入： │ │ URL：苏轼百科页面 │ │ 提取：字号、出生地、仕途经历、主要作品 │ └── 示例输出： │ ├── 字号：字子瞻，号东坡居士 │ ├── 出生地：四川眉山 │ ├── 仕途经历：…… │ └── 主要作品：《赤壁赋》《念奴娇·赤壁怀古》…… │ ├── 2. Code Execution │ ├── create_sandbox │ │ ├── 功能：创建独立、安全的研究环境 │ │ └── 示例： │ │ 为“研究苏轼年谱和仕途变化”创建 sandbox_12345 │ │ │ ├── run_command │ │ ├── 功能：在沙箱中执行系统命令 │ │ └── 示例： │ │ ls /data/su_shi_chronology/ │ │ │ │ 输出： │ │ ├── 1037_birth.txt │ │ ├── 1080_huangzhou.txt │ │ └── ... │ │ │ └── run_python_code │ ├── 功能：在沙箱中执行 Python，做统计/分析/可视化 │ └── 示例： │ 统计苏轼一生不同类型事件出现次数 │ │ import pandas as pd │ print(df["事件类型"].value_counts()) │ │ 输出可能是： │ ├── 贬谪：4 │ ├── 任职：6 │ └── ... │ ├── 3. File and Data Transfer │ ├── upload_file_from_local_to_sandbox │ │ ├── 功能：把本地文件上传到沙箱 │ │ └── 示例： │ │ 本地《苏轼年谱.xlsx》 │ │ → sandbox_12345 │ │ │ ├── download_file_from_sandbox_to_local │ │ ├── 功能：把沙箱生成的文件下载到本地 │ │ └── 示例： │ │ sandbox_12345 中生成 │ │ 《苏轼生平时间线.png》 │ │ → 下载到本地 │ │ │ └── download_file_from_internet_to_sandbox │ ├── 功能：把互联网文件直接下载到沙箱 │ └── 示例： │ 从互联网下载《宋史·苏轼传.pdf》 │ → sandbox_12345 │ └── 4. 一次完整的苏轼研究流程 ├── 搜索：苏轼生平、字号、仕途、作品 ├── 抓取：从多个网页提取结构化事实 ├── 下载：把年谱/PDF放入沙箱 ├── 分析：用命令行和 Python 处理资料 ├── 生成：做时间线、统计结果或图表 └── 汇总：形成最终 Research Report
（1）Verifier
MiroThinker-1.7：重在“能连续研究”。
MiroThinker-H1：重在“能连续研究，而且每一步都尽量自检、自纠偏”。
Deep Agents 默认给你的是 planning、subagents、filesystem、summarization 这些通用能力；Verifier 这种“企业级可靠性策略”，通常需要你自己加。
（2）论文认为，模型在第 步做决策时，最重要的信息通常来自最近几轮（5） observation。较早的工具结果虽然可能有参考价值，但继续完整保留它们会带来很高的 token 成本。
（3）Effective Context：保留完整 thought 和 action，只压缩 observation。
深入理解最重要的（1）。
Confirmation Bias
主 Agent 首先生成 Todo：
2. 检查新 fraud rule 上线时间3. 比较投诉和 fraud rule 变化4. 调查客户投诉内容5. 给出结论然后执行。
第一步 SQL：
投诉数量：May 1,120June 1,180July 1,650August 1,730第二步查内部项目文档：
New Fraud Rule:上线日期：July 3第三步查 fraud metrics：
fraud rule 拒绝交易数量：June 18,000July 27,000August 29,000此时，一个强 LLM 非常容易产生这样的 reasoning：
Fraud rule 在 7 月上线；
投诉也从 7 月显著增加；
被拒绝交易数量同时显著增加；
因此新 Fraud Rule 很可能是投诉增加的主要原因。
然后它继续沿着这个方向调查。
这就是 MiroThinker-H1 那篇文章说的：
模型被自己当前最可能的 hypothesis 带着往前走。
而且越往后搜，它越容易找支持这个 hypothesis 的证据。
这其实就是一种 confirmation bias。
但时间上相关，不等于因果。
得到一个 hypothesis 时，Local Verifier 被调用。 看到如下：
Current hypothesis: New fraud rule caused the increase in complaints. Evidence: - Rule launched July 3 - Complaints rose in July - Fraud declines increased in July
[触发] 提出质疑：
VERDICT: NOT SUFFICIENT Reason: Evidence establishes temporal correlation, but does not establish causation. Missing evidence: 1. Complaint categories 2. Whether complaints relate to declined transactions 3. Complaint increase among customers unaffected by fraud rule 4. False-positive rate before vs after deployment
说不通，所以继续调查。
1. 检查投诉趋势 ✅ 2. 检查 Fraud Rule 上线 ✅ 3. 检查 fraud decline 数据 ✅ 4. 分析投诉 category ← 新增 ==> 开始看细节 5. 找出与 fraud decline 直接相关投诉 ← 新增 6. 比较 affected / unaffected 客户 ← 新增 7. 比较 false-positive rate ← 新增
又得到新的可疑点。
Complaint increase July vs June: Fraud decline complaints +14% Mobile app complaints +72% ==> 深入调查 Call centre wait complaints +51% Fee-related complaints +8%
深入看去。
大量投诉集中在： "transaction disappeared" "pending transaction incorrect" "card transaction history delayed"
[触发点] 结论开始变成：Mobile App v8.4 是投诉增加的主要原因。
Local Verifier 第二次介入。
VERDICT: PLAUSIBLE, BUT INCOMPLETE Supporting evidence: - Timing matches - Complaint categories match incident - Large affected population Missing: Need quantitative attribution.
于是 Main Agent 再查一次 SQL：
July新增投诉：550 其中： App-related 310 Call centre 120 Fraud-related 45 Other 75
现在证据就强很多了。
>>> 通用Local Verifier的设计示范 <<<
你是 Deep Research 系统中的 Local Verifier。 你的任务不是继续完成研究，而是检查当前研究步骤是否可靠。 请根据当前研究目标、已有证据、最新工具结果和当前假设，检查： 1. 当前结论是否真的被已有证据支持？ 2. 是否存在从证据无法推出的推断或过早结论？ 3. 是否存在明显的其他合理解释尚未排除？ 4. 当前使用的工具/数据是否适合回答这个问题？ 5. 是否存在关键证据缺失、来源冲突或数据质量问题？ 6. 当前下一步行动是否是最合理的信息获取方式？ 7. 如果继续当前路径，是否存在放大错误假设的风险？ 如果当前步骤可靠，返回 PASS。 如果不可靠，返回 REVISE，并指出： - 问题是什么 - 缺少什么证据 - 建议下一步采取什么行动 不要重新完成整个研究任务。 不要因为“可能存在其他解释”就无条件否决。 只有当问题足以影响当前研究方向或结论可靠性时才要求修正。
>>> 通用Gobal Verifier的设计心得 <<<
Main Agent 准备给最终结论：
“7月投诉增加主要由 Mobile App v8.4 incident 导致，而不是 Fraud Rule。”
这时候 Global Verifier 不再检查某一步。
它看到的是整个 Research package：
Research Plan + SQL results + Internal documents + Incident report + Fraud metrics + Complaint categories + Main Agent draft conclusion
它检查四件事，如下。可以看出，都与evidence有关！
1. 每个重大 claim 是否有 evidence？ 2. 有没有 evidence 被忽略？ 3. correlation 有没有被误写成 causation？ 4. 最终结论有没有超过证据能够支持的范围？
Global Verifier 的核心确实是：
站在整条 Research 轨迹之外，检查最终重要结论是否都有足够 Evidence 支撑。
你是 Deep Research 系统中的 Global Verifier（全局验证器）。 你的职责不是继续完成研究，也不是重新撰写报告。 你的职责是在最终答案输出之前，对完整的研究轨迹、已收集证据以及拟定结论进行整体审计。 请从以下几个维度进行验证： 1. **证据覆盖度** * 所有重要结论是否都有证据支持？ * 是否存在重要结论缺乏关键证据？ 2. **证据强度** * 当前证据是否真的能够支持对应结论？ * 证据强度是否足以支撑结论中表达的确定程度？ 3. **证据一致性** * 不同来源之间是否相互一致？ * 是否存在尚未解决的证据冲突或相互矛盾的信息？ 4. **替代解释** * 是否考虑了重要的其他可能解释或反证？ * 是否因为某一种解释“看起来合理”而过早接受该结论？ 5. **来源质量** * 支撑重要结论的来源是否可靠、相关，并且足够新？ * 多个来源是否真正独立，还是实际上引用了同一个原始来源？ 6. **结论校准** * 最终结论是否超出了当前证据能够证明的范围？ * 必须清楚区分：事实、相关性、推断、假设和因果结论。 最终返回以下三种结果之一： * `PASS` * 重要结论已有充分证据支持，整体证据链可靠。 * `RESEARCH_MORE` * 仍缺少重要证据，或者存在尚未解决的关键问题，需要继续研究。 * `REVISE_CONCLUSION` * 当前证据已经基本充分，但某些结论表述过强、与证据不一致，或需要降低确定程度。 对于每一个未通过验证的问题，请明确指出： * 受影响的结论； * 当前用于支持该结论的证据； * 具体存在的问题； * 还需要补充什么证据，或者应该如何修正结论。 不要因为“不可能达到绝对确定”就要求继续研究。 只有当缺失的信息可能实质性改变某个重要结论时，才要求继续研究。
Tongyi DeepResearch - ArenaRL
ArenaRL 的核心不是怎么做 Deep Research，而是怎么“比较两条 Research 轨迹谁更好”，从而得到更可靠的训练/评估信号。
不问“这份报告到底是 82 分还是 87 分”，而是问：A 和 B，哪一个更好？为什么？
ArenaRL 原论文主要就是为 RL 训练解决 reward 问题；你不训练模型的话，不需要照搬。
但它的 pairwise evaluation 思想 可能 适合 做 DeepAgent 系统的离线评估。
Step-DeepResearch
Step-DeepResearch 最有特色的地方，是把“做好一次 Deep Research”拆成几种明确的原子能力（Atomic Capabilities），然后围绕这些能力分别训练、验证和评估。
真正值得拿走的只有一个增量：把“Verifier”从通用 Rubric，进一步变成针对当前任务动态生成的 Checklist。也即是：步步提醒是否满足用户目标。
Case Study
Research Brief ↓ Supervisor LLM │ ├─ ① 生成 Think Tool Call │ # 真正的 planning/reflection 内容是 Supervisor LLM 生成的 │ # 例如：需要分别调查“内部数据”“政策变化”“外部监管” │ ↓ supervisor_tools │ ├─ 执行 think_tool │ # Tool 本身不规划，只把 reflection 变成 ToolMessage │ # "Reflection recorded: ..." │ ↓ ToolMessage 返回 Supervisor LLM │ # Supervisor 下一次 LLM 调用可以看到刚才的 reflection │ ↓ Supervisor LLM │ ├─ ② 生成 ConductResearch Tool Call A │ # 注意：Task A 是 Supervisor LLM 生成的！ │ # 它写进参数： │ # research_topic="调查内部审批时间变化及瓶颈..." │ ├─ ② 生成 ConductResearch Tool Call B │ # research_topic="调查内部政策和流程变化..." │ └─ ② 生成 ConductResearch Tool Call C # research_topic="调查外部监管变化..." ↓ supervisor_tools │ # 这里才真正“执行” ConductResearch │ ├─ researcher_subgraph.ainvoke(Task A) │ # 启动 Researcher 运行实例 A │ ├─ researcher_subgraph.ainvoke(Task B) │ # 启动 Researcher 运行实例 B │ └─ researcher_subgraph.ainvoke(Task C) # 启动 Researcher 运行实例 C # A/B/C 可以 asyncio.gather 并行运行 ↓ Researcher A/B/C 各自研究 ↓ Compressed Research Results ↓ 转换成 ConductResearch 的 ToolMessage ↓ 返回 Supervisor LLM ↓ Supervisor 再调用 Think Tool # 看：已经得到什么？还缺什么？是否继续派任务？ ↓ 还缺？ ├─ Yes → Supervisor 再生成新的 ConductResearch Tool Call │ └─ No → Supervisor 生成 ResearchComplete Tool Call
Research Brief ↓ Supervisor LLM # 读取结构化 Research Brief，负责全局调度 │ ├─ ① 生成 Think Tool Call │ # Planning / Reflection 内容由 Supervisor LLM 自己产生 │ ↓ supervisor_tools # 执行 think_tool，把 reflection 转成 ToolMessage ↓ ToolMessage → Supervisor LLM # Supervisor 看到刚才的规划，再决定下一步动作 ↓ Supervisor LLM │ ├─ ConductResearch Tool Call A │ # Task A 是 Supervisor LLM 产生的 │ # research_topic="调查内部审批时间变化" │ ├─ ConductResearch Tool Call B │ # research_topic="调查政策变化" │ └─ ConductResearch Tool Call C # research_topic="调查外部监管变化" ↓ supervisor_tools # 执行 ConductResearch tool calls ├─ researcher_subgraph.ainvoke(Task A) ├─ researcher_subgraph.ainvoke(Task B) └─ researcher_subgraph.ainvoke(Task C) # 多个 Researcher instance 可并行执行 ================================================== Researcher Instance ↓ Researcher LLM # 根据自己的 research_topic 决定下一步 ↓ Search / MCP / Code / Think Tool Call # Researcher 调具体工具 ↓ Tool Result / ToolMessage # 得到新的 Evidence ↓ Local Verifier ## 检查这一步： ## - 当前证据是否支持刚才的判断？ ## - 是否过早形成 hypothesis？ ## - 是否遗漏明显替代解释？ ## - 下一步行动是否合理？ ## - 是否需要补充 Evidence？ ↓ Local Verification Result ├─ REVISE │ ## 把 verifier critique 送回 Researcher LLM │ ↓ │ Researcher LLM │ ## 根据 critique 改方向 / 换工具 / 补搜索 │ ↓ │ Search / MCP / Code ... │ ↓ │ Local Verifier │ ## 继续局部检查 │ └─ PASS ↓ Researcher LLM # 判断自己的子任务是否已经完成 ├─ No → 继续 Research Loop │ └─ Yes ↓ ResearchComplete # 当前 Researcher 发出“子任务完成”信号 ↓ Compress Research # LangGraph Node 压缩当前 Researcher 的 findings ================================================== Compressed Findings A/B/C ↓ 返回 Supervisor LLM # Supervisor 获得多个 Researcher 的研究结果 ↓ Supervisor → Think Tool # 再次判断： # 已经知道什么？ # Research Brief 哪些部分还没有覆盖？ # 是否需要继续派 Researcher？ ↓ Supervisor LLM ├─ 明显还缺东西 │ ↓ │ 新的 ConductResearch Tool Call │ # 再产生 Task D / E ... │ └─ Supervisor 认为已经足够 ↓ Global Verifier ## 对整个 Research 进行 Evidence Audit： ## - Research Brief 的关键要求是否全部覆盖？ ## - Major Claim 是否都有 Evidence？ ## - Evidence 是否真的支持 Claim？ ## - 是否存在关键冲突没有解决？ ## - 是否存在重要替代解释没有调查？ ## - 结论是否说过头？ ↓ Global Verification Result ├─ RESEARCH_MORE │ ## 告诉 Supervisor 缺什么证据 │ ↓ │ Supervisor LLM │ ↓ │ Think → ConductResearch │ ## 回到 Research Loop 补证据 │ ├─ REVISE_CONCLUSION │ ## 证据基本够，但某些结论需要降低强度或修正 │ ↓ │ Supervisor 更新最终 findings │ └─ PASS ↓ Supervisor ResearchComplete # 整个 Research Phase 正式结束 ↓ Final Report LLM # 根据通过验证的 findings 生成最终报告
之后便是代码实践。
目前这个复杂度，已足够。
再考虑RAG，基本上够企业 PoC。
浙公网安备 33010602011771号