什么是 Harness Engineering？一门让 AI Agent 从玩具变武器的工程学

📌 开篇先泼一盆冷水

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

在好久之前，其实我们就已经在搭 Harness 了。那时候这个词还没出生，我和一堆咨询用户都在闷头干同一件事——撞墙。撞很多墙。

我们的 Agent 工作流能跑好几个小时、产出正确结果、中断后还能丝滑恢复——在"长运行 Agent"这个术语被发表出来之前。我们在论文出来之前就在做 DAX 查询的程序化校验、反馈回路、LLM-as-Judge。

那时候这些玩意儿都没有名字。我们不是从文献里学的，是被现实逼出来的。

但最让我耿耿于怀的是：它们其实不算墙。墙会拦住你。我们没被拦住。我们走在最前沿，而前沿是会割人的。我们撞上的是一扇你没看见的玻璃门，等到你发现的时候，你已经穿过去了——满脸是血。我们有伤疤。

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

最让人抓狂的是什么？是 Demo 跑得太好了。利益相关方根本看不出来那些"脚手架"为什么要花那么多功夫。

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

问题在于：万一它坏了呢？ 六周后，生产环境发生漂移，Dev 环境完美复现不了，没有人知道怎么排查——这时候谁还记得当初 Demo 有多漂亮？

在没有漂移检测的情况下，给 Prompt 加几个 shot、多加几个工具、再来一层子 Agent 拆分——就像把果冻钉在墙上。非确定性行为 + "再加一个功能嘛"的心态 + 没有漂移检测 = 泡在酒精池里满身都是纸割伤还往里跳。这不叫"走在最前沿"，这叫自残。

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

有了共享术语，下一支团队就不用再穿玻璃门了。他们能看到门，找到把手，直接走进去。

这就是 Harness Engineering 给这个行业带来的东西。它不是给已经在干这些活的人发安慰奖，而是让所有人能用同一套语言讨论如何把 Agent 工作流送上生产环境，不用每次都从盘古开天辟地开始解释。

这件事现在有名字了。

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

这个学科作为有名字的东西，才 12 个月大；作为实践，大概 3 岁。

📦 一句话说清楚 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（arXiv 2405.15793）。

他们做了一件事——回头看，太他妈显而易见了；当时看，像是搞错了分类。

他们锁死了模型。 GPT-4 Turbo，不微调，不搞 Prompt 花招。

然后在模型和代码库之间搭了薄薄一层，起名叫 Agent-Computer Interface（ACI）。只改这一层。ACI 只有四个组件：

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

就这。同一个模型，同一个权重，同一个基准测试。

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 纯靠代码构建百万行生产代码库的文章里给出了正式定义。他们说自己的主要工程挑战不是模型能力，而是设计模型周围的环境、反馈回路和控制系统。

这篇文章让术语机构化了——三家前沿实验室里，有两家开始用同一个词写公开工程文章。

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 怎么设计的？

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

#AI #AIAgent #harness