解析Harness核心概念：我们到底在讨论什么

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 浪潮的步伐。

参考来源

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