剛剛，DeepSeek把超級智能體“秘籍”公開了。
智東西11月1日報導，10月31日晚間，DeepSeek Harness團隊公佈了其關於自主Agent探索——Super-agent（超級智能體）的底層架構。
GitHub地址：
https://github.com/deepseek-ai/dsh-superagent-prototype
DeepSeek想做的“Super-agent”，可以通俗理解為一個一直線上、能同時干多件事、會主動找活幹、出問題能自己恢復的Agent。該團隊本次推出的成果並非一款新產品，而是更接近一種新思路——把電腦系統裡的調度、快取、存算分離、看門狗（Watchdog）等經典思想搬進Agent架構。
隨著模型執行單任務減少人工干預，瓶頸轉向人的注意力。DeepSeek Harness試圖通過五大模組——雙層架構、事件驅動、非同步多通道互動、存算分離與外部Watchdog在底層接管會話管理與上下文同步，使人上移到決策與驗收，提升Agent應用體驗。
實驗上，基於該思路的Super-agent任務有一半任務12.4分鐘內完成，95%的任務15.7分鐘內完成，顯著優於帶Subagent工具的單Session（會話）；去掉訂閱直通後，Router決定數增加約30%，讀快取token從2323萬增到3177萬；Router批處理能把單個決定分攤的推理時間從6.4秒降到1.6秒。
這組資料意味著Super-agent在初步實驗中證明了“系統層接管會話調度”的可行性。
一方面，多工完成更快更穩，Router靠直通省開銷、靠批處理扛突發；但另一方面，它是拿更多token來換取時間和穩定性，而且實驗基於合成負載與簡化環境，只是初步參考，不是正式產品結論。
01.
Super-agent：不用切會話
一個Agent平行推進多工
過去一年，Coding Agent等單任務Agent已證明模型能用工具解決複雜問題，人越來越少介入底層執行，角色上移到決策與驗收。個人助手等持續線上、事件驅動的新形態開始湧現。
但現有Agent以單一Session為單位，多工上限受人的注意力限制，簡單擴展仍受同步阻塞、上下文混亂、裝置離線即停等制約。
因此，DeepSeek Harness團隊提出Super-agent：跨會話保持上下文、平行推進多工且互不干擾的連續實體，並且已有內部實例在IM與GitHub間連續推進任務。
團隊認為，Super-agent具備四個基礎特徵：
- 連續：使用者可以直接在IM聊天、GitHub評論等熟悉介面與它互動，感覺始終只存在一個Agent，不需要去想“Session X的上下文中是否有Y資訊”。例如使用者先在IM提出採用方案A，隨後在GitHub PR評論裡改為方案B，它能理解並調整執行方向。
- 高效：互動響應迅速，同時能平行、高品質完成多個複雜任務。無需等上一個命令或任務完成，就能接受下一條指令。
- 主動：無需等待使用者逐條下達指令，能持續觀察環境事件並主動推進值得處理的事項，不需要介入時保持安靜。
- 持久：始終線上、直接接入使用者真實工作環境，並在長期運行中遇到異常時自動恢復。
單個ReAct Loop無法同時支援上述四個特徵，底層需要一套相應架構。文章認為，相似設計約束會匯出相似架構選擇。無論是個人助手，還是軟體開發等商業場景的Agent，如果目標是建構持續線上、並行響應環境事件的系統，底層可能採用相近架構。這一過程中面臨的許多問題與傳統電腦系統長期探討的問題高度相似，因此電腦系統中的經典設計思想同樣適用。
具體落地會有不同變體，但文章認為五個模組構成支撐上述四個特徵的基本框架：通過雙層架構兼顧連續互動與高效並行，通過事件驅動實現主動響應，通過面向人的互動在互動過程中同時做到連續與高效，並通過計算、狀態與環境分離及Watchdog實現跨裝置持久線上與異常自癒。
02.
雙層架構：連續與吞吐不必二選一
一層分派、一層幹活
跨通道連續互動與多工高效並行存在根本權衡：全交給一個Session，上下文最連續，但單ReAct Loop序列、吞吐低、細節混雜；全開獨立Session，吞吐最高，但缺全域上下文、結果割裂、互動混亂。
DeepSeek Harness團隊的解法是把“維護全域連續性”與“高並行執行”拆成兩層：常駐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，平行推進任務、起草回覆。
03.
事件驅動：不等指令，環境事件當輸入
四步讓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。
Router層根據某個Thread的初始事件建立Worker Session後，該Worker會直接訂閱對應Thread，從而將事件路由分為兩條路徑：
- 已訂閱，Fast Path：同一Thread下後續事件由程序直通已訂閱Worker，無需Router層再次呼叫工具轉發。若新事件超出當前任務範圍，Worker也可取消訂閱或交回Router層重新分派。
- 未訂閱，Slow Path：Router層仍可觀測所有事件以掌握全域狀態，但僅負責判斷和分派尚未被訂閱的新事件。
此外，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層在長程中丟失先前資訊的問題。
具體來說，系統為Trigger、Thread和Worker Session等對象賦予唯一ID，並在注入時內聯緊密關聯對象ID，使這些對像在底層構成一張引用圖。由於每一次呼叫工具召回的對象本身同樣遵循Inline & Spill，其返回結果中又會內聯下一跳關聯對象的摘要與ID，模型便可以從當前事件出發，順著引用關係逐步按需召回上下文。例如從一條當前消息讀取所在Thread，再從Thread內聯ID追蹤到相關Worker Session，進而找到該Worker關聯的另一個程式碼評審Thread。
4、提前行動：後台提前試，有價值才交付
借鑑電腦系統中的投機執行思想，Agent可以在還不確定結果是否會被採用時，根據環境訊號在後台提前嘗試，通過消耗額外後台算力減少人類等待與介入成本。結果有價值就交付，沒有價值就丟棄。
在個人助手場景下，收到一封會議邀約郵件或待辦消息時，Agent可先在後台核對日程衝突、蒐集相關背景資料並備好回覆草稿，待使用者過目後直接確認發出。在研發協作場景下同樣如此。例如團隊在DeepSeek Harness內部使用者群中配置了一條“靜默復現並修復”策略：當群裡有人反饋問題或討論改動方案時，Agent先在後台嘗試復現並尋找修複方案，只有在確認問題並找到簡單修複方案後，才把結果交付給使用者，否則全程保持安靜。
04.
面向人的互動：全雙工隨時接新指令
多通道按人的習慣說話
雙層架構保證了跨通道上下文連續，但實際互動體驗還需解決兩點：用非同步ReAct Loop讓後台耗時操作不阻塞前台，會話隨時接受新指令；讓輸出方式匹配不同通道的頻寬與人的使用習慣。
1、全雙工互動：後台幹活，前台不卡，新指令隨時進
經典ReAct Loop中，模型發起一次同步的run()工具呼叫後，循環會阻塞，直到工具執行完畢並返回最終結果，在此期間會話無法響應任何新的使用者輸入。要消除這一阻塞，需要將對話從一問一答的半雙工模式轉變為全雙工模式。
為此，團隊將耗時命令與子任務工具呼叫改為非同步的start()和stop()，構成非同步ReAct Loop。模型呼叫start()後立即收到“已啟動”返回，循環不再等待該工具；後台工具執行完成後，系統再將最終結果作為一條新事件消息投遞進會話；同時，模型也可根據上下文呼叫stop()主動終止執行時間過長的後台命令。
由此，前台對話響應與後台任務執行得以解耦，Agent在背景執行耗時任務的同時也能響應人類輸入。新輸入在當前推理步結束後即被處理，不必等待後台工具完成。文章透露，這一非同步任務機制已在DeepSeek Harness中實現，但尚未默認開啟。
2、多通道互動：群聊低打擾短回覆，PR郵件高密度寫完整
不同工作通道具有不同資訊密度與互動習慣，系統輸出需要與之匹配。如果將面向單人終端的互動方式直接搬入群聊，把冗長推理過程與密集工具呼叫原樣輸出，在多人協作中極易造成資訊過載。
在Super-agent中，雙層架構已解決其中一部分問題：具體任務中冗長推理過程和密集工具呼叫都被隔離在Worker Session內部，不會直接輸出到外部通道，而由Router層統一負責對外互動。在此基礎上，系統還需接入使用者日常使用的各類工作環境，並通過提示詞針對不同通道定製互動規範：
- IM等即時通訊通道：側重低打擾的輕量溝通，像人類同事一樣只在需要決策或驗收時傳送通知，只問直接問題、給簡短結論。團隊驗證過一條簡單有效的硬性規定：單次回覆不超過100詞。
- GitHub、郵件與文件等非同步通道：側重結構化、高資訊密度的非同步交付，例如建立或更新Pull Request時按項目規範撰寫完整問題背景、改動說明與驗證結果，或在個人助手場景下直接起草結構化郵件與文件摘要。
05.
類Anthropic式“腦手分離”
計算、狀態與環境解耦
現有本地Agent默認將推進Agent Loop的計算、需要持久保存的會話狀態，以及程式碼倉庫與本地工具鏈等執行環境繫結在同一台裝置上。一旦裝置休眠或離線，Agent就會停止運行，且無法訪問其他裝置上的環境。
要讓Super-agent做到持久線上並靈活接入各類真實工作環境，可借鑑電腦系統中存算分離思想，分兩步解耦三者繫結：第一步先將推進Agent Loop的計算與持久化會話狀態分離，使Agent擺脫單機生命周期限制、實現雲端持久線上；第二步再將雲端Agent Loop與重狀態執行環境解耦，讓真實工作環境留在原地並支援跨裝置訪問。
文章指出，這一思路與Anthropic提出的“腦手分離”一致，同樣讓harness保持無狀態，把會話日誌存放在harness之外，並通過統一介面按需接入執行環境。
但兩者區別在於場景：Anthropic那篇文章描述的是託管服務，主要討論按需建立的沙箱和客戶VPC內資源；這裡首先要接入的是使用者日常使用、可能間歇線上的個人機器，上面有未提交修改和本地憑據。因此，這種設計既支援BYOM，即把使用者日常使用的開發機或個人電腦接入雲端Agent，也支援接入雲端託管機器或按需建立的計算環境。
由此，一個Agent不再受限於單台機器，而是可以在不同執行裝置之間切換，根據任務需要選擇環境來執行命令並獲取環境中上下文。它甚至能支援間歇線上裝置，例如使用者某台個人裝置重新上線後，再由雲端Agent自動觸發並完成需要在該裝置上執行的任務。
06.
持久線上靠外部Watchdog：
既盯基礎設施，也盯任務進展
要實現持久線上，除了第5節存算分離，還需要讓系統在長期運行中能從異常中自動恢復。持久線上的分佈式系統很難僅靠主系統內部邏輯保證長期可靠運行，需要在主系統之外引入獨立外部控制回路，即Control Loop。
同時，在Agent系統中，僅靠傳統處理程序存活探測或監控指令碼是不夠的，因為許多異常並非處理程序崩潰，而是模型在執行中陷入無效循環或偏離目標。因此，長期運行Agent系統不僅需要監控基礎設施存活，還需要監控任務本身進展。
團隊在主系統外部配置了一個獨立Watchdog Session，用定時消息驅動它，構成外部Control Loop。Watchdog除了處理介面報錯、狀態恢復失敗等基礎設施故障，還會由模型判斷各Worker是否有實質進展、方向是否偏離整體目標。發現異常時及時介入修復，遇到外部偶發故障則持續複查直至恢復正常。
由於Watchdog本身也是一個具備完整工具能力的Agent Session，維護者可以用自然語言向它詢問故障原因，也可以讓它線上修正主系統行為，例如增刪提示詞、調整觸發規則。
07.
初步實驗：雙層架構更快更穩
直通省三成token
Router越堵單決定越便宜
為評估前文核心調度與路由設計，團隊從兩個層面進行初步實驗：首先通過端到端實驗對比雙層架構、訂閱直通與單Session方案；隨後單獨測試Router層批處理。由於實驗基於合成負載與簡化環境，部分設定還可更加嚴謹，以下結果僅作初步參考。
1、消融實驗：更快更穩，直通不提速但省Router約37% token
實驗用群聊和GitHub CI消息流驅動四種方案，單次約300條消息、其中約20條工作請求，編碼工作用只耗時工具代替，每種跑5次。
Super-agent的p50與p95分別為12.4分鐘和15.7分鐘，顯著優於帶Subagent工具的單Session。後者受提示詞影響大：中性提示下5次運行一次都沒呼叫Subagent，全在主Session裡干、不斷被新消息打斷，p95達29.5分鐘；改為優先委派後5次有4次委派，仍慢於Super-agent，剩下1次模型判斷工作“很小”自己執行，形成長尾。
開銷上，Super-agent維護多會話，讀快取token高於單Session，用更多token換更短更穩的完成時間。去掉直通後完成時間基本一致，但Router決定數增加約30%，讀快取token從2323萬增至3177萬，增幅約37%，直通不提升速度，但為Router省下可觀的token與推理開銷。
2、Router層的批處理：積壓合併後，單決定分攤時間從6.4秒降到1.6秒
團隊單獨壓測了Router層：Router調真實模型、Worker用Mock模型，Trigger到達速率從每分鐘約1條升至約40條。
結果平均batch從1.0升至2.8，單次請求耗時僅從2.5秒增至3.9秒，增長慢於batch大小，單個決定分攤的推理時間從6.4秒降至1.6秒。
這說明突發擁堵時Router能自動合併積壓事件提高吞吐，也解釋了去掉直通後峰值負載增加仍未觸及瓶頸。因此目前團隊規模下無需過早水平切分、犧牲全域上下文連續性。
08.
四道檻仍待解：
架構擴展、人機協作、A2A、安全隱私
第2至第6節介紹的五個模組構成支撐Super-agent運轉的基本架構，第7節實驗也驗證了其中核心調度與路由機制在多工並行下的效果。
這套系統之所以能以較低複雜度運作，很大程度上是因為當前階段做了一系列工程和場景簡化。超出這些簡化適用範圍後，在雙層架構擴展、脫離Session後的人機協作、上下文邊界與A2A，以及安全與隱私上，仍有一些問題需要解決。
文章列出四個開放問題：一是雙層架構如何擴展，單Router承載超限後何時切分、粒度如何、Worker間何時直接通訊均無定論，跨月長程記憶也是瓶頸；二是脫離Session後如何協作，聊天窗口未必是最終形態，互動可更多發生在GitHub等領域介面，還需支援使用者中途介入、接管與即時協同。
三是組織擴大後如何劃分上下文邊界，多個隔離實例間的A2A通訊與協作待探索；四是安全與隱私，雲端Agent接入端側憑據存在被入侵和提示詞注入風險，還需讓Agent不接觸憑據本身也能使用憑據。
09.
結語：五大模組
解放Agent時代人的注意力瓶頸
文章並非提出全新理論，而是把電腦系統經典工程思想用於Agent系統建構，具體實現會演進，但設計思路有長期參考價值。基於DeepSeek Harness的內部Super-agent實例已持續運行，參與問題復現修復、程式碼審查和Harness迭代。
隨著模型執行單任務減少人工干預，瓶頸轉向人的注意力。雙層架構、事件驅動、非同步多通道互動、存算分離與外部Watchdog在底層接管會話管理與上下文同步，使人上移到決策與驗收。
Agent從被動對話窗口變為持續線上的自主協作者：面向個人是跨裝置助手，面向團隊融入研發工作流。團隊相信更自主的工作方式有望成為常態。部分設計已在dsh-superagent-prototype實現，但該外掛僅為驗證技術路線的原型，並非DeepSeek正式產品。(智東西)