三个智能体上的循环工程：yetone 的 Magpie 工作流对无人值守运行 Claude Opus 5.5 的启示

yetone 的这套配置最有趣的地方不在于模型，而在于数字三。Magpie——一个本地网关，让编码智能体可以针对你指定的任意模型运行——的维护者于 2026-10-13 在 X 上描述了自己的维护工作流：由 Anthropic 的 Claude Opus 5.5驱动的 Claude Code，同时运行三个 /loop任务，每个任务盯住一个不同的界面——GitHub 的 issue 与 pull request、Discord 社区，以及从 X 上涌来的反馈——并修复它发现的问题。循环工程（loop engineering），即让智能体持续循环运转、而不是逐轮提示的实践，是今年被大量讨论的话题。这个例子之所以值得一读，是因为它还附带了一张组织架构图。

Claude Opus 5.5 并不新鲜。Anthropic 早在三周前的 2026-09-22 就发布了它，定价为每百万输入 token 4 美元、每百万输出 token 20 美元。这不是一篇发布报道。它讲的是：这个模型的默认设置，对任何想要照搬一套三智能体维护循环的人来说意味着什么——以及这套循环中哪些部分会以教程里只字未提的方式出故障。

工作流中到底有什么？

信号很短，所以值得精确说明哪些是主张、哪些不是。yetone 在 Claude Code 上用 Opus 5.5 同时运行三个 /loop任务。一个盯着代码仓库——issue 和 pull request。一个盯着 Discord。一个盯着 X。智能体在循环中自行判断哪些值得修复就直接修复，无需人工逐轮分派。他自动化的这个模式，正是大多数维护者做得最差的一件事：分诊。不是写代码，而是每天吃掉一小时的那些阅读、分类、去重和回复。

“循环工程”这个说法在这里起着关键支撑作用。循环并不是一个在执行任务的智能体；它是一个会话，按自己选定的时间表不断回到某项任务上，而上一轮迭代的状态仍然摆在它面前。正是这一区别，让大多数自行搭建的版本分崩离析，也正是过去六周里工具链已经转向的地方。

Claude Code 的 /loop在 2026 年 10 月实际上会做些什么

如果你没有读过当前的文档，那么你记忆中的版本很可能是错的，因为/loop在循环工程成为热门话题时改变了形态。

不带间隔的 /loop 不再要求你指定间隔。省略它，Claude 会动态选择一个间隔——在一分钟到一小时之间——依据它在上一轮迭代中观察到的结果。当构建即将完成或拉取请求处于活动状态时，它会短暂等待；而在没有任何待处理事项时，它会等待久得多。每次迭代结束时都会打印所选的延迟及其原因，因此你能看到这个循环对自身节奏的判断。改为提供一个间隔——/loop 5m check the deploy——你就会得到固定的 cron 调度。

也省略提示词，你就会得到一个内置的维护提示词，它在每次迭代中按顺序处理三件事：

• 继续对话中任何未完成的工作。

• 处理当前分支的拉取请求——评审意见、失败的 CI 运行、合并冲突。

• 在没有其他待处理事项时，运行清理环节，例如缺陷排查或简化。

你可以用自己的指令替换该默认设置，方法是编写一个 loop.md——位于 .claude/loop.md（用于项目），或 ~/.claude/loop.md（用于每个未定义自身配置的项目）。编辑会在下一次迭代时生效，因此无需重新启动正在运行的循环即可完善其指令。文件超过 25,000 字节后会被截断，但这对于分类规则来说空间绰绰有余。

那个机制是三环结构中承重的部分，也是工作流图通常略去不提的部分。通用的内置维护提示并不是一套分类处理策略。如果你想要一个循环，让它像你的项目阅读 GitHub 议题那样去阅读 GitHub 议题——什么算作重复、什么会被打上标签而不是得到回复、什么永远得不到回复——那么这套策略就必须放在loop.md中，而不是放在你启动会话时输入的那条提示词里。

决定三是一个数字还是一句口号的界限

三个并发循环正是约束开始显现的地方，在照搬任何人的配置之前，值得把它们一一列出。

• 并发上限——一个会话最多可同时承载 50 个定时任务，所以三个循环远未触及上限。真正的约束不是任务数量，而是注意力：三个循环意味着三股工具调用流在争夺同一个会话。

• 到期 —— 重复任务会在创建七天后自行删除，并在消失之前再触发一次。一个在第八天悄然停止的维护循环，是最常见的一种故障模式，而且它是静默失败的。

• 恢复并不对称——用 --resume 或 --continue 恢复会话时，cron 计划任务会一并回来，但已过期的周期性任务除外。自定节奏的循环则完全不会恢复；你必须重新启动它。

• 忙碌会话行为——任务在轮次之间触发，绝不在响应中途触发。如果某个循环到期时，一个长时间的智能体轮次正在运行，触发会等待。错过的间隔不会叠加；它们会合并为一次触发。

• 抖动 — 周期性任务会有意延迟运行，最多延迟到距下次运行间隔的一半，且最多 30 分钟，这样一批会话就不会在同一秒汇聚。每十分钟运行一次的任务，启动时间会在准时到延迟五分钟之间。五分钟这一情况是例外：Claude Code 会将其提前 15 秒，以使每次运行都保持在提示缓存窗口内。

• 保持开机要求 — 循环仅在 Claude Code 正在运行且空闲时触发。合上笔记本电脑就会停止它们。你离开的那几个小时不会有任何补跑。

最后这一点，正是这套工作流是维护者的配置、而不是平台团队配置的原因。在一台机器上、一个会话里跑三个循环，是一种让你去做别的事时仍能让繁忙的开源项目继续推进的方式；它不是一项服务。

为什么这个工作流是 Claude Opus 5.5 特有的，而不仅仅是一个“智能体”

让三个智能体组成一个循环去跑一个没有大上下文窗口的模型，这些循环就会整天忙着反复重读。每一轮迭代都要重新吞入 issue 讨论串、PR diff 和 Discord 历史记录；如果窗口很小，这些历史就会被摘要抹掉，而随着会话越拖越长，循环的判断力也会悄无声息地退化。Claude Opus 5.5 搭载 100 万 token 的上下文窗口，外加 128K token 的输出，正是这一点让一个分诊循环能够同时握住一份真实的 issue 积压、一段对话，以及最近几轮的迭代。它的定价为每百万 token $4 / $20，而缓存读取为每百万 token $0.20——只有输入价格的正分之一——在这里这一点比平时更重要，因为循环是所有工作负载中最吃缓存友好的那一种。同一个系统提示词、同一套工具定义、同一份仓库上下文，一遍又一遍。

第二处契合在于思考默认值，而它会因每个循环所做的事情不同而朝相反方向起作用。Claude Opus 5.5 始终开启自适应思考，努力程度默认设为中等——比 Claude Opus 5 的默认值低一档。努力程度改变的不只是质量，它还改变工具调用的数量。负责问题分诊的循环和编辑代码的循环需要不同的设置，而最低努力程度设置本身也是一个调度问题：在自定节奏的循环中，模型自己决定下一次唤醒的延迟，因此一个低努力程度的分诊循环和一个高努力程度的修复循环，会以不同的节奏应对同一个代码仓库。没有任何设置能让二者保持一致。关键在于分清哪个是哪个，因为节奏上的差异正是你最先会看到的东西。

如果你想针对不同厂商的模型来运行循环和修复器——用便宜的东西做分诊，用 Claude Opus 5.5 来做修复——那是一个路由决策，而不是 Claude Code 的决策，这也正是网关位于会话前面的原因。

尝试这个，但不拿生产环境做赌注

对三循环配置的一个合理反对是：它会在头一个下午就把一个自主代理摆到用户议题的前面。这个循环会去评论，会去关闭条目。诚实地采用它的方式是：用一个只读的 GitHub 令牌，让一个循环以试运行模式跑上一周，看看它的分诊判断是否与你手工做出的判断一致——并且，另外在正式投入之前，把模型本身路由到一个你可以度量它的地方。

在 OrcaRouter 上，anthropic/claude-opus-5.5按 Anthropic 的标价提供，不额外加价，且来自同一个端点——它同时支持 OpenAI 兼容格式和 Anthropic Messages 格式，因此一个 Claude Code 会话和一个与同一模型通信的脚本无需两套集成。Anthropic 于 2026-09-22 公布了自己的 $4 / $20 定价；如果该标价发生变动，直通网关会在同一天随之调整，而不是等到下一个计费周期——当你为一个可能运行数月之久的循环做规模估算时，这正是你想要的那种版本。跨提供商的自动故障转移覆盖了文档中警告、却无人测试的那种情况：循环不会因为某个上游在凌晨三点返回 429 就停下来。模型融合和路由 DSL 在这里没那么重要——分诊循环要的是一个模型，并且始终如一，因为正是这种一致性让它的判断可被审查。

该如何处理数字三

循环工程的名声问题在于，今年展示出来的大多只是一个循环在演示里跑一项狭窄的工作。yetone 的配置有意思，因为它是三个循环跑在三路不同的输入上——代码仓库、聊天社区、公开时间线——这正是维护者没时间去做的那份实际工作的形态。它也是那种会把上面每一条约束都暴露出来的形态：过期、抖动、恢复、节奏，以及这些循环只在机器开机时才运行这一事实。

可迁移的并不是数量，而是每个循环都有自己的表面、自己在 loop.md 中的策略，以及自己醒来的理由——而且跑它的人能从迭代日志里看出每个循环为什么选择了它所选的那个延迟。这是一种你一周后仍能真正审计的设置。考虑到这些循环全都在第八天过期，这差不多就是你必须决定是否再把它构建一次的时间。

有必要直说：这是一位实践者自己的配置，由作者在 X 上描述，并非厂商推荐的指引。Anthropic 关于 Claude Opus 5.5 和 Claude Code 的 /loop文档只告诉你这些工具能做什么。它并没有说三个就是正确的数量，目前也没有其他人这么说。

当分诊循环与修复循环需要不同的模型时：让循环和修复器共用一个端点即可通过单一端点，以 Anthropic 的标价提供 Claude Opus 5.5，该端点同时支持 OpenAI 兼容与 Anthropic Messages 两种格式。

这样的模型选择，也正是失效模式暴露之处：这一类模型背后有据可查的 AI 事故与智能体故障，都收录在the OrcaRouter AI Incident Archive中，其中每一条记录都附带各自的来源、严重程度、置信等级和争议标记。