DeepSeek Super Agent 設計探索：邁向更自主的代理程式系統

本文從工程實務探討架構設計思路，並非介紹 DeepSeek Harness 現有的產品功能。

過去一年，以程式開發代理程式為代表的單一任務代理程式，已證明模型能使用工具解決複雜問題，需要人類持續監督與逐步介入的程度也愈來愈低。同時，模型協調多個代理程式的能力正在進步，讓跨工作階段的組織與排程成為可行做法。隨著人類減少參與底層執行，角色也逐步轉向更高層的決策與結果驗收。

模型能力的進展，也帶來新的應用形式。近期，個人代理程式（Personal Agent）大量出現，直接接入日常訊息、行事曆、電子郵件與工作平台，持續觀察資訊流並協助處理事務。這種常駐、事件驅動的運作方式不只適用於個人；個人助理只是其中一種應用，在軟體開發等商業情境中也同樣有價值。

然而，目前主流的代理程式設計，仍難以在多項任務與團隊協作的規模下支援這種模式。它們以單一工作階段（Session）作為基本工作單位，各 Session 彼此獨立。使用者同時推進多項工作時，必須手動切換並記住每個 Session 的脈絡。根據我們的觀察，一個人通常只能同時追蹤三到五個活躍的 Session。這種設計下，單項任務的上限由模型能力決定，多項任務的上限則由人的注意力決定。

只透過 CLI、MCP 或外部連接器擴充既有的本機單一工作階段代理程式，雖然能接收外部訊息，仍會受到單一工作階段同步阻塞、多項任務脈絡混雜，以及本機裝置離線就停止執行等限制，需要大量人工維護。

要突破這些限制，就需要解除代理程式與單次手動啟動工作階段的綁定，讓它成為能跨工作階段保留脈絡、同時推進多項複雜任務且互不干擾的持續實體。我們將這種代理程式形式及其系統架構稱為 Super-agent。

例如，我們內部以 DeepSeek Harness 執行的 Super-agent 執行個體，可以讓同一項開發任務持續在即時通訊與 GitHub 之間推進。它也會持續監看公開群組的回饋，即使沒有人 @ 提及，也會主動找出根本原因並提交修正用的 Pull Request。

具體而言，我們認為 Super-agent 具備四項基本特性：

• 連續性：使用者可以直接在 IM 聊天、GitHub 留言等熟悉的工作介面與它互動，感覺始終只有同一個代理程式，不必考慮「Session X 的脈絡裡是否有資訊 Y」。例如，使用者先在 IM 提出方案 A，後來在 GitHub Pull Request 留言改採方案 B，代理程式能理解這項變動並調整執行方向。
• 效率：能迅速回應互動，同時平行、高品質地完成多項複雜任務。不必等前一個指令或任務結束，就能接收下一項指示。
• 主動性：不必等待使用者逐項下達指示，能持續觀察環境事件，主動推進值得處理的事務；不需要介入時則保持安靜。
• 持續運作：隨時保持連線，直接接入使用者真實的工作環境，長時間執行時遇到異常也能自動復原。

單一 ReAct Loop 無法同時支援這四項特性，需要相應的底層架構。相似的設計限制，往往導向相似的架構選擇。我們認為，無論是個人助理，還是軟體開發等商業情境中的代理程式，只要目標是建立持續運作、能同時回應環境事件的系統，底層就可能採取相近的架構。過程中遇到的許多問題，也與傳統電腦系統長期研究的問題十分相近，因此經典的系統設計觀念同樣適用。

這套架構在實作上會有不同變形，但我們認為，下列五個模組構成支援上述特性的基本架構：透過雙層架構兼顧連續互動與高效並行（第 2 節）；透過事件驅動實現主動回應（第 3 節）；透過以人為中心的互動設計，兼顧溝通的連續性與效率（第 4 節）；再透過運算、狀態與環境分離（第 5 節）及 Watchdog（第 6 節），實現跨裝置的持續運作與異常自動復原。

下圖呈現 Super-agent 的整體系統架構，標號 [2] 至 [6] 分別對應下文第 2 至第 6 節。

要同時做到跨管道的連續互動與多項任務的高效並行，系統在組織底層工作階段時，必須取捨連續性與吞吐量。

將每個事件都交給同一個 Session，能保留最連續的脈絡，卻受限於單一 ReAct Loop 循序執行的速度，導致任務完成時間長、吞吐量低。多項任務的中間細節混在一起，也可能影響結果品質。

反過來，若每個事件都建立新的獨立 Session，雖然並行吞吐量最高，但任務並非完全獨立時，缺乏全域脈絡會讓結果彼此割裂。多個 Session 各自回覆使用者，也會造成混亂。

為兼顧連續性與吞吐量，可以將「維持全域連續性」與「高並行執行」分給兩個層級：由常駐 Router 層處理人類互動與全域協調（2.1 節），Worker 層則在隔離的脈絡中並行執行個別任務（2.2 節），如下圖所示。

這種雙層架構讓系統接手脈絡管理與並行執行，使用者不再需要在意底層 Session，始終與同一個 Super-agent 互動。從這個角度看，要求使用者手動管理 Session，很大程度上是沿用底層 LLM API 的設計慣性。Session 應該是系統的實作細節，而非使用者的認知負擔。

既有設計中的 Session，同時承擔技術上的脈絡管理與面向使用者的專案管理。產品體驗與底層 Session 分離後，專案管理便不再受它限制。應該提供什麼互動與任務管理體驗，成為獨立的產品設計問題，後文會進一步討論。

這裡的「雙層」是邏輯上的職責劃分，每層不必只由一個 Session 實作，也可以有自己的內部結構。以下分別說明 Router 層與 Worker 層。

2.1 Router 層

Router 是常駐的全域路由層，承接所有入口的人類互動。跨任務的資訊與決策都在此彙整，讓它成為全域的序列點（Sequence Point）、協調點與記憶。為避免這個全域節點成為效能瓶頸，Router 層不直接執行個別任務，只處理人類互動與任務分派，甚至可以不提供 Bash 工具。

這種中央節點分派多個執行節點的結構，看似常見的代理程式團隊（Agent Team），但重點不同。一般代理程式團隊主要拆解單一複雜任務的步驟、協調角色。由於子步驟通常緊密相依，團隊主導者需要深入理解任務、規劃子任務並頻繁協調成員，承擔大量推理工作。Super-agent 的 Router 層只處理任務間的高層關係與分派，不必介入個別任務的內部拆解。反過來說，若透過提示詞限制代理程式團隊的主要工作階段不親自執行，只處理對外互動，將不同任務交給成員獨立推進，也能視為這種雙層架構。依我們的經驗，Router 層的工作往往沒有想像中複雜，較輕量的模型通常就能兼顧速度與效果。

Router 層內部也不必只有一個 Session，部分邏輯甚至不需呼叫 LLM。我們選擇最直接的實作，以單一常駐 LLM Session 為核心，發現它不像表面看來那麼容易成為吞吐瓶頸。某輪推理期間到達的環境事件，也就是第 3 節的 Trigger，會先累積，再於下一輪一起處理，形成批次處理，合併處理的額外開銷很小：

• 外部事件流平穩時，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 層的並行吞吐量愈高，分片間的記憶與脈絡連續性就愈低。在全域記憶問題解決之前，這項取捨仍會存在。

2.2 Worker 層

Worker 層由負責執行的工作階段組成。各 Worker 的脈絡彼此隔離，配備完整執行工具，能在自己的脈絡中專注處理單一任務。由於 Worker Session 直接決定任務結果與程式碼品質，通常需要使用能力最強的模型。

Worker 不直接與人類互動，推理過程與工具呼叫也不直接輸出到外部管道，而是向 Router 層回報狀態，由 Router 統一回覆使用者。這樣既能維持並行程度與交付品質，也能避免多個工作階段各自回覆造成混亂。

多項任務同時執行時，各 Worker 獨立推進工作，同層 Worker 通常不必直接通訊。執行衝突多半發生在同一個 Pull Request 等共用工作環境中；只要 Worker 都訂閱對應的討論串，就會收到相同事件通知（3.2 節），有機會自行辨識並解決衝突。少數跨任務協調則由 Router 層轉達。

如同 Router 層，每個 Worker Session 內部也不必只有一個工作階段。執行複雜單項任務時，Worker 可以建立子代理程式，也可以本身就是一個代理程式團隊；上層 Router 不必知道這些細節。這種結構既適用於程式開發協作，讓獨立的問題重現、Pull Request 審查與功能開發互不阻塞，也適用於個人助理。個人助理介面通常只有一個聊天頁面，但使用者可能在同一段對話討論不同主題；單一聊天頁維持互動連續性，底層則能為每個主題分派 Worker，平行推進任務、草擬回覆。

要讓 Super-agent 主動工作，首先得改變驅動方式。主要輸入不再是人類逐項輸入 Session 的提示詞，而是環境中的半結構化事件。群組訊息、電子郵件與行事曆提醒、程式碼審查留言、CI 結果等環境事件，在 Super-agent 中稱為 Trigger。透過監聽並回應 Trigger，代理程式不必再像單一 Session 模式那樣，等人類下達指示才被動執行一次。

沿著環境事件從進入到處理的生命週期，以下依序討論四個問題：如何以程式與模型結合的兩階段策略過濾大量雜訊（3.1 節）；如何透過訂閱與直通將事件送給 Worker（3.2 節）；如何以 Inline & Spill 及鏈式召回注入高資訊密度的脈絡，並按需擷取（3.3 節）；以及如何透過推測執行，依環境訊號在背景提前行動（3.4 節）。

3.1 事件過濾

連接真實群組與程式碼平台後，環境事件流呈現明顯的「高雜訊、低觸發率」特性，絕大多數日常訊息都不需代理程式介入。若每個事件都呼叫大型模型重新判斷，延遲與運算成本都難以負擔。借用電腦系統的 Fast Path／Slow Path 觀念，大型模型推論可視為靈活但昂貴的 Slow Path；將已明確、穩定且頻繁的判斷寫成確定性的程式碼，則形成低延遲、低成本的 Fast Path。

因此，事件進入系統後，第一步是過濾。目標是在呼叫大型模型前，以確定性規則排除雜訊，只將需要語意理解的候選事件交給模型。我們採用結合程式規則與大型模型的兩階段過濾機制：

• 程式層規則（Fast Path）：依事件來源、群組範圍、使用者或機器人允許清單等確定條件，透過程式快速檢查。例如，針對不同來源設定「只回應明確請求」「列為候選事件」或「直接忽略」，在呼叫模型前排除多數無關訊息。
• 語意層規則（Slow Path）：通過程式層檢查的候選事件交給 LLM，由它根據提示詞中的規則與脈絡判斷是否行動。語意層也讓人類能以自然語言擴充系統，方便隨時透過提示詞開啟、關閉或新增規則，如下圖所示。

3.2 事件路由

第 2 節的全域 Router 層維持跨管道的連續性。但若已分派任務的每個後續事件仍需它轉送，這個全域節點就會承受大量負載，提高系統回應延遲。因此，Fast Path／Slow Path 也適用於過濾後的事件路由。全域 Router 層只負責啟動新任務與跨任務協調；歸屬關係確定後，程式直接將後續事件送到對應 Worker Session，不必再經 Router 轉送。

在實際流程中，同一個 GitHub Pull Request、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 在同一工作環境或討論交會時，新事件會直接送給所有訂閱者。即使不進行點對點通訊，它們也能得知彼此的操作，並有機會自行解決衝突。輸出端仍由 Worker 向 Router 回報關鍵結論，再由 Router 回覆使用者並更新全域記憶。

3.3 脈絡組織

事件通過過濾並送到目標 Session 後，下一個問題是該向模型的脈絡視窗注入多少資訊。系統輸入從有限的人類提示詞，轉為持續產生的半結構化環境事件後，工具呼叫與事件注入的結構就更重要。注入太多會占用視窗、分散模型注意力；注入太少則需要反覆呼叫工具取回資訊，增加執行步驟。浪費脈絡視窗，也就是浪費模型的智能。

因此，可以將有限的脈絡視窗當作快取管理。借用編譯器最佳化與電腦系統的觀念，脈絡注入可分為兩個基本操作。Inline 是將近期可能用到的資訊直接內嵌到目前視窗，省去額外的工具呼叫往返；Spill 則將超出視窗預算、或較少用到的完整資訊留在視窗外，只保留參照或摘要，讓模型按需讀取。

結合電腦系統中的區域性（Locality）原則，可以用 Inline & Spill 逐步改善事件注入與工具呼叫：

• 從最少資訊開始：最初只提供目前物件的 ID 與內容摘要。
• 依區域性逐步 Inline 關聯資訊：將近期可能用到的資訊內嵌至脈絡。先附上密切相關物件的 ID，再加入時間或結構相鄰的內容，例如內容前 50 個字、IM 訊息前後及其回覆的訊息，或程式碼審查討論中的相鄰留言。
• 超出上限就 Spill：無法完整 Inline 的長內容，先設定較小的長度上限，將剩餘內容留在視窗外。簡單做法是截斷超出部分並保留續讀入口，模型需要全文時再呼叫工具擷取。

此外，大量後續事件直接送給 Worker、系統也累積長期任務歷史後，Router 層無法將所有任務的完整歷史都放在自己的脈絡視窗，卻仍需在使用者跨管道提起舊任務時找回脈絡。將 Inline & Spill 一致套用到不同物件，就能形成按需、多跳擷取的機制，也就是鏈式召回（Chain of Recall）。如下圖所示，這種做法有助於緩解 Router 層長期運作後遺失早期資訊的問題。

具體而言，系統為 Trigger、Thread、Worker Session 等物件指定唯一 ID，注入時再內嵌密切相關物件的 ID，讓底層形成參照圖。每次透過工具取回的物件，也遵循 Inline & Spill，回傳資料中會包含下一跳物件的摘要與 ID。模型便能從目前事件出發，沿參照關係逐步取回所需脈絡。

例如，先讀取目前訊息所在的 Thread，再沿 Thread 內嵌的 ID 找到相關 Worker Session，進一步找到該 Worker 關聯的另一個程式碼審查 Thread。

3.4 提前行動

借用電腦系統的推測執行（Speculative Execution）觀念，代理程式能在尚未確定結果是否會被採用前，依環境訊號在背景先行嘗試，以額外背景運算減少人類等待與介入的時間。結果有價值就交付，沒有價值就捨棄。

以個人助理為例，收到會議邀請郵件或待辦訊息時，可以先在背景檢查行程衝突、蒐集相關背景資料並準備回覆草稿，使用者看過後就能直接確認寄出。開發協作也適用同樣做法。我們在公司的 DeepSeek Harness 內部使用者群組設定了「靜默重現並修正」規則：有人回報問題或討論變更方案時，代理程式先在背景嘗試重現並尋找修正方式；只有確認問題且找到簡單修正後，才將結果交給使用者，否則全程保持安靜。

第 2 節的雙層架構，從脈絡層面維持跨管道的連續性。但實際人機互動要兼顧連續性與效率，還需處理互動方式及管道上的兩個問題：首先，以非同步 ReAct Loop 消除背景耗時操作對前景對話的阻塞，讓工作階段不必等待前一個指令或任務完成，就能接收新指示（4.1 節）；其次，互動發生在不同工作管道時，輸出方式應配合各管道的資訊承載量與使用習慣（4.2 節）。

4.1 全雙工互動

傳統 ReAct Loop 中，模型發出同步的run()工具呼叫後，迴圈會阻塞，直到工具完成並回傳最終結果。這段期間，工作階段無法回應新的使用者輸入。要消除阻塞，就得將一問一答的半雙工對話改為全雙工模式，如下圖所示。

為此，我們將耗時指令與子任務的工具呼叫，改為非同步的start()與stop()，形成非同步 ReAct Loop。模型呼叫start()後立即收到「已啟動（Started）」回應，迴圈不再等待工具。背景工具完成後，系統將最終結果作為新的事件訊息送進工作階段。模型也能根據脈絡呼叫stop()，主動終止執行過久的背景指令。

如此一來，前景對話與背景任務執行便能分開運作。代理程式在背景處理耗時任務時，也能回應人類輸入。新輸入會在目前推理步驟結束後處理，不需等待背景工具完成。

這項非同步任務機制已在 DeepSeek Harness 實作，但尚未預設啟用。

4.2 跨管道互動

不同工作管道的資訊密度與互動習慣不同，系統輸出也需要配合。若直接將為單人終端機設計的互動搬進群組，把冗長推理過程與密集工具呼叫原樣輸出，很容易讓多人協作陷入資訊過載。

在 Super-agent 中，雙層架構已處理其中一部分問題：個別任務的冗長推理與密集工具呼叫，留在 Worker Session 內部，不直接輸出到外部管道，由 Router 層統一負責對外互動。在此基礎上，系統還需要接入使用者日常的工作環境，並透過提示詞為各管道設定互動規範：

• IM 等即時通訊管道：著重輕量、低干擾的溝通。像人類同事一樣，只在需要決策或結果驗收時通知，直接提問並提供簡短結論。我們驗證過的一項簡單有效規則，是每次回覆不超過 100 個詞。
• GitHub、電子郵件與文件等非同步管道：著重結構清楚、資訊密度高的交付。例如，建立或更新 Pull Request 時，依專案規範完整說明問題背景、變更與驗證結果；個人助理則可以直接草擬有結構的電子郵件與文件摘要。

既有本機代理程式，通常將推進代理程式迴圈的運算、需要持久保存的工作階段狀態，以及程式碼儲存庫與本機工具鏈等執行環境，綁在同一台裝置。裝置休眠或離線，代理程式就會停止執行，也無法存取其他裝置的環境。要讓 Super-agent 持續運作，並彈性接入真實工作環境，可以借用電腦系統的運算與儲存分離觀念，分兩步解除綁定：先將推進迴圈的運算與持久化工作階段狀態分開，擺脫單機生命週期限制，讓系統常駐雲端（5.1 節）；再將雲端迴圈與保存大量狀態的執行環境分開，讓真實環境留在原處，同時支援跨裝置存取（5.2 節）。

5.1 運算與狀態分離

推進代理程式迴圈的運算可以不保存狀態，需要持久保存的是工作階段狀態。因此，第一層分離將運算放入雲端無狀態、可彈性調整的容器，Session 等持久化狀態則存入資料庫。無狀態運算容器能水平擴充、重新啟動或替換，工作階段與任務的連續性由持久化儲存維持。如此便能擺脫單一本機裝置的生命週期限制，讓代理程式在雲端持續運作。

5.2 運算與執行環境分離

代理程式迴圈與工作階段狀態常駐雲端後，下一個問題是如何存取任務所需的執行環境。模型工作需要的大量脈絡，必須透過工具從程式碼儲存庫、本機檔案、相依服務等環境取得。從更廣的定義來看，脈絡也包含執行環境本身。

常見做法有兩種。一種是在雲端啟動沙箱、擷取程式碼，再重建與同步環境。但真實工作環境往往包含尚未提交的本機變更、私人憑證、對內部網路服務的相依性，以及特定硬體或工具鏈；同步這些環境的技術成本高，也容易遺漏資訊。另一種做法是要求使用者放棄本機環境，遷移至雲端工作，但對許多人而言，遷移成本過高。

既然難以複製與同步的是環境本身，就不必讓它跟著代理程式迴圈移至雲端。第二層分離讓迴圈在雲端執行，保存大量狀態的執行環境留在原處。裝置端只需部署不保存工作階段狀態的輕量常駐程式（daemon），負責執行指令與回傳結果。換言之，執行環境留在雲端之外，由代理程式按需讀取其中的脈絡。

這與 Anthropic 提出的「大腦與雙手分離」一致：Harness 不保存狀態，工作階段紀錄存放在外部，再透過統一介面按需連接執行環境。兩者差異在於使用情境。該文描述託管服務，主要討論按需建立的沙箱與客戶 VPC 內的資源；這裡優先連接的是使用者日常的個人電腦，它們可能只會間歇連線，且存有未提交變更與本機憑證。因此，這項設計既支援 BYOM（Bring Your Own Machine），讓日常開發機或個人電腦連接雲端代理程式，也支援雲端託管機器或按需建立的運算環境。

代理程式因此不再受限於單台機器，可以依任務切換執行裝置，選擇合適環境來執行指令與取得脈絡。即使裝置只會間歇連線，也能支援，例如使用者的個人裝置重新連線後，雲端代理程式就能自動觸發並完成必須在該裝置執行的任務。下圖呈現運算、持久化狀態與不同執行環境的兩層分離結構。

持續運作不只需要第 5 節的運算與儲存分離，系統還必須在長時間執行時自動從異常復原。常駐的分散式系統，難以只靠自身內部邏輯維持長期可靠性，因此需要在主系統之外建立獨立的外部控制迴路。

在代理程式系統中，傳統的處理程序存活探測或監控腳本並不足夠。許多故障不是處理程序當機，而是模型陷入無效迴圈或偏離目標。因此，長期執行的系統除了監看基礎設施是否存活，也必須監看任務是否持續推進。

我們在主系統之外設定獨立的 Watchdog Session，以排程訊息驅動，形成外部控制迴路。Watchdog 除了處理 API 錯誤、狀態復原失敗等基礎設施故障，也由模型判斷 Worker 是否有實質進展、是否偏離整體目標。偵測到異常就及時介入修復；遇到暫時性的外部故障，則持續檢查直到正常運作。

Watchdog 本身也是配備完整工具的代理程式工作階段，因此維護者可以用自然語言詢問故障原因，也能請它在系統運作期間調整主系統行為，例如增刪提示詞或修改觸發規則。

為評估上述核心排程與路由設計，我們進行兩個層次的初步實驗。先以端到端實驗，比較雙層架構、訂閱直通與單一 Session 方案（7.1 節），再單獨測試 Router 層的批次處理（7.2 節）。實驗採用合成工作負載與簡化環境，部分設定仍可更嚴謹，因此以下結果僅作初步參考。

7.1 消融實驗

我們以群組與 GitHub CI 訊息流，同時驅動四種端到端方案。單次實驗約有 300 則訊息，其中約 20 則是工作請求，其餘為閒聊、追蹤、停止請求與 CI 訊息。實際程式開發由只消耗時間的工具取代，因此測量的是系統排程與協調，而非執行單項任務的能力。每種方案各執行五次。

四種方案包括 Super-agent、移除直通的 Super-agent，以及兩種提示詞設定下的單一 Session 加子代理程式工具。

中性提示詞為：「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...」

註：每種方案各執行五次，任務完成時間從收到工作請求起，計算至發出結果訊息為止。

任務完成時間方面，Super-agent 的 p50 為 12.4 分鐘、p95 為 15.7 分鐘，明顯優於搭配子代理程式工具的單一 Session。原因在於，實驗情境中的單一 Session 容易受到提示詞影響，主 Session 經常選擇自己執行，造成整體完成時間長且效能不穩。中性提示詞下，模型五次執行都未呼叫子代理程式，所有工作都在主 Session 進行，並不斷被新訊息打斷，p95 達到 29.5 分鐘。改用優先委派提示詞後，五次中有四次委派，完成時間縮短，但整體仍慢於 Super-agent；剩下一次判定工作「很小」，選擇自行執行，形成圖中的紫色長尾。相較在單一 Session 依賴提示詞工程與模型臨時判斷是否委派，雙層架構透過 Router 不直接執行工作、Worker 只接收已訂閱 Thread 的訊息，從系統層面緩解這項問題。

系統開銷方面，由於維護多個獨立工作階段，Super-agent 每次實驗的快取讀取 Token 比單一 Session 多，以額外用量換取更短、更穩定的完成時間。移除直通後，完成時間幾乎不變，但 Router 的決策次數增加約 30%，快取讀取 Token 總量由 23.23 百萬增加至 31.77 百萬，增幅約 37%。這表示在該工作負載下，直通未提升任務完成品質與速度，但大幅節省 Router Session 的 Token 與推理開銷。

7.2 Router 層的批次處理

為評估 2.1 節中單一常駐 Router Session 的吞吐上限與批次處理機制，我們單獨對 Router 層進行壓力測試：Router 呼叫真實模型，Worker 使用模擬模型，將需要決策的 Trigger 到達速率，從每分鐘約一則逐步提高至約 40 則，觀察平均批次大小、單次請求時間與每項決策分攤的推理時間。

如圖所示，需要決策的 Trigger 到達速率，從每分鐘約一則提高至約 40 則時，平均批次大小由 1.0 升至 2.8，單次請求時間僅從 2.5 秒增加至 3.9 秒，增幅小於批次大小，因此每項決策分攤的推理時間由 6.4 秒降至 1.6 秒。這表示外部事件突然湧入並排隊時，Router 層可以自動合併累積事件，提高有效吞吐量。這也解釋了 7.1 節移除直通雖提高 Router 尖峰負載，仍未達到單一 Router 的吞吐瓶頸。因此，以目前團隊規模而言，不需過早將 Router 分片，犧牲全域脈絡連續性。

第 2 至第 6 節的五個模組，構成支援 Super-agent 的基本架構；第 7 節實驗也呈現核心排程與路由機制在多工並行情境下的效果。系統能以較低複雜度運作，很大程度上仰賴目前採取的工程與情境簡化。超出適用範圍後，雙層架構擴充（8.1 節）、Session 之外的人機協作（8.2 節）、脈絡邊界與 A2A（8.3 節），以及安全和隱私（8.4 節），都仍有待解決。

8.1 如何擴充雙層架構？

「單一常駐 Router Session、訂閱直通、Worker 之間不直接通訊」這組簡化設計，能以相對低的工程成本涵蓋目前多數日常任務。但任務規模擴大、相依程度提高後，可能超出單一 Router Session 的能力。各層內部結構尚無定論：Router 層何時分片、切分粒度多細、同層 Worker 何時需要直接通訊，以及採取何種協作拓樸，都需在更多情境驗證。系統與模型共同設計（Co-design）也值得探索，針對 Router 層的事件判斷、批次分派與脈絡召回等任務專門訓練，可能進一步改善吞吐量與決策效能。

另一方面，常駐 Router 層配合參照圖的鏈式召回，主要處理近期任務與工作階段歷史的按需擷取。執行週期拉長到數月甚至更久時，長期記憶就會成為限制擴充能力的主要瓶頸。

8.2 不以 Session 為中心後，如何與代理程式協作？

雙層架構將底層多工作階段的管理對使用者隱藏，Session 因此不必再是產品設計的首要考量。但執行工作階段不再直接對應介面上的對話後，新的問題是：如何呈現任務，以及什麼互動與專案管理方式才自然？我們認為，以聊天視窗為中心的互動，某種程度上是路徑依賴的結果。更多互動可以發生在特定領域介面，例如本文範例中的 Super-agent 直接在 GitHub Issue 與 Pull Request 工作。也可以依使用者習慣保留介面上的對話，但一個可見對話，底層未必只對應單一 Session。

前文主要討論任務發起與結果驗收階段的人類互動。但在模型能力快速進展的過渡期，許多任務仍需人類中途參與。產品設計如何兼顧使用者逐步介入重要細節，以及背景自主執行的效率，也值得探索。例如，讓使用者隨時介入、接手，或在代理程式背景工作時與它即時協作。

整體而言，使用者需要的專案管理與互動方式，與工作領域和個人風格密切相關，最後形式很可能高度客製化。DeepSeek Harness 的開放架構，也較容易支援這類客製化。

8.3 如何劃分脈絡邊界並進行 A2A 協作？

前文討論的是單一 Super-agent 執行個體的內部設計，假設服務範圍內的所有資訊都彙整到同一個全域脈絡。但使用範圍從個人、小型團隊擴大到大型組織時，如何部署 Super-agent，實際上就是決定脈絡共用與隔離的邊界。需要共用脈絡的範圍使用同一執行個體，需要隔離的範圍則各自部署。

進一步來看，若組織內外存在多個彼此隔離的執行個體，例如成員的個人助理與團隊共用的 Super-agent，跨邊界協作就成為代理程式之間的通訊，也就是 A2A，並非特指某項協定。在不共用底層脈絡、且各自代表不同權限邊界的前提下，如何實現安全、可靠的 A2A 通訊與協作，仍有待探索。

8.4 如何保障安全與隱私？

第 3 節的事件驅動設計，讓代理程式能受更多環境驅動，也增加了接觸不可信輸入的風險。若無法妥善處理安全與隱私問題，Super-agent 就只能在狹小且可信任的範圍運作。

例如，第 5 節將代理程式迴圈部署在雲端、執行裝置安裝輕量常駐程式的做法，預設雲端與裝置端彼此信任。但雲端迴圈持續接收外部環境事件，裝置端又保存私人程式碼、敏感資料與本機憑證，這種跨裝置連接便帶來明顯的安全與隱私風險。一旦雲端迴圈因伺服器入侵或提示詞注入而遭攻破，所有連接裝置都可能被控制。

即使雲端未遭攻破，只要裝置端憑證能進入模型脈絡，正常執行也可能洩漏憑證。因此，需要設計讓代理程式能使用憑證、卻不直接接觸憑證內容的機制。這套架構若要更廣泛應用，就必須在保留跨環境召回脈絡能力的同時，處理這些安全與隱私問題。

回顧整套設計，我們並未提出全新理論，而是將電腦系統的經典工程觀念運用到代理程式系統。實作方式會隨技術演進，但我們認為，背後的系統設計思路有更長期的參考價值。我們以這些觀念與 DeepSeek Harness 建立的內部 Super-agent，已持續運作，日常參與問題重現與修正、回應程式碼審查，以及 DeepSeek Harness 本身的開發。

如同開篇所述，大型模型執行單項任務時，需要的人類介入愈來愈少，進一步提升生產力的瓶頸正在轉向人的注意力。透過雙層架構、事件驅動、跨管道非同步互動、運算與儲存分離，以及外部 Watchdog，系統接手繁瑣的工作階段管理與脈絡同步，讓人類進一步離開執行細節，轉向更高層的決策與結果驗收。

在這種形式下，代理程式不再只是被動等待指示的聊天視窗，而是在數位環境中持續運作的自主協作者。對個人而言，它能跨裝置協助處理日常事務；對團隊而言，它融入開發流程，承接並推進具體任務。我們相信，隨著模型能力與底層架構共同演進，這種更自主的工作方式，有機會成為人機協作的常態。

本文部分設計已在 dsh-superagent-prototype 實作（點選「閱讀原文」可前往 GitHub 儲存庫）。這個外掛只是用來驗證技術路線的原型，並非 DeepSeek 正式產品。

本文來自 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、Hanxiang Xu、C.C. Yu、Ziya Zhang、F. Zhou 等參與審閱、討論並提供回饋。系統實作與文章形成，都仰賴團隊日常交流與經驗累積。