§06让循环在你睡觉时跑：Stripe的Minions，和调度怎

么选

Stripe's Minions, and Where a Loop Runs

一个公开、能追到一手出处的大规模案例，加上几种调度方式各自靠什么、能不能在你关机后继续跑。

Stripe的Minions：每周1,300多个PR

把loop推到企业规模，最值得看的是Stripe的Minions。

数字先放这：每周合并1,300多个PR，全部由Minions产出，人审过，但没有一行是人手写的。这是Stripe工程师Alistair Gray在Stripe官方博客上两篇长文里写的，第一篇2026年2月9日，第二篇2月19日；第一篇时还是1,000多个。这是2月的数，之后的我没查到。

触发方式很轻。一次典型的运行从一条Slack消息开始，到一个CI通过、等人审的PR结束，中间不用人插手。除了Slack，命令行、网页界面也能发起，Stripe内部的文档平台、feature flag平台、工单系统也都接了它。比如CI发现一个不稳定的测试，会自动开一张工单，工单上就有一个按钮，点一下让Minion去修。

LLM醒来之前，系统先用确定性的代码把上下文备齐：消息里有看起来相关的链接，就先把对应的MCP工具跑一遍，把内部文档、工单详情、构建状态、Sourcegraph代码搜索的结果拉进来。Stripe为此建了一个内部的中心MCP服务器，叫Toolshed，第一篇写的是400多个工具，第二篇已经是将近500个。

让LLM自己去找上下文，它可能搜错、可能漏、可能为了凑答案现编。Stripe把找资料这种能写死规则的活，从LLM手里拿走，交给确定性代码去办。

它的agent内核是Block开源的goose的一个fork，2024年底分出来，之后按Minions的需要一路改。

第二篇里有个概念叫blueprint（蓝图）。它把工作流写成代码，像一台状态机：有些节点是确定性的，只跑代码不调模型，比如「跑配置好的linter」「推送改动」；有些节点交给agent自由发挥，比如「实现任务」「修CI失败」。agent写完代码，linter一定会跑，它跳不过去。CI最多跑两轮：第一次推送没过，让Minion修一次再推，还不过就交还给人。

沙箱用的是devbox，就是Stripe工程师自己写代码用的那种AWS EC2机器。一池子devbox提前预热好，10秒内能起一台；它们跟生产环境和互联网隔离，所以Minion在里面跑不需要人逐条批权限。Stripe用的是运维那句老话：devbox是「cattle, not pets」，是一群随时能换的牛，不是养着的宠物。坏了不修，直接起一台新的。

§04讲并行靠git worktree，Stripe在第一篇里明说，worktree这种做法「wouldn't scale at Stripe」，他们靠的是一任务一台devbox。worktree是目录级的隔离，devbox是机器级的隔离。个人和小团队用worktree够了，规模大到Stripe这样，隔离单位就从目录变成了机器。

最后一行，这1,300个PR仍然由工程师审，时间从写挪到了审。

关机以后靠什么跑

本地的/loop也好，桌面的定时任务也好，它们都要你的机器开着。机器一关，loop就停了。要关机也跑，得靠别的东西：Cloud Routines，或者GitHub Actions的schedule触发。

要频繁、要看本地文件，用本地/loop，代价是机器得开着。要关机也跑、不依赖本地状态，上云，代价是最小间隔一小时、每次都是干净的clone。

举两个场景。你想让一个loop每分钟盯一下本地正在跑的开发服务器，那只能是本地/loop，云端看不到你机器里那个进程，间隔也下不到一分钟。反过来，你想让它每天凌晨三点扫一遍仓库的open issue、该提PR提PR，这种活不该绑在你的笔记本上，笔记本会合盖、会断电、会被你带出门。这时候用GitHub Actions的schedule触发或者Cloud Routines，它们跑在一台一直醒着的机器上。

本地/loop适合你在场时让它替你多跑几轮，云端调度才管你不在场的时候。

Cloud Routines现在仍标着research preview（研究预览），要用claude.ai的订阅账号登录才有/schedule ；

触发器除了定时，还能是一个API调用或者GitHub事件；每个账号定时运行每小时最多100次。

排程本身没什么神秘。按文档，/loop给了间隔就换算成标准的cron表达式，五个字段，最小粒度一分钟；循环任务7天后自动过期，最后触发一次然后删掉自己；嫌它烦，设个CLAUDE_CODE_DISABLE_CRON=1 就全关了。它还有一点抖动：循环任务可能比整点晚到，最多晚间隔的一半、不超过30分钟。

不过我10月实际跑的时候，看到的跟文档不一样。我在Claude Code 2.1.287里输入/loop 1m 加一句检查待办的prompt，它说循环已启动，每1分钟触发一次，30分钟后到期。我问它用什么机制实现的，它先调了一次CronList，结果是No scheduled jobs，然后告诉我：这个循环是用Monitor工具起的一个后台shell脚本，每60秒往外打一行带prompt的标记把它唤醒，设了30分钟超时。

它自己说的实现方式。文档里Monitor只出现在「不给间隔、让Claude自己定节奏」那种/loop里，我给了1m，它还是用了Monitor。

文档写的是7天过期的cron任务，我这一次（2.1.287，Sonnet 5.5）看到的是30分钟超时的后台脚本，你的机器上会出现哪一种，我没法保证。所以起完一个/loop，问它一句用什么机制跑的、什么时候到期，别默认它会替你跑满7天。

Codex的定时任务叫Scheduled tasks，归在ChatGPT桌面app里，Codex就在这个app里面。每个任务可以选在本地项目里跑，也可以开一个新的worktree跑；结果出现在侧栏的Scheduled里；自定义周期用的是日历标准里的RRULE写法，比如RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0 ，不是cron。Codex CLI和IDE扩展里没有这个管理界面。想关机也跑，有ChatGPT网页和手机端的定时任务（碰不到你电脑上的文件夹），还有按Gmail、Slack、GitHub事件触发的任务，这一种只在网页和手机端、符合条件的套餐里有，不能和定时同时设。另外，Codex Cloud任务也能在你电脑睡着时继续干活，它是另一套功能，不归Scheduled tasks管。这块我只读了文档，没在桌面app里实际建过。

有几个流传很广的数字，你看到时最好谨慎对待。比如「Anthropic约九成Claude Code由它自己写」「Nubank迁移百万行ETL提效12倍」这类，多是二手综述，我没追到一手出处。