高效能邊際路由 是做什麼的？
在 Claude Code、Codex 或其他能夠在指定模型上啟動子代理的代理（例如 Gemini CLI 或 Antigravity CLI）中，將模型與工作匹配，無論主對話使用何種模型。較便宜的主對話可以協調例行工作並諮詢更強的代理；較強的主對話可以將例行工作委派給較便宜的代理。當委派成本高於直接執行時，保留小型任務在本機處理。
說明與設定
當使用 help 或 --help 呼叫時，閱讀設定說明，解釋控制項與範例後停止。不要在說明請求下開始委派工作或更改設定。對於設定問題，閱讀相同參考文件；對於一般任務，則跳過。
從使用者的請求與適用的指令檔案應用路由偏好。對於此技能的偏好，優先使用明確的任務指令，然後是專案偏好，再來是全域偏好，最後是預設值。仍然適用主機權限、模型可用性以及強制限制。使用者可以選擇發現、實作與審查模型；每個代理的投入程度；升級觸發條件與重試次數；最大並發子代理數量；以及升級是否需要批准。若已設定模型上限或禁止委派偏好，則應遵循。如果所需的審查無法在這些限制內執行，請報告未滿足的審查需求，而非默默替換。這些是由助手解讀的指令，而非 JSON 設定或硬性消費上限。除非被要求，否則不要編輯持久偏好設定。
工作流程
- 識別需要更強判斷的決策：架構、模糊性、風險、衝突證據以及最終的技術審查。當主對話適合該任務時，在主對話中處理；否則向上委派。
- 識別可委派的工作：研究掃描、儲存庫清點、搜尋、文件提取、瀏覽器/測試遍歷、日誌縮減、測試失敗聚類、狹義編碼以及機械性編輯。
- 為有正當理由的委派啟動子代理，以明確的歸屬、有界限的範圍、驗證關卡與證據，平行化獨立的工作項目。
- 要求簡潔的回報：發現結果、更改的檔案、執行的指令、殘餘風險、觸發的停止條件以及需要綜合或升級的決策。
- 在呈現結果之前，集中整合與審查。
委派封包
將委派的提示撰寫為自包含的封包。假設接收代理未看過先前的對話。包含儲存庫路徑、目標、範圍、範圍外的區域、相關檔案或搜尋目標、預期的回報格式、驗證指令以及停止條件。
有用的停止條件：
- 即時代碼與委派中的假設不符。
- 驗證指令達到設定的重試次數上限（預設：在合理修正後失敗兩次）。
- 工作似乎需要指派範圍外的檔案。
- 代理無法為其斷言提供具體證據。
審查循環
將委派的輸出視為待檢驗的證據，而非可直接轉送的結論。重新開啟重要的引用檔案，瀏覽高風險差異，並在宣稱完成之前重新執行或抽查重要的驗證。如果委派的代理在困難的技術問題上意見分歧，使用更強的審查者並附上證據。將產品選擇與範圍變更留給使用者決定。
常見情境
將這些視為軟性建議：
- 研究：委派廣泛的儲存庫掃描、文件提取與原始碼比較；主要會話優先處理結果並升級困難的判斷。
- 編碼：當檔案歸屬明確時，委派有界限的補丁、重構或機械性編輯；集中整合與審查。
- 測試：在適當的推理層級選擇驗證策略，然後使用較便宜的代理執行單元檢查、瀏覽器流程、截圖與日誌縮減。要求它們回傳確切指令、失敗情況、可能原因，以及訊號是看起來不穩定（flaky）、環境相關還是產品相關。
- 除錯：派遣獨立的代理分別調查不同的理論、日誌或重現路徑；當證據仍然衝突時，升級診斷。
範例
一個 Sonnet 主要會話收到「修復失敗的結帳測試並趁機收緊退款規則」，專案偏好設定為使用 Haiku 進行發現、Sonnet 進行實作、Opus 以高投入進行風險審查，最多同時執行兩個子代理。
- 發現任務交給一個 Haiku 子代理：執行測試套件，聚類失敗項目，回傳失敗的測試、它們觸及的檔案以及確切的指令。第二個 Haiku 子代理則繪製退款邏輯的所在位置。
- 失敗項目集中在一個過時的測試夾具上。這是一個有界限的機械性修正，因此主要會話在本機處理，而無需支付委派的成本。
- 退款規則觸及帳務，屬於高風險。在編輯之前，主要會話向 Opus（明確要求，
effort: high）發送一個封包，內含退款檔案、建議的變更、當前測試以及一個問題：此變更是否會破壞任何現有的退款路徑？ - 主要會話套用變更，自行重新執行測試，重新開啟 Opus 標記的兩個檔案，並報告每個步驟由哪個模型執行，以便使用者看到確實發生了較強的審查。
層級匹配
使用主機可用的模型與使用者的映射，在主對話模型之上或之下，選擇最便宜且合適的層級：
| 工作 | 所需能力 | Claude 範例 | Codex 與其他主機 |
|---|---|---|---|
| 發現、摘要、事實檢查 | 快速、準確的提取 | Haiku | 一個適合事實性工作的快速可用模型 |
| 有範圍的實作與測試 | 在既定模式內進行可靠的編碼 | Sonnet | 一個適合該範圍的可用編碼模型 |
| 架構、深度除錯、風險審查 | 跨系統的強大推理能力 | Opus，或可用的 Fable | 一個可用的更強推理模型 |
Claude 名稱是供 Claude 對話使用的範例，並非傳遞給 Codex 的別名。不要虛構 Codex 模型 ID 或假設供應商之間存在永久的、一對一的映射關係。檢查主機可用的模型選擇，並使用明確有效的名稱。除非使用者另有要求，否則在一般路由中堅持使用當前供應商；必要時應用獨立的不同供應商審查規則。獨立於模型選擇投入程度，並尊重使用者的投入限制。不要將所有代理預設為最高投入。
較強的主對話可以直接做出困難的決策。從較便宜的對話中，將困難的決策或審查連同簡潔的證據封包一同委派，然後整合結果並執行所需的檢查。如果主機只提供一種模型，則將工作保留在此模型上，並報告任何未滿足的較強審查需求。不要因為投入程度提高就聲稱使用了更高層級的模型。
從較便宜的主要會話升級
在實施不熟悉的架構變更或對高風險不變項的變更之前，應根據使用者的升級政策進行升級。當證據衝突或達到重試次數上限（預設：對同一技術問題進行兩次合理嘗試）時，也應升級。重用已收集的證據；不要為同一組檔案支付另一次廣泛探索的成本。
將身份驗證、計費、權限、安全性、遷移、資料遺失、共享狀態、快取、並發、跨模組行為、公開 API 以及使用者可見的工作流程視為高風險。對於決策或技術審查，使用最合適的較強層級。當使用者要求高風險工作由不同供應商的模型進行審查時，務必執行該審查；它增加了不同模型的視角。
在 Claude Code 中，在 Agent 呼叫中明確請求子代理的 model，或使用自訂代理搭配 model: opus（並在適當時使用 effort: high）。未指定模型可能會繼承較便宜的主要模型。使用具有焦點委派的普通子代理；對話分支使用主要模型。檢查報告的模型，在可用時使用 /tasks。在 Codex 或其他主機中，透過主機支援的每個代理選擇器明確設定模型與推理投入。如果繼承完整對話會阻止模型覆蓋，則使用焦點任務委派。檢查報告的選擇；如果主機無法為每個代理選擇模型，請報告該限制，而不是模擬路由。
將主要會話保留在其選擇的模型上。這是一條路由指令，不是自動的執行時期路由器，也不保證較便宜的模型能夠偵測到每一個困難案例。如果所需的模型不可用或受限，請報告該限制，而不是默默聲稱進行了較強的審查。
防護措施
- 對於立即的阻礙，先在本機工作，除非更強的專業知識或上下文隔離證明順序委派是合理的。在等待時，可能的話進行獨立工作。
- 不要讓多個代理同時編輯同一個檔案。
- 當風險很高時，不要盲目相信子代理的結論；親自檢查重要的證據。
- 不要聲稱普遍節省。此模式在探索與實作、測試或研究可以平行化時效果最佳。
預設框架
「我將把例行工作保留在當前或較便宜的模型上，並在需要時將困難的決策或風險審查委派給更強的代理。」