为什么 Stripe 运行数百个 Agent 后彻底放弃了 localhost——通宵跑了一遍,完全理解了
在一场 12 小时的黑客马拉松里只用 Agent 构建产品后,我切身体会到了 Stripe Minions 和 Ramp Inspect 为何选择云端隔离环境。
快速摘要
在一场 12 小时的黑客马拉松里只用 Agent 构建产品后,我切身体会到了 Stripe Minions 和 Ramp Inspect 为何选择云端隔离环境。
昨晚的黑客马拉松只有一条规则:晚上 8 点完成规格设计和测试脚手架的搭建,之后双手离开键盘,直到早上 8 点。整整 12 小时,只让 Agent 来完成产品。
这次实验让我彻底明白了,为什么 Stripe 在发布 Minions 平台时,以及 Ramp 在分享自研背景 Agent Inspect 的经验时,都宣称”localhost 已死”。这个结论,我在 12 小时内就亲身验证了。
在笔记本上并行跑多个 Agent,冲突从一开始就存在
多个 Agent 跑在同一台机器上,状态必然会乱。密钥冲突、端口占用,机器一旦进入休眠,整个 12 小时的循环就全军覆没。
Stripe 和 Ramp 公开各自的 Agent 架构时,有一个共同点:都为每个 Agent 分配了独立的 VM 和开发容器。
Stripe 的 Minions 运行在称为”devbox”的隔离环境中。机器规格与工程师日常使用的一致,但与生产资源和公网完全隔离。启动时间不到 10 秒,且无需 git worktree 的额外开销即可支持并行任务执行。
Ramp 的 Inspect 构建在 Modal Sandbox 之上。每个会话都拥有独立的全栈开发环境,包含 Postgres、Redis、Temporal 和 RabbitMQ。会话之间零竞争,加上文件系统快照,启动几乎是即时的。
编码 Agent 需要占用我的机器和注意力,但背景 Agent 两者都不需要。实验过程中我亲眼看到,机器休眠一次就让整个循环停摆了。在云端 VM 上,这种情况根本不会发生。
顺序执行只能产出简单功能
这是本次黑客马拉松最痛的教训。顺序跑 Agent,简单的 CRUD 没问题,但一旦出现依赖关系就麻烦了——后面的 Agent 反复覆写或破坏前面已完成的模块。
这里需要区分两个概念:Agent Fleet 和 Agent Swarm。
Agent Fleet 是将同一变更同时推送到多个代码库的模式。Stripe 能做到每周合并 1,000 个以上 PR,靠的就是这种结构——把相同的迁移脚本、相同的 lint 修复一次性推送到数百个服务。
Agent Swarm 是将不同的部分分配给不同 Agent,最终汇聚成一个整体——前端、后端、测试各由不同 Agent 负责,以 PR 为单位进行合并。
不采用并行执行后合并 PR 的结构,就无法构建复杂产品。亲身实验后,并行 + 合并审查的组合与顺序执行相比,完成度的差距显而易见。
限速问题和 Agent 间通信,要靠基础设施解决,不是靠 Prompt
12 小时的循环里,撞上 rate limit 是不可避免的。此外还需要让一个 Agent 审查另一个 Agent 提交的 commit,并自动重新判断规格中模糊的地方。
有句话说得很准:“在系统 Prompt 里写’别删文件’是在祈求,不是在控制。”
Stripe 在执行层解决了这个问题。Minions 从根源上屏蔽了对生产资源和公网的访问,无需权限检查就能安全执行。他们将 400 多个 MCP 工具托管在名为”Toolshed”的内部服务器上,并为每个 Agent 策划可访问的工具集合。
Ramp 则通过 GitHub OAuth 确保 PR 必须以真实用户账户创建,而非 App ID。这从结构上防止了代码绕过审查直接合并。
在执行层锁定权限范围、保留审计日志、限制故障爆炸半径——没有这些,安全团队不会批准自主 Agent 上线。
个人提速不等于组织提速
我把这种现象叫做”假山顶”。引入编码 Agent 后,PR 数量激增,但交付周期纹丝不动——review 堆积,CI 挂掉,merge 冲突越来越多。
黑客马拉松里,Agent 快速生成代码从来不是问题。时间全都消耗在合并和验证这些产出的瓶颈上。
Stripe 用自动化打通了这个瓶颈。Minions 采用混合编排方式,将 Agent 循环与确定性代码操作交替进行,在保留 Agent 创造力的同时,确保 lint、测试、git 操作始终能够完成。CI 测试也被限制在最多重试两次,防止陷入无限循环。
Ramp 将”已合并 PR 数”作为核心成功指标。Inspect 生成的 PR 有超过 50% 实际被合并,而 Inspect 自身 80% 以上的代码也是由 Inspect 编写的。
只有背景 Agent 能在人之前完成 PR review、CI 失败分析和 merge 冲突解决,组织速度才能真正跟上来。本质是从”in the loop(亲自操作)“转向”on the loop(只审结果)“。
真正的竞争在于如何合并,而不是如何生成
让 Agent 快速生成代码,这个问题已经解决了。Stripe 每周 1,000 个以上的 PR、Ramp 超过一半的 PR,都由 Agent 完成。
真正的挑战在于设计一套能安全合并 Agent 产出的系统:隔离的执行环境、并行后合并的结构、基础设施级别的治理,以及验证自动化。缺少这四样,Agent 不过是一个跑得快的玩具。
订阅通讯
获取关于我最新项目、文章以及 AI 和 Web 开发实验的更新。