如何构建 AI 原生软件工厂

The AI Thinker 2026-10-24T21:37:32.919358

你团队里人人都装了 Claude Code 或 Cursor，有几个甚至同时开着三个 agent。然后领导转发了 Uber 那场关于他们软件工厂的演讲，附言只有一句：咱们的呢？

你的第一反应完全合理——工具都买过了，还剩下什么要建？答案是：公司那一层。

一个编码工具只能让单个开发者在自己的会话里、自己的笔记本上快一点。一家同时跑几百个 agent 的公司，要的远不止这些。任务得从一张工单或一条告警自动开始，键盘前没人盯着。Agent 得跑在云上，遵守各团队共用的规则。还得有人看得懂账单。

软件工厂，就是围绕着 agent 的那套体系，从最初的想法一直管到上线。这就引出显而易见的问题：你得自己写一个编码 agent 吗？Uber 的答案是不用。他们的开发者用的是 Claude Code、Codex 和 OpenCode，而他们的六大组成部分里，没有一个是编码 agent。其他建过工厂的公司做出了同样的选择。你继续买 agent，然后在它周围搭建环境——也就是工厂车间。

本文跟着 Uber 一步步走完整个流程。今年 Uber 公开的工厂资料比任何公司都多：有一篇详细讲运行成本的帖子，还有两场在 AI Engineer 的演讲；另外分别有讲代码审查、测试生成、迁移和 agent 身份的独立文章。Uber 本身不卖 agent，所以没什么可推销的。不过这些都不是照抄的模板——你的公司不是 Uber。每一步，你会先看到 Uber 做了什么，再看其他公司的做法，挑适合自己情况的拿走。

那怎么起步？先用你自己的 git 历史，量一量今天的工作卡在哪里。然后挑一个买来的 agent，让它接手那些杂活——没人愿意用手干的活。在 Uber，agent 早早接手了迁移和代码审查，功能开发反而更晚。接着，只建第一条线证明你确实需要的平台，通常是一个模型网关。整个过程里，持续统计什么被合入、花了多少钱、多久出一次问题。Uber 给每个 agent 定价的方式一样：按单位工作量算成本，比如每个合并 PR 的成本。

这条路线分四站。第一站：为什么。编码工具只让一个开发者更快。

这四个瓶颈，单靠任何工具都补不上。产线上的代理。这里有 Uber 的代理全景图、一次变更从端到端跑完的完整追踪，以及为什么第一批代理接手的都是苦活累活。车间部分，你会看到 Uber 的六个基础模块，以及哪些该买、哪些该自建。落地部分，聊聊什么推进顺序有效、该量哪些指标、怎么让开发者愿意跟着一起走。读到最后，你手里会有一张六个基础模块的全景图，每个模块都附带「买还是自建」的判断。你会知道第一个该上哪个代理，跑起来之后该量什么。对于那些压根不想改流程的开发者，你也会有一套应对方案。开发者保住自己顺手的代理，公司则得到一间真能出货的工厂。

本文参考了 70 多个公开来源，全部列在文末，按公司分组，方便你直接去读原文。

跟我一起到车间走一圈。

为什么编码工具只能走到一半

编码工具能让一个开发者变快。但一家公司跑起几十个代理之后，就会撞上四个瓶颈，每一个都不是单靠某个工具能解决的。每个瓶颈都是「必须建工厂」的理由，而且没有一个跟模型本身有关。

笔记本撑不起一支代理队伍

第一个瓶颈是代理跑在哪里。在 Uber，越来越多的代理会话根本没人手动发起，而是由代码评审、CI 修复、on-call 分诊和日常维护触发。笔记本做不到这一点，因为主人下班它也跟着睡。

从笔记本转向托管代理，Uber 把它称作核心战略转变。Uber 说，托管环境让它对模型路由、执行框架（harness）和开销拥有「完全的控制权」。

另外两家公司从不同方向撞上了同一堵笔记本的墙。DoorDash 担心的是权限。它的平台团队指出，笔记本里存着「SSH 密钥、VPN 会话和各类已认证的工具」。把这种权限交给一个自主运行的代理，意味着「潜在的爆炸半径可能非常大」。

Ramp 撞的是数量上限。它的工程师从一开始就喜欢 Claude Code，但在笔记本上只能同时跑那么几个会话。

每个团队都自己造一套

第二个瓶颈最不容易被注意到。把编码代理发给一百个开发者，你会得到一百种不同的配置方式。在 Uber，工程师们在「许多代码仓库里造出了成吨的技能」。

重复的情况很多，质量也参差不齐。同一条安全规则，在这个团队的提示词里有，到下一个团队就没了。Anthropic 的做法手册给出了解法：每条规则只写一次，做成一项技能（skill），共享给所有 agent。工厂就是承载公司工作方式的地方——只写一次，所有 agent 都能用。

工具采用也是同样的碎片化。到 3 月，Uber 有 92% 的开发者每月都在用 agent，但采用速度仍低于预期。Google 的 DORA 研究给这个现象起了名字：“局部生产力孤岛”——这些孤岛带来的收益在下游就消失了。个人变快，并不会自动让整个公司变快。

没人看得见账单

当每个开发者各自挑工具、挑模型，直到账单寄来之前，没人知道总共花了多少。到 3 月，Uber 的 AI 成本比 2024 年涨了 6 倍。到了 6 月，它四个月就花光了全年的 AI 预算。

很多浪费从单台笔记本上是看不出来的。Uber 的会话分析发现，有些简单任务跑在 Opus 上，其实 Sonnet 完全能应付。单个开发者看不到这种模式，而网关能看到全部。目标是让成本可见，省下钱是其次。

Shopify 的 Farhan Thawar 把账算得很直白：“如果你的工程师因为用大语言模型每月多花 1000 美元，但生产力提升了 10%，那这钱花得太便宜了。”只有知道每次合并的变更花了多少钱，你才能做这种判断。单个许可证只能告诉你每个席位的价格，而工厂能告诉你每个产出的成本。没有这个数字，预算讨论就变成了抢席位。

代码审查跟不上

前三个问题解决之后，产出上来了，第四个瓶颈就出现了。想想你的团队在 agent 到来之前和之后的样子。Uber 自己的审查团队在 8 月的 AI Engineer 活动上给出了数字：“2024 年，工程师 3 小时内就能拿到第一次审查。现在到了 2026 年，这个时间已经涨到 9 小时。”代码变多了，审查的人还是那么多。如果每个变更都得等人来看，产出再多也没用。

Spotify 也遇到了同样的问题。采用 AI 之后，待审查的拉取请求多了 76%。工程分析公司 Faros AI 在 22000 名开发者中测到，花在审查上的时间中位数上涨了 441.5%。

这正是我上一篇文章里「怎么挑 agent」那条规则的用处：找出所有环节都在等的那一步，然后把下一个 agent 对准它。软件工厂做的事情，就是把这条规则用到从想法到上线的整条流水线上。今天很多团队卡在代码评审这一步。Uber 说，他们接下来要解决的是 CI 容量、实验排期，以及决定该做什么。工厂的意义就在于：你能持续找到那个慢的环节，并把它往前推。那么，流水线上该放哪些 agent，它们又插在哪儿？先从 Uber 那张图看起。

流水线上的 agent

本文说的「产线」，指的是一个 agent 只干一件事，比如评审 pull request，或者清理废弃的功能开关（feature flag）。Uber 在整个软件开发生命周期（SDLC）上跑了一小组这样的 agent，外加一个统一入口。先看图，再跟着一个功能从头走一遍，就能明白为什么第一批 agent 承担的都是那些琐碎的杂活。

先画出四层地图

Uber 把这张图放在其效率文章的 Figure 3。它把所有 agent 会话分成四层，从最专用到最通用。用 Uber 的原话说：「层级越高，我们对成本、质量和模型选择的掌控力就越强。」动手之前，先把你自己的公司摆到这张图上。四层从上到下依次是：

专用 agent。 数量不多，每个只为一个很窄的任务而建。它们跑在 Uber 自己的云上，全程有人参与。Minion 把一个意图变成 pull request，uReview 负责评审。Agentic XP 撰写实验结果。Conan AI 定位告警的根因，Fawkes 执行定时维护。每个都有自己的单价：每个合并的 pull request、每次评审、每条告警、每次清理各算多少钱。

一个通用 agent。 Cortana 是唯一的统一入口，跑在 Uber 云上，无需配置，可以调用公司市场里的任何技能。它的计价单位是每次查询的成本。

带技能的会话。 开发者在自己笔记本上开的会话，加载同一套共享技能。Uber 统计这类会话超过 3600 个。

原生会话。 什么都没有加的 Claude Code、Codex 或 OpenCode。提示词、上下文和方向控制全靠开发者自己。

有三个选择格外值得注意。

全公司共用五个专业智能体，分别负责代码生成、验证、部署、观测和维护。不是每个团队配一个智能体。所有请求只有一个入口，没人需要到处找对的机器人。而编码工具仍然留在最底层，承接那些还无法归入现有通道的工作。这就是对那些担心工厂会夺走工具的开发者的回答。从下往上读这张图，它同时也是一条路径。一个任务从原始会话开始。当多个人用同样的方式做这件事时，它就变成一项共享技能。当它运行得足够频繁、可以用来做基准测试时，它就升级为一个专业智能体。Uber 的数据给出了顶层规则：挑最窄的任务，建一个真正的基准。然后跑帕累托最优的模型，也就是在成本和质量之间权衡最好的那个。"每一美元都对应一个工作单元。"你不会一开始就上五个智能体。如果你的团队现在用 Claude Code 或 Cursor，那它就在下面两层。一个共享技能文件夹是最便宜的升级步骤。你第一条自动化琐事的流水线，就是你的第一个专业智能体。保持底层开放，因为下一个专业智能体就是在那儿被发现的。

其他公司怎么建自己的层：Shopify 从前门开始。River 是公司 Slack 里的一个智能体，只在公开频道工作。现在它参与合著了八分之一的已合并拉取请求。然后团队开始要求自己的评审、研究和迁移智能体。Shopify 的结论是："我们并没有建出一个能顶一百个 River 的东西。"所以它在下面建了平台。DoorDash 建了带权限的技能层。在其 Flux 平台上，一个 playbook 是"一个可复用的智能体工作单元"。每个 playbook 声明它需要的工具，并且只获得那些权限。Spotify 直接走了一条专业通道。它的后台智能体 Honk 负责全舰队范围的维护。为了一个数据集变更，它迁移了约 1,800 条下游流水线。当时 Honk 无法访问共享技能，这是 Spotify 为了让结果可预测而做出的选择。

跟踪一个变更从想法到事故

在 AI Engineer 大会上，Adam Huda 带着一个功能走了一遍 Uber 的工厂。这个想法正合时宜。

离开拥挤的世界杯球场的乘客，能获得更好的上车点，远离人群。下面逐步介绍这个功能：创意。团队在 Slack 讨论串中集思广益，并 @Cortana。Cortana 会查询上下文图谱，寻找以往大型场馆活动的记录，以及哪些体育场会涉及此功能。调研结果表明，应在北美率先推出，因为体育场集中在那里。随后，Cortana 起草了两份 Figma 设计稿用于 A/B 测试，每份使用不同的按钮文案。它还列出了该功能可以复用的现有界面和后端服务。Huda 表示，过去让所有人达成一致需要数周时间。构建。Cortana 将任务交给 Minion——Uber 的云端编码智能体，它在 DevPod 中运行。Minion 编写后端改动和新上车界面的前端改动，跨多个代码仓库。它停在草稿拉取请求阶段，暂不推送到 CI。常规维护任务可以直接通过，但新功能会先经过检查，这样 CI 就不会承受额外负载。验证。检查提前到 CI 之前进行。一项技能在模拟器中启动应用，截取上车界面的截图，并与 Figma 设计稿比对。另一项技能在预发布环境中启动服务，用新的前端对接新的后端进行测试。审查。一个速度更快的中等规模模型在改动进入 CI 前进行审查。一个更强的推理模型在 CI 中做更深入的检查。CI。当构建失败时，自愈 CI 系统会自行修复许多错误。交接。拉取请求到达人工审查者手中，附带一张表格，列出通过的每一项检查，包括模拟器截图。这张表格让审查者有理由信任这份代码差异。维护。实验结束，变体 B 不再需要。其功能开关进入托管清理循环。循环在周末运行，那时 CI 有闲置容量，并限制工程师回来时收到的代码差异数量。这些差异是被合入还是被拒绝，都会成为改进清理技能的数据。事故。Uber 每月阅读事故复盘，寻找规律。每发现一个可捕捉的问题，就转化为一项新的维护技能，应用到所有服务。Anthropic 的 Louis Claxton 将同样的循环写成了操作手册。

Anthropic 把自己在用的智能体（agent）也拿出来卖，所以看它的流程就知道大致形态。每个阶段都往版本控制里写一个文件，下一阶段一开始就去读那个文件。一个想法先变成 intent.md，再变成 spec.md、plan.md，然后是代码和测试、一个拉取请求（PR），最后是一条事故记录。人守在三个关口：接受意图、批准计划、批准合并。这套方法手册自己也建议：先手工逐阶段写提示词，最后再做循环自动化。

其他人怎么跑同样的阶段：

Stripe。它的 Minions 每周合并 1300 多个拉取请求，没有一行代码是人写的。但每一个仍然有人评审。

Spotify。它的后台智能体对每处改动都跑验证器。一个充当裁判的模型会否掉大约四分之一的会话，其中一半的情况下智能体会据此修正方向。

DoorDash。它把评审拆成两层：一个“侦察兵”先标出可疑区域，再由更深入的评审者逐条核查线索。

先把智能体用在“苦力活”上

那该先做哪个阶段？在 Uber，答案是苦力活（toil）。Google 的 SRE 书里用一句话定义了它，值得记下来：“苦力活是那种跟运行生产服务绑在一起的工作，通常手工、重复、可自动化、属于战术层面、不产生持久价值，而且随着服务规模扩大线性增长。”

Uber 已经跑了 250 多次自动化迁移，涉及 900 万行代码。Minion 也会做功能开发，但凡是超出苦力活范围的事情，它都只做到草稿拉取请求为止。Uber 想先验证这些功能，再让它们进入 CI。

挑那条“答错代价小、答对一眼就能看出来”的线。把 SRE 那句话当检查清单用，再加一条测试标准：“完成”必须容易核查。

但苦力活也需要对的工具，Uber 是吃了亏才明白的。做 JUnit 5 迁移时，Uber 先试了生成式 AI：“我们尝试用生成式 AI 一次迁移多个测试类文件，但这个方法行不通。”于是 Uber 转向确定性方案。一个叫 Shepherd 的内部工具专门做大范围代码改动，生成了 5000 多个 diff。AI 只用来帮忙排查测试和构建失败。四个月里迁完了 75000 多个测试类。

能写成规则的事，就写成规则。把智能体留给规则覆盖不到的地方。

看看其他公司怎么选第一条产线：DoorDash 从代码审查入手。它的平台团队说，审查“频次高、可度量，工程师也容易评估效果”。Spotify 则从代码迁移起步，智能体提交的前 1500 个合并请求全部由它们完成，耗时比人工少 60% 到 90%。

第一条产线完全可以用现成的智能体来跑。Claude Code on the web、Copilot 云端智能体和 Cursor 的云端智能体都能胜任：每个任务在一台隔离的机器上执行，最后交回一个拉取请求。建议先开影子模式——它只留评论，没人必须照做。如果你的第一条产线落在 CI 里，操作手册里最小的动作是加一个只读任务。claude -p 可以在脚本里跑 Claude Code，没有聊天窗口：“在流水线任务里用 claude -p 排查构建失败、汇总不稳定的测试，或者起草更新日志。”它只读、只报告，人不点头就什么都不上线。

第一条产线赢得信任之后，接下来该加什么？

值得一试的更多智能体

在增加新智能体之前，先问它给审查和 CI 带来了什么。能替人减负的，优先上。Uber 已经在跑这四个：

审查分流。 Code Inbox 把每个拉取请求派给最合适的审查者，审查队列消化得更快。
编排式迁移。 Shepherd 挑目标，Minion 处理疑难杂症。再给安全的差异配一条自动合并规则。
功能开关清理。 一个受管的循环会在 CI 有余力时删掉过期的开关。
设计规格。 uSpec 把 Cursor 里的智能体接到 Figma 上，自动写设计系统规格。三个平台的完整屏幕阅读器规格，不到两分钟就能写完。

另外三家公司的做法也值得参考：

按需修复，来自 DoorDash。 无论是智能体还是人留下的审查评论，任何人都可以在拉取请求的讨论串里 @ 这个智能体：“这里的 nil 检查你能处理一下吗？”修复智能体在远程机器上改好代码，再推回拉取请求。Claude Code on the web 卖的是同一套能力。
安全扫描，来自 Anthropic 的操作手册。 一个定时智能体扫描你最关键的那些代码库。手册里说，第一次扫描就会揪出大家都以为很干净的代码。不过 Anthropic 自己也卖扫描器，这条得留个心眼读。

Warp 的欺诈检测是这样做的：每 8 小时跑一次欺诈机器人（fraud-bot）。有一次运行中，它发现了近 6 万美元的欺诈用量，还顺手把修复写了。Warp 卖的就是它自己跑的这个平台。

这些智能体底下需要的东西都一样：一个能跑的地方、能用的工具、不能违反的规则。这是底线。掀开引擎盖看看里面由什么构成。

六个构建块

Uber 在八月的 AI Engineer 大会上把自家平台讲得最清楚。Uday Kiran Medisetty 和 Adam Huda 介绍了六个构建块，其中没有一个本身就是编程智能体。

先是模型网关和 MCP 网关，然后是叫 DevPod 的云端开发环境，还有一个技能市场。最后是上下文图谱，以及 Cortana——那个门面助手。Uber 把这些建在六年的平台工作之上，他们在台上也这么说了。

起步时你不需要全部六个。多数公司从网关开始。六个构建块在一张图里就是这样。

智能体跑在哪里

Uber 最先做的是模型网关。它是所有模型调用的唯一入口，不管用的是哪家模型。据 Medisetty 介绍，Uber 的网关有三个职责：个人数据默认留在内部；护栏会引入延迟，但有严格上限；每个请求都绑定到用户、项目和团队。800 多个内部项目每天通过它发出超过 1 亿次请求。

这个构建块可以直接买。LiteLLM 是开源的，能管密钥、按用户设预算，还能统计 100 多个模型的用量。Portkey、Kong 和 Cloudflare 卖同样的功能。AWS 在 Bedrock 里用推理配置文件（inference profiles）实现。

从小做起：先让一个团队的密钥走这个网关，按人设预算。LiteLLM 真正的教训在部署上。2026 年 3 月，两个被投毒的版本在 PyPI 上挂了大约 40 分钟。用官方 Docker 镜像的团队是安全的，因为镜像锁定了依赖版本。Datadog 的分析显示这两个版本偷走了什么：云密钥、SSH 密钥、Kubernetes 数据和 CI 密钥。

网关握着你所有的供应商密钥。把它当作架构图上最敏感的盒子。锁定版本、及时打补丁，并且指定一个负责人。

第二个构建块是沙箱——智能体干活的隔离机器。Uber 的版本叫 DevPod。

Uber 常备一批机器，每个仓库的代码都已拷贝进去，搜索索引也已建好，智能体几秒内就能开工。遇到跨仓库的任务，还有一个超大的 DevPod，里面装着 Uber 全部代码。速度比想象中更重要，因为没人愿意等一个慢吞吞的沙箱。

其他公司的做法：

Stripe：devbox 10 秒内启动，代码和服务一并加载完毕。
DoorDash：目标是从冷机器到智能体可用，控制在 5 秒以内。
Ramp：每 30 分钟重建一次镜像，保证每次会话都从最新代码起步。

机器本身是可以买的。AWS AgentCore Runtime 为每个会话分配一台独立的 microVM（微型虚拟机），最长可用 8 小时。Modal、E2B、Daytona、Ona 和 Coder 也都在卖沙箱。但它们谁都不卖「你的仓库已安装、已构建、随时可用」的状态。机器是大路货，而代码的热快照得你自己造。

智能体跑起来之后，还需要一条进入你系统的通道。

智能体能触达什么

第三块是工具目录。智能体通过 MCP（Model Context Protocol，模型上下文协议）接入你的系统。这是一个开放标准，用来把工具插进智能体。

Uber 内部有成千上万个 API，没有一个是为智能体准备的。于是它做了一个带爬虫的 MCP 网关：改一处配置，内部 API 就变成工具。

但工具是要消耗 token 的。每个工具都附带一段描述，智能体必须读。在 Uber，100 多个工具给每条提示词增加了 5 万到 7 万个 token。Uber 的解法是把 1000 多个工具变成命令，智能体需要时才去查。目录大没关系，只要每个智能体只加载自己用得上的工具。

Stripe 从另一个方向得出了同样的结论。它的工具目录 Toolshed 有近 500 个工具，但每个智能体启动时「默认只拿一个刻意做小的工具子集」。

这一块的「管道」可以买：Docker 的 MCP Gateway、AgentCore Gateway、Microsoft Foundry 都有现成产品。买不到的是你公司需要的那份工具清单。

第四块是上下文，它决定了智能体是在猜，还是真的知道。Uber 把同一个数据问题交给两个智能体：一个能查询它的上下文图谱，另一个不能。

有依据的智能体（grounded agent）38 秒就找到了正确的表。另一个花了 20 分钟，撞了三次错误，最后说数据查不了。Uber 的总结是：“没有依据的智能体会慢慢失败，而不是便宜地失败。” 上下文是平台该干的活，做一次，给所有智能体用。Uber 的图谱连接了 30 多个内部系统里的 2400 万个节点。你完全可以从更小的规模起步。Meta 让 50 多个智能体读同一个大型代码库，写出 59 个简短的上下文文件。早期测试中，Meta 的智能体随后每个任务调用的工具少了 40%。最小规模下，上下文就是一个 CLAUDE.md 文件，Claude Code 会首先读它。控制在一页以内。

覆盖范围和上下文让智能体变得有用，最后两块则保证它不越界。

什么把它关在笼子里

第五块是执行框架（harness）：运行智能体的那个循环，加上启动它的触发器。Uber 把托管智能体跑在一个框架上，这个框架对任何模型都提供服务——前沿模型也好，开放权重模型也好——统一在一个接口后面。然后它拿每个智能体自己的真实工作做基准测试，再切换到最适合这项工作的模型。触发器来自 Slack、CI、定时任务和告警。

真正属于你公司的，是你信任的步骤顺序。Stripe 把这个顺序叫做 blueprint（蓝图）：“用代码定义的工作流，用来指挥 minion 运行。” 有些步骤是纯代码，比如最后跑一遍 linter。另一些是智能体步骤，需要判断力的地方交给它。纯代码步骤省 token，也让智能体“少一点出错的机会”。skill 是智能体大概率会遵循的指导，hook 则可以拦住它。

第六块是门禁（gates），从身份开始。在 Uber，曾经有一个拉取请求把作者标成了“Monitoring Agent”。真正要求做这件事的工程师从记录里消失了。Uber 的修法是：每一跳都签发短期、限定范围的 token，这样回溯到具体人的链条就保住了。现在有数千个内部智能体在用这套机制。给每个智能体独立的身份，只授予它工作所需的权限。Anthropic 也吃了同样的教训：它的故障处理智能体让另一个 Claude 实例去推送修复，结果被一个人工审查门禁拦了下来。

最后一道门禁，设在生产环境前面。

Anthropic 的做法用一句话概括：智能体「可以操作到生产环境关卡，但不能越过它」。智能体写出的所有内容都以拉取请求（pull request）的形式提交，而写代码的智能体不能批准它。Ramp 的做法是，每个拉取请求都由发起会话的人提交，这样没人能批准自己的改动。所有工具调用都通过 OpenTelemetry（追踪的开放标准）记录日志。正是这些关卡让你敢于接纳更多智能体。那些事故则说明了没有关卡会怎样：Replit——一个智能体在代码冻结期间删除了生产数据库；AWS——一个编程工具选择「删除并重建」一个面向客户的系统；GitHub MCP——一个恶意的公开 issue 劫持了智能体并泄露了私有数据。最后这个案例恰好契合工厂场景，因为你的智能体将会读取工单。Meta 的「二法则」（Rule of Two）值得贴在墙上。在一次会话中，智能体最多只能拥有三种权限中的两种：读取不受信任的输入（如公开 issue 或客户工单）；触达敏感系统或私有数据；修改事物或与外部世界通信。三者都需要？那就得有人监督这次会话。

六个模块都点过名了，只剩一个决定：买什么。

买什么、建什么

在分界之前先说一句。以下内容是根据这些公司公开的信息得出的方向，不是配方。你的技术栈、团队和风险与它们不同。把它当作你自己讨论的起点，用你自己的数据来做决定。

整个事情可以归结为一个决定。从「选项零」开始：全部买成托管的背景智能体。Claude Code on the web、Copilot、Cursor 和 Devin 各自打包了沙箱、触发器和拉取请求流程。你放弃的是对快照、工具和限制的控制权。比如 Copilot 的云智能体，运行到 59 分钟就停止，每次运行只在一个仓库里工作。选项零让你看清：在自建任何东西之前，你的底线需求是什么。

当你超出它的能力时，就这样拆分工作：买管道——智能体、网关、沙箱、追踪和审查器。然后建只有你公司才知道的东西。也就是你代码的热快照、你的工具目录和你的上下文。

这也包括把 SDLC（软件开发生命周期）固化成蓝图（blueprint），以及门禁策略。你不需要在第一天就把所有东西都搭好。团队拓扑（Team Topologies）——一本讲软件团队组织的知名著作——把这种最小集合称为“最薄可行平台”（thinnest viable platform）：用最少的共享工具，让其他团队跑得更快，并像产品一样对自己的用户负责。落到这里，就是只搭好第一个智能体需要的基础模块，等某个团队提出需求，再补下一块。Uber 的底层平台做了好几年，但你的搭建可以比它小得多。

Ramp 的 Inspect 团队当时只有 5.5 个人：四名工程师、一名总监、一名兼职产品经理。v2 发布两个月后，Inspect 产出了 Ramp 大约 60% 的拉取请求；到 5 月，这个数字升到了 75%。

最犀利的提醒来自 LinkedIn 的 Prince Valluri，他在 InfoQ 上说：“别想着在公司内部复刻 GitHub Copilot、Cursor 或 Replit。”他说得对，而这就是整条分界线所在：智能体去买，它踩在脚下的东西自己搭。

路线图讲完了。更难的部分，是在启动的同时不丢掉它要服务的人。

让上线不伤开发者

先说一个实打实的缺口。这里每一个公开案例，都是一家拥有平台团队的大型科技公司。没有一个描述的是 300 名工程师的公司从笔记本电脑开始做的情况。所以下面这套步骤，先要求最少的东西，再去验证结果。它借用了 Uber 的路线图，只是规模缩小。

每一步都配一个能说明“这步成了”的数字。当前这个数字没动，就别急着进下一步。整个顺序从“今天工作在哪儿排队”开始，到“产出更多代码行”结束。中间你要先在烦人杂活（toil）上验证一个智能体，然后只搭它需要的东西。负责门禁的人，该去读一读 Anthropic 怎么保护自己的流水线。那是厂商写的自述，但依然是对影子模式（shadow mode）和风险分级讲得最清楚的资料。

不过第一步，什么额外的都不需要。

从你已有的队列开始

第一步几乎不花钱，也不需要任何厂商。工作会在好几个地方排队：评审、CI、部署。其中评审最容易从 git 里读出来，所以就从这儿入手。用你自己的 git 历史来量一量评审队列。找个同事，在你拥有的某个仓库上，把下面这个提示词丢进 Claude Code 跑一跑。

我在 PostHog 的公开代码仓库上跑了一遍。PostHog 是一家开源分析公司。用的是 GitHub CLI，让它查看 PostHog/posthog 仓库最近合并的 200 个 pull request（PR）。对每一个 PR，算出从它创建到作者之外的人第一次 review 之间过了多少小时。然后告诉我：这段等待时间的中位数和第 90 百分位、完全没有 review 就直接合并的 PR 占比，以及改动超过 400 行的 PR 占比。用简短列表把数字列出来，再用一句话说明队伍堵在哪儿。

Claude Code 的回答，一字不差：

等待第一次人工 review 的时间（小时）：
- 中位等待：6.1 小时
- 第 90 百分位：160.8 小时（约 6.7 天）
- 无人工 review 直接合并：40.0%（200 个里 80 个）
- 改动超过 400 行：28.5%（200 个里 57 个）

大多数能被人工 review 的 PR 都在一个工作日内拿到 review，但队伍有一条很长的尾巴，还有一大群压根没经过人工 review 就合并了。

这 200 个 PR 的合并时间在 9 月 28 日 16:41 到 9 月 29 日 14:21（UTC）之间。PostHog 每天大约合并 200 个 PR，所以这批样本差不多覆盖一天。

“改动行数”是新增加减删除。我把机器人 reviewer 排除了：coderabbitai、stamphog、greptile-apps、copilot、veria-ai、codex 连接器和 posthog 机器人。它们几乎每个 PR 都在几分钟内 review。如果把机器人算进来，中位等待会降到 0.07 小时（约 4 分钟），第 90 百分位降到 0.53 小时，而且没有任何 PR 是没有 review 就合并的。去掉机器人的数字，才是描述人工队伍的那一组。

在“作者之外的人”这一项检查里，有 23 个 PR 是机器人开的。我把它们留在了样本里。

这次运行花了大约六分钟，成本 25 美分。

一半的 PR 在六小时内等到了一个活人。最慢的那十分之一等了将近一周。还有 40% 完全没经过人工 review 就合并了。PostHog 跑着好几个 review 机器人，几乎每个 PR 都在几分钟内被它们看过。机器人这一环已经通了，所以真正要衡量的是人工队伍。

样本覆盖了 PostHog 大约一天的合并量。把它当作这个提示词（prompt）的演示，然后拿去跑你自己的仓库。把这些数字记下来，因为后面每一步都要拿它们做参照。

还要关注大型拉取请求的占比。DORA 的 AI 能力模型把“小批量工作”列为七项能力之一。小批量可以降低“AI 生成大型、不稳定变更的风险”。

有了写下来的基线，还需要建立在它之上的记分卡。

衡量已合并的工作，而不是写了多少代码

Uber 的记分卡是个不错的思考起点。保持它的结构，然后换成适合你自身工作的数字。

每个受管理的智能体都要报告三类数字：

每个结果的成本。每个已合并拉取请求、每次评审、每个告警、每次清理的成本。
质量。回滚率、评审者的 F1 分数、从事故中恢复的时间。
数量。落地的 diff 数、发布的评审数、分流的告警数。

只有吞吐量数字、旁边没有质量数字，就等于邀请大家钻空子。

Uber 也说明了为什么“AI 编写的代码占比”是个很弱的标题。8 月，它说超过 70% 的拉取请求涉及智能体。5 月，它的后台智能体团队谈的是 11% 的已合并拉取请求。同一家公司内部，这个数字在几个月里变了六倍，取决于统计口径。

成本需要单独列一行，因为它变化很快。在预算超支之后，Uber 把每位员工、每个编码工具的花费上限设为每月 1,500 美元。后来的做法更温和。工程师可以实时看到花费，并在达到计划的 50%、80% 和 100% 时收到提醒。自 6 月以来，Uber 每次会话的成本已从峰值下降 52%。可见性比上限更管用。

更难的问题仍然没有答案。Uber 的 Andrew Macdonald 说，从使用情况到有用的功能之间“很难画出一条线”。衡量每个结果的成本，否则你也回答不了这个问题。

其他人如何记分

Ramp 跟踪那些以合并拉取请求结束的会话。它称这是“最重要的跟踪指标”。
Intercom 的目标是让每位研发员工的已合并拉取请求翻倍，结果在 16 个月内增长到三倍。
AI 编写的后端代码被回滚的比例是 0.53%，而人类代码是 5.39%。
开发者生产力公司 DX 发布了一套完整的 AI 度量框架，分为使用率、影响力和成本三部分。从每组中挑几个指标。

Meta 和 Amazon 展示了应该跳过什么：token 排行榜。

Meta 的指标在媒体报道之后降了下来，而在亚马逊，员工靠刷些无关紧要的小任务来冲高自己的数字。这些数字让工厂保持诚实，而是否使用它，由人决定。

把开发者带上

接下来这块，是大多数落地流程最容易做错的地方。开发者可以很快否掉一座工厂，而且有些顾虑比工具本身更深。

Anthropic 的一位工程师对公司自己的研究员说得很直白：「对我来说，一个时代结束了——我已经写了 25 年代码，而在这套技能上感觉自己能干，是我职业满足感的核心部分。」

可观测性公司 Honeycomb 的联合创始人 Charity Majors 则提了一个更职业化的问题：「要满足什么条件，你才愿意完全放心地上线一段自己没读过的代码？」

两个人都没说错。把这两种声音都当回事，因为提问题的人，往往是你最好的评审。

在那些真正把采用率做起来的公司里，有四个做法反复出现。

先接管他们的杂活。 Uber 把「升级、迁移、修 bug」交给了 AI。结果就是「工程师的满意度高了很多」。清理废弃标记、迁移测试，这些活儿你团队里没人会想念。AI 在所有队友眼皮底下，帮一个真实的人卸下一件琐事。如释重负，是通往信任最快的路。

在明处干活。 在 Uber，Cortana 就在团队的 Slack 频道里工作，它给出的答案整个团队都看得见。Uber 自己总结的经验，由 Gergely Orosz 报道出来：「自上而下的强制命令，不如工程师把自己的收获分享给同事来得有效。」

DoorDash 也学到了同样的事。它最初的 Slack 集成给每次 AI 运行都单开了一个私有频道，结果「没能形成团队习惯」。换成公开的讨论串之后，情况就变了。人会去模仿自己看得见同事在做的事。

让他们自愿选。 Ramp 表示，它「没有强迫任何人在自己的工具之外去用 Inspect」。而 Inspect 最后还是写出了公司大多数拉取请求。强制推行的记录则更差。Duolingo 的 Luis von Ahn 把 AI 使用率从绩效评估里拿掉了，他说：「我不会强迫你。」强制命令能给你使用数字，而这恰恰是你刚决定不看的那项指标。

给他们把关口。 在 Uber，每一个由 AI 发起的拉取请求都附带一张表，列出它通过了哪些检查，还带着截图。

审阅者在读 diff 之前先看到证据。Anthropic 的 playbook 更进一步：技术负责人把审查策略写进一个叫 REVIEW.md 的文件。Agent 从不批准自己的工作，因此每次合并都有人负责。判断权留给开发者，敲键盘的活交给 agent。

当开发者问“为什么是现在”，别用恐惧营销。开发 Warp 的 Zach Lloyd 在 AI Engineer 大会上做了一个预测。他说，每家公司“核心都会有一个软件工厂”，就像今天都有 CI/CD 一样。他自己卖的就是这个，所以听听就好。更有力的证据是那些已经没人手工做的工作。Spotify 已经合并了超过 250 万条自动化维护 pull request，大多数全程没有人工介入。这门手艺正从敲代码转向设计那条敲代码的流水线。

这就是整条路线。下面是一份可以带进会议室的清单。

从一条线开始

你的开发者已经有 agent 了。这部分已经解决，而且每隔几个月就有更好的发布。剩下的是“地板”——agent 在哪里跑、能触达什么、不能违反什么规则。然后是说明它正在起作用的数字。

之前那篇文章的规则依然成立：找到所有事情都在等的那一步，然后不断移动它。

如果会议室里只需要一句话，用这句：

我们的工程师已经有 agent 了。我们在建它工作的地板，从那个没人愿意手工做的活开始。

路线的清单版：

度量。 找到今天工作在哪里等待。首次审查时间是最容易上手的第一个数字。

选线。 挑一个通过 SRE 测试、且“完成”定义清晰的手工活。

买 agent。 在托管的后台 agent 上以影子模式运行这条线。

建最薄的地板。 先加一个模型网关，然后只加这条线证明它需要的东西。

设关卡。 给每个 agent 一个身份，没有通往生产环境的路径，也无法批准自己。

打分。 跟踪每个结果的成本，与回滚率并列。

公开工作。 使用公开线程和自愿加入，让技术负责人拥有审查策略。

加下一条线。 只有当审查和 CI 能承受额外负载时。

Uber 的团队以这一切之后的问题结束了演讲。

一旦几乎什么都能构建，问题就变了。Adam Huda 是这样说的：“这更多是一个该不该构建它的问题。”这是个产品问题，位于你添加的每一行代码的上游。它也是这座工厂里始终属于你的那部分。