最近，我在 Latent Space 的播客中听到一个令人震撼的案例。OpenAI Frontier 团队的 Ryan Lopopolo 分享了他们过去五个月完成的一项实验：一个仅有三人的小团队，在零行人工代码的前提下，驱使 AI 编程代理（Agent）编写了超过一百万行产品级应用代码。这个系统的日消耗大约是 10 亿个 token，折合人民币近两万元。
听完后我最大的感触是：他们所描述的工作方式，与我们熟知的传统软件开发相比，已然进化成另一个“物种”。
什么是“驾驭工程”？
Ryan 提出了一个新概念——Harness Engineering，中文可以译为“驾驭工程”。他还就此撰写了一篇深度文章，在技术圈引发了广泛讨论，甚至有人认为这定义了一个新兴的工程学科。
这个概念的核心在于：工程师的工作重心，从亲手编写代码，转移到了设计和维护一套能让 AI Agent 高效工作的“缰绳系统”。你可以想象驯马的过程：马的力气和速度远超人类，但你需要一套缰绳、明确的路线和规则，才能引导它奔向正确的方向。而“Harness”正是这套缰绳。
具体而言，Ryan 团队的工作包括：
- 为 AI Agent 撰写详尽的技术规范文档。
- 定义代码架构的边界与品味标准。
- 搭建可观测性系统，让 Agent 能清晰看到自身的运行状态。
- 设计自动化的代码审查流程。
- 将“什么是好代码”这类隐性知识，显性化地写入代码仓库的文档中。
他打了一个形象的比方：我现在的角色更像是一个管理 500 人工程团队的技术总监。我不可能审查每一个 PR 的细节，我的工作是通过抽样检查来判断团队在哪里遇到了瓶颈，在哪里已经流畅运转，然后将我的注意力精准投放到最需要的地方。这种从执行者到架构师和管理者的转变，正是驾驭工程的精髓。
前一个半月是地狱，后面是天堂
Ryan 非常坦诚地表示，这个实验的前一个半月，效率比自己写代码要慢上十倍。原因是早期的模型能力有限，你让它完成一个产品功能，它常常无法独立拼装起来。
然而，他们选择了一条反直觉的道路：每当模型搞不定时，不要直接教它怎么做，而是退后一步，将大任务拆解成更小、更基础的“积木块”，让模型能够利用这些积木自行组装。这个过程异常痛苦，但一旦这些基础“积木”搭建完毕，后续的生产力便如开闸洪水般奔涌而出。
进入第二个月后，团队的产出量飙升至每人每天 5 到 10 个 PR。随着模型从 o1、o3 一路升级到最新的 GPT-5.4，每一代新模型都能处理更复杂的任务，此前需要人工介入的环节越来越少。
这揭示了一个深刻的道理：前期投入基础设施建设的时间成本，将在后期获得指数级的回报。这与我们日常工作中的很多场景相通。许多人认为搭建系统、整理流程、撰写文档是“不产出”的工作，但恰恰是这些基础工作，决定了你未来能跑多快、跑多远。
人类自己成了瓶颈
团队很快遇到了一个意想不到的瓶颈：人类自己。
当每位工程师同时驱动多个 AI Agent 并行工作时，人类的注意力跟不上了。你需要在不同的终端窗口间频繁切换，审查这个 PR、指导那个任务、处理另一个合并冲突。Ryan 坦言，每天结束时他都精疲力竭。
于是，他们做了更激进的决定：将人类也从循环中移出去。
这就是 Symphony 系统诞生的背景。Symphony 是他们用 Elixir 语言构建的一个 Agent 编排系统，可以同时管理大量 Codex Agent，自动分配任务、提交 PR、处理代码审查、修复 CI 失败、解决合并冲突。人类工程师最终只需要做一次冒烟测试，确认应用运行正常，然后点击发布。
有趣的是，选择 Elixir 语言这个决策本身是由 AI 做出的。模型认为 Elixir 的进程监督和并发原语天然适合用于 Agent 编排。Ryan 说：“我自己其实不太会写 Elixir，但这不重要了，因为我现在不写代码。”
这个细节意味深长。过去我们选择技术栈，很大程度上受限于团队成员掌握的技能。但当代码全部由 AI 生成时，语言选择便可以纯粹从技术适配性出发，选用最合适的工具，而无需迁就人类的知识储备。
代码是一次性的，知识才是持久的
Ryan 反复强调一个观点：代码是廉价的、一次性的，真正有价值的是编码在系统中的工程知识。
他们的实践方法是：每当 AI Agent 犯了一个错误，团队不仅会修复它，更会深入追问——Agent 为什么会犯这个错？它缺少了什么上下文？然后，他们就将这些缺失的知识写入文档、补充进测试用例、或制定为新的 lint 规则，确保所有 Agent 今后都不会再犯同样的错误。
例如，有一次系统因缺少网络超时设置而触发告警。Ryan 在 Slack 中直接指示 Codex 修复问题，同时要求它更新“可靠性文档”，明确规定所有网络调用都必须设置超时。这样一来，他不仅修复了一个 Bug，更将“网络调用必须设超时”这条工程规范永久性地注入了系统。
更厉害的是，他们每天会收集所有 Agent 的工作轨迹，存入 blob 存储，然后运行一个专门的 Agent 去分析：作为一个团队，我们哪里可以做得更好？如何将这些改进反馈回代码仓库？ 这样，每个人的经验就自动转化为了整个组织的集体智慧。
这给了我们更广泛的启示：在任何领域，个人的隐性知识如果不能转化为组织的显性知识，就会随着人员流动而消失。Ryan 团队所做的，本质上是以 AI 为载体，将团队的集体智慧沉淀为可执行、可传承的规则。这套思路放在企业管理、团队协作乃至个人知识管理上，都同样适用。对于关注此类人工智能前沿实践的朋友，这个案例极具参考价值。
不要给 Agent 搭脚手架，给它一个完整的世界
Ryan 对于如何设计 AI Agent 的工作环境有一套清晰的哲学。
传统的 AI Agent 框架喜欢搭建“脚手架”（Scaffold），即预先定义一组状态和转换，让 Agent 在这个框架内按部就班执行。但 Ryan 认为，对于拥有强大推理能力的最新模型，这种做法反而会限制 Agent 的发挥。
他们的做法恰恰相反：不要把 Agent 放进预设的盒子里，而是给它一个完整、真实的工作环境，让它自己决定如何行动。 例如，他们不会预先启动好开发环境再把 Agent 放进去，而是让 Agent 自行决定启动哪些服务、设置哪些环境变量、运行哪些测试。
但这并不意味着没有约束。Ryan 精准地指出：不是不给盒子，而是确保盒子里有它需要的一切。只要提供了足够丰富的上下文和工具，Agent 就能自主运转。
他们的代码仓库中有一个名为 core_beliefs.md 的文件，里面记录了团队成员是谁、在开发什么产品、目标客户是谁、未来12个月的愿景是什么。这些信息看似与代码无关，却是 Agent 理解“我们为何要这样做”的关键上下文。
这个思路与管理学中的一个经典命题如出一辙：你是选择事无巨细的微观管理，还是选择阐明目标、原则与边界，然后充分授权？ 优秀的管理者会选择后者，优秀的“驾驭工程师”同样如此。
幽灵库：一种全新的软件分发范式
Symphony 系统还催生了一个极具想象力的概念——Ghost Library（幽灵库）。
传统的开源软件分发方式，是将编译好或源代码打包，供用户下载使用。但 Ryan 团队的做法是，只发布一份极其详细的技术规范文档（Spec），然后让你本地的 AI Agent 根据这份规范，自动生成实现代码。
他们的流程是这样的：
- 让一个 Codex Agent 参照内部代码仓库写出规范。
- 让另一个 Codex Agent 根据此规范生成实现代码。
- 再让第三个 Codex Agent 对比规范与实现，找出偏差并更新规范。
这个循环反复进行，直到规范能够高保真地复现整个系统。这意味着什么？软件的分发成本被大幅降低。你不再需要发布庞大的代码库，无需处理复杂的依赖冲突，也不必担心版本兼容性问题。你只需发布一份足够精确的“蓝图”，AI 就能在任何环境中将其重建出来。
Ryan 提到，有人直接将他那篇关于驾驭工程的文章链接扔给 Codex，并指令“把我的仓库改造成这样”，效果出奇地好。文章本身成了一种可执行的规范。
OpenAI 董事长 Brett Taylor 评论说，未来的软件依赖可能会消失，取而代之的是将依赖直接内化到自己的代码中。Ryan 部分赞同这个观点，他认为目前中小规模（几千行代码级别）的依赖，已经可以在一个下午内完成内化，并且内化后你可以只保留所需部分，剔除所有通用的冗余代码。
当前模型的局限性
Ryan 也很坦率地谈了当前模型的不足。
首先是“从零到一”的产品创造。 当你有一个全新的产品构想，没有任何现成的界面原型，需要将脑中模糊的概念转化为可交互的产品时，模型目前还难以胜任。Ryan 解释说，这是因为他自己也不擅长这个，而模型的能力在某种程度上与他是“同构”的。模型缺乏的并非编码能力，而是那些尚未被清晰表述的、存在于人类脑海中的原始需求。
其次是大规模的深度架构重构。 当你需要将一个单体应用拆分为微服务，或者重新设计核心接口的形状时，模型仍然需要大量的人工引导。
但 Ryan 对未来持乐观态度。他说，仅仅在一个月前，模型还只能处理低复杂度的小任务，而现在已能处理低复杂度的大任务和中等复杂度的任务。按照这个进化速度，那些今天仍需人工介入的环节，很快也将被模型接管。届时，人类便可以将注意力转移到更高层面的战略与创意问题上去。
这向所有知识工作者发出了一个重要信号：AI 的能力边界正在快速扩张，你今天赖以生存的核心技能，可能在半年后就被 AI 覆盖。真正的持久竞争力，在于你是否能持续站在 AI 能力边界的前沿，去处理那些 AI 暂时还无法搞定的、更复杂的问题。
重新设计命令行工具：为 Agent 服务
Ryan 分享了一个实用的工程洞察：命令行工具需要为 AI Agent 进行重新设计。
传统的 CLI 输出是为人类阅读优化的，会打印大量日志、进度条和格式化信息。但对 AI Agent 而言，这些都是噪音，只会徒然消耗宝贵的 Token。Agent 只关心两件事：任务成功还是失败？如果失败，具体的错误信息是什么？
因此，他们做了大量“瘦身”工作。例如，运行测试时，压缩所有通过的测试输出，只显示失败的部分；运行代码格式化工具时，启用静默模式，Agent 无需知道哪些文件已格式化，只需知道是否存在格式不正确的文件。
Ryan 提到，GitHub 的 CLI 工具 gh 是一个很好的范例，其输出 Token 效率很高，Agent 用起来非常顺手。他甚至表示，自己现在与 GitHub 网页版的唯一交互，就是使用 gh pr view --web 快速扫一眼代码差异，然后批准合并。
这个观察指向了一个更大的趋势：当 AI Agent 成为软件的主要使用者时，所有的工具、接口、输出格式都需要被重新审视。 过去我们为人类的视觉和认知习惯优化一切，未来则可能需要同时为 AI 的 Token 窗口和推理模式进行优化。
不要赌模型会变差
Ryan 反复强调一句话：不要赌模型会变差。
他的意思是，在设计系统时，你应该假设模型的能力会持续提升。因此，你今天为模型搭建的辅助工具和约束条件，应该是那些即使模型变得更强大后依然有价值的东西，例如完善的测试、清晰的文档、坚实的架构规范。而不应该是那些模型变强后会成为累赘的东西，比如过度限制模型输出的外部脚手架。
他用了一个强化学习的类比：你应该构建 “on-policy”的驾驭系统，即顺应模型自然行为方向进行引导的系统；而不是构建 “off-policy”的系统，即强行扭转模型行为的系统。前者会随着模型进步而变得更有价值，后者则会随着模型进步而显得碍事。
这个原则在更广泛的语境下也极具启发性。当你在学习和使用 AI 工具时，与其花费大量时间研究各种 Prompt 技巧来弥补模型的当前短板，不如把精力放在理解 AI 的核心能力模式上，并设计出能随着 AI 进步而自然升级的工作流。 因为那些短板，很可能会在下一个模型版本中被修复。关于如何构建适应未来的工作流，开发者广场里常有相关的深度讨论。
写在最后
Ryan 在访谈最后说了一句充满力量的话：You can just do things. （你就是可以去做事情。）
不需要等待完美的工具出现，不需要所有条件都成熟，也不需要别人先趟出一条路。拿起现有的工具，为自己设定一个激进的约束（例如“我不亲手写任何一行代码”），然后逼迫自己寻找全新的工作方式。
五个月前，Ryan 的团队只有三个人，面对一个全新的代码库，使用的还是一个不太成熟的 AI 编程工具。五个月后，他们交付了一个百万行代码的产品级应用，定义了一个新的工程学科，并且开创了一套全新的软件分发范式。
这个故事最令人震撼之处在于，它展示了一种全新的人机协作关系。人类不再是代码的直接执行者，而是转型为系统架构师、品味的最终裁判和知识的管理者。 代码变成了一次性的、可快速生成的消耗品，而人类的判断力、系统思维以及对“何为卓越”的定义能力，成为了真正稀缺且持久的资源。
无论你是否是程序员，这一趋势都值得认真对待。因为 Ryan 团队今天在软件开发领域验证的模式，迟早会蔓延至所有知识工作领域。到那时，真正的问题将变成：你是那个仍在亲手拉磨的人，还是那个设计好缰绳与跑道，让一群骏马替你驰骋的人？
原文访谈地址：https://youtu.be/CeOXx-XTYek
发表于 1 小时前
|
查看: 6|
回复: 0
