5 个月，7 名工程师，100 万行代码，0 行手写代码。
 这不是科幻，这是 OpenAI 今年初发布的实验报告。
 而让这一切成为可能的工程方法，叫做 Harness Engineering。

---

一切从一个问题开始

如果你今天打开 ChatGPT、Cursor 或者任何一个 AI 编程工具，你会发现一件有趣的事：

让它写一个 50 行的函数，结果相当不错。
 让它帮你重构一个模块，还算能用。
 但如果你说"帮我开发一个完整的产品"——它要么过几轮就跑偏，要么生成一堆表面漂亮、实则脆弱的代码。

这不是模型不够聪明，而是缺少一套让它稳定工作的系统。

这正是 OpenAI 工程团队在 2025 年 8 月到 2026 年 1 月做的那个实验想解决的问题。

---

那个改变认知的实验

OpenAI 的 Codex 团队设定了一个看起来有点疯狂的目标：用 AI 自己构建一个真实的内部产品，并推向内部用户使用。

实验结果：
 - 5 个月，从零到可用的测试版产品
 - 团队规模：最初 3 人，最终扩展至 7 人
 - 代码量：约 100 万行
 - 手写代码：0 行
 - 覆盖范围：应用逻辑、文档、CI/CD 配置、可观测性、工具链——全部由 AI 智能体完成
 - 合并 PR 数：约 1500 个，全部由 Codex 自动提交

数据会说话：在高峰期，7 名工程师平均每人每天产出 3.5 个 PR。

这已经不是"AI 辅助开发"，而是真正意义上的 Agent-First 软件开发。

---

但这里有一个关键问题

这一切的前提，是你不能只给模型一个提示词，然后等着它"自己把产品做出来"。

这种朴素的想法，99% 的概率会失败。

因为模型有一些天然缺陷，不是靠调参能解决的：

缺陷	表现
无持久记忆	每次对话结束，上下文清空，不知道上次做了什么
无执行能力	不能自己运行代码、跑测试、看报错
无架构意识	不知道整个系统的边界，容易到处破坏已有结构
自我评估偏差	倾向于认为自己的输出是正确的，很少主动发现问题
上下文腐烂	任务越长，上下文窗口越满，连贯性越差，最终乱成一团

这些不是小问题，是在生产环境中大规模使用 AI 的根本性障碍。

而 Harness Engineering，正是专门解决这些问题的工程方法论。

---

什么是 Harness Engineering？

Harness，字面意思是"缰绳"、"驾驭"。

在 AI 工程领域，它指的是：

围绕 AI 智能体构建的约束机制、反馈回路、工作流控制和持续改进循环的系统工程实践。

这个概念由 HashiCorp 联合创始人 Mitchell Hashimoto 在 2026 年 2 月正式提出，随后被 OpenAI 在其工程博客中采用，并引发了整个行业的讨论。

它有一个极其精炼的公式：

$$\text{Agent} = \text{Model} + \text{Harness}$$

Model 是引擎——负责生成内容、推理、理解语言。
Harness 是整套驾驭系统——方向盘、刹车、仪表盘、安全带。

没有引擎，车跑不了。但没有 Harness，车会失控。

---

Harness Engineering 不是第一次范式跃迁

如果你接触 AI 工程有一段时间，你可能经历过这样的认知升级：

第一阶段：Prompt Engineering（提示词工程）
 学会怎么写"好的提示词"，让模型一次性输出更好的结果。
 代表实践：few-shot prompting、思维链（Chain-of-Thought）。

第二阶段：Context Engineering（上下文工程）
 光靠提示词不够了，要设计模型看到的整个上下文——RAG、记忆注入、结构化输入。
 代表实践：检索增强生成（RAG）、向量数据库、系统提示设计。

第三阶段：Harness Engineering（驾驭工程）
 上下文管理好了，但 Agent 还是跑偏。现在需要的不是"给模型更好的输入"，而是设计整个运行环境——让 AI 在结构化的系统中稳定、可靠、可预期地工作。

每一次跃迁，解决的都不是同一层的问题。

Prompt Engineering 优化的是单次调用的质量。
 Context Engineering 优化的是单个 Agent 的信息质量。
 Harness Engineering 优化的是 Agent 在系统中持续运行的可靠性。

---

OpenAI 是怎么做的？

回到那个 100 万行代码的实验。OpenAI 的工程团队构建了一套 Harness，大致包含以下几个核心设计：

1. AGENTS.md：写给 AI 的"宪法"

团队为每个代码仓库维护一个 AGENTS.md 文件，但不是把所有信息塞进去。

正确的做法是：AGENTS.md 只是一个目录，指向 docs/ 目录下的架构图、设计文档、执行计划。文档保存在 docs/ 里，成为事实唯一来源（Single Source of Truth）。

他们还设计了一个"文档园丁"Agent（Doc-gardening Agent），定期检查文档是否过时，自动修复文档与代码的不一致。

2. 分层架构约束：让 AI 不能乱动

团队定义了严格的依赖方向：

Types → Config → Repository → Service → UI

每一层只能依赖下层，不能反向。

这个规则通过自定义 Linter + CI 强制阻断来执行——Codex 自己写了检查规则，CI 流水线在合并前自动验证。如果 AI 提交了违反架构的代码，PR 直接被拒绝。

规则即法律，法律不靠人记，靠机器执行。

3. 可观测性驱动的反馈循环

Codex 智能体不是写完代码就完事了。

团队把可观测性工具（日志、指标、链路追踪）直接接入 Agent 的工具链。Agent 能看到自己代码的运行结果，能读错误日志，能追踪性能问题，然后自主修复。

这形成了一个真正的闭环：写代码 → 运行 → 观察结果 → 发现问题 → 修复。

4. 垃圾回收模式：对抗技术债

一个跑了 5 个月、合并了 1500 个 PR 的系统，技术债积累是必然的。

OpenAI 的解法是定期触发"垃圾回收"任务——专门让一个 Agent 不干别的，就去重构冗余代码、删除僵尸函数、统一命名规范。

不是人工 Code Review，是 Agent 主导的周期性系统清洁。

---

核心哲学：人类掌舵，Agent 执行

这四个字，是 Harness Engineering 最核心的价值观：

Humans steer. Agents execute.

工程师不再是那个坐在电脑前一行一行敲代码的人。

工程师的新角色是：
 - 设计运行环境（Harness 本身）
 - 明确意图（声明式提示词、架构文档）
 - 定义边界（约束规则、架构分层）
 - 提供结构化反馈（评审、纠偏、验收）

这不是降低了工程师的价值，而是把工程师的工作上移了一层。

就像航空公司的机长，不是不重要了——而是从手动拉操纵杆，变成了设置航线、监控系统、处理异常。自动驾驶越强大，机长的系统设计能力就越重要。

---

Martin Fowler 怎么看这件事？

Thoughtworks 的技术大咖 Martin Fowler 在看到这个报告后评价说：

"Harness Engineering 是对 AI 赋能软件开发的关键部分的一种有价值的框架性阐述，它整合了上下文工程、架构约束和类似'垃圾回收'的维护机制。"

注意他用的词是"关键部分"——这不是一个小技巧，而是 AI Agent 能否在生产环境中真正落地的核心问题。

---

这个系列要聊什么

Harness Engineering 是一个完整的工程体系，单篇文章只能开个头。

接下来这个系列，我们会系统拆解：

• Agent = Model + Harness

   这个公式背后，Harness 到底弥补了模型的哪些能力缺口？

• Harness 的四大护栏：上下文工程、架构约束、反馈循环、熵管理，怎么设计、怎么落地？

• Anthropic 用 Generator-Evaluator Loop 做长周期任务，为什么独立评估比自我评估更可靠？

• 五种 Harness 设计范式，从个人工具到企业级系统，每种适合什么场景？

• AGENTS.md 怎么写才是对的，文档体系怎么设计？

• 上下文腐烂、架构漂移、文档过时——这些"AI 时代的技术债"怎么治？

欢迎关注，我们下篇见。

---

本系列参考资料：OpenAI 工程博客《Harness engineering: leveraging Codex in an agent-first world》、LangChain 博客《The Anatomy of an Agent Harness》、Martin Fowler 博客《Harness Engineering》、菜鸟教程 Harness Engineering 深度解析。

·  转载授权、学习交流、合作请联系我  ·

微信 ID：hanxin1987216

加入学习社区

赶快加入吧，关注本公众号，回复“优惠券” 立减50