Harness Engineering 工程学：将 AI Agent 从玩具变为实用工具

模型从来不是最难的那部分。从来不是。

其实，在“Harness”这个词诞生之前，很多团队就已经在埋头搭建类似的东西了。那时候没有现成的术语，大家做的都是同一件事：摸着石头过河，然后撞上一堵又一堵无形的墙。

比如，在“长运行Agent”这个概念被正式提出前，我们就已经在构建能稳定运行数小时、产出正确结果、中断后还能无缝恢复的工作流。在相关论文发表之前，我们就在实践DAX查询的程序化校验、反馈回路和LLM-as-Judge。

这些实践并非源于文献，而是被现实需求硬生生逼出来的。

但最令人困扰的，或许不是“墙”。墙会拦住你，让你知难而退。而我们遇到的，更像是一扇看不见的玻璃门——你以为前方畅通无阻，直到“砰”的一声撞上去，才发现自己早已头破血流。前沿探索的代价，往往就是这些伤疤。

走在最前沿 ≠ 走在最前沿且不受伤。前沿本身，就是伤疤的来源。

更让人无奈的是，Demo往往跑得太漂亮了。利益相关方看着流畅的演示，很难理解背后那些复杂的“脚手架”为何必要。

“Demo不是好好的吗？为啥搞这么复杂？”

问题在于，万一它坏了呢？六周后，生产环境发生数据漂移，开发环境无法完美复现，排查无从下手——到了那时，谁还会记得当初那个漂亮的Demo？

在没有漂移检测和可靠工程框架的情况下，盲目地给Prompt加示例、堆砌工具、拆分子Agent，就像试图把果冻钉在墙上。非确定性行为，叠加“再加一个功能试试”的心态，再配上缺失的监控，无异于在布满纸割伤的酒精池里反复横跳。这不能叫“走在最前沿”，这更像是一种工程上的“自残”。

给东西命名，就是给门上装把手

共享术语的价值就在于此。有了共同的语言，下一支团队就不必再撞上那扇玻璃门。他们能看到门，找到把手，然后从容地走进去。

这就是Harness Engineering为行业带来的东西。它不是在给先行者颁发安慰奖，而是为所有人建立了一套共同语言，用来讨论如何将Agent工作流可靠地送上生产环境，无需每次都从零开始解释。

现在，这件事有名字了。

那个包裹大语言模型、将其原始文本输出转化为可靠系统行为的工程化运行时，就叫Harness（外壳/挽具）。而设计、构建和运维这个Harness的学科，就叫Harness Engineering（外壳工程学）。

这个学科，作为一个被命名的概念，诞生仅约12个月；但作为一种工程实践，它已经存在了大约三年。

一句话说清楚 Harness 是什么

Harness是包裹LLM的工程化运行时，负责把模型的原始文本输出转化为可靠的系统行为。

具体来说，Harness承担了六件模型自身无法独立完成的事：

这里需要澄清一个最常见的误解：

Harness 不是 try-catch 包一层，防止模型挂掉。

它是一个精心设计的工程化环境，让一个有能力的模型能够完成它自己原本无法胜任的、更庞大、更持久、更自主的任务。

一个好的驾驶舱，其价值不只是防止飞行员坠机，而是让飞行员能够执行那些在糟糕驾驶舱里根本不可能完成的任务。

记住这个区别。大多数初次接触这个概念的人，都容易在这里产生误解。

这个学科有明确的“出生日期”

大多数工程学科没有确切的诞生时刻，但Harness Engineering有——2024年5月。

当时，普林斯顿的一个研究团队（Yang, Jimenez, Wettig, Lieret, Yao, Narasimhan, Press）发表了一篇论文《SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering》，后来被NeurIPS 2024收录。

他们做了一件事后看来显而易见、但当时却颇具启发性的事：他们锁死了模型。 使用固定的GPT-4 Turbo，不进行微调，也不玩复杂的Prompt技巧。

然后，他们在模型和代码库之间搭建了薄薄的一层，称之为Agent-Computer Interface（ACI）。整个实验只改动这一层。ACI仅包含四个组件：

1. 文件搜索最多返回50条结果
2. 一个有状态的文件查看器，一次看100行，并记住位置
3. 编辑时运行Linter，直接拒绝语法有问题的补丁
4. 上下文窗口管理器，随着交互记录增长而压缩旧信息

仅此而已。同一个模型，同一个权重，同一个基准测试。

结果，在SWE-bench基准测试上的成绩从3.8%提升到了12.47%。三倍以上的提升，全部来自于接口设计的改进。

这个数字本身令人震撼，但更震撼的是其背后的含义：SWE-agent团队通过可控实验证明，模型周围的运行时环境，其重要性可能超过模型本身。

在此之前，Agent研究的一个隐含假设是“更好的Agent需要更好的模型”。而ACI的消融实验表明：即使锁定模型，通过设计更好的接口，也能制造出更强大的Agent。

这篇论文，堪称Harness Engineering学科的基础设计文档。之后出现的各种Harness模式、工作流设计、协议栈讨论乃至生产环境回顾，都可以看作是对SWE-agent所证明原则的泛化和延伸。

1947 年的驾驶舱研究：一切思想的源头

当然，SWE-agent的作者并非凭空发明了这个原则。他们明确标注了思想来源：人因工程学（Human-Factors Engineering）。这条思想脉络的历史比计算机本身还要悠久。

1947年，Paul Fitts和Richard Jones发表了《460起飞行员操作失误事故的因素分析》。这项研究受美国空军航空医学实验室委托，起因是战后一系列被简单归因为“飞行员失误”的坠机事故。

Fitts和Jones采访了飞行员，检查了驾驶舱。他们发现的并非飞行员失误。

他们发现：

• 相同的控件，在不同飞机上的布局完全不同；
• 看起来一模一样的操纵杆，功能可能天差地别；
• 在高压力情境下，经验丰富的飞行员会稳定地误触错误的控制器——因为驾驶舱的设计从未考虑过人类在应激状态下的实际反应模式。

他们的结论彻底碘伏了整个领域：

别再去训练更好的操作员了。重新设计环境。驾驶舱才是变量。

这个结论催生了人因工程学，其思想经由Don Norman的《设计心理学》（1988）、Atul Gawande的《清单革命》（2009）以及外科手术和ICU的清单实践得以传承——这些实践通过改变环境而非苛求操作者，实实在在地拯救了无数生命。

SWE-agent论文所做的，正是将LLM置于“操作员”的位置，并套用了同一套逻辑。ACI就是为Agent重新设计的驾驶舱。

这意味着，Harness Engineering被嵌入了一段拥有八十年历史、且成果可度量的学术传统之中。它不是一时兴起的潮流，而是那条被反复验证的原则的最新实例：

当操作员不断重复同一个错误——环境才是变量。

“机械同理心”：赛车手的智慧，程序员的方法论

驾驶舱是一个绝佳的视角。另一个同样能引起软件工程师共鸣的视角，叫做机械同理心（Mechanical Sympathy）。

这个词由传奇赛车手Jackie Stewart提出。他说：你不理解车怎么工作，你就开不快。

Martin Thompson在2011年左右将这个理念引入软件工程领域，并由此创造了LMAX Disruptor——它证明了，只要代码尊重底层硬件（CPU缓存行、分支预测、内存层级、伪共享、缺页中断）的实际工作方式，就能在普通硬件上实现每秒数百万次的操作处理。

机械同理心 = 编写适配底层运行机制的代码，而不是与之对抗。

Harness Engineering，就是将机械同理心应用在一个全新的底层之上。这个新底层 = LLM + 上下文内存 + 注意力预算。

和所有底层一样，它也有有名字的失败模式：

这四个AI侧的失败模式，都是真实的、有明确定义的、可测量的，生产环境中的工程师每天都在与之搏斗：

• 上下文腐烂（Context Rot）：当上下文窗口被陈旧或低信息量的token塞满后，模型性能会可观测地下降。
• 上下文恐慌（Context Panic）：Agent在上下文压力下开始跳过步骤、短路计划过程。
• 迷失中间（Lost-in-the-Middle）：一个被反复验证的现象——对于长Prompt，模型对中间部分信息的注意力显著低于开头和结尾。
• U 型注意力（U-Shaped Attention）：对上述现象的更广义概括。

两年前，这四个术语一个都不存在。 而现在，它们都有了对应的Harness补救模式：上下文压缩、工作记忆纪律、检索排序、结构化笔记、子Agent隔离等。

至此，三条时间线串联在一起：

• 2011年左右：硬件层面的机械同理心教会程序员尊重缓存行和内存布局。
• 2024年5月：SWE-agent标志着机械同理心从CPU跨越到了LLM。同一个洞见，新底层，让Agent性能翻了三倍——且未改动模型。
• 现在：Harness Engineering正是这一洞见向生产级Agent系统的全面泛化。

三代同样的核心思想，在越来越高的抽象层次上重复上演：CPU → Agent-Computer Interface → 完整的Agent运行时。

从实践到学科：2025末到2026初的术语大合流

搭建Harness的实践，远比它的名字古老。

在2024到2025年，所有真正在交付Agent系统的团队，早就在模型周围搭建了工具层、上下文组装管线、校验器、记忆分层、可观测链路和恢复回路。任何在真实代码库上深度使用过Claude Code、OpenAI Codex或Cursor的人都会清楚——光靠模型本身是远远不够的。

但那时缺乏共享词汇。每个团队各有各的叫法：“wrapper”、“agent loop”、“编排层”、“运行时”。每个人都觉得自己搞的是一套独门秘籍。

然后——命名的时刻到来了。

时间线复盘

2025 年下半年：Anthropic 率先播种术语

当大多数团队还在使用“wrapper”这类泛称时，Anthropic已经开始在正式的工程文章中使用“harness”这个词。

• 2025年9月28日，《Effective Context Engineering for AI Agents》将上下文工程命名为一个独立的工程关注点，拥有自己的模式，独立于Prompt工程，并成为Harness Engineering的关键组成部分。
• 2025年11月25日，《Effective Harnesses for Long-Running Agents》更进一步，将Harness本身命名为一个独立的工程产物，附带一套独立的设计问题集。

2026 年 2 月：Mitchell Hashimoto 一锤定音

HashiCorp联合创始人Mitchell Hashimoto在一篇关于个人AI采纳历程的博客中，使用“harness engineering”来描述通过改进Harness而非Prompt来系统性修复Agent错误的实践。

Anthropic创造了这个词，Hashimoto则将其确立为一个学科的名称。一锤定音。

2026 年 2 月 11 日：OpenAI 正式跟进

OpenAI在一篇关于使用Codex Agent纯靠代码构建百万行生产代码库的文章中给出了正式定义。他们指出，主要的工程挑战并非模型能力，而是设计模型周围的环境、反馈回路和控制系统。

这篇文章让术语机构化了——三家顶尖AI实验室中，有两家开始在公开工程文章中使用同一个词。

2026 年 2-3 月：行业跟进

Martin Fowler的网站、LangChain、Cobus Greyling等纷纷发表跟进文章，将这一学科提炼成工程师可以直接引用的公式。

其中，LangChain压缩出了一个最精炼的版本：

Agent = Model + Harness

模型提供原始智能。Harness则负责管理记忆、工具、重试、人类审批、可观测性——让模型能够专注于推理本身。

2026 年 3 月 23 日：Anthropic 发布参考架构

《Harness Design for Long-Running Application Development》——这是迄今为止该学科最完整的参考设计。它不是一篇短文，而是一份完整的参考架构，涵盖了上下文组装、记忆分层、评估关卡、恢复回路以及长运行Agent所需的全部运维模式。

如果你只读一篇关于Harness设计的文档，就读这篇。

2026 年 4 月：术语普及

在各大AI工程团队、厂商博客和生产环境回顾中，“harness engineering”已成为标准工作用语。

总结

• 作为有名字的学科：约12个月大。
• 作为工程实践：大约3岁。

什么归 Harness，什么归模型？

设计一个有用的Agent，关键在于精确地知道Agent的哪些维度由模型负责，哪些由Harness负责。

一个最清晰的模型包含六个维度：

Agent = 感知 + 大脑 + 记忆 + 规划 + 行动 + 协作

四个开放标准，各管一层：

其中，MCP由Anthropic开源，并于2025年12月捐赠给Linux基金会。Agent Skills也作为开放标准公开发布在 agentskills.io。

结语：一句话总结

Harness Engineering 是把机械同理心应用在 LLM 这个新底层上的工程学科。

它让Agent从“Demo跑通了”进化到“生产环境跑不坏”。

它的思想源头可以追溯到1947年的驾驶舱研究，它的关键实验证据来自2024年的SWE-agent论文，而它作为一个有名字的学科，则诞生于2025-2026年的术语大合流。

所以，下次再有人和你讨论AI Agent时，别只问“用哪个模型”。

不妨问一句：你的 Harness 是怎么设计的？

如果对方愣住了——你可以把这篇转给他。