--- title: "Harness 工程：最初的思考" source: "https://martinfowler.com/articles/exploring-gen-ai/harness-engineering-memo.html" author: "Birgitta Böckeler" last_updated: 2026-04-11 tags: - concepts - harness-engineering raw_sources: - path: raw/Harness Engineering - first thoughts.md hash: "sha256:665a395b46ba1fbf3b5d3673f94437445182ab45e07c4beea9110b62c60cff59" --- # Harness 工程：最初的思考 ## 页面定位 本页是 Martin Fowler 团队关于 Harness 工程的早期思考备忘录（来源案例页）：最初动机、背景与思考脉络。负责该备忘录的原始视角；后续深化见 [[Harness-Engineering-for-Coding-Agent-Users|面向编码智能体用户的 Harness 工程]]，统一定义见 [[Harness-Engineering|Harness 工程]]。 本文是 Martin Fowler 团队关于 Harness 工程的早期思考备忘录。在撰写本文后，Birgitta Böckeler 进一步分析了这个主题，并撰写了一篇[更深入的文章描述 Harness 工程](https://martinfowler.com/articles/harness-engineering.html)。 --- ## 背景 阅读 OpenAI 最近关于["Harness 工程"的文章](https://openai.com/index/harness-engineering/)非常有趣。这篇文章描述了一个团队如何使用"完全没有手动输入的代码"作为强制函数，来构建一个用于用 AI 智能体维护大型应用程序的 Harness。经过 5 个月，他们构建了一个现在超过 100 万行代码的真实产品。 这篇文章的标题是"Harness 工程：在智能体优先的世界中利用 Codex"，但在正文中只提到了一次"harness"。也许这个术语是受到 [Mitchell Hashimoto](https://mitchellh.com/writing/my-ai-adoption-journey#step-5-engineer-the-harness) 最近博客文章的启发。无论如何，我喜欢"harness"这个词来描述我们可以用来控制 AI 智能体的工具和实践。 --- ## OpenAI 团队的 Harness 三大类别 OpenAI 团队的 Harness 组件混合了确定性和基于 LLM 的方法，分为 3 个类别（基于我的解释）： ### 1. 上下文工程 - 代码库中持续增强的知识库 - 智能体访问动态上下文，如可观测性数据和浏览器导航 ### 2. 架构约束 - 不仅由基于 LLM 的智能体监控，还包括确定性的自定义 linter 和结构测试 ### 3. "垃圾收集" - 定期运行的智能体，用于查找文档中的不一致性或架构约束的违规行为 - 对抗熵和衰减 他们还强调了这是多么迭代："当智能体遇到困难时，我们将其视为一个信号：识别缺少什么——工具、护栏、文档——并将其反馈回存储库，始终通过让 Codex 自己编写修复。" 所有描述的措施都专注于提高长期内部质量和可维护性。我在这篇文章中缺少的是对功能和行为的验证。 --- ## 思考与假设 撇开这个差距不谈，假设我们可以相信 OpenAI 对这一成功的描述（关于作者和团队，OpenAI 确实有让我们相信 AI 可维护代码的既得利益）——以下是我对文章中*实际*内容的思考。 ### Harness——未来的服务模板？ 大多数组织只有两三个主要技术栈——不是每个应用程序都是自己的雪花。这篇文章让我想象一个未来，团队从一组用于常见应用拓扑的 Harness 中挑选来开始。这唤起了今天的服务模板，它们帮助团队在"黄金路径"上实例化新服务。Harness——带有自定义 linter、结构测试、基本上下文和知识文档以及额外的上下文提供者——会成为新的服务模板吗？团队会将它们用作起点，然后随着时间的推移根据其应用程序的具体情况塑造它们吗？ 使用服务模板，团队随着获得经验而贡献回来，然后其他团队经常在合并更新时遇到困难。我们会看到 Harness 类似的分叉和同步挑战吗？ ### 运行时必须受到约束以获得更多 AI 自主权？ 很多早期和当前的 AI 编码炒作假设 LLM 会给我们目标运行时的无限灵活性。生成任何语言、任何模式，没有约束——LLM 会弄清楚的。但对于我们可以信任的大规模、可维护的 AI 生成代码，必须有所放弃。 描述的 Harness 表明，增加信任和可靠性需要约束解决方案空间：特定的架构模式、强制执行的边界、标准化的结构。这意味着放弃一些"生成任何东西"的灵活性，以换取充满技术细节的提示、规则和 Harness。 ### 收敛到有限数量的技术栈和拓扑？ 随着编码变得越来越少关于输入代码，而越来越多关于指导其生成，AI 可能会推动我们走向更少的技术栈。框架和 SDK 的可用性仍然很重要——我们反复看到，对人类有益的对 AI 也有益。但开发者的品味在那个细节级别上就不那么重要了。接口中的小低效和特质不会那么烦人，因为我们不会直接处理它们。我们可能会选择有好的 Harness 可用的栈，并优先考虑"AI 友好性"。 这可能不仅适用于技术栈，还适用于代码库结构和拓扑。我们可能会默认使用更容易用 AI 维护的结构，因为它们更容易被 Harness。OpenAI 团队讨论了架构刚性和强制执行规则。我可以看到的主要焦点领域是保持数据结构稳定以及定义和强制执行模块边界。听起来合理——但没有具体示例，我仍然很难想象"我们要求 Codex 在边界解析数据形状"在他们的 Harness 中实际上是什么样子。 但如果我们能广泛弄清楚如何利用代码库设计模式的 Harness，这些拓扑会成为新的抽象层，而不是像那么多 AI 爱好者希望的自然语言本身吗？ ### 两个未来世界：AI 前 vs AI 后应用维护？ 假设我们开发了好的 Harness 技术，将 AI 自主权调到 9 并增加我们对结果的信心。哪些技术可以应用于现有应用程序，哪些只适用于从头开始构建并考虑 Harness 的应用程序？ 对于较旧的代码库，我们需要考虑改造 Harness 是否值得付出努力。AI 可以帮助我们更快地做到这一点，但这些应用程序通常如此非标准化且充满熵，可能不值得。这让我想到在一个从未有过静态代码分析工具的代码库上运行它，然后淹没在警报中。 ### 你今天的 Harness 是什么？ 这个团队在他们的 Harness 上工作了 5 个月，这表明这不是你可以为快速结果而跳入的事情。但值得反思你今天的 Harness 是什么。你有预提交钩子吗？里面有什么？你对自定义 linter 有想法吗？你想对你的代码库施加什么架构约束？你尝试过像 ArchUnit 这样的结构测试框架吗？ --- ## 最后的思考 不出所料，他们描述的听起来比仅仅生成和维护一堆 Markdown 规则文件要多得多的工作。他们为 Harness 的确定性部分构建了广泛的工具。他们的上下文工程不仅涉及策划知识库，还涉及重要的设计工作——代码设计本身就是上下文的巨大组成部分。 OpenAI 团队说："我们最困难的挑战现在集中在设计环境、反馈循环和控制系统上。"这让我想起了 [Chad Fowler 最近关于"重新定位严谨性"的文章](https://aicoding.leaflet.pub/3mbrvhyye4k2e)。听到关于那个严谨性可能去向的具体想法和经验，而不仅仅是希望"更好的模型"会神奇地解决可维护性问题，这令人耳目一新。 最后，就这一次，我喜欢这个领域的一个术语。虽然它只有 2 周大——我可能可以屏住呼吸，直到有人把他们的单提示、基于 LLM 的代码审查智能体称为 Harness…… --- ## 相关研究 - [[Harness-Engineering-for-Coding-Agent-Users|面向编码智能体用户的 Harness 工程]] - [[Harness-Engineering|Harness 工程]] - [[OpenAI-Codex-Harness-Engineering|OpenAI Codex Harness 工程]]