Clive Notes
Stripe · Minions · Part 2

Minions 底层怎么跑

每周合并 1300+ 条无人值守 PR 的编程 Agent,核心不是更聪明的对话, 而是:热就绪的 Devbox、确定性与 Agent 交织的 Blueprint、精选 MCP 工具,以及最多两轮的 CI 回环。

综合整理 · 2026-08 原文 Part 2 Part 1 相关:Kai

1. 先接 Part 1:Minions 是什么

Minions 是 Stripe 自研的无人值守编程 Agent:目标是 one-shot 完成任务。 到 Part 2 发布时,每周约 1300 条合并 PR 完全由 minion 产出(Part 1 时约 1000); 仍经人工 review,但不含人类手写代码。

Part 1 讲用法:多从 Slack 线程拉起,也能从内部文档 / Feature Flag / 工单 UI 触发; 跑完推分支、过 CI、按模板准备 PR。Part 2 则拆 Stripe 特有的底层:环境、编排、上下文与反馈环。

贯穿全文的一句话 对人工程师长期投资的生产力基础设施(环境、规则、测试、工具),反过来成了 Agent 能规模化无人值守的前提—— 对人类好的,对 LLM 也好。

2. Devbox:热就绪、可并行、天然隔离

无人值守编码要规模化,需要云端开发环境具备三点:可并行、可预期、可隔离。 人要能同时派很多逻辑上互不干扰的活;Agent 需要干净环境与工作树,互相踩改会浪费 token; 全自动还要求系统性地隔离对特权机器与敏感凭证的破坏性操作。

笔记本上很难同时满足这些。容器或 git worktree 能帮一点,但难组合,也很难既像完整开发者 shell、又被恰当地约束。 Stripe 的解法是:Minions 跑在工程师日常写代码的同一套环境——devbox 上。

Devbox 是什么

  • AWS EC2,内含源码与开发中服务
  • 人大多用 IDE 经 SSH 连上去写代码
  • 「牲口不是宠物」:标准化、易替换
  • 一人常同时开半打左右

Hot and ready · 约 10 秒

  • 预热池:提前克隆巨仓
  • 预热 Bazel / 类型检查缓存
  • 拉起持续跑的代码生成服务等
  • 就绪后:REPL、测、改、类型检查、起服务都能立刻干
为什么这套对 Agent 是免费午餐 Devbox 本就是为人类并行、可预期、安全试错建的——隔离在 QA、无生产数据、无任意出网。 Minions 因此可以全权限跑、跳过确认弹窗:失误半径被关在一台 box 里。

3. Agent harness:为无人值守而改

Devbox 是现成的;agent harness 则是为 Minions 定制的。 2024 年末他们内部 fork 了 Block 的 goose, 接到 Stripe 的 LLM 基础设施上。之后功能演进刻意偏向无人值守,而不是「人盯着肩膀」的结对场景—— 后者已有 Cursor、Claude Code。

本地结对 Agent

人在环

  • 可打断、可中途改口令
  • 依赖确认弹窗保安全
  • 优化交互体验
Minions

无人值守

  • 不能靠 interrupt / 人手触发命令来纠偏
  • 隔离环境 → 可跳过确认
  • 大量小优化贴合 Stripe 开发流

更大、也更根本的优化是下一节的 Blueprint。

4. Blueprint:工作流 × Agent 的状态机

编排 LLM 常见两类原语(参见 Anthropic 的 workflows vs agents):

Minions 用的是第三种:Blueprint——用代码定义的工作流, 但某个节点既可以是确定性代码,也可以是聚焦子任务的 agent loop。 本质是「一串 agent skills,与确定性步骤交织」。

Implement task→ Run linters→ Push→ Fix CI→ …
节点类型 例子 谁做决定
Agentic(云朵) Implement task、Fix CI failures 模型在宽边界内自己判断
Deterministic(方框) Run configured linters、Push changes 不调 LLM,只跑代码
为什么要「把 LLM 关进小盒子」 能预见的小决策(比如「跑完一定 lint」)用确定性代码做:省 token、省 CI 成本、少给模型犯错机会。 Blueprint 还让子 agent 的上下文工程变简单——可约束工具、改 system prompt、为子任务裁剪对话。

团队也能自建专属 Blueprint,例如把「没法纯确定性 codemod」的棘手迁移编成专用流程。

5. 规则文件:按目录挂载,别一次灌满

在 Stripe 这种体量的仓里,Agent 若无指导,很容易偏离最佳实践或错用内部库——就算有 lint。 业界用 CLAUDE.md / AGENTS.md 一类规则让 Agent 遍历目录时自动「学」。

但仓太大,无条件全局规则必须极克制,否则上下文还没开工就装满规则。 他们几乎只挂「按子目录或文件模式」的规则,Agent 走到哪加载到哪。

6. Toolshed:中央 MCP,小盒子里干活

静态上下文靠文件系统;动态信息(内部文档、工单、构建状态、代码智能等)靠网络工具调用。 MCP 成标准后,他们把 Minions 接上去,并在跑起来之前对「看起来像链接」的东西确定性预拉 MCP,先灌上下文。

Stripe 内部 Agent 种类很多:无代码搭建器、专用服务、第三方现成 Agent、CLI、Slack bot…… 都需要 MCP,且工具集大量重叠。于是建了中央内部 MCP 服务 Toolshed:

~500
Toolshed 上的 MCP 工具(内部系统 + SaaS)
共享层
加一个工具 → 整个 Agent 舰队立刻能发现
精选子集
Minions 默认小工具箱;可按 blueprint 加主题包
安全 无人值守 + 可自由调 MCP,仍靠安全控制框架挡破坏性动作; 第一道防线仍是 Devbox:QA 环境、无真实用户数据、无生产服务、无任意出网。

7. 反馈左移:本地 lint → 最多两轮 CI

One-shot 是目标,但失败时必须有自动化反馈可迭代。Stripe 有 300 万+ 测试可当反馈源—— 但他们不想全靠推分支后的全量 CI。

原则是 shift feedback left:CI 会挂的检查,最好在 IDE / push 时就拦下,反馈越早越好。

本地 lint 节点

Blueprint 里确定性跑配置好的 linter;推之前本地闭环。预计算启发式 + 缓存,常见 lint 修复常 < 1 秒。

第一轮 CI

推分支后选择性跑相关测试;能 autofix 的自动打上。

第二轮(上限)

无 autofix 的失败丢回 agent 节点本地再修,再推一次 CI;然后交回人类。

为什么只 1~2 轮 CI CI 烧 token、算力与时间;对 LLM 无限转全量 CI,边际收益迅速下降。 策略是:能本地修的先修完,再上 CI;通常一轮,最多两轮。

8. 可带走的结论

工程上的可复用点

  • 先有可并行、隔离的开发环境,再谈无人值守
  • 用 Blueprint 把「必做步骤」钉死,把「未知」留给 agent 节点
  • 规则按路径条件加载;全局规则极克制
  • MCP 中央化(Toolshed)+ 每 Agent 精选子集
  • 反馈左移;CI 迭代设硬上限

一句话收束

Minions 是「工业标准概念(harness、MCP、规则文件)× 多年为人打磨的内部工具」的混合物。 改的不只是模型调用,而是把 Agent 嵌进已经验证过的人类开发生产线上。

对照

Minions vs Kai

Minions:无人值守写代码,产出 PR。

Kai:给人(尤其非工程)做知识工作,产出报告 / 看板 / 文档。

两者都依赖「共享执行底座 + 领域技能 / 工具治理」——见 Kai 整理。