Extreme Harness Engineering for Token Billionaires: 1M LOC, 1B toks/day, 0% human code, 0% human review — Ryan Lopopolo, OpenAI Frontier & Symphony

OpenAI 内部有个团队在过去五个月里干了件听起来很疯狂的事：他们做了一个内部产品，写了超过一百万行代码，提交了几千个 PR，但没有一行代码是人写的，也没有一行代码在合并前经过人工 review。这不是概念验证，是真实的生产系统。带队的 Ryan Lopopolo 最近发了篇长文谈 Harness Engineering，直接把这个话题推到了风口浪尖。

这个实验的起点很简单：Ryan 强迫自己不写代码，逼着 agent 必须端到端完成所有工作。早期的 Codex 慢得让人抓狂，但团队没有陷入 prompt 工程的泥潭，而是换了个思路——每次 agent 失败，他们不问"怎么让它更努力"，而是问"缺了什么能力、上下文或结构？"这个思路转变带来的结果是 Symphony，一个内部的 Elixir 实现，用来编排大量 coding agent 协同工作。关键是，他们把构建速度压到了一分钟以内，因为 agent 也需要快速的 inner loop 才能保持生产力。

最反直觉的地方在于：人变成了瓶颈。不是 token 成本，不是模型能力，是人的注意力。Ryan 的团队花了 1B tokens/day（按市场价和缓存假设，大概每天两三千美金），但他们认为如果你还没用到这个量级，基本上是"negligent"——这话说得很重，但背后的逻辑是，当 agent 可以自主完成 PR lifecycle 的时候，人应该把时间花在构建系统、observability 和上下文上，而不是盯着每一行代码。他们用 skills、docs、tests、markdown trackers 和 quality scores 把工程品味和非功能需求直接编码成 agent 能用的上下文，让 agent 自己 review、修复、合并代码。

这里面有个概念值得细说：ghost library。传统软件开发依赖共享的源代码，但在 agent-native 的世界里，你可以用高保真的 spec 让 agent 重现复杂系统，而不需要真的共享实现。代码变得 disposable，worktree 和 merge conflict 不再那么重要，因为 agent 可以自己解决。这不是说代码质量不重要，而是说质量保证的方式变了——从人工 review 变成了系统化的 observability 和自动化的验证。

Ryan 的团队现在做的事情叫 Frontier，目标是把这套玩法推到企业场景里。这不只是工具问题，是整个工作流和组织结构的重新设计。软件需要为 model 而写，就像以前需要为人而写一样。这意味着 agent legibility 比 human habit 更重要，意味着你需要重新思考 CLI 设计、policy layer、甚至公司文化怎么让 agent 理解。

当然，现在的 model 还是有明显短板。Ryan 提到 zero-to-one 的产品和复杂的 refactor 仍然是难点。但问题是，这些短板的半衰期有多长？如果每次 model release 都能处理更复杂的任务，那么今天需要人介入的地方，明天可能就不需要了。

这个实验最大的意义不是证明 agent 能写代码，而是证明了当你真的把 agent 当成 teammate 而不是 copilot 的时候，整个软件开发的范式会发生什么变化。问题是，你的团队准备好把一百万行代码的决策权交给 agent 了吗？