Stripe 在工程自动化领域迈出了重要一步，推出了一种名为 Minions 的无人值守一次性编程代理系统。该系统能够从需求描述出发，经过单次自主运行直接生成符合规范的 Pull Request，整个过程几乎不需要人工介入。Stripe 官方数据显示，Minions 目前每周能够生成并合并超过一千个 Pull Request，极大地释放了工程师的生产力。本文将从架构设计、蓝图工作流、确定性门控机制三个维度，深入解析这一一次性端到端编程代理的工程实现细节。
核心架构概览
Stripe Minions 的架构设计遵循一个核心原则：将「创造性」的代码生成任务交给大语言模型处理，而将「可靠性」的验证与流程控制交给确定性代码执行。这种混合架构既保留了 AI 的灵活性和适应性，又确保了工程实践中的可预测性和安全性。
系统的高层架构可以划分为六个关键层次。入口层支持多种触发方式，包括 Slack 消息、命令行工具、Web 界面以及内部工具系统，工程师可以在任何工作环境中发起任务请求。编排层负责选择合适的蓝图并驱动整个运行流程。工具层通过 Model Context Protocol（MCP）暴露超过四百个内部工具，涵盖代码搜索、文档查询、CI 状态查询、工单管理等功能。执行环境为每次运行分配隔离的临时开发虚拟机，该环境与 Stripe 工程师日常使用的开发环境完全一致，但禁止访问互联网和生产系统。测试验证层在代码生成后执行本地快速检查和 CI 测试。PR 创建层负责生成符合规范的 Pull Request 并提交人工审核。
值得注意的是，Minions 的核心代理引擎基于 Block 的 Goose 框架进行深度定制，Stripe 在此基础上叠加了特定的业务逻辑和工具集成。这种设计使得系统能够在模型无关的前提下，充分利用不同大语言模型的能力，同时通过工作流程和工具约束确保输出质量。
蓝图工作流：把流程写成代码
Minions 的最大创新在于引入了「蓝图」（Blueprint）这一抽象概念。蓝图本质上是用代码定义的工作流描述，它明确指定了某一类任务从接收到完成的完整执行步骤、可用工具以及安全 guardrail。与传统的提示工程不同，蓝图将行为规范从提示词中分离出来，使得工作流程本身变得可审查、可版本控制、可复用。
每一种任务类型都对应一个专属蓝图。例如处理 flaky test 修复的蓝图与处理 API 重构的蓝图遵循完全不同的执行路径。蓝图通常包含以下关键要素：上下文获取策略（如何从代码库、文档和工单系统中提取相关信息）、变更定位逻辑（确定需要修改的代码目录或服务范围）、工具调用序列（明确在哪个阶段使用哪些工具）、以及门控检查点（规定哪些验证必须通过才能进入下一阶段）。
这种设计带来了显著的优势。首先，行为变得完全可预测和可复现，同一类任务无论运行多少次都会遵循相同的验证流程。其次，工程师可以像审查代码一样审查蓝图本身，发现问题后通过代码审查流程进行修复。第三，蓝图为新手工程师提供了清晰的任务执行模板，降低了自主解决问题的门槛。
确定性门控与混合执行模型
Minions 的核心运行逻辑建立在「创造性区域」与「确定性区域」的清晰划分之上。创造性区域由大语言模型主导，负责理解需求、规划代码变更、解释错误信息等需要灵活判断的任务。确定性区域则由传统代码控制，包括环境初始化、代码格式化与 lint 检查、本地测试执行、CI 流水线触发、提交创建以及 PR 生成等可预测的流程步骤。
在一个典型的执行周期中，编排器首先通过工具获取完整的上下文信息，包括 Slack 对话内容、关联的工单、代码搜索结果以及相关的设计文档。随后，大语言模型在蓝图约束下制定修改计划，明确需要编辑的文件和预期的测试结果。代码编辑完成后，系统立即执行快速 lint 检查，如果检查失败则将诊断信息反馈给模型进行修复并重新执行，整个过程仍在蓝图管控之下。通过检查后，系统运行有针对性的本地测试，然后推送代码并等待 CI 结果。值得注意的是，Blueprint 强制规定了最大的 CI 重试次数上限，通常为两次，这一限制有效地控制了 token 消耗和计算成本。
这种混合模型的关键在于：模型可以自由发挥创造力，但每一步都在安全护栏的限制之内。人为定义的门控确保了即使模型产生意外输出，也不会导致不安全的代码进入代码库或生产环境。
上下文管理与规则文件
为了在有限的上下文窗口内提供最相关的信息，Stripe 设计了一套精细的上下文管理策略。核心思想是「将反馈左移」，即在实际执行之前尽可能多地预取相关上下文。编排器会根据任务描述智能选择需要加载的代码片段、设计文档、工单数据以及 CI 历史记录。
Stripe 放弃了传统的全局规则文档，转而采用基于子目录或领域的规则文件机制。每个代码子目录都可以包含专属的规则文件，向代理传达该领域的编码约定、常见模式以及需要避免的陷阱。这种设计的优势在于模型只会看到与当前任务直接相关的规则，避免了信息过载问题。例如，处理支付模块的代理会加载支付相关的规则，而不会受到账单模块规则的干扰。
安全与规模化实践
在安全层面，Minions 采用了多层次的防护措施。所有代理运行在隔离的临时开发环境中，无法访问互联网和生产系统。凭证权限被严格限制，代理只能通过 MCP 暴露的内部 API 进行操作。每次运行都会生成独立的虚拟机实例，运行结束后立即销毁，确保不同任务之间完全没有状态泄露。
从规模化角度来看，Minions 已经深度集成到 Stripe 的现有工程工作流中。工程师可以在 Slack 中并行触发多个 Minion 处理不同的 routine 任务，如修复 flaky test、更新依赖版本、修改配置文件等，而无需改变原有的代码审查和 CI 流程。这种「即插即用」的集成方式大幅降低了采用成本，使得 AI 代理能够与人类工程师的日常工作无缝配合。
Stripe Minions 代表了一种务实的一次性 AI 编程范式：通过将灵活的大语言模型置于确定性工作流的严格约束之下，实现了可预测、可审计、可规模化的工程自动化。这一架构思路对于希望构建类似系统的团队具有重要的参考价值。
资料来源：本文核心信息来源于 Stripe 官方技术博客及相关技术报道，参考链接包括 Stripe Dot Dev 官方博客及 Hacker News 社区讨论。