Stripe Minions
一句话定义
Stripe Minions 是 Stripe 内部一套企业级的 Loop-Engineering 实战系统——每周合并 1300 多个 PR、没有一行是人手写的，核心论点是”AI 的可靠性来自约束的质量，不是模型的大小”。
摘要
Minions 是把循环工程推到企业规模时最值得看的公开案例，细节来自 Stripe 工程师 Steve Kaliski 在播客《How I AI》里的讲述。它的触发方式极轻：你在 Slack 里 @ 一下 Minion bot，或给某条消息加个 emoji 反应，发完就不用管了（fire-and-forget）。但真正让它靠谱的不是触发轻，而是 LLM 醒来之前那一段——一个确定性的 orchestrator 先把上下文备齐，再让 agent 上场。
最反直觉的一点在底层：Minions 不是建在某个更强的模型上，它是开源工具 Goose 的一个 fork。它证明了一件事——一千多个 agent 能同时跑而不互相踩脚，靠的是工程约束的质量，而不在模型参数上。
详情
起源与背景
Minions 由 Stripe 工程团队搭建，对外披露主要通过工程师 Steve Kaliski 在《How I AI》播客的讲述。它常被引用为”loop engineering 已在企业生产环境每天跑着”的证据，与 Addy-Osmani 的个人 triage loop 形成”个人能搭 → 企业能规模化”的对照。
核心机制 / 工作原理
触发轻，准备重。 让 LLM 自己去找上下文是最不可控的环节——它可能搜错、可能漏、可能为了凑答案现编。Stripe 的做法是把”找资料”这种能写死规则的活从 LLM 手里拿走，交给确定性代码去办：扫 Slack 消息里的链接、拉 Jira、找文档、用 Sourcegraph 加 MCP 把相关代码搜出来。等 agent 上场，桌上已经摆好它要的所有材料。能用确定性逻辑解决的，绝不交给概率模型——这条线划在哪，直接决定 loop 靠不靠谱。
六层架构：确定性 gate 与 LLM 创造步骤交替咬合。 agent 写完代码，一段硬编码的 pipeline 跑 linter，agent 跳不过去；agent 去修 lint；修完，硬编码的步骤执行 git commit。沙箱用的是 Devbox，跑在 EC2 上，遵循”cattle not pets”——用完即弃，不当宠物养。每个 agent 的工作环境都是一头随时可换掉的牛，坏了不修直接起新的，这种设计让一千多个 agent 同时跑而不互相踩脚，因为没有哪个环境是”珍贵”的、动不得的。
| 环节 | 谁来做 |
|---|---|
| 触发 | 人（Slack @ 或 emoji） |
| 备上下文 | 确定性 orchestrator（非 LLM） |
| 写代码 | LLM agent |
| 跑 linter / commit | 硬编码 pipeline（agent 跳不过） |
| review 这 1300 个 PR | 人 |
应用 / 使用场景
- 企业级、高并发的自主代码修改与 PR 生产流水线
- 演示”约束的质量 > 模型的大小”这一工程命题的范本
局限与争议
- 人没退场，人换了工位：1300 个 PR 仍由工程师 review，时间从”写”挪到了”审”。loop 越能产出你没写的代码，能说”不”的那一环（硬编码 gate + 人工 review，见 Generator-Evaluator）就越关键。
- 一些流传很广的二手数字（如某些”提效 N 倍”综述）应谨慎对待；Minions 的细节相对可追到一手出处（Steve Kaliski 播客）。
与其他实体的关系
- Loop-Engineering —— 循环工程推到企业规模的旗舰案例
- Generator-Evaluator —— Minions 把”说不”的一半交给硬编码 gate，另一半留给人工 review
- MCP —— orchestrator 用 Sourcegraph + MCP 在 LLM 之前备齐代码上下文
参考来源
- Loop-Engineering循环工程橙皮书 —— 花叔，§06 三个真实的 Loop（Stripe Minions 部分）