---
title: "Harness Engineering —— 初步思考"
sourceTitle: "Harness Engineering - first thoughts"
sourceUrl: "https://martinfowler.com/articles/exploring-gen-ai/harness-engineering-memo.html"
sourceAuthor: "Birgitta Böckeler (Thoughtworks)"
sourcePublishedAt: "2026-02-17"
translationMethod: "baoyu-translate skill"
language: "zh-CN"
sourceFigureCount: 0
sourceFigureAudit: "2026-07-27 抓原文 HTML 核对：正文无插图；donkey-card.png 出现两次，分别在文章头部卡片与页脚系列导航，属站点 chrome"
---

# Harness Engineering —— 初步思考

> 译注：这是一篇早期备忘录，作者后来写了一篇[更成熟的分析文章](https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html)。

*写完这篇备忘录后，我有时间做了更深入的分析，写了一篇更成熟的文章来描述 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 的方法，分布在三个类别中（基于我的解读进行分组）：

1. **上下文工程**：代码库中持续增强的知识库，加上智能体对动态上下文的访问，如可观测性数据和浏览器导航

2. **架构约束**：不仅由基于 LLM 的智能体监控，还有确定性的自定义 linter 和结构测试

3. **"垃圾回收"**：定期运行的智能体，用于发现文档中的不一致或架构约束的违反，对抗熵和衰退

他们还强调了这个过程的迭代性："当智能体遇到困难时，我们将其视为一个信号：识别缺少什么——工具、护栏、文档——然后反馈到仓库中，始终由 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……