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

[在 Offloop 閱讀本文](https://offloop.org/zh-TW/learn/deepseek-super-agent-design)

Yifei

結合我們開發 Offloop 的經驗，分析它的架構、設計取捨與實驗結果。

DeepSeek Super Agent 是在 DeepSeek Harness 上執行的開源研究原型，探索團隊中的多代理程式協作：多人交辦任務、補充資訊，再由系統協調多個 AI 代理程式推進工作。

DeepSeek Harness 團隊已公開系統設計，以及[GitHub 上可執行的原型](https://github.com/deepseek-ai/dsh-superagent-prototype)。我們認為，以研究原型的形式發布，可能反映團隊仍在探索不同架構與應用方向。隨著這些方向發展，我們預期還會看到更多開源原型。

原始技術文章以簡體中文發布。我們提供[繁體中文全文與原有配圖](https://offloop.org/zh-TW/learn/exploring-deepseek-super-agent-design)，方便讀者了解完整設計與實驗結果。

## 重點摘要

DeepSeek Super Agent 重點摘要

| 問題           | 簡要說明                                                                   |
| ------------ | ---------------------------------------------------------------------- |
| 它是什麼？        | 一套協調多人、多項任務與多個 AI 代理程式的系統設計，並提供以 DeepSeek Harness 為基礎、採用 MIT 授權的研究原型。  |
| 它能做什麼？       | 團隊成員可以交辦與追蹤不同任務，由系統協調代理程式，減少人工分派工作、傳遞脈絡與追蹤進度的負擔。                       |
| 核心架構是什麼？     | Router 將請求連結到任務並分派工作，Worker 執行個別任務。任務紀錄與討論串訂閱機制，則將後續事件送到正在進行的工作。       |
| 公開原型實作了哪些功能？ | 以單一 GitHub 儲存庫的程式開發工作為主，支援 GitHub 與選用的飛書整合。                            |
| 執行需要什麼？      | 相容的 DeepSeek Harness、模型服務、主機、目標儲存庫，以及代理程式專用的 GitHub 帳號。                |
| 實驗結果如何？      | 在合成工作負載下，相較中性提示詞基準，任務完成時間中位數縮短約 39%；相較優先委派基準則縮短約 10%，但快取讀取 Token 用量較高。 |
| 主要限制是什麼？     | 公開程式碼仍是研究原型，需要設定環境與權限。實驗以模擬延遲取代實際撰寫程式，測量的是排程行為，未評估程式碼品質、人工審查或長期維護成本。   |

![團隊請求進入 Super Agent，由系統協調任務歸屬、事件與平行執行的 Worker 工作階段。](https://offloop.org/editorial/learn/deepseek-super-agent/super-agent-overview.svg)

Super Agent 協調團隊請求、任務分派與平行執行的 Worker 工作階段。

## 我們的分析：整合價值與設計取捨

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

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

![任務紀錄、事件訂閱與 Worker 執行，組成可檢視實作的協調系統。](https://offloop.org/editorial/learn/deepseek-super-agent/integration-tradeoffs.svg)

任務紀錄與事件訂閱協調由模型推動的執行流程。

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

## DeepSeek Super Agent 是什麼？

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

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

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

![多人透過 IM 與 GitHub 推進同一項任務，由 Super Agent 將更新帶回討論。](https://offloop.org/editorial/learn/deepseek-super-agent/cross-channel-task.webp)

同一項任務持續在團隊聊天、GitHub Issue 與 Pull Request 審查之間推進。

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

## 為什麼要設計 DeepSeek Super Agent？

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

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

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

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

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

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

Super Agent 透過協調層保留跨任務關係，再讓獨立的執行工作階段分別推進工作。團隊成員仍使用熟悉的管道。原文的[以人為中心的互動設計](https://offloop.org/zh-TW/learn/exploring-deepseek-super-agent-design#section-4)進一步說明人如何在執行過程中參與，以及如何跨管道與代理程式互動。

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

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

![人工協調不同代理程式，與透過共用頻道、Router 和 Worker 協調任務的方式比較。](https://offloop.org/editorial/learn/deepseek-super-agent/team-coordination.svg)

共用任務紀錄與事件路由，將團隊請求連結到正確的 Worker。

## DeepSeek Super Agent 如何運作：Router–Worker 架構

### Router–Worker 如何分派任務？

Super Agent 採用[Router–Worker 雙層架構](https://offloop.org/zh-TW/learn/exploring-deepseek-super-agent-design#section-2)。

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

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

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

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

實作細節可參考[公開原型的架構文件](https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/007-architecture.md)。

![雙層架構中，Router 負責共用脈絡、路由與互動，多個 Worker 在隔離的脈絡中執行任務。](https://offloop.org/editorial/learn/deepseek-super-agent/two-layer-architecture.webp)

Router 協調任務與使用者互動；Worker 執行任務，並向 Router 回報進度與結果。

完整架構圖見[繁中全文第 2 節](https://offloop.org/zh-TW/learn/exploring-deepseek-super-agent-design#section-2)。

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

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

![初始事件經由 Router 建立 Worker 並完成訂閱，同一討論串的後續事件直接送給該 Worker。](https://offloop.org/editorial/learn/deepseek-super-agent/subscription-direct-delivery.webp)

第一個事件先經過 Router；已訂閱討論串的後續事件，直接送給對應 Worker。

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

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

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

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

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

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

DeepSeek Super Agent 的 Router–Worker 架構

| 概念         | 作用                      |
| ---------- | ----------------------- |
| Ticket     | 記錄任務及其授權範圍。             |
| Assignment | 將任務連結到一次具體執行。           |
| 討論串訂閱      | 將後續訊息與事件送給對應執行者，減少重複路由。 |

初始請求建立任務關係，訂閱機制則讓後續事件直接送給 Worker。原文的[事件驅動設計](https://offloop.org/zh-TW/learn/exploring-deepseek-super-agent-design#section-3)說明了其中的過濾、路由與脈絡組織方式。

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

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

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

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

這些機制決定一則觀察到的訊息，如何成為獲准執行的工作。詳見原型的[授權設計](https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/002-authorization.md)。

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

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

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

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

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

原文進一步提出[運算、狀態與執行環境分離](https://offloop.org/zh-TW/learn/exploring-deepseek-super-agent-design#section-5)：代理程式迴圈在雲端執行，持久化狀態分開儲存，執行裝置透過輕量常駐程式接收指令。如此一來，執行代理程式的運算資源，就能與保存程式碼、相依套件及憑證的機器分開管理。

公開原型的[部署文件](https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/006-deployment.md)則描述較集中的部署方式：由 tmux 啟動 DeepSeek Harness，將資料庫存放在設定的狀態目錄中，並在執行機器準備任務工作目錄。

原文中的[Watchdog](https://offloop.org/zh-TW/learn/exploring-deepseek-super-agent-design#section-6)還會評估任務進度。獨立的代理程式工作階段會檢查 Worker 是否停滯或偏離目標。公開部署文件中的狀態檢查與重啟流程，主要針對處理程序、設定與執行錯誤。重啟服務與判斷任務是否有效推進，是兩種不同的能力。

[README](https://github.com/deepseek-ai/dsh-superagent-prototype)說明公開程式碼經過發布調整，與內部實作及文章描述的架構不同，部分設計仍留待後續探索。

## DeepSeek Super Agent 與子代理程式：任務協調有何不同？

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

![主代理程式決定是否委派給子代理程式，Router–Worker 架構則分開協調與執行職責。](https://offloop.org/editorial/learn/deepseek-super-agent/subagents-and-workers.svg)

子代理程式與 Router–Worker 系統都能平行工作，但協調職責的分配不同。

Super Agent 與單一代理程式搭配子代理程式的比較

| 比較面向 | 單一代理程式搭配子代理程式             | Super Agent                   |
| ---- | ------------------------- | ----------------------------- |
| 協調方式 | 主代理程式在執行過程中決定何時委派。        | 從架構上分開 Router 與 Worker 的職責。   |
| 平行工作 | 多個子代理程式處理委派的子任務。          | 不同 Worker 推進獨立任務。             |
| 後續訊息 | 由主工作階段或其他機制，將更新連結到進行中的工作。 | 透過任務關係與討論串訂閱，將更新送給執行者。        |
| 持續協作 | 取決於產品如何管理狀態與工作階段。         | 持久化任務、事件傳遞與跨任務協調是設計核心。        |
| 複雜任務 | 主代理程式可以直接執行，也可以委派。        | Worker 本身也能使用子代理程式，進一步組織執行工作。 |

Super Agent 的價值不只在於擁有多個代理程式。更值得研究的是，它如何減少對模型臨時決定是否委派的依賴，以及如何在執行中持續處理新輸入。原文的[雙層架構章節](https://offloop.org/zh-TW/learn/exploring-deepseek-super-agent-design#section-2)進一步說明了這項差異。

## DeepSeek Super Agent 與 Claude Code、Codex

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

![DeepSeek Super Agent 是開源研究原型，Claude Code 與 Codex 是程式開發產品。](https://offloop.org/editorial/learn/deepseek-super-agent/prototype-and-coding-products.svg)

Super Agent 是研究原型，Claude Code 與 Codex 是程式開發產品。

DeepSeek Super Agent 與 Claude Code、Codex 比較

| 比較面向  | DeepSeek Super Agent              | Claude Code                           | Codex                       |
| ----- | --------------------------------- | ------------------------------------- | --------------------------- |
| 定位與交付 | 提供程式碼與架構文件的開源研究原型。                | 程式開發代理程式產品。                           | 程式開發代理程式產品。                 |
| 主要價值  | 檢視、修改與重複利用任務協調、授權和事件路由機制。         | 可直接使用的程式開發、工具呼叫與子代理程式流程。              | 透過任務、討論串與工作區組織本機及雲端的程式開發工作。 |
| 協作重點  | 多人持續交辦與更新任務，由 Router–Worker 分工協調。 | 以主代理程式、子代理程式與實驗性 Agent Teams 組成的開發流程。 | 以獨立任務與討論串組織平行工作。            |
| 開始使用  | 部署原型，設定模型、帳號、權限與執行環境。             | 安裝、設定並使用現有產品介面。                       | 使用應用程式、CLI、IDE 整合或雲端任務。     |
| 維護責任  | 使用者維護原型及其執行環境。                    | 廠商維護核心產品功能，使用者管理設定與開發環境。              | 廠商維護核心產品功能，使用者管理設定與開發環境。    |

相關文件：[Claude Code 文件](https://code.claude.com/docs/en/overview)、[Agent Teams 文件](https://code.claude.com/docs/en/agent-teams)、[Codex 子代理程式文件](https://learn.chatgpt.com/docs/agent-configuration/subagents)、[Codex 雲端文件](https://learn.chatgpt.com/docs/cloud)。

## DeepSeek Super Agent 與 Grok Bot、Muse

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

![Super Agent、Grok Bot 與 Muse 在交付方式、工作組織和執行環境上的差異。](https://offloop.org/editorial/learn/deepseek-super-agent/prototype-and-assistant-products.svg)

Super Agent 的開源程式開發原型，與 Grok Bot、Muse 的比較。

DeepSeek Super Agent 與 Grok Bot、Muse 比較

| 比較面向      | DeepSeek Super Agent     | Grok Bot               | Muse                  |
| --------- | ------------------------ | ---------------------- | --------------------- |
| 定位與交付     | 開源研究原型。                  | 代理程式產品。                | AI 助理產品。              |
| 主要方向      | 協調多人、多項任務與多個執行者。         | 由不同 Bot 組織持續任務與脈絡。     | 個人多工與持續助理體驗。          |
| 工作組織      | Router、Worker、任務紀錄與事件訂閱。 | 各 Bot 維護自己的脈絡，並使用共用資源。 | 透過主要對話與側邊對話組織工作。      |
| 脈絡與記憶     | 圍繞任務與事件組織脈絡，並持久保存狀態。     | 依 Bot 組織工作脈絡。          | 使用者能檢視與編輯的持久記憶。       |
| 執行環境      | 由使用者設定主機與儲存庫。            | 同一帳號的 Bot 共用持久化雲端電腦。   | 專用虛擬機器提供瀏覽器、檔案與終端機功能。 |
| 開發者可取得的資料 | 原始碼、架構文件與實驗設計。           | 產品功能與公開文件。             | 產品功能、公開介紹與研究說明。       |

相關資料：[Grok Bot 文件](https://docs.x.ai/grok-bot/overview)、[Muse 介紹](https://introducing.muse.ai/)、[Muse 安全設計](https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse)。

## DeepSeek Super Agent 實驗：延遲與 Token 用量

[初步實驗](https://offloop.org/zh-TW/learn/exploring-deepseek-super-agent-design#section-7)使用約 300 則訊息，其中約 20 則是工作請求，其餘包含閒聊、追蹤訊息、停止請求與 CI 通知。

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

![Super Agent 與其他三種排程設定的工作請求累計到達及完成曲線，每種設定執行五次。](https://offloop.org/editorial/learn/deepseek-super-agent/ablation-study-original.jpg)

黑線表示到達的工作請求，彩色曲線表示各設定完成的任務，取五次執行的平均。訊息間隔與模擬工作時間縮短為四分之一，模型呼叫時間不縮放。

![四種排程設定的 P50、P95 完成時間與 Token 用量實驗結果。](https://offloop.org/editorial/learn/deepseek-super-agent/experiment-results.webp)

四種設定的任務完成時間與 Token 用量，每種設定以模擬程式開發工作執行五次。

DeepSeek Super Agent 的完成時間與 Token 用量

| 設定                   | 完成時間 P50 | 完成時間 P95 | 每次執行的快取讀取 Token |
| -------------------- | -------- | -------- | --------------- |
| Super Agent          | 12.4 分鐘  | 15.7 分鐘  | 23.23M          |
| Super Agent，關閉訂閱直通   | 12.6 分鐘  | 15.5 分鐘  | 31.77M          |
| 單一工作階段加子代理程式，中性提示詞   | 20.4 分鐘  | 29.5 分鐘  | 6.05M           |
| 單一工作階段加子代理程式，優先委派提示詞 | 13.8 分鐘  | 29.0 分鐘  | 10.82M          |

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 拓樸本身更有參考價值：程式機制處理任務歸屬與事件傳遞，模型負責語意判斷與執行。詳見[公開架構文件](https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/007-architecture.md)。

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

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

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

## DeepSeek Super Agent 的適用情境與限制

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

![從請求接收、協調到人工驗收的評估流程，包含審查、重做與成本。](https://offloop.org/editorial/learn/deepseek-super-agent/workflow-fit.svg)

將協調效益與人工審查、重做及維運成本一起評估。

主要限制包括：

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

原文的[開放問題](https://offloop.org/zh-TW/learn/exploring-deepseek-super-agent-design#section-8)也反映這些挑戰。將 Router 分片能提高吞吐量，卻會削弱共用脈絡。擴大參與者與執行裝置的範圍，也需要進一步釐清脈絡、權限與憑證的邊界。

## 如何開始：GitHub 儲存庫與安裝

[DeepSeek Super Agent GitHub 儲存庫](https://github.com/deepseek-ai/dsh-superagent-prototype)提供原始碼、[SETUP.md](https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/SETUP.md)與[部署指南](https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/006-deployment.md)。

![準備環境、安裝儲存庫與 profile，再啟動服務並完成設定。](https://offloop.org/editorial/learn/deepseek-super-agent/setup-workflow.svg)

準備環境、安裝儲存庫與 profile，再啟動並設定服務。

### 1. 執行需求

文件列出的需求包括：

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

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

複製儲存庫：

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

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

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

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

### 3. 安裝並執行 DeepSeek Super Agent

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

```bash
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`設為要使用的絕對路徑，再啟動服務：

```bash
scripts/dsh-superagent start
scripts/dsh-superagent status
```

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

## DeepSeek Super Agent 常見問題

### DeepSeek Super Agent 開放原始碼嗎？免費嗎？

公開原型採 MIT 授權。執行時需要模型推論與運算資源，因此仍有模型用量、基礎設施與維護成本。

### 多個人能向代理程式交辦任務嗎？

可以。設定中的身分與授權規則，決定誰能交辦及更新任務。

### Super Agent 能主動執行自己發現的任務嗎？

自動執行需要先設定對應的授權規則。預設觀察模式會辨識並記錄推斷出的工作，不會執行。

### Super Agent 是 DeepSeek 的新模型嗎？

Super Agent 是在 DeepSeek Harness 上執行的系統架構，負責組織模型、工具、事件與執行工作階段。底層的理解、推理與程式碼產生，仍由設定的模型完成。

## 參考資料

DeepSeek Super Agent 技術文章最初以簡體中文發布。閱讀繁體中文全文及原有配圖：

[Super-agent 設計探索：邁向更自主的代理程式系統](https://offloop.org/zh-TW/learn/exploring-deepseek-super-agent-design)

* [\[1\] DeepSeek 官方網站](https://www.deepseek.com/en/)
* [\[2\] DeepSeek Harness 官方網站](https://www.deepseek.com/en/harness/)
* [\[3\] DeepSeek 的 X 帳號：@deepseek\_ai](https://x.com/deepseek_ai)
* [\[4\] DeepSeek Harness 的 X 帳號：@DeepSeekHarness](https://x.com/DeepSeekHarness)
* [\[5\] DeepSeek Harness GitHub 儲存庫](https://github.com/deepseek-ai/deepseek-harness)
* [\[6\] DeepSeek Super Agent 原型 GitHub 儲存庫](https://github.com/deepseek-ai/dsh-superagent-prototype)
* [\[7\] Super Agent 安裝說明](https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/SETUP.md)
* [\[8\] 部署指南](https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/006-deployment.md)
* [\[9\] 授權設計](https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/002-authorization.md)
* [\[10\] 執行設計](https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/003-execution.md)
* [\[11\] 公開原型架構](https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/007-architecture.md)
* [\[12\] DeepSeek Harness 原始 X 長文](https://x.com/DeepSeekHarness/status/2116857257245987236)

更新於 2026 年 11 月 6 日