当我们讨论 Harness 的时候，我们在讨论什么？

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

Model + Harness = Agent

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

ini 复制代码

Model + Harness = Agent

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

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

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

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

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

"harness" 原义是马具------缰绳、鞍具、挽具。它不是马，但它让骑手能控制马。这个隐喻从一开始就锁定了 harness 的核心洞察：不直接修改受控者本身，而是在它外围构建控制系统。

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

但 test harness 有结构性的局限。它只有反馈（运行 → 验证），没有前馈（执行前引导方向）。它的 harness 是静态的------由人设计，由人维护，不会根据被测系统的表现自动迭代。它是快照式检查，不关心代码在两次测试之间是否在退化。它的受控者是确定性的：给相同输入，产相同输出。它的控制循环是一次性的：跑测试、出报告、结束。

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

Fowler 的框架：前馈 + 反馈

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

Guides（前馈控制） 在 agent 行动之前预判它的行为并引导方向。目标是提高 agent 第一次就做对的概率。实现形式包括：AGENTS.md、系统提示词、上下文注入、架构约束文档。这是 test harness 完全缺失的维度------不是等代码写完再检查，而是在 agent 动手之前就把规则塞进去。

Sensors（反馈控制） 在 agent 行动之后观察结果并帮助它自我纠正。目标是在问题到达人眼之前尽可能多地自动修正。实现形式包括：linter、测试套件、CI 门禁、自定义校验脚本。test harness 的核心就是一种 feedback-only 的 sensor，但 Fowler 框架的关键洞察是：sensor 产出的信号应该为 LLM 优化------比如自定义 linter 消息里包含自我修正的指令，本质上是一种正向的 prompt injection $3$ 。

两者的配合至关重要。只用 Guides，agent 编码了规则但永远不知道规则有没有生效。只用 Sensors，agent 反复犯同样的错误，无法从源头预防。这就像带一个实习生：你先跟他聊编码规范（前馈），然后 review 他的代码，发现问题就补充规则（反馈）。这个循环持续运转，harness 才是活的。

受控者不一定是 Model

harness 用于控制不确定的受控者。受控者可以是 model，这是当前叙事的焦点。但受控者也可以是人------业务流程约束的就是人怎么规范地操作。受控者还可以是整个业务运作过程------怎么设计、怎么落地、怎么监控、怎么优化，这些都不确定，都需要持续的控制。

广义 Harness 的三个层级

harness 的控制模式在不同层级重复出现，但控制对象不同。

AI 层 Harness 的公式是 model（受控者）+ harness（控制系统）= agent。harness 运行时持续生效，就像马奔跑时缰绳一直在。它控制的是 model 的推理和行动------系统提示词约束角色，工具调用约束能力边界，反馈循环纠正偏差。这是当前市场讨论最多的 harness 形态 $1$ $4$ 。

构建时工作流 的公式是 agent + 工作流 = 业务代码。agent 按照方法论运行，产出业务代码后，代码独立运转，不再依赖 agent。这是一次性的生产过程------产出后控制系统就撤了。回到刚才的标准：它是否持续约束不确定的受控者？ 不是。所以，工作流不是 harness。

工程层 Harness 的公式是业务本身 + 工程 harness = 业务系统。业务代码是确定的，不需要约束。但业务本身------怎么设计、怎么落地、怎么监控------是不确定的，是人和流程在推动。这一层的 harness 约束的是业务运作过程：测试框架持续验证质量，业务流程持续约束操作规范，产研效能持续监控和改进。Böckeler 已经在讨论 maintainability harness 和 architecture fitness harness $2$ $3$ ------这些就是工程层 harness 的具体形态。

AI 层和工程层都是 harness，因为它们都持续约束不确定的受控者。构建时工作流不是 harness，因为它是一次性的。

广义 Harness 的四个要素

完整的 harness 实践包含四个要素。Fowler 的文章 $2$ 描述了前两个，Böckeler 的 steering loop 触及了第三个，但完整的四要素框架还没有被明确提出。

运行时控制：前馈 + 反馈

这是 harness 的核心引擎。前馈在行动前引导方向，反馈在行动后纠正偏差。Fowler 已经把这个机制讲得很清楚了 $2$ ------Guides 提高首次正确的概率，Sensors 在错误到达人眼之前自动修正。两者缺一不可。

Harness 治理：谁来迭代控制系统本身

harness 不能自己迭代自己。

Böckeler 提出的 steering loop（驾驶循环）描述了这个过程 $2$ ：每次 agent 完成一个会话，人类要思考------这次它又犯了什么常见的错？能不能加一个 sensor 来捕捉？能不能改一下 guide 来预防？OpenAI 团队的 Ryan Lopopolo 写过一篇文章 $4$ ，说他们团队尽量不直接改代码，而是把精力花在迭代规则上------不是人在修代码，是人在修规则，然后让规则去修代码。

但 steering loop 目前被当作 harness 的"使用方式"，而不是 harness 的一个独立要素。我认为它值得被单独提出来，原因很简单：它的操作对象是 harness 本身，不是受控者。当 agent 的表现出了问题，你有两种选择------调整受控者（比如换一个 model），或者调整 harness（比如修改 AGENTS.md、增加一条 linter 规则）。治理关注的是后者。没有治理，harness 会退化成一堆过时的规则，约束力逐年衰减。

系统熵管理：谁来维护产出物

受控者的产出------代码、文档、架构------随时间退化。新功能不断叠加，旧代码没人清理，文档和实现逐渐脱节。这是软件系统的热力学第二定律。

没有自动化反熵机制，系统会腐化到一个临界点：harness 的约束依然有效，但产出物本身已经烂到 harness 救不了的程度。园艺 Agent、定时巡检、自动清理脚本------这些反熵工具的操作对象是产出物，既不是受控者，也不是 harness 本身。

四者的关系

复制代码

前馈 + 反馈  →  harness 的运行时引擎     →  操作对象：受控者
Harness 治理 →  harness 的进化机制        →  操作对象：harness 本身
系统熵管理   →  系统健康的兜底           →  操作对象：受控者的产出物

三个操作对象，三套不同的关注点。用治理的手段去解决熵管理的问题，或者用运行时控制的手段去解决治理的问题，方向就错了。

四要素在任何一层都适用。AI 层的治理是迭代 AGENTS.md 和 linter 规则，工程层的治理是迭代测试框架和流程规范。AI 层的熵管理是自动清理 agent 产出的冗余代码，工程层的熵管理是定期巡检业务代码的健康度。控制对象不同，但四要素的框架不变。

层级封装与实践启示

一个项目的 harness 可能由 skill、rules、agent.md、hooks、linter、测试框架等多个组件构成。它们是独立的子系统还是共同构成控制系统，取决于你的视角。对组件自身，它是独立系统；对上层业务，它是控制系统的一部分。

更关键的是层级封装：当一个系统封装好并作为下一层的受控者后，下一层应该在此基础上封装自己的控制系统，而不应介入本系统的内部逻辑。就像操作系统分层------应用不需要知道内核的调度算法。AI 层 harness 不应该直接操控业务代码，工程层 harness 不应该直接操控 model 的推理过程。每一层管好自己的控制范围，系统才能稳定演进。

无论你是做 AI 工程、测试开发、还是业务架构，都在 harness 的某个层级上工作。认清自己的层级，才能找到正确的发力方向。当前叙事集中在 AI 层 $1$ $4$ ，但工程层的 harness 一直都在------而且因为受控者是人和业务流程，可能更难做好。

如果我们不把 harness 的版图说清楚，就会出现一种错觉：harness 是 AI 时代的新发明，只有做 AI 的人才需要懂。但 harness 的思想比 AI 早了半个世纪 $7$ $9$ 。理解了这张版图，我们的工程能力才能真正跟上 AI 的浪潮。

参考来源

Mitchell Hashimoto, My AI Adoption Journey, 2026.02
Birgitta Böckeler, Harness engineering for coding agent users, martinfowler.com, 2026.04
Birgitta Böckeler, Maintainability sensors for coding agents, martinfowler.com, 2026.05
OpenAI, Harness engineering: leveraging Codex in an agent-first world, 2026.02
Anthropic, Effective harnesses for long-running agents
Akira Sato, Harness Engineering: From Code Scaffolding to WorldModel Stewardship, 2026.05
Sanderson Macedo, What makes a harness a harness, arxiv, 2026.06
deepset, Harness Engineering: How to Build Reliable AI Agents, 2026.05
OutcomeDev, Harness Engineering: The Discipline That Decides Whether AI Builds or Burns, 2026.05