子代理與蜂群

mu 可以用兩種方式把工作交給別的代理：子代理接各自獨立的任務，蜂群讓幾隻蜂同時攻一個難題。

子代理

模型用 delegate 工具委派，或者你用 /agents 來要求。對每個任務，判定器依難度挑一個角色、一個梯隊裡的模型和一個思考等級（swarm.routing）。內建角色：

你自己的角色放在 ~/.mu/agent/agents/。最多同時執行三個。子代理會拿到適用於它們任務的經驗，在你的硬性約束下工作，並沿用對話的權限模式。features.swarm.models 列出它們可以被分派到的模型，便宜的在前；不設定時，所有子代理都用工作階段的模型。

隔離的編輯

會改檔案的子代理在它自己的 git 工作樹（worktree）裡工作，這個工作樹在你的儲存庫之外，起點是主代理看到的檔案，包括還沒提交的改動。它做完後，改動以修補程式的形式交回，附帶檔案和行數。判定器根據任務、路徑和行數檢查修補程式是否在任務範圍內（swarm.patch），並加一行建議；它從不攔截。

然後由主代理決定：apply_patch_from 要麼全部套用，要麼完全不套用，不提交、不暫存，也不碰你的索引。在 git 儲存庫之外，或者正處在 rebase 或 merge 中間時，子代理直接在原處編輯，並說明原因。

蜂群

每個多代理系統都要回答同一個問題：一個代理知道的，要不要告訴另一個？什麼都不說，它們會走進同一條死路；什麼都說，每個上下文都會被別人的閒聊塞滿。在蜂群裡，判定器當閘門。

一個蜂群有二到六隻蜂，各有自己的關注點。蜂讀程式碼、跑指令、用瀏覽器；它們從不改程式碼，那是主模型的事。/hive <question> 發起一個蜂群；問題直接做不下去時，代理也會自己發起一個。

• 發布（hive.publish）。每隻蜂說完一段，判定器就問：這裡有沒有值得共享的發現、死路、決定或阻礙？有的話，它會上一塊只增不刪的共享板。
• 投遞（hive.deliver）。每來一則新筆記，判定器對每一隻別的蜂各問一次：這和它的關注點有關嗎？有關才投遞過去，標明「這是發現，不是指令」。
• 更正（hive.relate）。後來的發現可以推翻早先的：一隻蜂回報測試跑不起來，後來另一隻清掉一個環境變數，測試就跑通了。判定器讀兩則筆記之間的關係：「推翻」、「矛盾」或「支持」。被推翻的發現變成一則更正，送給每一隻聽過舊發現的蜂。互相矛盾的兩則都留著，標為爭議；一分鐘內沒人解決，就派一隻驗證蜂去查。

一次真實的執行：三隻蜂，九分鐘，評了 117 則候選筆記，27 則發布，16 則投遞給了需要它的蜂。每一次判定都在這次執行的帳本裡。

查看和停止

/swarm 顯示每一隻在做什麼；/swarm stop 讓它們現在交報告；/swarm kill 立刻結束它們。時間到了的蜂會被要求交報告，不交就被結束；卡住的模型或工具由看門狗處理。蜂群總會帶著結果回來。

在桌面版，蜂群頁顯示每隻蜂、它的角色和模型、它在說什麼，以及一張誰把什麼送給了誰的圖：投遞越多線越粗，更正和爭議各有自己的畫法，一則發現送到的那一刻會沿著線亮一下。對話裡的蜂群卡片附有這張圖的縮圖。