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方案的选型"，它拆出来的子任务往往是"什么是RAG""RAG的优缺点""主流方案对比"这种教科书式的层级，泛泛、不可操作。但如果给了明确的输出约束、时间预算和执行主体描述，拆解结果会完全不一样。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 设计，核心特点我认为可以浓缩为四个字：编排优先。它不是让一个大模型接管一切，而是把系统拆成几个明确的分层：

这几层合在一起，解决的核心问题是"谁能调用什么、凭什么调用、调用的结果往哪里放"。就拿预算管控来说，在这套架构里可以精确到"这个研究任务的检索调用不超过五十次，超过之后自动降级为缓存结果优先"，而这个控制逻辑无需侵入子 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；
• 结论摘要、信息置信度评分；
• 与哪些已有证据存在冲突或支持关系。

预算有限的场景下，这条表的查询性能完全够用。真正影响质量的是"置信度评分"怎么算。我给一个简化版的计算思路，就三条规则：

1. 来源权威性权重（官方文档 > 一线技术博客 > 综合资讯 > 社交讨论）；
2. 时效性衰减系数（半衰期按信息类型设定，技术方案类建议 180 天）；
3. 交叉验证加成（多条独立来源支持同一结论时，加分）。

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、贴流程，真正实战中遇到的问题很多要靠自己趟。我把最典型的问题整理成一张问题排查表：

第一个问题我在刚搭框架时几乎天天遇到。一开始我给的拆解提示词是"把这几个问题分解成若干子任务"，规划器输出的任务树结构不稳定，有的深有的浅，字段名甚至都不一致。后来我改成"必须按如下 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 配一个"运行日志摘要器"，每次任务结束之后，自动生成一页纸的过程纪要——本次任务拆了几步、每一步调用了几次检索、哪些证据产生了冲突、最终的置信度是多少。这个摘要既服务于审计，也服务于下一次任务规划时的参考。跑了几十次之后你会发现，它慢慢会变成你最宝贵的系统知识库。