Stripe 如何用"仆从"每周交付 1300 个零人工代码 PR
Stripe 每周合并超过 1300 个 Pull Request，这些 PR 里面没有一个字是人类写的——全部由名为"仆从"（Minions）的内部编码 Agent 自动完成。
工程师在 Slack 上发一条消息，起身去接杯咖啡，回来时 PR 已经跑过自动化测试，等着人类审核。五个问题并行处理，所需时间只够手动修复两个。
听起来像 AI 模型的功劳？但 Stripe 真正厉害的地方，跟底层模型几乎无关——关键在于基础设施，而且这套基础设施在 LLM 出现之前就已经为人类工程师构建好了。
为什么市面上的 Agent 不够用
Cursor、Claude Code 这类工具属于"伴随式 Agent"（Attended Agents）：开发者全程盯着，随时纠正偏差、逐步审批。
而 Minions 是"独立式 Agent"（Unattended Agents）——没有人盯着，收到任务后独立完成，直接交付结果。这个定位改变了整个系统的设计逻辑。
Stripe 的代码库还让这件事难上加难：数亿行代码，主要用 Ruby 配合 Sorbet 类型系统，属于相对小众的技术栈；代码库里充斥着自研库，LLM 训练数据中从未见过；生产环境每年流转超过 1 万亿美元支付额——复杂度和风险都是极端级别。
从零搭一个原型容易，但要往这种规模和成熟度的代码库里贡献代码，必须专门为独立运行场景打造 Agent。
运行 Agent 的环境：十秒拉起的云开发机
独立式 Agent 对运行环境有三个刚性需求：隔离（错误不能影响生产）、并行（多个 Agent 同时处理不同任务）、可预测性（每次启动都是干净一致的状态）。
Stripe 早就具备了这三点。他们有一种叫"devbox"的云开发机，预装了整套代码库、工具链和服务。Devbox 十秒内即可就绪，因为 Stripe 提前准备好了资源池：仓库克隆、缓存预热、后台服务启动——全部提前完成。人类工程师本来就一个人同时跑着六七个 devbox，Agent 直接复用同一套模式。
Devbox 运行在 QA 环境，与生产数据、真实用户信息、任意网络访问天然隔离。这意味着 Agent 可以用完整权限运行，没有任何确认弹窗，任何错误的影响范围都限制在一台临时机器上。
关键在于：Stripe 建这套东西不是给 Agent 用的，是给人用的。 在 LLM 出现之前，并行、可预测、隔离这些特性对工程师就有价值。换句话说，对人类友好的设计，对 Agent 同样友好。
蓝图的本质：确定性节点与智能体循环的交替
蓝图（Blueprint）是 Stripe Minions 的核心组织形式。每个蓝图由一系列节点构成，其中部分节点运行确定性代码，部分节点运行完整的智能体循环。
具体来说，"实现功能"或"修复 CI 失败"这类任务需要充分发挥智能体的自主能力，赋予其完整工具集和自由裁量权；而"运行代码检查"或"推送分支"这类步骤则被硬编码为确定性节点，严格按照公司 PR 模板规范执行。
这种区分至关重要——有些操作永远不该交由智能体判断。例如，代码检查必须每次都执行，分支推送必须遵循统一规范。将这些步骤设为确定性执行，既节省 Token 消耗、减少随机错误，又能保证关键步骤每一次都准确落地。在每天数百次运行的规模下，每个确定性节点都意味着少一处隐患，积累下来就是可观的可靠性收益。
上下文管理：让智能体在海量代码中找到正确信息
蓝图定义了智能体"如何工作"，但智能体还需要知道"在什么基础上工作"。在代码量达数亿行的代码库中，如何将正确的信息注入智能体有限的上下文窗口，是一项工程挑战。
按需加载的规则体系
LLM 能容纳的文本量有限。如果一次性加载所有编码规则和约定，智能体的上下文在真正开始工作前就已经填满了。Stripe 深知这一点，因此对全局规则的使用"极为审慎"（very judiciously）。
Stripe 改用目录级规则作用域策略：将规则文件关联到特定子目录和文件模式。当智能体在文件系统中移动时，它只会自动拾取当前工作区域相关的规则。这些规则文件同时被人类使用的工具（如 Cursor、Claude Code）读取，无需重复维护，也不存在智能体专属的额外开销。
统一工具接口：Toolshed MCP 服务器
对于文件系统中不存在的上下文信息，Stripe 构建了名为 Toolshed 的集中式内部服务器。该服务器通过 MCP（Model Context Protocol，业界标准）托管近 500 个工具，为智能体提供调用外部服务的统一方式。
通过 MCP，智能体可以获取内部文档、工单详情、构建状态、代码搜索结果等多种信息。不过 Stripe 坚持一个原则：工具并非越多越好。智能体在精心筛选的子集上表现最佳。Minions 默认获得少量工具，工程师可根据需要自行添加。
快速反馈与硬性迭代限制
智能体获得了合适的环境、结构和上下文后，代码正确性仍需验证。Stripe 为此设计了多层反馈架构：
- 本地即时检查：每次推送时，本地 linting 在 5 秒内完成。后台守护进程预计算适用的 lint 规则并缓存结果，使这一步几乎瞬时完成。
- 选择性 CI 测试：CI 从超过 300 万个测试用例中有选择地运行测试，并对已知失败模式自动应用修复（autofix）。
- 最后一次机会：若失败仍无自动修复方案，智能体获得一次额外机会重新修复并推送。
之后强制停止。最多两轮 CI 迭代。若第二次推送后代码仍未通过，分支退回给人类工程师处理。
这个上限是刻意设计的——LLM 在重复尝试同一问题时存在边际效益递减。更多轮次意味着更多 Token 和算力消耗，但改善效果不成正比。知道何时停下，和知道如何开始同样重要。
Stripe 坦然接受一个现实：即使一次 Minions 运行没有完全成功，它仍然是有价值的起点。一份工程师只需花 20 分钟润色的部分正确 PR，仍是显著的效率提升。
Stripe Minions 的四层架构总结
Stripe Minions 的可靠性来自四层设计的协同：
| 层次 | 作用 |
|---|---|
| 隔离环境 | 为智能体提供安全、并行的执行空间 |
| 混合编排 | 确定性护栏与智能体灵活性结合 |
| 精选上下文 | 只喂给智能体必要信息，避免上下文过载 |
| 快速反馈循环 | 带硬性迭代上限的多层验证 |
每层缺一不可，但任何一层单独存在都不够。
核心洞察：别从选模型开始
Stripe 最重要的经验是：多年积累的开发者生产力投入，在引入智能体后可以获得意想不到的回报。人类评审并未消失，而是发生了转移——工程师从"写代码"转向"审代码"。
部署编程智能体的一个关键教训是：不要从选择模型开始。应该首先关注开发者环境、测试基础设施和反馈循环。如果这些基础扎实，智能体会从中受益；如果基础薄弱，再好的模型也救不了你。Stripe 的经验表明，答案与其说是 AI 突破，不如说是那些本该始终被重视的工程基本功。
评论