Router + Worker 雙層架構解析：DeepSeek 爲什麼認爲 AI Agent 不應該只有一個 Session 的 4 個關鍵設計

作者注：解讀 DeepSeek Super-agent 的 Router + Worker 雙層架構，說明它如何把全局協調與獨立執行分離，以及開發者什麼時候值得在自己的 Agent 系統中採用類似設計。

如果你同時開着四五個 Coding Agent 窗口，就會遇到一個很現實的問題。一個窗口在修登錄 Bug，一個在跑數據庫遷移審查，另一個在等 CI 結果。你要記住每個窗口在做什麼、誰在等你回覆、哪兩個任務之間有關聯。模型確實越來越能獨立幹活，但管理這些會話的負擔落在了人身上。

2026 年 10 月 31 日，DeepSeek Harness 團隊發佈技術文章《Super-agent 設計探索：邁向更自主的 Agent 系統》，同時以 MIT 協議開源了研究原型 dsh-superagent-prototype。其中最核心的設計是 Router + Worker 雙層架構：一個常駐的 Router 負責全局協調，多個隔離的 Worker 負責具體執行。

這不是“讓一個 AI 同時做更多事”的噱頭。Super-agent 的重點在於用系統架構把全局協調與獨立執行拆開，從而減輕人類管理多個會話的負擔。本文按“問題—機制—證據—工程價值”的順序，拆解這套架構的設計動機、關鍵機制、官方實驗數據，以及它對 API 調用和成本管理的啓示。

核心價值：讀完本文，你將理解 Router + Worker 雙層架構真正解決的問題，並能判斷自己的 Agent 系統什麼時候值得采用類似設計。

Router + Worker 核心信息速覽

在深入架構之前，先把這次發佈的基本事實對齊。需要強調的是：DeepSeek 開源的是研究原型，不是正式商業產品，也不是新的基礎模型。

官方爲 Super-agent 提出了四個目標特徵：Continuous（跨渠道上下文連續）、Productive（多任務並行）、Proactive（在授權範圍內主動響應事件）、Persistent（持續在線、可從部分異常中恢復）。這些是設計目標，不代表開源原型已全部實現。

爲什麼 AI Agent 不應該只有一個 Session

DeepSeek 團隊的判斷是：AI 編程工具的瓶頸正在從“模型能力”轉向“人類注意力”。根據團隊的日常觀察，一個人通常只能有效跟進約 3—5 個活躍 Agent Session。這是團隊經驗判斷，不是公開的大規模用戶統計，但它準確描述了很多開發者的真實體感。

單 Session 與多 Session 的兩難

常見的兩種做法各有硬傷，Router + Worker 正是爲了兼顧“全局上下文連續性”和“後臺並行處理能力”而提出的。

單 Session 的問題是“堵”，多 Session 的問題是“散”。前者讓一個上下文窗口承擔所有任務的中間步驟，後者把協調成本全部轉嫁給人。DeepSeek 的思路是在系統層面引入一個專門負責“記住全局”的角色，讓執行者專心執行。

Router + Worker 雙層架構如何工作

Router：只做協調的全局調度層

Router 是長期運行的邏輯層。在官方當前的架構探索中，它主要由一個常駐 LLM Session 實現，但概念上不必嚴格等同於一個模型會話。它的職責集中在“管”而不是“幹”：

• 統一接收用戶消息與 GitHub、IM、CI 等外部事件；
• 維護全局任務關聯，判斷是否需要建立新工作；
• 檢查授權並向 Worker 分配任務，處理跨任務協調；
• 彙總需要交付給人類的信息，必要時召回舊任務上下文。

一個很關鍵的細節是：官方認爲 Router 甚至可以不具備 Bash 工具。不讓 Router 親自執行復雜編程，就能避免它被長時間的工具調用阻塞。同時，Router 的任務往往不需要最強的推理模型，較輕量的模型有時就能滿足交互與分派需要，這爲“不同角色配置不同模型”提供了技術依據。

Worker：隔離執行的任務層

Worker 負責具體工作。在公開原型中，一個 Ticket 對應一個 Executor Session，每個 Ticket 擁有獨立的工作目錄。Worker 在授權範圍內修改代碼、運行測試、處理後續反饋，完成後形成 Report；需要人工決策時設置 Attention 狀態，結果通過原始渠道（例如 GitHub PR）交付。

不同 Worker 的模型上下文相互獨立，這解決了多任務中間步驟混雜在同一窗口的問題。但要注意，獨立 Session 與獨立目錄不等於強安全隔離。官方部署文檔說明，Worker 默認以操作者的操作系統用戶身份執行命令。

一個 GitHub Issue 如何走完 Router + Worker 流程

根據開源實現的 Domain Model，任務鏈路可以概括爲 Source → Trigger → Eval → Decision → Ticket → Assignment → Executor → Report。以“授權用戶在 GitHub Issue 中請求修復 Bug”爲例：

1. GitHub Source 收到 Issue 評論，產生 Trigger；
2. 系統先用確定性規則做權限過濾，再由模型判斷是否符合接單規則；
3. Router 接受任務並創建 Ticket，Ticket 中記錄任務範圍與授權（Mandate）；
4. 系統爲 Ticket 建立 Assignment，分配給對應 Worker；
5. Executor 在獨立目錄和獨立 Session 中執行修復；
6. Worker 彙報進度或提交結果，生成 PR；
7. 系統通過原始 Issue 或 PR 線程把結果交付給用戶。

如果用戶隨後在這個 PR 裏提出修改意見，新消息可以自動關聯到原任務。用戶不需要再翻找“當時是哪個 Agent 會話在處理這件事”，這正是雙層架構減輕人類管理負擔的具體體現。

Router + Worker 的 4 個關鍵設計

雙層架構本身只是骨架，真正讓它可用的是幾個針對性的工程設計。每個設計都對應一個具體問題：

Thread 訂閱直通：減少 Router 的重複分派

假設 Worker A 負責某個 PR，那麼這個 PR 的後續評論和 CI 結果可以按 Thread 歸屬直接交給 Worker A，Router 不必爲每條關聯消息重新決策。這是一個典型的“把高頻低價值決策從中心節點卸載”的設計。

但訂閱直通有明確的權限邊界。官方授權文檔寫明：訂閱消息可以提供上下文，不能擴大原 Ticket 的 Mandate。如果後續評論要求做授權範圍外的新工作，Worker 應交回系統重新評估。這一點對防範外部評論中的越權指令很重要。

Router 批處理：應對突發事件

當 Router 正在進行一輪推理時，新到達的 Trigger 會先積壓，下一輪作爲一個批次統一分析。這相當於把“每條消息一次模型調用”變成“每輪推理處理若干消息”，在事件密集時顯著攤薄單個決策的推理開銷。

Inline & Spill 與鏈式召回：把上下文當緩存

DeepSeek 把上下文窗口視作一種緩存。Inline 是把近期很可能用到的信息直接放進窗口，例如當前任務的最新評論、相關代碼行及必要的周邊代碼；Spill 是把不常用或過長的內容留在窗口外，只保留摘要、關聯 ID 和讀取入口，例如很長的歷史討論。不相關的歷史消息則不必每次注入。

在此基礎上延伸出 Chain of Recall（鏈式召回）：模型可以順着 Trigger → Thread → Ticket → Worker 的對象關聯，按需逐步找回歷史信息。這比“每次塞入完整歷史”更節省上下文，也更接近數據庫按索引查詢的思路。不過官方也承認，跨月乃至更長期的記憶仍是未解決的問題。

Router + Worker 實驗數據解讀

DeepSeek 做了一組初步的合成負載實驗。每次模擬運行約 300 條消息，其中約 20 條是工作請求，其餘是閒聊、後續反饋、取消請求和 CI 消息；每種方案運行 5 次。編程工作由耗時的模擬工具替代，所以這組數據衡量的是調度系統表現，不是代碼生成質量。

端到端調度對比

與中性提示的單會話方案相比，Super-agent 的 P50 完成時間降低約 39%，P95 降低約 47%。與優先委派的單會話方案相比，P50 只有小幅優勢，但 P95 長尾明顯更短。也就是說，雙層架構最大的收益在於讓最慢的那批任務不再拖很久。

代價同樣清楚：Super-agent 的緩存讀取量約爲中性單會話方案的 3.8 倍。它是用更多並行會話和推理資源換來更短、更穩定的完成時間。但這不等於總費用增加 3.8 倍，實際花費還取決於模型單價、緩存命中、普通輸入與輸出 Token、Router 與 Worker 的模型選擇以及工具調用。官方也尚未公佈真實工單的平均 API 花費。

訂閱直通的消融實驗也值得細看。移除訂閱直通後，Router 需要處理的決策數增加約 30%，緩存讀取 Token 增加約 37%，但完成時間幾乎不變。結論是：訂閱直通在該測試中主要節省 Router 的模型調用與上下文開銷，而不是直接提速。

Router 批處理壓力測試

這組測試中 Router 使用真實模型，Worker 使用模擬模型：

事件密度升高時，單次請求變慢了，但每個決策分攤的推理時間反而下降，說明批處理提高了有效吞吐。官方的結論很剋制：在當前團隊規模下單個 Router 暫時夠用，但這不能推斷爲一套 Router 可以無限處理消息。

Router + Worker 對開發者的影響

模型分層：Router 用輕量模型，Worker 按任務選模型

雙層架構最直接的工程啓示是：不同角色不必使用同一個模型。Router 的工作以分類、分派和摘要爲主，適合快速、低成本的模型；Worker 則根據任務複雜度選擇推理能力更強的模型。原型本身也支持爲 Router 和 Worker 分別指定模型提供方與模型。

下面是一個最小示意，用同一個 OpenAI 兼容接口讓 Router 做分派判斷：

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # API易 統一接口，一個 Key 切換多家模型
)

ROUTER_MODEL = "your-fast-cheap-model"   # 替換爲控制檯中可用的輕量模型名

resp = client.chat.completions.create(
    model=ROUTER_MODEL,
    messages=[{"role": "user", "content": "判斷這條 Issue 評論是否需要新建 Ticket:修復登錄頁 500 錯誤"}]
)
print(resp.choices[0].message.content)

import json
import openai
from typing import Dict

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

# 角色與模型分層:模型名請替換爲你實際可用的模型
ROLE_MODELS: Dict[str, str] = {
    "router": "your-fast-cheap-model",
    "worker_simple": "your-mid-tier-model",
    "worker_complex": "your-strong-reasoning-model",
}

usage_log = []  # 按 Ticket 記錄 Token 消耗

def call(role: str, ticket_id: str, prompt: str) -> str:
    resp = client.chat.completions.create(
        model=ROLE_MODELS[role],
        messages=[{"role": "user", "content": prompt}],
    )
    u = resp.usage
    usage_log.append({
        "ticket": ticket_id, "role": role,
        "input": u.prompt_tokens, "output": u.completion_tokens,
    })
    return resp.choices[0].message.content

def router_dispatch(ticket_id: str, event: str) -> str:
    prompt = (
        "你是任務調度器,只做分類,不執行任務。"
        "輸出 JSON:{\"accept\": bool, \"complexity\": \"simple\"|\"complex\"}\n"
        f"事件:{event}"
    )
    decision = json.loads(call("router", ticket_id, prompt))
    if not decision["accept"]:
        return "ignored"
    role = "worker_complex" if decision["complexity"] == "complex" else "worker_simple"
    return call(role, ticket_id, f"在授權範圍內處理任務:{event}")

print(router_dispatch("T-001", "CI 失敗:單元測試 test_login 超時"))
print(usage_log)

🎯 技術建議：搭建分層 Agent 時，建議先通過 API易 apiyi.com 用同一個 API Key 分別測試輕量模型與強推理模型在 Router、Worker 角色上的表現，再決定最終配置，避免給所有角色都使用最昂貴的模型。

成本控制：按 Ticket 記賬，而不是看總賬

官方實驗顯示雙層架構會消耗更多推理資源，因此成本管理必須更細。比較實用的做法包括：

• 按 Ticket 記錄 Token：區分 Router 決策開銷和 Worker 執行開銷，定位哪類任務最貴；
• 區分費用類型：模型費用、工具費用（如搜索、網頁獲取）和執行環境費用分開統計；
• 關注緩存命中：Super-agent 的 Token 大頭是緩存讀取，而緩存命中與未命中的單價差異可能很大，以 DeepSeek 官方價格爲例，兩者相差數十倍；
• 減少無效決策：借鑑訂閱直通思路，讓後續事件直達負責的 Worker，砍掉 Router 的重複分派。

💰 成本優化：多 Worker 並行意味着調用量會成倍增加。通過 API易 apiyi.com 按量計費調用多家模型，可以在同一賬單裏對比不同角色、不同模型的實際花費，更方便做分層成本優化。

什麼時候值得采用 Router + Worker

雙層架構不是越複雜越好。可以參考以下判斷：

• 適合採用：同時存在多個相互獨立的工作事項（如 Ticket A 修 Bug、Ticket B 審遷移、Ticket C 處理 CI），且事件來自多個渠道、需要持續在線響應；
• 可以暫緩：任務數量少、彼此強依賴，或主要是圍繞單個複雜任務分工，單 Agent 或傳統 Agent Team 更省資源；
• 需要先補基礎設施：權限隔離、文件修改衝突處理、按任務計費日誌還沒就緒時，貿然並行反而放大風險。

還要注意，Router + Worker 和普通 Agent Team 的側重點不同。普通 Agent Team 往往把一個複雜任務拆成研究、編碼、測試等角色；Super-agent 的 Router 更強調在多個獨立事項之間協調，而不深入每項任務的技術細節。官方也說明，如果普通 Agent Team 的主會話只做統一交互與跨任務分派，同樣能形成類似結構，雙層架構並不是 DeepSeek 獨佔的概念。

Router + Worker 架構的侷限與原型邊界

寫這類架構解析，最容易犯的錯誤是把設計文章裏的完整藍圖當成開源原型的現有功能。按資料嚴格區分：

• 原型已支持：監聽單個 GitHub 倉庫、可選飛書接入、Ticket 管理、獨立 Worker 會話與目錄、生成 PR、管理面板展示待人工處理任務、按後續消息繼續工作；
• 設計中但未證明完整實現：多倉庫自動管理、生產級雲端持續運行與跨設備環境、完整的獨立 Watchdog 自治修復；異步 ReAct Loop 已在 Harness 中實現但尚未默認啓用；
• 主動性有邊界：推斷出的工作默認使用 observe 模式，只記錄不執行；PR 自動合併默認關閉。

架構層面仍有幾個公開承認的難題。第一是單 Router 擴展，官方只說當前團隊規模下夠用，更大規模如何分片尚無答案。第二是長期記憶，Inline & Spill 和鏈式召回解決了中短期上下文，跨月記憶仍未解決。第三是權限邊界，Router 與 Worker 的預設運行在 danger-full-access 模式，默認以操作者系統用戶身份執行，官方建議使用獨立系統用戶；外部評論帶來的 Prompt Injection、憑證管理也列在待解決問題中。社區還出現過針對特定 commit 的第三方源碼審計報告，但完整攻擊過程未被獨立復現，只能視爲潛在風險。

社區實測也印證了“原型”定位：有用戶按 SETUP.md 從全新克隆成功跑通了 Issue 到 PR 的端到端流程，同時也報告了 Node.js 24 進程識別、GitHub 通知延遲漏消息、中文系統語言導致測試斷言失敗等問題。

常見問題 FAQ

Router + Worker 核心要點 Key Takeaways

• 核心定位：Super-agent 是模型之外的系統架構，開源的是研究原型而非商業產品；
• 問題本質：瓶頸從模型能力轉向人類注意力，單 Session 會“堵”，多 Session 會“散”；
• 職責分離：Router 只做全局協調甚至不配 Bash，Worker 在隔離會話中獨立執行；
• 關鍵機制：訂閱直通卸載 Router 決策，批處理攤薄推理開銷，Inline & Spill 把上下文當緩存；
• 數據邊界：調度實驗顯示長尾完成時間更短，但 Token 消耗更高，且不代表編碼能力；
• 上手方式：可藉助 API易 apiyi.com 統一接口爲不同角色配置不同模型，按 Ticket 管理成本。

總結

DeepSeek 用 Router + Worker 回答了“AI Agent 爲什麼不應該只有一個 Session”：

1. 架構價值：把全局協調與獨立執行拆開，讓系統記住任務關係，而不是讓人記住；
2. 工程設計：訂閱直通、批處理、Inline & Spill 和鏈式召回，分別對應中心負載、突發吞吐、上下文容量和歷史召回問題；
3. 理性看待：實驗證明的是調度效率與資源開銷的權衡，單 Router 擴展、長期記憶和權限隔離仍待解決。

如果你的系統已經需要同時處理多個獨立事項，雙層架構值得借鑑；如果任務少而集中，單 Agent 依然是更經濟的選擇。無論採用哪種結構，模型分層和按任務記賬都是控制成本的關鍵。

推薦通過 API易 apiyi.com 快速驗證不同模型在 Router 與 Worker 角色上的效果，平臺提供 OpenAI 兼容接口、按量計費和新用戶免費測試額度。

📚 參考資料

1. DeepSeek 官方架構文章：Super-agent 設計探索：邁向更自主的 Agent 系統
2. 鏈接： x.com/DeepSeekHarness/article/2116857257245987236

3. 說明： 雙層架構、五大模塊、實驗數據與未解決問題的一手來源

4. DeepSeek 官方 GitHub 倉庫：dsh-superagent-prototype

5. 鏈接： github.com/deepseek-ai/dsh-superagent-prototype

6. 說明： 項目狀態、源碼、協議與當前適用範圍

7. 開源 Domain Model 文檔：任務對象與流轉模型

8. 鏈接： github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/001-domain.md

9. 說明： Source、Trigger、Ticket、Assignment 等核心概念定義

10. 授權與訂閱文檔：Mandate 與 Thread 訂閱規則

11. 鏈接： github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/002-authorization.md

12. 說明： 訂閱消息不能擴大授權範圍的官方說明

13. 部署文檔：依賴、賬號與安全提示

14. 鏈接： github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/006-deployment.md

15. 說明： 高權限運行模式與獨立系統用戶建議

16. DeepSeek API 官方定價：模型與工具價格

17. 鏈接： api-docs.deepseek.com/quick_start/pricing
18. 說明： 緩存命中與未命中價格差異，成本估算參考

作者: APIYI 技術團隊
技術交流: 歡迎在 API易 apiyi.com 網站首頁聯繫我們交流 Agent 架構與多模型調用實踐，更多資料可訪問 docs.apiyi.com 文檔中心

延伸閱讀

• 一個人最多盯 5 個會話？拆解 DeepSeek 超級智能體五大模塊:解讀 DeepSeek Harness 團隊的超級智能體（Super-agent）架構文章：五大模塊、實驗條件與數據、四個開放問題、小團隊落地清單，以及 Router 與 Worker 的模型搭配和成本估算。