鸭梨公共文档

主题

Harness Engineering：当 AI 光速写代码，如何防止造出屎山 ​

1. 百万行代码零人工编写的震撼 ​

2026 年初，OpenAI 发布了一篇名为《Harness Engineering: Leveraging Codex in an Agent-First World》的技术博客，披露了一个令人震惊的事实：

他们的团队使用 AI 代理构建了一个超过 100 万行代码的生产级应用，其中零行代码由人类手动编写。

这不是科幻小说的情节，而是正在发生的现实。工程师们不再编写代码，而是设计让 AI 能够可靠编写代码的系统。这个系统——包括约束条件、反馈循环、文档、代码检查工具和生命周期管理——就是所谓的 Harness（工具/约束系统）。

Harness Engineering（工具工程）由此成为一门新兴学科，它正在重新定义软件工程师的角色和技能要求。

2. 什么是 Harness Engineering ​

2.1 马具的隐喻 ​

"Harness" 一词源自马具——缰绳、马鞍、马嚼子等装备，用于引导强大但不可预测的动物朝正确方向前进。这个隐喻非常贴切：

  • AI 代理就像一匹强壮的马，能力强大但行为难以预测
  • Harness 就是约束和引导它的装备
  • 好的 Harness 既能发挥 AI 的力量，又能控制其风险

2.2 核心定义 ​

Harness Engineering 是设计使 AI 代理可靠的系统的学科，包括：

  • 约束（Constraints）：定义 AI 不能做什么
  • 反馈循环（Feedback Loops）：让 AI 知道它做得如何
  • 文档（Documentation）：为 AI 提供必要的上下文
  • 生命周期管理（Lifecycle Management）：管理代码的生成、审查、合并和维护

2.3 为什么需要 Harness Engineering ​

传统的软件工程假设代码由人类编写，而 Harness Engineering 假设代码由 AI 生成。这种转变带来了新的挑战：

代码熵增问题：AI 生成的代码会以不同于人类的方式积累技术债务。OpenAI 称之为"熵"——代理生成的代码会逐渐偏离最佳实践，产生难以维护的代码。

可维护性重新定义：传统上，可维护性意味着人类能够理解和修改代码。现在，可维护性更多地转向意图的清晰度、边界、契约和约束——这些允许人类和机器都能可靠地复现或演进系统。

规模化的 sloppy：模型移动速度快、规模化快， sloppy（草率）也会规模化。我们需要工程纪律来确保质量。

3. Harness Engineering 的三大支柱 ​

3.1 上下文工程（Context Engineering） ​

AI 代理的表现很大程度上取决于它获得的上下文。Harness Engineering 强调：

AGENTS.md 文件：在代码库根目录放置此文件，为 AI 代理提供项目概述、架构图、执行计划和质量标准。与代码一起版本控制，确保代理始终获得最新信息。

知识库维护：OpenAI 团队没有维护一个巨大的指令文件，而是构建了一个小型 AGENTS.md，指向更深入的信息源——设计文档、架构图、执行计划、质量等级——所有这些都与代码一起版本控制。

文档一致性代理：后台代理定期扫描过时的文档，并打开清理 PR——为代理准备的文档，由代理维护。

3.2 架构约束（Architectural Constraints） ​

为了防止 AI 生成"功能正确但难以维护"的代码，Harness Engineering 强调架构约束：

黄金原则（Golden Principles）：OpenAI 在代码库中编码了一套"黄金原则"——有主见的、机械化的规则，保持代码库对未来代理运行清晰和一致。例如：

  1. 优先共享工具包：优先使用共享的工具包而非手写的辅助函数，将不变量集中管理
  2. 不 YOLO 式探测数据：验证边界或依赖类型化的 SDK，防止代理基于猜测的数据结构构建代码

模块边界强制：明确约束重要的地方和不重要的地方。这类似于领导大型工程平台组织：在中央强制执行边界，在本地允许自治。

代码设计即上下文：代码设计本身是上下文工程的重要组成部分。良好的模块化设计使 AI 更容易理解和修改代码。

3.3 熵管理（Entropy Management） ​

技术债务就像高利贷——持续小额偿还总是比让债务累积然后痛苦地一次性解决更好。

垃圾回收代理：OpenAI 运行定期的"垃圾回收"代理，扫描不一致和违规，更新质量等级，并打开针对性的重构 PR。大多数 PR 可以在一分钟内审查并自动合并。

持续清理流程：人类品味被捕捉一次，然后在每一行代码上持续强制执行。这使得能够在日常基础上捕获和解决不良模式，而不是让它们在代码库中传播数天或数周。

质量等级系统：代码库中的每个模块都有质量等级，代理被鼓励优先改进低质量模块。

4. OpenAI 的实践案例 ​

4.1 团队结构转变 ​

OpenAI 的工程师团队结构发生了根本性变化：

开发者：定义"做什么"和"为什么"。他们拥有意图、业务逻辑和架构图景。

AI 代理：执行"怎么做"。它处理语法、样板代码和文档。

当开发者专注于"意图"和"环境"，让代理处理"实现"时，产出增加到每位开发者每天 3.5+ 个 PR。

4.2 实际工作流程 ​

  1. 需求澄清：工程师澄清产品行为、边界情况和规格，然后才进入实现
  2. 架构审查：审查 AI 生成代码的架构影响，而不是执行机械的连接工作
  3. 业务逻辑优化：优化需要深度领域推理的业务逻辑和性能关键路径
  4. 模式设计：设计指导代理生成代码的模式、护栏和约定
  5. 跨职能协作：与产品经理和设计师协作迭代功能意图，而不是样板代码

4.3 关键指标 ​

  • 代码产出：每位开发者每天 3.5+ 个 PR
  • 代码质量：通过持续的垃圾回收保持高质量
  • 技术债务：通过持续小额偿还控制债务累积
  • 开发者满意度：工程师专注于更高阶的工作，满意度提升

5. Harness Engineering 的行业影响 ​

5.1 工程师角色的演变 ​

Harness Engineering 正在改变工程师的工作内容：

传统工程师Harness 工程师
编写代码设计代码生成环境
调试实现调试约束和反馈循环
代码审查Harness 审查
技术决策意图和架构决策
手工重构设计自动化重构代理

5.2 行业最佳实践的收敛 ​

从 OpenAI 到 Stripe 到 OpenClaw，行业正在形成 Harness Engineering 的共识：

模型是商品，Harness 是护城河：LangChain 仅通过改变 Harness 就从基准测试的 Top 30 跃升到 Top 5，证明了 Harness 的重要性。

简单开始：一个好的 AGENTS.md 和预提交钩子比复杂的中间件更有影响力。

构建可撕掉的 Harness：过度工程会在模型改进时失效，保持适应性。

5.3 对软件工程教育的启示 ​

计算机科学教育可能需要调整课程：

  • 更多关注系统设计和架构
  • 强调约束设计和反馈系统
  • 培养"元编程"思维——编写生成代码的代码

6. 如何开始实践 Harness Engineering ​

6.1 入门步骤 ​

  1. 创建 AGENTS.md：为你的代码库创建一个简单的 AGENTS.md 文件，包含项目概述、架构图和编码规范

  2. 设置预提交钩子：使用 linter 和代码格式化工具强制执行基本规范

  3. 定义黄金原则：识别 3-5 条最重要的编码原则，写入代码库

  4. 建立反馈循环：设置 CI/CD 流程，让 AI 代理知道代码是否通过测试

  5. 启动垃圾回收：定期运行代理扫描代码库，识别和修复技术债务

6.2 进阶实践 ​

多代理验证系统：像 Antfarm 那样，使用独立的验证代理检查代码质量

文档一致性代理：让代理负责维护文档与代码的一致性

质量等级系统：为代码库模块分配质量等级，优先改进低质量模块

6.3 常见陷阱 ​

过度约束：过多的约束会限制 AI 的创造力，找到平衡点

忽视人类审查：完全自动化的流程可能引入难以发现的问题，保持人类在关键决策中的参与

静态 Harness：Harness 需要随着模型能力和项目需求的变化而演进

7. 未来展望 ​

7.1 Harness 即服务 ​

未来可能出现专门的 Harness 提供商，为不同技术栈和领域提供预构建的 Harness 模板。

7.2 自适应 Harness ​

Harness 本身可能由 AI 维护，根据代码库的健康状况和团队反馈自动调整约束和规则。

7.3 标准化 ​

AGENTS.md、WORKFLOW.md 等文件格式可能成为行业标准，类似于今天的 Dockerfile 和 docker-compose.yml。

8. 结语：从编码到驯码 ​

Harness Engineering 代表了一种思维转变——从"编写代码"到"驯服代码生成"。在这个新范式中，最优秀的工程师不是写代码最快的人，而是设计最弹性环境的人。

正如 OpenAI 团队所说："我们现在的最大挑战集中在设计环境、反馈循环和控制系统上。" 这种严谨性的重新定位，正是 Harness Engineering 的核心所在。

AI 不会取代工程师，但使用 Harness Engineering 的工程师会取代不使用它的工程师。你准备好成为 Harness 工程师了吗？

9. 参考资源 ​

  1. https://openai.com/index/harness-engineering/ - OpenAI 官方博客
  2. https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html - Martin Fowler 的深度分析
  3. https://github.com/openai/symphony - OpenAI Symphony 开源框架
  4. https://www.marktechpost.com/2026/03/05/openai-releases-symphony-an-open-source-agentic-framework-for-orchestrating-autonomous-ai-agents-through-structured-scalable-implementation-runs/ - Symphony 技术详解

10. 扩展阅读：Ralph Wiggum 循环 ​

OpenAI 在 Harness Engineering 实践中提到了一个有趣的概念——Ralph Wiggum 循环（Ralph Wiggum Loop）。这个名字源自《辛普森一家》中的角色，代表一种自我验证的循环机制。

在 Codex 的工作流程中，代理会：

  1. 审查自己的代码变更
  2. 请求其他代理进行代码审查
  3. 根据反馈进行迭代修改
  4. 直到所有审查者满意为止

这种"代理审查代理"的模式，使得人工审查的需求大幅降低，同时也确保了代码质量。正如 OpenAI 团队所说："随着时间的推移，我们几乎将所有审查工作都推向了代理对代理的处理。"