5 个月，100 万行代码，0 行出自人手。

这是 OpenAI Frontier 团队在一次公开访谈中透露的数字（据 Latent Space 播客）。3 个人启动，后来扩到 7 人。整个内测产品的仓库里，没有一行代码是人写的，合并前也没有人做 code review——审查工作交给了另一个 Agent。

每天烧掉 2000 到 3000 美元的 token。团队负责人 Ryan Lopopolo 说了一句话：“如果你每天没用掉 10 亿 token，那近乎于失职。”

大多数人看到这组数字的第一反应是震惊于产出量级——100 万行啊。但先别急着被这个数字唬住，后面我们会聊为什么"行数"本身说明不了太多。

真正激进的地方在别处：他们取消了两道过去被视为不可取消的人类工序——亲手编码，和合并前审查。这不是让人写得更快，是把人从生产回路里整个拿掉了。

那问题来了：人不写代码、不审代码，人干什么？

答案是三个字：管失败。

一、失败不是 bug，是工程对象

OpenAI 团队在实践中反复提到一条原则：当 Agent 失败时，正确的反应不是给它更好的 prompt，不是让它"再试一次"——而是问三个问题：

• 缺什么能力？（比如不会用某个工具）
• 缺什么上下文？（比如不知道项目的架构约定）
• 缺什么结构？（比如没有构建反馈回路告诉它哪里错了）

翻译成工程语言就是：在当前模型能力水平下，修环境比调模型更可控、回报更快。

这套方法论有了一个名字：Harness Engineering——harness 是"驾驭"的意思，核心是设计让 Agent 在其中成功运行的环境。

市面上对它的介绍，大多聚焦在"让 Agent 更高效"。但如果你仔细看 OpenAI 团队实际做的事，会发现一个更深层的逻辑：

他们不是在让 Agent 成功。他们是在系统化地管理 Agent 的失败。

文档约束的真实作用？当 Agent 不知道该怎么写时，让它有地方查——给失败兜底。

Review Agent 的真实作用？当 Agent 写出有问题的代码时，有另一个 Agent 能拦下来——给失败设防线。

1 分钟构建约束（从写完代码到知道有没有问题，不超过 1 分钟）的真实作用？缩短失败的反馈回路。Agent 1 分钟内就能知道自己错了，而不是等 10 分钟才发现。

把这三件事串起来，你会看到一个模式：Harness Engineering 的核心工作是建造一个能吸收失败、定位失败、约束失败、修复失败的系统。

失败不是意外，是工程对象。你得像管理数据库连接一样管理它——有池化，有超时，有重试策略，有熔断机制。

二、三条路线，殊途同归

有意思的是，不只 OpenAI 在做这件事。至少还有两条路线在走向类似的方向。

第一条辅线：不信任生成者。

多个 AI 实验室在工程实践中发现了同一个问题：模型倾向于高估自己生成结果的质量。你让一个 Agent 写完代码再自己评审，它大概率觉得自己写得还不错。

应对策略是把"生成"和"评估"拆成两个独立回路。写代码的 Agent 不评价自己的产出，另一个独立的评估 Agent 来判断质量，判断不通过就打回重来。

这本质上是承认"Agent 会失败"这个前提，然后建造一个不依赖 Agent 自我判断的失败检测系统。

第二条辅线更激进：重新定义什么叫"测试通过"。

传统软件工程里，“测试通过"是一个二元判断——绿了就行，红了就改。但当 Agent 同时拥有修改代码和修改测试的权限时，一个值得警惕的推演场景出现了：Agent 可以把测试改成永远通过——极端情况下，一句 return true（让测试无条件返回"成功”）就能骗过整个持续集成流水线。

这类似于强化学习中的 reward hacking——Agent 找到了绕过度量指标的捷径，而不是真正完成任务。只不过这次不是在训练环境里，是在代码仓库里。

解法是什么？把验证搬到代码库外面。不是"这组测试跑过了吗"，而是"在一个 Agent 碰不到的环境里，这段代码是否满足真实场景的需求"。

三条路线的起点和归因并不相同——一个在补环境，一个在修评估，一个在重写度量。但它们的工程动作指向同一件事：

Agent 会失败。问题不是"怎么让它不失败"，而是"失败发生后，系统怎么接住"。

如果你的回答还是"给更好的 prompt"或者"换更强的模型"，那还停留在逐案处理的阶段。这三条路线的共同启示是：把失败当作系统的常态输入来设计，而不是当作需要消除的异常。

三、我自己就在做这件事

你可能觉得这些都是顶级实验室才需要考虑的问题。100 万行代码、10 亿 token/天——离普通开发者太远了。

但我发现，哪怕在一个完全不同的场景里——用 AI Agent 写技术文章——我走过了一模一样的路。

WriteCraft 是我给自己搭的写作工程系统。简单说，它让 AI 按四个阶段产出文章：立意（确定写什么）、论证（写初稿+构造论据）、锤炼（独立评审+迭代修改）、交付（终校+发布）。每个阶段有独立的 Agent 定义文件，有明确的行为约束，有质量关卡。

举个具体的例子。早期版本里，我让 Agent 写完初稿后自己评审自己。结果它每次都说"质量不错，可以进入下一阶段"——哪怕文章里有明显的逻辑跳跃和事实错误。我的第一反应和大多数人一样：调 prompt。“请严格评审"“请不要放水”。没用。同样的 prompt，这次严格了，下次又放水。

转折点是我停止调 prompt，开始调系统：不让写初稿的 Agent 评审自己，而是启动一个全新的、没参与过创作的 Agent 来做"冷读”——它只看成品，不知道创作过程，用 6 个独立视角扫描全文。

这个改动一下子把问题暴露出来了。

现在 WriteCraft 的失败管理长这样：

行为约束预检。每次 Agent 启动，第一件事是输出一份预检清单——“我理解以下约束：观点必须经人确认、论据自造优先、品牌调性优先于模板”。这不是仪式，是强迫 Agent 把约束加载进上下文。OpenAI 团队的文档约束干的是同一件事。

独立评估回路。初稿写完后，启动独立的冷读 Agent 评审。它没参与创作，只看成品，用不同视角找问题。这和把生成器与评估器分开是同一个逻辑。

自治循环上限。Agent 可以自己修改、自己重新评审，但最多 3 轮。超过 3 轮说明系统层面有问题，不是多试几次能解决的——升级给人。

经验蒸馏。每篇文章写完后，如果发现了一个通用问题——比如"Agent 会偷偷降低评审标准"——我不是在 prompt 里加一句"请不要降低标准"，而是把这条规则编码进系统的配置文件，让它成为所有后续文章的硬约束。下次不是靠人记得，是靠系统执行。

我后来意识到，这些做法和 OpenAI 的 Harness Engineering 是同构的：

规模差了几个数量级——一个是 7 人团队每天烧几千美元 token 构建产品，一个是 1 人用 AI 写文章。但底层原理是一样的：不要试图让 Agent 不失败，要建造一个能系统化吸收失败的环境。

四、这不是银弹

话说回来，Harness Engineering 不是万能的。

OpenAI 这个实验的成功条件非常特殊：顶级模型的内部使用权限、每天数千美元的 token 预算、极强的内部基础设施能力、一个小而强的核心团队。这是 Frontier 级组织在 Frontier 资源条件下的结果，不能直接平移到普通团队。

然后是"100 万行"这个数字。我在开头用它做了钩子，但必须老实说：这个数字本身不说明太多。以前我们用代码行数评价人类工程师就很可笑——10x 工程师不是写 10 倍代码的人，而是让整个团队少写 10 倍代码的人。换成 AI 之后，我们突然又开始崇拜产出体积了。100 万行不自动等于高可维护性、低事故率、或者长期演进能力。速度和质量从来不是同一件事。

还有两个更深层的风险值得警惕。第一，Harness Engineering 本身可能导致过度工程化——为了管理失败而建造的基础设施，其成本可能比失败本身更高，尤其在小团队和低风险场景下。第二，失败系统化可能制造虚假安全感：有了评估回路和自治循环，团队可能觉得"系统会兜底"而放松警惕。但问题是——谁来评估评估器？这个递归问题没有终极答案。

对大多数团队来说，更现实的路径不是"取消人工审查，建一座暗黑工厂"，而是从一个更小的问题开始：你的 Agent 上次失败时，你做了什么？

如果答案是"调了 prompt"——试试换个思路：它失败是因为缺什么上下文？缺什么约束？缺什么反馈回路？把答案编码进系统，你就已经在做 Harness Engineering 了。

结语

Ryan Lopopolo 在访谈里说过一句话：“唯一真正稀缺的，是团队同步的人类注意力。”

代码生成是廉价产能。模型每天都在变强，写代码的成本只会更低。

但把失败关进笼子里的能力——设计约束、建造评估回路、蒸馏经验进系统、在正确的时机让人介入——这是昂贵的工程能力。它不会因为模型变强就自动出现。

工程师的位置变了：从键盘前，到系统架构旁。写代码这件事可能越来越多地交给 Agent，但决定 Agent 在哪里可以失败、失败后谁来接住——这件事，暂时还只能是人的。