DeepSeek Super Agent 是什麼?Router/Worker 架構與主動式 Agent 全解析
2026 年 10 月 31 日,DeepSeek Harness 團隊發表 Super Agent 設計探索文章並在 GitHub 開源原型 dsh-superagent-prototype,核心主張是 agent 工作流的瓶頸是人類注意力(一人同時跟進 3 到 5 個 session),而非模型能力
目錄

重點摘要
- 2026 年 10 月 31 日,DeepSeek Harness 團隊發表 Super Agent 設計探索文章並在 GitHub 開源原型 dsh-superagent-prototype,核心主張是 agent 工作流的瓶頸是人類注意力(一人同時跟進 3 到 5 個 session),而非模型能力
- Super Agent 採 Router/Worker 雙層架構:Router 只決定「這活推給誰」,Worker 之間上下文隔離,靠訂閱同一 Thread 感知衝突;後續相關訊息可直達對應 Worker,不必再過 Router 轉達
- 兩道事件過濾(規則篩網 + 模型語義判斷)讓系統在不讓所有訊息都過模型的前提下識別真正需要觸發的任務訊號;第二道策略用自然語言描述,改策略只需改提示詞
DeepSeek Harness 團隊(下稱 DSH)在 2026 年 10 月 31 日晚間發表文章《Super-agent 設計探索:邁向更自主的 Agent 系統》,同時在 GitHub 開源了原型實作 dsh-superagent-prototype。這篇文章的出發點不是「怎麼讓模型更聰明」,而是翻了個方向問:就算模型夠強,真正的瓶頸在哪?DSH 的觀察是,一個人同時能跟進的活躍 agent session 大概只有 3 到 5 個,超過這個數字就顧不過來。問題不在模型能力,而是人類注意力本身就有上限。Super Agent 要解的,就是這個上限。
Super Agent 的核心不在於提升模型的單點智力,而是透過 Router/Worker 雙層架構解開人類的注意力瓶頸,實現主動卻不刷存在感的協作運作。
Super Agent 是什麼,跟普通 agent 差在哪?
普通 agent 是單一 session 的處理器:一次任務、一個 session、完成就結束。下次叫它,從零開始,上一次的結論、跑了一半的調查全部不見。更根本的問題是,多個 agent 同時運作時,全局脈絡只有你自己知道,因為 session 之間不通。A agent 在 B session 裡發現了什麼、C session 的任務走到哪一步,都要你自己記。這個記憶負擔最後還是壓在人身上,把人變成所有 agent 之間唯一的中繼站。
Super Agent 的設計目標是讓 agent 承擔這個記憶和追蹤負擔。DSH 的定義是跨 session、跨平台持續運作、能主動響應環境變化的 agent。「持續」意味著它不在每次對話結束後重置;「跨平台」意味著同一件事可以從群組聊天跑到 Email 再到 GitHub,agent 能接上繼續;「主動」是核心,條件符合就自己啟動,不等指令。DSH 文章中展示了從群聊切換到 GitHub 繼續推進任務的內部示例,但這些是特定部署情境下的案例,能否通用到任意架構,視實作而定。
Router/Worker 雙層架構怎麼分工?
Super Agent 用兩個角色解開「讓單個 agent 同時幹所有事」的問題。讓一個 agent 同時修 bug、寫報告、回訊息,速度會拖慢,不同任務的細節也容易混在一起,輸出品質下降。DSH 的做法是拆開角色。
Router 是派任者,不是執行者。它理解需求、判斷任務屬性,決定派給哪個 Worker,不親自進到任務細節裡。每個 Worker 在獨立的上下文空間執行,修 bug 的只帶 bug 相關背景,寫報告的只帶報告需要的脈絡,彼此不互相污染。DSH 文章特別提到,不同 Worker 的溝通風格不一樣,有些好對話、有些難對話,而 Router 作為統一對口,讓使用者只需要跟 Router 說清楚需求,不必逐一跟每個 Worker 交手。
Worker 之間只要訂閱同一個 Thread 就能感知衝突,不用靠 Router 主動協調,這讓 Router 的推理負擔保持在最低。任務派出之後,後續相關訊息也不必再繞回 Router,而是直達負責的 Worker。DSH 打了個比方:維修師傅接單之後,你直接找師傅說問題,不用再讓客服轉一遍。這個直通訂閱機制減少了中間環節的延遲,多個 Worker 可以同時跑,彼此不互相等待。
主動性從哪來?兩道過濾與後台執行
Super Agent 的「主動」,機制上是觀察工作環境裡的所有訊號,將符合條件的訊號轉為任務觸發器。問題是,群組聊天裡大部分都是閒聊,讓模型讀每一條訊息既慢又貴。DSH 的做法是兩道篩網串聯。
第一道是規則層:預先設定哪些管道的訊息才算數、哪些來源直接跳過,計算成本接近零。通過第一道的訊息進入第二道,讓模型判斷:這句話是隨口吐槽,還是真的有一件需要處理的事?語義判斷規則沒辦法寫,只有模型能做。第二道策略用自然語言描述,想改規則只需改提示詞,不必動程式碼,策略調整的門檻低。
兩道都過了,Router 才正式派任。DSH 文章展示了一個內部示例:群聊裡有人說「這個專案有 bug」,沒有人 @ agent,但這句話通過兩道過濾、符合事先設定的「靜默復現並修復」策略,Router 就派了一個 Worker 去處理。Worker 沒有復現出問題或發現修復複雜,就保持安靜;確認問題且找到簡單方案,才提交 PR 等待人工驗收。這是 DSH 文章裡的部署案例,不是通用保證。
DSH 文章還提到 Super Agent 會把工作放到後台執行。
Anthropic 推出的 Claude Duet 目前仍在預覽版,走的是相近的主動範式:主動讀 Email 和日曆,早上提供簡報,有重要事情才來通知使用者。兩者的共同立場是 agent 不應該只等指令,但 Claude Duet 的觸發面目前看來集中在個人助理情境,Super Agent 的架構設計看起來更偏向橫跨多個協作工具的場景,兩者服務的場景目前看來並不完全重疊。
跟「主 agent 帶子 agent」架構差在哪?
表面上看,Router 加 Worker 和「主 agent 帶子 agent」很像,但兩者分配推理負擔的方式完全不同。
在傳統「主 agent 帶子 agent」的架構下,主 agent 得深入理解任務細節、拆解子任務,還要高頻協調各子 agent 的進度,推理負擔既集中又沉重。子 agent 每一步都得跟主 agent 緊密連動,主 agent 必須頻繁介入,整體流程才跑得下去。Anthropic 自己的《構建 Agent》一文也指出,堆疊子 agent 的整體效率不見得比單一 agent 高,耦合成本正是背後的主因。
Router 的設計刻意迴避了這個負擔。Router 只問「這活推給誰」,不做深度任務理解,不規劃細節,不高頻介入。Worker 之間上下文隔離,靠訂閱同一個 Thread 感知彼此進展和衝突,不需要 Router 持續協調,這讓 Router 保持輕量,不會成為整個系統的推理瓶頸。代價是,複雜的任務依賴關係需要在 Thread 設計和任務拆分策略上事先處理好,Router「只管派任」的邊界如果設計得不夠清楚,衝突感知能否完整覆蓋所有邊界情況,目前看來仍是需要實際部署驗證的問題。
Super Agent 試圖突破的終極瓶頸,不是把模型變更聰明,而是即使一個人只能同時跟進 3 到 5 個 session,整個工作流依然能順暢推進。DSH 特別強調的設計哲學是主動但不刷存在感,系統知道何時出手,更知道何時閉嘴。這個拿捏,目前看來比「夠不夠主動」更難設計,也會是 dsh-superagent-prototype 從原型走向真實部署時最關鍵的驗驗點。
常見問題
Super Agent 的「主動」是否代表系統會頻繁打擾使用者?
不一定。DSH 的設計哲學是主動但不刷存在感,系統只在兩道事件過濾都通過、且符合預設策略時才啟動任務。Worker 如果沒有復現出問題,或判斷修復複雜,就保持安靜,不主動回報;只有有明確結果的情況才提交 PR 等待人工驗收。
Router 和傳統主 agent 最大的差別是什麼?
主 agent 要深入理解任務細節並高頻協調子 agent,推理負擔重、耦合緊;Router 只決定「這活推給誰」,不做深度任務規劃,Worker 之間靠訂閱同一 Thread 感知衝突,不需要 Router 持續介入。這讓 Router 保持輕量,不會成為系統的推理瓶頸。
dsh-superagent-prototype 是生產可用的工具嗎?
目前定位是開源原型,供開發者參考架構設計。作為原型,距離生產環境部署仍有距離,具體能力與限制需參考 GitHub 上的說明文件。
標籤



