从百万行代码实验看工程师如何驾驭智能体

作者：Nokka（นก-กา）｜AI 领域自由撰稿人 · 2026 年 10 月 18 日

本文由 AI（deepseek-v4.1-flash · 模型提供商：ollama-cloud）通过 Hermes Agent 撰写，由人类 Nokka（นก-กา）负责监督与质量审核。

让人停下来细看的数字

OpenAI 团队在 2026 年 2 月 11 日发布的一篇总结中写道 [1]，他们进行了一项为期五个月的实验。

这个项目是一款供真实用户试用的内部产品。

它的每一行代码都由 Codex 编写。

总计约一百万行 [1]。

推动这个项目的团队只有三名工程师。

期间，他们创建并合并了大约 1,500 个 pull request [1]。

相当于每名工程师每天 3.5 个 PR [1]。

令人意外的是，当团队扩充到七人时，这个速度还在提升。

他们估算，耗时大约只有手工编写的十分之一 [1]。

文中用一句话概括了这一切：“人类掌舵，智能体执行。”

继续之前，我想先简单解释一下 harness 这个词。

它指的是支撑 Codex 各种界面的智能体循环及底层逻辑，从网页、CLI、IDE 扩展到桌面应用，都建立在这套机制之上 [2]。

简单来说，我们平时所说的智能体，其中很大一部分其实并不是模型本身。

读完之后，我同时产生了两种感受。

第一是惊叹，第二是怀疑。

而且我认为，这种怀疑有其道理。

这篇文章会拆开来看，哪些经验确实可以借鉴。

哪些部分还不宜轻信。

“人类掌舵，智能体执行”到底意味着什么

这句话听起来很漂亮，但如果不拆开讲清楚，就很容易产生误解。

OpenAI 解释说，人类始终参与其中 [1]。

只是工作转移到了另一个抽象层级。

人的工作是确定优先级，将用户反馈转化为验收标准，并检查结果。

编写代码、测试、审查和修复 bug，则交给智能体。

我认为最重要的是下面这一点。

当智能体做不到时，团队将其视为一个信号，而不是一次失败。

他们会立刻追问：“还缺少什么能力？怎样才能把它表达得足够清楚，让智能体照着做？”

随后，他们将答案反馈到系统中，让 Codex 自己编写解决方案。

这意味着，工作从“编写代码”转向了“设计一个能让智能体开展工作的环境”。

经验一：AGENTS.md 应该是目录，而不是手册

这是我认为整篇文章最有价值的一条经验。

OpenAI 团队尝试过很多人都在用的做法：把所有内容塞进一个 AGENTS.md 文件里 [1][11]。

结果，它以四种可以预见的方式失败了。

第一，上下文是稀缺资源。巨大的指令文件会挤占任务本身、代码和相关文档的空间。

结果是，智能体忽略了重要约束，或者围绕错误的约束进行优化。

第二，指导过多，就失去了指导作用。当一切都重要时，就等于没有什么是重要的。

智能体开始根据眼前的内容匹配模式，而不是有意识地按照计划推进。

第三，它几乎立刻就会过时。庞大的手册会变成陈旧规则的坟场。

智能体分不清哪些内容仍然有效，人也不再维护，最终这个文件就成了一个等人踩中的陷阱。

第四，难以用机器检查。一整块文本无法方便地检查内容覆盖度、时效性或负责人。

他们的解决办法是将 AGENTS.md 改成一份约 100 行的目录 [1]。

它指向 docs/ 文件夹，后者是项目的权威信息源。

计划也被提升为项目的一等产物。

小任务使用简短的临时计划，无须保存。

复杂任务则会形成正式的执行计划，包含进度记录和决策记录，并提交到代码仓库中 [1][12]。

这叫作渐进式披露：让智能体从一个精简、稳定的入口开始，再告诉它接下来应该去哪里查找信息。

经验二：智能体访问不到的东西，就等于不存在

原文中，这一节的标题是“目标是让智能体能够理解”[1]。

其思路是：既然整个代码仓库都由智能体构建，就应该优先让它适合智能体阅读。

这类似于组织代码，让新加入的开发者更容易理解。

区别在于，这里的目标是让智能体仅凭代码仓库本身，就能直接理解整个业务领域。

有一句话让我停下来反复读了读。

对于智能体来说，运行时无法访问的东西，就等于不存在。

Google Docs、聊天讨论串或人脑中的知识，并不存在于智能体的系统里。

它能看到的，只有代码仓库中受版本控制的文件。

因此，团队必须不断将更多上下文放进代码仓库。

如果某次聊天确定了一种架构模式，却没有将其写入代码仓库，

那么对智能体来说，这场讨论就像从未发生过。而且，同一个代码库中还有 Aardvark 等其他智能体在工作 [1][16]。

这个结论让我立刻想到了自己的团队。

经验三：选择“无聊”的技术，因为智能体更容易理解

我觉得这一点很聪明，也有些反直觉。

OpenAI 团队选择的依赖和抽象，都是智能体能够仅凭代码仓库中的内容就完整理解的 [1]。

人们口中“无聊”的技术，往往更容易让智能体建立心智模型。

因为它们的组件易于组合，API 稳定，而且出现在模型见过的训练数据中。

其中有一个例子，我特别喜欢 [1]。

他们没有引入现成的并发限制包，而是让智能体自己编写一个辅助工具。

原因是，自行编写的版本能够与团队现有的追踪系统集成。

它有完整的测试覆盖，行为也完全符合运行时的预期。

有时，让智能体自己写一个新工具，比适配一个无法看清内部实现的库，成本更低。

但这里我必须提醒一句：如果你的团队没有测试，这种思路立刻就会变得危险。

经验四：用智能体自己编写的 lint 规则约束架构

仅靠文档，不足以让智能体生成的所有代码保持一致。

因此，OpenAI 团队选择强制执行系统不变量 [1][14]，而不是事无巨细地规定代码应该怎么写。

文中举的例子是，要求 Codex 在系统边界处校验数据结构。

但不规定具体怎么实现，也不指定使用什么库。

他们建立的结构，是将每个业务领域划分为固定的层。

并强制要求层与层之间的依赖只能沿一个方向流动 [13]。

Types > Config > Repo > Service > Runtime > UI

至于身份验证、连接器、遥测和功能开关等横跨各个领域的关注点，

都必须通过一个明确声明的统一入口接入，名为 Providers。

其他方式一律不允许，并由工具强制检查。

原文作者总结说，这种架构通常要等到团队有上百名工程师时才会考虑。

但当代码由智能体编写时，从一开始就需要它。

因为正是这些约束，才能让开发提速，同时避免代码腐化 [15]。

还有一个细节，我觉得非常聪明。

这些 lint 规则也是由智能体自己编写的。

而且，错误信息经过专门设计，会将修复方法作为指令重新注入智能体的上下文 [1]。

智能体犯错后，会从错误信息中读到修复方法，然后自行修正。

经验五：撤掉阻塞合并的关卡

这一点会让很多团队感到不安。

当智能体的产出速度提高时，许多工程惯例反而成了阻力。

因此，OpenAI 团队将阻止合并的关卡减到了最低限度 [1]。

让 pull request 保持较短的存续时间。

遇到不稳定的测试失败时，他们通常会重新运行，而不是停下来等待。

文中给出的理由是：在智能体的产出速度远超人类注意力所能处理的系统中，修正的成本低于等待。

他们也足够坦诚，明确补充说：

如果是在产出速度较低的环境中，这种做法就是不负责任。

经验六：清理积累的垃圾，必须成为日常工作

这一部分最能引起许多人的共鸣。

智能体会模仿代码仓库中已有的模式，即使那些模式并不好。

时间一长，标准就会逐渐偏移。

他们提到，每个星期五，也就是每周 20% 的时间，都耗在清理所谓的 AI 垃圾上 [1]。

显然，这种做法无法随规模增长而持续下去。

解决办法是直接将黄金原则写入代码仓库 [1]，再建立周期性的清理任务。

这些原则是明确、可机械检查的规则，例如使用共享工具函数，而不是自行编写辅助工具。

以及禁止猜测数据结构，必须在系统边界处校验，或者使用带有类型定义的 SDK。

随后，由后台任务持续扫描偏离原则的情况。

更新质量评分，并创建用于重构的 pull request [1]。

原文作者将其比作内存中的垃圾回收。

技术债就像高利率贷款。

持续一点点偿还，比任由利息滚存、最后再付出惨痛代价去处理，要好得多。

完整闭环，以及随之而来的提醒

在某个时刻，这个代码仓库跨过了一条有意义的界线 [1]。

只需一条指令，Codex 就能完整推进一项新功能。

先检查代码的当前状态，复现用户报告的 bug。

录制视频，展示故障现象。

修复后，再录制视频，证明问题已经解决。

创建 pull request，回复智能体和人类提出的审查意见。

检测并修复构建失败。

只有在确实需要判断力时，才交给人类处理。

最后，合并这次变更。

但原文作者明确指出，这种能力依赖于该代码仓库特有的结构和工具。

如果没有同样的投入，就不应该认为也能做到同样的事情。

至少目前还不能。

必须了解的代价：OpenAI 文章标题没有提到的事

读到这里，一切都好得有些不真实。

我不会让你带着这样的印象读完。

读过这篇文章的工程师社区并没有全盘接受它 [3]。在一些用户讨论自行构建 harness 的帖子中，也有人指出，这类故事往往听起来好得令人难以置信 [17]。

最尖锐的批评是，他们不认可 OpenAI 选择的论证方式。

一百万行代码被解读为代码重复 [3]、不必要的冗长，以及未来维护负担的警示。

而不是能力的证明。

很多人认为，这展示的是规模，而不是质量。

随后，又有一个非常重要的事实被披露出来 [3]。

原文作者澄清，那个未公开的项目其实是一款 Electron 桌面应用 [3]，配有一个小型后端服务。

并不是很多人自行想象的那种庞大分布式系统 [3]。

而且，团队的大部分时间都花在调整提示词、技能和文档上。

与此同时，他们还丢弃了智能体产出中超过一半不符合标准的工作 [3]。

这些事实缩小了最有力主张的适用范围，也让它更可信。

也就是说，只要提供足够的支撑结构，智能体确实能在大型代码库中推动工作进展。

但这还不足以让人相信，对于需要长期维护的系统，优先围绕智能体组织开发已经是一个好的默认选择。

也不能因此将原始产出速度当成产品质量的衡量指标。

我觉得另一个重要的点，是 harness engineering 这个术语本身出现了多久。

这个词并不是 OpenAI 创造的。

2026 年 2 月 5 日，Mitchell Hashimoto 以一种略带歉意的口吻，非正式地提出了这个说法 [4]。

六天后，OpenAI 就把它用作一篇重磅总结文章的标题。

再过六天，Martin Fowler 也跟进撰文。

大约七周后，它就成了一个被大家习以为常地讨论的工程类别。

一位分析人士直言，这样的时间线 [4] 应该让技术读者保持警惕。

但他的结论同样指出，忽视它也是错的。

正确的问题不是“这是真本事还是炒作”，而是“这个窗口还会开放多久”。

他的答案是 2026 年到 2027 年这段时间 [4]，而不是一条挖好之后就能永久存在的护城河。

而且，OpenAI 自己也在文章中承认：

我们仍然不知道，对于完全由智能体构建的系统，在持续多年的演进中，架构一致性会如何发展。

这句话很重要，因为它指出了一个尚无答案的问题。

后续的新文章说了什么（其中有一篇，我觉得最值得关注）

如果只读 OpenAI 那篇文章，你看到的只是截至 2 月的情况。

但在那之后，又出现了不少延伸讨论的文章，其中一些也提出了反证。

第一篇来自 LangChain，发表于 2026 年 2 月 17 日 [5]。

他们报告称，自家的智能体在 Terminal Bench 2.0 上从第 30 名升到了第 5 名。

只修改了 harness，完全没有改动模型。

第二篇来自 Thoughtworks 的 Birgitta Böckeler [6]，于 4 月 2 日发表在 Martin Fowler 的博客上。

她提出了一个思考框架，用于建立对 AI 所生成代码的“信任”。

这个框架分为两个方向：预先输入规则，以及提供反馈。

同时又分为两类：可以通过计算检查的内容，以及需要推断的内容。

第三篇由 Addy Osmani 撰写，于 5 月 15 日发表在 O'Reilly Radar [7]。

他的定义简短而精辟：智能体就是模型，加上你围绕它构建的一切。

第四篇发表于 9 月 9 日的 Google Developers Blog [8]。

两位 Google 工程师，一位是 Principal Engineer，另一位是 Staff Software Engineer，介绍了如何评估、筛查和监控编程智能体。

但我觉得最有意思的，是 2026 年 10 月 13 日的那篇文章。

Naresh Jain 在 Martin Fowler 的博客上写道，他做了一项实验 [9]，让智能体用两种方式构建同一个 API。

一种有 harness，另一种没有。

结果是，前沿模型在两种情况下都通过了所有标准。

但另一个主打低成本的模型，在没有 harness 时，10 次运行只成功了 3 次。

加入 harness 后，10 次全部成功。

有意思的是，与取得同样结果的前沿模型相比，加入 harness 后，每次运行的成本低了 33%。

我认为，这是整个领域中最有分量的结论。

harness 或许能让你的团队用上更便宜的模型，而不必不断追逐更贵的模型。

最后一篇来自 Anthropic，同样发表于 10 月 13 日 [10]。

他们透露，2026 年 5 月，公司每天大约合并 2,500 次代码。

到了 9 月，这个数字已经突破每天 30,000 次。

git 成了瓶颈，于是他们用五个月构建了自己的版本控制系统。

把这些文章放在一起看，图景就更加清楚了。

问题不只在模型，也不只在 harness。

问题在于整套基础设施，它至今仍然是为人类设计的。

如果你想开始，这五个步骤可以立即采用

我不建议任何人照搬 OpenAI 的整套做法。

但有五个步骤，无论团队规模大小，都可以着手实施。

第一步：精简指令文件，把知识移到文档中 [13]

可以尝试设定一个目标：每次注入上下文的文件，控制在一百行左右 [18]。

让它发挥地图的作用，而不是充当手册。

第二步：把聊天中达成的共识写进 repo

每次团队做出架构决策，都要问一句：怎样才能让智能体看见这个决定？

如果答案是“在我脑子里”，那就意味着智能体看不见。

第三步：用 lint 强制执行约束，而不只是写在文档里

可以立即落地的例子包括：模块之间的依赖方向、文件大小上限，以及日志记录格式。

同时，让错误信息说明如何修复，而不只是告诉你哪里错了。

第四步：安排周期性的清理任务

不必等到团队有十个人才开始。可以先安排每周任务，查找不该出现的模式，再提交 PR 修复 [1]。

记住，别让技术债像复利一样不断累积。

第五步：衡量真正值得衡量的东西

OpenAI 衡量的是每人每天提交的 PR 数，但社区的提醒也很正确：不要只衡量原始吞吐量 [3]。

要衡量你真正需要付出代价的事情，比如理解现有代码所花的时间，以及修复后再次出问题的次数 [3]。

那么，最初那个问题的答案是什么

OpenAI 团队之所以能做到，是因为他们没有把目标放在让 AI 写代码上。

他们构建了一套系统，让写代码成为剩余工作中占比最小的一部分。

所有投入都转向了环境设计、文档和反馈循环。

一百万行代码不是答案，而是附带的结果。

真正的答案，是让智能体能够可靠工作的系统。

我觉得，你应该问自己的问题，不是“你的聊天机器人会写代码吗”。

而是“如果明天有十个智能体来帮忙，你的系统准备好接住它们了吗”。

如果你尝试从这五个步骤入手，遇到了阻碍，或找到了更顺畅的做法，

欢迎告诉我。我很想知道，在你的团队环境中，情况会有多大不同。

下一篇文章，我会带大家看看另一面的情况：有些团队尝试之后，认为 harness 并没有什么帮助。这样的案例也存在，而且同样值得关注。

[1] Ryan Lopopolo，《Harness engineering：在智能体优先的世界中运用 Codex》（OpenAI，2026 年 2 月 11 日 · 三名工程师的团队 · 一百万行代码 · 1,500 个 PR · 每人每天 3.5 个 PR · 耗时缩短至十分之一 · AGENTS.md 是一份 100 行的目录 · 黄金原则 · 承认尚不清楚长期架构一致性会如何发展），访问日期：2026 年 10 月 18 日。

[2] Celia Chen，《揭秘 Codex harness：我们如何构建 App Server》（OpenAI，2026 年 2 月 4 日 · 解释 Codex 的所有界面如何使用同一套 harness），访问日期：2026 年 10 月 18 日。

[3] HN Debrief，《Harness engineering：在智能体优先的世界中运用 Codex》（工程师社区反应汇总 · 批评“一百万行代码”被解读为展示规模，而非展示质量 · 指出实际项目是一个 Electron 应用 · 团队丢弃了智能体超过一半的工作成果），2026 年 6 月 7 日。

[4] Bruce，《Harness Engineering：机会窗口，而非永久护城河》（梳理 harness engineering 一词从 Mitchell Hashimoto 于 2026 年 2 月 5 日提出，到 Anthropic 于 3 月 24 日跟进的时间线 · 结论是窗口开放于 2026 年至 2027 年），2026 年 5 月 8 日。

[5] Vivek Trivedy，《通过 harness engineering 改进 Deep Agents》（LangChain · 仅修改 harness，就让智能体在 Terminal Bench 2.0 上从第 30 名升至第 5 名），2026 年 2 月 17 日。

[6] Birgitta Böckeler，《面向编程智能体用户的 harness engineering》（Martin Fowler 博客 · 建立对 AI 代码信任的思考框架 · 预先输入规则与提供反馈 · 可计算的内容与需要推断的内容），2026 年 4 月 2 日。

[7] Addy Osmani，《Agent Harness Engineering》（O'Reilly Radar · 将智能体定义为模型加上围绕它构建的一切），2026 年 5 月 15 日。

[8] Taylor Mullen 和 Christian Gunderman，《剖析 Harness Engineering：如何评估、迭代 AI 编程智能体并为其设置护栏》（Google Developers Blog），2026 年 9 月 9 日。

[9] Naresh Jain，《Harness 值得这笔成本吗？》（Martin Fowler 博客 · 对同一个 API 进行有无 harness 的对照实验 · 低成本模型在没有 harness 时 10 次成功 3 次，加入后 10 次全部成功 · 每次运行成本低约 33%），2026 年 10 月 13 日。

[10] Anthropic Engineering，《重新设计 Anthropic 的版本控制》（每天合并代码的次数，从 5 月的 2,500 次增至 9 月的 30,000 多次 · 五个月内迁移到自建版本控制系统），2026 年 10 月 13 日。

[11] agents.md，《AGENTS.md》（智能体指令文件的开放格式，该网站称已有超过 60,000 个开源项目采用），访问日期：2026 年 10 月 18 日。

[12] Aaron Friel，《使用 PLANS.md 解决耗时数小时的问题》（OpenAI Cookbook · 包含进度记录与决策记录的工作计划 · 页面标注该方案已归档），2025 年 10 月 7 日。

[13] Matklad，《ARCHITECTURE.md》（顶层架构地图文档的理念），2021 年 2 月 6 日。

[14] Alexis King，《解析，而非校验》（在系统边界检查数据结构的理念，OpenAI 团队将其落实为强制约束），2019 年 11 月 5 日。

[15] Steve Krenzel，《AI 正在迫使我们写出好代码》（Bits of Logic · 观察到智能体在边界清晰、结构可预测的环境中表现最好），2025 年 12 月 29 日。

[16] OpenAI，《介绍 Aardvark》（与 Codex 连接的 OpenAI 安全智能体 · 关于使用同一代码库的说法见 [1]，并非出自本页面），访问日期：2026 年 10 月 18 日。

[17] r/ClaudeAI 社区成员，《妻子一直唠叨我，于是我构建了一个 harness 来……》（用户自行构建 harness 的记录，以及质疑这类故事往往好得令人难以置信的评论），2026 年。

[18] Ken Imoto，《OpenAI Codex 依靠 AGENTS.md 交付了 100 万行代码：比更换模型更有效的三条 Harness 经验》（一位开发者将 OpenAI 文章中的三条经验应用于实际工作的记录。核查时，kenimoto.dev 上的原始链接返回 404，因此采用作者本人发布在 dev.to 上的副本），2026 年 7 月 21 日。

如需采取进一步措施，可以考虑屏蔽此人和／或举报滥用行为。