这段时间社区里关于 Agent 的讨论挺有意思很多人还在纠结模型选型、上下文窗口、工具调用格式但我发现真正把 Agent 从demo推向产品的团队几乎都在做同一件事——搭好 Agent 外面的那层壳。这层壳就是标题里说的 Harness。今天想结合 Anthropic 在长时任务上的设计思路以及 Google AX 那套声明式调度的玩法聊聊我理解的 Agent 新护城河到底在哪以及这套东西落地的真实手感。1. 为什么 Harness 比模型本身更值得投入1.1 模型是发动机Harness 才是整车过去一年我和很多做 Agent 的团队聊过有个特别普遍的错觉大家觉得只要模型够聪明Agent 就自然好用。结果呢换个更强的模型任务完成率确实涨了但工程上的坑一点没少——上下文越拖越长、工具调用的参数经常飞、失败重试完全靠运气。问题出在哪出在大家把智能全押在模型上却没人管干活这件事本身。我习惯把 Agent 拆成两层来看。底层是模型它负责理解、推理、生成上层是 Harness它负责约束、记忆、调度、恢复、安全。打个比方模型是发动机Harness 是整车。发动机马力再大没有变速箱、刹车、转向系统你也没法开着它上路。Anthropic 在长时任务设计里反复强调的 session management、task state、tool 调用的生命周期管理本质上都是在补整车的部分。很多人问Harness 和 Agent 到底什么区别我的理解是Agent 是一个逻辑实体它由模型工具状态策略共同定义而 Harness 是承载这个实体的运行时框架。你可以没有 Harness 地写一个脚本式的 Agent但一旦任务变长、工具变多、并发上来脚本式的写法必然崩塌。这不是模型能力问题是工程结构问题。1.2 长时任务的三个真实痛点我做过一个内部数据分析 Agent最初版本很简单用户提问题Agent 调 SQL 工具返回结果完事。跑通 demo 很容易但放到真实业务里就出现三个痛点。第一个是上下文漂移。一个分析任务往往要经过理解需求→查元数据→写 SQL→跑查询→看结果→发现问题→再查这样的多轮循环每轮都会往上下文里塞东西。塞到第 20 轮模型自己都忘了最初的需求是什么。第二个是失败恢复。SQL 写错了、接口超时了、中间某个工具返回格式变了Agent 该怎么处理没有 Harness 的话基本就是重试重试不行就死循环。第三个是任务中断。真实环境里任务不可能一口气跑完服务重启、网络抖动、用户等不及关掉页面再回来时上下文没了一切归零。这三个痛点的共同本质是Agent 缺一个外部大脑来管理任务状态和生命周期。模型只负责单步决策跨步骤的稳定性必须由 Harness 来兜底。这也是我后来看到 Anthropic 那套设计时特别有共鸣的原因——他们不是在教模型怎么思考而是在教 Agent 怎么把一件事做完。2. Anthropic 长时任务设计里的工程化信号2.1 Session 不是存储是任务的空间结构Anthropic 在长时任务设计里有一个理念很关键不要把所有状态都堆在对话上下文里而是把任务空间拆出来。对话只是任务空间的一个窗口真正的状态应该落在 session 的持久化层。我举个具体例子。假设让 Agent 写一份市场调研报告它需要查资料、读 PDF、做摘要、写初稿、按反馈修改。如果所有中间产物都放在对话里很快对话就变成一锅粥。正确做法是给任务建一个工作台——它有独立的资料区、笔记区、产出区每一步的结果都沉淀到工作台里对话只负责传递当前要做的动作。这个设计在代码上的体现就是Session 对象不仅存消息历史还存任务元数据、工具调用记录、中间产物索引。我在自己的项目里实现了一个简单的版本核心就是给 session 加了一个 context store所有工具写回的结果都先落到 context store再以引用形式出现在对话里。这么做之后上下文长度直接降了一半多模型对任务的聚焦度明显提升。2.2 Tool 调用的生命周期比正确率重要另一个我特别赞同的思路是把工具调用当作有状态的操作来管理而不只是一次性函数调用。一个工具调用从发起到完成有 pending、running、succeeded、failed、cancelled 这些状态工具产生的结果要分门别类地归档失败要能定位到具体是参数错误、超时、还是权限问题。你可能觉得这是不是过度设计了真不是。没有生命周期管理的时候Agent 调一个工具失败模型只能看到一行错误信息它根本不知道是应该改参数重试还是换一个工具还是干脆放弃。有了生命周期管理Harness 能把失败原因结构化地告诉模型决策质量完全不一样。我在实践中会用一个 wrapper 统一包装所有工具调用把每个调用包装成一个 task 对象记录输入输出和状态并提供 retry、rollback、compensating action 的钩子。这套东西看起来占用不多但它在异常场景下救了我无数次。比如某个数据服务临时挂了Harness 检测到失败模式是上游超时就会自动切到备用数据源Agent 甚至感知不到发生了切换。2.3 长任务的检查点与恢复机制Anthropic 这类长时任务设计里还有一个容易被忽略的点检查点。长任务跑几十分钟甚至几小时中间任何一次异常都可能导致整个任务报废。正确做法是定期把任务状态落盘包括当前进度、已完成步骤、未完成步骤、上下文摘要。任务中断后新会话可以从检查点恢复而不是从头开始。这里有个细节值得展开恢复时上下文怎么处理直接塞满历史消息不现实更合理的做法是生成一个结构化的任务摘要包含目标、已完成事项、当前结论、下一步计划让模型在摘要基础上继续。我实测下来恢复后的效果和未中断前几乎一致只要摘要质量足够好。我从这个设计里学到的最重要的一件事是Agent 项目要把任务可恢复当成默认要求而不是事后补救。你永远不知道生产环境会发生什么与其祈祷别出问题不如让系统天然能扛住问题。3. 声明式调度把 Agent 的执行逻辑从代码里抽出来3.1 为什么命令式编排会走向失控编排是 Agent 项目里最容易腐化的地方。刚开始大家习惯用命令式代码写编排if 用户意图是 A就调工具 X再根据结果判断要不要调工具 Y。这种写法在小规模时很直观但一旦分支多起来就变成了谁也改不动的面条代码。我见过一个真实案例某个 Agent 的编排代码有六个嵌套层级每个分支还要处理异常、重试、回退。加一个新功能要改四个地方跑一晚上测试第二天全是回归。根因是命令式编排把意图和实现焊死了——代码里写的是如何执行但业务真正关心的是做什么、按什么顺序、满足什么条件。声明式调度就是把这个逻辑反转过来你只需要声明任务由哪些步骤组成、每一步的依赖关系、什么条件下执行什么至于每一步怎么执行、失败怎么处理、怎么并发都由调度引擎负责。Google AX 那套思路的核心正是这个——把 Agent 的执行流程看作一个有向无环图节点是工具或子任务边是依赖和条件调度器负责驱动这个图跑完。3.2 Google AX 的调度模型拆解Google AX 给我的启示可以拆成几个要点。第一任务定义与执行解耦。你在配置里写清楚这个任务需要经过 step1、step2、step3step2 依赖 step1 的结果引擎按图执行。第二支持条件分支和并行。某些步骤之间没有依赖关系可以并行跑某些步骤根据前置结果决定要不要执行。第三具备内置的观测性。每一步的运行状态、耗时、输入输出、错误信息都能追踪到排障不需要再看日志猜。我在一个 RPA 落地项目里实验过这套模型场景是从邮件读取附件→解析 Excel→匹配数据库→生成报表→发送钉钉通知。用命令式写大概要两百行代码加一堆异常处理用声明式写就是一份步骤清单加依赖关系引擎负责按图跑。最直观的好处是后续加一个如果报表数据异常则跳过发送并告警的分支只需要改配置不需要改代码。这里我想强调一个容易被误解的地方声明式调度不是要消灭代码而是把流程控制从业务代码里剥离出来。工具本身的逻辑还是代码但何时调用、失败怎么办、如何并行这些控制逻辑交给声明式定义和引擎执行。分开之后两边都更简单。3.3 DAG 引擎在 Agent 场景的落地要点在 Agent 场景里用 DAG 引擎我总结了几个落地要点。节点粒度要适中。如果每个工具调用都做成一个节点图会变得非常大且失去抽象能力如果把整个 Agent 做成一个节点又回到了命令式。我的经验是把一组具有明确内聚目标的动作作为一个节点比如资料收集是一个节点内部包含多次搜索和阅读。状态传递要显式化。节点之间传递的数据要明确定义 schema不要偷偷塞一个全局变量进去。显式传递最大好处是每个节点可以独立测试、独立恢复。失败策略要在图上就规划好。哪些节点失败可重试哪些节点失败要中断整个流程哪些节点有 fallback 实现这些应该在声明配置里写清楚而不是散落在代码里。我在实现时还加了两个实用功能一个是超时控制每个节点有独立的超时时间防止某个工具卡死拖垮整个流程另一个是节点级重试带退避策略避免一失败就整条图重跑。这两个功能让整个调度的鲁棒性高了一个档次。4. 我实测过的 Harness 架构与实现坑4.1 一套可复用的三层 Harness 结构基于前面的理解我在自己的项目里沉淀了一套三层 Harness 结构会话层、执行层、资源层。会话层负责和模型交互管理 session、上下文裁剪、摘要生成执行层负责任务调度跑 DAG、管理工具生命周期、处理重试和恢复资源层负责对接外部系统包括工具注册中心、数据存储、权限控制、限流熔断。用这套结构重写之前的 Agent 后最明显的变化是加功能变成了一件很轻的事。以前加一个新工具要在编排代码里加分支现在只需要注册工具、声明它在哪个节点可用调度引擎自动把它纳入流程。以前处理一个失败分支要写一整套 if-else现在在声明配置里加一个 on_failure 策略就行。关于并发这套结构也给了我一个清晰的抓手。因为执行层是有状态的我可以精确控制同时跑多少个任务、每个任务最多多少个工具并发、超时怎么算。实测下来并发从 10 提升到 50 时稳定性没有明显下降主要瓶颈变成了下游服务的承受能力。这里的关键是 Harness 把并发控制的逻辑集中化了而不是散落在各个工具里。4.2 三个让我印象深刻的坑第一个坑是上下文裁剪的时机。我以为定期裁剪就行结果发现裁剪太晚会造成 token 浪费裁剪太早会丢掉关键信息。后来我的方案是不按时间裁剪按事件裁剪——每次工具调用结束后把工具产生的长输出转为摘要只保留摘要和引用。这样做之后上下文长度非常稳定模型注意力也明显更集中。第二个坑是工具调用的超时处理。一开始我把超时值设成固定的结果有些慢查询任务频繁超时。后来我引入了动态超时根据历史耗时的分位数自动调整阈值并且区分预期长耗时和异常卡死两种情况。凡是工具声明自己的预估耗时范围Harness 就按声明来没有声明的才用默认阈值。第三个坑是最隐蔽的模型输出中的工具调用参数做 JSON 解析时经常会因为特殊字符、截断、格式漂移而失败。我踩过几次之后养成了两个习惯一是所有发给模型的结构化指令都附带一个严格的 JSON schema 示例二是解析失败时不直接让模型重来而是让 Harness 做一次修复——把残片和 schema 一起返给模型让它只输出修正后的 JSON。这一招把工具调用的成功率从 87% 拉到了 99% 以上。4.3 安全与权限Harness 最容易欠的债社区里搜 Agent 安全的人越来越多我猜大家也意识到这个问题了。Harness 在大模型系统里其实是放置安全能力的最佳位置——它拦截所有输入输出理应承担权限控制、数据脱敏、行为审计的职责。我在项目里的做法是为每个 Agent 运行实例分配一个最小权限身份工具调用前先做权限校验所有工具的输出在返回给模型前先过一道脱敏层把手机号、邮箱、身份证这类字段替换成掩码所有外部副作用操作比如发消息、删文件、转账都要求二次确认或走审批流。这套东西放在 Harness 层实现业务代码完全无感。坦白说安全这块是最难一蹴而就的但它也是最不该欠的技术债。Agent 一旦接入真实业务系统出事就是大事。5. Harness、RPA 与现有系统的融合思路5.1 从 RPA 到 Agent 的演进不是替换而是叠加最近热词里出现harness rpa落地实现说明很多人已经在做这件事了。我的观点是RPA 和 Agent 不是替代关系而是互补的关系。RPA 擅长稳定的规则型操作比如打开系统、填写表单、点击按钮Agent 擅长需要判断和适应的事情比如理解一封邮件的意图、决定回复策略、处理异常情况。把 Harness 作为中间层可以让 RPA 脚本变成 Agent 的工具。Agent 负责决策RPA 负责执行Harness 负责调度和监控。我做过的一个案例是Agent 读取客服工单判断问题类型如果是改地址这类标准化操作就调用 RPA 脚本去 CRM 系统里执行如果是需要人工判断的复杂问题就自动转人工并附上 Agent 的分析摘要。整个流程的编排用声明式配置RPA 脚本注册成工具即可。5.2 内网部署与插件体系的一点经验做 Agent 项目时很多人卡在内网部署和扩展能力上。基于常见实践我的建议是把 Harness 设计成插件式架构核心调度器只负责流程执行所有能力通过插件注册进来。这样做的好处是内网部署时你只需要把核心和必要插件打包新能力上线时只是新增一个插件不影响现有流程。插件体系我一般按三层划分基础插件比如文件读写、网页请求、数据库查询业务插件比如 CRM 操作、报表生成、消息推送AI 插件比如摘要生成、意图分类、向量检索。每一层插件都实现统一的接口Harness 通过接口调度不关心插件内部实现。关于内网部署有两点提醒一是模型服务的地址和鉴权配置要放在 Harness 的配置中心里不要在插件里硬编码二是插件之间的数据传递要严格走沙箱避免一个插件出错污染整个环境。我在项目里吃过一次亏某个插件在工作目录里写临时文件和另一个插件冲突了排查了半天后来统一改成沙箱目录才解决。5.3 独立 Agent 还是统一 Harness还有一个很容易让人纠结的问题是每个业务一个独立 Agent还是统一一个 Harness 加多个 Agent 配置我的建议是统一 Harness、多 Agent 配置。原因很简单Agent 的骨架——上下文管理、调度、恢复、安全——是完全通用的没有必要每建一个 Agent 就重写一遍。不同的业务通过不同的 skill 配置、工具集、提示词模板来区分。这也就解释了为什么社区里很多人专门搜harness工程之道这类内容——大家逐渐意识到Agent 的真正壁垒不在单点能力而在工程体系。谁把 Harness 做得更扎实谁的 Agent 就能更快落地、更稳运行、更容易扩展。好消息是这些能力是可以积累的每做一个项目Harness 就会厚一层。6. 如果从零开始搭我建议的优先级6.1 先搭状态管理再谈模型优化如果你正准备做一个 Agent 项目我的优先级建议是第一优先级是状态管理。没有可靠的状态管理后续一切优化都是沙上建塔。先把 session、任务状态、工具调用记录管好这是 Harness 的地基。第二优先级是工具生命周期管理。让每个工具调用都有状态、有超时、有重试这一步做完稳定性会有一个质的飞跃。第三优先级才是声明式调度。等你有了十几个工具、多个任务场景之后自然会感受到命令式编排的痛那时候再上 DAG 引擎水到渠成。别一上来就追求调度多花哨。很多团队第一步就栽在先写个优雅的调度器上结果调度器写了一千行业务一个没跑通。正确的姿势是用最小功能跑通一个真实任务然后逐步往 Harness 里加东西。我见过最成功的落地案例一开始就是一个脚本加一个 session 持久化三个月后才演化成完整的 Harness。6.2 模型选型与 API 兼容性的一笔账关于模型选型我多说两句。现在社区里既有 Claude 也有 DeepSeek还有各种开源模型可本地部署。我的经验是不要在模型层面只押一家而是让 Harness 层支持多模型切换。具体来说就是抽象出一个模型网关统一处理接口协议、鉴权、路由、降级。这样既可以利用各家模型的长处又能在某家服务不稳定时快速切换。这里有一个细节搜热点词的朋友可能也注意到了很多人会碰到类似模型服务连接失败或者模型路由不匹配之类的报错。这类问题大都是因为客户端直接把服务地址和模型名写死了。如果通过模型网关做一层适配配置中心统一管理路由规则这些问题就能从源头避免。多花半天做网关后面能省无数个半夜排查的时辰。6.3 给团队的三条建议最后给团队三个建议。第一Agent 项目一定安排一个专门的 Harness 负责人不要让每个人都改调度核心。权限收拢变更走评审否则很容易出现你改了我的状态字段我的恢复逻辑全崩了的惨剧。第二所有工具调用要有可观测性每一步的输入输出、耗时、成本都要记录。没有数据你就不知道瓶颈在哪、成本在哪、该优化什么。第三从第一个版本就考虑任务可恢复。哪怕只是简单的落盘加恢复也要有等出事再造就晚了。踩过几次坑之后我的体会是Agent 项目的天花板根本不取决于模型的单次推理能力而取决于 Harness 能托起多长的任务、扛住多大的并发、恢复得多快、扩展得多容易。这个护城河是工程化的是踏踏实实一砖一瓦砌出来的。如果你也在做 Agent不妨把一部分精力从催模型转移到搭架子上效果可能会出乎意料。