本文是 Stripe 内部 AI 编码智能体“Minions”系列的第二部分，深入探讨了支撑这些智能体高效运行的底层架构与技术细节。Minions 是一种无需人工干预、端到端的单次编码智能体，每周在 Stripe 产生的合并 PR 超过 1300 个。

其核心优势在于充分复用了 Stripe 为人类工程师构建的成熟基础设施。首先，Minions 运行在名为 devbox 的云开发环境中，这种环境具备并行化、可预测和隔离的特性，确保智能体在 10 秒内即可获得干净且配置齐全的工作空间。其次，Stripe 引入了 “蓝图”（Blueprints） 概念，这是一种结合了确定性代码节点和灵活性智能体节点的混合工作流，既保证了代码规范（如 Lint 检查）的强制执行，又保留了 LLM 处理复杂任务的能力。

在上下文获取方面，Minions 利用 规则文件（Rule files） 自动学习代码库规范，并通过集中的 Toolshed（基于 MCP 协议） 动态调用内部工具。最后，Minions 遵循“反馈左移”原则，在推送到 CI 之前进行本地自动化迭代，并限制 CI 循环次数以平衡成本与效率。Stripe 的经验表明，多年来在提升人类开发者效率上的投入，正成为 AI 智能体发展的巨大红利。

---

Devbox：为智能体提供“即插即用”的环境

Stripe 的 Minions 并非运行在本地笔记本电脑上，而是部署在名为 devbox 的云端开发环境中。devbox 是基于 AWS EC2 的实例，包含了完整的源代码和开发服务。对于大规模的自动化编码而言，环境的并行化、可预测性和隔离性至关重要。如果多个智能体在同一个环境中互相干扰，或者因为权限问题破坏敏感机器，将极大降低效率。

Stripe 预先配置并维护了一个 devbox 池，确保任何请求都能在 10 秒内获得一个“热就绪”的环境。这个环境已经完成了巨大的 Git 仓库克隆、Bazel 缓存预热以及类型检查服务的启动。这种“基础设施即代码”的模式原本是为人类工程师设计的，旨在让他们能像处理“牛群”而非“宠物”一样快速更换开发环境。事实证明，对人类友好的环境（隔离、标准、快速）同样是 AI 智能体的理想温床，这让 Minions 能够拥有完整的 Shell 权限而不会造成安全隐患。

蓝图（Blueprints）：确定性与灵活性的平衡

在编排 LLM 任务时，Stripe 采用了名为 “蓝图” 的原始模型。传统的 LLM 系统通常分为“固定工作流”和“自主智能体”两种。工作流虽然稳定但死板，而智能体虽然灵活但容易失控。蓝图则将两者结合：它是一个由代码定义的有向图，其中的节点既可以是运行确定性代码的“确定性节点”（如运行 Lint、推送代码），也可以是调用 LLM 的“智能体节点”（如实现功能、修复 CI 错误）。

通过蓝图，Stripe 能够强制执行某些关键步骤。例如，无论智能体如何发挥，蓝图都会确保在任务结束前运行代码检查工具。这种“将 LLM 放入受控盒子”的方法显著提高了系统的可靠性，减少了 Token 浪费，并降低了出错率。此外，不同团队还可以根据特定需求（如复杂的代码迁移）定制专属蓝图，将人类的经验以确定性逻辑的形式固化在智能体的工作流中。

上下文与工具集成：规则文件与 MCP

为了让 Minions 在庞大的代码库中不迷失方向，Stripe 采用了 规则文件（Rule files） 和 MCP（模型上下文协议）。由于代码库过于庞大，无法将所有规则塞进 Context Window，Minions 会根据当前操作的文件路径动态加载局部的规则文件（兼容 Cursor 的格式）。这使得智能体能够自动学习特定目录下的编码规范。

在动态信息获取方面，Stripe 构建了一个名为 Toolshed 的集中式内部 MCP 服务器。Toolshed 包含了近 500 个工具，涵盖了内部文档检索、工单详情查看、构建状态查询等功能。通过 MCP 协议，Stripe 的所有 AI 系统（包括 Slack 机器人和 Minions）都能共享这些能力。为了安全起见，Minions 只能访问 Toolshed 中经过筛选的子集，且由于 devbox 运行在隔离的 QA 环境中，智能体无法接触到真实的生产数据或进行破坏性的网络操作。

自动化迭代：反馈左移与 CI 循环

Minions 的目标是“单次（One-shot）”完成任务，但在实际操作中，自动化的反馈循环必不可少。Stripe 遵循 “反馈左移” 原则，即尽可能在开发早期（推送到 CI 之前）发现问题。Minions 会在本地 devbox 上运行预推钩子（Pre-push hooks）和 Lint 检查，利用后台守护进程在秒级内完成代码格式化和初步校验。

当代码推送到远程分支后，Minions 会进入 CI 迭代阶段。如果 CI 失败且存在自动修复方案，系统会自动应用；如果没有自动修复方案，失败信息会被传回蓝图中的智能体节点，给予 Minions 第二次尝试修复的机会。Stripe 将这种 CI 循环限制在 1-2 次，以在修复成功率和计算成本（Token 及 CI 资源）之间取得平衡。这种严谨的反馈机制确保了最终提交给人类审查的代码具有极高的质量。

---

问答

问：为什么 Stripe 选择在云端 devbox 而不是本地运行 Minions？ 答：云端 devbox 提供了并行化、可预测性和隔离性。它能在 10 秒内提供干净的环境，避免智能体之间互相干扰，并能通过环境隔离确保智能体无法访问敏感的生产数据或个人凭据。

问：什么是“蓝图（Blueprints）”，它解决了什么问题？ 答：蓝图是一种混合工作流，结合了确定性的代码执行和灵活的 LLM 智能体节点。它解决了纯智能体不可控的问题，通过在流程中嵌入强制性的确定性步骤（如 Lint 检查），提高了系统的整体可靠性和资源利用率。

问：Minions 如何获取 Stripe 庞大代码库的上下文？ 答：主要通过两种方式：一是动态加载与文件路径相关的规则文件（兼容 Cursor 格式）；二是通过 Toolshed（基于 MCP 协议的工具集）动态调用内部 API 获取文档、工单和构建状态。

问：Minions 如何处理代码错误和 CI 失败？ 答：Minions 遵循“反馈左移”原则，先在本地运行 Lint 和格式化工具。推送到 CI 后，如果失败，系统会尝试自动修复或将错误发回给智能体进行第二次尝试。为了平衡成本，这种 CI 迭代通常限制在 1-2 次。

问：Stripe 开发 Minions 的核心启示是什么？ 答：核心启示是：多年来在提升“人类”开发者效率上的投入（如快速的环境启动、完善的测试套件、标准化的规则文件）在 AI 时代会产生巨大红利，因为对人类友好的基础设施通常也对 AI 智能体友好。