编者按：当 AI 能写出海量代码时，我们如何确保代码可信、可维护、能交付？OpenAI 工程师 Ryan Lopopolo 及其团队近数月来，没有手写过一行代码，也未人工审查过一行代码，而是推行“Harness Engineering”，让 Agent 自主完成从需求到 PR 的全流程。随着 GPT-5 系列迭代，人均 PR 吞吐量从每周 3.5 个飙升至 70 个。这篇文章基于 Ryan 在《AI Native Dev》播客的分享整理，深入探讨了这种激进的工作模式。
核心观点如下：
- Harness Engineering 的核心在于，要让 Agent 写出我们信任、能支撑业务信心的代码，需要把无数微小的决策“写下来”，让它们成为可复用的上下文。
- 随着代码库中的上下文与能力不断累积，每一位通过 Codex 进入仓库的新成员，都能即刻获得团队的最佳实践，而无需像过去那样花费数月去融合吸收。
- 正如我们希望新人从错误中学习一样，我们也希望看到 Agent 犯的错误。这样，作为监督者的我们，才能想办法教会它们。
- 软件工程师的核心技能不再是“编写代码”，而是系统思维：为团队成功创造条件、前瞻性地解决问题、提升从代码到客户交付的速度。
零人类手写代码
Simon：什么是 Harness Engineering？
Ryan： 我们手头这些神奇的编程 Agent 和极其智能的模型，能产出海量代码。但 Harness Engineering 的中心思想是：要产出我们认可、信任并确信能交付业务的代码，背后有大量微小决策需要落地。为了让 Agent 掌握这些，我们必须将它们书写下来。让所有关于“好代码”的非功能性需求，能在正确的时间点被 Agent 看到，确保生成的每一行代码都遵循我们生产高质量软件的“金线”。我们会评审、测试、lint，用过大型重构循环等各种方式让 Agent 闭环自证——它产出的代码是可接受的，可以合并。
Simon：提示工程、上下文工程与 Harness Engineering 有何区别与重叠？
Ryan： 与 Agent 交互时，你只有两个操作杆：提供什么上下文，给予什么工具。Harness Engineering 本质上是这两者的结合，目标是确保给 Agent 的上下文正确，让它发挥推理魔力生成好代码。但真正特殊的是：我们实际上在利用工具调用对 Agent 进行“提示注入”，以此管理其上下文窗口。我们在代码库中组织测试与 lint 的方式，和为人类组织信息截然不同。对人，我能给出详尽的失败清单；但 Agent 截然不同——由于 Agent 调用工具的机制，传递给它的消息需要既紧凑又富含语义。我绝不会给 Agent 一条机读的 eslint 报错，而是用自然语言描述：“你在文件 X 中搞错了，打开它，参照文件 Y 的手册去修——你之前犯过同样错误，且我们知道你有能力处理好。”
Simon：你曾在 Stripe 组建效率工程团队，在 Brex 主导 350 人团队的生产力，这些经验对做 Harness Engineering 是帮助还是掣肘？
Ryan： 绝对是巨大的帮助。它让我习惯了“通过他人工作”的思维模式。当我试图提升一个 350 人的工程组织的效率时，我没法亲力亲为去检视每个 PR 的细枝末节。我必须隐藏在幕后引导，确保正确的事情自然发生。高度的信任源自一个正确的系统预设。而这一点，正是与 Agent 高效协作、超越结对编程进入大规模并行模式（比如我同时开着 15 个团队窗口）所需要的心态。这种系统化的思维和运作方式，对我来说很自然，因为它们是我整个职业生涯赖以成长的专长。
Simon：你给自己和团队设定了一条极其激进的约束：零手写代码。做这个决定的当下，你害怕吗？你有多大把握它是正确的方向？
Ryan： 这绝对是个激进的想法。我刚开始这么干的时候，甚至还没有像样的推理模型。GPT-5 是 2025 年 8 月发布的，而我在 6 月就已步入这种“放手”模式了。那是 O3 的时代，Codex Mini 刚面世，Codex CLI 还是第一个版本。坦率地说，当时模型的能力差远了，用这种方式运作痛苦不堪。无奈之下，我必须把自己变成一个“笨重的工具”，当 Agent 卡住时可委托给我。起初，它能做的唯一一件事就是“让 Ryan 来帮忙”。很快我就厌倦了被不断要求做同样的事。比如它总是让我用 Cargo 装依赖，这是 Codex 当时无法可靠完成的。自动化这件事成了我的第一步，它让我进入了一种状态：密切关注自己的时间投入，然后想方设法构建一个工具调用来消除这种消耗。
从零开始这样做，你会亲身经历 Agent 的每一次失败。看着它写代码，亲眼见证它会在哪里出错，也能洞察它真正擅长什么。Codex 极其擅长遵循指令，也极为擅长编写并执行测试。因此，把大量工程流程压缩成这些“铺好的路径”，让我对 Agent 的信心逐步建立起来。
Simon：你说它擅长遵循指令、写测试——这不恰好是大多数开发者的反面吗？团队里其他人对这种零代码的决策接受度如何？
Ryan： 很幸运，我们扩张团队时招募的全是新人。这些新成员直接掉进了这个疯狂的环境里，心想“哦，原来我们就是这么干活的”，然后一头扎了进去。早期最痛苦的是如何指导大家不产出“垃圾代码”，但一旦我们摸索出门道，到我们招到第五、六、七号成员时，在最初两周内，我们就可以看到 PR 吞吐量提升了 5%、10%、15%。这根本不是团队快速扩张时的通常轨迹。原因在于，随着我们在代码库中不断累积上下文与能力，每一位通过 Codex 作为唯一入口进入仓库的人，默认就能获取所有人的最佳实践，而不是像传统团队那样，新人需要花费一到三个月去吸收那些“隐形”的智慧。这些东西已经被“铺”在代码库里了。这意味着新成员能极快地贡献自己的最佳判断与上下文，每个人的效率都能飞速提升。
Simon：所以你们实际上是在用 Agent 给新人“入职”？
Ryan： 没错。
零人类代码审查
Simon：有个说法很妙：“只有有了刹车才能飙快车”。现在，“快车”就是让 Codex 以比手动快得多的速度生成代码，而“刹车”就是测试、评审——它们验证代码，并标记出我们在交付前需要修整的地方。另一个有趣的点是“零人类代码评审”，这简直是把 AI 当刹车用了。工程师们对让 Agent 来做评审的接受度究竟如何？
Ryan： 其实，合并后审查这个概念本身并不新鲜。2010 年代初我刚入行时，这就是写软件的常态，团队内部高度信任，倾向行动和吞吐量，只随机抽查部分代码。除此之外，还需要大量的同步沟通，确保所有人对系统持有相同的心智模型。现在，Agent 让这种做法又流行回来了，这很酷。因为如果代码库的入口永远是 Agent，那么团队里每位工程师实际上不需要对系统有完整的心智模型，他们只需信任队友们正让 Codex 保有那种专业水准即可。
有一点需要澄清的是，系统里并非完全没有审查。我们确实在某些场景下要求传统的双人预合并审查，主要集中在高度复杂的计划、跨周的里程碑这类事情上。原因很简单：这些计划、里程碑和执行文档，本质上就是你要提供给 Agent 的提示词。如果你依赖文本文档来驱动实现，那文档里的措辞是否精确、描述是否充分，就变得至关重要。如果你一开始就没把任务描述清楚，最终得到的就是垃圾。所以，我们把人工审查的重点前置到了这里，而非逐行的代码审查上。
Simon：所以这里的审查和我们通常理解的代码审查截然不同，它是前置的。传统代码审查常纠缠于细节、命名、风格指南之类的东西。而现在，我们着眼的是更高层次的设计，这可能是因为审查高层设计本身就更有趣——我们能提供更有意义的输入，思考自己能在此贡献的最大价值。但同时，我们也离代码本身更远了，以至于在某种程度上必须选择信任。或者说，深入实现细节近乎是在浪费时间，因为我们更需要将这些抽象化，需要有机制让测试自动运行来确保成功。
Ryan： 没错，这又回到了那种“团队技术主管”的心态。我当年在 Brex 负责开发者生产力时，我从不管每个团队具体怎么写每一行 Terraform 代码。但我非常关心高层的指导原则——我希望基础设施可复现，要能快速部署，要用模块解决常见开发者工作流。但你底层模块具体如何组织，哪怕代码只在局部内聚，实际解决了业务问题，我其实都不太在意。
Simon：你和团队是在哪个阶段真正感到：“我完全信任这套机制了”？
Ryan： 我觉得有两个阶段。第一个阶段是：我是否信任 Agent 能产出代码？那个魔幻时刻发生在我和队友一起开发 Codex 应用早期版本的时候。我当时想，“天啊，我要是能语音输入就好了”。然后我给机器一个提示词，半小时后，这个想法就在真实应用里跑起来了。那感觉无与伦比，你瞬间获得了信心：只要我安排提示词的节奏足够好，这个“魔法机器”就能将我的愿景变成现实。这就是第一步，进入那种心态：作为工程师，我们的角色应该是想办法喂养机器、安排工作，让愿景得以落地。
第二阶段是：这代码值得信任吗？质量足够高吗？当我们把第三位工程师招进团队时，PR 吞吐量猛然飙升，但我们根本来不及审查，也无力保证“垃圾代码”不会混进代码库。所以我们开始踩刹车，每周五搞“垃圾回收”，开大量的长时同步站会，把这些心智模型社会化。我们倾向吞吐量，倾向合并，但同时得守住质量底线。每个周五都在努力清除垃圾，同时寻找系统性的方式去消灭它，绝不想给出两次同样的反馈。于是，这逐渐累积成了一种程序化的护栏，以及一个非常长的外循环——它由自动化 CI 任务构成，专门查找垃圾代码、识别垃圾代码，然后编译出一份好代码的“金线原则”，再找出代码库中违背这些原则的地方，自动提交 PR。到那一刻我们才看到：原来，Agent 确实能以我们期望的方式编写代码，我们只需要设置正确的循环和系统，让它自己关闭反馈回路。
Simon：这是通过上下文或者 Skill 之类的东西提供给它的吗？
Ryan： 那还是 skills 功能出现之前，大概八个月前吧。我们用的手段相当廉价：建一个 GitHub issue，工程师和 Agent 都可以在里面留言，记录底层的软件开发原则。这个 issue 越堆越大，最终变成了一篇有 100 到 150 条评论的巨型帖子。这个帖子就成了“种子”，Agent 以此爬遍整个代码库，对违规行为进行优先级排序，然后提交 PR。
一开始我们完全不信任它。我们设了一个 on-call 值班，专门监督所有 Agent 产出的内容。值班员做的就是人工“点赞/点踩”：合并或不合并，留下评审反馈。这样一来，下一次反垃圾循环启动时，它就会审视自己之前产出的所有 PR，吸收这些人类反馈，并与上次运行的会话日志作对比。它会自我拷问：我犯了哪些错？遗漏了哪些优先级？产出了不对齐的代码吗？为什么？然后它自己找出不再犯同样错误的办法，生成一些 Markdown 文档，保存到 GitHub 运行记录里。于是下一次运行时，它就拥有了一份额外的、从系统中真实人类反馈学来的上下文。
Simon：那这是正确的方式吗？你会推荐其他人也这样搭建 Agent 迭代流程吗？是先写代码，然后事后审计、审查，还是现在你已经更倾向于在代码生成时就嵌入这些规则？
Ryan： 两者结合。我们确实认为这些异步循环是高效工作的核心组成部分。早期的 Codex Security 项目也是同样的工作方式：代码合并到主分支后，安全审查才介入，找到漏洞后生成补丁、提 PR、审查、合并。这种流程的好处在于，它允许错误真正流进主分支，而这些错误是可供学习的。每当我们能够提出一个修正时，除了修复问题本身，我们也会通过 Agent、循环、蒸馏来识别重复的模式——这些正是我们希望更早拉入流水线的东西。
Simon：当你确实把错误推送到生产环境时，现在会不会没那么害怕了？因为你知道 Agent 能很快地审查并修复它们？
Ryan： 这确实是一个光谱。说实话，这个项目我们并没有做持续部署。我们在构建一个原生应用，手动切发布分支，做冒烟测试。冒烟测试起初全部由人工完成，然后我们观察时间花在哪儿，再尝试让 Agent 接手一部分。但在这个世界里，我认为对发布流程保持一定水平的人工监督仍然很重要。
不过，如果我戴上团队技术主管的帽子，有些错误完全是可以犯的，它们的后果很低。正如我希望成长中的工程师从自身错误里学习一样，我真切地希望看到 Agent 犯的错误。如此一来，作为监督者，我们才能找到方法让它们也学明白。
在代码生产成本如此低廉的新世界里，我认为你可以把 DevOps 的左移策略彻底翻转过来。现在成本最低的事，就是修改我的提示词。这是修正生成代码最便宜的方式。如果发现更系统化的错误模式，我再考虑进一步左移：添加文档，或者部署一个审查 Agent，让它按这些文档去评判每一个 PR。甚至可以做更彻底的左移——编写确定性测试来自动捕获这类行为，越早越好。但出发点永远是用最少的精力去压止不良行为，因为这些模型是神奇的推理者。多数情况下，只需我付出极少的努力，它们就能做得非常好。
SPEC 驱动的未来
Simon：你刚才描述的那种“通过修改提示词就能改变整个实现”的方式，让我觉得真正持久留存的东西不再是代码，而是我们的提示词、上下文和功能需求。这让我想到了 Symphony，一个“幽灵库”——它本质上就是 SPEC 和上下文，而不是实现或代码。当我们这么想时，代码就成了一个一次性产物，今天的实现明天就可能面目全非。真正持久、值得我们投入最多时间的，是 SPEC 和提示词，这是未来的方向吗？当我们思考 SPEC 与代码的关系时，这种关系正在发生多大程度的变化？
Ryan： 想想传统的 SPEC 驱动开发：你从 SPEC 开始，然后在代码产出过程中不断细化它。但对于 Symphony 这样的项目，我实际上发现，先产出代码要容易得多。让代码先摊出一个“稻草人”，一个关于世界可能长什么样的初始版本，然后团队围绕它讨论、改进，最后再从中提炼出 SPEC 来。因为产出的工件——无论是代码、电子表格还是 Google 文档——它们在决策密度上极高，这些决策全是为了产出我们认可为“好”的东西而做出的。
所以对于 Symphony，我们最终交付的东西本质上是一个 SPEC，但我们的起点却是在 monorepo 里用 TypeScript 写的一个“感觉对了”的实现版本。当我们觉得它不错了，才开始从中产出 SPEC，分享给世界。这过程非常酷，我们有一个三阶段的流水线：
第一阶段，我们把 Symphony 的原始实现交给 Codex，让它生成一个 SPEC Markdown 文件，这个文件需能够复现此系统。第二阶段，我们拿着这个 SPEC，交给一个全新的、无权访问原始代码的 Agent，说：“这是 SPEC，请实现。”第三阶段，当它说“完成”后，我们把新系统、SPEC 和原始实现一并交给第三个 Agent，让它做裁判：“派生工件与原始系统之间有哪些不一致？请提出对 SPEC 的修改建议，以便下一次尝试做得更好。”
这是一个极其消耗 Token 的过程。但最终，你获得的是一个高度精炼的 SPEC，它能可靠地复现原始系统，同时依然为这个“幽灵库”的消费者留足了空间和歧义性，让他们可以根据自己的实际业务上下文去适配。我认为这极其酷，因为它意味着我们能在业务逻辑、关键部分上达到极其紧凑、高精度的 SPEC，并同时保留灵活性。
Simon：我喜欢你描述的这个过程，一个非常纯粹的原型：快速开发出应用程序，从中获取经验。但区别在于，因为开发成本极低，现在可以说：“我可以直接扔掉它。”我不会被诱惑去保留那个半成品，而是把我学到的一切和功能需求都提炼到那份 SPEC 里去。
Ryan： 其实这个过程并不新鲜。回想我职业生涯里的其他领域，比如与数据科学团队合作时，他们会在 Jupyter Notebook 里拼凑出一个模型先验证想法。一旦对结果有了信心，就交给工程团队去生产化。又或者我们在 Figma 里快速设计原型，然后交给团队生产化，也是同样的背景。但现在，因为代码的生产成本变得极其低廉，我们可以在生产系统中直接做这件事了。
我们在构建的应用中有一个很酷的实践——在 Dev Electron 应用里，我们设了一个窗口，Agent 可以启动它。这个窗口提供了我们正在交付的原生渲染画布，以及完整的设计系统和组件库。这意味着 Agent 能直接在即将部署的界面上快速制作新屏幕的原型，生成截图，交给我们的设计师。这就形成了一个超级紧凑的反馈循环：我们的愿景是否与现实匹配？我们能否在将要发布的界面中实现这种体验？
Codex 的演进
Simon：最近在社交媒体和社区讨论中，大家对 Codex 的行业认知发生了巨大变化。我听到很多人都在称赞 Codex，从其他知名的 Agent 迁移到 Codex 上。这到底是某个特定功能让 Codex 实现能力跃升，还是团队持续积累的成果？
Ryan： Codex 的产品迭代速度极快。我们刚刚庆祝了一个里程碑：周活跃用户突破 500 万。Codex 的开发与研究团队之间存在着一个非常紧密的良性循环，这是一个奇妙的飞轮。GPT-5 系列的每一个小版本迭代，Codex 的能力都在实现飞跃式提升。从 5.2 到 5.3，最大提升来自后台工具调用和并行工具调用。这意味着 Codex 能同时做更多事，在更复杂的需求上推进更快。到了 5.4 版本，普通 GPT-5 模型与 Codex 模型的统一带来了质变：你不仅得到了一个超强的代码生成 Agent，它还同时拥有极其强大的通用智能和文本能力，这意味着我可以用 Codex 来处理软件开发流程中除写代码之外的所有环节。比如我今天晚些时候要演示的幻灯片，100% 由 Codex 利用 Google Sheets 的应用连接器生成，这在去年我根本不敢想象。而在 5.5 版本中，计算机使用和内置浏览器功能的出现，更进一步闭环了整个流程。回想 5.1、5.2 时代，我们得做大量的笨拙变通，现在这些都不再需要了，因为我们正在给 Agent 提供越来越强大、越来越完整的工具。
因为我们部署的框架和应用、我们的研究环境以及让模型有效使用这些东西之间存在着良性循环，这是一个能力持续提升的过程。我喜欢 Codex 的一点是，它会完整地完成工作，不给我废话。我可以像对待团队中的其他成员一样对待它，我不会盯着七位队友的肩膀，在他们做错时敲他们的脑壳。我给他们任务，偶尔在站会上检查一下，我相信他们会生成能完成工作的 PR，我对 Codex 及其自主完成任务的能力也抱有同样的信任。
Simon：在你看来，到底是 Agent 的更新拉动效果更大，还是模型本身的更新更关键？
Ryan： 两者都有贡献，但我必须得说，新模型的发布才是最让我兴奋的部分。在提升能力方面，我们拥有的最强杠杆就是持续训练模型。我认为 5.2 就是这些编程 Agent 的奇点时代，从 5.2 系列开始的每一次版本更迭，都在反复拉升 PR 吞吐量。在 5.2 时代初期，团队里每个工程师每周大概能产出 3.5 个 PR。到了 5.5，这个数字变成了 70。这已经不是线性增长，简直令人咋舌。
Simon：那这变化是因为人变了，还是能力本身变好了？
Ryan： 两者兼有。随着模型能力以这种跨越式的方式提升，我们在“赋能”环节上需要投入的精力确实变少了，Harness Engineering 变得更简单了。我们使用的技术内核没变，但为了把 Agent 连接到外部世界而需要构建的笨重工具，正在变得越来越少。举个例子，在计算机使用功能诞生前，为了让 Codex 驱动我们的 Electron 应用，我们需要启动一个跑在 Docker 容器里的图形化 Ubuntu 系统，里面得装虚拟显示驱动和 X Server，然后让工程师在他们的 Mac 上安装 XQuartz，通过 Agent 连到那个无头主机，再连上 FFmpeg 去录制应用屏幕的变化，整个过程笨重无比。而现在，这一切只需在应用里打开一个计算机使用的开关就行了。
Frontier 项目中的 Harness 实践
Simon：拿 Frontier 项目这个典型案例，请你带我走一遍这个项目的 Harness 究竟长什么样，包括哪些部分会更新、谁拥有它、谁负责修改它。
Ryan： OpenAI Frontier 是我们的企业级 Agent 平台，覆盖了从如何用 API 构建 Agent、Agent SDK、Codex harness，到如何观察和治理在企业中运行的 Agent 这一整套体系。最酷的是，所有 harness 都统一对齐到 Codex 上，这意味着我们在产品和研究之间有了一个单一的、高度杠杆化的接口。模型上做的所有后训练改进，都能自动为每个产品带来杠杆效应。
目前，我们通过插件向 Codex 注入新能力的方式非常清晰。这些插件就是 skills 和 scripts，本质上还是 context 和 tools。有意思的是，我们最终形成了一种类 IOCTL 的可扩展机制。作为 Agent 构建者和产品构建者，我们给模型、给 Codex 的最大杠杆，就是给它越来越粗粒度的工具，这些工具直接连接到我们试图解决的实际业务问题，同时帮它做好上下文塑形与管理。
我和团队还在 Frontier 上做了另一件令人兴奋的事——企业级上下文管理。我们要搞清楚企业里究竟在做哪些工作，数据仓库的数据本体是什么，以及这些数据如何被用来回答指标问题。我们做了很多有趣的实验，比如给企业里的每个 Agent 配一个“边车”，让它持续管理上下文。这个想法背后是：所有 Agent 都是 Coding Agent，所以我们应该给它们那些对 git 仓库来说原生的事物——它们可以 grep，可以搜索。我们写代码所用的技术，会非常自然地迁移到在企业中构建 Agent 这件事上，而这一切都源于使用那个基础的 Codex Harness 来构建这些 Agent。
代码可读性：面向人类还是面向 Agent
Simon：我们刚才聊到字节码和机器码，那些代码是写给机器读的，不是人。后来我们进入了下一代编程语言，开始更多地为人类写代码。现在，我们是不是又站在了一个新的分水岭上？代码的可读性，到底应该面向人类，还是面向 AI Agent？
Ryan： 如果非要我只选一样东西对人类可读，我会选择系统的参考文档、接口定义，以及用 Mermaid 绘制的实体关系图、系统图和时序图，这是今天就能做到的。当然，我仍然会往下看机器生成的代码，会看 Agent 产生的 diff。但随着我对 Agent 的信任逐渐建立，我看那些代码的次数越来越少了。对于越来越复杂的任务，我可以做到忽略 Agent 生成的代码细节，不是所有任务，但越来越多。
我发现我和团队能提供最大价值的地方，恰恰在于定义接口、定义系统的组件是什么、每个组件该如何结构化，以及代码间如何相互关联。至于这些组件的具体实现，老实说，我可能甚至不知道它们是用什么语言写的。
有个很好笑的故事：我们在开发本地开发流程时，希望 Codex 能通过 Chrome DevTools 协议连接到我们的 Electron 应用，最初我们用的是 MCP。后来我偶然瞥了一眼代码，发现它已经彻底变了样。Codex 仍然通过 Chrome DevTools 协议连接 Electron 应用，但实际是启动了一个本地的 TypeScript 守护进程，提供一个微型 CLI 接口，而非 MCP。因为我们发现实际上只需要 2 到 3 个工具调用，这样做更省上下文、速度更快。这一切都在我不知情的情况下发生，我的工作流完全没有被打断。
Simon：你觉得这很酷还是令人担忧？
Ryan： 我觉得震撼，但也觉得很好。这基本上意味着我真实地体验到了那种高度信任的关系：团队里的某个人构思了一个更好的世界，然后把它实现了，并且完全没有干扰到团队中的任何人。而且因为写代码的是 Agent，它们对工具或结构没有执念。只要我们给它们能用的东西，允许它们完成工作就成了。
Simon：在目前使用场景中，什么情况下你仍然想深入查看代码？
Ryan： 如果画一个二维坐标图，横轴是低/高模糊度，纵轴是低/高复杂度，那么在“高模糊 + 高复杂度”这个象限里，主要对应两类项目。第一类是从零开始做全新的事情：接口的形状、代码放哪里、用户体验什么样，我都还不知道。第二类是最困难的重构：我需要打破或重新定义接口，甚至回退删除代码来实现目标，但我尚不清楚最终想要的形态是什么。这些是我最投入精力的地方，也恰恰是我最想待的地方。因为这才是预判未来六个月、为团队扫清障碍的意义所在。而且在这里，代码是廉价的，我乐意写一个 5 万行 diff 的 PR 然后直接扔掉，仅仅是为了搞清楚 Agent 会在哪里失败，然后把我中意的接口放进去。
每天十亿 Token 的暴论
Simon：我们来聊聊你之前说过的一句话：“一天不用掉十亿个 Token，几乎就是失职。” 你这话是想敲打谁？
Ryan： 核心想法是：我们能从模型中提取的智能量，在某种程度上与 Token 消耗量是线性相关的。这当时很有争议，但如今看来它越来越成立。这就是 test time compute 存在的原因。为了让模型更聪明、产生更丰富的副作用，我们得把工作流推向高 Token 消耗的场景。而要达到每天十亿 Token，你绝不能只是在跟模型结对编程。你必须找到并行化的方式，必须搭建异步循环，必须构建能对组织和团队产生影响的 Agent，而不是只影响你自己的。为此，我们发明了一系列模式，从仓库上下文中生成自动化，让团队里每个人都能用，而不是单机模式。
当然，不是说今天喊一声“我要消耗十亿 Token”就魔法般地实现了，这需要做大量工作来确保安全、保证输出对齐。现阶段，我们还没有一套持久、可扩展、固化的模式。所以故意抛出“十亿 Token”这个挑衅性目标，本质上是逼着大家去搞清楚到底什么模式管用。感觉就像我们刚发明了 CI/CD 的概念，大家都拼命理解它意味着什么。15 年后它才成为标准化的默认标配。现在，Agent 和软件生产也得经历同样的过程，我们必须找出那些模式。
Simon：顺着这个逻辑推演下去，如果每个团队、每个开发者每天都用十亿 Token，那工程团队会变成什么样？
Ryan： 我发现拥有一支视角、经验和专长多样化的团队非常有价值。我自己更偏向后端和基础设施，这意味着当团队只有我一个人时，我写的 React 代码糟糕透顶——有些组件 6000 行长，一堆糟糕的渲染逻辑，那些 useEffect 钩子里有四层重叠的闭包，极难推理。把能对我说“Ryan，这代码是垃圾”的人拉进团队，帮助巨大。拥有这些全栈团队，我觉得非常有用。
另外，我认为软件工程师不再需要把“编写代码”作为核心技能来培养，我更希望工程师培养的是系统思维：如何为团队的成功创造条件，如何尽可能远地预见未来、解决问题、提升代码生产和交付给客户的速度。现在我的时间分配是：30% 做最难的重构，30% 做从零到一的产品构思，30% 跟客户交流、排优先级、安排工作。而以前我大概 50% 到 70% 的时间都在写代码。所以我能退后一步，专注于这些跨职能、高优先级的工作流，为 Agent 团队扫清障碍，让它们去完成代码生产的部分。
Simon：最关键的部分是跟用户交流、理解需求，并把这些映射回应用的功能需求，而不是过度思考“应用该怎么构建、实现”，却忽略了“用户真正想要什么”。
Ryan： 对，其中一部分是决定不构建什么。现在很多人容易掉进这个陷阱。
Simon：因为编码太便宜了，什么都能建。但我们必须停下来问自己：这个该建吗？因为最终消费产品的还是人类。当我们考虑人类用户实际使用时，我们必须以他们能舒适接受的节奏来开发，这是一个非常有趣的平衡。
访谈视频原链接：
https://www.youtube.com/watch?v=MFQIKbr1IEo
声明：本文为 InfoQ 编译，不代表平台观点，未经许可禁止转载。
在 云栈社区，我们持续关注 AI Agent、深度学习与工程生产力的前沿碰撞。如果你也想探索如何将 Agent 融入日常开发流，欢迎来社区与众多同行交流。
发表于 5 小时前
|
查看: 6|
回复: 0
