Three Agents 的迴圈工程：yetone 的 Magpie 工作流程對無人值守執行 Claude Opus 5.5 的啟示

yetone 的設定最有趣的地方不在於模型，而是「三」這個數字。Magpie 的維護者——這是一款本地閘道，讓編碼代理能對上你指定的任何模型執行——在 2026-10-13 於 X 上描述了他自己的維護工作流程：由 Anthropic 的 Claude Opus 5.5 驅動的 Claude Code，同時執行三個 /loop 任務，每個任務各自盯著不同的表面——GitHub 議題與拉取請求、Discord 社群，以及從 X 湧入的回饋——並修好它發現的問題。迴圈工程（loop engineering），也就是讓代理持續循環運作、而非一輪一輪提示它的做法，是今年許多討論的主題。這個例子之所以值得一讀，是因為它還附帶了一張組織圖。

Claude Opus 5.5 並非新品。Anthropic 已在 2026-09-22 推出，也就是三週前，定價為每百萬輸入 token 4 美元、每百萬輸出 token 20 美元。這不是一篇發布報導。這是一篇關於該模型的預設值，對任何想複製三代理維護迴圈的人意味著什麼的故事——也是關於那個迴圈中哪些部分會以教學文章未曾提及的方式失靈的故事。

工作流程裡實際上包含什麼？

這個訊號很短，所以值得精確說明哪些是有根據的主張、哪些不是。yetone 在 Claude Code 上以 Opus 5.5 同時執行三個 /loop任務。一個監看儲存庫——議題與拉取請求。一個監看 Discord。一個監看 X。這個代理會在迴圈中自行判斷值得修復的就修，無需人類逐輪分派。他所自動化的那個模式，正是大多數維護者做得很糟的一件事：分流。不是寫程式，而是每天吃掉一小時的閱讀、分類、去重與回覆。

「迴圈工程」這個說法在此具有關鍵支撐作用。迴圈並不是一個正在執行任務的代理；它是一個工作階段，會按照自己選定的排程一再回到某項任務，而且上一次迭代的狀態仍擺在它眼前。這個區別正是大多數自製版本瓦解之處，而這也正是過去六週以來工具鏈已經推進的方向。

Claude Code 的/loop在 2026 年 10 月究竟做了什麼

如果你還沒讀過目前的文件，你記憶中的版本很可能已經錯了，因為 /loop在迴圈工程正流行時改變了樣貌。

單獨使用 /loop時，不再需要你指定間隔。省略它，Claude 會動態挑選一個間隔——介於一分鐘到一小時之間——取決於它在上一輪迭代中觀察到的情況。當建置即將完成或有拉取請求正在進行時，它會短暫等待；而當沒有任何待處理事項時，它會等待得久得多。每次迭代結束時都會印出所選的延遲時間及其原因，因此你可以看到迴圈本身對其節奏的推理。改成提供一個間隔——/loop 5m 檢查部署——那你得到的就是固定的 cron 排程。

也省略提示詞，你就會得到一個內建的維護提示詞，它會在每次迭代中依序處理三件事：

• 繼續對話中任何未完成的工作。

• 處理目前分支的提取要求——審查意見、失敗的 CI 執行、合併衝突。

• 當沒有其他待辦事項時，執行清理作業，例如錯誤排查或簡化。

你可以撰寫自己的指示來取代該預設值，只要寫入 loop.md——位置在 .claude/loop.md（適用於單一專案），或 ~/.claude/loop.md（適用於所有未定義自身設定的專案）。編輯會在下次迭代時生效，因此你可以調整執行中迴圈的指示，而不必重新啟動它。檔案超過 25,000 位元組後會被截斷，這已遠超過分流規則所需的空間。

那個機制是三迴圈架構中承重的部分，而它正是工作流程圖通常會略過的部分。通用的內建維護提示並不是分流政策。如果你想要一個迴圈，能以你的專案讀取 GitHub 問題的方式來讀取 GitHub 問題——什麼算作重複、什麼會得到標籤而不是回覆、什麼永遠不會得到回覆——政策就必須存在於 loop.md，而不是你開始工作階段時輸入的提示。

決定「三」是一個數字還是一句口號的界線

三個並行迴圈正是各種限制開始發威的地方，而在你複製任何人的設定之前，這些限制值得先列出來。

• 併發上限 —— 一個工作階段一次最多可容納 50 個排程工作，所以三個迴圈離上限還差得遠。真正的限制條件不是工作數量，而是注意力：三個迴圈代表三股工具呼叫串流在競爭同一個工作階段。

• 到期 — 週期性任務會在建立七天後自我刪除，並在消失前再觸發最後一次。一個在第八天悄然停止的維護迴圈，是最常見的單一故障模式，而且它會無聲無息地失敗。

• 還原的不對稱 — 使用 --resume 或 --continue 繼續工作階段，cron 排程的工作就會回來，但已過期的週期性工作除外。自行控制步調的迴圈完全不會被還原；你必須重新啟動它。

• 忙碌工作階段行為——任務會在回合之間觸發，絕不會在回應中途觸發。若迴圈到期時，長時間的代理回合仍在執行，觸發便會等待。錯過的間隔不會累積；它們會收攏成一次觸發。

• 抖動（Jitter）——週期性任務會刻意延遲執行，最多延後到下一個執行間隔的一半，且上限為 30 分鐘，如此一來大量工作階段才不會全部擠在同一秒啟動。每十分鐘執行一次的任務，實際啟動時間會落在準時到延遲五分鐘之間。五分鐘延遲的情況是例外：Claude Code 會把它提前 15 秒，以確保每次執行都落在提示快取的時窗內。

• 需保持開機 — 迴圈只會在 Claude Code 執行中且閒置時觸發。闔上筆電就會讓它們停止。你離開的那幾個小時不會有補跑。

最後那一點，正是這套工作流程是維護者的設定，而非平台團隊設定的原因。在同一台機器上、同一個工作階段中跑三個迴圈，是一種在你忙其他事情時讓忙碌的開源專案持續推進的方法；它不是一項服務。

為什麼這個工作流程專屬於 Claude Opus 5.5，而不只是「一個代理」？

在沒有大型上下文視窗的模型上執行三代理迴圈，這些迴圈會整天都在重複閱讀。每一次迭代都會重新吞入 issue 討論串、PR diff 和 Discord 紀錄；如果視窗很小，那些歷史就會被摘要掉，而隨著 session 逐漸變長，迴圈的判斷也會悄悄劣化。Claude Opus 5.5 具備 1M token 的上下文視窗與 128K token 的輸出，這正是讓分診迴圈能同時容納真實的 issue 待辦清單、一段對話，以及最近幾次迭代的原因。它的定價也是每百萬 token $4 / $20，而快取讀取為每百萬 token $0.20——是輸入價格的五分之一——這在這裡比平常更重要，因為迴圈是世上最適合快取的工作負載。相同的系統提示、相同的工具定義、相同的 repo 上下文，一遍又一遍。

第二個契合點是思考預設，而且它會依每個迴圈正在做什麼而往相反方向作用。Claude Opus 5.5 的自適應思考永遠開啟，努力程度預設為中等——比 Claude Opus 5 的預設低一個等級。努力程度不只改變品質；它也會改變工具呼叫量。一個負責分診問題的迴圈和一個負責編輯程式碼的迴圈需要不同設定，而最低努力程度設定本身也有排程問題：在自行調速的迴圈中，模型會自己挑選下一次喚醒延遲，因此低努力程度的分診迴圈和高努力程度的修復迴圈，會針對同一個儲存庫以不同步調運行。沒有任何設定能讓它們一致。重點是要知道哪個是哪個，因為步調差異是你會最先看到的東西。

如果你想讓迴圈和修復器跑在不同廠商的模型上——分診交給便宜一點的模型，修復交給 Claude Opus 5.5——那屬於路由決策，而不是 Claude Code 的決策，這也是為什麼閘道會置於工作階段之前。

試試這個，但不把正式環境押上去。

對三迴圈架構的合理反對意見是，它會在第一個下午就把自主代理擺到使用者問題的最前線。這個迴圈會留言。它會關閉東西。誠實採納這種做法的方式，是先用唯讀的 GitHub token，讓一個迴圈以 dry-run 模式跑一週，看看它的分流判斷是否和你手動做出的判斷一致——另外，還要先把模型本身導向某個在你正式投入之前能夠衡量它的地方。

在 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 文件說明了這些工具能做什麼。它不會告訴你三就是正確的數字，目前也沒有其他人會這麼說。

當分流迴圈與修復迴圈想要不同的模型時：讓迴圈與修復程式共用同一個端點透過單一端點，以 A​nthropic 的定價提供 Claude Opus 5.5，而該端點同時支援 OpenAI 相容與 A​nthropic Messages 兩種格式。

像這樣的模型選擇，也正是失效模式會顯現的地方：這類模型背後有紀錄的 AI 事件與代理失效，都收錄於OrcaRouter AI Incident Archive，其中每筆條目都帶有自己的來源、嚴重程度、可信度等級與爭議標記。