1. Deep Research 到底改变了什么先搞清楚它为什么是分水岭2025年AI圈最热的一个词是 Deep Research。但说实话很多人把它当成一个能自动写报告的新功能来用这格局就小了。我自己在落地 DeeperFlow 2.0 的过程中越做越清楚一个判断Deep Research 真正的价值不在于帮你省掉几小时的信息搜集时间而在于它给Agent 工程化这件事定了一套可量化的标准。简单说Deep Research 把AI 能干正经活从 demo 变成了流水线。普通对话、普通检索增强生成本质上是你问一句它答一段上下文里的信息拼凑感很强结果对不对、依据足不足用户很难验证。而 Deep Research 范式要求 Agent 必须经历问题拆解 — 多路检索 — 证据抽取 — 交叉验证 — 综合成文五个阶段产出物必须带引用、带推理链路、带明确的置信度说明。这一套东西用户才真的敢拿它去决策。我举个实际例子。以前我让人工智能帮我调研一个开源项目的选型普通模式给的结果是这个项目支持X、Y、Z功能star数很高听起来没什么问题但一旦细问这些功能在什么场景下被验证过跟竞品对比的原始数据从哪里来它就说不清了。用 Deep Research 工作流跑一遍输出会变成结论 / 支持依据 / 证据来源 / 证据之间的冲突点 / 还有哪些信息无法确认。这一字之差决定了它是参考还是可用的交付物。DeerFlow 2.0 的标题里把 Deep Research 放在前面、Super Agent Harness 放在后面这个顺序很有意思。我的理解是Deep Research 不是终点它是 Super Agent Harness 的地基能力。也就是说2.0 要解决的已经不单是怎么把一份研究做好而是怎么把若干个研究型、执行型、工具调用型的子智能体编排进一个可治理的统一框架让它们像一支队伍一样工作。这一步迈出去Agent 才从单兵作战走向协同作战。为了让后面讲的架构不悬空我先给一个简单的心智模型。你可以把 Deep Research 想象成一个能力点Super Agent Harness 想象成组织能力的方法论。点得先存在方法论才有编排的对象方法论成熟之后点的能力又能反过来增强——因为 Agent 之间的任务传递本身就是一种研究过程。DeerFlow 2.0 想做的就是把这两层叠起来给出一套工程上能落地、运维上是可控的实现。2. Deep Research 工作流中的核心模块拆解2.1 从提问到任务树的解析逻辑Deep Research 的第一步不是搜索是把大问题切成小任务。这一步做不好后面全乱。DeerFlow 2.0 的规划模块核心思路是把用户输入的一条开放式问题转化为一棵可并行的任务树。我在本地跑通这套流程后的体会是任务拆解的成功率跟提示词的约束方式强相关。你如果只给大模型一句帮我调研一下RAG方案的选型它拆出来的子任务往往是什么是RAGRAG的优缺点主流方案对比这种教科书式的层级泛泛、不可操作。但如果给了明确的输出约束、时间预算和执行主体描述拆解结果会完全不一样。DeerFlow 2.0 的规划模块在这种场景下会接收这样一组提示词层面的参数目标角色调研对象是谁、决策者关注什么指标输出形式结论优先还是过程优先需要表格还是需要时间线检索预算最多允许多少次并行调用、多少次串行深度检索证据要求引用来源级别、时间窗口偏好、信源权重设定。这些参数其实就是 Deep Research 里面所谓的深度是一个没有写进论文、但在工程里起决定性作用的细节。任务树生成之后接下来就是分配到不同的检索执行器。DeerFlow 2.0 在这一层的设计有两个显著特点。第一检索执行器不是一套搜索引擎打天下而是按任务类型划分网页检索、学术检索、代码库检索、垂直社区检索各走各的通道每个通道有自己的重排规则。第二子任务之间存在信息依赖关系时框架不会盲目并行而是识别出前序子任务完成才能开始后序子任务的阻塞节点压入一个状态图里管理。2.2 证据链聚合与冲突消解Deep Research 只把信息检索回来不算完真正的重活在于判断哪些信息可信、哪些信息互相矛盾、哪些信息时效性已经失效。DeerFlow 2.0 在这块引入了一个我认为非常有价值的模块——证据链聚合器。我的理解是它做的是这么一件事把每个检索结果当作一条证词每条证词携带来源、时间、上下文、信源类型、与任务树节点的关联度这几个维度的标签然后用打分排序的方式做加权融合。如果两条信息指向同一个结论但来源一个是技术博客、一个是一线团队的开源仓库 README它会给后者更高的证据权重如果两篇资料结论相反它不会硬揉而是把冲突点连同双方论据一起保留在中间态留给后续的推理模块做裁决。实际跑下来这个机制对最终报告质量的提升是肉眼可见的。过去用蛮力检索拼接的内容经常出现前后矛盾而不自知的情况因为普通管道上信息是流式的没有回溯校验。而证据链聚合相当于给每一个结论都留了一份卷宗矛盾暴露的前置时间大大提前。2.3 从证据到报告的合成输出最后一步是报告合成也是用户感知最强烈的一环。DeerFlow 2.0 的合成模块不是简单的把检索结果做个摘要而是按证据链层级来组织内容结构先写结论再给论据再列证据来源最后标注未决问题。这种结构有一个现实的好处——决策者可以直接跳到最后一部分看风险和盲区而不是通篇读完还要自己去判断哪里不可靠。我用这套框架做的第一个实际任务是一个开源向量数据库的选型调研。过去类似的事情我要花大半天Google 搜索、翻文档、看 issue、微信群问一圈、再自己做个对比表。DeerFlow 2.0 跑下来的报告把五个候选库在性能、生态、许可证、维护活跃度这些维度上的差异列得清清楚楚最意外的是它把某一个库的许可证变更历史这种我人工调研经常漏掉的信息主动标了出来。那一刻我很确定Deep Research 这一层我已经不可能再退回纯人肉检索的时代了。3. Super Agent Harness 到底在解决什么问题3.1 单体 Agent 的天花板在哪里大模型应用落地到中期大家普遍会碰到的天花板是单个 Agent 能做一件完整的事但做不了一件复杂的事。最典型的死法是这样的——把写一份市场分析报告这个任务交给一个 Agent文件检索、数据分析、报告撰写、格式排版全塞在同一套提示词上下文里。上下文越来越长指令越来越绕结果模型开始精神分裂前一半在认真分析后一半忽然开始写诗或者干脆忽略了某个关键指令。单体 Agent 的另一个硬伤是工具权限无法细粒度治理。所有工具调用都走同一个会话同一个 API Key出了问题无法定位是哪一步、哪个子任务干的。往上游一点说单体结构也没办法做预算控制一个复杂的调研任务可能触发几十次检索调用成本如何预估失败如何重试这些如果在单体架构里做代码会变成一大坨没人愿意维护的分支逻辑。这不是模型能力的问题是组织方式的问题。就像一家公司你可以让一个万能员工干所有事但他不可能同时在十个战场一线工作你需要的是架构师、岗位分工、工作流制度和汇报线。Super Agent Harness 想做的就是这个组织层。3.2 DeerFlow 2.0 对 Harness 的具体实现思路DeerFlow 2.0 的 Harness 设计核心特点我认为可以浓缩为四个字编排优先。它不是让一个大模型接管一切而是把系统拆成几个明确的分层层级职责典型模块关键特性任务编排层接收用户目标拆解任务树分配执行器Orchestrator Planner支持人机确认节点执行器层完成具体研究/执行动作Search Executor, Code Runner, Tool Adapter按类型隔离独立配置记忆与状态层保存跨任务上下文、中间结果、证据链Memory Store, Evidence Graph支持持久化恢复治理与控制层权限、预算、审计、速率限制Policy Engine, Budget Tracker每一次调用可溯源这几层合在一起解决的核心问题是谁能调用什么、凭什么调用、调用的结果往哪里放。就拿预算管控来说在这套架构里可以精确到这个研究任务的检索调用不超过五十次超过之后自动降级为缓存结果优先而这个控制逻辑无需侵入子 Agent 的内部实现只要在调度层加一个拦截器就行。从我实际做工程的角度看这种横切关注点的抽取是 Harness 最有价值的地方。任何单体 Agent 做到后期预算、重试、观测这些逻辑最终都会跟业务逻辑纠缠在一起改一行权限代码可能要重新测一遍全部流程。而 Harness 模式让这些治理能力成为一个独立层业务迭代和治理迭代可以各自独立进行。3.3 融入决策反馈的闭环除了编排和治理DeerFlow 2.0 的 Super Agent Harness 还做了一件我认为不可省的事把人和机器的决策节点显式建模。整个工作流不是一股脑全部自动跑完而是在几个关键节点上停下来问用户任务拆解结果是否符合预期检索到的信息覆盖面是否足够初步结论和用户的预判是否有冲突这种做法在纯自动化爱好者眼里是不够智能但在实际业务里反而是最稳的方案。因为用户的真实需求很少一次性表达完整很多约束条件是看到中间结果之后才想起来的。如果一上来就闷头跑结果大概率跟真实意图偏离很远了。DeerFlow 2.0 把这些确认节点作为一等公民设计进 Harness 这是从工程师思维到产品思维的成熟转变。4. 关键实现路径如何从 0 到 1 搭一套 Deep Research 工作流这一部分我直接分享可落地的方案。你不需要完全照搬 DeerFlow 2.0 的代码但核心思路值得借鉴——我把它拆成五个步骤4.1 先定任务类型再定规划策略第一步不是写代码是想清楚你的系统主要处理什么类型的开放式问题。两类典型场景结论型调研多源信息收集后输出决策建议技术选型、竞品分析观点型综述整理多方论点、分析异同、输出综述框架学术文献整理、政策趋势解读。两类场景对任务拆解粒度的需求差异很大。结论型调研的任务树更适合自顶向下的结构目标 → 维度 → 指标 → 检索词观点型综述更适合自底向上的信息聚类先并行抓取各方观点再聚类提炼共识和分歧。规划模块的提示词模板要为这两类分别设计混用会导致效果明显下降。4.2 建设检索执行器的多路通道实践中一个执行器的效果天花板是很低的。我自己跑测试时单一用网页搜索和混合使用网页社区代码库三种通道在同一个调研任务上的信息来源覆盖度差距能到三倍以上。多路通道的最小落地配置可以是这样网页通道通用关键词检索 域名白名单过滤 时间窗口过滤代码与文档通道GitHub 搜索、官方文档站抓取、README 解析社区通道技术论坛、问答站点、社交媒体精选信源。每个通道的输出都要统一化成结构化的检索条目格式标题、摘要、链接、时间、来源类型、相关性分数这样后端证据聚合器才能统一处理。我踩过一个坑不同通道输出的格式不统一结果聚合阶段只好逐条人工清洗工作量直接翻倍这个基础约定必须在一开始就定死。4.3 搭建轻量级证据链管理不必引入复杂的图数据库一张带任务节点 id 的信息表足够起步。核心字段我建议至少包含证据唯一 id、来源 URL、抓取时间关联任务树节点 id结论摘要、信息置信度评分与哪些已有证据存在冲突或支持关系。预算有限的场景下这条表的查询性能完全够用。真正影响质量的是置信度评分怎么算。我给一个简化版的计算思路就三条规则来源权威性权重官方文档 一线技术博客 综合资讯 社交讨论时效性衰减系数半衰期按信息类型设定技术方案类建议 180 天交叉验证加成多条独立来源支持同一结论时加分。4.4 规划 Harness 的治理边界在落地 Harness 层之前先明确四个治理边界参数单任务预算上限、单 Agent 连续执行步数上限、对外部工具的调用频率限制、内部状态审计日志的保留策略。这四个参数本身就是业务规则的表达不同的业务场景取值天差地别——做风控研究的系统审计日志保留期可能要求 180 天以上做内部效率工具的系统可能 7 天就够了。4.5 从研究型 Agent 到执行型 Agent 的衔接Deep Research 生产出来的结论最终要有人执行落地。在 DeerFlow 2.0 的 Harness 体系里研究型 Agent 产出任务清单 → 执行型 Agent 认领任务并调用具体工具 → 执行结果回流到记忆层更新上下文这是一条完整的业务闭环。研究结论不再是一份建议而是一份工单。这一步做通之后系统才真正从会研究变成能干活。我在自己的项目里做完这层衔接之后的直接体验是再复杂的任务人只需要盯住两个节点的输出——任务拆解是否合理、最终成果是否达标。中间的流程风险不再靠人肉把关而是靠编排层的约束机制兜底。5. 我在实践 DeerFlow 2.0 时踩过的坑和解题思路这部分写给打算自己动手复现的读者。网上关于 DeerFlow 2.0 的代码详解文章不少但大多是列 API、贴流程真正实战中遇到的问题很多要靠自己趟。我把最典型的问题整理成一张问题排查表症状根本原因处理思路任务拆解阶段就反复卡壳耗时长规划提示词缺少输出约束为任务树定义严格 schema让规划器直接输出 JSON 结构检索结果大量重复后面的证据聚合形同虚设检索词之间相关性太强缺少多样性控制在规划阶段显式要求子任务覆盖不同信源类型和角度多路并行检索总是超时报错上游接口限流、重试策略过于死板在 Harness 层引入令牌桶限流器加重试退避报告篇幅很长但没有结论任务树中的决策路径没有被强调在合成阶段的提示词中加入结论前置要求并限制每个论据的字数子 Agent 之间的上下文互相污染记忆层的写入读取缺少隔离引入任务域命名空间按任务 id 隔离读写第一个问题我在刚搭框架时几乎天天遇到。一开始我给的拆解提示词是把这几个问题分解成若干子任务规划器输出的任务树结构不稳定有的深有的浅字段名甚至都不一致。后来我改成必须按如下 JSON schema 输出节点字段包括 id、父 id、描述、检索预算、成功标准稳定率立刻提升了一个量级。所以我的第一原则是能让机器用结构化 schema 约束的就不要只靠提示词里的语言描述。第二个问题特别隐蔽。最开始跑调研任务发现检索回来的二十多条结果全是在讲同一份榜单、同一个示例覆盖率极其感人。排查了原因检索词的生成方式出了问题——子任务之间共享了过高的语义相似度导致搜索引擎返回了相似的结果集。解决办法是给每个子任务至少配备两个不同表述的检索词并强制其中至少一个来自非技术类信源的表达习惯这个 trick 让结果多样性改善非常明显。第四个问题关系到报告的最终可用性。我还记得第一次完整跑通流程之后收到的报告足足有八千多字但读完之后不知道到底应该选 A 还是选 B因为每个方案的论据铺开了一整篇没有主次没有排序。后来我在合成模块中加了一条硬规则所有关键结论必须先给出推荐方向并标注置信度再展开论据。从那之后报告的第一屏就成了答案区后面才是素材区领导看得舒服我也少被问三遍所以结论呢。6. 从 Deep Research 到 Super Agent Harness落地路线图如果你现在想在自己的项目里应用 DeerFlow 2.0 的思路我的建议是分三个阶段走不要一上来就追求全量落地。第一阶段先把单条的 Deep Research 工作流跑通。核心交付物就是一份可验证、可回溯的研究报告。这一步的意义在于验证你的检索通道、任务拆解模板和证据聚合逻辑是否合理。此阶段不需要引入复杂的 Harness 治理层用普通函数调用链也能实现。第二阶段加入 Harness 的治理框架。任务编排统一走调度器各类 Agent 注册成可被编排的执行单元加入预算、频率、审计三件套。完成这一步后系统的单兵能力不会变强但作战纪律有了多个调研任务可以并发安全地跑出问题时能快速定位。第三阶段打通研究型 Agent 和执行型 Agent 的闭环。让 Deep Research 产出的不仅是报告还是一组可执行的任务描述由 Harness 分配给对应的执行类子 Agent 去操作具体工具。到这个阶段你手里的东西就已经是一个真正意义上的 Super Agent Harness——研究、决策、行动三者统一。我自己的项目目前停在第二、三阶段交界处。最深的体会是从研究到执行的闭环打通技术难度其实远低于组织层面的想象难度。真正难的是业务上要接受人退到监督位、机器走到执行位这个姿态变化。DeerFlow 2.0 的架构本身已经把路铺得很实剩下的每一步都要靠具体业务场景反复调参和验证。最后分享一个我在实际部署中的小技巧给整个 Harness 配一个运行日志摘要器每次任务结束之后自动生成一页纸的过程纪要——本次任务拆了几步、每一步调用了几次检索、哪些证据产生了冲突、最终的置信度是多少。这个摘要既服务于审计也服务于下一次任务规划时的参考。跑了几十次之后你会发现它慢慢会变成你最宝贵的系统知识库。