DeepSeek Super Agent 技術解析：它是什麼、如何運作、為何值得關注

我們認為，這套設計的整合價值高於架構創新。Router–Worker 分工、事件驅動、持久化任務紀錄與背景工作，都建立在既有的工程觀念上。Offloop 已使用許多類似機制與設計模式超過六個月。Super Agent 值得研究之處，是將這些部分整合成開發者能檢視、執行與討論的開源系統。

我們尤其重視它處理任務管理的方式。多人交辦工作、補充脈絡與審查結果時，系統透過明確紀錄與程式規則，追蹤任務歸屬、授權與執行狀態。討論串訂閱機制會將後續訊息送給對應的 Worker。這些機制比單純增加代理程式數量，更有工程參考價值。

公開實驗每種設定各執行五次。相較優先委派基準，Super Agent 的完成時間中位數縮短約 10%，快取讀取 Token 用量則約為 2.1 倍。根據開發 Offloop 的經驗，我們認為，這套設計在多人參與、多項任務同時進行的流程中，具有理論上的效率優勢：明確的任務歸屬與事件路由，可以減少重複協調、脈絡交接與執行中斷。我們會以真實團隊工作負載測試這項優勢，衡量任務驗收、審查與重做時間、協調投入及總成本。

DeepSeek Super Agent 是一套支援持續協作的系統設計。團隊成員提出請求、補充脈絡並審查結果；系統將這些輸入連結到進行中的任務，再協調多個執行工作階段完成工作。

核心問題是：多個人如何與多個 AI 代理程式一起工作。

例如，同事先在聊天中提出需求，開發者在 GitHub Issue 補上重現步驟，審查者稍後又在 Pull Request 要求修改。這些輸入來自不同管道、發生在不同時間，卻屬於同一項工作。系統必須辨識它們的關聯，將資訊送給正確的執行者，並保留任務進度與範圍。

Super Agent 在 DeepSeek Harness 上執行。Harness 提供工具執行與代理程式工作階段等基礎功能；Super Agent 在此之上協調任務、事件與多個代理程式。

模型愈來愈能獨立完成單項任務，但團隊仍需協調多人與多項工作之間的請求、脈絡和進度。DeepSeek Super Agent 希望將更多協調工作交給系統處理。

假設團隊同時收到三個請求：

• 產品經理在飛書提出功能需求。
• 開發者在 GitHub 回報測試失敗。
• 審查者要求修改既有的 Pull Request。

同時，有些代理程式正在執行任務，有些在等待外部結果，也有些在等待人類決定。

協調工作會反覆遇到幾個問題：新訊息屬於既有任務，還是需要建立新任務？由誰負責？是否已有其他代理程式正在處理？補充脈絡應該送到哪裡？下一步需要誰釐清、授權或審查？

由人手動維護這些關係時，就得花時間搜尋對話、轉傳脈絡與追問進度。若把所有內容放進同一個工作階段，無關任務的脈絡又會混在一起，新訊息也可能打斷進行中的工作。

Super Agent 透過協調層保留跨任務關係，再讓獨立的執行工作階段分別推進工作。團隊成員仍使用熟悉的管道。原文的以人為中心的互動設計進一步說明人如何在執行過程中參與，以及如何跨管道與代理程式互動。

這與 Offloop 的設計相當接近。DeepSeek 技術文章的作者也曾與我們團隊的開發者交流想法。這些討論，加上開發 Offloop 的經驗，讓我們更深入理解這套架構的目標與取捨。

也可以現在體驗 Offloop。我們已實作這種多人、多代理程式的協作方式，目前正在內部測試。可以將它想像成 AI 隊友在類似 Slack 的協作空間工作：人類交辦任務、補充脈絡與追蹤進度；代理程式分工，再把結果帶回討論。

Router–Worker 如何分派任務？

Super Agent 採用Router–Worker 雙層架構。

Router 維護跨任務關係，判斷新請求該建立任務、加入既有任務，還是送給原有執行者。Worker 在各自的執行脈絡處理個別任務，也能視需要使用子代理程式。

這種分工將協調與執行分開。一個 Worker 修改程式碼時，另一個可以處理獨立請求；針對第一項任務的補充指示，仍會連結到原任務。

原文建議限制 Router 的執行工具，讓它專注於協調，例如不提供 Bash。

公開原型採取不同做法：Router 保留 Bash 等工具，但使用較小的工具集、較短的 Shell 等待上限，並透過提示詞要求它避免直接檢視程式碼與實作變更。

實作細節可參考公開原型的架構文件。

完整架構圖見繁中全文第 2 節。

事件驅動的任務協調與討論串訂閱

Super Agent 的事件驅動架構，將新請求與後續事件連結到進行中的工作。任務協調包含建立任務、連結執行工作階段，以及在相關更新到達時送給執行者。

以團隊程式開發流程為例。

一位有權交辦工作的同事回報測試失敗。系統辨識請求，建立任務與授權紀錄，再連結 Worker 執行。

另一位同事在同一個 Issue 補上紀錄。因為這個討論串已訂閱至該任務，補充資訊就能直接送達對應 Worker。

第三位同事提出無關的文件修改需求。系統可以建立獨立任務，交給另一個 Worker，讓兩項工作的脈絡分開維護。

Pull Request 審查與 CI 結果隨後以事件形式到達。若新請求超出任務已授權的範圍，系統需要重新評估，不會只因後續訊息就擴大權限。

公開實作使用三個核心概念：

初始請求建立任務關係，訂閱機制則讓後續事件直接送給 Worker。原文的事件驅動設計說明了其中的過濾、路由與脈絡組織方式。

任務授權：哪些請求能觸發執行？

接收規則先檢查來源與身分，再由模型判斷內容與任務的關係。Issue 留言、執行紀錄與 CI 結果可以補充脈絡，但不會因此授予執行權限。

公開原型區分幾種授權情境：

• 預設觀察模式會辨識並記錄推斷出的工作，不會自動執行。
• 明確請求符合相關規則時，可以觸發執行。
• 自動執行需要先設定對應的授權規則。

這些機制決定一則觀察到的訊息，如何成為獲准執行的工作。詳見原型的授權設計。

脈絡管理、背景執行與持久化

持續執行的代理程式，不能仰賴無限增長的脈絡視窗。

Super Agent 圍繞任務與事件組織脈絡：在目前視窗保留必要摘要與參照、依需求擷取較長內容，再沿著任務、討論串與事件的關係取回歷史。這種做法能控制脈絡大小、減少重複輸入，並保留存取歷史資料的方式。

長期記憶還涉及其他問題：舊結論何時失效、如何處理互相衝突的資訊、摘要是否遺漏重要條件，以及歷史紀錄是否仍符合現況。原文未詳細說明專門處理這些問題的機制。

耗時操作也與新輸入分開處理。工作在背景持續執行，完成後以新事件回傳，讓系統在執行期間仍能接收後續輸入。

原文進一步提出運算、狀態與執行環境分離：代理程式迴圈在雲端執行，持久化狀態分開儲存，執行裝置透過輕量常駐程式接收指令。如此一來，執行代理程式的運算資源，就能與保存程式碼、相依套件及憑證的機器分開管理。

公開原型的部署文件則描述較集中的部署方式：由 tmux 啟動 DeepSeek Harness，將資料庫存放在設定的狀態目錄中，並在執行機器準備任務工作目錄。

原文中的Watchdog還會評估任務進度。獨立的代理程式工作階段會檢查 Worker 是否停滯或偏離目標。公開部署文件中的狀態檢查與重啟流程，主要針對處理程序、設定與執行錯誤。重啟服務與判斷任務是否有效推進，是兩種不同的能力。

README說明公開程式碼經過發布調整，與內部實作及文章描述的架構不同，部分設計仍留待後續探索。

兩種做法都能平行執行工作，主要差異在於由誰組織任務，以及進行中的工作如何收到後續訊息。

Super Agent 的價值不只在於擁有多個代理程式。更值得研究的是，它如何減少對模型臨時決定是否委派的依賴，以及如何在執行中持續處理新輸入。原文的雙層架構章節進一步說明了這項差異。

DeepSeek Super Agent 是用來探索、驗證架構的開源研究原型；Claude Code 與 Codex 則是提供給使用者、持續維護的產品。兩者處理的問題不同：前者探討如何設計多人、多代理程式系統，後者讓使用者透過現有產品完成工作。

相關文件：Claude Code 文件、Agent Teams 文件、Codex 子代理程式文件、Codex 雲端文件。

Grok Bot 與 Muse 也以產品形式提供持續工作、多工或個人助理體驗。Super Agent 的特色，是公開系統設計，以及開發者能檢視和修改的實作。

相關資料：Grok Bot 文件、Muse 介紹、Muse 安全設計。

初步實驗使用約 300 則訊息，其中約 20 則是工作請求，其餘包含閒聊、追蹤訊息、停止請求與 CI 通知。

每種設定各執行五次。實驗以工具中的模擬延遲取代實際撰寫程式，因此測量的是排程與協調行為，未評估產生的程式碼品質、人工審查或重做時間。

P50 是中位數，P95 描述完成時間較慢的一端；M 表示百萬 Token。

有三項結果值得注意。

第一，基準方案如何協調工作，會明顯影響比較結果。相較中性提示詞基準，Super Agent 的完成時間中位數縮短約 39%；相較優先委派基準則約為 10%。中性基準的五次執行從未呼叫子代理程式；優先委派基準則有四次進行委派。

這支持了一項具體的架構判斷：將協調與執行分開，可以減少對模型逐項決定是否委派的依賴。

第二，訂閱直通主要降低額外開銷。移除直通後，完成時間大致相近，但快取讀取 Token 從 23.23M 增加至 31.77M，增幅約 37%。反過來說，相較未啟用直通的設定，啟用直通可減少約 27% 的快取讀取量。

第三，較低的延遲伴隨較高的 Token 用量。Super Agent 的快取讀取量約為中性基準的 3.8 倍、優先委派基準的 2.1 倍。快取讀取量無法直接換算成帳單，總成本還取決於快取讀取價格、其他輸入輸出 Token 與基礎設施。

技術分析：任務狀態、路由與執行

最值得參考的實作選擇，是將任務控制邏輯移出模型脈絡。Ticket 記錄任務與授權範圍，Assignment 將任務連結到執行，Engine 管理狀態轉換。已訂閱討論串的事件直接送達對應 Worker，減少由模型判斷路由的次數。

這比 Router–Worker 拓樸本身更有參考價值：程式機制處理任務歸屬與事件傳遞，模型負責語意判斷與執行。詳見公開架構文件。

對協作而言，實際好處是任務不再只存在於某人的記憶或對話紀錄中。即使參與者切換工作階段，明確紀錄仍能保留任務關係。

整合也增加了維運負擔。長期執行的協調器、事件來源、持久化狀態、執行環境與授權規則，都需要維護。系統仍須可靠地判斷：請求應該建立新任務、更新既有任務，還是需要人類介入。

我們認為，Super Agent 是值得研究與借鏡的架構。任務狀態、授權與事件路由機制，都可以分別運用。對於流程可預期、職責清楚的任務，簡單委派仍是有用的比較基準。

若團隊持續從聊天、Issue 與 Pull Request 收到請求，同時推進多項任務，且人類持續參與釐清與審查，Super Agent 就特別值得參考。

主要限制包括：

• 公開原型針對較有限的工作流程。它圍繞單一儲存庫、GitHub 與選用的飛書整合組織工作。完整文章另討論跨裝置執行、雲端運作與持續監督。
• 任務紀錄保存狀態，內容正確性則需要其他機制。Ticket、Assignment 與事件紀錄，協助確認誰正在處理什麼工作。
• 獨立工作目錄主要分開任務檔案與脈絡。Worker 以執行服務的作業系統使用者身分運作，能存取該使用者可讀取的檔案。因此，部署文件建議使用只保存代理程式憑證的專用作業系統帳號，詳見部署指南。
• 平行執行會增加協調與審查工作。多個 Worker 修改相關程式碼時，可能產生重複實作、合併衝突，或對需求有不同理解。

原文的開放問題也反映這些挑戰。將 Router 分片能提高吞吐量，卻會削弱共用脈絡。擴大參與者與執行裝置的範圍，也需要進一步釐清脈絡、權限與憑證的邊界。

DeepSeek Super Agent GitHub 儲存庫提供原始碼、SETUP.md與部署指南。

1. 執行需求

文件列出的需求包括：

• Node.js 22.19+ 或 24+，以及 pnpm。
• Git 2.32+、Python 3.8+ 與 tmux。
• GitHub CLI 2.48+。
• 已設定的模型服務。
• 目標 GitHub 儲存庫。
• 代理程式專用的 GitHub 帳號，以及規定誰能交辦工作的規則。

2. 複製 GitHub 儲存庫並依 SETUP.md 設定

複製儲存庫：

git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git dsh-superagent
cd dsh-superagent

接著可以請程式開發代理程式協助設定，提示詞如下：

Read SETUP.md in this repository and set up dsh-superagent with me.

設定流程會確認目標儲存庫、代理程式帳號、獲准使用者與模型服務。

3. 安裝並執行 DeepSeek Super Agent

以下指令用來建立新的 profile。先檢查是否有同名 profile，避免覆寫既有設定。

npm install -g @deepseek-ai/dsh@0.2.1-rc.3 pnpm@11.7.0

pnpm install
pnpm build

dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"

cp examples/profile.cordis.patch.yml ~/.dsh/profiles/superagent/cordis.patch.yml

將stateDir設為要使用的絕對路徑，再啟動服務：

scripts/dsh-superagent start
scripts/dsh-superagent status

首次執行時，結束代碼3可能表示設定尚未完成。開啟啟動紀錄所列的設定介面網址，再設定模型、目標儲存庫、GitHub 身分、獲准使用者與工作目錄。