跳到正文
Hacker News· gmays·· 9 天前AI 评分62

如何搭建 AI 原生的软件工厂

How to build an AI-native software factory

AI 导读

文章提出 AI 原生软件工厂的关键不在编码智能体本身，而在围绕它的公司级系统，并给出四步落地路线：先从 git 历史度量评审等待时间，再让买来的智能体接手迁移、评审等苦活，然后只建第一条产线证明需要的平台，通常从模型网关开始，最后持续跟踪每次合并的成本、质量与吞吐。

正文 · AI 翻译

译文尚不完整，完整内容请切换到原文。

你团队里的每个人都已经在用 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 的定价方式都一样：单位工作的成本，比如每个已合并 pull request 的成本。

路线如下，共四站。

  • 为什么。一个编码工具加速一个开发者。一家公司会撞上四个任何工具都无法单独解决的限制。

  • 产线上的 agent。这是 Uber 的 agent 地图，一次变更端到端地走完，以及为什么第一批 agent 承担了苦活。

  • 车间。你会看到 Uber 的六个构建模块，以及哪些该买、哪些该建。

  • 推广。有效的顺序、该衡量什么，以及如何让开发者与你同行。

到最后，你会得到一张六个构建模块的地图。每一个都附带一个买或建的判断。你会知道哪个 agent 先上，以及它运行后该衡量什么。你还会有一个针对那些宁愿什么都不改的开发者的计划。你的开发者保留他们喜欢的 agent，而你的公司得到一个能交付的工厂。

本文参考了 70 多个公开来源。每一个都在文末按公司分组列出，方便你自己阅读原文。

跟我一起走一遍车间吧。

一个编码工具能让开发者更快。而一家运行着数十个智能体的公司会撞上四个极限，单靠工具无法解决。 每一个极限都是构建这座工厂的理由，而且没有一个与模型有关。

第一个极限是智能体在哪里运行。在 Uber，越来越多的智能体会话在没有人类参与的情况下启动。代码审查、CI 修复、值班分诊和维护都会启动它们。笔记本电脑做不到这一点，因为它的主人睡觉时它也休眠。 Uber 称从笔记本电脑转向托管智能体是其核心战略转变。它表示，托管环境让它对模型路由、运行框架和支出拥有“完全控制权”。

另外两家公司从不同方向撞上了笔记本电脑这堵墙：

  • DoorDash担心的是访问权限。其平台团队指出，笔记本电脑里存着“SSH 密钥、VPN 会话和已认证的工具”。把这种访问权限交给一个自主智能体，意味着“潜在的影响范围可能很大”。

  • Ramp则在数量上碰到了天花板。其工程师从一开始就喜欢 Claude Code，但在笔记本电脑上他们只能运行几个会话。

第二个极限最不显眼。给一百个开发者一个编码智能体，你就会得到一百套配置。在 Uber，工程师们构建了“横跨众多仓库的大量技能”。存在“大量重复”，而且许多质量很差。安全规则最终出现在一个团队的提示词里，却在下一个团队里缺失。Anthropic 的操作手册给出了解决办法：把每条规则写成一个技能，然后共享它。工厂就是公司工作方式存在的地方，一次编写，供每个智能体使用。

采用方式也同样碎片化。到三月，Uber 92% 的开发者每月使用智能体，但采用速度仍慢于预期。Google 的DORA 研究点明了结果：“局部化的生产力孤岛”，它们在下游就消失了。快速的个体本身并不能累加成一个快速的公司。

当每个开发者各自挑选工具和模型时，直到账单到来之前没人看得到总数。到三月，Uber 的 AI 成本自 2024 年以来上涨了 6 倍。到六月，它在四个月内花光了全年的 AI 预算。大部分浪费从单台笔记本电脑上是看不见的。Uber 的会话分析标记出那些本可由 Sonnet 轻松处理、却运行在 Opus 上的简单会话。一个开发者看不到这种模式，而一个网关能看到全部。

目标是可见性，更小的账单可以排在其次。Shopify 的 Farhan Thawar把这笔交易说得很直白：

“如果你的工程师因为 LLM 每月多花 1000 美元，而他们的生产力提高了 10%，那太便宜了。”

只有当你知道每一次合并的变更花了多少钱，你才能做出这个判断。单个许可证只告诉你席位价格。工厂告诉你的是每个成果的成本。没有这个数字，预算讨论就会变成一场关于席位的争吵。

第四个极限在前三个解决、产出上升之后才会出现。想象一下你的团队在智能体到来之前的样子，然后再想想之后。

Uber 自己的评审团队在 8 月的 AI Engineer 大会上给出了这些数字：

“回到 2024 年，我们看到工程师会在 3 小时内拿到第一次评审。而到了 2026 年，这已经增长到 9 小时。”

更多代码到达了同样数量的评审者手中。如果每个变更仍然要等人，更多的产出也无济于事。Spotify 也看到了同样的情况。在采用 AI 之后，它的待评审拉取请求增加了 76%。在 22,000 名开发者中，Faros AI——一家工程分析公司——测得评审所花时间的中位数上升了 441.5%。

这正是我早前那篇关于挑选智能体的文章中的规则适用之处。找出所有事情都在等待的那一步，然后把你的下一个智能体对准它。软件工厂则是对整条线做这件事，从想法到生产。评审是如今许多团队的慢步骤。Uber 说它接下来的慢步骤是 CI 容量、实验名额，以及决定要构建什么。工厂就是让你不断找到慢步骤，并推动它的方式。

那么，哪些智能体上线，它们又插在哪里？先从 Uber 的图谱开始。

在本文中，一条线指的是一个智能体只做一件事，比如评审拉取请求或清理旧的功能开关。Uber 在整个 SDLC 中运行一小组这样的智能体，外加一个前门。先看图谱。然后跟着一个功能走一遍，看看为什么最初的智能体承担了那些苦活。

Uber 把它的图谱画成了其效率文章中的图 3。它把每个智能体会话归入四个层级，从最专用到最通用。用 Uber 的话说，“层级越高，我们对成本、质量和模型选择的控制力就越强”。在构建任何东西之前，先把你自己的公司放到那张图上。

以下是四个层级，从上到下：

  • 专用智能体。少数几个智能体，每个都为一项狭窄的工作而构建。它们在 Uber 的云中运行，并有人参与其中。Minion 把意图转化为拉取请求，uReview 来评审它。Agentic XP 撰写实验结果。Conan AI 找出告警的根本原因，Fawkes 运行定期维护。每个都有自己的单价：每个已合并拉取请求、每次评审、每个告警、每次清理的成本。

  • 一个通用智能体。Cortana 是唯一的前门。它在 Uber 的云中运行，无需设置。它可以使用公司市场中任何技能。其单位是每次查询的成本。

  • 带技能的会话。开发者在自己笔记本电脑上的会话，加载了相同的共享技能。Uber 统计到超过 3,600 个这样的会话。

  • 原始会话。没有任何附加内容的 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 随后为 A/B 测试起草了两个 Figma 模型，每个使用不同的按钮文案。它还列出了该功能可以复用的现有屏幕和后端服务。Huda 说，过去让所有人就此达成一致需要数周时间。

  • 构建。 Cortana 移交给 Minion，Uber 的云端编码智能体，运行在 DevPod 中。Minion 跨代码仓库编写后端变更和新的上车屏幕的前端变更。它停在一个草稿拉取请求处，还不会推送到 CI。苦差事可以直接通过，但新功能会先被检查，这样 CI 就不会承受额外负载。

  • 验证。 检查提前了，在 CI 之前。一项技能在模拟器中启动应用，抓取上车屏幕的截图，并将其与 Figma 模型进行比较。另一项技能在预发布环境中启动服务，以用新的后端测试新的前端。

  • 审查。一个更快的中等规模模型在变更进入 CI 之前对其进行审查。一个更强的推理模型在 CI 中做更深入的检查。

  • CI。当构建失败时，自愈式 CI 会自行修复许多错误。

  • 交接。拉取请求到达人工手中时，附带一张列出其通过的所有检查的表格，包括模拟器截图。这张表格让人类审查者有理由信任这个 diff。

  • 维护。实验结束，变体 B 不再需要。它的功能开关进入一个受管理的清理循环。该循环在周末运行，那时 CI 有空闲容量，并限制工程师回来时落到他们手上的 diff 数量。这些 diff 是被合并还是被拒绝，都会成为改进清理技能的数据。

  • 事故。每月一次，Uber 会阅读其事故复盘以寻找模式。每一个能捕捉到的模式都会成为一项新的维护技能，应用到所有服务上。

Anthropic 把同样的循环写成了 playbook，作者是 Louis Claxton。Anthropic 出售它所运行的 agent，所以读它是为了了解其形态。每个阶段向版本控制写入一个文件，下一个阶段从读取它开始。一个想法变成 intent.md，然后 spec.md，然后 plan.md，然后是代码和测试、一个拉取请求，以及一份事故记录。人在三道关口把关：接受意图、批准计划、批准合并。该 playbook 自己的建议是先手动提示每个阶段，最后再自动化循环。

其他人如何运行同样的阶段：

  • Stripe。 它的 Minions 每周合并超过 1,300 个拉取请求，没有人类编写的代码。但仍有人审查每一个。

  • Spotify。 它的后台 agent 对每个变更运行验证器。一个充当裁判的模型会否决大约四分之一的会话，然后 agent 有一半时间会纠正方向。

  • DoorDash。 它把审查一分为二。一个侦察员标记可疑区域，更深入的审查者检查每条线索。

那么哪个阶段先做？在 Uber，答案是苦役。 Google SRE 书用一句值得记住的话定义了它：

“苦役是那种与运行生产服务相关的工作，它往往是手动的、重复的、可自动化的、战术性的、缺乏持久价值的，并且随着服务增长而线性扩展。”

Uber 已经运行了 250 多次自动化迁移，涉及 900 万行代码。Minion 也构建功能，但对于苦役之外的任何事情，它止步于草稿拉取请求。Uber 希望在那些功能加载 CI 之前对其进行验证。 选择那条错误答案代价低、正确答案显而易见的线。 把 SRE 的那句话当作检查清单，并增加一项测试：“完成”必须易于检查。

苦役仍然需要正确的工具，Uber 是吃了苦头才明白这一点的。对于其 JUnit 5 迁移， Uber 首先尝试了生成式 AI：

“我们尝试使用生成式 AI 一次迁移多个测试类文件，但这种方法没有成功。”

于是 Uber 转向了确定性方法。一个用于大规模代码变更的内部工具 Shepherd 生成了 5,000 多个 diff。AI 只帮助调试测试和构建失败。四个月内迁移了超过 75,000 个测试类。能写规则的时候，就写规则。把智能体留给规则触及不到的地方。

其他人如何选择他们的第一条线：

你可以在购买的智能体上运行第一条线。Claude Code on the web、Copilot cloud agent 和 Cursor 的云智能体都适用。每个都在隔离的机器上运行任务，并返回一个拉取请求。以影子模式启动，它只评论，没人需要采取行动。如果你的第一条线位于 CI 中，该手册中最小的动作是一个只读任务。claude -p 在脚本中运行 Claude Code，没有聊天窗口：

“在流水线任务中使用 claude -p 来分诊失败的构建、总结不稳定的测试，或起草变更日志。”

它读取并报告。在人发话之前，什么都不会发布。一旦第一条线赢得信任，下一个问题就是添加什么。

在你添加另一个智能体之前，问问它为审查和 CI 增加了什么。能减轻人员负担的智能体优先。Uber 已经在运行这四个：

  • 审查路由。 Code Inbox 将每个拉取请求发送给最适合阅读它的审查者。它更快地清空审查队列。

  • 编排迁移。 Shepherd 选择目标，Minion 处理特殊情况。为安全的 diff 规划自动合并规则。

  • 功能标志清理。 当 CI 有余力时，一个受管理的循环会移除过时的标志。

  • 设计规范。 uSpec 将 Cursor 中的智能体连接到 Figma 并编写设计系统规范。为三个平台编写完整的屏幕阅读器规范只需不到两分钟。

以及来自其他公司的三个智能体：

  • 按需修复，在 DoorDash。 对于任何审查评论，无论是来自智能体还是人，任何人都可以在拉取请求线程中标记该智能体。“你能处理这里的 nil 检查吗？” 一个修复器在远程机器上进行更改并将其推回拉取请求。Claude Code on the web 也提供同样的功能。

  • 安全扫描，来自 Anthropic 的手册。 一个定时智能体扫描你最关键的代码库。手册说，第一次扫描会标记出所有人都以为干净的代码。Anthropic 出售扫描器，所以请谨慎看待这一点。

  • 欺诈检查，在 Warp。 Warp 每 8 小时运行一次欺诈机器人。在一次运行中，它发现了近 6 万美元的欺诈使用并编写了修复。Warp 出售它所运行的平台。

这些 agent 底下都需要同样的东西。它需要一个运行的地方、能触及的工具，以及不能打破的规则。这就是底线。掀开引擎盖，看看它是由什么构成的。

Uber 在 8 月的 AI Engineer 大会上最清晰地展示了它的平台。Uday Kiran Medisetty 和 Adam Huda 逐一讲解了六个构建模块。这六个模块都不是编码 agent 本身。首先是模型网关和 MCP 网关。然后是云开发环境，称为 DevPods，以及一个技能市场。最后是上下文图和 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 机密。网关持有你拥有的每一个供应商密钥。把它当作你架构图上最敏感的盒子。固定它、修补它，并给它指定一个负责人。

第二个模块是沙箱，即 agent 工作的隔离机器。Uber 的版本是 DevPod。Uber 维护一个就绪的机器池，每个仓库都已复制进去，搜索索引也已构建好。Agent 可以在几秒内开始工作。对于跨仓库工作，一个单一的大型 DevPod 容纳了 Uber 的所有代码。速度比你想象的更重要，因为没人愿意等一个缓慢的沙箱。

其他人如何运行他们的沙箱：

这些机器本身也在出售。AWS AgentCore Runtime 为每个会话提供独立的 microVM（小型虚拟机），最长可用 8 小时。Modal、E2B、Daytona、Ona 和 Coder 也出售沙箱。但它们都不出售你的代码仓库——已安装、已构建、随时可用。 机器是商品，而你的代码的热快照需要你自己来构建。 运行中的 agent 仍然需要一条进入你系统的通道。

第三个模块是工具目录。Agent 通过 MCP（Model Context Protocol，模型上下文协议）接入你的系统。这是一个把工具接入 agent 的开放标准。Uber 有数千个内部 API，但没有一个为 agent 做好准备。于是它构建了一个带爬虫的 MCP 网关。 一次配置变更就能把内部 API 变成工具。

不过工具是要消耗 token 的。每个工具都附带一段 agent 必须阅读的描述。在 Uber，100 多个工具为每个提示词增加了 50,000 到 70,000 个 token。Uber 的解决办法是把 1,000 多个工具变成命令。Agent 只在需要时才查找某个命令。 目录大没关系，只要每个 agent 只加载它需要的工具。

Stripe 从另一端得出了同样的规则。它的目录 Toolshed 收录了近 500 个工具。但每个 agent 启动时默认只带 “一个刻意精简的工具子集”。这个模块的管道你可以买：Docker 的 MCP Gateway、AgentCore Gateway 和 Microsoft Foundry 都在出售。 你买不到的是你公司所需的工具清单。

第四个模块是上下文，它决定 agent 是否会靠猜。Uber 把同一个数据问题交给两个 agent。一个能查询它的上下文图谱，另一个不能。有依据的 agent 在 38 秒内找到了正确的表。另一个花了 20 分钟，撞上三次错误，然后说数据无法查询。Uber 的总结是：“没有依据的 agent 失败得慢，而不是失败得便宜”。 上下文是平台层面的工作，做一次，供所有 agent 使用。

Uber 的图谱连接了来自 30 多个内部系统的 2,400 万个节点。 你可以从远小得多的规模起步。 Meta 让 50 多个 agent 阅读同一个大型代码库，并写出 59 个简短的上下文文件。在早期测试中，Meta 的 agent 随后每个任务减少 40% 的工具调用。在最小规模下，上下文就是一个 Claude Code 首先读取的 CLAUDE.md 文件。把它控制在一页以内。覆盖范围和上下文让 agent 有用，而最后两个模块保证它的安全。

第五个模块是 harness：运行 agent 的循环，以及启动它的触发器。Uber 在一个 harness 上运行其托管 agent，该 harness 在一个接口后面服务于任何模型，无论是前沿模型还是开放权重模型。然后它在各自的真实工作上对每个 agent 进行基准测试，并转向最适合该工作的模型。触发器来自 Slack、CI、定时任务和告警。 始终属于你的是你公司所信任的步骤顺序。

Stripe 把这种顺序称为蓝图：“用代码定义的工作流，用来指挥一次 minion 运行”。有些步骤是普通代码，比如最后运行 linter。另一些是 agent 步骤，需要判断力。普通步骤节省 token，也让 agent “少一点出错的机会”。skill 是 agent 大概率会遵循的指引，而 hook 可以阻止它。

第六个模块是关卡，从身份开始。在 Uber，一个 pull request 曾把一个“Monitoring Agent”列为作者。提出请求的工程师已从记录中消失。Uber 的修复方案在每一跳都签发短时效、限定范围的 token，这样回溯到具体个人的链条得以保留。如今数千个内部 agent 都在使用它。给每个 agent 独立的身份，只授予其工作所需的权限。Anthropic 也学到了同样的教训：其事故 agent 要求另一个 Claude 实例推送修复，被人工审查关卡拦下了。

最后一道关卡位于生产环境之前。Anthropic 的 playbook 用一句话概括：agent “可以行动到生产关卡，但无法通过它”。agent 写的一切都以 pull request 形式提交，而写代码的 agent 不能批准它。Ramp 以启动会话的人的身份打开每个 pull request，这样没人能批准自己的变更。通过 OpenTelemetry（追踪的开放标准）记录每一次工具调用。关卡正是让你敢对更多 agent 说“是”的原因。

这些事故展示了没有关卡会发生什么：

最后一条恰好适用于工厂，因为你的 agent 会读取工单。Meta 的 Rule of Two 是值得贴出来的防御原则。在一次会话中，agent 最多可拥有三种能力中的两种：

  • 读取不可信输入，比如公开 issue 或客户工单。

  • 访问敏感系统或私有数据。

  • 修改东西，或与外界通信。

三者都需要？那就由人来监督该会话。六个模块都点明了，只剩一个决定：买什么。

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

把整件事当作一个决定来看。从选项零开始：全部作为托管的后台 agent 购买。Claude Code on the web、Copilot、Cursor 和 Devin 各自打包了沙箱、触发器和 pull request 流程。你放弃了快照、工具和限制的控制权。例如 Copilot 的云 agent在 59 分钟时停止，且每次运行只在一个仓库中工作。选项零让你在动手构建任何东西之前，看清自己的底线需要什么。

当你不再满足于它时，像这样拆分工作。

购买管道：智能体、网关、沙箱、追踪和审查器。然后构建只有你们公司才知道的东西。这意味着你代码的热快照、你的工具目录和你的上下文。还意味着编码你 SDLC 的蓝图，以及门禁策略。你不需要在第一天就拥有全部。 Team Topologies，一本关于组织软件团队的知名书籍，称这为最薄可行平台。那是让其他团队更快的最小共享工具集，像产品一样为其用户运行。在这里，它意味着只构建你的第一个智能体所需的模块，并在团队提出需求时添加下一个。

Uber 的地板花了好几年，但构建可以比那更小。Ramp 的 Inspect 团队有5.5 个人：四名工程师、一名总监和一名兼职 PM。在其 v2 发布两个月后，Inspect 撰写了 Ramp 约 60% 的拉取请求。到 5 月，这一比例达到 75%。

最尖锐的警告来自 LinkedIn 的 Prince Valluri，在 InfoQ 上：

“不要试图在公司内部重建 GitHub Copilot 或 Cursor 或 Replit。”

他说得对，这就是全部的分界。购买智能体，构建它所立足的东西。地图已经完成。更难的部分是在不失去它所服务的人的情况下启动它。

先说一个诚实的差距。这里每个公开案例都是一家拥有平台团队的大型科技公司。没有一个描述从笔记本电脑起步的 300 名工程师的公司。所以下面的顺序在证明任何东西之前要求最少。它以更小的规模借用 Uber 的地图。每一步都有一个数字说明它奏效了。 只有当当前数字变化时，才进入下一步。

这个序列从今天工作在哪里等待开始，到更多行结束。在这之间，你在苦差事上证明一个智能体，然后只构建它需要的东西。负责门禁的人应该阅读Anthropic 如何保护自己的管道。这是一家供应商在写自己，但仍然是关于影子模式和风险层级最清晰的叙述。不过，第一步完全不需要任何东西。

第一步几乎不花钱，也不需要供应商。工作在几个地方等待：审查、CI、部署。审查是从 git 读取的最容易的等待，所以从那里开始。 从你自己的 git 历史测量你的审查队列。让一位队友在你拥有的仓库上，在 Claude Code 中运行这个提示。我在PostHog的公共仓库上运行了它，这是一家开源分析公司：

Using the GitHub CLI, look at the last 200 merged pull requests in the PostHog/posthog repository. For each one, find how many hours passed between the pull request opening and its first review from someone other than the author. Then tell me: the median and the 90th percentile of that wait, the share of pull requests that merged with no review at all, and the share that changed more than 400 lines. Show me the numbers in a short list, then one sentence on where the queue is.

Claude Code 的回答，逐字如下：

等待首次人工审查，以小时计：

  • 中位等待：6.1 小时

  • 第 90 百分位等待：160.8 小时（约 6.7 天）

  • 未经人工审查即合并：40.0%（200 个中的 80 个）

  • 更改超过 400 行：28.5%（200 个中的 57 个）

大多数获得人工审查的 PR 会在工作日内获得一次审查，但队列有长尾，还有一大群未经任何人工审查就合并。

这 200 个 PR 在 UTC 时间 9 月 28 日 16:41 至 9 月 29 日 14:21 之间合并。PostHog 每天合并约 200 个 PR，所以这大约涵盖一天。“更改行数”指添加加删除。

我把机器人审查者排除在外：coderabbitai、stamphog、greptile-apps、copilot、veria-ai、codex 连接器和 posthog 机器人。它们几乎会在几分钟内审查每一个 PR。如果把它们算进去，中位等待时间会降到 0.07 小时（约 4 分钟），第 90 百分位降到 0.53 小时，而且没有 PR 是在没有审查的情况下合并的。排除机器人的数字才是描述人类队列的数字。

在“作者以外的人”这一检查中，有 23 个 PR 是由机器人打开的。我把它们保留在样本中。

这次运行大约花了六分钟，成本为 25 美分。一半的拉取请求在六小时内得到了人工处理。最慢的十分之一等了将近一周。还有 40% 在完全没有人工审查的情况下合并了。PostHog 运行着几个审查机器人，它们几乎会在几分钟内查看每一个拉取请求。机器人已经完成了它们那部分，所以要衡量人类队列。

该样本覆盖了 PostHog 大约一天的合并情况。把它当作提示词的演示来阅读，并在你自己的代码仓库上运行它。把数字写下来，因为之后的每一步都会以它们为评判标准。也要关注大型拉取请求的占比。DORA 的 AI 能力模型在其七项能力中列出了小批量工作。小批量可以对抗“AI 生成大型、不稳定变更的风险”。有了写下来的基线，你还需要建立在其之上的记分卡。

Uber 的记分卡是一个很好的思考起点。保留它的形态，然后选择适合你自己工作的数字。每个托管代理都会报告三类数字：

  • 每个结果的成本。每个已合并拉取请求、每次审查、每个告警、每次清理的成本。

  • 质量。回滚率、审查者的 F1，以及从事故中恢复的时间。

  • 数量。落地的 diff、发布的审查、分诊的告警。

没有质量数字相伴的吞吐量数字会诱使人们钻空子。Uber 也说明了为什么“由 AI 编写的代码百分比”是一个薄弱的主标题。8 月，它表示超过 70%的拉取请求涉及代理。5 月，其后台代理团队谈到了11% 的已合并拉取请求。取决于统计口径，这个数字在一家公司内部就变化了六倍。

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

更难的问题仍然悬而未决。Uber 的 Andrew Macdonald 表示，从使用情况到有用功能之间“很难划出一条界线”。衡量每个结果的成本，否则你也无法回答这个问题。

其他人如何记分：

这些数字让工厂保持诚实，而由人来决定它是否被采用。

接下来是大多数推广都会搞错的部分。开发者可以很快拒绝一个工厂，而有些反对意见比工具本身更深刻。一位 Anthropic 工程师对公司自己的研究人员直言不讳：

“对我来说，这是一个时代的终结——我已经编程 25 年了，而在这项技能上感到胜任是我职业满足感的核心部分。”

可观测性公司 Honeycomb 的联合创始人 Charity Majors 提出了职业版本的问题。“你需要什么才能完全放心地发布你没有读过的代码？” 他们俩都没错。两者都要认真对待，因为提出这些问题的人是你最好的评审者。在成功实现采用的公司中，有四个做法反复出现。

先接手他们的苦活。 Uber 把“升级、迁移、bug 修复”交给了 AI。结果是“我们的工程师满意度大幅提高”。清理功能开关和测试迁移是团队里没人会怀念的工作。智能体在队友面前，从真人手中拿走一件杂活。解脱感是通往信任的最快路径。

公开工作。 在 Uber，Cortana 在团队 Slack 频道中工作，因此它的回答对整个团队可见。Uber 自己的教训，由 Gergely Orosz 报道：“自上而下的强制命令不如工程师与同伴分享自己的成功经验有效。” DoorDash 也学到了同样的事。它最初的 Slack 集成给每次智能体运行分配了一个私有频道，它“没有形成团队习惯”。公开线程改变了这一点。人们会模仿他们能看到同事在做的事。

让他们自愿选择。 Ramp 表示，它“没有强迫任何人放弃自己的工具来使用 Inspect”。Inspect 最终还是编写了它的大部分拉取请求。强迫使用的结果更糟。Duolingo 的 Luis von Ahn 将 AI 使用情况从绩效评估中移除，他说 “我不会强迫你”。强制命令能给你使用数据，而这正是你刚刚决定忽略的指标。

把闸门交给他们。在 Uber，每个智能体的拉取请求都附带一张它通过的检查表，还包含截图。审查者在阅读 diff 之前就能看到证据。Anthropic 的做法更进一步：技术负责人把审查策略写在一个名为 REVIEW.md 的文件里。智能体从不批准自己的工作，因此每次合并都有人负责。开发者保留判断权，智能体负责打字。

当开发者问为什么是现在，别用恐惧推销。打造 Warp 的 Zach Lloyd 在 AI Engineer 上做出了预测。他说，每家公司都将“以软件工厂为核心”，就像它们拥有 CI/CD 一样。他自己就在卖这个，所以请权衡一下。更好的证据是那些不再需要人工完成的工作。Spotify 已经合并了超过 250 万个自动化维护拉取请求，其中大多数没有人工介入。这门手艺正从敲代码转向设计敲代码的流水线。

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

你的开发者已经拥有智能体。这部分已经解决，而且每过几个月就会有更好的版本发布。剩下的是地基。那是智能体运行的地方、它能触及的范围，以及它无法打破的规则。然后是说明它正在起作用的数字。之前那篇文章的规则依然成立。找到所有事情都在等待的那一步，然后不断推动它。

如果你需要在会议室里用一句话，就用这句：

我们的工程师已经拥有智能体。我们正在构建它工作的地基，并从那个没人愿意手工完成的任务开始。

以下是作为清单的路线：

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

  • 选择流水线。选择一个通过 SRE 测试且“完成”标准明确的苦差事。

  • 购买智能体。在托管的后台智能体上以影子模式运行这条流水线。

  • 构建最薄的地基。先添加一个模型网关，然后只添加流水线证明它需要的东西。

  • 设置闸门。给每个智能体一个身份，没有通往生产环境的路径，也无法自我批准。

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

  • 公开工作。使用公开线程和选择加入，并让技术负责人负责审查策略。

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

Uber 团队以这一切之后的问题结束了演讲。一旦你几乎可以构建任何东西，问题就变了。Adam Huda 这样说道：“这更多是我们是否应该构建它的问题”。这是一个产品问题，它位于你添加的每条流水线的上游。这也是工厂中一直属于你的那部分。

以下是本文使用的所有链接，外加一些未能放入的链接。它们按公司分组，然后按构建模块分组。关于自家产品的供应商文章已标记。

Uber

Anthropic（出售其运行所依赖的代理）

Spotify

Stripe

DoorDash

Ramp

Shopify

Intercom

Meta

Warp（销售该平台）

其他公司

研究与框架

市场上的构建模块

Incidents worth reading

The PostHog example from the rollout section uses the public PostHog repository. My earlier post on picking agents covers the constraint rule this article builds on.

No posts

来源：Hacker News · theaithinker.com

Agent 智能体部署工程MCP 与工具调用教程实践#教程/实践#Agent#部署/工程#MCP/工具调用#Anthropic#OpenAI