剛剛，DeepSeek 公布下一代 agent harness 理念

原文標題：Super-agent 設計探索：邁向更自主的 Agent 系統

原文作者：DeepSeek 產品部

1. Super-agent

過去一年裡，以 Coding Agent 為代表的單任務 Agent 已經證明，模型能夠使用工具解決複雜問題，且越來越少需要人類持續監控和逐步介入。與此同時，模型的多 Agent 協同能力也在提升，使跨會話的組織與調度變得可行。隨著人類在底層執行中的參與減少，人的角色正逐步上移到更高層的決策與驗收。

模型能力的這一提升，也催生了新的應用形態。近期個人助手（Personal Agent）開始集中湧現，它們直接接入日常的消息、日程、郵件與工作平台，持續觀察信息流並協助處理事務。這種持續在線、事件驅動的工作模式並不局限於個人場景，個人助手只是其中一類應用；在軟體開發等商業場景中，它同樣很有價值。

然而，現有的主流 Agent 設計還難以在多任務和團隊協作的規模上支撐這一模式。Agent 的工作模式仍然以單一 Session 為基本單位，不同 Session 之間彼此獨立。當用戶並行推進多項工作時，必須手動切換並記住各個 Session 的上下文，而據我們觀察，一個人通常只能同時跟進 3 到 5 個活躍 Session。在這種設計下，單任務的上限取決於模型能力，多任務的上限取決於人的注意力。

如果只在現有的本地單會話 Agent 上借助 CLI、MCP 或外部連接器做簡單擴展，Agent 雖然也能接入外部消息，但仍受制於單會話同步阻塞、多任務上下文混亂、本地設備離線即停止運行等問題，需要大量人工維護。

要突破這些限制，需要打破 Agent 與單次手動會話的綁定，使其成為一個能跨會話保持上下文、同時推進多項複雜任務且互不干擾的連續實體。我們把這種 Agent 形態及其系統架構稱為 Super-agent。

例如，在我們內部基於 DeepSeek Harness 運行的 Super-agent 實例中，同一個開發任務可以在 IM 和 GitHub 之間連續推進；這個實例還會持續觀察公共群聊中的反饋，在無人 @ 的情況下主動定位根因並提交修復 Pull Request：

同一個任務在 IM 群聊與 GitHub Pull Request 評審之間連續推進

持續關注公共群聊，在無人 @ 的情況下主動識別缺陷並提交修復 Pull Request

具體來說，我們認為 Super-agent 具備以下四個基礎特徵：

• 連續：用戶可以直接在 IM 聊天、GitHub 評論等熟悉的工作界面與它互動，感覺始終只存在一個 Agent，不需要去想「Session X 的上下文中是否有 Y 信息」。例如，用戶先在 IM 上提出採用方案 A、隨後在 GitHub Pull Request 評論裡改為方案 B，它能理解並調整執行方向。

• 高效：交互響應迅速，同時能並行、高質量地完成多個複雜任務。無需等上個命令或任務完成，就能接受下一條指令。

• 主動：無需等待用戶逐條下達指令，能持續觀察環境事件並主動推進值得處理的事項，不需要介入時則保持安靜。

• 持久：始終在線、直接接入用戶真實的工作環境，並在長期運行中遇到異常時自動恢復。

單個 ReAct Loop 無法同時支持上述四個特徵，底層需要一套相應的架構。相似的設計約束會導出相似的架構選擇。我們認為，無論是面向個人的助手，還是面向軟體開發等商業場景的 Agent，如果目標是構建一個持續在線、並發響應環境事件的系統，那麼在底層就可能會採用相近的架構。同時，這一過程中面臨的許多問題與傳統計算機系統長期探討的問題具有很高的相似性，因此計算機系統中的許多經典設計思想在這裡同樣適用。

在具體落地中，這套架構會有不同的變體，但我們認為以下五個模塊構成了支撐上述四個基礎特徵的基本框架：通過雙層架構（第 2 節）兼顧連續交互與高效並發，通過事件驅動（第 3 節）實現主動響應，通過面向人的交互（第 4 節）在交互過程中同時做到連續與高效，並通過計算、狀態與環境的分離（第 5 節）及 Watchdog（第 6 節）實現跨設備的持久在線與異常自癒。

下圖展示了 Super-agent 的整體系統架構，圖中各模塊的標號 [2] 至 [6] 分別對應下文第 2 至第 6 節：

Super-agent 整體系統架構，標號 [2] 至 [6] 對應下文第 2 至第 6 節

2. 雙層架構

要同時實現跨信道的連續交互與多任務的高效並發，系統在底層會話組織上面臨連續性與吞吐量之間的根本權衡（Trade-off）。

如果每條事件都交給同一個 Session 處理，雖然上下文最連續，但受限於單個 ReAct Loop 串行執行的速度上限，任務完成耗時長、吞吐低，且多任務的中間細節混雜在一起也會影響完成效果。

反過來，如果每條事件都直接新開獨立的 Session 去處理，雖然並發吞吐最高，但一旦任務之間並不完全獨立，缺少全局上下文會讓各個 Session 的結果彼此割裂，同時多個 Session 各自向用戶響應也會造成交互混亂。

為了兼顧連續性與吞吐量，我們可以將「維護全局連續性」與「高並發執行」拆分到兩個不同的層級中：由常駐的 Router 層（2.1 節）統一承接人類交互與全局協調，由上下文隔離的 Worker 層（2.2 節）並發執行具體任務，如下圖所示：

雙層架構：Router 層統一負責路由與對外交互，多個 Worker Session 隔離並發執行任務

通過這一雙層架構，系統在底層接管了上下文管理與並發執行，從而在用戶側淡化了 Session 的存在，使用戶面對的始終是同一個 Super-agent。從這個角度看，讓用戶手動管理 Session，在很大程度上是從底層 LLM API 延續下來的設計慣性；Session 應當是系統的實現細節，而不應是用戶的認知負擔。

在現有設計中，Session 同時承載了技術上的上下文管理與面向用戶的項目管理。將產品形態與底層 Session 解耦後，面向用戶的項目管理便不再受 Session 的限制，向用戶暴露怎樣的交互與任務管理方式成為了一個獨立的產品問題。我們將在後文討論這個問題。

這裡的「雙層」是邏輯上的職責劃分，每一層在實現上都不必局限於單個 Session，而是可以有各自的內部結構。下文將分別介紹 Router 層與 Worker 層的設計。

2.1 Router 層

Router 層是常駐的全局路由層，負責承接所有入口的人類交互。所有跨任務的信息與決策都在 Router 層中匯總，由它充當全局的序點（Sequence Point）、協調點和記憶。為了避免這一全局節點成為系統的性能瓶頸，Router 層在設計上不直接執行具體任務，只負責人類交互與任務分派，甚至可以不配備 Bash 工具。

這種由一個中心節點分派多個執行節點的結構，表面上看與常見的 Agent Team 相似，但兩者的側重點不同。常見的 Agent Team 主要用於單個複雜任務內部的步驟拆解與角色協作，由於子步驟通常耦合較緊，Team Lead 往往需要深入理解任務細節、規劃子任務並高頻協調各個成員，自身承擔了很重的推理負載。而在 Super-agent 中，Router 層只處理任務之間的高層關聯與分派，無需介入單任務內部的拆解；相反，如果通過提示詞約束一個 Agent Team 的主會話不親自執行具體任務，僅負責對外交互並將不同任務分派給各成員獨立推進，那麼它也可以視為這種雙層架構。從我們的實踐來看，Router 層的任務常常沒有想像中複雜，使用較輕量的模型往往就能兼顧速度與效果。

在內部實現上，Router 層同樣不必局限於單個 Session，甚至部分邏輯未必需要調用 LLM。我們選擇了最直接的單個常駐 LLM Session 作為 Router 層的核心實現，並發現它並沒有表面看起來那麼容易成為吞吐瓶頸，因為上一輪推理期間到達的環境事件（即第 3 節的 Trigger）會積壓下來、在下一輪一並處理，形成批處理（Batching），而合併處理的額外開銷很小：

• 當外部事件流平穩時，Trigger 逐條進入 Router Session，此時單次響應延遲較低；

• 當事件密集湧入、Router Session 開始出現排隊擁堵時，上輪推理期間積壓的多條 Trigger 會自動合併，在下一次 LLM 調用中一併注入。Router Session 只做輕量的互動與分派，每步通常是長輸入、短輸出。把積壓的多條 Trigger 合併進一次 LLM API 調用，會在 Prefill 階段並行計算，單次請求耗時的增長遠慢於批處理大小。因此在一定範圍內，積壓越多，單個決定分攤的推理時間越低；上限取決於上下文長度，以及模型在一輪中能準確處理多少條 Trigger。

我們將在 7.2 節通過實驗定量展示這一批處理機制的效果。加上後文將介紹的訂閱與直通機制以及鏈式召回（見 3.2、3.3 節），單個常駐 Router Session 在保持上下文連續的同時，在我們目前的團隊規模下已經夠用。

當規模進一步擴大、單個會話確實不足以承載時，Router 層內部也可以設計為多層過濾結構，或水平切分（Sharding）為多個會話。此時，Router 層的內部設計本質上是連續性與吞吐量的權衡。切分粒度越細，Router 層的並發吞吐量就越高，但分片之間的記憶與上下文連續性就會越低。在全局記憶問題被解決之前，這一權衡始終存在。

2.2 Worker 層

Worker 層由負責具體執行的會話組成，各個 Worker 彼此上下文隔離，掛載完整的執行工具，在獨立上下文中專注完成單一任務。由於 Worker Session 直接決定任務結果與代碼質量，通常需要配置能力最強的模型。

Worker 不會直接與人類互動，其推理過程和工具調用不會直接輸出到外部信道，而是向 Router 層匯報狀態、由 Router 層統一向用戶回覆，從而在保障並發度與交付質量的同時避免多個會話各自回覆帶來的混亂。

在多任務並發執行時，各個 Worker 獨立推進任務，同層 Worker 之間通常也不需要直接通信。多個 Worker 在具體執行中的衝突往往出現在同一個 Pull Request 等共享工作環境中；只要它們都訂閱了對應的 Thread，就會收到相同的事件通知（見 3.2 節），從而有機會自行發現和解決衝突，少數跨任務協同則由 Router 層中轉。

與 Router 層類似，每個 Worker Session 在內部也不必局限於單個會話：在執行複雜單任務時，Worker 內部可以再創建 Subagent，也可以本身就是一個 Agent Team，這些對上層的 Router 層保持透明。這一結構既適用於代碼協作場景（同時推進多個獨立的問題復現、Pull Request 評審與特性開發而互不阻塞），也適用於個人助手場景：雖然個人助手在介面上通常只提供一個單會話的聊天頁面，但當用戶在同一對話框中同時討論多個不同話題時，前端的單一聊天頁負責維持互動的連續性，而底層可以為每個話題分別派遣 Worker，並行推進任務、起草回覆。

3. 事件驅動

要讓 Super-agent 具備主動性，首先需要改變系統的驅動方式。驅動 Agent 的主要輸入不再是人類在 Session 中逐條鍵入的提示詞，而是環境中的半結構化事件。在 Super-agent 中，群聊消息、郵件與日程提醒、代碼審查評論、CI 運行結果等環境事件被稱為 Trigger。通過監聽並響應 Trigger，Agent 不必再像單 Session 模式下那樣，等人類下達指令才被動執行一次。

圍繞一條環境事件從進入到處理的生命周期，下文將依次討論四個遞進的問題：如何通過程序與模型結合的兩級策略過濾大量噪音（3.1 節）、如何通過訂閱與直通機制將事件路由給 Worker（3.2 節）、如何利用 Inline \& Spill 與鏈式召回向模型高密度地注入與按需召回上下文（3.3 節），以及如何利用投機執行根據環境信號在後台提前行動（3.4 節）。

3.1 事件過濾

在接入真實的群聊與代碼平台後，環境事件流呈現出顯著的「高噪音、低觸發率」特徵，絕大多數日常消息並不需要 Agent 介入。如果對每個事件都調用大模型從頭判斷，延遲和算力成本都會難以承受。借鑒計算機系統中的 Fast Path / Slow Path 思想，大模型推理可以看作一條靈活但高成本的 Slow Path，而將已經明確且穩定的高頻判斷固化為確定性代碼，則構成了低延遲、低成本的 Fast Path。

因此，事件進入系統後的第一步是過濾，目標是在調用大模型之前先用確定性策略篩除噪音，只將需要語義理解的候選事件交給模型判斷。我們採用程序策略與大模型相結合的兩級過濾機制：

• 程序層策略（作為 Fast Path）：針對事件來源、群組範圍、用戶或機器人白名單等確定性條件，直接通過代碼進行快速準入檢查，例如對不同來源分別設置「僅響應明確請求」、「作為候選事件」或「直接忽略」，在調用模型前濾除大部分無關消息。

• 語義層策略（作為 Slow Path）：通過程序層準入的候選事件交給 LLM，由它根據用提示詞編寫的策略和上下文判斷是否需要行動。語義層同時作為面向人類的自然語言擴展點，方便隨時通過提示詞開關或新增策略，如下圖所示：

兩級過濾：先由程序層策略篩除大部分無關消息，再交由語義層策略判斷

3.2 事件路由

第 2 節引入的全局 Router 層負責維持跨信道的連續性，但如果已分配任務的每個後續事件仍需經由 Router 層轉發，這一全局節點依然會承受大量負載，推高系統的響應延遲。因此，Fast / Slow Path 同樣適用於過濾後的事件路由。全局 Router 層僅負責新任務的冷啟動與跨任務協調，而已確定歸屬關係的後續事件由程序直接發往對應的 Worker 會話，無需經由 Router 層轉發。

在實際工作流中，同一個 GitHub Pull Request、同一個 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.3 上下文組織

在事件經過過濾與路由、進入目標 Session 後，下個問題是應當向模型的上下文窗口注入多少信息。由於系統輸入從有限的人類提示詞轉向了環境持續產生的半結構化事件，工具調用與事件注入的結構設計變得更加重要。注入過多會擠佔窗口、稀釋模型注意力，注入過少又會迫使模型反復調用工具讀取，增加執行步數。浪費上下文窗口，就是浪費模型的智能。

為此，我們可以將有限的上下文窗口當作 Cache 來管理。借用編譯優化與計算機系統中的概念，上下文注入的設計可以歸納為兩個基本操作。Inline 是指將近期很可能用到的信息直接內聯進當前上下文窗口，以省去額外的工具調用往返。Spill 則是指將超出窗口預算或低頻使用的完整信息留在上下文窗口之外，僅在窗口內保留引用或摘要，供模型按需讀取。

結合計算機系統設計中經典的局部性（Locality）思想，我們可以用 Inline \& Spill 對事件注入和工具調用逐步優化：

1. 從最少信息開始：最初只提供當前對象的 ID 和內容摘要。

2. 利用局部性逐步 Inline 關聯信息：將近期很可能用到的信息 Inline 到上下文中，先附上緊密關聯對象的 ID，再附帶時空相鄰的內容，例如內容前 50 字、IM 消息的前後相鄰消息與所回覆的消息，或代碼評論所在評審討論中的相鄰評論。

3. 超出上限則 Spill：對無法全部 Inline 的長內容設定較小的長度上限，將超出部分 Spill 到窗口之外。一種簡單直接的做法是截斷超出部分並保留續讀入口，模型需要完整內容時再調用工具讀取。

此外，在大量後續事件直通 Worker、且系統在長期運行中累積了許多歷史任務後，Router 層既不能把所有任務的全量歷史都放入自己的上下文窗口，又需要在用戶跨信道提起某個舊任務時找回上下文。將 Inline \& Spill 一致地應用到系統中的各類對象後，就得到了一種按需展開的多跳檢索機制，即鏈式召回（Chain of Recall）。這種鏈式召回過程緩解了 Router 層在長程中丟失先前信息的問題，如下圖所示：

鏈式召回：每次召回的對象均內聯下一跳關聯對象的 ID，支持沿引用關係逐跳展開上下文

具體來說，系統為 Trigger、Thread 和 Worker Session 等對象賦予唯一 ID，並在注入時內聯緊密關聯對象的 ID，使這些對象在底層構成一張引用圖。由於每一次調用工具召回的對象本身同樣遵循 Inline \& Spill，其返回結果中又會內聯下一跳關聯對象的摘要與 ID，模型便可以從當前事件出發，順著引用關係逐步按需召回上下文。

例如從一條當前消息讀取所在 Thread，再從 Thread 內聯的 ID 追蹤到相關的 Worker Session，進而找到該 Worker 關聯的另一個代碼評審 Thread。

3.4 提前行動

借鑒計算機系統中的投機執行（Speculative Execution）思想，Agent 可以在還不確定結果是否會被採納時，根據環境信號在後台提前嘗試，通過消耗額外的後台算力來減少人類的等待與介入成本。結果有價值就交付，沒有價值就丟棄。

在個人助手場景下，當收到一封會議邀約郵件或待辦消息時，Agent 可以先在後台核對日程衝突、搜集相關背景資料並備好回覆草稿，待用戶過目後即可直接確認發出。在研發協作場景下同樣如此，例如我們在公司的 DeepSeek Harness 內部用戶群中配置了一條「靜默復現並修復」策略：當群裡有人反饋問題或討論改動方案時，Agent 先在後台嘗試復現並尋找修復方案，只有在確認問題並找到簡單的修復方案後，才會把結果交付給用戶，否則全程保持安靜。

投機執行示例：群內還在討論解決方案時，Super-agent 已在後台提交了修復 Pull Request

4. 面向人的交互

第 2 節的雙層架構從上下文層面保證了跨信道的連續，但要在實際的人機交互體驗中同時做到連續與高效，還需要在交互方式與交互渠道上解決兩個問題：一是如何通過異步 ReAct Loop 消除後台耗時操作對前台對話的阻塞，使會話無需等待上一个命令或任務完成即可隨時接受新指令（4.1 節）；二是當交互發生在用戶熟悉的不同工作信道時，如何讓系統的輸出方式匹配對應信道的帶寬與人的使用習慣（4.2 節）。

4.1 全雙工交互

在經典的 ReAct Loop 中，模型發起一次同步的 run () 工具調用後，循環會阻塞，直到工具執行完畢並返回最終結果，在此期間會話無法響應任何新的用戶輸入。要消除這一阻塞，需要將對話從一問一答的半雙工模式轉變為全雙工模式，如下圖所示：

經典 ReAct Loop 與異步 ReAct Loop 對比：異步調用立即返回 Started 通知，後台工具運行期間仍可響應新消息

為此，我們將耗時的命令與子任務工具調用改為異步的 start () 和 stop ()，構成異步 ReAct Loop。模型調用 start () 後立即收到「已啟動（Started）」的返回，循環不再等待該工具；在後台工具執行完成後，系統再將最終結果作為一條新的事件消息投遞進會話；同時，模型也可以根據上下文調用 stop () 主動終止執行時間過長的後台命令。

由此，前台對話響應與後台任務執行得以解耦，Agent 在後台運行耗時任務的同時也能響應人類輸入。新輸入在當前推理步結束後即被處理，不必等待後台工具完成。

這一異步任務機制已經在 DeepSeek Harness 中實現，但尚未默認開啟。

4.2 多信道交互

不同工作信道具有不同的信息密度與交互習慣，系統的輸出需要與之匹配。如果將面向單人終端的交互方式直接搬入群聊，把冗長的推理過程與密集的工具調用原樣輸出，在多人協作中極易造成信息過載。

在 Super-agent 中，雙層架構已經解決了其中一部分問題：具體任務中冗長的推理過程和密集的工具調用都被隔離在 Worker Session 內部，不會直接輸出到外部信道，而由 Router 層統一負責對外交互。在此基礎上，系統還需要接入用戶日常使用的各類工作環境，並通過提示詞針對不同信道定制交互規範：

• IM 等即時通訊信道：側重低打擾的輕量溝通，像人類同事一樣只在需要決策或驗收時發送通知，只問直接問題、給簡短結論。我們驗證過的一條簡單有效的硬性規定是單次回覆不超過 100 詞。

• GitHub、郵件與文檔等異步信道：側重結構化、高信息密度的異步交付，例如在創建或更新 Pull Request 時按項目規範撰寫完整的問題背景、改動說明與驗證結果，或在個人助手場景下直接起草結構化的郵件與文檔摘要。

5. 計算、狀態與環境的分離

現有的本地 Agent 默認將推進 Agent Loop 的計算、需要持久保存的會話狀態，以及代碼倉庫與本地工具鏈等執行環境綁定在同一台設備上。一旦設備休眠或離線，Agent 就會停止運行，且無法訪問其他設備上的環境。要讓 Super-agent 做到持久在線並靈活接入各類真實工作環境，我們可以借鑒計算機系統中存算分離（Compute-Storage Separation）的思想，分兩步解耦這三者的綁定：第一步先將推進 Agent Loop 的計算與持久化的會話狀態分離，使 Agent 擺脫單機生命週期限制、實現雲端持久在線（5.1 節）；第二步再將雲端的 Agent Loop 與重狀態的執行環境解耦，讓真實工作環境留在原地並支持跨設備訪問（5.2 節）。

5.1 計算與狀態分離

推進 Agent Loop 的計算可以做成無狀態的，需要持久保存的是會話狀態。因此，第一層解耦是將推進 Agent Loop 的計算放入雲端無狀態的彈性計算容器中，而將 Session 等持久化狀態存入數據庫。無狀態計算容器可以水平擴展、重啟或替換，會話與任務的連續性則由持久化存儲保障，從而使 Agent 擺脫單台本地設備的生命週期限制，實現雲端持久在線。

5.2 計算與執行環境分離

在 Agent Loop 與會話狀態常駐雲端後，進一步的問題是如何訪問任務所需的執行環境。模型工作所需的上下文很大一部分要通過工具調用從代碼倉庫、本地文件、依賴服務等執行環境中獲取，從這個意義上說，廣義的上下文也包含了執行環境本身。

圍繞這一問題，常見的思路有兩種：一種是在雲端啟動沙箱、拉取代碼並嘗試重建和同步環境，但由於真實工作環境往往包含未提交的本地修改、私有憑據、內網服務依賴以及特定的硬件或工具鏈，在技術上同步這樣的環境不僅成本很高，還容易出現信息遺漏；另一種是直接要求用戶放棄本地環境、遷往雲端工作，但對很多用戶來說遷移成本過高。

既然難以複製和同步的是環境本身，就不必讓執行環境跟著 Agent Loop 上雲。第二層解耦是讓 Agent Loop 在雲端運行，而讓重狀態的執行環境留在原地，僅在端側部署一個不保存會話狀態的輕量 daemon，它只負責執行命令與返回結果，相當於把執行環境留在雲端之外，由 Agent 按需讀取其中的上下文。

這一思路與 Anthropic 提出的「腦手分離」（Decoupling the brain from the hands）一致，同樣讓 harness 保持無狀態，把會話日誌存放在 harness 之外，並通過統一接口按需接入執行環境。兩者的區別在於場景。那篇文章描述的是托管服務，主要討論按需創建的沙箱和客戶 VPC 內的資源；這裡首先要接入的是用戶日常使用、可能間歇在線的個人機器，上面有未提交的修改和本地憑據。因此，這種設計既支持 BYOM（Bring Your Own Machine），即把用戶日常使用的開發機或個人電腦接入雲端 Agent，也支持接入雲端托管機器或按需創建的計算環境。

由此，一個 Agent 不再受限於單台機器，而是可以在不同的執行設備之間切換，根據任務需要選擇環境來執行命令並獲取環境中的上下文。它甚至能夠支持間歇在線的設備，例如在用戶的某台個人設備重新上線後，再由雲端 Agent 自動觸發並完成需要在該設備上執行的任務。下圖展示了計算、持久化狀態與各類執行環境分兩層解耦後的結構：

存算分離與執行環境解耦：Agent Loop 與持久化狀態在雲端分離，並透過端側 daemon 按需接入各類執行環境

6. 監控器

要實現持久在線，除了第 5 節的存算分離，還需要讓系統在長期運行中能從異常中自動恢復。持久在線的分佈式系統很難僅靠主系統內部邏輯保證長期可靠運行，需要在主系統之外引入獨立的外部控制回路，即 Control Loop。

同時，在 Agent 系統中，僅靠傳統的進程存活探測或監控腳本是不夠的，因為許多異常並非進程崩潰，而是模型在執行中陷入無效循環或偏離目標。因此，長期運行的 Agent 系統不僅需要監控基礎設施的存活，還需要監控任務本身的進展。

我們在主系統外部配置了一個獨立的監控器會話，用定時消息驅動它，構成外部的 Control Loop。監控器除了處理接口報錯、狀態恢復失敗等基礎設施故障，還會由模型判斷各個 Worker 是否有實質進展、方向是否偏離整體目標。發現異常時及時介入修復，遇到外部偶發故障則持續復查直至恢復正常。

由於監控器本身也是一個具備完整工具能力的 Agent 會話，維護者可以用自然語言向它詢問故障原因，也可以讓它在線修正主系統的行為，例如增刪提示詞、調整觸發規則。

7. 初步實驗

為了評估前文的核心調度與路由設計，我們從兩個層面進行了初步實驗：首先通過端到端實驗對比雙層架構、訂閱直通與單會話方案（7.1 節），隨後單獨測試 Router 層的批處理（7.2 節）。由於實驗基於合成負載與簡化環境，部分設置還可以更加嚴謹，以下結果僅作為初步參考。

7.1 消融實驗

我們用群聊和 GitHub CI 消息流同時驅動四種端到端方案：單次實驗包含約 300 條消息，其中約 20 條是工作請求，其餘是閒聊、跟進、叫停和 CI 消息。編碼工作用一個只消耗時間的工具代替，因此實驗衡量的是系統的調度與協作能力，而非對單個任務的執行能力。每種方案重複運行 5 次。

對比的四種方案包括 Super-agent、去掉直通的 Super-agent，以及兩種提示詞配置下的單會話 + Subagent 工具。

其中，中性提示寫為 "Use a subagent for a piece of work when appropriate…"

提示優先委派則寫為 "Every message of the chat reaches you, so work you run yourself keeps stopping for new messages. Prefer handing each piece of work to a subagent of its own, and do only small things yourself…"。

工作請求的累計到達曲線與四種方案的累計完成曲線（5 次實驗運行均值；消息間隔與工作時長按 1/4 縮放，模型調用耗時為真實值）

每種方案重複運行 5 次；任務完成時間指從工作請求到結果消息的耗時。

從任務完成時間看，Super-agent 的 p50 與 p95 分別為 12.4 分鐘與 15.7 分鐘，顯著優於帶 Subagent 工具的單會話。原因在於，帶 Subagent 的單會話在實驗場景下受提示詞影響較大，主會話常常決定自己直接執行任務，導致總完成時間長、性能不穩定。在中性提示下，模型在 5 次運行中一次都沒有調用 Subagent，所有工作都在主會話中進行並不斷被新消息打斷，p95 達到 29.5 分鐘；改為提示優先委派後，模型在 5 次運行中有 4 次進行了委派，完成時間有所縮短但整體仍慢於 Super-agent，且剩下 1 次它判斷工作「很小」而選擇自己執行，形成了圖中的紫色長尾。相比於在單會話中依賴提示詞工程和模型臨場判斷分不分工，雙層架構通過讓 Router 不直接執行具體工作、Worker 僅接收所訂閱 Thread 的消息，在系統層面上緩解了這一問題。

從系統開銷看，由於維護了多個獨立會話，Super-agent 單次實驗的讀緩存 token 高於單會話，是以更多的 token 消耗換取更短且更穩定的完成時間。而在 Super-agent 內部去掉直通機制後，任務完成時間與完整版基本一致，但單次實驗中 Router 需要做出的決定增加了約 30%，總讀緩存 token 從 2323 萬增加到 3177 萬，增幅約 37%。這表明在實驗負載下，直通機制不提高任務完成質量與速度，但為 Router 會話節省了可觀的 token 與推理開銷。

7.2 Router 層的批處理

為了驗證 2.1 節中單個常駐 Router 會話的吞吐上限與批處理機制，我們單獨對 Router 層進行了壓力測試：讓 Router 調用真實模型、Worker 使用 Mock 模型，並將需要決定的 Trigger 到達速率從每分鐘約 1 條逐步提升至約 40 條，觀察平均 batch 大小、單次請求耗時與單個決定分攤的推理時間。

不同 Trigger 到達速率下 Router 會話的 batch 大小、單次請求耗時與單個決定的分攤推理時間

8. 開放問題

第 2 至第 6 節介紹的五個模塊構成了支撐 Super-agent 運轉的基本架構，第 7 節的實驗也驗證了其中核心調度與路由機制在多任務並發下的效果。這套系統之所以能夠以較低的複雜度運作，很大程度上是因為我們在當前階段做出了一系列工程和場景簡化。超出這些簡化的適用範圍後，在雙層架構的擴展（8.1 節）、脫離會話後的人機協作（8.2 節）、上下文邊界與 A2A（8.3 節），以及安全與隱私（8.4 節）上，仍有一些問題需要解決。

8.1 如何擴展雙層架構

前文通過「單常駐 Router 會話 + 訂閱直通 + Worker 間不直接通信」的簡化組合，以較小的工程代價覆蓋了我們目前的大多數日常任務。但當任務規模擴大、耦合度提高，超出單個 Router 會話的承載範圍時，具體的層內結構並無定論，Router 層何時需要水平切分、粒度如何劃分，以及同層 Worker 之間何時需要引入直接通信、採用何種協作拓撲，仍有待在更多場景中檢驗。同時，系統與模型的協同設計（Co-design）也是一個值得探索的方向，針對 Router 層的事件判別、批量分派與上下文召回等任務進行專項訓練，有可能進一步提升 Router 層的吞吐與決策性能。

與此同時，前文中常駐的 Router 層配合基於引用圖的鏈式召回，主要解決的是近期任務與會話歷史的按需檢索。當運行周期拉長到跨月甚至更長的時間跨度時，長程記憶便成為制約可擴展性的主要瓶頸。

8.2 脫離會話之後如何與 Agent 協作

前文通過雙層架構將底層的多會話管理對用戶隱藏，使會話不再是產品設計的首要問題；但當底層的執行會話不再直接對應用戶界面上的會話後，如何向用戶呈現任務並提供自然的交互與項目管理形式，便成為了新的問題。我們認為，以聊天窗口為中心的交互在一定程度上是路徑依賴的結果。交互可能可以更多地發生在領域特化的交互界面中，例如像本文的實例那樣，讓 Super-agent 直接在 GitHub 的 Issue 和 Pull Request 中工作；會話也可以出於用戶的使用習慣而在界面上保留，但用戶看到的一個會話在底層未必只對應一個會話。

同時，前文主要討論了人類在任務發起與結果驗收階段的交互；但在模型能力快速演進的過渡期內，許多任務仍需要人類在中途參與，如何在產品設計中兼顧用戶對關鍵細節的逐步干預與後台自主推進的效率，例如讓用戶在後台執行過程中隨時介入、接管或與 Agent 實時協同工作，同樣值得探索。

總的來看，用戶所需的項目管理與交互形式與具體的工作領域和個人風格密切相關，最終形態很可能是高度定制化的；而 DeepSeek Harness 由於採用開放的架構設計，也更容易支持這種定制化。

8.3 如何劃分上下文邊界並進行 A2A 協作

前文討論的始終是單個 Super-agent 實例內部的設計，默認其服務範圍內的信息都匯總在同一個全局上下文中。但當使用範圍從個人或小團隊擴展到更大的組織時，組織在決定如何配備 Super-agent 時實際上是在劃分上下文共享與隔離的邊界。需要共享上下文的範圍共用同一個實例，需要隔離的範圍則各自獨立配備。

進一步看，一旦組織內或組織間存在多個彼此隔離的實例，例如每個成員各自的個人助手與團隊共用的 Super-agent 之間，此時跨邊界的協同就是 Agent 間通信（A2A，不特指某個協議）。在互不共享底層上下文、各自代表不同權限邊界的前提下，如何實現安全、可靠的 A2A 通信與協作，仍需進一步探索。

8.4 如何保障安全與隱私

第 3 節的事件驅動設計讓 Agent 能夠被更廣泛的環境驅動，但也增加了接觸不可信輸入的風險。如果沒有辦法很好地解決安全與隱私問題，那麼 Super-agent 只有在一個很小且可信的範圍才能工作。

例如，第 5 節將 Agent Loop 部署在雲端、並在各類執行設備上安裝輕量 daemon，這一設計默認建立在雲端與端側環境彼此受信任的前提之上。但當雲端的 Agent Loop 持續接入外部環境事件、而端側設備上又存有私有代碼、敏感數據與本地憑據時，這種跨設備連接便引入了顯著的安全與隱私隱患。一旦雲端的 Agent Loop 遭遇服務端入侵或提示詞注入而被攻破，其連接的全部端側設備都面臨被控制的潛在風險。

此外，即使雲端未被攻破，只要端側環境中的憑據能夠進入模型的上下文，正常執行過程中同樣存在憑據洩露的風險；因此還需要設計相應的機制，讓 Agent 能夠在完全不接觸憑據本身的情況下使用憑據。如果這一架構要走向更廣泛的應用，就需要在能夠從多樣化的環境中召回上下文的同時，解決上述安全與隱私問題。

9. 結語

回顧整套設計，我們並沒有提出全新的理論，而是將計算機系統中經典的工程思想應用到了 Agent 系統的構建中。具體的實現方式會隨技術發展而演進，但我們認為背後的系統設計思路有更長期的參考價值。目前，我們基於這套思路和 DeepSeek Harness 構建的內部 Super-agent 實例已經在持續運行，日常參與問題復現與修復、代碼審查響應與 DeepSeek Harness 自身的迭代。

正如開篇所述，隨著大模型執行單個任務越來越少需要人工干預，限制生產力進一步提升的瓶頸正在轉向人的注意力。通過雙層架構、事件驅動、異步多信道交互、存算分離與外部 Watchdog，系統在底層接管了繁瑣的會話管理與上下文同步，使人類得以從具體的執行細節進一步上移到更高層的決策與驗收。

在這種形態下，Agent 不再只是一个被動等待指令的對話窗口，而是演進為數位環境中持續在線的自主協作者：面向個人，它可以是跨設備協助處理日常事務的個人助手；面向團隊，它融入研發工作流，承接並推進具體任務。我們相信，隨著模型能力與底層系統架構的共同演進，這種更自主的工作方式有望成為人機協作的常態。

本文的部分設計已在 dsh-superagent-prototype 中實現。該插件只是一種為了驗證技術路線而提供的原型，並非 DeepSeek 的正式產品。

Author \& Acknowledgements

本文源於 DeepSeek Harness 團隊的共同實踐。Yujia Qiao 完成了系統實現和本文寫作，Huanqi Cao, Zui Chen, Xieting Chu, Tianyi Cui, Shiyuan Feng, Yudong Han, Kexin Liu, Shichun Liu, Gesi Luo, Yifan Shi, Tongrui Xiong, C.C. Yu, Ziya Zhang, F. Zhou 等參與審閱討論並提供反饋。系統的實現與文章的形成，離不開團隊日常的交流與積累。