很多团队一谈到 Agent 工程，就会把 Skill、记忆文件、CLI、浏览器网关、评测集以及多 Agent 调度，一股脑都归进“Harness”这个概念里。名词不断膨胀带来的直接后果是：团队开会时都在讨论要补 Harness，真正落地时却不清楚究竟应该优先优化哪一层。
我越来越倾向于一个更聚焦、也更实用的定义：模型是引擎，提示词是方向盘，Harness 则是让车能够稳定行驶的变速箱、仪表盘和刹车；至于路面、加油站、地图服务这些外部能力，则属于 Agentic Infra。换句话说，Harness 解决的是“怎么开才不失控”，Infra 解决的是“路上有哪些资源可以调用”。
一、第一层壳：流程管控，专治不听指挥
在长任务执行过程中，最常见的失败原因往往不是模型突然变差了，而是状态发生漂移：它以为任务已经完成，但进度文件还停留在第二步；它反复修改同一处内容，真正卡住任务的依赖问题却始终没有处理。
流程管控层真正要做的，不是再补一段更长的 system prompt，而是把“当前目标、已完成事项、未完成事项、禁止操作”这些关键信息外置成可检查、可追踪的状态。这里的重点不在于格式有多精美，而在于 harness 能基于这些状态进行干预：超时无推进就暂停，偏离目标就收回工具权限，需要人工确认的动作不能由模型自行放行。
这一层还有一个常被忽略的原则：状态对人和对 Agent 最好保持同构。人看不懂的黑盒式记忆，一旦出问题往往只能重启；只有人能查看、能编辑、能回滚的进度状态，才真正具备人工干预能力。很多团队把记忆机制做成高维向量之后，反而失去了可操作性，故障发生时连“它以为自己完成到了哪一步”都说不明白。这并不是记忆系统太先进，而是流程控制这层壳做得太薄。
二、第二层壳：并发调度，专治集体低效
一旦引入多 Agent，团队通常很容易产生“效率会大幅提升”的预期。可在实际生产环境里，更常见的情况是：一堆角色都去修改最简单的文件，真正困难的问题却没人接手；或者大家彼此等待，最后形成一种看似礼貌、实则停滞的死锁状态。
调度层的核心并不是“多开几个角色”这么简单，而是要建立结构性的任务压力：谁负责规划、谁负责执行、谁负责验收，职责边界必须明确切开；任务包要带有难度和优先级，不能只靠模型自觉去挑最难的问题；共享工作区还需要清晰的所有权规则，避免互相覆盖之后双方都以为对方会负责收尾。
这里有一条很实用的判断标准：如果去掉某个 Agent，系统关键路径几乎没有变化，那它大概率不是真正的协同，只是在重复劳动。Harness 应该优先减少的是无效并发，而不是不断堆叠角色名称。还有一条更关键：没有所有权和验收接口的并行协作，本质上只是把单 Agent 的混乱复制了 N 份。
三、第三层壳：验证纠错，专治自我欺骗
这是我认为在生产环境中最不应该省掉的一层。因为当生成回路既充当选手又充当裁判时，分数可能看起来很好，最终交付结果却经不起复核。工程中的自我欺骗通常表现为：测试根本没跑却宣称通过，只改了注释却说重构完成，失败被简单归因成“环境问题”然后继续向下推进。
独立验证的最低配置其实很朴素：结果必须由另一套规则、另一个角色，或一次真实副作用检查来承接；失败之后要有回滚或重新开始的路径；“完成”必须是被判定出来的，而不是被模型生成出来的。
你可以把验证层理解成刹车系统。没有刹车的车不是不能开，而是你不敢开快，也不敢跑远。很多团队先堆 Skill 和各种工具，相当于先加大马力，却迟迟不安装刹车。更危险的是，用“让模型再 review 一遍自己的输出”来冒充验证——在同一先验、同一上下文下，它很难真正跳出自我确认的闭环。
四、和 Infra 怎么划边界
有一条我自己长期使用、也比较顺手的判断标准：
换了模型之后依然必须保留、并且直接决定“任务能不能稳定跑住”的，属于 Harness。换了模型之后可以整体替换、主要承担能力供给和资源支持的，更接近 Infra。
按照这个标准来看：像检查点、权限闸门、超时熔断、独立验收、避免空转的任务分配这类能力，更偏向 Harness；而模型网关、浏览器托管、向量库、特定 Skill 包、某家云函数这些能力，则更偏向 Infra。Skill 确实非常重要，但 Skill 更像是一套可以随时替换的工具箱；如果缺少验证机制与权限控制，那么 Skill 越多，整个系统的失控面反而可能越大。
边界清晰的最大好处，就是团队分工会更明确。负责 Infra 的人可以专注于更好的检索能力、更快的沙箱环境；负责 Harness 的人则盯住那些不变量：失败可恢复、动作可审计、完成可验证。两边如果都试图做成“大一统平台”，最后往往会变成什么都有一点，但没有任何一项真正守得住。
也可以从排障视角反向判断：线上系统出问题时，如果你第一反应是换模型、换 Skill，那问题大概率出在 Infra 或能力供给；如果你第一反应是“它为什么还能继续执行、是谁批准的、完成标准到底是什么”，那问题基本就在 Harness。
五、落地时怎么排优先级
如果资源只够先做一层，那么优先做验证纠错。因为它直接决定系统会不会在错误方向上持续加速。
如果能够做两层，就把流程管控补上。只有状态外置、任务可打断，长链路任务才真正具备可接手、可恢复的能力。
并发调度应当放在后面考虑。没有前两层做基础，多 Agent 只会把原本的混乱进一步并行放大。
也不要指望一次性设计出完美的 Harness。更现实、也更符合工程实践的路径是：先为一条高价值业务链路建立“可验证的完成定义”，再逐步补齐超时、权限、检查点，最后才考虑多角色协作。判断 Harness 是否成熟，不是看它接入了多少框架和流行名词，而是看你是否敢让它在无人值守的情况下，稳定跑完一个真实工作日。
还有一个很好用的自检问题是：如果关掉聊天窗口，只保留日志、任务进度和验收结果，你还能不能判断这次任务是成功还是失败？如果做不到，说明系统仍然停留在“会说话”的阶段，还没有真正进入“能交付”的阶段。
结语
当模型能力越来越趋于公共化之后，团队之间真正拉开差距的，往往不再只是模型本身，而更多体现在约束机制与验证能力上。Harness 并不是又一个需要盲目追逐的热门术语，它更像是在承认一个现实之后形成的工程化思路：模型会漂移，系统就必须能刹住、能接续、能证明自己做对了。与其继续引入一个新的大框架，不如先把三层壳与 Infra 的边界讲清楚，这反而更接近真正可落地的生产实践。
