為什麼 Muse Code 的 Agent 整場 session 都不下班？常駐式背景代理架構解析

「生完即丟」的老問題

大多數多 agent 程式開發工具走的都是同一套流程：任務進來，就起一個幫手 agent，塞給它一小塊工作，收完結果就把它拆掉。抽象上很乾淨，代價卻很難看。每個剛生出來的 agent 都得從零開始——重新讀一遍儲存庫結構、重新摸清建置系統、重新學習你程式碼庫的慣例。一場有十個任務的 session，這筆蒐集情境的稅就得繳十次。

而這筆稅不只是 token。它是延遲——每次冷啟動都在拖慢真正的工作；它也是你的指揮成本，因為一個把一小時前學到的東西全忘光的 agent，會把同樣的問題再問你一遍。

Muse Code 的答案：常駐

Muse Code 的架構是一個簡單的主 agent 迴圈，加上一組非同步的背景 agent——而這些背景 agent 在整個 session 期間都保持運作。它們不是為了個別任務而建立的。每一個都有專門分工，隨著 session 推進不斷累積情境，並且自己判斷什麼事情值得回報給主 agent。

最後這個細節比聽起來重要得多。背景 agent 不會卡住主迴圈等指令，也不會拿一堆狀態更新灌爆它。它們獨立推進下一步，只在真正要緊的時候才開口。Meta 官方給的理由正是上面那兩筆成本：常駐降低了延遲，也減少了困難的多步驟任務對人為指揮的依賴。

前台平行施工，後台持續審查

實際用起來的體驗，比較像一支有固定編制的團隊，而不是一排排隊的臨時工。Worker 平行執行變更；reviewer 在背景持續批評產出，趕在東西送到你面前之前。官方發表時的說法——「multi-agent by default（預設即多代理）」——用字非常精準：協作不是一個要你打開的模式，而是每一項任務本來的執行方式。你出貨變快，不是因為哪個單一 agent 變快了，而是因為品質管控是同步進行的，不再是事後補做的功課。

練進模型裡，而不是外掛上去

這套 harness 設計搭配 Muse Spark 1.2 的效果，會比套在任何通用模型外面來得好，是有原因的。這個模型是和 Muse Code harness 一起共同訓練的——訓練配方明確針對 subagent 行為做了最佳化，連同目標追蹤與情境壓縮一起。主迴圈搭配常駐專才的分工方式，不是事後疊上去的 prompt engineering 花招；模型在訓練期間就見過這套架構。「重試更少、工具用得更好」這些宣稱就是從這裡來的，細節可以看我們解析 Muse Spark 1.2 訓練方式的文章。

常駐解決不了的事

一群長壽的 agent 同時編輯同一個儲存庫，照理說是合併災難的完美配方——前提是它們共用同一份工作副本。但它們沒有。當工作分派出去時，每個具備寫入能力的子 agent 都會拿到自己隔離的 git worktree，所以平行作業永遠不會在檔案層面互撞。這套隔離機制值得專文解釋：agent fan-out 與 git worktree。而當你想知道這些 agent 在你沒盯著的時候到底做了什麼，只能附加寫入（append-only）的事件日誌有完整的答案。