Harness Engineering —— 初步思考
原文：Harness Engineering - first thoughts 作者：Birgitta Böckeler (Thoughtworks) 日期：2026-02-17 备注：这是一篇早期备忘录，作者后来写了一篇更成熟的分析文章
写完这篇备忘录后，我有时间做了更深入的分析，写了一篇更成熟的文章来描述 Harness Engineering。那篇文章将 harness 的组成元素框定为引导器（guides）和传感器（sensors），它们可以是计算性的，也可以是推理性的。Harness 模板让我们能够在更大的软件组织中共享通用的引导器和传感器。Harness 试图将人类开发者经验所带来的价值外部化并显式化，但它只能做到一定程度。一个好的 harness 不应以完全消除人类输入为目标，而应将人类输入引导到我们的参与最重要的地方。
读到 OpenAI 最近关于”Harness engineering”的文章非常有趣，文中描述了一个团队如何使用”完全不手写代码”作为强制函数（forcing function），为使用 AI 智能体维护大型应用程序构建了一套 harness。经过 5 个月，他们构建了一个真正的产品，现在已经超过 100 万行代码。
文章标题是”Harness engineering: leveraging Codex in an agent-first world”，但正文中只提到了一次”harness”。也许这个术语是受到 Mitchell Hashimoto 最近博文的启发而后加的。无论如何，我喜欢”harness”（驾驭工具）这个词来描述我们可以用来约束 AI 智能体的工具和实践。
OpenAI 团队的 harness 组件混合了确定性方法和基于 LLM 的方法，分布在三个类别中（基于我的解读进行分组）：
-
上下文工程：代码库中持续增强的知识库，加上智能体对动态上下文的访问，如可观测性数据和浏览器导航
-
架构约束：不仅由基于 LLM 的智能体监控，还有确定性的自定义 linter 和结构测试
-
“垃圾回收”：定期运行的智能体，用于发现文档中的不一致或架构约束的违反，对抗熵和衰退
他们还强调了这个过程的迭代性：“当智能体遇到困难时，我们将其视为一个信号：识别缺少什么——工具、护栏、文档——然后反馈到仓库中，始终由 Codex 自己来编写修复。”
所有描述的措施都聚焦于提升长期内部质量和可维护性。我在这篇文章中缺少的是对功能和行为的验证。
暂且搁置这个缺口，并假设我们可以信任 OpenAI 对此的成功陈述（尊重作者和团队，但 OpenAI 确实在让我们相信 AI 可维护的代码这件事上有既得利益）——以下是我对文章已有内容的思考。
Harness——未来的服务模板？
大多数组织只有两三个主要技术栈——不是每个应用都是独一无二的雪花。这篇文章让我想象了一个未来：团队从一组针对常见应用拓扑的 harness 中选择一个来起步。这让人联想到今天的服务模板（service templates），它帮助团队在”黄金路径”上实例化新服务。Harness——带有自定义 linter、结构测试、基础上下文和知识文档，以及额外的上下文提供者——会成为新的服务模板吗？团队会以它们为起点，然后随时间推移根据应用的具体情况进行调整吗？
对于服务模板，团队在积累经验后会贡献回来，但其他团队通常难以整合更新。我们会在 harness 上看到类似的分叉和同步挑战吗？
这篇文章还让我重新审视了我的一些旧假说：
更多 AI 自主性需要约束运行时？
许多早期和当前的 AI 编码炒作都假设 LLM 会给我们目标运行时的无限灵活性。用任何语言、任何模式生成，没有约束——LLM 会搞定一切。但要想获得可维护的、可信赖的、规模化的 AI 生成代码，必须有所取舍。
所描述的 harness 表明，提高信任度和可靠性需要约束解空间：特定的架构模式、强制执行的边界、标准化的结构。这意味着放弃一些”生成任何东西”的灵活性，换取充满技术细节的提示词、规则和 harness。
技术栈和拓扑结构会趋向收敛？
当编码从”敲代码”变成”引导代码生成”时，AI 可能会推动我们走向更少的技术栈。框架和 SDK 的易用性仍然重要——我们反复看到，对人类好的东西对 AI 也好。但开发者的品味在那个细节层面将变得不那么重要。接口中的小低效和特异性也不那么烦人了，因为我们不直接和它们打交道。我们可能会选择有好 harness 可用的技术栈，并优先考虑”AI 友好度”。
这可能不仅适用于技术栈，还适用于代码库结构和拓扑。我们可能会默认选择更容易用 AI 维护的结构，因为它们更容易被驾驭。OpenAI 团队讨论了架构刚性和执行规则。我能看到的主要关注领域是保持数据结构稳定和定义并执行模块边界。听起来合理——但没有具体例子，我仍然难以想象他们 harness 中”我们要求 Codex 在边界处解析数据形状”在实践中是什么样子。
但如果我们能广泛地弄清楚如何驾驭代码库设计模式，这些拓扑结构会成为新的抽象层吗——而不是像许多 AI 爱好者所希望的那样由自然语言充当抽象层？
两个未来世界：Pre-AI vs Post-AI 应用维护？
假设我们开发出好的驾驭技术，将 AI 自主性调到 9 并增加了我们对结果的信心。哪些技术可以应用于现有应用，哪些只适用于从一开始就考虑了 harness 的新应用？
对于旧代码库，我们需要考虑改造 harness 是否值得投入。AI 可以帮助我们更快地完成改造，但那些应用通常是如此非标准化且充满熵，以至于可能不值得。这让我想到在一个从未运行过静态代码分析工具的代码库上运行它，然后被警报淹没。
你今天的 Harness 是什么？
这个团队花了 5 个月来打磨他们的 harness，说明这不是一件能快速见效的事。但值得反思你今天的 harness 是什么。你有 pre-commit hook 吗？里面有什么？你有自定义 linter 的想法吗？你想对代码库施加什么架构约束？你试验过像 ArchUnit 这样的结构测试框架吗？
最后的想法
不出所料，他们描述的工作量远远超过仅仅生成和维护一堆 Markdown 规则文件。他们为 harness 的确定性部分构建了大量工具。他们的上下文工程不仅涉及策划知识库，还涉及大量的设计工作——代码设计本身就是上下文的重要组成部分。
OpenAI 团队说：“我们现在最困难的挑战集中在设计环境、反馈回路和控制系统上。“这让我想起 Chad Fowler 最近关于”重新定位严谨性”（Relocating Rigor）的文章。听到关于严谨性应该去向哪里的具体想法和经验，而不是仅仅寄希望于”更好的模型”会神奇地解决可维护性问题，这让人耳目一新。
最后，难得我对这个领域的一个术语感到满意。虽然它才诞生两周——我大概可以屏住呼吸，直到有人把他们的单提示词、基于 LLM 的代码审查智能体也叫做 harness……