【翻译】Minions：Stripe One-shot 端到端 Coding Agent 认知

写在前面

这篇是 Stripe Minions Part 1 + Part 2 的合编翻译整理版。
原文发布时间：Part 1 = 2026-02-09，Part 2 = 2026-02-19。
我尽量保留原文的技术主线，但会换成更好懂的说法来讲清楚它到底厉害在哪里。
如果你只想先抓重点，可以先记住一句话：Minions 不是"帮你写两段代码"的聊天机器人，而是一套能把需求推进到 PR 阶段的工程 Agent 系统。

把"智能"放进"流程"，AI 才能从"看起来很强"变成"真的能交付"。

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

术语速览

Agentic Coding：不是"AI 给一段代码建议"，而是 AI 自己去查资料、改代码、跑命令、解决问题。
Unattended Agent：你把任务丢给它，它自己往下跑，中间不用一直盯着。
One-shot：尽量一次把事情做完，不是改一小段就停。
Devbox：给 Agent 准备的独立开发环境，你可以理解成"临时工位"。
Blueprint：Stripe 给 Agent 定的执行流程，哪些步骤必须做，哪些步骤交给模型发挥。
Agent Harness： Agent 的"运行外壳"，负责调工具、控流程、塞上下文。
MCP：让模型去连工具、连系统的一套通用接口。
Toolshed：Stripe 内部的工具总线，很多 Agent 都从这里拿能力。
Lint：代码规范和静态检查。
CI：代码提交后的自动构建、自动测试那套流水线。
Shift Left：能在本地发现的问题，就别拖到 CI 再炸。
Flaky Test：这次过、下次挂，特别烦人的随机失败测试。

这篇文章到底在讲什么？

Minions 是 Stripe 内部的一套无人值守编码 Agent 系统。工程师在 Slack 里丢一个任务， Agent 就会自己去拉上下文、改代码、跑检查、修问题、推分支、准备 PR，尽量把整条链路一次走完。

根据 Stripe 披露，合并到主干的 PR 里，每周已经有 1300+ 是 Minions 产出的（Part 1 时还是 1000+）。换句话说，很多代码已经进入"人来审，但不一定要人亲手写"的阶段。

这篇文章的重点，不是某个模型参数多大，而是 Stripe 如何把 AI 塞进现有工程体系里，让它在大仓、强约束、高风险环境下依然能稳定干活。

1. Stripe 为什么非要自己做，而不是直接买现成工具？

核心原因其实不是"模型不够聪明"，而是 Stripe 的研发环境太特殊：

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

这就意味着：能从零写个 demo，和 能在超大代码库里安全改线上相关代码，完全不是一个难度级别。

Stripe 的思路也很明确：不是让 AI 另起炉灶，而是把它接进原有研发基础设施里，按现有规矩做事。

2. 使用体验：从 Slack 发一句话，到自动产出 PR

它的体验并不神秘，流程大概就是下面这样：

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

此外，Minions 也不只接 Slack，它还接进了文档系统、特性开关平台、工单系统。比如发现某个 flaky test 老是飘，就可以直接一键叫 Agent 去修。

3. 真正的底座：不是模型，而是 Devbox

Part 2 把这一层讲得更透：Minions 能跑起来，靠的不只是模型，而是 Stripe 早就为工程师准备好的开发底座。

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

这里有一个很重要的工程洞见： 以前为了提升人类研发效率而建设的基础设施，恰好也是 AI Agent 最好的宿主。

这点非常关键。很多团队上来先研究"模型怎么选"，但 Stripe 的答案是：先把运行环境搭稳， Agent 才有机会稳定输出。

4. Agent 内核：不是放任 AI 自由发挥，而是塞进 Blueprint 流程机

Stripe 在分叉 Block goose 的基础上，做了自己的 agent harness。里面最关键的设计，不是什么玄学提示词，而是一个叫 Blueprint 的流程框架：

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

说白了，Stripe 没有让 Agent "想到哪做到哪"，而是给它套了一层流程骨架：哪些步骤必须做死，哪些地方再让模型发挥。

这样设计的直接收益很实际：

降低 token 与 CI 成本。
减少 Agent 在"可预知子任务"上的犯错概率。
通过更小、更干净的子上下文提升稳定性。

5. 上下文工程（1）：别把全仓都塞给模型

在超大代码库里，规则文件其实就是 Agent 的"工作守则"。

Stripe 的做法是 少放全局规则，多放局部规则：

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

这背后的思路很朴素：不是让模型知道一切，而是只在它需要时，把和当前任务最相关的规则喂进去。

6. 上下文工程（2）：静态信息看文件，动态信息靠工具

文件系统里的代码和文档，只能解决"静态知识"；像工单状态、构建结果、内部文档这类"动态信息"，就得靠工具调用。Minions 通过 MCP 获取文档、工单、构建状态、代码检索等信息。Stripe 进一步做了统一平台化：

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

这个思路很像"内部 API 网关 + 能力市场"，只不过以前是给人用，现在变成主要给 Agent 调用。

7. 安全模型：可以放手让它跑，但不能让它乱跑

Minions 虽然能自己跑命令、调工具、改代码，但它不是满世界乱飞，活动范围卡得很死：

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

所以 Stripe 才敢少弹很多确认框，让 Agent 执行更顺畅；因为它不是"完全自由"，而是"在一个被圈好的安全场里自由行动"。

8. 反馈闭环：先本地自查，再有限度地打 CI

Stripe 追求的是 one-shot，但它并没有天真到觉得"所有任务都能一次过"。真实做法是：尽量在本地把坑踩完，再把问题压缩到最少：

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

为什么要限制轮次？

因为每多打一轮 CI，就要多花 token、算力和等待时间，而且越往后收益越低。说白了，Stripe 不是在追求"无限试到过为止"，而是在做一个很现实的平衡：成本、时效、质量 三者不能一起拉满。

9. 两篇文章 Stripe 其实反复在讲 6 件事

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

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

这 6 条里，最值得记住的一点是： Agent 的价值，不只是"会写代码"，而是能不能嵌进现有工程流程里稳定交付。

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

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

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

和"普通 AI 聊天写代码"最大的区别就在这：它不是回你一段代码建议就算完事，而是尽量把 从接需求到提 PR 这条链路自己走完。

再直白一点：

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

11. 如果你不是 Stripe，也可以先抄一个轻量版

你完全没必要一上来就做 Stripe 这种规模。更实际的做法，是先搭一个"轻量 Minion"：

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

比较适合先试点的任务类型：

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

不建议一开始就丢给 Agent 的任务：

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

一句话建议：

先把 Agent 当加速器，不要一上来就当替代者。 先做低风险、可验收、能闭环的小任务，跑顺了再逐步放权。

实战：用 goose 跑一遍"从提需求到产出代码"

下面给一个可以直接上手的最小实战流程，目标不是复刻 Stripe，而是让你从 0 到 1 亲手体验一次" Agent 接任务 -> 生成产物 -> 继续迭代"的闭环。

Step 0：准备环境

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

Step 1：安装 goose CLI

macOS / Linux：

bash 复制代码

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

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

bash 复制代码

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

Windows（Git Bash / MSYS2 / PowerShell）：

bash 复制代码

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

Windows（纯 PowerShell 方式）：

powershell 复制代码

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

Step 2：配置模型提供方

运行：

bash 复制代码

goose configure

按提示选择：

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

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

Step 3：开启一次会话

创建一个空目录做演示：

bash 复制代码

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

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

text 复制代码

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

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

Step 4：给 Agent 加"手脚"（可选）

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

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

然后让它执行：

text 复制代码

open the tic-tac-toe game in a browser

Step 5：把它变成真正的"工程任务"，而不只是 Demo

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

text 复制代码

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

这个写法的重点在于：目标 + 约束 + 验收标准 要一次说清。

很多人觉得 Agent "不靠谱"，本质上不是模型完全不行，而是任务单写得太虚。

Minions 值得学的到底是什么？

如果只看表面，Minions 像是"Stripe 做了一个很强的写代码 Agent"。但往深一层看，它真正值得学的不是某个提示词，也不是某个模型，而是下面这套思路：

先把工程环境标准化，再让 Agent 进去干活。
先把确定性流程固化，再让模型处理不确定性。
先把反馈回路前移，再去追求 one-shot。
先从低风险任务拿结果，再慢慢扩大 Agent 权限。

所以这篇文章真正的主题可以浓缩成一句话：

AI 之所以能在 Stripe 里真正落地，不是因为它更像人，而是因为它被放进了一套足够成熟的工程系统里。

参考链接

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