年初，harness 这个词在 AI 工程领域突然无处不在。Mitchell Hashimoto 给出了操作性定义。OpenAI 用百万行代码做了验证，LangChain 把它写进了公式。但如果把时间线拉长，你会发现这个词在软件工程里已经存在了五十年——从 test harness 到 evaluation harness。再到今天的 agent harness。每一次它都在说同一件事：在受控者外围建立控制程序。

使用者痛点

• 不清楚 harness 与传统测试工具的区别。话说回来，
• 认为只有 AI 场景才需要 harness。忽略了其通用性，
• 难以把握持续约束与一次性控制的边界。
• 缺乏可操作的治理与熵管理策略。按理说，
• 对不同层级如何协同缺乏认知。

Model + Harness = Agent

当前 harness 叙事的标准起点是这个公式：

Model + Harness = Agent

Mitch Hashimoto 给出了最简洁的操作性定义："每当 agent 犯了一个错误。你就花时间设计一个方法，使得 agent 未来不会再犯一样的错误。" OpenAI 紧接着用一个三人团队、五个月、零手写代码的实验验证了这个思路——产出一百万行生产代码和 个合并的 PR。

如图 所示，harness 被理解为包裹 model 的一切外围程序：提示词模板、上下文注入、工具调用约束、沙箱环境、反馈循环。控制对象始终是 model。

这个定义没有错。但 model 只是受控者的一种。我认为，对 model 的 harness 的思想。可以扩大到适用于所有对不确定行为的控制。这不是推翻当前定义，而是把它放到一个更大的图景里。test harness 比 AI harness 早了五十年，harness 的控制思想从来就不只属于 AI。

Harness 的本质：控制不确定行为

从词源到 test harness：这不是新概念

"harness" 原义是马具——缰绳、鞍具、挽具。怎么说呢，它不是马，但它让骑手能控制马。这个隐喻从一开始就锁定了 harness 的主要洞察：不直接修改受控者本身，而是在它外围建立控制程序。

年代，test harness 的概念在软件工程中成型。Bell Labs 的研究员用 stubs 和 drivers 建立受控环境，为被测组件提供输入、捕获输出、验证结果。NIST 在 年代末标准化了这个术语，它成为 JUnit、pytest 等所有现代测试框架的祖先。

但 test harness 有结构性的局限。它只有反馈，没有前馈，它的 harness 是静态的——由人设计。由人维护，不会根据被测程序的表现自动迭代。它是快照式检查，不关心代码在两次测试之间是否在退化。说起来，它的受控者是确定性的：给相同输入，产相同输出。它的控制循环是一次性的：跑测试、出报告、结束。

test harness 把 harness 当作一个工具而不是一个程序。 工具用完就放下，现代 harness 需要的是持续运行的程序——harness 一刻不停地约束受控者，受控者一刻不停地产出。这个"持续约束"的特征，是区分 harness 和非 harness 的主要标准。

Fowler 的框架：前馈 + 反馈

年 月，Birgitta Böckeler 在 Martin Fowler 的网站上发表了一篇文章。将 harness 拆解为两个互补的控制机制：

• Sensors: 在 agent 行动之后观察结果并帮助其自我纠正。目标是在问题到达人眼之前尽可能多地自动修正。实现形式包括 linter、测试套件、CI 门禁、自定义校验脚本等。本质上是一种正向 prompt injection。Sensors: 在 agent 行动之前预判其行为并引导方向，提高第一次就做对的概率。老实说，例如 AGENTS.md、程序提示词、上下文注入还有架构约束文档等。两者配合很关键：单独使用 Guides 或 Sensors 都无法形成完整闭环。

受控者不一定是 Model

Turing's Test Harness 是针对模型，但现实中的“受控者”可以更广泛：人类流程、不确定业务流程甚至整个业务运作过程。“持久化”的 control system 一样必要。”

广义 Harness 的三个层级

AIs 层 Harness： 模型+Harness=Agent；按理说，此层级持续约束模型推理与行动，是目前行业市场讨论最多形态。.

Buildup 工作流： agent+工作流=业务代码；这是一次性生产过程，无持续约束，所以不是 Harness。

Eengineering 层 Harness： 业务本身+工程Harness=业务程序；这里持久化关注的是业务流程与监控，如测试框架持续验证质量和运维监测等。.

• 运行时控制 : 主要引擎；Guides 提高首次正确率；Sensors 自动修正错误。.
• Harness 治理 : steering loop； 当 Agent 出现问题时对规则进行迭代而非直接改码。 .
• 程序熵管理 : 自动清理冗余代码与文档失配，以抵御热力学第二定律带来的退化风险。.

四要素关系示意图:

前馈 + 反馈 → 持续运行时引擎
↓
Harness 治理 → 持续进化规则
↓
熵管理 → 保持产出物健康
↓
整体程序稳定

三个操作对象不同。但四要素框架一致，可应用于任何层级：

• AIs 层治理指更新 AGENTS.md 与 linter；熵管理则自动清除 Agent 冗余产出。
• Eengineering 层治理更新测试框架和规范文件；熵管理通过定期巡检保持业务代码健康度。
• Buildup 工作流虽不属于 Harness，却可借鉴治理与熵管理理念提高一次性产出的可靠度。

层级封装与实践启示

• A 项目中的 Harvest 可以包含 skill 、rules 、agent.md 、hooks 、linter 等多个组件。它们既可作为独立子程序，也可集成为整体 Control System ——取决于你的视角与需求。
• Pains & Solutions: • 缺乏层级视角导致资源重复投入 • 不知道何时将某项技术提高为下一层 Control System • 对“持续约束”的理解偏差导致项目失效 → 建议先明确自己所在层级。再围绕该层级建立或调整对应要素，并逐步向外 封装链条.
• AIs 层不能直接操纵业务代码，而 Eengineering 层也不能直接操纵 Model 推理，以保持各自自治，从而保障整个程序平稳演进。
• No matter if you're an AI engineer,a QA developer,or a business architect,you are working on some layer of same overarching “Harness” ecosystem. Clear boundaries and shared principles unlock cross‑functional synergy.
.

参考来源

1. Mitch Hashimoto,My AI Adoption Journey.
2. Birgitta Böckeler,"Harness engineering for coding agent users",martinfowler.com.
3. Birgitta Böckeler,"Maintainability sensors for coding agents",martinfowler.com.
4. OpenAI。"Harness engineering: leveraging Codex in an agent-first world".
5. Anthropic,Effective Harnesses for Long‑Running Agents.
6. Aki Sato,"Harness Engineering: From Code Scaffolding to WorldModel Stewardship".
7. Sanderson Macedo,"What Makes a Harness a Harness",arXiv.
8. Deepset,"Harness Engineering: How to Build Reliable AI Agents".
9. “OutcomeDev”,“Harness Engineering: The Discipline That Decides Wher AI Builds or Burns”. \end{ol>