[翻译] Stripe:如何一周让 AI 提交 1300 次 PR,0 人工代码

原链接：https://blog.bytebytego.com/p/how-stripes-minions-ship-1300-prs

npx workos：一个能将认证代码直接写入你代码库的 AI 智能体

npx workos启动一个 AI 智能体^[1]，由 Claude 驱动，能读取你的项目、检测你的框架，然后将完整的认证集成直接写入你现有的代码库。它不是模板生成器。它会阅读你的代码，理解你的技术栈，然后写出与之匹配的集成代码。

WorkOS^[2] 智能体会进行类型检查和构建，并将任何错误反馈给自己进行修复。

每周，Stripe 合并超过 1,300 个完全不包含人工编写代码的 Pull Request。一行都没有。这些 PR 由 "Minions" 生成——Stripe 内部的编程智能体，完全自主运行，无需人工干预。

工程师在 Slack 中发送一条消息，离开去做别的事，回来就能看到一个已经通过自动化测试、准备好供人工审查的完整 Pull Request。这种生产力提升场景相当令人振奋。

运作方式如下：

来源：Stripe 工程博客

想象一位 Stripe 工程师在值班时，一夜之间积攒了五个小问题。他无需逐个处理，而是在 Slack 中发送五条消息，每条都 @ Minions 机器人并附上修复说明。然后去倒杯咖啡。等他回来时，五个智能体已经在不到十秒内各自启动了一台隔离的云机器，阅读了相关文档，编写了代码，运行了代码检查工具，推送到 CI，并准备好了 Pull Request。这位开发者审查后，批准了三个，对一个提出反馈，丢弃了最后一个。换句话说，在手动修复两个问题的时间内，五个问题已经全部处理完毕。

然而，Minions 能够运转的核心原因与驱动它们的 AI 模型几乎没有关系。一切都归功于 Stripe 在 LLM 出现之前数年就为人类工程师构建的基础设施。在这篇文章中，我们将深入探讨 Stripe 是如何达到这一水平的。

声明：本文基于 Stripe 工程团队公开分享的细节撰写。如有不准确之处，欢迎指出。

为什么现成的智能体不够用

你可能接触过的 AI 编程工具属于一类叫做"有人值守智能体"（attended agents）的范畴。像 Cursor 和 Claude Code 这样的工具与你协同工作。开发者观察它们，在它们偏离方向时进行引导，并在每一步进行确认。

请看下面的图表，展示了典型的 AI 智能体架构：

Stripe 的工程师也使用这些工具。然而，Minions 属于"无人值守智能体"（unattended agents）。没有人观察或引导它们。智能体接收任务，独立完成，然后交付最终结果。这一区别彻底改变了下游所有的设计要求。

Stripe 的代码库也让事情比听起来更困难。代码库包含数亿行代码，主要使用 Ruby 和 Sorbet 类型系统编写——这是一个相对不常见的技术栈。代码中充斥着大量自研库，这些库从未出现在 LLM 的训练数据中，而且生产环境中每年处理的支付金额超过 1 万亿美元。风险之高与复杂度之大同样极端。

从零开始构建原型与向如此规模和成熟度的代码库贡献代码有着本质区别。因此，Stripe 专门为无人值守工作构建了 Minions，而将有人值守的编程工作交给第三方工具处理。

Unblocked：为你节省时间和 Token 的上下文工具（赞助内容）

AI 编程工具快速、强大，但完全缺乏上下文感知。即使有规则、技能和 MCP 连接，它们生成的代码仍然会忽略你的约定、无视过去的决策、打破既有模式。你最终要为这个差距付出返工和额外 Token 的代价。

Unblocked 改变了这个经济学。

它从你的代码、PR 历史、对话、文档和运行时信号中构建组织上下文。它映射跨系统的关系，协调冲突信息，尊重权限，并针对当前任务呈现最重要的内容。智能体不再猜测，而是像经验丰富的工程师一样理解系统。

你可以：

• 生成反映系统实际运作方式的计划、代码和审查意见
• 通过提前提供更好的上下文，减少昂贵的检索循环和工具调用
• 减少纠正本应一次性正确的代码所花费的时间

运行智能体的环境

Stripe 决定自建后，首先要解决的问题是在哪里运行这些智能体。

无人值守智能体对环境有三个要求：

• 隔离性：错误不能影响生产环境。
• 并行性：多个智能体可以同时处理不同的任务。
• 可预测性：每个智能体都从干净、一致的状态开始。

Stripe 早已具备这三点。他们的"devbox"是预装了整个代码库、工具和服务的云机器。它们能在十秒内启动，因为 Stripe 会主动预热一个机器池，提前克隆仓库、缓存数据和启动后台服务。工程师已经习惯了每个任务使用一个 devbox，一个工程师可能同时运行五六个。智能体只是融入了同样的模式。

由于 devbox 运行在 QA 环境中，它们已经与生产数据、真实用户信息和任意网络访问隔离。这意味着智能体可以以完整权限运行，无需任何确认提示。任何错误的爆炸半径都被限制在一台可丢弃的机器上。

需要理解的关键点是：Stripe 不是为智能体构建这些的。他们是为人类构建的。在 LLM 出现之前很久，并行性、可预测性和隔离性就已经是工程师所期望的特性了。换句话说，对人类好的，对智能体也好。

智能体不即兴发挥

好的环境给智能体提供了工作场所。但它并没有告诉智能体如何工作。

编排 LLM 系统通常有两种方式：

• 工作流（Workflow）：固定的步骤图，每个步骤做一件窄小的事，顺序是预先确定的。
• 智能体（Agent）：一个循环，LLM 根据前一步的结果决定下一步做什么。

工作流可预测但死板。智能体灵活但不可靠。

Stripe 构建了介于两者之间的东西，他们称之为"蓝图"（blueprints）。蓝图是一系列节点，其中一些节点运行确定性代码，另一些节点运行智能体循环。可以把它看作在固定步骤和创造性步骤之间交替的结构。例如，"实现功能"步骤或"修复 CI 失败"步骤会获得完整的智能体循环，拥有工具和自由度。而"运行代码检查"步骤是硬编码的。"推送分支"步骤是硬编码的。

这种分离至关重要，因为有些任务永远不应该交给智能体的判断。你总是希望代码检查运行。你总是希望分支以遵循公司 PR 模板的方式推送。将这些步骤确定性化可以节省 Token、减少错误，并确保关键步骤每次都执行。每天数百次运行中，每个确定性节点就是少一个可能出错的环节，这些累积起来就是巨大的可靠性提升。

正确的上下文

蓝图告诉智能体如何工作。但智能体仍需知道自己面对的是什么。在一个数亿行代码的代码库中，如何将正确的信息塞进智能体有限的上下文窗口，本身就是一个工程挑战。

LLM 一次只能容纳有限的文本。如果你试图全局加载每一条编码规则和约定，智能体的上下文在工作开始前就被填满了。正因如此，Stripe "非常谨慎地"使用全局规则。他们将规则限定在特定的子目录和文件模式中。当智能体在文件系统中移动时，它会自动只加载与当前工作位置相关的规则。这些规则文件与 Cursor 和 Claude Code 等人工导向工具读取的完全相同，因此没有重复，也没有专门为智能体维护的额外开销。

对于不在文件系统中的信息，Stripe 构建了一个名为 Toolshed 的集中式内部服务器。它通过 MCP（Model Context Protocol，模型上下文协议）托管了近 500 个工具——这是一个行业标准，为智能体提供了调用外部服务的统一方式。通过 MCP，智能体可以获取内部文档、工单详情、构建状态、代码搜索结果等。

但工具不是越多越好。智能体在使用经过精心筛选的、与任务相关的工具子集时表现最佳。Stripe 为 Minions 提供了一个小的默认工具集，并允许工程师在需要时添加更多。

快速反馈，硬性限制

现在智能体有了环境、结构和正确的上下文。然而代码仍然必须正确，这意味着需要更多反馈循环。

Stripe 的反馈架构分多层运作：

• 第一层：本地代码检查在每次推送时运行，不到五秒完成。一个后台守护进程预先计算哪些检查规则适用并缓存结果，使这一步骤几乎是瞬时的。
• 第二层：CI 从 Stripe 超过 300 万个测试的测试池中选择性运行测试，已知失败模式会自动应用自动修复。
• 第三层：如果仍有无法自动修复的失败，智能体还有一次机会修复并再次推送。

然后就停止了。最多两轮 CI。如果代码在第二次推送后仍未通过，分支就退还给人类工程师。

这个上限是有意为之的。LLM 在反复尝试同一问题时收益递减。更多轮次消耗更多 Token 和算力，但改进不成比例。知道何时停下来和知道如何开始同样重要。

当一次 Minion 运行没有完全成功时，它仍然通常是一个有用的起点。一个工程师花二十分钟就能完善的半正确 PR 仍然是一个显著的胜利。Stripe 为这种现实而设计，而不是假装每次运行都会完美无缺。

结论

四个层次构成了 Stripe Minions 的运作基础：

• 隔离环境：为智能体提供安全、并行的工作空间。
• 混合编排：将确定性护栏与智能体灵活性相结合。
• 精选上下文：为智能体提供恰当的信息，既不匮乏也不过载。
• 快速反馈循环：配以严格的迭代上限。

每一层都不可或缺，单独任何一层都不够。

Stripe 方法的核心洞见在于：多年来对开发者生产力的投资，在将智能体纳入工作流时能带来意想不到的红利。人工审查并没有消失，而是转移了重心。工程师从编写代码转向了审查代码。

在考虑部署编程智能体时，一个关键教训是：不要从模型选择开始。从你的开发环境、测试基础设施和反馈循环开始。如果这些是扎实的，智能体将从中受益。如果不是，再好的模型也救不了你。Stripe 的经验表明，答案不在于 AI 突破，而在于那些本来就应该重视的工程基本功。