人工智能领域从不缺少新名词，它们有时引领技术浪潮，有时则如过眼云烟。最近频繁出现的 “Harness” 就属于前一种：一边是大厂和社区密集发文，强调它在大规模 Agent 开发中的作用；另一边则是工程师的质疑，认为这不过是在旧实践上贴了个新标签。

争论背后，其实是同一个现实困境：模型越来越强，但在复杂、长周期任务上依然容易跑偏，时而急于收工，时而半途烂尾。Harness 这套说法，到底是在解决问题，还是在制造概念？

概念溯源：从 Test Harness 到 “Agent = Model + Harness”

单看 “Harness” 这个单词，它并不是一个凭空创造的新名词。在传统软件测试领域，早就有 Test Harness 的说法，用来指代那套为了支撑测试代码运行而搭建的框架：测试运行器、模拟环境、日志收集等都在其中。在模型评估社区，也有开源项目叫 lm-evaluation-harness，负责把各种评测数据集、指标和运行流程串在一起，为模型打分。

在 Agent 方向，去年 11 月，Anthropic 发布了《Effective Harnesses for Long-Running Agents》，专门讨论如何为长时间运行的 Agent 配置环境，让它尽量少出岔子。可见，Harness 这个词本身早就存在于工程实践中，只是一直相对低调，没有被当成需要大张旗鼓宣传的概念。

真正开始被反复提起的，是 “Harness Engineering” 这个组合词。

今年 2 月 5 号，一位工程师写下个人实践博文《My AI Adoption Journey》。作者坦言自己并不确定业界有没有统一叫法，索性先把这套做法叫作 Harness Engineering。核心思路很朴素：只要 Agent 在某个场景里犯了错，就去改系统，改上下文、改工具链、改规则，把这类错误从工程上“封死”，让它不再发生。 如果以后出现更合适的名字，再改口也不迟。

从传播效果看，这篇博文本身并没有引起特别大的轰动，但它把 “Harness Engineering” 这个词第一次摆到了台面上。

几天之后，也就是 2 月 11 号，一篇长文《Harness Engineering》发布，系统性地讲了如何围绕 Agent 设计 Harness，从上下文管理、验证反馈到技术债清理，信息量极大，很快在圈内引发了讨论。很多人也是从这篇文章开始，第一次认真思考“人掌舵、Agent 执行”这种新的分工方式。

再过 6 天，2 月 17 号，Martin Fowler 技术博客（martinfowler.com）刊出《Harness Engineering — First Thoughts》，相当于对这篇长文的第一反应。作者在文中留意到一个有趣的细节：那篇长文的标题虽然高举 Harness Engineering，但正文里 “Harness” 这个词只出现了一次。于是，她推测标题很可能受到了 2 月 5 号那篇《My AI Adoption Journey》的影响，是一个事后加上的概念包装。

到了 3 月 10 号，LangChain 发布《The Anatomy of an Agent Harness》，给了 Harness 一个极简的公式：Agent = Model + Harness。意思是说，一个完整的 Agent，可以被拆解为底层模型和包在外面的那一层 Harness；反过来理解，Harness = Agent − Model，也就是除模型本身之外的所有系统部件。

紧接着，在 3 月 24 号，Anthropic 又发布《Harness Design for Long-Running Application Development》，在长运行工作的基础上，给出了后来被广泛引用的 三 Agent 架构：Planner、Generator 和 Evaluator。再往前追溯，这篇文章可以看作《Effective Harnesses for Long-Running Agents》的续作：前者专注于让 Agent 能跑得久，后者则在此基础上，把 Planner / Generator / Evaluator 这套结构定了调。

从 Test Harness、lm-evaluation-harness，到《Effective Harnesses for Long-Running Agents》，再到 2 月以来一连串的《My AI Adoption Journey》《Harness Engineering》《Harness Engineering — First Thoughts》《The Anatomy of an Agent Harness》和三 Agent 架构，Harness 这个词完成了一次从“默默使用”到“被正式命名、抽象和系统化”的演变。 它不再只是零散工具和零碎实践的统称，而是一整套围绕模型搭建系统的工程视角。

三 Agent 架构：先对齐标准，再执行，再评估

要理解 Harness 的工程价值，很难绕开一个核心实践：Planner / Generator / Evaluator 三 Agent 架构。它试图回答一个具体问题：当我们把一个长而复杂的需求交给 Agent 时，怎么避免它半路迷失方向，或者草草收工？

这套架构最早来自一个看似简单但工作量巨大的实验：让 Agent 去“克隆”一个复杂的在线应用。起初的做法，是让单一 Agent 直接接收需求，然后一口气开干。结果可想而知：

• 需求过大，Agent 倾向于急于求成，想一次性把所有功能做完；
• 上下文很快被塞满，重要信息被淹没；
• 某个 Agent 干到一半就“弃坑”，下一个接手时对前情一无所知，只能凭感觉判断“好像差不多了”，然后贸然宣布完成。

为了扭转这种局面，文章里一步步把原本单一的 Agent 拆成了三个角色。

首先是 Planner。 它负责把用户模糊、宏观的需求，拆解成清晰、具体的功能列表，并沉淀为一份可以机读的规划文档。这个规划里不只有要做哪些功能，还包括大致的优先级和里程碑。后续所有 Agent 的工作，都是在 Planner 产出的这个“蓝图”上展开。

然后是 Generator。 它是具体的执行者，拿着 Planner 的功能列表，一次只选取一个功能点来做。这里有一个非常关键的节奏：在正式开工前，Generator 不会直接写代码，而是先去找 Evaluator 对齐交付标准。

两者之间大致会经历这样一个过程：

• Generator 提出自己对“完成”的理解，例如“这一功能需要哪些接口、需要覆盖哪些边界情况”；
• Evaluator 根据经验和规范提出补充或收紧的意见，例如“必须包含单元测试”“日志需要满足某些约束”；
• 双方反复几轮，直到 Evaluator 认为交付标准足够明确、可验证。

这一步，就是典型的 Harness 设计：先对齐标准，再开始执行。

标准对齐后，Generator 才开始针对当前功能点生成代码、配置或文档。完成后，它会把产出提交给 Evaluator。Evaluator 作为一个独立的第三方，并不参与生成过程本身，而是根据刚刚对齐好的标准，执行一整套验证流程：

• 运行 linter、测试用例，检查是否违反架构和编码规范；
• 比对规划，确认功能是否真正实现，而不是“纸面通过”；
• 记录失败原因，并形成结构化反馈。

如果 Evaluator 判定不合格，它不会“替对方写代码”，而是把具体问题原样反馈给 Generator，由后者自行修改，再次提交。这个 “执行 — 评估 — 修正 — 再评估” 的循环会持续进行，直到某一次所有检查全部通过，对应的功能点才算真正完成。

在这个过程中，还有一个细节值得注意：为了防止 Generator 再次急于求成，早期的提示词里会明确要求它“每次只做一个功能点，做完一个再做下一个”。 这本身也是一种 Harness 约束。代价是整体耗时和花费明显上升，但换来的是任务可控性的大幅提高。

当所有功能点依次走完这套节奏，整条产品链路也就完成了。相较于一开始的单 Agent 方案，三 Agent 架构被称为 Full Harness 方案：

• 质量上，从“几乎没法用”提升到“达到可用水准”；
• 成本上，时间和费用都高了一个量级。

这是一种很典型的工程权衡：为了避免长任务跑偏，把一个大请求拆成一系列小目标，用 Planner 对齐方向，用 Generator 专注执行，用 Evaluator 做独立验收，再通过强制分步和验收闭环把节奏慢下来、稳下来。

争议与前瞻：新瓶装旧酒，还是过渡期的关键答案？

回顾这段发展轨迹，很容易理解为何有人把 Harness Engineering 视为噱头。

一方面，技术上几乎没有“新东西”。无论是任务拆解、自动化测试，还是代码规范检查、技术债清理，在传统软件工程里都早已是成熟做法。现在不过是换了对象：从人写的确定性程序，变成了大模型驱动的非确定性 Agent。对很多工程师来说，这看起来像是一次“新瓶装旧酒”的概念重组。

另一方面，成本也的确不低。以三 Agent 架构为例，同样的需求下，单 Agent 的 Solo 方案二十分钟左右就能跑完，Full Harness 则可能需要数小时、数十倍的费用。对于预算有限、对质量要求不高的场景，这样的投入未必划算。

更尖锐的质疑来自未来视角：随着模型自身能力的持续增强，今天看起来必不可少的这些 Harness 设计，会不会被模型一点点“吃掉”？

不妨看两个具体的例子，它们已在回答这个问题。

第一个例子是 “上下文焦虑”。在 Sonnet 4.5 上，团队观察到一个很具体的现象：当上下文变得很长时，模型倾向于尽快结束任务，用更少的 token 草草交付，结果是长任务的质量明显下降。最初的解决方式，是一种典型的 Harness 手段——“上下文重置”：

• 当对话拉得很长时，系统主动在中途“清场”，开启新的会话；
• 只把必要的信息做成摘要带过去；
• 通过重置，避免上下文越滚越大，把模型推向“求快不求好”的状态。

这是一个非常工程化的补丁。然而，当模型升级到更强的 Opus 4.5 后，这种上下文焦虑现象被大幅缓解，对应的上下文重置策略也变得不那么必要了。同一个问题，从 Harness 层的“结构性补丁”，变成了模型层能力提高后的“自然消失”。

第二个例子来自前文的三 Agent 架构。早期，为了避免 Generator 再次急于求成，团队在提示词里强制它“每次只选取一个功能点，做完一个再做下一个”，并要求 Evaluator 按功能点逐个验收。这是解决长任务执行质量问题的关键 Harness 设计之一。

但在后续迭代中，当 Generator 换用更强的 Opus 4.6 后，这道“强制分步执行”的护栏被拿掉了：

• Generator 可以一次性拿到所有功能点，自行安排先后顺序；
• 依然能够稳步推进，不再那么容易乱跑；
• Evaluator 也可以更多地聚焦于对整体产出的评估，而不是对每一个小步骤逐一过筛。

从这两个例子可以清楚地看到一个趋势：模型越强，需要的 Harness 就越少。 很多原先用工程手段兜底的问题，会在新一代模型上自然消退，相应的 Harness 结构也会被压缩、合并甚至完全删除。

不过，Harness 的命运并不是“被彻底淘汰”，而是 “最小化与变形”。

更进一步的观点是：随着模型变强，Harness 的形态也会跟着进化，去解锁更复杂的任务；它不会消失，而是从厚重的管控系统，逐渐演变为：

• 一层轻量的接口层，负责把模型和外部世界（工具、API、文件系统）连接起来；
• 一道坚固的安全底线，负责权限控制、数据约束和最终验收，为模型行为划定“红线”。

站在这个角度看，Harness Engineering 既不是纯粹的噱头，也大概率不是终点。 它更像是强模型时代的一项过渡期关键技术：在模型能力尚不完美的几年里，用工程手段把风险压下去、把质量拉上来，同时为未来更强的模型打好“连接世界”的基础设施。

给读者的一个小建议

回到今天，模型依然会犯错，依然会幻觉，依然会在复杂任务中偏离轨道。在这种现实下，谁能把 Harness 搭得更稳，谁就更有机会把 AI 的潜力转化为真正的生产力。

与其纠结概念本身是不是“新瓶装旧酒”，不如从手边的一件小事做起。例如，选一个边界清晰的任务：自动生成周报、整理日志、生成某个固定模板的文档等。尝试做几件事：

• 想清楚这个任务的目标是什么，什么结果才算“完成得好”；
• 给模型准备好必要的上下文和工具，而不是把一切信息一股脑丢进去；
• 在任务前就约定好验收标准，并用尽量自动化的方式去验证产出。

当你习惯了这种“先对齐标准—再执行—再评估”的节奏，就已经在不知不觉中练习 Harness 思维了。那时，争论 Harness 是否是噱头这件事，本身也许就不再那么重要——重要的是，你是否真的用它，让模型在你的系统里，跑得更稳、更久，也更有价值。