Harness Engineering，Minions - Part 1 #

这篇文章 Minions: Stripe’s one-shot, end-to-end coding agents 的解读。

Minions：Stripe 的端到端无人值守 Coding Agent #

一、背景：为什么需要 Minions？ #

过去几年，Agentic Coding（智能体编程）从一种新兴技术逐渐变成了软件开发的基础能力。

随着底层大语言模型不断进步，无人值守的 Coding Agent 已经从理论上的可能变成了实际可用的工程方案。

Stripe 自己研发了一套 Coding Agent，称为 Minions。

它有几个重要特点：

1. 完全无人值守：任务启动后，不需要开发人员持续参与。
2. 一次性完成任务：目标是从任务描述直接完成代码修改。
3. 端到端交付：最终生成通过 CI 检查、可以交给人工 Review 的 Pull Request。

Stripe 披露了一个很有意思的数据：

每周有超过 1000 个合并到 Stripe 的 PR 完全由 Minions 生成。虽然这些代码仍然需要人工 Review，但代码本身没有人工编写的部分。

为什么要无人值守？ #

传统 AI Coding 通常需要开发人员不断参与：

• 给 AI 描述需求。
• 检查 AI 的代码。
• 告诉 AI 哪些地方不正确。
• 让 AI 修改。
• 再次检查。

这意味着开发人员的注意力仍然是一个重要瓶颈。

Minions 希望解决这个问题。

开发人员可以同时启动多个 Agent，让它们并行完成不同的任务。

例如，在 On-call（值班）期间，可能同时出现多个小问题。工程师可以启动多个 Minions 分别处理，而不需要自己逐个修改代码。

这里的核心思想是：

让开发人员从逐个执行任务，转变为并行管理多个 AI Agent。

二、为什么 Stripe 要自己开发？ #

Stripe 为什么不直接使用 Cursor 或 Claude Code？

因为从零开始开发一个原型，与在 Stripe 这样的大型成熟代码库中开发，是两件完全不同的事情。

Stripe 的代码库具有几个特点：

1. 代码规模非常庞大

代码分布在少数几个大型仓库中，总代码量达到数亿行。

2. 技术栈比较特殊

Stripe 的后端大量使用 Ruby，但并不是 Rails，而是结合 Sorbet 进行类型检查。

此外，内部还有大量自研库和基础设施。

这些内部库对普通 LLM 来说并不熟悉。

3. 业务风险非常高

Stripe 的生产代码每年处理超过一万亿美元的支付交易量。

代码不仅需要满足普通软件工程要求，还必须遵守：

• 金融机构的各种依赖和协议。
• 监管要求。
• 合规要求。
• 生产系统的稳定性要求。

因此，AI 即使能够从零开始写出一个完整的软件，也不意味着它能安全地修改 Stripe 的生产代码。

4. AI 缺少大型项目的工程认知

人类开发者在修改大型代码库之前，通常需要建立一套完整的心智模型（Mental Model）。

例如：

• 哪些模块负责什么？
• 哪些接口可以调用？
• 修改某个模块会影响哪些地方？
• 哪些内部工具必须使用？
• 项目有哪些特殊约束？

AI 也需要这些信息。

但它受到 Context Window（上下文窗口）的限制，不可能一次性了解整个代码库。

因此，Stripe 选择自己构建 Minion Harness，并将其与已有的开发基础设施深度集成。

这里有一个非常重要的观点：

Stripe 没有重新发明所有开发工具，而是让 AI 使用与人类开发者相同的工程基础设施。

包括：

• 源代码管理。
• 开发环境。
• 代码生成。
• CI。
• 内部开发工具。

作者认为，既然这些工具能够帮助人类工程师高效开发，那么它们同样能够帮助 LLM。

三、Minions 是如何使用的？ #

Stripe 为 Minions 提供了多个入口：

• CLI。
• Web UI。
• Slack。
• 公司内部的其他业务系统。

其中，工程师最常用的是 Slack。

3.1 从 Slack 启动 Agent #

工程师可以在讨论某个开发任务的 Slack 消息中，直接调用 Minions。

Minion 不仅能获取当前消息，还能读取整个讨论线程以及其中包含的链接。

这意味着它能够获取：

• 原始需求。
• 讨论过程。
• 相关技术背景。
• 其他参考资料。

而不是只拿到一条孤立的 Prompt。

3.2 从其他内部系统启动 #

Minions 也集成在 Stripe 的其他内部系统中。

例如：

CI 系统检测到不稳定测试（Flaky Tests）后，可以自动创建一个任务。

工程师点击任务中的按钮，就能启动 Minion 修复这个问题。

这里有一个值得注意的设计：

Agent 不一定需要人类主动提出需求，也可以由工程系统中的事件触发。

3.3 Agent 执行过程可视化 #

在 Minion 执行任务期间，或者任务完成之后，工程师都可以通过 Web UI 查看：

• Agent 做了哪些决策。
• Agent 执行了哪些操作。
• 任务目前处于什么状态。

这有助于工程师了解 AI 的执行过程，而不是只看到最后生成的代码。

3.4 最终交付 PR #

Minion 完成任务后，会自动：

1. 创建 Git 分支。
2. 提交代码。
3. 推送代码到 CI。
4. 创建符合 Stripe PR 模板的 Pull Request。

接下来分两种情况：

• 如果代码质量符合要求，工程师发起人工 Review。
• 如果代码存在问题，工程师可以继续给 Minion 提供指令，让它在原分支上继续修改。

即使 Minion 没有完全完成任务，它生成的代码也可能成为人工开发的良好起点。

四、Minions 的内部实现原理 #

这是整篇文章中最值得关注的部分，也是 Harness Engineering 的核心实践。

作者介绍了 Minion 从启动到完成任务的大致执行流程。

4.1 独立的开发环境：Devbox #

每次 Minion 执行任务，都会从一个隔离的开发环境开始。

Stripe 称之为 Devbox。

它与 Stripe 人类工程师使用的开发机器类型相同。

Devbox 有几个特点：

预热环境（Pre-warmed）

环境提前准备好，启动一个 Devbox 只需要大约 10 秒。

里面已经预装：

• Stripe 代码。
• 开发所需的服务。
• 必要的工具和依赖。

因此 Agent 不需要每次启动时重新安装依赖、配置环境。

环境隔离

Devbox 与生产资源和互联网隔离。

这样做有两个好处：

1. Agent 不会直接影响生产环境。
2. 在这个隔离环境中，可以不需要人工权限确认就执行任务。

支持并行开发

每个 Minion 都可以在独立的 Devbox 中工作。

因此多个任务可以同时执行，而不需要承担传统 Git Worktree 方案在 Stripe 这种规模下的管理开销。

4.2 Agent 执行引擎：Goose #

Minions 的核心 Agent 执行循环基于 Block 开源的 Coding Agent——Goose。

Stripe 很早就 Fork 了 Goose，并对其进行了深度定制。

这里最值得注意的是：

Stripe 没有让 LLM 自由地执行所有开发步骤，而是将 Agent 的执行循环与确定性的程序逻辑交替组合。

例如：

• Git 操作由程序负责。
• Lint 由程序负责。
• 测试执行由程序负责。
• 代码修改和问题分析由 Agent 负责。

为什么这样设计？

因为 LLM 擅长的是理解、推理和处理不确定性问题，但不适合承担所有确定性的工程操作。

例如，不能仅仅告诉 AI：

「记得运行 Lint。」

而应该由 Harness 确保 Lint 一定会执行。

核心思想：创造性工作交给 Agent，确定性工作交给程序。

4.3 Agent Rules：规则文件 #

Minions 会读取与 Cursor、Claude Code 类似的 Agent 规则文件。

但 Stripe 有一个特殊设计：

它们几乎不会设置大量全局生效的规则。

而是根据代码所在的子目录，有条件地加载对应规则。

例如：

假设项目有以下结构：

project/
├── frontend/
│   └── AGENTS.md
├── backend/
│   └── AGENTS.md
├── geometry/
│   └── AGENTS.md
└── README.md

如果 Agent 修改 geometry 目录中的代码，就应该读取 Geometry 对应的开发规则，而不需要把前端、后端所有规则都加载进来。

这样可以减少无关上下文，避免全局规则过于庞大。

4.4 MCP：获取外部上下文和工具 #

Minions 接入了 MCP（Model Context Protocol）。

通过 MCP，它能够获取 Stripe 内部的各种信息。

例如：

Stripe 还专门构建了一个中央 MCP Server，叫做 Toolshed。

这个系统提供了超过 400 个 MCP 工具，覆盖 Stripe 内部系统以及使用的 SaaS 平台。

Minions 和其他 Agent 可以根据实际需要，访问其中经过筛选和配置的工具集合。

还有一个很有意思的细节：

Stripe 并不是等 Agent 启动后才让它自己寻找所有上下文。

在 Minion 启动之前，系统会根据任务中可能出现的链接，确定性地调用相关 MCP 工具，提前获取需要的信息。

这个过程可以理解为 Context Preloading（上下文预加载）。

这样可以让 Agent 一开始就获得更完整的任务背景。

4.5 自动测试和反馈机制 #

这是整篇文章最值得借鉴的设计之一。

Minions 的目标是一次性完成任务，但实际开发中不可能保证每次都成功。

因此，Stripe 为 Agent 建立了多层自动化测试反馈机制。

第一层：本地自动检查

小于 5 秒

每次 Git Push 时，自动根据启发式规则选择并执行相关 Lint。

第二层：CI 自动测试

超过 300 万个测试

推送代码后，CI 从 Stripe 的庞大测试集合中选择相关测试执行。

第三层：自动修复

如果测试失败，先检查是否存在自动修复方案。

• 有自动修复：自动应用修复。
• 没有自动修复：将错误反馈给 Minion，让它分析并修改代码。

第四层：有限次数的重试

最多两轮 CI

第一次 CI 失败后，Agent 可以修改代码并再次推送。

第二次 CI 仍然失败，就结束自动执行流程，交给人工处理。

这里有两个非常值得学习的工程思想。

思想一：Shift Feedback Left（尽早反馈）

如果某个问题能够在本地发现，就不要等到 CI 才发现。

例如：

• 代码格式错误。
• Lint 错误。
• 简单的静态检查。
• 可以快速运行的单元测试。

这些检查应该尽量放在本地执行。

这样可以减少反馈时间和计算资源消耗。

思想二：不要无限重试

为什么最多只执行两轮 CI？

因为 CI 会消耗：

• Token。
• 计算资源。
• 时间。

而且随着重试次数增加，LLM 继续修复问题的边际收益会逐渐下降。

Stripe 认为比较合理的策略是：

1. 首先尽可能完成所有本地检查。
2. 第一次 CI 验证。
3. 如果失败，Agent 修复后进行第二次 CI。
4. 第二次仍然失败，就交给人工处理。

这是速度、成本和正确性之间的平衡。

五、Stripe 对未来的判断 #

Minions 已经改变了 Stripe 内部的开发方式。

虽然整个行业还在探索 Agentic Coding 的未来，但 Stripe 认为：

无人值守的 Coding Agent 将会成为 AI Agent 最重要的应用方向之一。

六、结合我的 CAD 项目，我认为最值得学习的 5 个设计 #

我觉得这篇文章真正有价值的地方，不是 Minions 使用了什么模型，而是它如何把 AI Coding 变成一个完整的软件工程流程。

结合我目前的 CAD 项目，我把值得借鉴的地方归纳一下。

尤其是最后一点。

假设我让 Codex 实现一个 CAD 图层功能。

传统方式可能只验证：

• TypeScript 是否编译通过。
• ESLint 是否通过。
• 单元测试是否通过。

但这些并不能证明 CAD 图层功能正确。

真正应该验证的是：

1. 能否创建、删除、重命名图层？
2. 拖动图层后，实体显示顺序是否正确？
3. 同一个图层中的实体置顶，是否不会跨越图层？
4. Undo/Redo 是否正确恢复图层及实体顺序？
5. 保存并重新打开文档后，状态是否一致？

这些才是业务级测试。

如果 Harness 能够自动启动 CAD、执行操作、检查模型状态、验证渲染结果，并把失败信息反馈给 Agent，那么 AI 才真正具备了独立完成 CAD 业务开发的能力。

我认为可以把这篇文章总结成一句话：

不要只让 AI 参与代码编写，而要让 AI 成为一个完整的软件工程执行者。人类负责定义目标和验收标准，Harness 负责提供工程环境、执行约束和验证机制，Agent 负责完成具体任务。