Harness Engineering（约束工程）
Birgitta 是 Thoughtworks 的杰出工程师和 AI 辅助交付专家。她拥有超过 20 年的软件开发、架构师和技术领导者经验。
本文属于”Exploring Gen AI（探索生成式 AI）“系列。该系列记录了 Thoughtworks 技术专家探索将生成式 AI 技术用于软件开发的历程。
2026 年 2 月 17 日
阅读 OpenAI 最近关于”Harness engineering（约束工程）“的文章非常有趣，该文描述了一个团队如何以”完全不手动编写代码”作为强制手段，构建了一个用于维护大型应用程序的 harness（约束框架），由 AI agent（智能体）来完成。5 个月后，他们构建了一个真实的产品，代码量已超过 100 万行。
这篇文章的标题是”Harness engineering: leveraging Codex in an agent-first world（约束工程：在智能体优先的世界中利用 Codex）“，但正文中只提到了一次”harness”。也许这个术语是受到 Mitchell Hashimoto 最近博客文章的启发而后加的。无论如何，我喜欢用”harness”这个词来描述我们可以用来约束 AI agent 的工具和实践。
OpenAI 团队的 harness 组件混合了确定性方法和基于 LLM 的方法，分为 3 个类别（基于我的理解分组）：
- Context engineering（上下文工程）：代码库中持续增强的知识库，加上 agent 对动态上下文的访问，如可观测性数据和浏览器导航
- Architectural constraints（架构约束）：不仅由基于 LLM 的 agent 监控，还通过确定性的自定义 linter（代码检查器）和结构测试进行监控
- “Garbage collection（垃圾回收）“：定期运行的 agent，用于查找文档中的不一致性或架构约束的违规行为，对抗熵增和衰退
他们还强调了这一过程的迭代性：“当 agent 遇到困难时，我们将其视为一个信号：识别缺少的内容——工具、防护栏、文档——然后将其反馈到代码库中，始终让 Codex 自己编写修复方案。”
所有描述的措施都专注于提高长期的内部质量和可维护性。我在文章中缺少的是对功能和行为的验证。
暂且抛开这个空白，假设我们可以相信 OpenAI 对这一成功情况的描述（就作者和团队而言，OpenAI 确实有既得利益让我们相信 AI 可维护的代码）——以下是我对文章内容的思考。
Harnesses——未来的服务模板？
Section titled “Harnesses——未来的服务模板？”大多数组织只有两三个主要技术栈——并非每个应用程序都是独特的雪花。这篇文章让我想象这样一个未来：团队可以从一组用于常见应用程序拓扑的 harness 中进行选择，以此作为起点。这让我想起今天的服务模板，它帮助团队在”黄金路径”上实例化新服务。harness——带有自定义 linter、结构测试、基础上下文和知识文档，以及额外的上下文提供者——会成为新的服务模板吗？团队会将它们作为起点，然后随着时间的推移根据自己的应用程序特性进行塑造吗？
使用服务模板时，团队随着经验积累会贡献回模板，但其他团队往往难以整合更新。我们会看到 harness 出现类似的分叉和同步挑战吗？
这篇文章还让我重新审视了一些我较早的假设：
运行时必须受到约束才能实现更多的 AI 自主权？
Section titled “运行时必须受到约束才能实现更多的 AI 自主权？”许多早期和当前的 AI 编码热潮都假设 LLM 将为我们提供目标运行时无限灵活性。用任何语言、任何模式生成，无需约束——LLM 会搞定。但对于我们可以信任的、可维护的、大规模生成的 AI 代码，必须有所取舍。
所描述的 harness 表明，要提高信任和可靠性，需要约束解决方案空间：特定的架构模式、强制边界、标准化结构。这意味着放弃一些”生成任何内容”的灵活性，转而使用充满技术细节的提示、规则和 harness。
是否会收敛到有限数量的技术栈和拓扑？
Section titled “是否会收敛到有限数量的技术栈和拓扑？”随着编码变得不那么关乎输入代码，而更多地关乎引导其生成，AI 可能会推动我们走向更少的技术栈。框架和 SDK 的可用性仍然重要——我们反复看到，对人类友好的东西对 AI 也有益。但在那个细节层面上，开发者的偏好将变得不那么重要。界面中的小低效和怪癖将不那么烦人，因为我们不再直接处理它们。我们可能会选择有良好 harness 可用的技术栈，并优先考虑”AI 友好性”。
这可能不仅适用于技术栈，也适用于代码库结构和拓扑。我们可能会默认采用那些更容易用 AI 维护的结构，因为它们更容易被 harness 约束。OpenAI 团队讨论了架构刚性和执行规则。我能看到的主要关注点是保持数据结构稳定，以及定义和执行模块边界。听起来很合理——但如果没有具体例子，我仍然难以想象”我们要求 Codex 在边界处解析数据形状”在他们的 harness 中实际上是什么样子。
但如果我们能广泛地找出如何 harness 代码库设计模式，这些拓扑会成为新的抽象层吗？而不是像许多 AI 爱好者希望的那样，是自然语言本身？
两个未来世界：AI 前与 AI 后的应用程序维护？
Section titled “两个未来世界：AI 前与 AI 后的应用程序维护？”假设我们开发了良好的 harness 技术，将 AI 自主权提升到 9 级，并增加对结果的信心。哪些技术可以应用于现有应用程序，哪些只适用于从头开始构建时就考虑 harness 的应用程序？
对于较旧的代码库，我们需要考虑 retrofitting（ retrofitting：为现有系统添加新功能或改进）一个 harness 是否值得付出努力。AI 可以帮助我们更快地完成这项工作，但这些应用程序往往过于非标准化且充满熵增，可能不值得这样做。这让我想起在一个从未使用过静态代码分析工具的代码库上运行该工具，然后被警报淹没的情景。
你今天有什么 harness？
Section titled “你今天有什么 harness？”这个团队花了 5 个月时间来构建他们的 harness，这表明这不是为了快速结果就能贸然投入的事情。但值得反思一下你今天的 harness 是什么。你有 pre-commit hook（预提交钩子）吗？里面有什么？你有关于自定义 linter 的想法吗？你想对代码库施加什么架构约束？你尝试过像 ArchUnit 这样的结构测试框架吗？
毫不奇怪，他们所描述的内容听起来比仅仅生成和维护一堆 Markdown 规则文件要做的工作多得多。他们为 harness 的确定性部分构建了广泛的工具。他们的上下文工程不仅涉及策划知识库，还包括重要的设计工作——代码设计本身就是上下文的很大一部分。
OpenAI 团队说：“我们现在最困难的挑战集中在设计环境、反馈循环和控制系统上。“这让我想起 Chad Fowler 最近关于”Relocating Rigor（重新定位严谨性）“的文章。听到关于严谨性可能去向的具体想法和经验令人耳目一新，而不是仅仅希望”更好的模型”能神奇地解决可维护性问题。
最后，难得一次，我喜欢这个领域的一个术语。虽然它才诞生 2 周——我大概可以屏住呼吸，直到有人把他们那个单次提示、基于 LLM 的代码审查 agent 称为 harness……
最新文章（3 月 4 日）：
Humans and Agents in Software Engineering Loops（软件工程循环中的人类与智能体）
上一篇文章：
Context Engineering for Coding Agents（编码智能体的上下文工程）
下一篇文章：
Humans and Agents in Software Engineering Loops（软件工程循环中的人类与智能体）