⭐ 设为星标 · 第一时间收到推送
Claude Loops 想解决的不是“怎么写出一个完美 prompt”，而是把那些反复发生的工作放上时间表，让 agent 到点自己出现、自己跑、自己交结果。
loop 只是按计划运行的 Claude
单次 prompt 只运行一次，然后就结束了。loop 的区别在于，它会按你设定的节奏反复运行，不需要你每次手动打开 Claude、复制上下文、再发一遍指令。
机制本身很朴素：让 Claude 用 cron 之类的调度方式创建任务，再告诉它重复频率。可以是每分钟、每 30 分钟，也可以是每天晚上一次。
这件事听起来不酷，但正因为足够简单，才容易落地。一个会重复执行的任务，会把 Claude 从“聊天窗口”变成一个按时间表上班的工人。
关键是把频率和任务类型配上。CI 这种变化快的东西，可以几分钟看一次；日报、总结、清理类任务，则适合每天晚上跑一遍，第二天早上直接看结果。
| 任务类型 | 更适合的 loop |
|---|---|
| CI、PR、测试失败 | 高频检查，几分钟一次 |
| 反馈聚类、工作总结 | 低频处理，每 30 分钟或每天一次 |
| 报告、回顾、整理 | 夜间运行，早上交付 |
真正强的是很多 loop 同时跑
一个 loop 有用，但一组 loop 并行运行，才会让工作方式发生变化。
你可以让一个 loop 盯着打开的 PR，顺手 rebase，发现 CI 挂了就修；另一个 loop 维护测试套件，把 flaky test 收拾掉；还有一个 loop 每 30 分钟从反馈流里拉信息，聚类成干净主题。
它们不需要你在旁边等。每个 loop 只拥有一件事，按自己的节奏运行。你去做别的事情，甚至什么都不做，它们也会继续推进。
这就是一个人做出团队产出的原因：不是打字更快，而是把几十个重复动作交给不同的 loop，让它们全天候替你打字。
难的不是命令，而是心智切换。你不再问“下一句 prompt 写什么”，而是问：从现在开始，哪些工作应该自己跑？
任何你做过两次以上的事，任何你总是手动检查的东西，任何凌晨三点坏掉还要等人处理的流程，都是一个正在等你创建的 loop。
合上电脑，工作也要继续
本地 loop 有一个显而易见的问题：电脑一关，它们就停。
解决办法是把同样的思路搬到服务器上。你配置一次任务，让它按计划、webhook 或 API 调用触发。这样你的机器开不开都无所谓，agent 到点醒来，把活干完，等你有空再看结果。
这也是很多高效团队真正安静的部分：agent 在会议间隙、夜里、大家睡觉的时候继续工作。人的注意力不再被“启动任务”耗掉，更多时候只是检查它已经完成了什么。
放在一起看，聊天窗口会慢慢消失。你不是手动运行 Claude，而是在运行一个会自我调度的系统。loop 负责重复工作，routine 负责让它离开本机也能活着，你只需要决定哪些任务值得存在。
先从一个窄任务开始
很多人第一天就想做完整系统：十个 loop、一个 dashboard、再配一堆自动化。通常周末还没到就崩了，因为你根本分不清哪一个 loop 做了什么。
更稳的方式是从一个开始。挑一个最烦、最固定、每天早上都会习惯性检查的任务，把它变成单一 loop。让它跑几天，观察它在哪里越界、哪里漏掉、输出是不是能一眼看懂。
一个好 loop 通常有三点：有清楚的时间表；工作边界窄到不容易误读；输出能在几秒钟内验证。CI watcher、PR rebaser、daily digest 都属于这种类型。
失败的 loop 往往太虚。“改进代码库”不是 loop，只是愿望。“找出超过 50 行的函数，并逐个开 issue”才是 loop。任务越窄，越适合无人值守。
保留人在回路里，但别待在每个回路里
让 agent 通宵跑听起来有点冒险，但真正稳定的设置并不是把所有权限都交出去。每个 loop 都有自己的车道，风险高的动作仍然需要人点头。
PR 看护员可以自动 rebase、修 CI，但合进 main 之前仍然通知你。迁移类 loop 可以批量打开 PR，但第一批通过人工确认后再继续铺开。agent 负责体量，人保留判断。
这也是一套系统能不能长期用下去的分水岭。目标不是完全没有人，而是让人从无聊的 95% 里退出，把注意力留给真正有风险的 5%。
边界要写在 loop 的指令里，并且每次运行都遵守。你不是盯着每个任务，而是盯着规则本身；规则一旦写清楚，后面每次都能复用。
一周之后，变化会翻过来
第一天通常会觉得麻烦。你要写 schedule，要看 loop 跑错，要收紧指令。它看起来甚至比自己做还慢。
但到一周后，账就变了。PR 看护员替你省掉几十次上下文切换；夜间报告每天早上自动出现；反馈聚类把一个你懒得看的 feed 变成了可读主题列表。
你打开 Claude，不再只是问它问题，而是检查它已经做了什么。聊天窗口从工作台，变成状态面板。
Boris 指的真正变化，大概就在这里：不是模型突然聪明了很多，而是工作从手上挪到了时间表上。跑得最快的人，不一定打字最快；他们只是让 loop 在别人还停留在聊天窗口里时，继续往前跑。
最后说一句
Claude Loops 的重点不是酷炫自动化，而是把重复任务从“每次都要人提醒”变成“默认会发生”。
最好的起点不是搭系统，而是找一个足够窄、足够无聊、足够容易验收的任务。先让它稳定跑起来，再想第二个。
别先追求十个 agent 同时跑，先让一个 loop 可靠地替你守住一件小事。