harness革命：AI工程中的约束系统，是必需品还是过渡方案？

自2026年初以来，“harness engineering”这个概念以病毒般的速度席卷了整个AI工程领域。Mitchell Hashimoto为它命名，OpenAI通过一个百万行代码零手写的项目为它做了最佳广告，Stripe则以每周处理1300个AI拉取请求的实践为其背书。一时间，行业中似乎形成了一种共识：不讨论harness，就不配称为真正的AI工程师。

然而，当最初的狂热逐渐退去，一些根本性问题值得我们冷静审视。

harness究竟是什么？

“Harness”一词源自马术装备——缰绳、马鞍、嚼子——即一套用于引导强壮却不可预测的马匹走向正确方向的全套器具。在AI智能体语境中，harness就是包裹在模型外部的一系列基础设施，包括约束机制、反馈循环、文档体系、工具编排以及人工审批流程等。

模型是马，人是骑手，harness就是缰绳与辔头。没有harness约束的智能体，如同一匹在旷野上肆意奔驰的纯血马——速度惊人，姿态优雅，却难以产生任何实际价值。

这个词的中文翻译也面临挑战。“约束工程”定义过窄，因为harness的功能不仅是限制，还包括引导和赋能。“驾驭工程”在语义上较为接近，但仍存在微妙偏差——harness本质是装备（名词），而“驾驭”是一个动作（动词）。因此，中文技术圈目前基本直接沿用英文术语，仅在首次出现时附加括号说明。

有哪些真实的落地案例？

将现有案例按成熟度排序，可以清晰地看到实践路径：

Stripe Minions 是目前最为扎实的生产级应用。他们的Minions是完全自主的编码智能体，每周合并超过1300个拉取请求，且无需人工手写一行代码。其harness是一个五层管道，从Slack消息处理一直延伸到生产级PR的生成。每个Minion运行在隔离的devbox环境中，拥有完整的Shell权限，但无法触及生产系统。其智能体harness深度分叉自Block开源的Goose项目，并针对无人值守场景进行了大量改造。最关键的是，它连接了Stripe内部的集中式工具服务器，暴露了近500个工具，不同智能体按需请求工具子集。

OpenAI内部Codex项目 是“harness工程”这一术语的起源。仅凭3名工程师，在5个月内完成了百万行代码的项目，全程零手写。他们的核心洞见是：庞大的AGENTS.md文件不能当作百科全书使用。大文件会挤占宝贵的上下文窗口、内容会快速过时、且难以进行机械化验证。因此，他们将AGENTS.md缩减至约100行，仅作为“目录”使用，真正的知识库则存放在结构化的docs/目录中。

Anthropic 完成了两项引人注目的实践。一是利用16个智能体从零开始编写了一个能够编译Linux内核的C语言编译器，共计10万行Rust代码，消耗了约两万美元的API费用。其二是在近期发表的一篇文章中，他们将生成对抗网络（GAN）的思路引入harness设计——生成器负责编写代码，评估器则通过实际操作应用来打分，这种职责分离有效解决了“智能体为自己的作品打高分”的问题。

LangChain DeepAgents 是开源社区中最具系统性的实践。他们通过纯粹的harness优化，在不更换模型的情况下，将Terminal Bench 2.0的得分从52.8%提升至66.5%，排名从30名开外一跃进入前五。

一个有趣的观察是，尽管这些项目的规模与风险承受能力差异巨大，但它们却得出了高度相似的结论。

harness的八大核心组件

梳理成功实践，一个完整的harness系统大致需要包含以下组件：

上下文工程 —— 不仅仅是“写好文档”，而是设计一套上下文注入策略：决定在何时、以何种方式将信息注入模型的上下文窗口。OpenAI采用了三级架构：全局AGENTS.md（始终加载、极其简短、作为目录使用）→ 目录级规则文件（根据智能体工作位置自动加载）→ skill/docs/目录下的内容（按需延迟加载）。

测试驱动开发与静态分析 —— 确保智能体的每次修改都能被机械化验证。但这里有一个关键细节：测试本身必须为智能体设计，而非人类。测试harness不能输出数千行无用信息，以免污染上下文窗口。

可观测性集成 —— 整合开放遥测、日志系统与仪表板访问权限，使智能体能够“看见”系统的运行时状态信息。

架构约束强制执行 —— 使用ArchUnit、depguard等工具机械化地强制分层规则，而不是在文档中简单写下“不要违反分层架构”的标语。

执行环境隔离 —— 沙盒是所有其他约束层的物理保障。没有它，上层约束都只是“君子协定”。Stripe为每个Minion分配一个一次性的开发环境，任务完成后立即销毁。

工具集的精准裁剪 —— 并非将所有可用工具都暴露给智能体。Vercel的实践表明，在砍掉80%的工具后，智能体的表现反而更佳。工具过多意味着决策空间过大，智能体更容易做出错误选择。

重试与升级策略 —— 当智能体任务卡住时如何处理？Stripe的设计是：CI流程失败最多重试两次，第三次则直接标记为需要人工介入。LangChain则开发了循环检测中间件，用于识别并跳出死循环。

熵值治理机制 —— 智能体生成的代码会以不同于人类的方式积累技术债务。需要定期运行“垃圾回收”智能体，来扫描文档漂移、命名不一致以及死代码堆积等问题。

关于AGENTS.md的重要教训

OpenAI曾尝试过“一个庞大的AGENTS.md文件”方案，但以失败告终。原因非常直观：上下文窗口是稀缺资源，大文件会挤占任务描述和代码本身的空间；当所有内容都被标记为“重要”时，实际上没有任何内容是真正重要的；单体文件最终会腐烂成过时规则的坟场。

苏黎世联邦理工学院最近的研究也发现，由大语言模型生成的AGENTS.md文件对任务成功率有轻微的负面影响。智能体确实会遵循指令——因此会运行更多测试、阅读更多文件、执行更多搜索——但这些行为对于解决具体任务而言往往并非必要。

Stripe的做法更进一步——他们采用目录级规则文件，智能体在遍历文件系统时会根据所在目录自动加载相应的上下文内容。他们还兼容了Cursor的规则文件格式，从而在Minions、Cursor和Claude Code三套智能体系统之间实现同步。

因此，核心原则是：AGENTS.md文件越简短越好，只应包含智能体不可能自行推断出的关键信息。

AI编码是否需要测试驱动开发？

围绕这个问题存在讨论，但结论并不统一。

支持测试驱动开发的核心论点是：如果让智能体同时编写代码和测试，它倾向于编写“同义反复”的测试——这些测试只验证“代码实际做了什么”，而非“代码应该做什么”。让测试先行于实现，就切断了这条作弊路径。

然而，一项反直觉的实验发现被记录在TDAD论文中。单纯地给予智能体“先写测试再实现”的指令，不仅没有减少回归错误，反而将回归率从6.08%提高到了9.94%——效果比不提供任何指令更差。原因是：智能体并不需要被告知“如何进行测试驱动开发”，它需要知道的是“应该检查哪些测试”。测试驱动开发的流程本身对智能体并非关键，关键在于基于依赖关系感知的测试选择。

回顾主流的关于harness的论述，几乎没有人明确提到测试驱动开发。OpenAI的做法是“设置最少的阻塞性合并关卡，保持较短的拉取请求生命周期，测试的偶发性失败通过后续运行来解决”——这与测试驱动开发“先写测试再实现”的理念完全相反。Stripe也类似——智能体编写代码后运行测试，若持续集成失败则重试两次，第三次则请求人工介入。

实际做法大致可分为三种流派：

人类编写测试，智能体实现功能 —— 这是最受推荐的方式，测试作为刚性合约存在，但本质上是将“定义何为正确”这一最具挑战性的工作留给了人类。

快速反馈循环 —— OpenAI和Stripe所采用的方法，不追求“一次成功”，而追求“快速收敛到正确结果”。

提供测试驱动开发的上下文，而非流程 —— 不告诉智能体“先写测试再写代码”，而是为其提供一张依赖关系图，使其明确知晓“修改会影响哪些测试”。

因此，结论是：harness系统无需强制推行测试驱动开发的流程，但必须强制执行两件事——测试应由人类（或独立的智能体）作为规范提供，以及智能体必须具备定位并运行影响范围内的测试的能力。

Stripe的三百万项测试

Stripe的持续集成体系并非仅由单元测试构成。他们建立了一个三层反馈体系：第一层是本地代码检查工具（5秒内完成），第二层是选择性持续集成（从三百万项测试中选取与改动文件相关的部分运行），第三层是务实的上限机制（失败后返回给智能体修复，最多两轮）。

三百万项测试，如此庞大的规模不可能全部是单元测试。但单元测试确实是其中的主体——只有这种粒度的测试才能支持选择性持续集成和秒级反馈。

那么，Stripe是否拥有单元测试？答案是肯定的，并且有确凿证据。早在2015年，他们就公开撰文介绍“如何在三分钟内运行完三小时的Ruby测试”，当时已拥有一万五千个测试用例。他们后来开发了Sorbet（Ruby的渐进式类型系统），其诞生的原因之一便是“Ruby作为动态类型语言，某些错误只能通过运行单元测试来发现”。

但为何关于harness的文章很少提及“AI编写单元测试”？ 因为对Stripe而言，测试并非智能体的产出物，而是智能体的约束条件。三百万项测试是十年间人类工程师积累的宝贵资产，是harness系统的一部分，而非智能体需要交付的内容。让智能体同时编写代码和测试，又会回到“同义反复测试”的问题上。

Anthropic的生成对抗网络式harness

Anthropic在近期发表了一篇重要文章，其核心贡献在于将生成对抗网络中生成器与判别器分离的思路，应用到了智能体harness的设计中。

他们识别出两个关键的失败模式：一是上下文退化，特定模型在长上下文中会出现“上下文焦虑”并过早结束任务；二是自我评价失真，智能体在评价自己的作品时会自信地给出高分，即使质量明显一般。

解决方案是构建一个三智能体架构：规划者（将简短提示扩展为完整的产品规格）、生成器（按照迭代计划逐个实现功能）、评估器（通过实际操作应用来打分）。在每个迭代开始前，评估器与生成器还需协商一份迭代契约——明确“什么算作完成”需要在编写代码前达成一致。

效果是显著的。对于同一个提示（创建一个2D复古游戏编辑器），单一智能体在20分钟内完成但核心功能无法运行，而采用新架构的智能体耗时一小时，产出的却是一个真正可玩的应用程序。

最有趣的部分是harness设计随模型能力的进化而简化。在新模型发布后，迭代分解的步骤被移除了（因为模型能够连续工作两个多小时而不偏离轨道），上下文重置也不再需要。然而，评估器在模型能力的边界上仍然至关重要。

文章作者最后总结了一句精辟的话：“有趣的harness组合空间不会随着模型能力的提升而缩小，它只会发生位移。”

buffa：Anthropic的内部harness实践

Anthropic还有一个不太引人注目但极具说服力的案例——buffa，一个用Rust实现的protobuf库。该项目在六周内完成，大部分工作由Claude Opus完成，并且已在Anthropic的生产环境中运行。

该项目通过了谷歌的protobuf一致性测试套件，但作者明确指出：通过一致性测试是必要条件，但远不充分。他列举了几个规范盲区的例子——例如，在oneof结构中处理封闭式枚举的方式，规范根本没有定义，一致性测试也不覆盖。

最重要的harness洞察是：Claude在发现这类规范缺口方面表现出色，但只有在被明确提示“将规范、测试与代码进行对比，寻找相对于标准实现的差距”时，才会触发这种行为。

这个项目证明了一件事——harness不一定是复杂的多智能体架构。有时，它仅仅是人类、一个智能体、一套好的测试套件以及精准的提示语的组合。

人在环路之内，还是之外？

审视所有案例后，一个显而易见的结论是：关于harness工程的“自动化”叙事容易让人误以为它是全自动的，但实际上，人类从未真正离开环路。

回顾每个案例中人类扮演的角色：

Stripe —— 人类负责撰写任务描述、审查每个拉取请求、设计harness基础设施。智能体是“无人值守执行”，但人类既在入口把关，也在出口监督。

OpenAI —— 人类“确定工作优先级、将用户反馈转化为验收标准、并验证最终结果”。智能体编写代码，人类定义做什么以及如何验收。

Anthropic —— 人类负责设计评估标准、校准评估器的评分偏好、阅读执行轨迹以发现评估器判断与自身判断不一致之处并调整提示。最终产出仍需要人类亲自操作以验证效果。

因此，harness实际所做的是将人类从“编写代码”的工作中解放出来，转移到“设计约束+审核结果”的工作上——工作的抽象层级发生了变化，但人类并未脱离环路。更准确地说，是“人类在更高层级的环路中”：不再介入每一行代码的循环，而是介入任务定义、harness调优和最终验收这个更大的循环。

这也解释了很多人好奇的问题：既然Stripe已经实现了如此程度的AIharness自动化，为何没有出现大规模裁员？

观察数据：2025年总收入约为194亿美元，同比增长17%，净利润率达10.6%。员工人数在8000至10000人之间。支付总额达1.4万亿美元。最新估值为1590亿美元。

答案是：Stripe利用AI来扩大产出，而非缩减编制。每周1300个AI拉取请求、人均每天3.5个拉取请求，对应的不是“用更少的人做同样的事”，而是“用同样的人做更多的事”。AI释放出来的工程生产力被业务增长的需求吸收了。

工程师的工作内容发生了变化——从编写代码转变为撰写任务描述、审查AI生成的拉取请求、维护harness系统——但工程师本身仍然是不可或缺的。真正被节省下来的是人手敲击键盘编写实现代码的时间，而非工程师的岗位。

harness最大的未解难题

将所有成功案例并列观察，一个未被直面的事实浮现出来：它们全都建立在既有的、丰富的测试资产之上。

Stripe拥有三百万项测试，这是十年积累的成果。buffa项目有谷歌的protobuf一致性测试套件，这是现成的资源。C编译器项目有GCC的torture测试套件，同样是现成的。而OpenAI那个从零开始的项目让Codex自行编写测试——Martin Fowler直接批评其“缺乏对功能与行为的验证”。

目前，尚未有令人信服的实践能够展示“从零开始的项目 + 无既有测试 + 高质量产出”这一组合。

这其中存在一个结构性的矛盾：

让AI同时编写代码和测试 —— 会导致同义反复测试，测试仅验证“代码做了什么”。

让人类先行编写测试 —— 那么测试设计本身就成为最耗费脑力的工作，harness所节省的仅仅是“敲击实现代码”这部分体力劳动。

让AI编写测试，人类审查测试 —— 这可能是最实际的折中方案，但审查测试的认知负担并不比编写测试低多少。

Anthropic那篇文章中提到的评估器智能体，正是在尝试解决这个问题——利用独立的智能体进行验收。但作者自己也承认，这个评估器在开箱即用时是一个糟糕的质量保证智能体，它会发现问题，然后说服自己“这不算大问题”并予以放行。必须经过人类的反复调试，才能达到合理的水平。

因此，对于从零开始的项目，真实的成本结构是这样的：harness叙事所宣称的“人类从编写代码转向设计约束”，在零基础场景下，实际上是“人类从编写代码转向设计测试 + 设计验收标准 + 校准评估器”。这部分工作的难度和工作量并未被AI显著降低——因为其本质上是制定规范的工作，即“定义何为正确”，而非“将正确的事物实现出来”。

那么，是否应该采用harness？

harness工程并非银弹。它是一套有效但具有前提条件的方法论。

如果你的项目拥有高覆盖率的测试套件、完善的持续集成基础设施、清晰的架构约束——那么harness能够让你的团队产出翻倍，甚至翻十倍。Stripe就是最好的例证。

如果你的项目是一个测试覆盖率仅有30%、没有代码检查工具、架构约束全靠口头约定的遗留项目——那么请先补足这些基础设施，再考虑引入harness。harness不会凭空产生约束，它只是让已有的约束能够被智能体理解和消费。

如果你的项目是从零开始的——请想清楚由谁来定义“何为正确”。这个问题，harness无法替你回答。

harness工程的核心洞察是正确的：模型是商品，harness是护城河。但这道“护城河”的地基，是多年积累的工程基础设施——测试、持续集成、类型系统、架构约束。没有这些，harness就如同在沙滩上建造城堡。

至于人类是在环路之内还是之外——不要被表面的叙事所迷惑。观察实际的案例：人类从未离开。只是换了一个位置，从马背上的骑手，变成了马厩里的装备设计师。马匹奔跑得更快了，但前进的方向依然由人类设定。

或者，用更直白的话来说：AI替你编写了代码，但“编写什么代码”以及“这些代码是否正确”，这两项任务依然由你承担。