【翻译】Minions：Stripe One-shot 端到端编码代理

把“智能”放进“流程”，才会变成稳定生产力。

术语解释（先看这个）

1. Agentic Coding：由大模型驱动、可调用工具并自主推进的软件开发流程。
2. Unattended Agent：无人值守代理，中途不需要人类持续盯着操作。
3. One-shot：一次执行尽量完成任务，从需求到可评审 PR 尽量闭环。
4. Devbox：隔离的云端开发机，预装代码和开发服务，支持快速拉起与并行。
5. Blueprint：Stripe 的编排原语，把“确定性步骤”和“代理步骤”串成状态机。
6. Agent Harness：代理运行框架，负责调度、工具调用、上下文注入和流程控制。
7. MCP：Model Context Protocol，代理调用网络工具和外部系统的标准接口。
8. Toolshed：Stripe 内部统一 MCP 工具服务器，给不同代理提供共享能力层。
9. Lint：静态代码规范/质量检查。
10. CI：持续集成流水线，用于自动构建、测试和质量闸门。
11. Shift Left：反馈左移，让问题尽量在本地或更早阶段暴露。
12. Flaky Test：偶发失败、非确定性的测试用例。

写在前面

---

• 这篇是 Stripe Minions Part 1 + Part 2 合编整理版。
• 原文发布时间：Part 1 = 2026-02-09，Part 2 = 2026-02-19。
• 目标是保留原文技术脉络，同时用更通俗、可落地的方式组织内容。

把“智能”放进“流程”，才会变成稳定生产力。

持续分享技术干货，感兴趣小伙伴可以关注下 ^_^

---

一句话概括

Minions 是 Stripe 的无人值守编码代理体系。工程师在 Slack 里发起任务后，代理会在隔离 devbox 中自动完成编码、检查、修复、推送和 PR 准备。

根据 Stripe 披露，合并 PR 中每周已有 1300+ 由 Minions 产出（Part 1 时是 1000+），代码可做到“人审但不人写”。

1. Stripe 为什么要自研，而不是直接用现成工具？

核心原因不是“模型不够强”，而是工程环境太特殊：

1. 代码库规模超大（数亿行，多大仓）。
2. 技术栈有明显企业特征（Ruby 非 Rails + Sorbet + 大量内部库）。
3. 业务风险高（生产系统承载万亿美元级年支付流水）。
4. 监管与合规约束强，错误成本极高。

这意味着“从零写个 demo”与“在成熟大仓安全改代码”不是同一难度等级。
Stripe 的策略是把代理接入既有研发基础设施，而不是绕开它。

2. 使用体验：从 Slack 到 PR 的无人链路

典型流程如下：

1. 工程师在讨论线程中发起 Minion 任务（最常见入口是 Slack）。
2. Minion 读取线程和链接，收集上下文。
3. 在 devbox 执行实现、lint、本地校验、CI 迭代。
4. 自动建分支并推送，按模板准备 PR。
5. 人类做最终代码审阅，必要时追加指令继续迭代。

此外，Minions 也集成到文档系统、特性开关平台、工单系统。
例如检测到 flaky test 时，可一键拉起代理去修复。

3. 基础设施底座：Devbox 的“热启动 + 隔离 + 并行”

Part 2 把这一层讲得更清楚：

1. Devbox 本质是 AWS EC2 开发机，工程师日常也在这上面开发。
2. 设计理念是“cattle, not pets”：标准化、可替换，而不是个性化长寿命机器。
3. 为了做到“10 秒可用”，Stripe 会提前预热池子：拉代码、预热 Bazel/类型检查缓存、启动持续代码生成服务等。
4. 这种隔离环境天然适合无人代理：并行、可预测、低干扰、低爆炸半径。

这里有一个关键工程洞见：
过去为人类研发效率建设的基础设施，恰好也是代理规模化运行最好的宿主。

4. 代理内核：不是纯 Agent Loop，而是 Blueprint

Stripe 在分叉 Block goose 的基础上构建了 Minions 的 agent harness。
其最关键抽象是 Blueprint：

1. Workflow 的确定性：固定步骤能保底执行。
2. Agent 的灵活性：不确定问题交给模型自主探索。
3. 在同一状态机中混编两类节点：
4. 确定性节点：如 Run configured linters、Push changes（不调用 LLM）。
5. 代理节点：如 Implement task、Fix CI failures（调用 LLM + 工具）。

这样设计的直接收益：

1. 降低 token 与 CI 成本。
2. 减少代理在“可预知子任务”上的犯错概率。
3. 通过更小、更干净的子上下文提升稳定性。

5. 上下文工程（1）：规则文件体系

在超大仓里，规则文件是控制代理行为的重要手段。
Stripe 的做法是少全局、多局部：

1. 全局无条件规则严格受控，避免一上来就塞满上下文窗口。
2. 规则主要按子目录/文件模式条件加载，让代理“走到哪里学到哪里”。
3. 对齐人机规则文件：Minions 读取与人类常用工具（如 Cursor、Claude Code）尽量一致的规则体系，减少重复维护。

6. 上下文工程（2）：MCP 与 Toolshed

文件系统上下文只能解决静态知识，动态信息要靠工具调用。
Minions 通过 MCP 获取文档、工单、构建状态、代码检索等信息。Stripe 进一步做了统一平台化：

1. 构建内部 MCP 服务 Toolshed，作为全代理共享能力层。
2. 当前规模接近 500 个工具，覆盖内部系统和外部 SaaS。
3. 按任务和代理类型做工具子集配置，避免“工具过载”。

这个思路很像“内部 API 网关 + 能力市场”，只不过面向的是代理调用。

7. 安全模型：自由执行，但在受控边界内

Minions 可自主调用工具并执行代码，但安全边界清晰：

1. 默认运行在 QA 环境 devbox。
2. 无真实用户数据访问。
3. 无生产服务访问。
4. 无任意外网出口。
5. 叠加内部安全控制框架，避免工具被用于破坏性操作。

因此 Stripe 可以跳过大量确认弹窗，把执行效率拉高，同时维持可控风险。

8. 反馈闭环：Shift Left + 两轮 CI 上限

Minions 追求 one-shot，但并不幻想“永远一次过”。
它依赖多层自动反馈持续迭代：

1. 本地先跑快速 lint/检查（含预推送修复机制）。
2. 背景守护进程预计算 lint 规则，很多修复可在秒级完成。
3. 本地尽量清完再推 CI，提升首轮通过率。
4. CI 失败先自动应用 autofix；无自动修复则回传代理修一次。
5. 标准策略最多两轮 CI，然后交回人审。

为什么限制轮次？
因为 CI 每轮都消耗 token、算力和时间，边际收益递减明显。
这本质上是一个成本-时效-质量三目标优化问题。

9. 上下篇合并后的方法论总结

Minions 可迁移的经验可以归纳为 6 条：

1. 先有工程底座，再谈代理智能。
2. 让代理复用人类成熟工具链，避免双轨体系。
3. 确定性节点前置，把“必须对”的事情代码化。
4. 上下文做减法，按目录与任务精确注入。
5. 反馈左移，尽可能本地闭环，减少 CI 试错。
6. 并行化优先，释放工程师注意力才是核心收益。

10. 大白话版：把 Minions 想成“自动化实习生团队”

如果用生活化一点的比喻，Minions 像一个不会累、可并行的“实习生团队”：

1. 你在群里提需求，就像给实习生下任务单。
2. 它先去看文档、看历史工单、看代码，再动手干活。
3. 干完先自检（lint、本地检查），再提测（CI）。
4. 出问题就按报错回去改，改完再提一次。
5. 最后把一份可审阅的 PR 交给正式工程师把关。

和“普通 AI 聊天写代码”最大的区别在于：
它不是给你一段建议代码就结束，而是把从需求到提审这条链路尽量走完。

再直白一点：

1. Devbox 像给每个实习生分配独立工位，互不打扰。
2. Blueprint 像标准作业流程（SOP），关键步骤必须执行。
3. MCP/Toolshed 像企业内部知识库和工具总线，缺资料就自己查。
4. 两轮 CI 上限 像规定“最多返工两次”，防止无限试错烧成本。

11. 给中小团队的简化落地版（先抄这 5 步）

你不需要一上来就做 Stripe 这种规模。可以先做“轻量 Minion”：

1. 先把任务入口统一：只允许从工单或群消息触发，避免口头需求。
2. 固化最小闭环：拉分支 -> 改代码 -> 跑 lint/test -> 推 PR。
3. 做好隔离环境：哪怕只是临时容器，也要做到“可回收、可并行”。
4. 先接 3-5 个高频工具：文档检索、代码搜索、CI 状态、工单读取。
5. 给轮次上限：例如“本地循环不限，CI 最多两轮，之后必须人接管”。

适合先试点的任务类型：

1. 修 flaky test。
2. 批量小重构（重命名、样板代码替换）。
3. 文档和注释补全。
4. 低风险告警修复。

不建议一开始就给代理做的任务：

1. 账务、权限、风控等高风险核心逻辑。
2. 需求频繁变化且验收标准不清晰的任务。
3. 需要大量跨团队口头对齐的复杂改造。

一句话建议：
先把代理当“加速器”，不要当“替代者”；先做可控增量，再逐步放权。

12. 实战：用 goose 跑一个端到端任务

下面给一个可以直接上手的最小实战流程，目标是从 0 到 1 体验一次“代理写代码 -> 本地产物落盘 -> 继续迭代”。

Step 0：准备环境

1. 有可用的 LLM Provider（例如 OpenAI、Anthropic、Gemini、Tetrate、OpenRouter 等）。
2. 能在本机使用终端（macOS/Linux 的 shell，或 Windows 的 Git Bash / PowerShell）。

Step 1：安装 goose CLI

macOS / Linux：

curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | bash

如果你不想安装时进入交互配置：

curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | CONFIGURE=false bash

Windows（Git Bash / MSYS2 / PowerShell）：

curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | bash

Windows（纯 PowerShell 方式）：

Invoke-WebRequest -Uri "https://raw.githubusercontent.com/block/goose/main/download_cli.ps1" -OutFile "download_cli.ps1"
.\download_cli.ps1

Step 2：配置模型提供方

运行：

goose configure

按提示选择：

1. Configure Providers
2. 选择你的 provider
3. 输入 API Key（或走对应登录流程，比如 GitHub Copilot 的设备码登录）
4. 选择模型

配置完成后，goose 会提示 Configuration saved successfully。

Step 3：开启一次会话

创建一个空目录做演示：

mkdir goose-demo && cd goose-demo
goose session

然后直接给它一个明确任务，例如：

create an interactive browser-based tic-tac-toe game in javascript where a player competes against a bot

这一步结束后，目录里通常会出现 html/js 文件，你可以直接运行或打开验证。

Step 4：给代理加“手脚”（可选）

如果你希望 goose 能直接帮你打开浏览器、做网页自动化，可以启用内置扩展 Computer Controller：

1. 退出当前会话（Ctrl + C）
2. 运行 goose configure
3. 选择 Add Extension -> Built-in Extension -> Computer Controller
4. timeout 可以先用 300 秒
5. 继续会话：goose session -r

然后让它执行：

open the tic-tac-toe game in a browser

Step 5：把它变成“工程任务”而不只是 Demo

你可以把 prompt 改成更贴近真实研发的版本：

在当前仓库新增一个 /health 接口，返回 JSON：{"status":"ok","version":"v1"}。
要求：
1) 补充单元测试
2) 更新 README 的 API 示例
3) 输出你改动的文件清单和验证命令

这个写法的重点是：目标 + 约束 + 验收标准，能明显提升一次完成率。

Step 6：常见坑位（实战版）

1. goose 命令找不到：通常是 PATH 没加上（尤其 Windows）。
2. provider 配好了但调用失败：先检查 API key、额度和速率限制。
3. 本地模型效果不稳：优先换工具调用能力更强的模型。
4. 任务太大一次跑崩：拆成 2-3 个更小任务，逐个 session 执行。
5. 一直“会说不会做”：把 prompt 从“愿景描述”改成“可验收任务单”。

参考链接

---

• Part 1：https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents
• Part 2：https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2
• goose：https://github.com/block/goose
• goose Quickstart：https://block.github.io/goose/docs/quickstart
• goose Installation：https://block.github.io/goose/docs/getting-started/installation
• goose Providers：https://block.github.io/goose/docs/getting-started/providers

---

© 2018-至今 liruilonger@gmail.com, 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)