摘要

Ryan Lopopolo 的团队在5个月内，将整个代码库做到了约100万行代码、完成1,500个PR，前提是Ryan本人不写任何代码。 这一约束是刻意设定的：如果企业级 agents 要接手他的工作，“我能完成工作的唯一方式，就是让 agent 完成我的工作”。Codex Mini 最初无法独立完成完整功能，团队因此先构建更小的原语，再让 agents 可靠地组装起来。
生产力曲线先是大幅倒退，随后压倒传统工程吞吐量。 前1个半月的速度比Ryan手写代码“慢10倍”，但这笔工具建设成本最终让系统达到了单个工程师手工开发约10倍的速度。更大的启示是，采用 agents 之前，必须先为装配线投入资金，之后才可能获得装配线经济性。
在 agent 规模下，稀缺资源是同步的人类注意力，而不是 tokens 或代码生成能力。 团队从严密代码审查转向以合并后的抽样检查为主，因为模型“可以轻易并行”，而人仍然需要睡觉，也不可能跟进几十条并发轨迹。自治仍有边界：这是一个 greenfield 原生应用，人类仍会切出发布分支、批准 smoke test，然后再分发。
持久优势来自被编码进系统的组织化品味：文档、测试、lint、可观测性和审查 agents，会把每次失败都转化为未来的上下文。 一次因缺少 timeout 引发的故障，既会得到修复，也会变成“所有网络调用都必须设置 timeout”的规则；一次失败的构建或PR评论，则说明“agent 在某个时点缺少上下文”。因此，优势正从私人掌握的工程直觉，转向一个持续改进、机器可读的操作系统。
Symphony 消除了盯着终端等待的工作；Shawn 说，随之而来的工作流又带来了5倍生产力提升。 在5.2之前，产出已从每位工程师每天3.5个PR提升到5.2之后的5–10个，但上下文切换耗尽了人类精力；Symphony 则推动 tickets 一路完成，并将决策压缩成一个简洁的合并判断。如果结果无法通过审查，它会删除 worktree 和PR，从头开始，因为代码如今对“实际作者体验”的投入“接近于零”。
代码供给过剩可能压缩软件依赖和内部工具市场的一部分，但Ryan保留了重要边界。 他认为，一个几千行的依赖如今已经可以在一个下午内内化，只保留所需的精确功能；而“ghost libraries”可以分发可复现的规格，而非源代码。Shawn 的反驳是，内化会让信心值归零，丢掉广泛使用和“许多双眼睛”积累的经验。
在后半段的 Frontier 讨论中，Peter Steinberger 描述了同一工厂模式如何从编码延伸到受治理的企业劳动。 Frontier 面向的是可观测的 agents，并将其接入 IAM、安全工具、工作区、定制安全策略和可撤销授权。David Luan 表示，Codex 每周活跃用户已超过200万，且周环比增长25%；Shawn 则称，每日部署的智能约有10亿 tokens。但边界依然清晰：困难且全新的产品创建，以及“最棘手的重构”，仍需要人类持续引导。

精读

1. 不写人类代码的约束，迫使 harness 成为工程师

Ryan 负责 Frontier 产品探索，将 OpenAI 模型封装进企业产品。在使用 coding agents 6到8个月后，他判断 agents 在能力上已足够“与我同构”，于是设定了一条硬约束：产品代码不能由他亲自编写。
早期的 Codex Mini 无法组装出完整功能。Ryan 因此形成了基础工作循环：“每当模型确实做不到，就打开那个任务，深入拆解，构建更小的积木”，让模型之后可以重新组装成更大的目标。
在生产力形成复利之前，成本非常高：“前1个半月比我自己写慢10倍。”但5个月后，这套 greenfield Electron 系统的代码库已约100万行，完成约1,500个PR，报告吞吐量约为手工开发的10倍，因为团队已经搭好了“工具和装配工位”。

2. 模型升级如今会倒逼基础设施升级

代码库经历了 GPT-5、5.1、5.2、5.3 和5.4，每一代模型都带来不同的工作方式。因此，Ryan 的团队把模型行为视为基础设施约束：模型一变，构建系统和代码库有时也必须随之调整。
在5.2下，Codex 没有后台 shell，因此阻塞式脚本可以承担长时间运行的工作。到了5.3，后台执行让 agent 变得“更没耐心，也更不愿意阻塞”，团队遂从定制 Makefile 迁移到 Bazel、Turborepo，最终转向 Nx，把构建时间压到1分钟以内。
1分钟并非什么神奇阈值，而是团队可以强制执行的不变量。与其放任构建延迟上升、再安排一次持续数周的平台清理，不如让廉价的并行 tokens 持续“打理”代码库，压低代码和软件开发生命周期中的离散度。

3. 人类注意力成为产能上限

Ryan 的经济学框架非常直接：“只要我愿意花费足够多的 GPUs 和 tokens，我就能获得足够的代码库工作产能。”真正稀缺的投入是无法并行化的同步人类注意力，而终端、审查、上下文切换、午餐和睡眠都会消耗它。
因此，运营问题不再是某个 agent 是否犯了一次错误，而是：“agent 在哪里犯错？我的时间花在哪里？怎样才能以后不再花这些时间？”每个答案都应转化为足够可靠的自动化，把该环节从人类监督中移除。
代码审查基本已转移到合并之后。Ryan 把自己的角色比作负责技术领导一个500人的组织：抽样代表性代码、据此判断系统性问题是合理的，但不应对每个PR都形成详细意见。
主持人追问了安全边界。这是一个 greenfield 原生应用，而不是要求严格 uptime、持续部署的基础设施；人类仍会切出发布分支、执行经过认可的 smoke test，并批准将版本推向分发环节。

4. 每个缺陷都会被转化为持久的文本上下文

Ryan 说：“模型从根本上渴求文本。”代码库通过顶层简明指南、核心信条、skills、技术债务追踪器和质量评分提供文本，让 Codex 检查业务逻辑、对照防护栏，并提出之后可以自动消化的工作。
他的 timeout 案例说明了这一机制：一次因缺少 timeout 导致的故障发生后，Codex 可以修复调用，并更新可靠性文档，要求所有网络调用都设置 timeout。之后，这条规则还可以生成测试、lint 或针对性审查行为，把一次点状修复升级为流程知识。
主持人的反驳值得保留：永久性规则可能遗漏合理例外，而遵循指令的 agents 也可能过度字面地执行规则。Ryan 的回答是保留可选性：skills 只在相关时调用，提示词明确允许 agents 质疑、延后执行，或结合上下文理解指令。
早期的审查 agents 会“霸凌”编写 agents，迫使它们进行无法收敛的重写。团队于是教会审查 agents 偏向合并，不提出严重程度高于 P2 的问题；编写 agents 也可以拒绝反馈，或把扩大范围的建议放入 backlog，而不是把每条评论都当成必须立即执行的命令。

5. Agent 规模的团队需要组织规模的架构

Ryan 避免规定业务逻辑的详细形态，但坚持使用能够形成杠杆的原语，例如自动提供 tracing、metrics 和可观测性的 command class。核心问题不是作者是否有审美，而是每个实现是否继承了自治运行所需的能力。
Ryan 形容这套代码库大约包含500个 npm packages，采用的是“1万名工程师级别的架构”——其深度相当于一个7人团队通常不会采用的程度。当每个人驱动10–50个 agents 时，深度拆解、严格接口和分片不再是过早复杂化，而是避免并发工作互相踩踏共享界面的必要条件。
这种规模也制造了新的人类问题：没有人能稳定掌握当前代码状态。团队每天召开45分钟 stand-up 来扩散信息，尽管产品代码、测试、CI、发布工具、仪表盘、文档、评测 harness 和代码库管理脚本都由 agents 编写。

6. Coding harness 正在扩展为通用工作 harness

Ryan 更广泛的论点是：只要可能，就把用户旅程压缩成代码，再让 Codex 提供连接和执行。主持人直截了当地指出，这意味着 coding agents 可能“吃掉知识工作”，包括那些团队过去认为必须用定制化非 coding agent 完成的任务。
Git 的多 agent 摩擦并没有说服Ryan放弃 Git。当一个“land” skill 能够推送PR、等待审查和 CI、修复 flaky 问题、合并上游、进入队列，并持续跟进直到变更进入 main 时，worktrees 和合并冲突都是可以接受的。
在工具定义被强行注入上下文、干扰 compaction、并教会 agent 一堆它永远用不到的调用时，Ryan 对 MCP “相当悲观”。他的 Playwright 案例中，有人用本地构建的 daemon 和极小的 CLI shim 替代了直接的 MCP 配置；系统因此变得更好，而Ryan甚至不知道发生了这次替换。
CLI 有效，是因为它们以文本为媒介且节省 tokens。理想命令会压制成功时的噪声，只返回可行动的失败信息；即使是视觉界面，也可以在图像旁附上 ASCII 布局，因为 agents 对空间设计的感知并不等同于人类。

7. 可丢弃的代码改变了哪些东西该自建、采购或分发

Ryan 同意 Bret Taylor 关于部分依赖可以被 vendored away 的看法，但将当前能力限定在“低到中等”复杂度。一个几千行的依赖可以在一个下午内内化，删掉通用功能，只保留真正需要的界面。
随后，Codex Security 可以直接检查和修改这段代码，避免等待上游补丁、等待发布，以及处理传递依赖兼容性。Shawn 则反驳说，规模化测试和开源审查承载着积累下来的知识；内化会让信心回到零，所有这些保障都必须重新建立。
团队一名工程师花了一个下午，为导出的性能 trace 构建了一个精致的本地 DevTools Next.js 查看器。Ryan 后来意识到，这个面向人类的工具并无必要：Codex 可以直接读取 tarball，并在5分钟内回答调试问题，暴露出旧有直觉如何让人类继续陷入已经不必参与的循环。

8. Symphony 将异步 agent 工作工业化

产出从12月底每位工程师每天约3.5个PR，升至5.2发布后1月初的5–10个PR，期间代码库没有其他变化。吞吐量当然受欢迎，但在活跃的 tmux panes 之间切换，让工程师“几乎被榨干”。
Ryan 解释说，Elixir 实现适合 BEAM 的进程监督和 GenServers，而这两者天然匹配任务编排：每个 ticket 都成为一个受监督的进程，被持续推动到完成。他是在事后才学习这套生态，但自己熟悉哪种语言，已经不再需要影响“该选什么工具”。
人类审查被刻意设计成二元且低成本：可合并，或返工。返工会销毁整个 worktree 和PR，从头重来，并追问第一次为什么失败，以便在重新运行 ticket 前修复缺失的上下文。
Shawn 表示，这套工作流又把生产力推高了5倍。信任讨论的核心是压缩后的证据，例如随PR附上的、由 agent 生成的共享演示，而不是“肩后观看”完整 coding 轨迹；团队成员不会要求另一名成员提供完整屏幕录制。

9. 系统从自身轨迹中学习，但并非所有任务都已解决

Peter Steinberger 说，代码库中约有6个共享 skills。新行为首先会被加入现有 skill，因为通用模式能让 agents 低成本迁移上下文；修改一条共享指令，也比重新训练每个人类操作者的习惯更容易。
Peter 说，Codex 的 session logs 会被收集到 blob storage，每天分析一次，以识别全团队层面的改进。PR评论和失败构建也会接受同样处理：每一项都是“agent 在某个时点缺少上下文”的证据，应被提炼回代码库。
Peter 描述了政策、配置、协调、执行、集成和可观测性层；Shawn 提议增加一个“零层”，先问清楚工作流本身是否应该改变。Agents 可以更新工作流并创建后续 tickets，不过主持人将“不要把 agent 关在盒子里”重新表述为：给它一个装有其领域内全部必要条件的盒子。
尚未解决的象限，是既困难又全新的工作。Ryan 仍难以一次性把全新的 mock 变成可玩的产品，并把最多同步时间花在留白设计和“最棘手的重构”上；这两类任务都会随着轨迹展开，才逐渐暴露需求。

10. Frontier 为企业劳动封装同一控制平面

Peter Steinberger 将 Frontier 描述为一个平台，用于在企业内部部署可识别、可观测、可控制的 agents，并接入原生 IAM、安全系统和工作场所工具。Agent SDK 的目标，是把模型、shell 访问、Codex harness、附件和 containers 组合成一个可靠的默认方案，供开发者定制。
安全也必须反映企业自身的现实。Peter 提到了 GPT-OSS-Safeguard 模型，以及覆盖数据外泄风险、内部代号和公司政策的定制安全规范；Frontier 的构件包括 steering，以及在 agent 偏离目标时撤销授权的能力。
Peter 描述了两层产品：员工使用 agents，以及 IT、GRC、治理、安全或 AI 创新团队监督部署。控制面板可以下钻到单条轨迹；内部数据 agent 则暴露公司的本体论，包括 revenue 或 active users 等存在争议的概念，让 agents 理解企业实际上如何运作。
Shawn 提到，每日部署的智能约有10亿 tokens。David Luan 表示，Codex 每周活跃用户已超过200万，且周环比增长25%。Shawn 将这种方法称为“on-policy” harness；Peter 的底层观点是，原生防护栏——测试、代码和与输出对齐的检查——可以改善模型行为，而不必用一个很快会过时的限制性脚手架把模型包围起来。

油价冲击期间如何配置仓位 Michael Nielsen：为什么外星文明会拥有与我们不同的技术栈