Harness工程：让AI输出真正可控

你是否注意到，同样使用Claude或GPT来编程，有的团队交付稳定、质量可靠，有的团队却频频失控、效果混乱？

问题的关键并不在模型（LLM）本身，而在模型外围那套“马具”式的约束系统。到了2026年，技术圈为这套机制正式命名：Harness工程（Harness原本指马具，如缰绳、鞍具、嚼子，这里借指围绕AI建立的控制体系）。

这篇文章主要想讨论三件事：什么是Harness工程，什么是CMMI AIM，以及两者之间到底是什么关系。

2026年4月，Thoughtworks杰出工程师Birgitta Böckeler在Martin Fowler网站发表了一篇重要文章，正式引入了Harness工程这一概念。文章一开始给出了一个非常简明的公式：

Agent = Model + Harness

换成更通俗的话来说：一个AI agent最终的表现 = 大语言模型自身的能力 + 你为它构建的整套控制机制。

一匹马即使再有力量，如果没有马具，依然只是难以驾驭的野马。同样，一个大语言模型即便能力再强，没有Harness，它产生的结果依旧难以预测。

Böckeler将Harness归纳为两类核心控制机制：

第一类：Guides（引导）——在AI开始行动前先把方向设定好。

这就像骑马前先把路线规划清楚。具体形式包括：架构文档、编码规范、项目模板、操作手册等。这些内容会告诉AI agent：“你应当如何行动。”例如，很多团队如今会在项目根目录放置一个AGENTS.md文件，明确写出架构约定、命名规则和禁用事项——AI agent在开始执行前会先读取这个文件，就像新员工入职时先看员工手册一样。

第二类：Sensors（传感器）——在AI完成动作之后对结果进行检查。

这就像马一旦跑偏，缰绳会把它及时拉回。典型做法包括：代码检查工具（linter）、自动化测试、类型检查器、架构约束检查器等。这些工具会在AI agent每完成一步后自动触发运行，一旦结果偏离预期，就把反馈返回给agent，让它自行修正。

Böckeler特别指出：只有引导没有检查，问题会在不知不觉中累积；只有检查没有引导，同类错误则会一再重复。二者必须配套出现。

如果你熟悉CMMI，可以这样去理解：Guides类似过程定义——告诉你应当怎么做；Sensors类似验证与确认——检查你做得是否正确。Harness工程所做的，是把这两部分自动化，并让它们以毫秒级速度持续运行。

技术社区已经出现了一些实际案例。Manus团队在半年内重构了五次Harness架构，才最终摸索出稳定方案。Vercel团队删除了80%的agent工具，结果反而让agent响应更快、执行步骤更少。OpenAI则在内部建立了严格的分层架构，通过自定义检查工具与结构化测试来约束agent行为。

这些案例都在说明同一个结论：真正决定AI agent表现的，关键不只是大语言模型，而是你围绕它设计的Harness。

技术圈通过实践得出的这一判断，对从事过程改进的人来说，其实并不陌生。因为这正是我们讲了二十多年的核心观点：过程决定结果。

无论你有没有使用AI，过程本身都会决定结果。

把手机放到另一个房间里，注意力马上就会上升。不是因为意志力突然增强，而是因为环境约束发生了变化。

给自己设定一个番茄钟，效率会明显提高。不是因为你一下子变聪明了，而是你为自己增加了时间预算控制。

每天晚上提前写好第二天要做的任务并放在桌上，第二天一早就能直接开工。不是因为你突然更勤奋了，而是你提前完成了“上下文预加载”。

对每个模块的代码做细致走查，也不是因为开发能力突然跃升，而是因为你增加了一个发现问题的环节。

Harness工程的底层逻辑完全一样：为AI agent设置Guides和Sensors，并不是让大语言模型本身变强，而是通过过程约束让它的输出变得可控制、可预期。

同样的大语言模型，配置不同的Harness，最终产出可能相差悬殊。

Harness工程解决的是一个非常关键的工程问题：怎样有效地约束和控制单个AI agent。这当然很重要，但对企业而言，挑战远不止这一层。

设想这样一种场景：企业里有几十个研发团队，上百个AI agent在不同项目、不同业务场景中运行。有的团队使用Claude，有的使用GPT，也有的采用开源模型。有的团队已经建立了较完善的Harness，有的团队还在不断试探。

这时，一系列组织层面的问题就会浮现出来：

由谁来保证各团队Harness的质量保持一致，而不是高低不齐？由谁来衡量AI在各项目中的真实效能，而不是凭感觉判断？由谁来管理AI带来的安全、合规与伦理风险？由谁来确保一个团队摸索出的优秀实践能够被其他团队复用？又由谁来保障这些工程实践能在组织层面系统采纳并持续优化？

Harness工程并不直接回答这些问题。它聚焦的是单个agent的控制闭环，而不是组织级的治理框架。

而这，正是CMMI AIM要解决的事情。

CMMI AIM（Artificial Intelligence Maturity，人工智能成熟度）是CMMI研究院计划于2026年6月推出的新框架，它把全球广泛认可的CMMI绩效改进体系进一步扩展到了AI领域。

在传统软件与系统开发领域，我们常讲道法术器。道：过程决定结果。法：CMMI最佳实践框架。术：具体落地的方法。器：支撑法和术落地的工具。过去二十多年里，正是依靠CMMI这套体系，许多开发团队通过过程改进持续提升了能力。

进入AI时代，AI工具作为“器”突然强大到足以承担部分人的工作。于是有些人开始认为，工具就能决定一切，道法术都可以被抛开。但经过这一年多的实践，龙虾（OpenClaw）等AI工具的流行确实让更多团队拥抱了AI，同时人们也逐渐发现：AI固然能显著提升生产率，但能否稳定维持这种生产率才是真正关键。Harness工程的出现本身就是证明——技术社区也已经意识到，仅有强模型还不够，还必须有过程与约束。

CMMI AIM要做的，就是把这种认知从单个团队上升到整个组织层面。它在组织治理维度上定义了AI成熟度标准，覆盖八个域：开发、服务、数据、安全、人员、安保、供应商和虚拟。全部31个实践域都已经加入AI相关内容，其中276个实践里有126个提供了AI专属指导。

CMMI AIM还划分了三种AI使用场景：辅助增强（AI辅助人完成工作）、验证增强（AI执行工作，由人监督）和完全自主（AI独立完成工作）。这三类场景对Harness的要求是逐步升高的——AI越趋向自主，对控制系统的严密程度要求就越高。

到这里，我们就可以把两者之间的关系梳理清楚了。

CMMI AIM在组织治理层面定义了AI成熟度标准，其中自然也包含了对AI agent管控的要求。Harness工程则是满足这些要求的一种具体工程方法。二者之间属于“法与术”的关系，就像CMMI与各种具体软件工程实践之间的关系一样。

CMMI会告诉你“必须进行评审（Peer Review）”，并提供最佳实践方向——建立评审过程、开展预审、正式评审、问题解决、数据分析。但它不会规定你一定要用Fagan检查法还是轻量级代码走查。类似地，CMMI AIM会告诉你“必须对AI agent实施有效管控”，但具体如何管——采用Harness工程的Guides/Sensors体系，还是采取其他办法——则要由企业结合自身情况来决定。

对于技术团队而言，Harness工程本身就可以独立使用，它已经是一套完整的工程实践体系。但对于希望系统化、可衡量地推进AI转型的组织来说，CMMI AIM则提供了更高层次的框架，确保这些实践能够被一致采用并持续改进。

打个比方：Harness工程好比每位骑手为自己的马调校马具的技术；CMMI AIM则像整个马术俱乐部的管理体系——它确保每匹马都配有合格马具，每位骑手都接受过训练，每次出发前都完成安全检查，并且俱乐部整体表现是可衡量、可追踪、可持续优化的。

一个只有Harness工程、却没有治理框架的组织，AI落地往往会变得碎片化——各团队各行其是，优秀实践难以复制，风险也无法统一管理。反过来，一个只有CMMI AIM框架、却缺少具体工程实践的组织，评估又容易流于表面——成熟度等级看起来不错，但真实的AI agent控制能力并没有跟上。

只有把两者结合起来，企业才能真正实现AI的系统化落地。

值得补充的是，在我们编写CMMI AIM时，Harness工程这一概念还没有被正式提出。CMMI AIM是从过程改进的视角，提前看到了组织需要系统治理AI的需求；而技术社区后来则从工程实践角度，独立发展出了Harness工程这一具体方案。

两个不同领域，从不同起点出发，最后却都指向同一个认知：过程决定结果。

今年是AI落地之年。龙虾（OpenClaw）让更多团队得以快速拥抱AI，Harness工程让AI agent的输出更加可控，而CMMI AIM则保证这一切能够在组织层面实现系统化、可衡量和可持续。

我是CMMI高成熟度评估师，曾在全球完成300多个CMMI评估项目，对如何系统提升整个开发团队能力有较深理解。作为全球25名CMMI AIM编委之一，我也深度参与了CMMI AIM模型的编写与试点工作。

如果你的企业正在思考如何系统性地让AI在开发团队中真正落地——我把这称为AI转型——欢迎交流。因为既需要Harness工程这样的“术”来解决具体技术问题，也需要CMMI AIM这样的“法”来保证组织层面的落地一致性与持续性。

你的组织，准备好了吗？

参考文献：