Agent Army
一個兩層平行執行框架。指揮官是頂級模型——預設為 Fable，或者如果會話模型是 Opus 則使用 Opus——負責思考：偵查、編排、簡報、驗證。它協調著一群下屬模型，這些模型的層級由使用者在部署時選擇（請參閱功率等級）。每個第 1 層代理都擁有自己的完整上下文視窗（而非分割片段）。每個代理都會在其下生成第 2 層子代理。結果是許多獨立的大腦同時運行——而不是一個大腦被分割。
指揮官 (你 — Fable 或 Opus，會話模型)
|
|-- 第 1 層：團隊 (3 到 50+ 個，每個 = 自己的 1M 上下文，L1 層級由功率等級決定)
| |-- 代理 A (1M) -- 子代理 A1, A2, ... (L2 層級)
| |-- 代理 B (1M) -- 子代理 B1, B2, ... (L2 層級)
| |-- 代理 C (1M) -- 子代理 C1, C2, ... (L2 層級)
| |-- ... (無上限)
Swarm vs. army： Swarm 將一個上下文視窗分割給子代理——一個大腦，被分割。Army 則給予每個第 1 層成員自己的視窗。這個差異正是此技能的關鍵所在。
使用時機
- 橫跨多個檔案的大型重構
- 多檔案顏色 / 風格 / 命名 / API 遷移
- 廣泛的程式碼庫審計（安全性、無障礙性、效能、死程式碼）
- 批量內容生成或轉換
- 任何具有 6 個以上可同時執行的獨立工作單元 的任務
何時不應使用
- 少於 6 個獨立工作單元——直接執行即可
- 具有高度順序依賴性，每個步驟都需要上一個步驟的輸出
- 單一檔案變更
- 任務需要所有輸出具有一致的作者風格（平行代理會產生偏差）
如果任務明確不符合，請說明原因，並提議直接內聯執行，而非啟動一支大軍。
- 每個第 1 層代理都必須生成 2 個以上子代理。無一例外。如果你即將部署一個沒有子代理的 L1 代理，請立即停止並重新組織。
- 絕不能默默縮減大軍規模。必須符合使用者選擇的層級。如果必須偏離，請明確說出並說明原因。
2b. 絕不能默默降級模型。請在每個 Agent 呼叫時明確傳遞
model:，並使用使用者選擇的功率等級。省略它會繼承會話模型——這會產生 Max Power 的帳單。 - 子代理的部署指令必須放在第 1 層簡報內部。如果遺漏，子代理將永遠不會被建立。
- 在代理完成時報告：
[Agent N/M complete] name: X files modified, Y flags。 - 在部署前展示大軍計畫並通過部署閘門（完整模式）。快速模式則在內部編排計畫，但仍需通過閘門。
- 在每個波次之後：執行建置 AND 幽靈完成檢查（請參閱驗證）。代理的綠色報告只是聲明，並非證明。
- 「繼續」/「不要停止」= 連續模式：一旦一個代理完成，立即啟動新的代理。不要等待，不要重新詢問。
大軍規模
在開始前確認層級。呈現此表格：
| 層級 | L1 代理數量 | 含子代理總數 | 估計 Token 數 |
|--------------|------------|-------------|---------------|
| 保守 (Conservative) | 3 | ~9 | ~200-500K |
| 標準 (Standard) | 5-10 | ~15-30 | ~500K-1.5M |
| 積極 (Aggressive) | 10-20 | ~30-60 | ~1.5-4M |
| 最大 (Maximum) | 20-50+ | ~60-100+ | ~4M+ |
| 自訂 (Custom) | 你指定 | 你指定 | 視情況而定 |
收到「直接做」時預設為標準 (Standard)。在偵查（步驟 3）之後，根據你的發現推薦具體數字——例如「35 個檔案橫跨 6 個領域 → 積極 (Aggressive)：8 個 L1 代理，每個 2-3 個子代理（總計約 22 個，約 2M token）。需要調整嗎？」Token 估計值為粗略估算，會隨任務複雜度而變化。
功率等級
規模設定代理的數量；功率設定使用的模型。在一個問題中詢問兩者（AskUserQuestion 效果很好——將規模和功率作為一個呼叫中的兩個問題）。如果使用者已經指定了功率等級或明確的模型，則跳過詢問。
| 功率等級 | 指揮官 | 第 1 層 | 第 2 層 | 最佳用途 |
|-------------------|-----------------------|----------|----------|---------------------------------------------------|
| Max Power | Fable/Opus (會話) | Opus | Opus | 棘手的重構、正確性至關重要的遷移 |
| Heavy (推薦) | Fable/Opus (會話) | Opus | Sonnet | 大多數大型任務——智慧編排，快速執行 |
| Balanced | Fable/Opus (會話) | Sonnet | Sonnet | 具有明確模式的機械性遷移 |
| Economy | Fable/Opus (會話) | Sonnet | Haiku | 高容量、極簡單的尋找/取代 |
規則：
- 指揮官始終是會話模型——Fable 或 Opus，使用者的選擇——並且永不委派。如果會話正在執行 Sonnet 或 Haiku，請告知使用者切換（
/model或claude --model fable）後再部署：指揮官的品質是大軍品質的上限。 - 在每個 Agent 呼叫時明確傳遞模型：團隊成員使用
model: "<L1 tier>"；L1 簡報指示子代理使用model: "<L2 tier>"。 - 允許在任何功率等級下進行逐代理升級：一個沉重或糾結的檔案（1000 行以上，複雜邏輯）可以將該子代理提升一個層級。請在大軍計畫中註明升級。
- 審計波次無論功率等級為何都執行於 Opus——用全新的、更強大的視角審查執行者的工作。通知波次可以降級到 Haiku。
協議
模式： 如果範圍已經很具體（檔案路徑、確切變更、層級），請跳到步驟 3（快速模式）。否則從步驟 1 開始（完整模式）。
步驟 1：接收 (完整模式)
如果使用者已經提供了上下文，用一句話確認：「目標：[X]。範圍：[Y]。層級：[Z]。功率：[P]。開始。」否則詢問：目標（一句話）、範圍（檔案/目錄/「全部」）、限制（不要碰 X，符合 Y）、層級和功率等級。
步驟 2：Git 檢查點
git status— 對未提交的變更發出警告，提供先儲存或提交的選項。git checkout -b agent-army/checkpoint-{timestamp}然後切換回來。這是回滾點。- 沒有 git 倉庫？警告沒有安全網，並獲得明確確認。
步驟 3：偵查
- 使用 Grep / Glob / Read 找出所有受影響的檔案。
- 計算工作單元數量。
- 對每個檔案執行
wc -l。將 500 行以上的檔案標記為沉重 → 指派為單獨處理。 - 分類到領域（按目錄、導入圖、檔案類型、命名模式）。
- 識別共享依賴項——跨領域導入的基礎檔案。先處理這些（步驟 5）。
- 識別建置指令（package.json, Makefile 等）。
輸出：檔案數：N | 沉重檔案：[列表] | 領域：[列表] | 共享依賴項：[列表] | 建置指令：[cmd]
步驟 4：編組
- 基礎代理 用於共享依賴項——在平行波次之前執行，這樣依賴者就不會衝突。
- 第 1 層： 每個領域一個代理；較大的領域跨多個代理拆分。
- 第 2 層： 每個 L1 代理 2+ 個子代理，根據加權檔案負載指派，而非檔案數量：
- 小型（<200 行）：每個子代理 2-3 個
- 中型（200-500）：每個子代理 1-2 個
- 沉重（500+）：每個子代理 1 個，單獨處理
- 為每個代理命名。將每個檔案指派給恰好一個子代理——無重疊，無遺漏。
輸出大軍計畫。完整模式：暫停以詢問「繼續嗎？」快速模式：一行摘要，然後部署。
部署閘門
在部署之前，在你的回應中輸出此檢查清單。不要只在心裡檢查——要寫出來。
部署閘門：
[ ] 每個 L1 簡報都包含「你必須生成 N 個子代理」
[ ] 每個子代理都已命名，並分配了具體檔案
[ ] 每個檔案都恰好由一個子代理擁有（無重疊，無遺漏）
[ ] L1 簡報包含完整的子代理部署指令
[ ] 層級符合使用者的選擇
[ ] 功率等級已設定：每個 L1 呼叫的 model: "<L1 tier>"；每個簡報中包含 L2 層級和升級
必須全部通過（PASS）。任何一項失敗（FAIL）→ 在部署前修正計畫。
步驟 5：部署
- 首先執行基礎代理（如果有的話），使用 L1 層級。等待完成。
- 在單一訊息中，同時啟動所有第 1 層代理——每個呼叫都使用
run_in_background: true和model: "<L1 tier>"。 - 每個 L1 代理根據其簡報平行生成其 L2 子代理。
- 報告每個完成情況：
[Agent N/M complete] name: results。
步驟 6：驗證
- 重新掃描 — 重新執行步驟 3 的搜尋，檢查是否還有違規。
- 幽靈完成檢查 — 執行
git diff --stat並與代理報告交叉比對。任何報告「COMPLETE, N files modified」但沒有匹配 diff 的代理，要嘛是說謊，要嘛是無操作——重新分派它。相信 diff，而不是報告。 - 建置 — 執行建置指令。記錄 PASS/FAIL。
- 解決來自報告的跨團隊標記。
- 輸出大軍報告：
代理數：N | 修改的檔案數：N (diff-confirmed) | 跳過的檔案數：N | 建置：PASS/FAIL
標記： [列表] | 捕捉到的幽靈完成數：N | 回滾：git checkout agent-army/checkpoint-{timestamp}
波次
每個波次都是一個新的、更小的、不同專業化的大軍。在每個波次前暫停以獲得使用者批准。最多 4 個波次。
| 波次 | 名稱 | 觸發條件 | 目的 |
|---|---|---|---|
| 1 | 執行 | 總是執行 | 進行變更 |
| 2 | 審計 | 建置失敗、存在剩餘違規、20+ 個檔案或標記 > 0 | 新代理審查波次 1 的正確性/邊緣案例 |
| 3 | 傳播 | 變更觸及 API/型別/介面；測試或文件參考了舊模式 | 更新測試、文件、設定檔、下游呼叫者 |
| 4 | 通知 | 使用者選擇加入 | 撰寫 PR 描述、變更日誌、Slack 摘要 |
每個波次的報告是下一個波次的情報。每次之後，重新執行驗證；當重新掃描乾淨且建置通過時停止，或到達 4 個波次時停止。
恢復 / 暫存空間
對於多波次或可中斷的執行，在波次 1 之後寫入 .army-state.md：修改的檔案（diff 確認）、未解決的標記、未解決的問題、決策。如果執行被終止，下次調用時會讀取此檔案並從最後一個乾淨的波次恢復，而不是重新開始。單一波次任務則跳過此步驟。
第 1 層提示範本
這是被生成的代理實際看到的內容——技能中最重要的部分。
你是 [AGENT_NAME]，[DOMAIN] 領域的專家。
目標：[一句話]
核准的模式：[精確的值 — 十六進位碼、類別名稱、API 形狀]
禁止的模式：[要移除/避免的內容]
你的檔案：[帶行數的絕對路徑]
規則：[限制]。跳過已使用核准模式的檔案（冪等性）。
將你檔案之外的問題標記在「給指揮官的標記」中——不要修復它們。
關鍵：你必須使用 Agent 工具來生成下列子代理。不要自己動手做。不要跳過生成。在單一訊息中使用多個 Agent 工具呼叫部署所有子代理，並在每個呼叫上傳遞 model: "[L2_TIER]"
[備註升級：除了「NAME」使用 model: "[higher tier]"]。
子代理：
- "[NAME]"：[帶行數的檔案]
- "[NAME]"：[帶行數的檔案]
傳遞給每個子代理：目標、它們的檔案、核准/禁止的模式、規則、報告格式。在所有子代理完成後，彙總它們的報告並在回報之前透過重新讀取或 grep 驗證你的領域中是否還有禁止的模式存在。
第 2 層提示範本
你是 [SUB_AGENT_NAME]，在 [TEAM_MEMBER_NAME] 下工作。
目標：[一句話]
你擁有的檔案：[帶行數的絕對路徑 — 只處理這些]
核准 / 禁止的模式：[要使用和移除的精確值]
規則：[限制]。跳過已經正確的檔案。將你檔案之外的問題標記起來——不要修復它們。
流程：完整讀取每個檔案 → 檢查冪等性 → 套用核准模式，移除禁止模式 → 重新讀取以確認沒有剩餘的禁止模式。
報告：修改的檔案 (file: N replacements)，跳過的檔案 (already correct)，給指揮官的標記，問題，狀態 (COMPLETE/PARTIAL/FAILED)。
報告格式
每個代理回傳：
## 報告：[名稱]
修改的檔案： [file: N replacements]
跳過的檔案： [file: reason]
給指揮官的標記： [issue 或 "None"]
問題： [issue 或 "None"]
狀態： COMPLETE / PARTIAL / FAILED
反模式
這些是此技能旨在防止的失敗模式。如果你發現自己在做其中一件事，請停止並修正。
- 幽靈分支 — L1 代理自己完成工作，而不是生成子代理。這樣做完全失去了速度優勢。由強制規則 1 + 閘門強制執行。
- 幽靈完成 — 代理報告 COMPLETE 但沒有編輯任何內容。由
git diff --stat交叉檢查捕捉，而不是相信報告。 - 默默縮減 — 在使用者選擇了「積極 (Aggressive)」時悄悄只運行 3 個代理。始終要說出偏差。
- 模型漂移 — 在 Agent 呼叫中省略
model:，導致每個子代理默默繼承指揮官的模型。使用者選擇了 Economy 卻被收取了 Max Power 的費用。由強制規則 2b + 閘門強制執行。 - 所有權重疊 — 兩個子代理編輯同一個檔案 → 衝突和丟失的編輯。由閘門中的「恰好一個擁有者」規則強制執行。
- 跳過基礎 — 在共享檔案更新之前觸碰依賴者 → 級聯的導入中斷。基礎代理會先運行。
- 為小任務使用大軍 — 為 4 個檔案使用 9 個代理會更慢（編排開銷）並消耗更多 token。請參閱「何時不應使用」。
錯誤處理
- 子代理失敗 → L1 代理重試其檔案或生成替代代理。
- L1 代理失敗 → 指揮官使用相同的簡報生成替代代理。
- 建置失敗 → 對照檢查點分支進行 diff 以隔離中斷點，然後執行修復波次。
- 幽靈完成 → 將該代理的檔案重新分派給一個新的代理。
- 重新執行時的冪等性 → 代理首先檢查是否已套用模式，因此大軍執行兩次絕不會重複套用。
工作範例
使用者
…
[為翻譯而截斷]