2026 年初，若要论及 AI 工程领域最炙手可热的词汇，非 "harness" 莫属。Mitchell Hashimoto 为其赋予了清晰的操作性定义[1]，OpenAI 通过百万行代码的实践验证了它的可行性[4]，而 LangChain 则直接将其纳入公式体系。然而，若将视野拉长至五十年，这一概念在软件工程发展历程中实则早有迹可循——从 test harness（测试框架）到 evaluation harness（评估框架），再到如今备受关注的 agent harness（智能体框架）[7]。每一次演进，都在阐述同一个核心：在受控对象的外围构建一个完整的控制系统。
Model（模型）+ Harness（框架）= Agent（智能体）
当前关于 harness 的标准叙事，源自这样一个基础公式：
Model + Harness = Agent
Mitchell Hashimoto 给出了最为简洁的操作性定义[1]：“每当智能体犯下错误，你就投入时间设计解决方案，确保它未来不再重蹈覆辙。” OpenAI 紧随其后，通过一个三人团队、历时五个月、不编写一行手写代码的实验，有力验证了这一思路[4]——最终产出了达一百万行的生产代码和 1500 个已合并的 PR（拉取请求）。
如图 1 所示，harness 被理解为包裹模型外的所有外围系统：提示词模板、上下文注入机制、工具调用约束、沙箱运行环境以及反馈循环体系。控制的焦点始终锁定在模型之上。
这一界定本身并无问题。然而，模型仅仅是受控者的一种类型。针对模型的 harness 思想，完全可以拓展到对所有不确定行为的控制领域。这并非要推翻现有定义，而是将其置于一个更为宏大的图景中审视。test harness 比 AI harness 早了半个世纪[7][9]，harness 所蕴含的控制思想从来就不局限于 AI 领域。
Harness 的本质：驾驭不确定行为
词源追溯与 test harness：并非全新概念
"harness" 的原意是马具——缰绳、鞍具、挽具。它并非马匹本身，却能使骑手有效驾驭马匹。这一比喻从一开始便锁定了 harness 的核心洞察：不直接修改受控者本体，而是在其外围构建控制系统。
上世纪 70 年代，test harness 的概念在软件工程领域正式确立[9]。贝尔实验室的研究人员利用桩模块和驱动程序构建受控环境，为被测组件提供输入、捕获输出并验证结果[7]。被测组件对此浑然不觉，只是按指令运行。美国国家标准与技术研究院（NIST）在 70 年代末对该术语进行了标准化[9]，它也由此成为 JUnit、pytest 等所有现代测试框架的始祖。
但 test harness 存在结构性的局限：它仅具备反馈机制（运行→验证），缺乏前馈能力（执行前的方向引导）。其框架是静态的——由人设计、由人维护，不会根据被测系统的表现自动迭代。它执行的是快照式检查，不关注代码在两次测试之间是否发生退化。其受控者具有确定性：输入相同，输出必然相同。其控制循环是一次性的：跑完测试、输出报告、流程结束。
简而言之，test harness 将框架视为工具，而非系统。工具用完即可放下。而现代 harness 需要的是持续运行的系统——框架一刻不停地约束着受控者，受控者一刻不停地产生输出。这种“持续约束”的特性，正是区分 harness 与非 harness 的核心标准。
Fowler 框架：前馈机制与反馈机制
2026 年 4 月，Birgitta Böckeler 在 Martin Fowler 的网站上发表文章[2]，将 harness 拆解为两种互补的控制机制：
Guides（前馈控制） 在智能体行动之前，预判其行为并引导方向。其目标是提高智能体首次尝试即成功的概率。实现形式包括：AGENTS.md 文件、系统提示词、上下文注入机制、架构约束文档。这是 test harness 完全缺失的维度——并非在代码编写完成后才检查，而是在智能体动手之前就将规则植入其行动指南。
Sensors（反馈控制） 在智能体行动之后，观察其结果并辅助其自我纠正。其目标是在问题暴露于人眼之前，尽可能多地实现自动修复。实现形式包括：linter（代码检查工具）、测试套件、CI（持续集成）门禁、自定义校验脚本。test harness 的核心正是一种仅依赖反馈的 sensor，但 Fowler 框架的关键洞察在于：sensor 产出的信号应当为 LLM（大语言模型）进行优化——例如，自定义 linter 消息中包含自我修正的指令，本质上就是一种正向的提示注入技术[3]。
两者缺一不可。仅使用 Guides，智能体虽编码了规则，却永远无法知晓规则是否生效。仅使用 Sensors，智能体会反复犯同样的错误，无法从源头上加以预防。这就像指导一名实习生：先与其沟通编码规范（前馈），随后审阅其代码，发现问题时补充规则（反馈）。只有此循环持续运转，harness 才能真正“活”起来。
受控者并不限于模型
Harness 用于控制具有不确定性的受控者。受控者可以是模型，这是当前叙事的焦点。但受控者也可以是人——业务流程所约束的，正是人如何规范操作。受控者甚至可以是整个业务运作过程：如何设计、如何落地、如何监控、如何优化，这些环节都存在不确定性，都需要持续的控制。
广义 Harness 的三个层级
Harness 的控制模式在不同层级上重复出现，但其控制的对象各不相同。
AI 层 Harness 的公式为模型（受控者）+ 框架（控制系统）= 智能体。框架在运行时持续生效，就像马奔跑时缰绳始终在手。它控制的是模型的推理与行动——系统提示词约束其角色定位，工具调用约束其能力边界，反馈循环纠正其行为偏差。这是当前市场讨论最为广泛的 harness 形态[1][4]。
构建时工作流 的公式为智能体 + 工作流 = 业务代码。智能体按照既定的方法论运行，产出业务代码后，代码便独立运转，不再依赖智能体。这是一个一次性的生产过程——产出完成后，控制系统便撤出。回到前述标准：它是否持续约束不确定的受控者？并不满足。因此，工作流并非 harness。
工程层 Harness 的公式为业务本身 + 工程框架 = 业务系统。业务代码具有确定性，无需额外约束。但业务本身——如何设计、如何落地、如何监控——具有不确定性，依赖人与流程的推动。这一层的框架约束的是业务运作过程：测试框架持续验证质量，业务流程持续规范操作，产研效能持续监控与改进。Böckeler 已在讨论 maintainability harness（可维护性框架）与 architecture fitness harness（架构适应性框架）[2][3]——这些正是工程层框架的具体形态。
AI 层与工程层均属于 harness，因为它们都在持续约束不确定的受控者。构建时工作流则不属于 harness，因其是一次性行为。
广义 Harness 的四个要素
一个完整的 harness 实践，包含四个核心要素。Fowler 的文章[2]描述了前两个，Böckeler 的 steering loop（驾驶循环）触及了第三个，但完整的四要素框架尚未被明确提出。
运行时控制：前馈 + 反馈
这是 harness 的核心引擎。前馈在行动前引导方向，反馈在行动后纠正偏差。Fowler 已对此机制进行了清晰阐述[2]——Guides 提高首次正确的概率，Sensors 在错误到达人眼之前自动修正。两者不可偏废。
Harness 治理：谁来迭代控制系统本身
Harness 不能自行迭代。
Böckeler 提出的 steering loop（驾驶循环）描述了这一过程[2]：每次智能体完成一个会话，人类需要思考——这次它又犯了哪些常见错误？能否新增一个 sensor 来捕捉？能否修改某个 guide 来进行预防？OpenAI 团队的 Ryan Lopopolo 曾撰文[4]指出，他们团队尽量不直接修改代码，而是将精力集中在迭代规则上——不是人在修代码，而是人在修规则，再让规则去修代码。
但 steering loop 目前被当作 harness 的“使用方式”，而非 harness 的一个独立要素。这一点值得单独提出，原因很简单：它的操作对象是 harness 本身，而非受控者。当智能体的表现出现问题时，你有两种选择——调整受控者（例如更换模型），或者调整框架（例如修改 AGENTS.md、增加一条 linter 规则）。治理关注的是后者。缺乏治理，harness 会退化为一系列过时的规则，约束力逐年衰减。
系统熵管理：谁来维护产出物
受控者的产出——代码、文档、架构——会随时间退化。新功能不断叠加，旧代码无人清理，文档与实现逐渐脱节。这是软件系统的热力学第二定律。
缺乏自动化的反熵机制，系统将腐化至一个临界点：框架的约束依然有效，但产出物本身已溃烂到框架无力挽救的程度。园艺 Agent、定时巡检、自动清理脚本——这些反熵工具的操作对象是产出物，既非受控者，也非框架本身。
四要素之间的关系
前馈 + 反馈 → harness 的运行时引擎 → 操作对象：受控者
Harness 治理 → harness 的进化机制 → 操作对象：harness 本身
系统熵管理 → 系统健康的兜底保障 → 操作对象：受控者的产出物
三个操作对象，对应三套不同的关注焦点。用治理的手段去解决熵管理的问题，或者用运行时控制的手段去解决治理的问题，方向就错了。
四要素在任何层级都适用。AI 层的治理是迭代 AGENTS.md 和 linter 规则，工程层的治理是迭代测试框架和流程规范。AI 层的熵管理是自动清理智能体产出的冗余代码，工程层的熵管理是定期巡检业务代码的健康度。控制对象不同，但四要素的框架始终如一。
层级封装与实践启示
一个项目的 harness 可能由 skill（技能）、rules（规则）、agent.md（智能体描述文件）、hooks（钩子）、linter（代码检查工具）、测试框架等多个组件构成。它们是独立的子系统，还是共同构成控制系统，取决于你的视角。对组件自身而言，它是独立系统；对上层业务而言，它是控制系统的一部分。
更为关键的是层级封装：当一个系统被封装好并作为下一层的受控者后，下一层应在此基础上封装自己的控制系统，而不应介入本系统的内部逻辑。这就像操作系统分层——应用无需了解内核的调度算法。AI 层框架不应直接操控业务代码，工程层框架不应直接操控模型的推理过程。每一层管好自己的控制范围，系统才能稳定演进。
无论你从事 AI 工程、测试开发，还是业务架构，都在 harness 的某个层级上工作。认清自己所处的层级，才能找到正确的发力方向。当前叙事集中在 AI 层[1][4]，但工程层的框架始终存在——而且由于受控者是人及业务流程，可能更难做好。
如果我们不把 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
