DeepSeek又開源了！公佈Super agent架構

作者 | 李水青 編輯 | 心緣 11月1日報道，10月31日晚間，DeepSeek Harness團隊公佈了其關於自主Agent探索——Super-agent（超級智能體）的底層架構。▲Super-agent開源項目地址 GitHub地址： https://github.com/deepseek-ai/dsh-superagent-prototype DeepSeek想做的“Super-agent”，可以通俗理解為一個一直在線、能同時幹多件事、會主動找活幹、出問題能自己恢復的Agent。

該團隊本次推出的成果並非一款新產品，而是更接近一種新思路——把計算機系統裡的調度、緩存、存算分離、看門狗（Watchdog）等經典思想搬進Agent架構。隨著模型執行單任務減少人工干預，瓶頸轉向人的注意力。DeepSeek Harness試圖通過五大模塊——雙層架構、事件驅動、異步多信道交互、存算分離與外部Watchdog在底層接管會話管理與上下文同步，使人上移到決策與驗收，提升Agent應用體驗。▲Super-agent整體系統架構 實驗上，基於該思路的Super-agent任務有一半任務12.4分鐘內完成，95%的任務15.

7分鐘內完成，顯著優於帶Subagent工具的單Session（會話）；去掉訂閱直通後，Router決定數增加約30%，讀緩存token從2323萬增到3177萬；Router批處理能把單個決定分攤的推理時間從6.4秒降到1.6秒。這組數據意味著Super-agent在初步實驗中證明了“系統層接管會話調度”的可行性。一方面，多任務完成更快更穩，Router靠直通省開銷、靠批處理扛突發；但另一方面，它是拿更多token來換取時間和穩定性，而且實驗基於合成負載與簡化環境，只是初步參考，不是正式產品結論。

一、Super-agent：不用切會話，一個Agent並行推進多任務 過去一年，Coding Agent等單任務Agent已證明模型能用工具解決複雜問題，人越來越少介入底層執行，角色上移到決策與驗收。個人助手等持續在線、事件驅動的新形態開始湧現。但現有Agent以單一Session為單位，多任務上限受人的注意力限制，簡單擴展仍受同步阻塞、上下文混亂、設備離線即停等制約。因此，DeepSeek Harness團隊提出Super-agent：跨會話保持上下文、並行推進多任務且互不干擾的連續實體，並且已有內部實例在IM與GitHub間連續推進任務。

▲同一個任務在 IM 群聊與 GitHub Pull Request 評審之間連續推進 ▲持續關注公共群聊，在無人@的情況下主動識別缺陷並提交修復Pull Request 團隊認為，Super-agent具備四個基礎特徵： – 連續：用戶可以直接在IM聊天、GitHub評論等熟悉界面與它交互，感覺始終只存在一個Agent，不需要去想“Session X的上下文中是否有Y信息”。例如用戶先在IM提出採用方案A，隨後在GitHub PR評論裡改為方案B，它能理解並調整執行方向。– 高效：交互響應迅速，同時能並行、高質量完成多個複雜任務。無需等上一個命令或任務完成，就能接受下一條指令。

– 主動：無需等待用戶逐條下達指令，能持續觀察環境事件並主動推進值得處理的事項，不需要介入時保持安靜。– 持久：始終在線、直接接入用戶真實工作環境，並在長期運行中遇到異常時自動恢復。單個ReAct Loop無法同時支持上述四個特徵，底層需要一套相應架構。文章認為，相似設計約束會導出相似架構選擇。無論是個人助手，還是軟件開發等商業場景的Agent，如果目標是構建持續在線、併發響應環境事件的系統，底層可能採用相近架構。這一過程中面臨的許多問題與傳統計算機系統長期探討的問題高度相似，因此計算機系統中的經典設計思想同樣適用。

具體落地會有不同變體，但文章認為五個模塊構成支撐上述四個特徵的基本框架：通過雙層架構兼顧連續交互與高效併發，通過事件驅動實現主動響應，通過面向人的交互在交互過程中同時做到連續與高效，並通過計算、狀態與環境分離及Watchdog實現跨設備持久在線與異常自愈。二、雙層架構：連續與吞吐不必二選一，一層分派、一層幹活 跨信道連續交互與多任務高效併發存在根本權衡：全交給一個Session，上下文最連續，但單ReAct Loop串行、吞吐低、細節混雜；全開獨立Session，吞吐最高，但缺全局上下文、結果割裂、交互混亂。

DeepSeek Harness團隊的解法是把“維護全局連續性”與“高併發執行”拆成兩層：常駐Router層承接人類交互與全局協調，上下文隔離的Worker層併發執行具體任務。Session應成為系統實現細節，而非用戶認知負擔。▲雙層架構：Router層統一負責路由與對外交互，多個Worker Session隔離併發執行任務 1、Router層：只分派不幹活，靠批處理攤薄成本 Router層是常駐的全局路由層，負責承接所有入口的人類交互。所有跨任務的信息與決策都在Router層彙總，由它充當全局序點、協調點和記憶。

為避免這一全局節點成為性能瓶頸，Router層在設計上不直接執行具體任務，只負責人類交互與任務分派，甚至可以不配備Bash工具。這種由一箇中心節點分派多個執行節點的結構，表面上與常見Agent Team相似，但側重點不同。常見Agent Team主要用於單個複雜任務內部的步驟拆解與角色協作，子步驟通常耦合較緊，Team Lead往往需要深入理解任務細節、規劃子任務並高頻協調成員，自身承擔很重推理負載。而在Super-agent中，Router層只處理任務之間的高層關聯與分派，無需介入單任務內部拆解。

相反，如果通過提示詞約束一個Agent Team的主會話不親自執行具體任務，僅負責對外交互並將不同任務分派給各成員獨立推進，也可以視為這種雙層架構。團隊實踐顯示，Router層任務常常沒有想象中複雜，使用較輕量模型往往就能兼顧速度與效果。內部實現上，Router層同樣不必侷限於單個Session，甚至部分邏輯未必需要調用LLM。

團隊選擇最直接的單個常駐LLM Session作為Router層核心實現，並發現它並沒有表面看起來那麼容易成為吞吐瓶頸，因為上一輪推理期間到達的環境事件會積壓下來、在下一輪一併處理，形成批處理，而合併處理的額外開銷很小： – 外部事件流平穩時，Trigger逐條進入Router Session，單次響應延遲較低； – 事件密集湧入、Router Session出現排隊擁堵時，上一輪推理期間積壓的多條Trigger會自動合併，在下一次LLM調用中一併注入。Router Session只做輕量交互與分派，每步通常是長輸入、短輸出。

把積壓多條Trigger合併進一次LLM API調用，會在Prefill階段並行計算，單次請求耗時增長遠慢於批處理大小。因此在一定範圍內，積壓越多，單個決定分攤的推理時間越低；上限取決於上下文長度，以及模型在一輪中能準確處理多少條Trigger。文章在後文通過實驗定量展示批處理機制效果。加上訂閱與直通機制以及鏈式召回，單個常駐Router Session在保持上下文連續的同時，在目前團隊規模下已經夠用。當規模進一步擴大、單個會話確實不足以承載時，Router層內部也可設計為多層過濾結構，或水平切分為多個會話。此時Router層內部設計本質上是連續性與吞吐量的權衡。

切分粒度越細，Router層併發吞吐量越高，但分片之間的記憶與上下文連續性越低。在全局記憶問題被解決前，這一權衡始終存在。2、Worker層：只幹活不搶話，衝突靠訂閱同一Thread自己發現 Worker層由負責具體執行的會話組成，各Worker彼此上下文隔離，掛載完整執行工具，在獨立上下文中專注完成單一任務。由於Worker Session直接決定任務結果與代碼質量，通常需要配置能力最強的模型。Worker不會直接與人類交互，其推理過程和工具調用不會直接輸出到外部信道，而是向Router層彙報狀態，由Router層統一向用戶回覆，從而在保障併發度與交付質量的同時避免多個會話各自回覆帶來混亂。

多任務併發執行時，各Worker獨立推進任務，同層Worker之間通常不需要直接通信。多個Worker在具體執行中的衝突往往出現在同一個Pull Request等共享工作環境中；只要它們都訂閱了對應Thread，就會收到相同事件通知，從而有機會自行發現和解決衝突，少數跨任務協同則由Router層中轉。與Router層類似，每個Worker Session內部也不必侷限於單個會話：執行復雜單任務時，Worker內部可再創建Subagent，也可本身就是一個Agent Team，這些對上層的Router層保持透明。

這一結構既適用於代碼協作場景，同時推進多個獨立問題復現、PR評審與特性開發而互不阻塞；也適用於個人助手場景：雖然個人助手界面上通常只提供一個單會話聊天頁面，但當用戶在同一對話框同時討論多個不同話題時，前端單一聊天頁負責維持交互連續性，底層可為每個話題分別分派Worker，並行推進任務、起草回覆。三、事件驅動：不等指令，環境事件當輸入，四步讓Agent主動幹活 要讓Super-agent具備主動性，首先需要改變系統驅動方式。驅動Agent的主要輸入不再是人類在Session中逐條鍵入的提示詞，而是環境中的半結構化事件。

在Super-agent中，群聊消息、郵件與日程提醒、代碼審查評論、CI運行結果等環境事件被稱為Trigger。通過監聽並響應Trigger，Agent不必再像單Session模式下那樣，等人類下達指令才被動執行一次。圍繞一條環境事件從進入到處理的生命週期，文章依次討論四個遞進問題：如何通過程序與模型結合的兩級策略過濾大量噪音；如何通過訂閱與直通機制將事件路由給Worker；如何利用Inline & Spill與鏈式召回向模型高密度注入與按需召回上下文；如何利用投機執行根據環境信號在後臺提前行動。

1、 事件過濾：程序先快篩，模型再慢判 接入真實群聊與代碼平臺後，環境事件流呈現顯著“高噪音、低觸發率”特徵，絕大多數日常消息並不需要Agent介入。如果對每個事件都調用大模型從頭判斷，延遲和算力成本都難以承受。借鑑計算機系統中的Fast Path / Slow Path思想，大模型推理可看作靈活但高成本的Slow Path，而將已經明確且穩定的高頻判斷固化為確定性代碼，則構成低延遲、低成本的Fast Path。因此，事件進入系統後的第一步是過濾，目標是在調用大模型之前先用確定性策略篩除噪音，只將需要語義理解的候選事件交給模型判斷。

團隊採用程序策略與大模型相結合的兩級過濾機制： – 程序層策略，作為Fast Path：針對事件來源、群組範圍、用戶或機器人白名單等確定性條件，直接通過代碼進行快速准入檢查，例如對不同來源分別設置“僅響應明確請求”“作為候選事件”或“直接忽略”，在調用模型前濾除大部分無關消息。– 語義層策略，作為Slow Path：通過程序層准入的候選事件交給LLM，由它根據用提示詞編寫的策略和上下文判斷是否需要行動。語義層同時作為面向人類的自然語言擴展點，方便隨時通過提示詞開關或新增策略。

▲兩級過濾：先由程序層策略篩除大部分無關消息，再交由語義層策略判斷 2、事件路由：後續事件不再繞Router，訂閱了就直接發Worker 第2節引入的全局Router層負責維持跨信道連續性，但如果已分配任務的每個後續事件仍需經由Router層轉發，這一全局節點依然會承受大量負載，推高系統響應延遲。因此，Fast / Slow Path同樣適用於過濾後的事件路由。全局Router層僅負責新任務冷啟動與跨任務協調，已確定歸屬關係的後續事件由程序直接發往對應Worker會話，無需經由Router層轉發。

實際工作流中，同一個GitHub PR、同一個IM話題或同一封往來郵件串下的連續事件構成一條事件流，即Thread。▲Thread示例：同一個IM話題或同一個GitHub Pull Request下的連續Trigger構成一條Thread Router層根據某個Thread的初始事件創建Worker Session後，該Worker會直接訂閱對應Thread，從而將事件路由分為兩條路徑： – 已訂閱，Fast Path：同一Thread下後續事件由程序直通已訂閱Worker，無需Router層再次調用工具轉發。若新事件超出當前任務範圍，Worker也可取消訂閱或交回Router層重新分派。

– 未訂閱，Slow Path：Router層仍可觀測所有事件以掌握全局狀態，但僅負責判斷和分派尚未被訂閱的新事件。▲訂閱與直通：初始事件經由 Router 層創建 Worker 並建立訂閱，同一 Thread 的後續事件直接發往該 Worker 此外，Thread與Worker之間的訂閱是多對多關係。一個Worker可同時訂閱多個相關Thread，同一個Thread也可被多個Worker訂閱。當多個Worker在同一個工作環境或討論中發生交集時，該Thread下新事件會同時直通給所有訂閱它的Worker，使它們無需點對點通信，也有機會獲知彼此操作並自行解決衝突。

在輸出側，Worker仍將關鍵結論彙報給Router層，由Router層統一向用戶回覆並同步全局記憶。3、上下文組織：常用直接放，長文先摘要，舊任務順ID找 事件經過過濾與路由、進入目標Session後，下一個問題是應向模型上下文窗口注入多少信息。由於系統輸入從有限人類提示詞轉向環境持續產生的半結構化事件，工具調用與事件注入的結構設計變得更加重要。注入過多會擠佔窗口、稀釋模型注意力，注入過少又會迫使模型反覆調用工具讀取，增加執行步數。文章直言：浪費上下文窗口，就是浪費模型的智能。為此，可將有限上下文窗口當作Cache管理。借用編譯優化與計算機系統概念，上下文注入設計可歸納為兩個基本操作。

Inline是指將近期很可能用到的信息直接內聯進當前上下文窗口，以省去額外工具調用往返。Spill則是指將超出窗口預算或低頻使用的完整信息留在上下文窗口之外，僅在窗口內保留引用或摘要，供模型按需讀取。結合計算機系統設計中經典的局部性思想，可用Inline & Spill對事件注入和工具調用逐步優化： – 從最少信息開始：最初只提供當前對象ID和內容摘要。– 利用局部性逐步Inline關聯信息：將近期很可能用到的信息Inline到上下文中，先附上緊密關聯對象ID，再附帶時空相鄰內容，例如內容前50字、IM消息前後相鄰消息與所回覆消息，或代碼評論所在評審討論中的相鄰評論。

– 超出上限則Spill：對無法全部Inline的長內容設定較小長度上限，將超出部分Spill到窗口之外。一種簡單直接做法是截斷超出部分並保留續讀入口，模型需要完整內容時再調用工具讀取。此外，在大量後續事件直通Worker、系統長期運行累積許多歷史任務後，Router層既不能把所有任務全量歷史都放入自己的上下文窗口，又需要在用戶跨信道提起某個舊任務時找回上下文。將Inline & Spill一致應用到系統中各類對象後，就得到一種按需展開的多跳檢索機制，即鏈式召回。這種鏈式召回緩解了Router層在長程中丟失先前信息的問題。

▲鏈式召回：每次召回的對象均內聯下一跳關聯對象的ID，支持沿引用關係逐跳展開上下文 具體來說，系統為Trigger、Thread和Worker Session等對象賦予唯一ID，並在注入時內聯緊密關聯對象ID，使這些對象在底層構成一張引用圖。由於每一次調用工具召回的對象本身同樣遵循Inline & Spill，其返回結果中又會內聯下一跳關聯對象的摘要與ID，模型便可以從當前事件出發，順著引用關係逐步按需召回上下文。例如從一條當前消息讀取所在Thread，再從Thread內聯ID追蹤到相關Worker Session，進而找到該Worker關聯的另一個代碼評審Thread。

4、提前行動：後臺提前試，有價值才交付 借鑑計算機系統中的投機執行思想，Agent可以在還不確定結果是否會被採用時，根據環境信號在後臺提前嘗試，通過消耗額外後臺算力減少人類等待與介入成本。結果有價值就交付，沒有價值就丟棄。在個人助手場景下，收到一封會議邀約郵件或待辦消息時，Agent可先在後臺核對日程衝突、蒐集相關背景資料並備好回覆草稿，待用戶過目後直接確認發出。在研發協作場景下同樣如此。

例如團隊在DeepSeek Harness內部用戶群中配置了一條“靜默復現並修復”策略：當群裡有人反饋問題或討論改動方案時，Agent先在後臺嘗試復現並尋找修復方案，只有在確認問題並找到簡單修復方案後，才把結果交付給用戶，否則全程保持安靜。▲投機執行示例：群內還在討論解決方案時，Super-agent已在後臺提交了修復Pull Request 四、 面向人的交互：全雙工隨時接新指令，多信道按人的習慣說話 雙層架構保證了跨信道上下文連續，但實際交互體驗還需解決兩點：用異步ReAct Loop讓後臺耗時操作不阻塞前臺，會話隨時接受新指令；讓輸出方式匹配不同信道的帶寬與人的使用習慣。

1、全雙工交互：後臺幹活，前臺不卡，新指令隨時進 經典ReAct Loop中，模型發起一次同步的run()工具調用後，循環會阻塞，直到工具執行完畢並返回最終結果，在此期間會話無法響應任何新的用戶輸入。要消除這一阻塞，需要將對話從一問一答的半雙工模式轉變為全雙工模式。▲經典ReAct Loop與異步ReAct Loop對比 為此，團隊將耗時命令與子任務工具調用改為異步的start()和stop()，構成異步ReAct Loop。

模型調用start()後立即收到“已啟動”返回，循環不再等待該工具；後臺工具執行完成後，系統再將最終結果作為一條新事件消息投遞進會話；同時，模型也可根據上下文調用stop()主動終止執行時間過長的後臺命令。由此，前臺對話響應與後臺任務執行得以解耦，Agent在後臺運行耗時任務的同時也能響應人類輸入。新輸入在當前推理步結束後即被處理，不必等待後臺工具完成。文章透露，這一異步任務機制已在DeepSeek Harness中實現，但尚未默認開啟。2、多信道交互：群聊低打擾短回覆，PR郵件高密度寫完整 不同工作信道具有不同信息密度與交互習慣，系統輸出需要與之匹配。

如果將面向單人終端的交互方式直接搬入群聊，把冗長推理過程與密集工具調用原樣輸出，在多人協作中極易造成信息過載。在Super-agent中，雙層架構已解決其中一部分問題：具體任務中冗長推理過程和密集工具調用都被隔離在Worker Session內部，不會直接輸出到外部信道，而由Router層統一負責對外交互。在此基礎上，系統還需接入用戶日常使用的各類工作環境，並通過提示詞針對不同信道定製交互規範： – IM等即時通訊信道：側重低打擾的輕量溝通，像人類同事一樣只在需要決策或驗收時發送通知，只問直接問題、給簡短結論。團隊驗證過一條簡單有效的硬性規定：單次回覆不超過100詞。

– GitHub、郵件與文檔等異步信道：側重結構化、高信息密度的異步交付，例如創建或更