作者注：從 DeepSeek 超級代理設計出發，拆解多代理系統中 router 與 worker 的模型分配邏輯，並講清楚緩存讀取 Token 如何影響架構成本。
搭建多代理編碼系統時，多數人會給“總指揮”配最強的模型，再讓下面的執行者用便宜模型。DeepSeek Harness 團隊在 2026 年 11 月公開的超級代理設計給出了相反的思路：router 用便宜模型、worker 用強模型。負責對話和派活的 router 用輕量模型，真正寫代碼的 worker 用最強的模型。
這不是一篇轉述新聞的文章。我們把這套架構翻譯成可執行的模型選型判斷：router 需要哪些能力，worker 需要哪些能力，緩存讀取 Token 怎樣估算，什麼時候該選低價模型。文中引用的測試數據，DeepSeek 自己也只稱爲“指示性”結果，我們會把邊界講清楚。
核心價值：讀完本文，你能爲自己的多代理系統寫出一份按角色分配模型的方案，並用緩存讀取量粗算出這份方案的成本量級。
多代理模型分配核心要點
DeepSeek 的設計分爲兩層。router 是一個長期存在的會話，負責和人溝通、分派任務、跟蹤任務之間的關係。worker 每次只領一個任務，擁有獨立的乾淨上下文，從不直接和人對話，只向 router 彙報狀態。按這個分工，模型分配可以先用下表定下基調。
| 角色 | 核心職責 | 是否寫代碼 | 推薦模型檔次 | 選型理由 |
|---|---|---|---|---|
| router | 對話、分派、跟蹤任務關係 | 否，可以不給 shell 權限 | 輕量、低價、快速 | 工作簡單但調用頻繁，延遲和單價更重要 |
| worker | 領取單個任務並完成編碼 | 是 | 當前可用的最強編碼模型 | 代碼質量直接決定交付結果 |
| 觸發器過濾層 | 篩掉羣聊、CI 通知裏的噪聲 | 否 | 第一道用普通代碼，第二道用小模型 | 大多數事件不需要進入模型 |
爲什麼多代理模型分配要“倒置”
DeepSeek 認爲，AI 輔助編碼的瓶頸已經從模型能力轉移到人的注意力上。一個人通常只能同時跟蹤 3 到 5 個活躍的代理會話，再多就會搞不清哪個在等審批、哪個卡住了、哪兩個在悄悄修改同一個 PR。所以 router 的價值不在“聰明”，而在“穩定地派活和記賬”。它不拆解任務，只負責分配和跟蹤，這與常見的“主代理把任務拆成步驟”模式不同。
既然 router 不需要深度推理，也不寫代碼，把最貴的模型放在這裏就是浪費。worker 纔是真正產出代碼的地方，代碼質量決定交付成敗，強模型的預算應該花在這裏。這就是“模型選擇倒置”：越靠近用戶的角色越輕，越靠近代碼的角色越重。
router 與 worker 分別需要哪些能力
把角色職責拆成能力項，才能落到具體的模型選擇上。下面這張清單可以直接用來評估候選模型。
| 能力項 | router 要求 | worker 要求 | 選型提示 |
|---|---|---|---|
| 指令遵循與分類 | 高，要穩定判斷任務歸屬 | 中 | router 優先測分派準確率 |
| 長上下文與回溯 | 中，靠 ID 摘要逐級展開 | 高，需要讀大量代碼 | worker 看上下文窗口和代碼檢索能力 |
| 代碼生成質量 | 不需要 | 最高優先級 | worker 預算不要省 |
| 響應延遲 | 高優先級，頻繁做決策 | 中，單任務可以慢一些 | router 選 Flash 類快速模型 |
| 單價敏感度 | 很高，緩存讀取量巨大 | 中 | router 的單價影響總賬 |
| 工具調用 | 少，可以不給 shell | 多，需要執行與測試 | 用權限邊界約束角色 |
router 還有一個容易被忽略的要求：結構上不能“自己動手”。DeepSeek 特意讓 router 沒有 shell 權限，就是爲了消除它直接幹活的可能。所以給 router 選模型時，不必追求它“什麼都會”，反而要接受它“只會派活”。
多代理模型分配中的緩存 Token 開銷
router 便宜還不夠，這套架構真正的成本大頭是緩存讀取 Token。router 是長期會話，會反覆讀取緩存中的上下文；多個 worker 並行運行，又各自讀取大量上下文。DeepSeek 的測試數據把這個問題擺得很直觀。
| 測試指標 | 數值 | 說明 |
|---|---|---|
| 每輪消息數 | 約 300 條 | 其中約 20 條是真實工作請求 |
| 超級代理平均完成時間 | 12.4 分鐘 | 慢的一端爲 15.7 分鐘 |
| 單會話基線慢端耗時 | 29.5 分鐘 | 用作對照 |
| router 決策負載 | 每分鐘約 1 次升至約 40 次 | 單次決策耗時從 6.4 秒降到 1.6 秒 |
| 緩存讀取 Token | 2,320 萬 | 開啓 pass-through 優化 |
| 無優化時緩存讀取 | 3,180 萬 | worker 不直接訂閱線程的情況 |
| 緩存成本 | 約 7 美元 | 按 DeepSeek 自家閒時 Flash 檔定價 |
如何根據緩存讀取量估算多代理模型分配成本
估算時可以把一輪運行的成本拆成三塊：緩存讀取 Token 乘以緩存讀取單價，加上未命中緩存的輸入 Token 乘以輸入單價，再加上輸出 Token 乘以輸出單價。在 router-worker 架構裏，第一項往往佔絕對大頭，所以緩存讀取單價是選型時最該盯住的價格項。
用報道的數字做反推：約 7 美元對應 2,320 萬緩存讀取 Token，摺合約每百萬 Token 0.3 美元的量級。這只是由報道數字反推的近似值，不是官方報價，實際價格要以模型廠商當前的價目表爲準。有了這個量級，你可以把候選模型的緩存讀取單價代入，快速看出同樣的工作量換成高價模型會放大多少倍。
pass-through 優化本身也值得注意。worker 訂閱線程後，新事件直達 worker，不必經過 router 轉發，緩存讀取量從 3,180 萬降到 2,320 萬，減少了約 27%。也就是說，架構層面的優化和換便宜模型一樣，都能直接壓低賬單。
原文數據需要注意的三個邊界
- 編碼環節是模擬的：測試中“寫代碼”由一個只消耗時間的工具代替，測的是調度行爲，不是代碼質量，所以無法用它證明 worker 用什麼模型效果最好。
- 數據只是指示性的：DeepSeek 明確說這些數字是 indicative，不是嚴格的基準測試。
- 與 Sonnet 檔的比價表述不一致：報道摘要提到按 Sonnet 檔估算約 4.64 美元，正文卻說同樣用量在高價檔會“明顯更貴”，兩處說法互相矛盾。在查閱 DeepSeek 原始文章覈實之前，不建議引用這個具體比價。
多代理模型分配快速上手
把上面的邏輯落到自己的系統裏，可以按以下步驟推進。這裏不給代碼，所有配置項都以行內形式說明，便於你對照自己的框架。
- 先拆角色，再選模型：列出系統中所有會調用模型的角色，至少區分 router、worker、觸發過濾三類，爲每類寫出它是否寫代碼、是否需要工具。
- 把模型名做成配置項：在配置中爲每個角色單獨設置
router_model、worker_model、filter_model之類的參數，不要把模型名寫死在業務代碼裏。 - 用結構保證委派：給 router 去掉 shell 等執行工具。DeepSeek 的實驗顯示，單會話代理在中性提示詞下 5 次運行一次都沒委派過，最慢一次接近半小時；即使提示詞明確要求委派，5 次裏也有 1 次判斷任務太小自己幹了。
- 過濾先行：觸發事件先用普通代碼按事件來源、白名單篩掉噪聲，只把留下的事件交給模型按團隊規則判斷。
- 記錄緩存讀取量：每輪運行都記錄緩存讀取、未緩存輸入、輸出三類 Token，用前文的公式算出單輪成本。
- 換模型做對比：保持任務集不變，只替換
router_model，觀察分派準確率、延遲和成本的變化，再決定是否降檔。
在第 2 步和第 6 步，接入方式會直接影響實驗效率。如果 router 和 worker 來自不同廠商，各自維護一套密鑰和 SDK 配置，切換一次就要改很多地方。通過 API易 apiyi.com 這類統一接口平臺，可以用同一個 API 密鑰、同一套 OpenAI 兼容請求格式，只改 model 參數就爲 router 和 worker 分配不同廠商的模型，對比實驗的成本會低很多。
🚀 快速上手建議：做原型驗證時，建議先在 API易 apiyi.com 上用同一個密鑰分別配置 router 和 worker 的模型參數，跑同一批任務記錄 Token 用量。具體有哪些模型可用（例如 DeepSeek 的 Flash 檔模型），以平臺當前的模型列表爲準。
何時該爲多代理模型分配選擇低價模型
低價模型不是處處適用。下表給出一組判斷依據，幫你決定每個角色要不要降檔。
| 場景特徵 | 建議 | 原因 | 接入方式 |
|---|---|---|---|
| 角色只做分派、跟蹤、檢查緩存上下文 | 選低價快速模型 | 任務簡單，單價和延遲主導體驗 | API易 apiyi.com 或廠商官方 API |
| 角色負責生成和修改代碼 | 選強模型 | 代碼質量決定交付結果 | API易 apiyi.com 或廠商官方 API |
| 緩存讀取量達到千萬級、並且每天重複運行 | 優先壓低緩存讀取單價 | 緩存成本隨運行次數線性增長 | 按廠商價目表覈算 |
| 偶發、輕量的單次任務 | 按量計費即可 | 用量小，不值得爲架構複雜度買單 | 任意按量渠道 |
| 高頻、Token 密集的自動化任務 | 評估包月或高限額方案 | 單次運行的邊際成本不再體現在賬單上 | 視具體訂閱條款 |
最後一行有一個參照：同期報道的 Claude Code Pass 定價爲每月 9.99 美元，在 Kimi K3.1 Pro、GLM 5.3、DeepSeek V4.1 Flash 等開放模型上提供約 2 到 5 倍的速率限額，並設有 5 小時、每週、每月三層用量上限。報道同樣認爲，在只做路由決策或檢查緩存上下文的環節，快速便宜的模型在技術上就更合適，而不只是更省錢。不過這類方案會把你鎖定在套餐內的模型上，worker 如果依賴套餐外的模型，仍需要另外的接入渠道。
多代理模型分配的風險與邊界
模型分配解決的是成本和分工問題，不解決這套架構本身的遺留難題。DeepSeek 承認了兩個未解決的問題：一是長期記憶，系統運行幾個月後，如何在不撐爆上下文窗口的前提下保留相關歷史仍然很難；二是提示詞注入，凡是讀取外部事件（羣聊、PR 評論）的代理都可能被操縱，而 router 與 worker 通過共享的雲端循環相連，一個被攻破的事件源理論上可能把指令擴散到系統接觸的每臺機器。
這對模型分配有直接影響。router 用了便宜模型，不代表可以放鬆它的防護，因爲它恰恰是第一個接觸外部事件的角色。DeepSeek 內部部署時，主動行爲先以“本來會這樣做”的日誌模式運行，而不是立刻執行。比如“靜默復現並修復”策略：有人報告 bug 時，代理在後臺嘗試復現，確認並修好後纔在對話進行中提交 PR，復現不了就什麼都不發。新系統上線時，先觀察日誌、再逐步放權，是更穩妥的做法。
此外，原型代碼 DSH Super Agent 在 GitHub 上明確標註爲研究代碼，不是正式產品。參考它的設計思路沒有問題，但不建議直接部署到生產環境。
常見問題 FAQ
Q1: 什麼是多代理系統中的“模型選擇倒置”？
指 router 用輕量便宜的模型，worker 用最強的模型。router 只負責對話、分派和跟蹤，不寫代碼；worker 負責實際編碼，因此強模型的預算應該花在 worker 上，而不是放在“總指揮”的位置。
Q2: router-worker 架構和“主代理拆解任務”的模式有什麼區別？
主代理模式中，主代理要把任務拆成步驟，對推理能力要求較高。DeepSeek 的 router 不做任何拆解，只分配和跟蹤任務，所以能用更輕的模型。代價是 worker 必須能獨立完成整個任務。
Q3: 這套設計是什麼時候公開的？DSH Super Agent 能直接用嗎？
相關報道發佈於 2026 年 11 月 3 日。DSH Super Agent 是隨設計文章一起發佈在 GitHub 上的研究原型，官方明確它不是受支持的產品，只適合用來理解架構。
Q4: 只用提示詞讓單個代理學會委派，可行嗎？
DeepSeek 的測試表明不可靠：中性提示詞下 5 次運行零委派，強調委派的提示詞也有 1 次沒有委派。可靠的委派要靠結構隔離，例如拆分會話、移除執行工具，而不是寫更長的提示詞。
Q5: 如何在同一個系統裏方便地爲 router 和 worker 配置不同廠商的模型？
關鍵是把模型名做成按角色區分的配置項，並統一接入方式：
1. 在 API易 apiyi.com 註冊並獲取一個 API 密鑰
2. 在系統配置中分別設置 router 和 worker 的 `model` 參數
3. 保持請求格式不變，只替換模型名來做對比實驗
這樣不需要爲每個廠商單獨維護一套 SDK 配置。可用模型以平臺當前列表爲準。
Q6: 原文的成本數據能直接用來做預算嗎？
不建議直接套用。編碼環節是模擬的，數據只是指示性結果，與 Sonnet 檔的比價表述也前後不一致。更好的做法是用自己的任務集實測緩存讀取量，再乘以當前單價。在 API易 apiyi.com 上保持任務不變、切換模型分別跑一輪，就能得到適合自己場景的數據。
Q7: 這種架構有哪些已知限制？
主要有三點：長期運行後的記憶退化；讀取外部事件帶來的提示詞注入風險；緩存讀取 Token 量很大，用高價模型時成本會被明顯放大。此外，目前缺少 router 具體使用哪個模型的效果數據，需要自行測試。
多代理模型分配核心要點 Key Takeaways
- 模型選擇倒置：router 用輕量便宜模型，worker 用強模型寫代碼。
- 瓶頸在注意力：人通常只能盯住 3 到 5 個會話，router 負責收攏溝通。
- 委派靠結構：去掉 router 的執行工具，比改提示詞可靠得多。
- 緩存是成本大頭：一輪測試緩存讀取達 2,320 萬 Token，單價最關鍵。
- 架構優化同樣省錢：pass-through 直通讓緩存讀取減少約 27%。
- 數據要謹慎引用：編碼爲模擬，結果僅具指示性，比價待覈實。
- 用統一接口做實驗：在 API易 apiyi.com 只改
model參數即可對比不同分配方案。
總結
router 用便宜模型、worker 用強模型，這套多代理模型分配思路的核心要點如下：
- 按職責分檔：不寫代碼、只做分派跟蹤的角色用低價快速模型，編碼角色用強模型。
- 按緩存算賬：緩存讀取 Token 是這類架構的主要開銷，選型時優先比較緩存讀取單價。
- 按實測定案：原文數據只能參考方向，最終要用自己的任務集跑出成本和效果。
建議先用一個小任務集搭起 router-worker 原型，把模型名做成按角色配置的參數，再逐步替換 router 的模型，觀察分派準確率和成本的變化。推薦通過 API易 apiyi.com 用一個密鑰統一接入多家模型來完成這組對比，讓選型決策建立在自己的數據上。
📚 參考資料
- DeepSeek’s Super Agent Harness: Fixing the Attention Bottleneck in AI Coding：DeepSeek 超級代理設計解讀
- 鏈接：
mindstudio.ai/blog/deepseek-super-agent-harness-design -
說明： 包含 router-worker 架構、委派實驗、緩存 Token 數據與未解決問題
-
Claude Code Pass Pricing: What’s in the $9.99/Month Plan：包月高限額方案解讀
- 鏈接：
mindstudio.ai/blog/claude-code-pass-pricing - 說明： 討論按量計費與包月方案在多代理、Token 密集型工作流中的取捨
作者: APIYI 技術團隊
技術交流: 歡迎在 API易 apiyi.com 首頁聯繫我們討論多代理模型分配方案，更多接入資料可訪問 docs.apiyi.com 文檔中心
