我自己做 LLM Agent 的工程化落地也有几年了手上这套被我简化成 DeerFlow 2.0 的内部框架最开始只是为了解决团队里“搜资料、写报告”这件烦心事做了个典型的 Deep Research 应用。结果跑着跑着发现它越来越多的能力被其他业务团队看上有的人拿它做竞品信息汇总有的人让它定期巡检线上数据还有人干脆想让它每天自动处理一批工单。到这一步我意识到原来的“研究助手”定位已经不够了它本质上需要变成一个能编排多个子任务、挂接多种工具的 Super Agent Harness。这篇内容就用这套系统的演进过程来聊聊Deep Research 能力怎么一步步变成通用 Agent 运行时的以及在实际搭建过程中应该注意哪些细节。适合看这篇文章的人很明确一是正在做 RAG 或者 Research Agent被多轮检索、长上下文和高成本折腾得够呛的工程师二是已经跑通了单个 Agent 场景想往上抽象一层做多 Agent 编排的产品或技术负责人。我尽量不写那些 PPT 里才有的概念多说能直接复用的方案和参数。1. 为什么从 Deep Research 升级到 Super Agent Harness1.1 Deep Research 在真实项目中遇到的坎先说 Deep Research 原本解决的问题。所谓深度研究本质上不是“搜索一下然后拼凑摘要”而是把一个宽泛问题拆成若干子问题再经历多轮检索、阅读、信息抽取、交叉验证最后生成带引用的结构化报告。市面上不少产品化的 Deep Research 工具都长这样输入一个问题后台调用搜索接口抓取几十个网页再用 LLM 总结成报告。但实际落地的时候问题很快暴露出来。第一个坎是任务边界太窄。团队一开始的需求是“帮我调研某个技术选型”跑得挺好。但当需求变成“调研完顺便把对比表格写到在线文档再给相关同事发个通知”时原来的单链路就傻了。它不是不能做而是要我把检索、总结、文档写入、内部通知这些能力硬塞进同一个提示词里提示词越写越长模型表现越来越不稳定。第二个坎是上下文管理失控。深度研究一轮任务动不动产生几十万字检索内容全塞进上下文既不现实也没必要。早期我图省事把所有网页内容截断后直接拼进提示词结果模型注意力被大量噪音干扰报告质量忽高忽低。后来不得不自己做分层摘要、上下文压缩但这部分代码已经明显超出了“研究应用”的范畴更像是一个通用 Agent 框架在做的事。第三个坎是缺乏通用编排能力。研究任务天然适合并行拆成 4 个子问题理论上可以并行检索、并行阅读最后再汇总。但单应用的代码里我很难快速实现“并行执行一部分子任务、失败重试、汇总结果”这样的编排逻辑。每次新需求几乎都要改主流程维护成本非常高。1.2 DeerFlow 2.0 想解决什么问题正是这些坎让我把目光从“研究应用”转向了“研究基础设施”。DeerFlow 2.0 这个名字里的 2.0代表的不只是版本号而是一次架构视角的切换不再把 Deep Research 当作一个完整应用来写而是把它降级为一个“应用场景”底层则是一套通用的 Super Agent Harness。Super Agent Harness 这个名字直译过来是“超级智能体装备层”我更喜欢把它理解成“Agent 的运行时与操作台”。就像写后端服务你不会从路由到数据库全手写一遍而是依赖一个 Web 框架Agent 应用也应该站在一套公共能力之上规划、执行、反思、记忆、工具调用、并发控制、日志追踪、安全审批。DeerFlow 2.0 的 Deep Research 功能只是这套 Harness 上的第一个旗舰应用。有了这层抽象之后新场景接入的成本从“重新开发一套”变成了“注册几个新工具、写一个场景配置”。比如后面接线上数据巡检时我只加了两个步骤节点和一个告警推送工具连核心执行引擎都没有动。这个差距是我觉得这次升级最有价值的地方。1.3 什么样的人适合参考这套思路纯调 API 的初学者可能会觉得这套东西有点重但如果你的目标只是做一个给内部用的小工具那确实不用上这么复杂的架构。真正值得参考的是下面两类情况。一类是你正在同时维护三个以上的 Agent 场景。如果每个场景都是独立代码库、独立提示词、独立跑批逻辑你会发现公共部分越来越多都要调用模型、都要管理上下文窗口、都要做重试、都要记录日志。把这些公共部分抽成 Harness收益会非常明显。另一类是你的 Agent 场景涉及长链路和多种工具。比如从研究到写文档、从数据查询到生成图表、从外部检索到内部系统操作。这种场景如果不用统一的编排框架来管最后一定会陷入“提示词调用提示词”的泥潭排错排到怀疑人生。DeerFlow 2.0 的设计思路就是让这类复杂场景能有章法地拆开、执行、追踪。2. 核心架构拆解一个研究任务怎么被组织起来2.1 规划-执行-反思的三段式循环DeerFlow 2.0 的底层执行单元不是一条写死的链式调用而是一个“规划-执行-反思”的循环。每个复杂任务进来主 Agent 先把任务目标拆成步骤图然后逐步执行每完成一个阶段就停下来检查中间结果。我把这套循环的实现方式简化一下规划阶段由 LLM 输出一个任务清单每个任务包含名称、目标、依赖工具和预期产出执行阶段按顺序或并行调用节点反思阶段会重新审查已产出内容判断是否需要调整后续计划。关键是一定要在反思节点留出“重新规划”的出口否则反思只是个摆设。实际工程里我习惯给反思节点设置预算。比如整个任务的规划次数上限是 6 次一旦反思结果显示需要重新规划就计数加一达到上限后强制进入汇总阶段。没有这个限制Agent 会在一些刁钻问题上反复横跳既费 token 又拖时间。这样写不是为了限制模型的聪明程度而是为了保证任务一定能结束这在生产环境里比“追求完美回答”重要得多。2.2 工具抽象工具包、输入输出契约、重试与超时Deep Research 场景需要三类基础工具搜索引擎、网页抓取器、文档解析器。如果要做更通用的 Harness还得加上数据库查询、在线文档写入、消息通知、代码执行器等。我在 DeerFlow 2.0 里把每一个工具都包成标准结构工具名、描述、输入 JSON Schema、输出 JSON Schema、超时时间、重试策略、是否需要人工审批。模型不关心工具内部实现它只看到“工具描述 参数约束”这一点非常关键因为工具描述写得越清晰模型的调用准确率越高。举个例子搜索工具的输出 Schema 我会固定成{results: [{title: , url: , snippet: }]}绝不掺入无关字段。抓取工具则明确标注“最大返回字符数”并且在真实返回前先让一个轻量摘要模型把页面压一遍。这么做的原因在后面第三部分会细讲简单说就是为了避免大段原始文本冲击主模型的上下文。每个工具还要单独做超时与重试配置。搜索引擎偶尔慢、爬虫偶尔被反爬拦截、文档解析偶尔超时这些都是日常。我曾经见过一个 Agent 因为某个工具没设超时整个任务卡在原地半小时后面所有并行子任务全部白等。现在我的默认策略是普通工具超时 15 秒重试 2 次重试之间指数退避涉及外部网页抓取的可以放宽到 30 秒但重试上限不变。2.3 状态管理与上下文压缩状态管理是 Super Agent Harness 里最容易被低估的一块。Deep Research 的链路长中间要保存的东西很多原始问题、子任务列表、每轮检索结果、已经完成的提取片段、尚未处理的 URL 队列、生成中的报告草稿。我建议用一个全局状态对象来承载这些数据并且每个节点执行前后的状态变化都要落盘。这样有两个直接好处一是任务中途挂了可以恢复不用从零开始二是调试时可以精准回放“走到哪一步状态就变得不对劲了”。上下文压缩则是为了保证主模型的窗口不被撑爆。我的经验是三层压缩策略。第一层是“检索结果压缩”每个网页先由摘要模型生成 300 字以内的结构化摘要再交给后续环节。第二层是“长期信息归档”已经提取出来的原子事实直接写入状态数据库不再驻留在对话上下文里。第三层是“对话裁剪”当上下文接近窗口上限时把最早的部分压缩成一个整体摘要替换掉原始消息。这三层策略听上去不复杂但缺了任何一层长链路研究任务都会在做到后半程时出现明显的质量下滑。2.4 可观测性从黑盒到可回放早期版本最让我难受的一件事是任务失败后完全不知道哪里出了问题。模型按照自己的逻辑调了一堆工具最后报告没生成我手里只有一句笼统的报错。没有链路追踪这类问题几乎没法定位。DeerFlow 2.0 里我把可观测性当成一等公民来做。每个节点的执行都会记录输入参数、输出结果、耗时、token 消耗、状态码、异常信息。这些记录最终汇成一条完整的事件流支持按任务 ID 查询。调试的时候我可以把一次任务完整“重放”一遍盯着每一步的输入输出一眼看出是哪次工具调用给了错误参数。链路追踪的具体实现不复杂思路跟后端微服务一样给每个任务分配 trace ID给每个子任务分配 span ID父子关系通过 ID 关联。关键是坚持记录不在“简单任务”上偷懒。因为简单任务出错时你通常不需要追踪而一旦需要追踪却没有数据那才是真正的灾难。3. 深度研究链路的实操拆解3.1 把用户问题拆成研究子任务Deep Research 的第一步是把用户的原始问题拆成一组可执行的研究子任务。这一步骤不能简单地让模型“给出几个搜索关键词”而是要模型输出一个结构化的研究方案。我常用的提示词模板大致包含这些要求先明确研究目标再列出 3 到 6 个互不重叠的子问题每个子问题标注适合用什么类型的信息源比如行业报告、官方文档、社区讨论、学术论文部分子问题还需要标注回答的评价标准比如“必须包含数字来源”。这里有一个很容易犯的错子任务拆得太细导致检索成本翻倍但信息增量很小。比如用户问的是“A 框架和 B 框架哪个更适合做实时数仓”如果拆出 8 个子问题其中 3 个都是“A 框架的架构原理”这种那就是资源浪费。我自己的解法是让规划模型每输出一个子问题同时预估研究难度太简单的子问题直接合并进别的环节不再单独建任务。拆完之后还有一个校验步骤检查子问题是否完整覆盖了原始诉求。实践中可以让另一个模型做一次反向验证把子问题列表拿回去判断“基于这些子问题是否能回答原始问题”。多花这一次调用能避免不少“报告答非所问”的情况。3.2 搜索、抓取与正文提取的工程细节搜索环节看起来简单实际上水很深。直接拿搜索接口返回的 snippet 拼给模型信息量根本不够完整抓取网页再全文阅读又会带来高延迟和高 token 开销。我的折中策略是“两级检索”。第一级是先用搜索引擎拿到前 10 到 20 条结果的标题、摘要和链接让一个简单的评分模型或规则判断哪些链接值得深入阅读。第二级才对筛选后的链接做网页抓取和正文提取。这一层过滤能把后续处理的网页数量控制在个位数质量还更高。正文提取也有不少细节。很多网页动辄几十 KB但主体内容只有几千字。我一般先用 HTML 解析库去掉导航、广告、脚本和页脚再基于正文密度算法抽取主文本区域。实测下来这类算法对新闻、博客、文档页效果都不错遇到特别复杂的页面再加一层兜底直接把可见文本全量截断到 5000 字以内。反爬是另一个常见问题。我的经验是控制单域名并发、加合理的请求间隔、设置完整的请求头。但一定要给抓取器配置降级方案如果抓取失败至少把搜索结果里的摘要返回出去不让任务卡死。很多时候那一段 snippet 已经能支撑后续的信息提取了没必要以失败结束整个节点。3.3 多源信息提取与交叉验证抓完网页后不能直接把全文丢给主模型总结而要先做“信息提取”。这一步我会针对每个网页单独调用一个提取 Agent让它只抽取与当前子问题相关的事实逐条输出每条事实必须带来源 URL 和原文摘录。输出格式我固定成下面这种 JSON{ facts: [ { fact: 截至2025年Q3A产品的市场份额为31.2%, source_url: https://example.com/report, source_excerpt: A产品在第三季度领跑市场占有率31.2%, confidence: high } ] }指定“带原文摘录”这个约束很关键它迫使提取 Agent 不要凭空发挥。每条事实都有出处的直接好处是后续报告可以真正做到“可溯源”。当多个网页对同一个问题的说法不一致时我会安排交叉验证节点。做法是让验证 Agent 把涉及同一事实的不同来源放到一起判断是口径不同还是真实冲突。如果冲突无法解决报告里就如实呈现双方观点不强行二选一。这一步最能体现深度研究和普通搜索摘要的价值差距。3.4 引文体系和报告组装报告组装阶段我的习惯是先用提纲再写正文。汇总 Agent 根据子问题和已验证的事实列表生成一份带章节结构的报告大纲每个段落预先分配几个核心事实。这个大纲通过后再逐章节展开。引文体系要从信息提取阶段就开始建立。每个来源 URL 在第一次出现时分配一个 ID比如[S5]后续所有引用都指向同一个 ID。报告最后统一列出完整来源列表包含标题、链接、访问日期。这样一个闭环用户看报告时能直接点回原文验证信任度提升非常明显。报告组装时还有一个性能细节不要在一步调用里让模型输出整篇一万字的报告。分段生成的效果通常好得多因为模型在短文本生成上更稳定。先写前言和摘要再写各章节最后把所有片段拼起来再用一个润色节点统一风格。成本上多了一次调用但报告质量的提升非常值得。4. 从研究应用扩展到 Super Agent Harness 的编排方案4.1 用 Supervisor 模式替换单一线性链DeerFlow 2.0 从研究工具走向通用 Harness 后第一个架构变化就是把“单一线性链”换成了“Supervisor 模式”。所谓 Supervisor 模式就是有一个主控 Agent 负责理解用户目标、拆解任务、分发给若干子 Agent再收集子 Agent 结果做整合。子 Agent 各管一段有的专职搜索有的专职阅读有的专职写代码有的专职调用内部 API。主控 Agent 不直接执行具体动作只做任务分配和结果汇总。这么做的好处非常实在每个子 Agent 的上下文是隔离的不会被其他任务的中间结果污染。研究 Agent 不需要知道数据查询 Agent 的中间变量写文档的 Agent 只需要接收整理好的事实不用面对一堆原始抓取内容。模块之间的边界清晰了调试和替换成本都大幅度下降。一个容易踩坑的地方是 Supervisor 模式的提示词设计。不要让主控 Agent 拥有过多“自由发挥”的空间至少要给它明确的节点清单和输出约束。我见过不少项目搞了 Supervisor 之后反而更不稳定因为主控 Agent 在多个子任务之间反复横跳输出格式经常对不上。我的做法是把子 Agent 的调用协议写成固定 JSON Schema主控只能按协议调用不允许自己发明新字段。4.2 任务队列、并发控制与故障恢复多子 Agent 并行离不开任务队列。我在 DeerFlow 2.0 里的实现是先把所有可并行子任务放进队列再由一个调度器按配置决定同时执行几个。并发数不是越大越好要同时考虑模型接口限流和工具服务压力。我自己常用的参考配置是外部搜索类并发 3 到 5内部数据服务并发 5 到 8纯模型生成类并发可以放到 10 左右。这里没有标准答案完全取决于你的上游服务能扛多大压力。建议在生产环境先压测一轮静态配置不如实际跑一次数据说话。故障恢复也依靠任务队列实现。每个子任务都有独立状态待执行、执行中、成功、失败、重试中。一旦某个子任务失败且重试次数用完调度器就把该任务标记为失败并且不让它影响其他并行任务。等剩下所有任务跑完汇总节点再决定是降级处理失败部分还是整体终止。这个机制在实际运行时救过我很多次。比如研究 6 个子问题其中一个子问题要查的数据源临时挂了其他 5 个照常执行报告把挂掉的那块标记为“数据暂不可得”而不是让整份报告泡汤。4.3 记忆系统工作记忆、长期记忆与元记忆记忆系统是 Harness 区别于普通脚本的一条重要分界线。我按三个层次来组织。工作记忆对应的是当前任务进行中的临时状态正在处理的子问题、刚抓到的页面、已经提取的事实。这部分通常放在全局状态对象里任务结束可以清理。长期记忆是 Agent 跨会话需要保留的知识比如“用户所在团队常用的报告格式”“历史上调研过哪些竞品”“哪些数据源可信度更高”。这些我放在向量数据库里每次新任务规划时先检索一遍长期记忆把相关背景注入给规划模型。这个能力让同一套系统在不同团队里越用越顺手因为它能记住团队的偏好。元记忆则是关于 Agent 自身运行模式的记录包括哪类问题在哪些环节容易失败、哪类工具调用经常超时。这部分在每次任务结束后异步生成沉淀成调优的依据。坦白说元记忆并不适合做成一个单独的 AI 模块用普通日志聚合分析就能实现大部分价值但不做这一层沉淀系统性能就会长期停留在一个不稳定的水平反复踩同一个坑。4.4 安全边界权限、审批点和审计日志从内部工具变成通用 Harness安全边界的建设就绕不过去了。尤其是当 Agent 掌握了“写文档、发消息、改配置”这一类写操作工具时没有权限控制就像把钥匙挂在门口看着方便住着不安心。我给写操作工具分了三级权限只读、受控写入、高权限写入。受控写入需要经过审批节点高权限写入必须有独立审批流。审批节点的实现不复杂调度器遇到标记为“需要审批”的工具调用时先冻结该节点的执行把调用参数推给审批人等审批通过再放行。审计日志也要从一开始就记录。每个工具调用、每次提示词交互、每次状态变更都写入不可篡改的日志存储。这个习惯在事故排查时价值极大可以明确看到 Agent“在什么时间、基于什么上下文、做出了什么操作”避免出了事互相推诿。不要觉得日志数据量大宁可存下来用不上也比要用时没有强。5. 部署与实践调参记录5.1 环境准备和模型分工我把 DeerFlow 2.0 的运行时拆成了两部分核心引擎和执行节点。核心引擎负责任务解析、编排、调度、状态管理执行节点则按功能分拆成搜索节点、抓取节点、提取节点、汇总节点等。每个节点可以独立部署、独自扩容也可以全放同一个进程里跑方便开发调试。模型选择上我强烈建议做分工不要一个模型打天下。规划与反思这种对推理能力要求高的节点用当前能力最强的推理型模型信息提取这种机械性工作用中等级别的模型就够了摘要生成可以用性价比更高的模型。这样搭配下来总成本往往能省一半以上而质量几乎没有损失。环境准备本身不复杂开通模型 API 权限、准备一个向量库用于长期记忆、装好网页解析和文档解析依赖、配好各工具的 API Key。如果希望快速验证跑一个本地版也能跑通只是网页抓取和并发能力不如线上版。5.2 关键配置示例一个研究 Agent 的服务端配置下面这个配置片段可以作为参考一个典型的 Deep Research 任务配置{ agent_type: deep_research, max_replan_times: 6, parallelism: 4, steps: [ { name: plan, model: reasoning-model, budget_tokens: 4000 }, { name: decompose, model: reasoning-model, budget_tokens: 3000 }, { name: search, tool: web_search, timeout_seconds: 20, retry: 2, parallel: true }, { name: extract, model: econ-model, budget_tokens: 2000, parallel: true }, { name: verify, model: reasoning-model, budget_tokens: 3000 }, { name: write_report, model: flagship-model, budget_tokens: 8000 } ], memory: { enabled: true, namespace: team-marketing } }这个配置里最值得留意的两个参数一个是max_replan_times一个是parallel。前者保证任务不无限循环后者决定哪些节点可以并行。搜索和提取标记为并行是因为多子问题间的检索互不依赖验证和写报告标记为串行是因为它们需要等待前序所有结果就绪。5.3 性能与成本控制经验性能优化上我踩过最深的坑是盲目并行。早期为了追求速度把子任务并发数从 4 调到 10理论上能快 2.5 倍实际上因为模型接口限流加部分工具超时不仅没变快失败率还直线上升。最后回滚到 5效果反而稳定。性能调优一定要以压测数据为准别靠感觉拍脑袋。成本控制方面预算应该从任务开始前就确定而不是跑完再看账单。我在每个节点都配了 token 预算例如提取一个网页的预算通常是 1500 token超出了就只保留最重要的部分继续做。规划节点允许模型多写一点但也要小于 4000 token。还有一种成本陷阱是“隐蔽的多次调用”。有些模型会以工具调用结果作为中间过程一次任务里可能调用搜索十几次。我后来给搜索节点加了一个“去重缓存”同一个查询指纹在 5 分钟内不重复调用搜索接口。这一个改动就把搜索调用量降了三成效果立竿见影。5.4 我在生产环境里实测的血泪建议真的上了生产才会发现 Demo 阶段想象不到的问题。我挑几个印象最深的经验写在下面。第一任务超时要分级设置。我之前统一设 60 秒超时结果导入型任务经常 40 秒能跑完而网页抓取任务 30 秒就该判超时拖到 60 秒反而浪费整个流水线的等待时间。按工具类型单独设超时性能提升比你想的更大。第二异常信息一定要保留给上层。子 Agent 失败时如果只传一个“执行失败”的 flag汇总节点完全不知道怎么处理。我现在强制子 Agent 的失败输出带上错误码和可读信息比如“search_rate_limit”“page_parse_error”汇总节点就能根据这些信息决定重试、降级还是跳过。第三产出物的质量检查不能只在最后一步。我在每个关键节点后面都挂了轻量校验脚本比如检查提取结果是不是合法 JSON、搜索返回的 URL 有没有重复、报告里引用的来源 ID 是否都存在于来源列表中。这些校验都很便宜但能在问题扩散前拦截住。6. 常见问题与排查速查表6.1 Agent 卡在重复搜索的死循环里这是一个高频问题。Agent 在做研究任务时反复搜索同一个关键词只是换了个说法结果没有实质动作白白消耗 token。我遇到几次之后在调度器里加了一个重复检测对每次搜索查询做规范化处理后取哈希存在一个查询历史集合里遇到重复的查询直接复用缓存结果并且不再触发新的搜索调用。同时在提示词层也做了约束明确告知模型“如果某个查询已经执行过且未取得新信息请更换查询策略而不是重复执行”。两条结合起来问题基本能解决。6.2 上下文一长报告质量就明显下滑这个问题通常不是模型不行而是上下文里的噪音太多。我在早期做长报告时经常把提取出来的所有事实一股脑塞进最后生成的节点结果模型被大量低相关度信息干扰报告抓不住重点。后来我在写入最终节点前做了一次“相关性过滤”让一个轻量模型把待引用的事实列表按“与报告主旨的关联度”排序只保留前 80% 相关的事实。削减 20% 的数据量报告质量反而提升了一个档次。上下文不是越多越好够用且精炼才是关键。6.3 工具调用解析失败和超长输出问题LLM 偶尔会生成不合法的 JSON 参数这是工具调用的经典难题。我的处理方法是先解析解析失败时把原始输出拼进错误消息重新请求模型修正一次。如果修正还失败就判定该次工具调用失败不阻塞整个任务。超长输出则是另一个让人头疼的问题。有些模型在生成总结时不受控制地输出一大段文本塞满上下文。我给每个工具输出都加了两道闸门一是结构层面限制字段长度二是内容层面先让压缩模型做摘要。两道闸门一起上超长输出问题基本绝迹。6.4 调试技巧日志、链路追踪与离线回放最后分享一个我每天都在用的调试流程。遇到某个复杂任务表现不对时我的第一步不是凭直觉改提示词而是先把链路追踪数据拉出来逐个节点看输入输出。具体操作是打开一次任务的事件流从第一个节点开始按时间顺序观察。大多数情况下一两分钟内就能定位到异常节点比如某次检索结果质量差、某次提取漏掉了关键事实、某次汇总丢了一个子任务的结论。定位到异常节点之后把该节点的输入复制出来单独跑一次离线调用快速验证修改方向。这个“离线重放”的习惯帮我避开了大量无效调试。直接在长链路里改提示词很难判断改动到底影响了哪一个环节而离线重放可以控制变量每次只改一个地方观察效果效率高得多。常见问题排查速查表现象常见原因缓解方案任务无限循环缺少重规划次数限制配置 max_replan_times默认 5~6 次重复搜索、结果雷同查询去重缺失查询规范化缓存5 分钟内不重复上下文溢出原始文本直接进入主上下文分层压缩先摘要再注入报告抓不住重点事实列表过载生成前做相关性过滤截断低相关项工具失败影响全局没有独立失败降级机制子任务独立状态失败可跳过模型返回非法 JSON参数解析不稳定自动修正一次失败则标记节点失败线上问题定位慢缺少链路追踪全链路 trace ID 节点级日志7. 写在最后我的一些实际体会这套系统从第一版到 DeerFlow 2.0 的形态我在过程中最深的体会是做 Agent 框架不要一开始就追求大而全而是要让“通用能力”被真实场景逼出来。如果我在第一版 Deep Research 没有跑出稳定效果前就去搭 Harness很可能造出一个没人用的空壳。反而是先解决具体研究任务再把中间的复用点抽象出来水到渠成地形成了 Harness。另一个体会是Agent 类项目最容易低估的是工程复杂度而不是模型能力。很多人以为只要模型够聪明一切都好说真正跑起来才发现状态管理、并发控制、上下文压缩、可观测性每一个环节都能让系统崩溃。模型是引擎但引擎再好车身不稳也跑不了长途。如果看完这篇内容你正准备动手做类似的事情我给出三个最直接的落地建议。第一先拿 Deep Research 这类闭环场景跑通全链路建立数据和日志基础。第二在开发每个节点时多想一层复用性哪怕是提取节点也尽量写成与具体研究课题无关的通用组件。第三从第一天起就给工具调用加上审计日志这个习惯会在未来无数次调试和事故排查中救你。最后再顺手分享一个小技巧我给每个关键节点都设计了“空跑模式”只记录输入输出、不真正调用外部工具。调试时用历史数据做离线模拟开发速度能快一大截。这个设计最初只是为了省测试成本后来发现它意外成了最好的回归测试工具。遇到版本升级或者提示词调整先跑一遍历史任务对比结果比什么评估指标都直观。