使用一次性编码代理将工单转化为已合并的拉取请求
作为本博客迷你系列第一部分的回顾，minions 是 Stripe 内部自研的无人值守智能体编码流程。任务：Stripe 工程师部署了名为“minions”的无人值守编码智能体流程，用于生成拉取请求。该系统运行在隔离的 AWS EC2“devbox”上，这些环境可在 10 秒内预置，确保了并行性和安全性。智能体使用 Block 的 goose 的定制分支，由“blueprints”（蓝图）编排，混合了确定性代码节点（如 linting、push）和智能体节点（如实现、修复 CI）。上下文通过作用域规则文件和名为 Toolshed 的集中式 MCP 服务器收集。人类审查最终输出，但智能体生成的 PR 中不包含任何人工编写的代码。；工具：custom-built or unnamed agent。人工角色：原始帖子没有说明人如何参与。；局限：此工作流依赖于 Stripe 特定的内部基础设施，包括 devbox、Toolshed 和定制的 goose 分支，这使得在没有大量工程投入的情况下难以在外部复制。智能体在 QA 环境中运行，无法访问生产数据或任意网络出口。系统限制 CI 迭代为一到两轮，以平衡速度和成本。合并前必须经过人工审查。来源可靠性高，因为是第一方工程博客，但缺乏量化的性能数据。。
工具
custom-built or unnamed agent
Agent Work Atlas 发布日期:
概述
作为本博客迷你系列第一部分的回顾，minions 是 Stripe 内部自研的无人值守智能体编码流程。
工作流程
Stripe 工程师部署了名为“minions”的无人值守编码智能体流程，用于生成拉取请求。该系统运行在隔离的 AWS EC2“devbox”上，这些环境可在 10 秒内预置，确保了并行性和安全性。智能体使用 Block 的 goose 的定制分支，由“blueprints”（蓝图）编排，混合了确定性代码节点（如 linting、push）和智能体节点（如实现、修复 CI）。上下文通过作用域规则文件和名为 Toolshed 的集中式 MCP 服务器收集。人类审查最终输出，但智能体生成的 PR 中不包含任何人工编写的代码。
原文报告的结果
来源报告称，每周有超过 1,300 个 Stripe 拉取请求被合并，这些请求完全由 minions 生成并经人工审查。这一数字较系列第一部分中的 1,000 个有所增加。文本未提供关于错误率、节省时间或成本降低的具体指标，也未详述失败情况。结果被描述为改变了 Stripe 软件工程领域的格局，利用了现有的开发者生产力基础设施。
人工角色
原始帖子没有说明人如何参与。
局限
此工作流依赖于 Stripe 特定的内部基础设施，包括 devbox、Toolshed 和定制的 goose 分支，这使得在没有大量工程投入的情况下难以在外部复制。智能体在 QA 环境中运行，无法访问生产数据或任意网络出口。系统限制 CI 迭代为一到两轮，以平衡速度和成本。合并前必须经过人工审查。来源可靠性高，因为是第一方工程博客，但缺乏量化的性能数据。
试一试
我想为我的团队实施 Stripe“minion”编码智能体工作流的简化版本。我们使用 [replaceable: 例如 GitHub Actions, Docker 容器] 进行 CI/CD，使用 [replaceable: 例如 Cursor, Claude Code] 进行本地开发。 1. **设置隔离环境**：创建一个脚本，启动一个包含我们代码库克隆的、全新的、隔离的容器或虚拟机。确保其无法访问生产凭证。 2. **定义蓝图**：编写一个配置，定义包含确定性步骤（克隆、安装依赖、linting）和智能体步骤（实现功能、修复测试）的工作流。 3. **集成上下文**：设置一个规则文件（如 AGENTS.md），为智能体提供项目特定的指南和库使用模式。 4. **智能体执行**：配置智能体在隔离环境中自主运行，进行代码更改并运行本地测试。 5. **CI 反馈循环**：实施一个步骤，智能体将更改推送到分支，触发 CI，如果测试失败，智能体接收错误日志并尝试一次修复。 6. **人工审查**：在第二次 CI 运行后停止流程，并生成一个供人工审查的拉取请求。 在真实任务上运行此流程之前，请在 [replaceable: 示例工单或错误报告] 上进行试运行。向我展示生成的 diff 和 CI 结果。未经我明确确认，不要合并或部署任何内容。如果智能体未能生成有效的 PR，请报告错误日志并建议调整蓝图或上下文规则。
来源报告未经独立核验。发布日期为本站案例发布日期，并非原始文章日期。