三个人，管理 500 个 AI 程序员：OpenAI 正在重写软件开发这件事。

最近听了一期很炸裂的播客。Latent Space 请来了 OpenAI Frontier 团队的 Ryan Lopopolo，聊了聊他们过去五个月干的一件事：三个人的小团队，零行人工代码，让 AI 编程代理写出了超过一百万行代码的产品级应用，每天消耗大约 10 亿个 token，折合人民币差不多两万块钱一天。

听完之后我最大的感受是，这个人描述的工作方式，跟我们熟悉的软件开发已经完全是两个物种了。

1、什么是 Harness Engineering

Ryan 提出了一个新概念叫 Harness Engineering，中文可以翻译成“驾驭工程”。他写了一篇同名长文，在技术圈引发了很大的讨论，被认为可能定义了一个新兴学科。

这个概念的核心意思是：工程师的工作重心，从亲手写代码，转移到了设计和维护一套让 AI 代理高效工作的“缰绳系统”。你可以把它想象成驯马。马的力气比你大得多，跑得比你快得多，但你需要一套缰绳、一条路线、一组规则，让它朝着正确的方向跑。Harness 就是这套缰绳。

具体来说，Ryan 团队做的事情包括：给 AI 代理写好详细的技术规范文档，定义代码架构的边界和品味标准，搭建可观测性系统让代理能看到自己的运行状态，设计自动化的代码审查流程，以及把所有“什么是好代码”的隐性知识显性化地写进仓库里。

他打了一个很形象的比方：我现在的角色更像是一个管理 500 人工程团队的技术总监。我不可能盯着每一个 PR 的细节，我要做的是通过抽样审查来判断团队在哪里遇到了困难，在哪里已经跑得很顺，然后把我的注意力转移到真正需要我的地方。

2、前一个半月是地狱，后面是天堂

Ryan 很坦诚地说，这个实验的前一个半月比自己写代码慢了十倍。因为早期的模型能力有限，你让它做一个产品功能，它根本拼不起来。

但他们没有放弃，而是选择了一条很反直觉的路：每次模型搞不定的时候，不要去教它怎么做，而是退后一步，把任务拆成更小的积木块，让模型能用这些积木自己拼装。这个过程很痛苦，但一旦这些积木搭好了，后面的生产力就像开了闸一样。

到了第二个月之后，团队的产出量飙升到每人每天 5 到 10 个 PR。而且随着模型从 o1、o3 一路升级到最新的 GPT-5.4，每一代模型都能处理更复杂的任务，之前需要人介入的环节越来越少。

这里面有一个很深刻的道理：前期投入建设基础设施的成本，会在后期以指数级的方式回报你。这跟我们日常工作中的很多场景其实是相通的。很多人不愿意花时间搭建系统、整理流程、写文档，觉得这些事情“不产出”。但恰恰是这些看起来不产出的工作，决定了你后面能跑多快。

3、人类变成了瓶颈

团队很快遇到了一个意想不到的问题：人类自己成了瓶颈。

当每个工程师同时驱动多个 AI 代理并行工作的时候，人的注意力跟不上了。你要在不同的终端窗口之间来回切换，审查这个 PR、指导那个任务、处理另一个合并冲突。Ryan 说他每天结束的时候都精疲力竭。

于是他们又做了一件事：把人也从循环里移出去。

这就是 Symphony 诞生的背景。Symphony 是他们用 Elixir 语言构建的一个代理编排系统，可以同时管理大量的 Codex 代理，自动分配任务、自动提交 PR、自动处理代码审查、自动修复 CI 失败、自动解决合并冲突。人类只需要在最后做一次冒烟测试，确认应用能正常运行，然后发布。

有意思的是，Elixir 这个语言选择本身就是 AI 做出的。模型认为 Elixir 的进程监督和并发原语天然适合做代理编排，所以自己选了这个语言。Ryan 说，我自己其实不太会写 Elixir，但这不重要了，因为我又不写代码。

这个细节特别值得玩味。过去我们选技术栈，很大程度上取决于团队成员会什么语言。但当代码全部由 AI 来写的时候，语言选择就可以纯粹从技术适配性出发，选最合适的工具，而不用迁就人的技能树。

4、代码是一次性的，知识才是持久的

Ryan 反复强调一个观点：代码是廉价的、一次性的，真正有价值的是编码在系统中的知识。

他们的做法是，每当 AI 代理犯了一个错误，团队不会只是修复这个错误，而是会追问：代理为什么会犯这个错？它缺少了什么上下文？然后把这个缺失的知识写进文档、写进测试、写进 lint 规则里，让所有代理以后都不会再犯同样的错。

举个例子，有一次系统因为缺少超时设置而报警。Ryan 在 Slack 里让 Codex 修复这个问题，同时要求它更新可靠性文档，规定所有网络调用都必须设置超时。这样一来，他不仅修了一个 bug，还把“网络调用要设超时”这条工程规范永久地注入了系统。

更厉害的是，他们每天会把所有代理的工作轨迹收集起来，存到 blob 存储里，然后跑一个代理循环去分析：作为一个团队，我们哪里可以做得更好？怎么把这些改进反映回代码仓库？这样，每个人的经验就自动变成了所有人的经验。

这让我想到一个更广泛的启示。在任何领域，个人的隐性知识如果不能变成组织的显性知识，就会随着人员流动而消失。Ryan 团队做的事情，本质上是用 AI 作为载体，把团队的集体智慧沉淀成了可执行的规则。这个思路放到企业管理、团队协作、甚至个人知识管理上，都是成立的。

5、不要给代理搭脚手架，给它一个完整的世界

Ryan 对如何设计 AI 代理的工作环境有一套很清晰的哲学。

传统的 AI 代理框架喜欢搭“脚手架”（scaffold），就是预先定义好一组状态转换，让代理在这个框架里按部就班地执行。但 Ryan 认为，有了推理能力强大的模型之后，这种做法反而限制了代理的发挥。

他们的做法是反过来的：不要把代理放进一个预设的盒子里，而是给它一个完整的工作环境，让它自己决定怎么做。比如，他们不会预先启动好开发环境再把代理放进去，而是让代理自己来启动整个技术栈。代理可以选择启动哪些服务、设置哪些环境变量、运行哪些测试。

但这不意味着没有约束。Ryan 说得很精准：不是不给盒子，而是确保盒子里有它需要的一切。上下文和工具，这两样东西给够了，代理就能自主运转。

他们的代码仓库里有一个叫 core_beliefs.md 的文件，里面写着团队成员是谁、在做什么产品、目标客户是谁、未来 12 个月的愿景是什么。这些信息看起来跟代码无关，但它们是代理理解“为什么要这样做”的关键上下文。

这个思路其实跟管理学里的一个经典命题一模一样：你是选择事无巨细地微观管理，还是选择把目标、原则和边界讲清楚，然后放手让团队去干？好的管理者选后者，好的 Harness Engineer 也选后者。

6、Ghost Library：一种全新的软件分发方式

Symphony 还带来了一个很有想象力的概念，叫 Ghost Library，幽灵库。

传统的开源软件分发方式是把代码打包好，你下载下来直接用。但 Ryan 团队的做法是只发布一份详细的规范文档（spec），然后让你本地的 AI 代理根据这份规范自动生成实现代码。

他们的流程是这样的：先让一个 Codex 代理参照内部仓库写出规范，再让另一个 Codex 代理根据规范生成实现，再让第三个 Codex 代理对比规范和实现，找出偏差并更新规范。这个循环反复跑，直到规范能够高保真地复现整个系统。

这意味着什么呢？软件的分发成本大幅降低了。你不需要发布一个庞大的代码库，不需要处理依赖冲突，不需要担心版本兼容。你只需要发布一份足够精确的“蓝图”，AI 就能在任何环境里把它重建出来。

Ryan 说，有人直接把他那篇 Harness Engineering 的文章链接丢给 Codex，说“把我的仓库改成这样”，效果出奇地好。文章本身就变成了一种可执行的规范。

OpenAI 的董事长 Brett Taylor 看完之后评论说，软件依赖可能要消失了，以后可以直接把依赖内化到自己的代码里。Ryan 部分同意这个观点，他认为目前中小规模的依赖（几千行代码级别）已经可以在一个下午内完成内化，而且内化之后你可以只保留自己需要的部分，去掉所有通用化的冗余。

7、模型还做不到什么

Ryan 也很坦率地谈了当前模型的局限性。

第一个是从零到一的产品创造。当你有一个全新的产品想法，没有任何现成的界面原型，需要把脑子里模糊的概念变成可以交互的产品，模型目前还做不好。Ryan 说，这是因为他自己也不擅长这个，而模型的能力跟他是同构的。模型缺的不是编码能力，而是他脑子里那些还没说出来的需求。

第二个是大规模的深度重构。当你需要把一个单体架构拆分成微服务，或者重新设计核心接口的形状，模型还需要大量的人工引导。

但 Ryan 对未来很乐观。他说，一个月前模型还只能处理低复杂度的小任务，现在已经能处理低复杂度的大任务和中等复杂度的任务了。按照这个速度，那些今天还需要人介入的环节，很快也会被模型接管。到那时候，人类就可以把注意力转移到更高层面的问题上去。

这里面隐含着一个对所有知识工作者都很重要的信号：AI 能力的边界在快速扩张，你今天赖以安身立命的技能，可能半年后就会被 AI 覆盖。真正持久的竞争力，在于你能不能持续地站在 AI 能力边界的前面，去处理那些 AI 还搞不定的问题。

8、让 CLI 为代理服务，而不是为人类服务

Ryan 分享了一个很实用的工程洞察：命令行工具（CLI）需要为 AI 代理重新设计。

传统的 CLI 输出是为人类阅读优化的，会打印大量的日志、进度条、格式化信息。但对 AI 代理来说，这些都是噪音，白白消耗 token。代理只关心两件事：成功了还是失败了？如果失败了，错在哪里？

所以他们做了很多“瘦身”工作。比如运行测试的时候，把所有通过的测试输出都压掉，只显示失败的部分。运行代码格式化工具的时候，加上静默模式，代理不需要知道哪些文件已经格式化好了，它只需要知道有没有格式不对的文件。

Ryan 还提到，GitHub 的 CLI 工具（gh）是一个很好的范例，token 效率很高，代理用起来非常顺手。他甚至说，自己现在跟 GitHub 网页版的唯一交互就是用 gh pr view --web 快速扫一眼 diff，然后就批准合并了。

这个观察其实指向了一个更大的趋势：当 AI 代理成为软件的主要使用者时，所有的工具、接口、输出格式都需要重新审视。过去我们为人类的眼睛和大脑优化一切，未来可能需要同时为 AI 的 token 窗口和推理能力优化。

9、不要赌模型会变差

Ryan 反复提到一句话：不要赌模型会变差（Don‘t bet against the model）。

他的意思是，你在设计系统的时候，应该假设模型的能力会持续提升。今天你为模型搭建的辅助工具和约束条件，应该是那种模型变强之后依然有价值的东西，比如测试、文档、架构规范。而不应该是那种模型变强之后就会变成累赘的东西，比如限制模型输出的外部脚手架。

他用了一个强化学习的类比：你应该构建“on-policy”的 harness，也就是顺着模型自然行为方向去引导的系统，而不是“off-policy”的 harness，也就是强行扭转模型行为的系统。前者会随着模型进步而变得更好，后者会随着模型进步而变得碍事。

这个原则放到更广的语境下也很有启发。当你在学习和使用 AI 工具的时候，与其花大量时间去研究各种 prompt 技巧来弥补模型的短板，不如把精力放在理解 AI 的核心能力模式上，然后设计出能随着 AI 进步而自然升级的工作流。因为那些短板，大概率会在下一个版本被修复。

10、写在最后

Ryan 在访谈最后说了一句很有力量的话：You can just do things. 你就是可以去做事情。

不需要等完美的工具出现，不需要等所有条件成熟，不需要等别人先趟出一条路来。拿起现有的工具，设定一个激进的约束（比如“我不写任何一行代码”），然后逼自己找到新的工作方式。

五个月前，Ryan 的团队只有三个人，面对一个全新的代码库，用一个还不太成熟的 AI 编程工具。五个月后，他们交付了一个百万行代码的产品级应用，定义了一个新的工程学科，还开源了一套全新的软件分发范式。

这个故事最让我震动的地方在于，它展示了一种全新的人机关系。人类不再是执行者，而是架构师、品味裁判和知识管理者。代码变成了一次性的消耗品，而人类的判断力、系统思维和对“什么是好”的定义，成了真正稀缺的资源。

不管你是不是程序员，这个趋势都值得认真对待。因为 Ryan 团队今天在软件开发领域验证的模式，迟早会蔓延到所有知识工作领域。到那时候，问题就变成了：你是那个还在亲手拉磨的人，还是那个设计好缰绳、让一群骏马替你跑的人？

#科技先锋官# #How I AI#