DeepSeek 公開了一套名為 Super-agent 的研究原型。它不只在單一對話裡完成一次程式修改，而是持續接收 GitHub 與團隊聊天裡的工作，把不同任務分派給 Agent，再將 PR 審查意見與 CI 結果接回原本的任務。
這次公開的重點不是新的 DeepSeek 模型，而是如何把 Coding Agent 變成能持續接案、分工與追蹤進度的團隊系統。本文整理它的 Router／Worker 架構、主動開工條件，以及和 Claude Code、Codex 的差別。
DeepSeek Super-agent 是什麼
DeepSeek Super-agent 是 DeepSeek Harness 團隊公開的 Coding Agent 研究原型，GitHub 專案名稱為 dsh-superagent-prototype。它以一個 GitHub repository 為工作範圍，接收獲准的開發請求，安排 Agent 執行，再回到原討論串交付結果；飛書／Lark 聊天整合可以選擇是否啟用。 官方 README 將它定位為供參考的研究程式碼，尚非正式 DeepSeek 產品。
Coding Agent 是能讀取專案、使用工具並修改程式的 AI 助手。模型負責理解問題與決定下一步，執行環境則提供檔案、終端機、工具與對話紀錄。 DeepSeek Harness 就是這類開源執行環境，採用插件架構；Super-agent 是安裝在其中、負責協調團隊工作的插件組合。
它要減少的是人工管理多個對話的負擔：收到需求後由誰處理、後續留言應交給哪項工作、什麼時候需要找人回答。專案的設計原則是減少占用人的注意力，只有獲得請求或團隊規則允許時才行動，並在有人需要採取動作或能使用結果時通知。這次公開的原型，也讓這些協作設計有了可以閱讀與修改的實作。 設計原則 說明了這套取捨。
Super-agent 與其他 Coding Agent 的差別
Super-agent 把團隊訊息、接案授權與任務追蹤放進同一套常駐流程。Claude Code 和 Codex 也能處理背景工作與自動化，三者的差別主要在接收任務的方式、工作如何分派，以及誰負責維運執行環境。以下比較截至 2026 年 11 月 2 日的官方文件。
| 比較項目 | DeepSeek Super-agent | Claude Code | Codex |
|---|---|---|---|
| 任務入口 | GitHub；可選飛書／Lark | 直接交辦、排程、API 或 GitHub 事件 | 直接交辦、排程、GitHub 審查或事件 |
| 接案判定 | 允許名單、團隊規則與接案模式 | 由使用者、排程設定或組織權限決定 | 由使用者、排程觸發或 repository 設定決定 |
| 工作分派 | Router 分派給各個 Worker | 主 session 可分派給 sub-agent | 主 thread 可分派給 subagent |
| 後續接續 | 訂閱討論串，收回留言與 CI 資訊 | 一般排程每次建立新 session；專案中可接續 thread | 可接續任務；排程可回到原對話 |
| 部署與維運 | 自行準備 Harness、模型服務與常駐環境 | 使用現成客戶端或雲端功能 | 使用現成客戶端或雲端功能 |
Claude Code 的 Routines 現在稱為雲端排程任務（scheduled tasks），可以在 GitHub 事件發生時開工，也能由 API 觸發，仍屬研究預覽。已有 Claude Code 工作流程時，可以先檢查這些入口是否足以處理固定的審查、維護或文件工作。相關背景可參考 Claude Code Routines 介紹 ，現行名稱與功能則以 官方排程文件 為準。
Codex 的 GitHub 整合支援 @codex review 與自動審查，也能透過其他 @codex 留言啟動以 PR 為上下文的 legacy cloud chat。桌面排程可處理本機專案或 worktree，並支援回到原對話持續跟進；網頁與行動版另有依方案開放的事件觸發功能。這些入口的執行位置與可用條件各有不同，詳見 GitHub 整合 與 排程文件 。
Super-agent 如何處理 GitHub 工作
Super-agent 由 Router 接收與分派工作，Worker 在自己的 session 和目錄執行，再將成果交付審查。以下以「獲准成員在 Issue 要求修正匯出功能」為流程示例，說明公開原型的運作方式。
Router 接收請求與分派任務
成員提及 Agent 帳號後，系統先依來源設定與允許名單判定這則訊息是否可提出請求，再進行任務路由。接受的新工作會建立 Ticket，記錄需求與授權範圍；若訊息屬於既有工作，則可接到對應任務。 任務模型文件 將這些外部訊息稱為 Trigger，將工作項目稱為 Ticket。
Worker 在獨立工作目錄執行
匯出功能的修正交給自己的 Worker session。任務目錄可透過準備指令建立 Git worktree，讓不同工作的程式變更分開；未設定準備指令時，Worker 會從空目錄開始。執行者依需求閱讀程式、修改與檢查，另有新任務時，系統依並行上限安排其他 Worker。 執行文件 說明了目錄準備與工作名額的管理。
後續討論與 CI 接回原任務
假設成員接著補充「只有空白欄位會出錯」，訂閱該討論串的任務就能收到這項資訊。PR 的審查意見與 CI 結果也可以沿著訂閱送給執行者，讓修正繼續推進。這些資訊仍受原任務範圍約束；若補充要求變成另一項功能，執行者需要交回重新路由。
需要人決定或回答時，任務會交出具體問題；成果準備好則進入待審查狀態。 網頁面板 優先列出需要人處理的工作，再呈現系統健康與任務歷史。使用者可以從原討論串接續需求，也能在面板追查處理進度。
Super-agent 何時會主動開工
Super-agent 會在收到獲准的明確請求，或自行發現的工作符合團隊規則時開工；後者還取決於接案模式。官方預設使用 observe，先評估並記錄候選工作，讓操作人員檢視它原本想做什麼。 授權文件 定義了以下三種模式。
| 模式 | 自行推斷的工作 | 獲准的明確請求 |
|---|---|---|
off | 不進入候選評估 | 可接受 |
observe，預設 | 評估並記錄原本會接受的項目，不建立新工作 | 可接受 |
auto | 通過評估且至少符合一項啟用規則時，可接受 | 可接受 |
observe 只限制自行推斷的工作，獲准使用者直接交辦的任務仍能執行。例如團隊可以先限定允許名單，再觀察「特定類型的錯誤回報是否值得處理」這類規則的評估紀錄；確認符合需求後，再決定是否啟用 auto。接收未提及 Agent 的訊息，還需要在對應來源開啟接收設定。
訊息的用途也分成兩種：既有任務收到 CI 失敗結果，可以把它當作修正工作的上下文；新的工作則要經過授權與接案判定。允許名單、規則與每項任務的授權範圍由主程式檢查，留言或引用文件無法自行改變這些設定。
使用 Super-agent 需要準備什麼
使用公開原型，需要自行準備 DeepSeek Harness、模型服務、專用 GitHub 帳號與持續運作的執行環境。這部分適合打算評估自行部署的開發者；官方提供 SETUP 指南 ，由 Coding Agent 協助收集設定並提出安裝方案。
| 準備項目 | 用途與條件 |
|---|---|
| 執行工具 | Node.js 22.19+ 或 24+、pnpm、Git 2.32+、Python 3.8+、tmux、GitHub CLI 2.48+ |
| Harness 與模型服務 | 使用符合原型相容範圍的 Harness，先配置 model provider；評估與執行設定可另指定模型 |
| GitHub repository | 位於 github.com，備妥本地 clone 與每項工作的 checkout 準備方式；目前不支援 GitHub Enterprise Server |
| Agent 帳號 | 專用 GitHub 使用者帳號，給予 repository 寫入權限，以其身分留言、推分支與開 PR |
| 聊天整合，選用 | 飛書／Lark App、Bot 與對應 CLI 設定 |
前置條件與相容版本應對照 部署文件 及專案的 package.json。原型需要讀取 Agent 帳號通知，因此這裡使用 GitHub 使用者帳號，GitHub App 無法代替該身分。
程式碼採 MIT 授權，執行費用則取決於模型 provider、任務量、重試與常駐主機。Router 的判定和 Worker 的實作都可能產生模型用量，多項工作並行也會增加資源需求。評估成本時，可以先限定 repository、允許名單與工作類型，累積實際用量紀錄後再調整規模。
Super-agent 原型的執行權限與限制
公開原型的 Router 與 Worker 以執行者的 OS 帳號權限運作，預設使用 danger-full-access，命令不逐條等待批准。這會影響部署位置、憑證配置與交付流程，需要與「誰能提出請求」一起規劃。
獨立工作目錄與系統隔離
Ticket 目錄與 Git worktree 用來分開程式變更，Worker 仍能依 OS 權限存取家目錄，或透過絕對路徑執行程式。官方建議使用只保存 Agent 所需憑證的專用 OS 帳號；帳號 wrapper 與命令封鎖設定提供預設行為，沒有建立完整的程序隔離。接收 GitHub 或聊天資訊的範圍，也應和執行帳號能讀到的資料一起檢查。
PR 合併與審查條件
安裝指南建議初期由人合併 PR。若另外設定自動合併，原型透過 Delivery requirements 提示詞要求 Agent 遵守條件，主程式沒有專門的合併判定邏輯。需要強制審查時，應在 GitHub 設定 branch protection、要求批准並取消過期批准；要維持人工合併，則省略合併用 CLI 或移除自動合併指示。這是 官方執行文件 提供的對應做法。
公開原型與長期維運
官方提醒，公開程式碼經過整理，與內部版本及設計文章描述的實作不同，部分設計仍是未來方向。實際評估時，可從公開版本的接案判定、工作追蹤、失敗恢復與交付品質著手。
Super-agent 適合哪些團隊
Super-agent 適合想自行控制接案規則、工作分派與 GitHub 協作流程，並能維護 Harness、模型服務及常駐環境的團隊。公開原型提供接案、分派與追蹤的參考實作，也可修改成符合內部流程的版本。
如果只需要定時檢查專案、審查 PR，或在特定 GitHub 事件發生後執行固定工作，Claude Code 與 Codex 現有的排程或事件觸發功能已有對應做法，也不必另行維護一套 Super-agent 環境。
常見問答
以下整理產品身分、使用入口與整合方式的常見問題。
Super-agent 是新的 DeepSeek 模型嗎
不是。它是建立於 DeepSeek Harness 的 Agent 協調系統，透過已設定的模型服務執行判定與工作；開源的是原型程式碼。
Super-agent 可以免費使用嗎
程式碼可依 MIT 授權使用；模型服務、主機及其他外部服務的費用，需要依所選配置計算。
沒有飛書也能使用嗎
可以。GitHub 就能作為請求與交付入口，飛書／Lark 是選用整合。
一般 DeepSeek 聊天使用者能直接開啟嗎
不能直接從一般聊天介面啟用這份原型。目前公開的使用方式是自行配置 Harness、模型服務與 repository，再透過設定好的 GitHub 或聊天來源交辦工作。
參考來源
- DeepSeek GitHub: dsh-superagent (Super-agent 研究原型)
- DeepSeek GitHub: DeepSeek Harness (Agent 執行環境)
- DeepSeek GitHub: 000 Philosophy (設計原則)
- DeepSeek GitHub: 001 Domain model (任務模型)
- DeepSeek GitHub: 002 Authorization (接案授權)
- DeepSeek GitHub: 003 Execution (執行與合併)
- DeepSeek GitHub: 005 Panel (監督面板)
- DeepSeek GitHub: 006 Deployment (部署與執行權限)
- DeepSeek GitHub: SETUP (設定指南)
- Claude Code Docs: Automate work with scheduled tasks (雲端排程與事件觸發)
- Claude Code Docs: Create custom subagents (子 Agent 的 context 與分工)
- ChatGPT Learn: Scheduled tasks (排程與持續跟進)
- ChatGPT Learn: Review GitHub pull requests with Codex (GitHub 審查與修正)
- ChatGPT Learn: Cloud environments (雲端任務環境)