Stripe 每周 1300 个 PR 全由 AI 写完：他们是怎么做到的？

每周 1300 个 PR，全是 AI 写的

Stripe 最近公开了一件让整个工程界震惊的事：他们内部有一套叫 Minions 的自研 AI 编程 Agent 系统，每周能独立完成并被 merge 超过 1300 个 Pull Request。

全 AI 写，人工 review，没有一行代码出自人手。

这不是 demo，不是实验，是真实跑在生产环境里的系统——而且处理的是每年流转超过 1 万亿美元支付量的代码库。

原文链接：Minions: Stripe’s one-shot, end-to-end coding agents

为什么 Stripe 要自己造轮子？

市面上不缺 AI 编程工具，Cursor、Claude Code 他们都在用。但 Stripe 还是选择自研，原因很现实：

Stripe 的代码库太特殊了。

• 数亿行代码，分布在几个大型 repo 里
• 后端主要用 Ruby（不是 Rails），加上 Sorbet 类型系统——这个组合非常罕见，LLM 原生不熟悉
• 大量内部自研库，LLM 根本没见过
• 代码直接影响全球支付，容错率极低

通用工具在这种环境下效果打折扣。Stripe 需要一个深度集成自家工具链的 Agent，而不是一个通用助手。

他们的原则很简单：对人类工程师好用的工具，对 LLM 也应该好用。

Minions 的工作流程

一次典型的 Minion 任务是这样的：

1. 工程师在 Slack 里 @ 一下 bot，描述任务，或者贴上 issue/ticket 链接
2. 系统立刻启动一个隔离的 devbox（AWS EC2 实例），和人类工程师用的开发环境完全一样
3. LLM 开始思考之前，系统先确定性地自动拉取所有上下文：
   • Slack 完整对话线程
   • 相关 Jira/ticket 内容
   • Sourcegraph 代码搜索结果
   • 内部文档、设计文档
4. Agent 开始执行任务，修改代码
5. 本地跑 linter 和部分测试，改完代码 → git push → 触发完整 CI（Stripe 有 300 万+ 测试用例）
6. CI 失败 → 最多允许两次重试，超过就停，不无限循环
7. CI 通过后，Minion 按标准 PR 模板自动创建 Pull Request
8. 人类工程师 review → 批准 → merge

整个过程，工程师只需要在开头描述任务，最后 review 代码。中间全部自动完成。

工程师可以同时启动多个 Minion 并行处理不同任务，在 on-call 轮值期间特别有用——一堆小问题可以同时扔给多个 Minion 去解决。

核心架构：三个关键设计

1. Devbox：隔离的云端开发环境

Minion 运行在 Stripe 标准的 devbox 上——这是工程师日常用的 AWS EC2 开发环境，不是专门为 AI 造的。

关键特性：

• 10 秒内就绪：预先热身一批 devbox，包括克隆代码库、预热 Bazel 缓存、启动代码生成服务
• 完全隔离：每个 Minion 有独立的 devbox，互不干扰
• 有限爆炸半径：Agent 出错最多影响一个 devbox，不会波及生产环境，所以可以跳过确认提示，全权限运行

这个设计的妙处在于：devbox 本来是为人类工程师造的，结果发现对 AI Agent 同样完美适用。

2. Blueprints：确定性 + 灵活性的结合

Minion 的执行流程用一种叫 Blueprint 的原语来编排。

Blueprint 是一个状态机，混合了两种节点：

• 确定性节点（矩形）：直接跑代码，不调用 LLM。比如”跑 linter”、“push 代码”
• Agent 节点（云形）：让 LLM 自由发挥。比如”实现任务”、“修复 CI 失败”

这个设计解决了一个核心矛盾：纯 workflow 太死板，纯 agent 太不可控。Blueprint 把能确定的事情确定化，把需要灵活判断的事情交给 LLM。

实践效果：把 LLM 关进小盒子里，每个子任务只给它需要的工具和上下文，系统整体可靠性大幅提升。

3. 上下文工程：MCP + 400+ 工具

在 LLM 开始思考之前，系统通过内部工具 MCP + Toolshed（400+ 个工具）自动、确定性地拉取上下文。

这一步非常关键：与其让 LLM 自己去搜索需要的信息，不如在它开始之前就把相关信息全部准备好。

上下文来源包括：

• Slack 对话线程（任务的完整背景）
• Jira/ticket 内容
• Sourcegraph 代码搜索（找到相关代码文件）
• 内部文档和设计文档

对于代码库规则，Stripe 采用了 Cursor 的规则文件格式，并同步到 Claude Code 可读的格式——这样 Minions、Cursor、Claude Code 三套工具都能共享同一套代码库规范。

几个值得关注的细节

CI 重试上限是两次。 不是无限重试，超过就停。这个设计很务实——无限循环既浪费资源，也说明任务超出了 Agent 的能力范围，这时候应该让人类介入。

Agent 基于 Block 的 goose fork。 2024 年底，Stripe 内部 fork 了 Block 的开源 coding agent goose，然后针对 Minions 的无人值守场景深度定制。

规则文件的粒度控制。 由于代码库太大，全局规则会把上下文窗口塞满。Stripe 几乎只用目录级别的规则文件，Agent 遍历文件系统时按需加载，而不是一开始就全部加载。

并行是核心价值。 开发者注意力是最稀缺的资源。Minions 的核心价值不是替代工程师，而是让工程师可以同时推进多件事情。

这意味着什么？

Stripe 的实践给出了一个清晰的信号：大公司里纯 AI 写代码已经不是未来，是现在。

但有几点值得注意：

1. 不是替代，是增强。 人类工程师还在做最重要的事：定义任务、review 代码、把控质量。
2. 基础设施投入是前提。 Stripe 能做到这一点，是因为他们在开发者工具上有多年积累——devbox、CI、内部工具链。没有这些基础，Minions 跑不起来。
3. 适合特定类型的任务。 一次性、边界清晰的任务最适合 Minion。复杂的架构设计、跨系统的重构，还是需要人类主导。
4. 流程管理是关键。 严格的流程（隔离环境、CI 验证、人工 review）是让 AI 写代码可信赖的保障。

---

原文链接：

• Part 1: Minions: Stripe’s one-shot, end-to-end coding agents
• Part 2: Minions—Part 2