6个 Deep Research Agent 架构拆解！这样设计才不翻车

6个 Deep Research Agent 架构拆解！这样设计才不翻车 6个 Deep Research Agent 架构拆解！这样设计才不翻车 Modified January 9 协作机制 状态机边（顺序执行） • 固定流程：Planner → Researcher → Analyst → Coder → Reporter • 通过共享状态（State）传递信息 • 无并行：每个节点完成后才进入下一个 状态管理 Checkpoint（自动持久化） • 每个节点执行完自动保存到 MongoDB • 崩溃后可以从最近的 Checkpoint 恢复 • 优势：长流程的容错能力 上下文管理 pre model hook（机械压缩） • 每次调用 LLM 前自动触发 • 首尾保留、中间删除（固定规则） • 问题：可能丢失重要中间信息 执行流程 固定五步 1. Planner ：生成研究计划（结构固定） 2. Researcher ：按计划搜索 + RAG 检索 3. Analyst ：分析数据，生成洞察 4. Coder ：生成代码示例（如需要） 5. Reporter ：多格式输出（报告/PPT/播客） 工具配置 Pipeline 专属 • 每个节点有专属工具集 • Researcher : web search + local search tool（RAG） • Reporter : format converter（多格式） 压缩方式对比 DeerFlow vs V3 • DeerFlow（pre model hook） ：每次调用 LLM 前自动触发，机械删除（首尾保留、中间丢弃）→ 可能丢失信息 • V3（compress research） ：研究员完成后主动调用，LLM 语义压缩 → 保留关键信息 • 生活类比 ：DeerFlow 像“会议记录太长，删掉中间几页”；V3 像“让秘书写一份精炼摘要” 适用场景 • 固定流程、可预测成本：企业内部标准化报告 • 需要断点续传：长时间运行的任务 • 多格式输出：一次生成多种交付物 • 开放式探索：计划固定后无法根据发现调整方向 核心权衡 • DeerFlow 优先 可控性 （固定流程、Checkpoint、成本可预测） • V3/Anthropic 优先 探索性 （动态定结构、并行执行、质量优先） 四、设计哲学：为什么这样设计才对？ 4.1 为什么“先搜索后定结构”是对的？ 研究的本质是探索性的 。 Anthropic 技术博客： “研究工作涉及开放式问题，很难提前预测所需步骤。你无法为探索复杂主题编写固定路径，因为过程本质上是 动态的、路径依赖的 。" 核心洞察 ：报告结构应该是搜索发现的自然呈现，而非预设框架。V1/V2 先定义章节（如“技术背景”、“应用案例”），但搜索可能发现更重要的角度——此时结构已固定，无法调整。 V2 的额外问题 ：分工写作导致章节间不连贯 • Worker 各自独立写作，互不知晓其他章节内容 • Worker 1 写完“技术背景”，Worker 2 写“应用案例”时不知道 Worker 1 写了什么 • 结果：章节衔接可能生硬、内容可能重复或跳跃、叙事逻辑断裂 • Supervisor 拼接这些独立章节 + 写引言/结论 V3 的解决 ： • 不分配章节写作，而是收集“研究发现”（压缩摘要） • Supervisor 基于所有研究发现，统一生成整个报告 • 报告是一气呵成的整体，叙事连贯 实践验证 ：V3、DeepAgents、Anthropic 三个独立团队都选择了“先搜索后定结构”，这不是巧合。 4.2 为什么采用 Subagent as Tool？ 三个独立团队的收敛 ： • LangChain V3： ConductResearch 工具 • LangChain DeepAgents: task 工具 • Anthropic: run subagent 工具 为什么收敛？ 研究任务的特点是：每个子任务相对独立，结果可以压缩后汇总，Subagent as Tool 正好适合： 协作机制 状态机边（顺序执行） • 固定流程：Planner → Researcher → Analyst → Coder → Reporter • 通过共享状态（State）传递信息 • 无并行：每个节点完成后才进入下一个 状态管理 Checkpoint（自动持久化） • 每个节点执行完自动保存到 MongoDB • 崩溃后可以从最近的 Checkpoint 恢复 • 优势：长流程的容错能力 上下文管理 pre model hook（机械压缩） • 每次调用 LLM 前自动触发 • 首尾保留、中间删除（固定规则） • 问题：可能丢失重要中间信息 执行流程 固定五步 1. Planner ：生成研究计划（结构固定） 2. Researcher ：按计划搜索 + RAG 检索 3. Analyst ：分析数据，生成洞察 4. Coder ：生成代码示例（如需要） 5. Reporter ：多格式输出（报告/PPT/播客） 工具配置 Pipeline 专属 • 每个节点有专属工具集 • Researcher : web search + local search tool（RAG） • Reporter : format converter（多格式） 压缩方式对比 DeerFlow vs V3 • DeerFlow（pre model hook） ：每次调用 LLM 前自动触发，机械删除（首尾保留、中间丢弃）→ 可能丢失信息 • V3（compress research） ：研究员完成后主动调用，LLM 语义压缩 → 保留关键信息 • 生活类比 ：DeerFlow 像“会议记录太长，删掉中间几页”；V3 像“让秘书写一份精炼摘要” 适用场景 • 固定流程、可预测成本：企业内部标准化报告 • 需要断点续传：长时间运行的任务 • 多格式输出：一次生成多种交付物 • 开放式探索：计划固定后无法根据发现调整方向 核心权衡 • DeerFlow 优先 可控性 （固定流程、Checkpoint、成本可预测） • V3/Anthropic 优先 探索性 （动态定结构、并行执行、质量优先） 四、设计哲学：为什么这样设计才对？ 4.1 为什么“先搜索后定结构”是对的？ 研究的本质是探索性的 。 Anthropic 技术博客： “研究工作涉及开放式问题，很难提前预测所需步骤。你无法为探索复杂主题编写固定路径，因为过程本质上是 动态的、路径依赖的 。" 核心洞察 ：报告结构应该是搜索发现的自然呈现，而非预设框架。V1/V2 先定义章节（如“技术背景”、“应用案例”），但搜索可能发现更重要的角度——此时结构已固定，无法调整。 V2 的额外问题 ：分工写作导致章节间不连贯 • Worker 各自独立写作，互不知晓其他章节内容 • Worker 1 写完“技术背景”，Worker 2 写“应用案例”时不知道 Worker 1 写了什么 • 结果：章节衔接可能生硬、内容可能重复或跳跃、叙事逻辑断裂 • Supervisor 拼接这些独立章节 + 写引言/结论 V3 的解决 ： • 不分配章节写作，而是收集“研究发现”（压缩摘要） • Supervisor 基于所有研究发现，统一生成整个报告 • 报告是一气呵成的整体，叙事连贯 实践验证 ：V3、DeepAgents、Anthropic 三个独立团队都选择了“先搜索后定结构”，这不是巧合。 4.2 为什么采用 Subagent as Tool？ 三个独立团队的收敛 ： • LangChain V3： ConductResearch 工具 • LangChain DeepAgents: task 工具 • Anthropic: run subagent 工具 为什么收敛？ 研究任务的特点是：每个子任务相对独立，结果可以压缩后汇总，Subagent as Tool 正好适合： 1. 隐藏细节 ：子 Agent 的搜索过程和中间思考不会污染主 Agent 的上下文 2. 可压缩 ：通过工具返回值控制信息量 3. 稳定 ：工具调用是 LLM 原生支持的机制 五、核心对比 5.1 上下文工程对比 维度说明 • 上下文卸载 ：把信息写到外部存储，释放 Agent 工作记忆 • 上下文减少 ：压缩信息量 • 上下文隔离 ：多 Agent 各自独立上下文，避免互相污染 • 上下文检索 ：按需从外部存储取回 各架构实现对比 • V1 ：四项全无 → Token 快速爆炸 • V2 ：隔离（Send API）→ Supervisor 仍爆炸 • V3 ：压缩（LLM）+ 隔离（Subagent）→ 核心突破 • DeepAgents ：四项全覆盖（卸载/压缩/隔离/检索）→ 框架化 • Anthropic ：四项全覆盖 + Memory 按需检索 → 产品级 • DeerFlow ：Checkpoint 卸载 + 机械删除 + RAG 检索 → 顺序执行 5.2 多 Agent 架构的本质差异 V2、V3、Anthropic、DeepAgents 都是“主管 + 研究员”架构，但 信息如何流转和整合 完全不同： • V2 ：静态分发（ Send ）+ 无压缩 + 无反思 → 信息爆炸 • V3 ：动态分发（ ConductResearch ）+ 显式压缩 + think tool → 质速兼得 • Anthropic ：动态分发（ run subagent ）+ 压缩 + Memory 持久化 + CitationAgent → 信息完整性 • DeepAgents ：框架工具（ task ）+ 提示词压缩 + 文件系统 → 框架化 5.3 状态管理 核心问题 新信息来了，怎么更新状态？ 实现方式 • V1/V2 ：追加模式 + 直接更新 → 消息只能追加，Token 爆炸 • V3 ：override reducer（灵活模式）→ 初始化覆盖、运行时追加 • DeepAgents ：Command 模式（框架层控制）→ Agent 返回指令，框架执行 • Anthropic ：Memory 工具 → 显式保存/读取，按需检索 • DeerFlow ：Checkpoint（自动持久化）→ 每步保存，断点续传 写在最后 本文是基于开源代码和技术文档的分析 ，可能存在理解偏差或不准确之处。如果你发现任何错误，或有不同见解，非常欢迎在评论区指正和讨论。技术的进步离不开开放的交流。 这篇文章分析了 6 个架构，但我最大的收获不是“哪个最好”，而是理解了 架构设计背后的权衡逻辑 ： • 上下文爆炸 → 压缩、隔离、卸载、检索 • 内容不连贯 → 先搜索后定结构 • 多 Agent 通信 → Subagent as Tool • 质量控制 → 反思机制 关注我 ，持续分享产品经理视角的 AI 产品、技术分析与实用工具推荐。 关于我： 我正在寻找 AI 产品经理的工作机会。如果你的团队在做 Agent，或者知道相关机会，欢迎私信交流 参考资源 1. Open Deep Research ◦ GitHub: https://github.com/langchain ai/open deep research ◦ GitHub: https://github.com/langchain ai/open deep research 2. DeepAgents ◦ GitHub: https://github.com/langchain ai/deepagents ◦ GitHub: https://github.com/langchain ai/deepagents 3. Anthropic Research System ◦ blog: https://www.anthropic.com/engineering/multi agent research system ◦ Cookbook: https://github.com/anthropics/claude cookbooks/tree/main/patterns/agents/prompts ◦ blog: https://www.anthropic.com/engineering/multi agent research system ◦ Cookbook: https://github.com/anthropics/claude cookbooks/tree/main/patterns/agents/prompts 4. DeerFlow ◦ GitHub: https://github.com/bytedance/deer flow ◦ GitHub: https://github.com/bytedance/deer flow 🔗 Source link: https://mp.weixin.qq.com/s/2rE4QZE3... https://mp.weixin.qq.com/s/2rE4QZE3... Original Suda探险家 苏打气泡档案 2026年1月8日 22:07 广东 2025 年，开源框架撕开了 Deep Research 神秘面纱的一角。从 LangChain 的 Open Deep Research 三个版本演进，到 Anthropic 的架构探索，再到 DeepAgents 框架化——不到半年时间，这个领域从“能跑通”走向了“最佳实践”。 为什么值得研究？ 这是少有的“设计选择对比清晰”的 Agent 场景。你能看到：开放式探索场景为什么应该先搜索后定结构，上下文压缩为什么是核心，多 Agent 协作的不同方案。这些设计选择背后的权衡逻辑，适用于你正在做的任何 Agent 系统。 讨论范围 ：本文分析的是 开源 Deep Research Agent 架构。部分闭源产品（如 ChatGPT Deep Research、Kimi Reseacher）采用单体 Agent + 微调模型方案，设计思路不同，不在本文讨论范围。 一、1 分钟速览 早期版本（V1/V2） ：先定结构后搜索、无压缩、无反思 成熟方案（V3/Anthropic/DeepAgents） ： • 先搜索后定结构（动态生成） • 并行执行 • Subagent as Tool（上下文隔离） • LLM 压缩 + 反思机制 另一条路（DeerFlow） ：先定结构、顺序执行、Checkpoint 断点续传 二、分析框架：三大核心维度 2.1 上下文工程 ：Token 爆炸怎么办？ • Deep Research 搜索 10 个网页就是 50k tokens，加上对话历史轻松突破 200k • 四种应对：卸载（外部存储）、减少（压缩）、隔离（多 Agent 独立）、检索（按需取回） 2.2 Multi agent 协作 ：主 Agent 怎么委派任务？ • 单 Agent“既要当老板，又要干活，还要记住所有细节” → 上下文混乱 • 核心差异：Send API（静态分发）、Subagent as Tool（工具调用）、状态机边（固定流程） 2.3 反思机制 ：怎么保证质量？ • Agent 容易“搜一个结果就直接写报告” → 质量差 • 反思层次：基础 ReAct、显式 think tool、专职 CitationAgent 三、演进轨迹 说明 : V1/V2/V3 指 Open Deep Research（LangChain 开源项目）的三个版本。 3.1 起点：V1 的极简主义（2025.4） 生活类比 ：一个人写论文——先列大纲，然后同时启动多个任务（并行查资料），但所有内容都在一个笔记本里（共享状态）。 状态管理 追加模式，所有消息线性累积 • 用户输入 → 大纲 → 章节 1 内容 → 章节 2 内容 → …… → 最终报告 • 问题：第 10 个章节的上下文包含前 9 个章节的所有内容 执行流程 1. generate plan ：生成报告大纲（3 5 个章节） 2. build sections ：使用 Send() API 并行执行多个子图，每个子图处理一个章节 3. compile report ：汇总所有章节成最终报告 工具配置 单 Agent + 并行子图 • 主流程拥有所有工具：web search、报告生成 • 没有独立的 Agent，只是并行执行子图 核心问题 • 先定结构后搜索 ：没调研就定结构，本末倒置 • 共享状态 ：所有章节共享同一个状态，没有上下文隔离 • 无压缩 ：上下文线性累积 → Token 爆炸 • 无反思 ：结构生成后就固定执行，无法调整 价值 最简单的并行实现，适合学习 Agent 基础概念：ReAct 循环、状态机、工具调用、Send API。 3.2 第一次突破：V2 引入多 Agent 架构（2025.5） 生活类比 ：项目经理带团队——PM（Supervisor）分配任务，每个团队成员（Worker）有自己的工作记录本（独立上下文），并行工作，PM 汇总。 协作机制 Send API（LangGraph 并行调度） • Supervisor 通过 send 函数派发任务给多个 Worker • Worker 各自独立执行，返回 Section 对象（包含完整章节内容） • Supervisor 收集所有返回的章节内容 状态管理 仍是追加模式 • Supervisor 的上下文 = 自己的消息 + 所有章节的完整内容 • 问题：3 个 Worker 各返回完整章节（假设各 2000 tokens）→ Supervisor 接收 6000 tokens 执行流程 分工但仍先定结构 1. supervisor ：生成大纲，分配章节给 Worker 2. workers 并行 ：每个 Worker 负责 1 2 个章节 3. supervisor ：收集结果，生成最终报告 工具配置 • Supervisor ： ◦ Sections（定义章节列表） ◦ Introduction/Conclusion（写作引言结论） ◦ web search（可选，prompt 要求先搜索了解主题，再定义章节） ◦ Sections（定义章节列表） ◦ Introduction/Conclusion（写作引言结论） ◦ web search（可选，prompt 要求先搜索了解主题，再定义章节） • Worker ： ◦ Section（完成章节写作，返回完整章节内容） ◦ web search（可选，深度研究章节内容） ◦ FinishResearch（标记完成） ◦ Section（完成章节写作，返回完整章节内容） ◦ web search（可选，深度研究章节内容） ◦ FinishResearch（标记完成） 突破 • 多 Agent 架构： Supervisor Worker 分层，每个 Worker 是独立 Agent（MessagesState） • 上下文隔离：Worker 各有独立对话历史，互不干扰 • 并行执行：速度提升 3 5 倍（相比 V1 没有本质提升，因为 V1 也是并行的） 遗留问题 • Send API 不稳定：Worker 失败时，整个流程难以恢复 • 无压缩：Worker 返回完整的章节内容，无压缩机制 → Supervisor 上下文爆炸 • 仍是先定结构后搜索：Supervisor 先调用 Sections 定义完整章节列表，Worker 按固定结构研究 • 分工写作导致章节间不连贯：Worker 各自独立写作成型章节，互不知晓，章节衔接可能生硬或重复 价值 首次引入真正的多 Agent 架构（独立 Agent + 独立上下文），Send API 的局限性为 V3 的 Subagent as Tool 提供了动机。 3.3 关键突破：V3 的三大创新（2025.7） 生活类比 ：研究主管带专业团队——主管定主题后持续反思，研究员独立调查后写精炼摘要交给主管，主管根据摘要动态决定下一步行动。 创新 1: Subagent as Tool（稳定性突破） 问题 V2 的 Send API 不稳定。 解决 把子 Agent 包装成工具调用。 Send API (V2) 的问题 • Worker 失败难恢复 • 返回 Section 对象，包含完整章节内容（ Section.content ），无法压缩 • 需要手动管理上下文 Subagent as Tool (V3) 的优势 • 工具调用是 LLM 原生机制，稳定 • 只返回工具返回值（ compressed research ），可压缩 • 天然隔离，失败 = 返回错误信息 关键区别 • V2 ：Worker 返回完整章节 → Supervisor 直接接收 • V3 : Researcher → compress research 节点（LLM 语义压缩）→ Supervisor 接收压缩摘要 创新 2：先搜索后定结构 问题 V1/V2 先定报告结构（章节划分），然后按固定结构去搜索。搜索结果可能发现更重要的主题，但大纲已固定。 解决 Research Brief 只是主题描述，最终报告结构由搜索结果自然呈现。 V1/V2 的错误流程 预先定义章节结构 → 按固定结构搜索 → 按预设结构写报告 V3 的正确流程 Research Brief（ 研究简报，不含章节结构 ）→ 动态搜索 + 反思 → 基于搜索发现生成结构 生活类比 • V1/V2 ：出门前列好购物清单“苹果、香蕉、橙子”，到超市发现芒果更新鲜、猕猴桃特价，但清单已定，无法修改 • V3 ：制定目标“买水果”，到超市根据实际情况（新鲜度、价格、品种）决定买什么，灵活调整 创新 3：LLM 语义压缩 工作流程 1. Researcher 完成搜索和思考 2. 自动进入 compress research 节点 3. 用 LLM 读取所有研究消息，生成精炼摘要 4. 返回 compressed research （压缩摘要）给 Supervisor 压缩实现 • 模型 ：使用专门的 compression model （可独立配置） • 提示词 ：切换到“压缩模式”，要求整理已有研究结果 • 输出 ：结构化摘要（ compressed research ）+ 原始笔记（ raw notes ，用于最终报告） 整合生成最终报告 • Supervisor 收集所有压缩摘要和原始笔记 • 用 final report model 生成最终报告（这是整合，不是再次压缩） 对比 DeerFlow 的机械删除 • V3 ：让秘书读完所有会议记录，写一份精炼摘要（语义理解） • DeerFlow ：会议记录太长了，机械地删掉中间几页（首尾保留） V3 设计细节总结 状态管理 override reducer（灵活模式） • 使用自定义 reducer 函数，根据数据结构决定是追加还是覆盖 • 初始化时覆盖，运行时追加 • 生活类比 ：像笔记本的两种写法——“翻到新页重新写”（覆盖）vs“接着往下写”（追加） 执行流程 动态循环 1. brief ：创建研究简报（只定义主题，不定义结构） 2. supervisor ：反思 → 决定调查方向 → 调用 ConductResearch 3. researcher ：并行搜索 → compress research 节点（LLM 压缩）→ 返回压缩摘要 4. supervisor ：评估 → 够了？→ 不够回到步骤 2，够了进入步骤 5 5. final report ：基于搜索结果自然生成报告结构 工具配置 严格职责分离 • Supervisor : think tool（反思）、ConductResearch（委派）、ResearchComplete（完成） • Researcher : web search（搜索）、ResearchComplete（完成） • 压缩 ： compress research 节点（非工具，自动触发） 核心价值 • 解决了 V2 的所有问题 • 建立了“先搜索后定结构”的正确范式 • 证明了 Subagent as Tool 的可行性 3.4 并行突破：Anthropic 的架构探索（2025.6） 生活类比 ：博士生导师带研究团队——导师有个随身笔记本（Memory）记录研究计划，派多个学生并行调研不同方向，学生交回精炼摘要而非原始资料，最后还有专门的助理（CitationAgent）帮忙核对引用格式。 背景 ：2025 年 6 月，Anthropic 发布了 Claude Research 技术博客，详细阐述了他们的多代理研究系统设计。这是与 V3（2025.7）并行开发的独立实现，两者高度一致证明了设计的收敛性。 协作机制 run subagent 工具 • 同步调用：主 Agent 等待 Subagent 完成再继续 • 返回压缩结果（非完整对话） • 与 V3 的 ConductResearch 工具概念一致 状态管理 Memory 工具（持久化创新） • Memory.save(key, value) ：保存研究计划、中间发现 • Memory.load(key) ：按需检索 • 优势：上下文超过 200k token 仍不丢失关键信息 执行流程 动态循环 + 质量控制 1. LeadResearcher ：反思策略 → Memory.save 保存计划 2. 并行派发多个 Subagent 调查不同方向 3. 综合判断：够了？→ 不够继续，够了进入引用核对 4. CitationAgent ：专门核对引用准确性（质量保障） 工具配置 三层架构 • Lead Agent : search tools、MCP tools、memory、run subagent、complete task • Search Subagent ：搜索工具（专注搜索） • Citations Subagent ：引用核对 核心数据验证 • 多代理比单代理性能提升 90.2% • Token 使用量解释 80% 的性能差异 • 多 Agent 使用 15× tokens，但产出质量大幅提升 与 V3 的对比 • 共同点 ：Subagent as Tool、动态规划、压缩、并行执行 • Anthropic 的扩展 ：Memory 持久化、CitationAgent 质量控制 3.5 框架化：DeepAgents（2025.10） 生活类比 ：乐高积木工厂——框架提供标准化的基础积木块（任务管理、文件系统、子代理调度），你只需要添加几块定制积木（搜索工具、反思工具），就能搭出完整的研究系统。80% 的积木是现成的，你只做 20%。 背景 ：DeepAgents 的架构设计主要参考了 Claude Code 和 Manus 的架构思想，LangChain 团队将这些成功产品的共同模式（planning tool、subagents、file system、detailed prompt）抽象成框架，使其通用化。 定位 ：把 V3 的设计封装成框架，开发者只需定制 20%。 • 框架层 （DeepAgents 提供）：task 工具、文件系统、任务管理、上下文摘要 • 业务层 （你需要做）：添加 tavily search + think tool + 提示词 框架中间件栈 （像洋葱，每层增加能力）： • Layer 6: 工具调用修复 • Layer 5: 提示词缓存 • Layer 4: 上下文摘要 • Layer 3: 子代理调度 • Layer 2: 文件系统 • Layer 1: 任务管理 协作机制 task 工具（框架级封装） • 框架自动处理子 Agent 创建、调度、结果收集 • 开发者只需提供工具定义和提示词 状态管理 Command 模式（更新方式）+ 框架层灵活控制（更新策略） • Agent 返回 Command(goto="...", update={...}) ，框架负责执行 • 框架层可选择追加或覆盖，Agent 无需关心细节 • 优势 ：职责分离，Agent 只负责决策，框架负责执行 上下文工程 四项全覆盖 • 卸载 ： write file 把长文本写入文件系统 • 减少 ：Layer 4 自动摘要（中间件） • 隔离 ：Layer 3 子代理调度 • 检索 ： read file 按需取回 持久化 可插拔后端 • FilesystemBackend ：本地文件 • StoreBackend ：数据库 • CompositeBackend ：混合模式 工具配置 框架/业务分层 • 框架层