Agent Harness工程：复杂规划为何常是多余且脆弱的

上周我把某个内部批量文档服务从“会规划的Agent”重构成了“基本不会规划的Harness”效果反直觉到我自己都有点吃惊延迟从平均30秒左右降到2秒上下Token成本只剩原来的十分之一线上还更稳了。这逼我重新想清楚了一个问题——AI Agent Harness Engineering 到底需要什么样的规划能力答案可能和大多数人的直觉相反至少有两类场景复杂规划不仅多余而且恰恰是整个系统里最脆弱的环节。如果你正在搭Agent的编排层、工具层、护栏层或者正被“Agent必须会自主规划”这种默认观念折腾得焦头烂额这篇文章应该能给你一个撤退路线。我尽量不堆概念只讲实际工程里怎么判断、怎么拆、怎么落地。1. Harness 是脚手架不是大脑先把概念摆正1.1 Harness Engineering 到底管什么很多人一聊Agent就盯着“模型规划能力”比如要不要ReAct、要不要Plan-and-Execute、要不要让模型自己拆子任务。但真把系统跑到线上决定生死的往往是外围那层东西工具怎么接入、权限怎么控制、上下文怎么组装、步骤怎么编排、结果怎么校验、失败怎么重试、日志怎么串起来。这一层就是Harness。我理解的Harness Engineering不是教模型“怎么想”而是给模型搭一个跑不偏的“赛道”哪些工具能碰、哪些参数能传、每步有什么前置条件、输出必须满足什么Schema、超时多少秒、最多重试几次、中途怎么暂停和恢复。打个比方演员的演技是核心但剧组的舞台、灯光、提词器、安全绳才是决定一场演出能不能稳定复演的东西。Harness就是那套舞台设施。规划能力只是演员的一部分素质不是系统稳定性的全部来源。1.2 “规划崇拜”是怎么来的又是怎么误导我的我早期做Harness的时候也踩过一个很典型的坑看到框架Demo里都是“让Agent自主完成复杂任务”就觉得“能规划”才是Agent的标配。于是做一个内部批量文档转HTML的小服务我也给它套了一个ReAct风格的循环让模型先“思考”要不要转换、转换格式对不对、布局要不要调整再决定调用哪个工具。结果问题一大堆。单文档延迟从秒级涨到几十秒Token烧得飞快最离谱的是模型在“规划”中自己脑补了一个步骤——“把docx转成pdf再转成HTML”执行器老老实实照做最后把用户的原始文件结构改了。那个版本上线不到一周就被我撤下来重写。后来我才想明白不是所有任务都需要“生成新方案”很多任务本质上是“执行一套已经写清楚的标准作业流程”。这时候硬塞给一个擅长开放式幻想的模型反而引入了不确定性。Harness的价值不是放大模型的聪明而是缩小模型犯错的机会。1.3 一句话概括反直觉结论在规则边界清晰、反馈闭环快的任务里用有限状态机、决策树、规则引擎和确定性校验器去搭Harness比让LLM做复杂规划更高效、更便宜、更容易调试。这句话只适用于特定场景不是全称命题。下面我把这两类场景的特征和判断方法展开讲。2. 两类真正不需要规划的任务规则边界清晰与高频小决策2.1 场景A规则边界清晰的确定性流程任务这类任务的典型特征是输入模式有限规则可以穷尽每个步骤都有明确前置条件和预期输出失败了可以安全重试甚至回滚单步错误的影响范围是局部的不会把后面的步骤全带偏。我在模拟项目X里做的批量文档转HTML服务就是典型代表。系统只面向内部几个已知格式docx、pdf、md、html来源是受信任的上传通道大小有上限格式映射规则固定。这种任务完全不需要模型“发明”流程只需要一个能稳定走完的流水线。同类例子非常多批量文件格式转换、压缩、重命名定时数据抓取、字段校验、告警路由工单按来源/类型/紧急度自动分类日志聚合后的规则清洗和字段补齐参数化脚本按既有模板批量执行这些任务如果交给LLM规划模型能做但属于杀鸡用牛刀而且牛刀还会偶尔砍偏。它们真正需要的是一个“作业指导书执行器”不是“作业指导书发明器”。2.2 场景B高频小决策的窄操作任务第二类特征是决策数量多但每个决策都非常小正确性有客观标准不太依赖“品味”执行过程允许中断、重试、回退因为调用频率高所以对延迟和单次成本特别敏感。举个例子客服Tier-1初筛一封邮件进来第一步判断是不是退信第二步判断是不是投诉第三步判断涉及哪个产品线第四步套用对应回复模板。每一步都是标准判断没有哪个步骤需要写一篇小作文式的“深度思考”。再比如邮件分拣与模板回复API调用失败后的错误分类与重试策略选择自动化的信息检索与格式化汇总FAQ意图匹配和标准答案返回简单审核流程的流转规则这类任务的决策频率极高如果每一步都让LLM从一个开放空间里“规划”出答案成本会线性放大。更重要的是高频场景下用户能容忍的延迟极低规则判断是微秒到毫秒级LLM单次推理是秒级差两到三个数量级。2.3 决策复杂还是调度复杂一个关键判断我后来形成了一条很简单的判断准则问自己“这个任务的SOP能不能用‘如果-那么’或固定步骤列表写清楚”。如果能那它是调度复杂不是决策复杂。调度复杂的难点在于“几十个条件分支和步骤怎么稳定、可预期地串起来”解决方案是状态机、规则引擎、工作流编排而不是让LLM现场生成一套计划。如果一开始写不清楚SOP或者输入空间大到无法枚举那才可能是决策复杂才需要考虑让模型参与规划。为什么这个区分很关键因为“无法枚举”和“规则很多”是两码事。规则很多可以通过表格、决策树、规则文件管理无法枚举才需要靠模型的泛化能力硬顶。很多人就是把“规则很多”误判成“需要智能”然后启动了昂贵的规划引擎。3. 复杂规划放在这两类场景代价不只是慢3.1 延迟和Token开销只是冰山一角先算一笔体验过的账。规则引擎里一次分支判断大概1到10毫秒LLM单次决策按现在主流模型算普遍要1到3秒。一个原本需要6次判断的任务在ReAct循环里可能触发5到15次模型调用端到端延迟轻松破30秒。Token方面更明显。“规划”“反思”“验证中间结果”都会产生大量冗余输出这些输出不直接产生用户价值却照样计费。批量任务还会把成本问题放大到月度账单上。最坑的是LLM生成式规划的结果无法缓存同一类任务每次都要重新推理而规则引擎的执行路径是编译后的代码可以反复走零边际成本。3.2 状态漂移计划一旦脱离事实执行越努力越偏比延迟和成本更隐蔽的代价是“状态漂移”。规划类Agent通常会先让LLM读一下任务描述生成一个计划然后执行器拿着计划去跑工具。可问题是计划生成那一刻对世界的“假设”可能已经和下一步执行时的真实状态不一致。我遇到过的典型翻车场景LLM规划里写了“先转换docx再转PDF”但实际文件在验证阶段已经被系统自动转成HTML了执行器忠实执行旧计划重新转换后把原文件覆盖。还有一次计划假设某个共享目录存在备份但备份在计划生成后被清理任务删了后续所有步骤都基于一个已经失效的假设运行。这就是“拿着错误的计划越走越远”。规则型Harness没有这个问题因为每个节点都会对当前输入做校验前置条件不满足就直接失败宁可快速失败也不要带着幻觉往前冲。3.3 黑箱调试失败链路越长定位越像猜谜复杂规划Agent还有一个让我极其头疼的地方调试像猜谜。计划层、工具层、状态层、输出层各自独立一个任务失败我得先判断是“模型想错了”“工具参数传错了”还是“上下文没拼对”。更麻烦的是LLM每次输出都不一样同一个错误很难稳定复现回归测试经常莫名其妙挂掉。我印象很深的一次一个任务在第五步报错我查了三小时最后发现是第二步模型输出的一个“过度谨慎”的额外校验步骤把文件名过滤掉了。这种问题在规则型Harness里根本不会出现因为每步行为都写在代码里跑一遍日志就知道谁动了文件名。3.4 一张表看清规则 Harness 和规划 Agent 的差别维度规则型 HarnessLLM 规划 Agent单步决策延迟毫秒级秒级端到端耗时确定、可估算随决策链长度膨胀Token消耗几乎为零规划反思重试叠加状态可预测性每一步由代码保证计划可能和事实脱节可调试性单步看日志即可计划/执行/工具多层交叉回归测试稳定性同一输入同一结果同一输入可能不同输出失败恢复节点级重试快速失败可能要重规划整个链路这张表不是否定LLM规划的价值而是想说在规则边界清晰的场景里用LLM规划相当于把已经修好的高速路拆了换越野车去跑。越野车确实有它的用武之地但那是下一个章节的事。4. 规则为主干、LLM为叶子的 Harness 长什么样4.1 最小闭环批量文档转HTML服务怎么拆现在拿我重构过的模拟项目X当例子。这个服务的需求是内部团队上传文档系统转成统一HTML页面并自动生成摘要和标题优化。我先定义了严格的输入契约扩展名白名单docx、pdf、md、html中的一种单文件大小限制50MB以内上传来源白名单只接受内部固定系统通道格式不对、大小超限、来源异常一律直接拒绝不走LLM然后设计了一个最小状态机每个任务从WAITING开始进入VALIDATING做契约校验通过后进入CONVERTING执行转换最后落到DONE或FAILED。转换环节内部还有一个重试子状态失败按指数退避重试最多三遍。关键不是状态机本身有多深而是每一步都有清晰的前置条件和输出校验。VALIDATING没通过的任务根本到不了下一步FAILED任务会留下完整日志方便事后定位。4.2 四层分层把LLM关进笼子里这个服务的整体架构分四层每层解决一类问题Layer1 路由层纯规则根据扩展名、MIME、字段合法性和来源白名单判断任务走哪条处理通道。Layer2 执行层纯规则文件解析、HTML模板套用、样式注入、图片尺寸调整、代码块高亮全部用固定逻辑处理。Layer3 生成层LLM受限使用只保留两件事——生成摘要和优化标题。这是整个服务里唯一需要“理解语义、组织语言”的地方。Layer4 校验层纯规则对LLM输出做JSON Schema校验、长度检查、链接可访问性检查不合格就有限重试重试失效则任务失败。所谓“把LLM关进笼子里”不是靠提示词里写“请只输出JSON”而是靠代码层强约束解析失败就重试重试还失败就拒绝整个输出外部还有超时和配额模型就算想“自由发挥”也没有舞台。4.3 LLM 生成层的具体约束方式我给LLM的输入是一个高度模板化的few-shot prompt输出被限定成一个固定JSON结构{ title: 不超过100字的优化标题, summary: 不超过512字的内容摘要, keywords: [3到5个关键词] }生成之后代码层立刻做三步校验是否能解析成合法JSON、字段是否齐全、长度是否越界。任何一步失败就让模型重跑一次最多三次三次都失败任务进入FAILED状态并告警。这种方式的价值是LLM的“语言创造力”被用在唯一需要它的地方其余所有流程都保持100%确定性。我实测下来LLM负责的部分输出偶尔不稳定但只要校验器把关严格它最多浪费几次重试不会污染整个任务链路。4.4 护栏和可观测性规则型系统被低估的两项红利很多人以为护栏靠“模型自我约束”我觉得这是伪命题。模型只会按概率生成文本不会“记住”你不能越界。真正的护栏是外部逻辑白名单、Schema、超时、配额、自定义校验器全部由代码强制执行。规则型Harness在护栏上有一个天然优势你可以在任意节点插入校验逻辑不需要等模型“自觉”。比如检查LLM输出是否引用了不在白名单里的工具检查某个步骤是否超过配额甚至检查结果里是否包含危险代码片段。这些在规则框架里都是透明的代码不是概率行为。可观测性同样是被低估的红利。规则型系统每个节点都可以打日志、记录耗时、记录输入输出摘要出现问题时可以单步断点重放。我以前排查一个复杂规划Agent的问题要翻好几个模型调用链现在看规则管线基本扫一眼trace就知道哪一步挂了。5. 什么时候才轮到复杂规划以及怎么优雅升级5.1 开放域和长链路任务复杂规划真正的主场说了这么多规则的好话也得给复杂规划说句公道话。有些任务确实是它唯一能打的地方。典型特征是目标开放没有标准答案需要从多个未知数据源里自行发现路径任务和任务之间有长期依赖需要记忆主目标用户意图模糊需要多轮澄清错误成本高但输入空间大到无法预设SOP。比如一个研究型助手要帮用户从多个数据源里整理某个行业的变化趋势用户自己都说不清楚到底要看什么需要模型自己提假设、自己换路径、自己决定要不要深挖某个方向。这种任务用规则树硬写写出来的覆盖范围一定漏。所以我的立场不是“永远不用复杂规划”而是“复杂规划是稀缺资源要放在只有它能解决的问题上”。5.2 用监控指标说话不拍脑袋升级要不要给某个模块升级成复杂规划我用几个指标当决策依据失败率规则Pipeline因为“输入无法覆盖”而失败的占比人工介入率需要人工修补的比例平均决策延迟单任务从进来到出去花了多久单任务Token成本LLM在链路上消耗的Token总量如果失败率和人工介入率一直很低说明规则覆盖是够用的没必要为了“看起来智能”而升级。如果失败率连续几周升高且主要集中在“输入空间超出预设规则”这一类那才说明规则边界确实需要让位给更灵活的模型判断。最怕的是没有数据支撑纯粹因为“别人都在用规划Agent”而跟风升级。我踩过的坑告诉我先让监控指标暴露真实瓶颈再决定把哪个节点换成智能判断比整体推翻重来靠谱得多。5.3 先规则后规划复杂系统的降级逃生通道即使未来真的需要引入复杂规划我建议也不要一步到位全量替换。更稳的路是“先规则后规划”让规则当主干把LLM放在“灰区决策”的位置上。具体做法是当规则判断不了某条输入时不要直接失败而是把这条输入送到LLM做一次“灰区处理”LLM给出候选处理方案再回到校验器检查能过就走不能过才失败。这样原本的确定性流程没有被推翻只是增加了一条智能旁路。我管这个叫“逃生通道”。它的好处是新输入可以被处理但处理结果仍然受旧护栏约束一旦发现LLM在这个灰区里质量不稳可以随时把通道关掉退回纯规则模式。整个系统有清晰的降级路径不会因为一个模块升级失控把全站拖垮。最后再聊一点个人体会这几年我最大的体感是“先让系统简单到不可能失败再让它聪明”。Harness Engineering 的职责不是给模型尽可能大的自由而是给它一个怎么折腾都不会翻车的边界。复杂规划能力当然有价值但它是一种高成本、高不确定性的资源应该用在规则真的兜不住的地方而不是成为所有Agent系统的默认配置。如果你正打算给某个批量服务加“智能规划”我建议先从规则树开始给每个分支装上日志让数据告诉你哪里真的需要智能再把LLM放进去一次只放一个点。这样你反而能更快做出一个可靠得多的Agent系统。