DeepSeek Super-agent 對比 Claude Code、Codex：6 個維度看清區別在模型還是調度系統

作者注：DeepSeek 開源 Super-agent 研究原型後，它與 Claude Code、Codex 的真正差異在哪裏？本文從 6 個維度拆解模型、編程工具與調度系統三層能力，給出不同工作模式下的選擇建議。

2026 年 10 月 31 日，DeepSeek Harness 團隊發佈技術文章《Super-agent 設計探索：邁向更自主的 Agent 系統》，並在官方 GitHub 以 MIT 協議開源了配套原型 dsh-superagent-prototype。常駐 Router + 獨立 Worker 的雙層調度架構迅速引發討論，Bloomberg、南華早報等媒體都把它放到與 Claude Code、Codex 競爭的背景下報道。

這不是又一篇“誰取代誰”的站隊文章。倉庫本身明確標註爲研究原型，Claude Code 與 Codex 也早已不是單會話工具。DeepSeek Super-agent 對比 Claude Code、Codex，真正值得問的是：差異來自底層模型，還是來自 Agent 的調度系統？

核心價值：讀完本文，你將分清三者分別處在哪一層，理解 DeepSeek 設計側重的實際意義，並能根據自己的工作模式選擇合適的工具組合。

DeepSeek Super-agent 核心信息速覽

先把事實邊界擺清楚。DeepSeek Super-agent 不是一個新的基礎模型，而是一套圍繞大語言模型構建的 Agent 系統架構；當前公開的也只是研究原型，不是正式商業產品。

截至 11 月 2 日，項目頁面顯示約 8900 個 Star、898 個 Fork，這個數字仍在變化。需要強調的是，Star 數只代表關注度，既不能說明真實安裝量，也不能說明編碼成功率。

DeepSeek Super-agent 想解決什麼問題

DeepSeek 團隊的出發點很有意思：隨着模型單任務能力變強，效率瓶頸開始從模型能力轉向人類注意力。團隊根據自身經驗認爲，一個人通常只能有效跟進約 3—5 個活躍 Agent 會話，原因包括上下文分散、頻繁切換窗口、任務結束後要人工下達下一步指令、工具調用阻塞會話、本地設備休眠導致任務中斷等。

這個 3—5 個會話的數字是 DeepSeek 團隊的經驗判斷，並非行業統計。但它清楚地揭示了 Super-agent 的研究方向：不是讓模型更聰明，而是把會話調度、事件處理和上下文管理從“人”轉移到“系統”。官方爲此提出了 Continuous（連續性）、Productive（高生產力）、Proactive（主動性）、Persistent（持久性）四個目標特徵，這些是設計目標，不代表原型已全部實現。

DeepSeek Super-agent 對比 Claude Code、Codex：先分清三個層級

討論“誰更強”之前，必須先承認三者不在完全相同的產品層級。Claude Code 和 Codex 是面向編程工作的 Agent 產品及工具生態；Super-agent 則側重在 Agent 外層建立持續在線、事件驅動、多任務協調的運行機制，實際推理和工具執行仍依賴底層模型與 DeepSeek Harness。

因此比較應拆成三層：模型能力決定單步推理和代碼生成質量，編程工具能力決定能否讀寫文件、跑測試、提 PR，調度系統能力決定多個任務如何被接收、分派、追蹤和交付。把三層混在一起比，很容易得出誤導性結論。

下面按 6 個維度對比目前公開的能力機制。注意，這張表比較的是“機制”，不是同條件性能排名。

每一行的實際意義不同。“單任務編程”決定你日常寫代碼的體驗；“事件觸發”和“後臺運行”決定能否讓 Agent 在你不盯着時幹活；“上下文管理”決定任務一多時會不會互相污染；“部署成本”則直接決定團隊願不願意先投入時間。

Claude Code 的多 Agent 能力並不弱

按 Anthropic 官方文檔，Claude Code 的 Subagents 擁有獨立上下文窗口，可設置專門系統指令、限制工具範圍、指定不同模型，還能在後臺並行開展研究和部分實現任務。實驗性的 Agent Teams 更進一步：一名 Lead 加多個 Teammate，各自是獨立的 Claude Code 會話，共享任務列表，隊友之間還能直接發消息。該功能默認關閉，官方也提醒它會增加協調開銷和 Token 消耗。

事件與持續運行方面，claude-code-action 可以響應 Issue、PR 評論中的 @claude 並在合適配置下把 Issue 轉爲 PR；Channels 以研究預覽形式，通過 MCP 把聊天消息、Webhook、CI 結果推入正在運行的會話，但要求會話保持運行。此外還有會話內 /loop、桌面端定時任務和雲端定時任務，部分任務可以在本機關閉後由雲端繼續。所以“Claude Code 只能被動等待輸入”早已是過時印象。

Codex 的多任務能力：產品與 API 要分開看

Codex 可以藉助 Git Worktree 爲同一項目創建多個獨立工作目錄，讓不同會話並行修改不同分支。Codex Cloud 在隔離工作區中分析代碼、實現修改、運行測試，本機關閉後雲端任務仍可繼續。ChatGPT/Codex 生態也已支持後臺定時任務，以及面向具備資格用戶的 GitHub 等應用事件觸發和 PR 活動過濾。

這裏有一個容易混淆的點：OpenAI Agents API 與 Responses API 提供的 Multi-agent 能力（主 Agent 分派子 Agent、子 Agent 獨立上下文）屬於 API 能力，不能直接等同於 Codex 所有產品界面的默認功能。同樣，OpenAI Cookbook 介紹的“CI 失敗後用 GitHub Actions 調用 Codex CLI 生成修復 PR”是一種工作流搭建方式，不是 Codex CLI 開箱即帶的內置功能。

DeepSeek Super-agent 的 Router + Worker 調度

DeepSeek 原型的核心流程可以概括爲 Source → Trigger → Eval → Ticket → Assignment → Executor → Result。事件從 GitHub 或飛書進入，先經過確定性規則做權限過濾，再由模型判斷是否需要建任務；被接受的任務生成獨立 Ticket，分配給擁有獨立工作目錄的 Worker，結果再沿原渠道返回，比如一個 GitHub PR。

Router 是長期運行的主會話，負責接收消息、維護全局上下文、判斷是否建任務、檢查授權、分配和追蹤任務，原則上不承擔複雜編碼。官方認爲正因如此，Router 在某些情況下可以選用較輕量的模型來降低調度成本。Worker 則接收明確工單，在隔離目錄中寫代碼、跑測試、處理後續反饋並提交結果。

真正的區別：DeepSeek Super-agent 調度系統的設計側重

既然 Claude Code 和 Codex 都已有多 Agent、後臺和事件能力，DeepSeek 的差異化在哪裏？答案不在“有沒有”，而在“誰來管理任務”以及管理的範圍。

常規的主 Agent 分派子任務，或 Agent Team 的 Team Lead，往往深度參與單個複雜任務的規劃、協調和結果合併。DeepSeek 的 Router 則更重視跨任務的高層協調：一個常駐 Router 同時管理多個相對獨立的工作事項，用戶只面對一個邏輯上的 Super-agent，直接在 GitHub、飛書等工作渠道交互，不必自己管理每個 Worker 會話。

DeepSeek 官方也坦率承認，如果把 Agent Team 的主 Agent 配置成只處理全局交互和分派、不親自執行，同樣能形成類似的雙層架構。所以 Router + Worker 並非別人無法實現的獨有能力，真正的差異是把常駐監聽、跨任務路由和統一工作上下文系統化的程度。具體體現在三點：

• 常駐 Router：作爲長期在線的主會話存在，而不是每次任務臨時拉起的協調者，全局上下文可以跨任務延續。
• 事件訂閱直通：已訂閱某個 Thread 的 Worker 可直接接收後續事件（如同一 PR 的新評論），減少 Router 的重複分派。
• 保守的主動性：任務分爲 Explicit（明確請求）與 Inferred（推斷候選），推斷出的工作默認 observe 模式，只記錄不執行，PR 自動合併默認關閉。

DeepSeek Super-agent 官方實驗數據怎麼讀

DeepSeek 做了一組合成調度實驗：每次約 300 條消息，其中約 20 條是工作請求，其餘是閒聊、後續反饋、取消和 CI 消息；編程工作用耗時的模擬工具替代，每種方案運行 5 次。

這組數據最有價值的信息有兩條。其一，與優先委派的單會話方案相比，Super-agent 的 P50 優勢很小，但 P95 長尾明顯更短，說明雙層架構的收益主要在“任務一多時別拖尾”。其二，移除訂閱直通後完成時間幾乎不變，緩存讀取卻從約 2320 萬升到約 3180 萬，可見訂閱直通的主要作用是減少 Router 重複處理，而非提速。

但必須劃清邊界：這是調度實驗，不是代碼生成質量測試；對照組是特定提示詞下的單 Session + Subagent，不是 Claude Code 或 Codex 完整產品的同條件實測。因此它不能證明真實編程效率提升 39% 或 47%，更不能用來製造三方速度排行榜。官方另一組 Router 批處理測試顯示，事件每分鐘約 40 條時平均批次增至 2.8，每個決策分攤推理時間降至 1.6 秒，同樣只說明當前測試負載下的可用性。

DeepSeek Super-agent 的成本與安全邊界

更快的代價是更多 Token。在合成測試中，Super-agent 的緩存讀取量約是中性單會話方案的 3.8 倍，但這不等於總費用增加 3.8 倍，最終費用還取決於模型價格、緩存命中、輸入輸出 Token 量以及 Router/Worker 各自用什麼模型。官方也尚未公佈每個真實工單的平均花費。

作爲參考，以下是 DeepSeek 官方 API 在 2026-11-02 的價格（美元 / 100 萬 Token），這是模型費率，不是 Super-agent 的收費套餐：

此外 Search、Fetch 各爲每 1000 次成功請求 $0.75，自 2026 年 11 月 1 日北京時間 00:00 起計費，只在實際調用時產生。部署者還要算上服務器資源、持續運行開銷和人工維護成本。Claude Code 與 Codex 則涉及訂閱、API、雲端執行等不同計劃，三者目前沒有統一的“每個合格 PR 成本”可比。

💰 成本管理建議：多 Agent 架構的費用核心在於“哪個角色用哪個模型”。如果你想自己試驗 Router 用輕量模型、Worker 用強模型的組合，可以通過 API易 apiyi.com 用一個 API Key 接入多家主流模型，按量計費，便於在同一賬單裏觀察不同組合的 Token 開銷。

安全方面同樣不能忽視。官方部署文檔承認，Router 與 Worker 的專用預設運行在 danger-full-access 模式，默認以操作者的系統用戶身份執行，可能讀取主目錄文件、執行本地程序、接觸本地憑證。官方建議使用獨立系統用戶和獨立的 GitHub 機器人賬號。監聽外部評論和消息還帶來 Prompt Injection 風險；社區也出現了針對 commit 6337fc8 的第三方審計報告，指出管理接口校驗等潛在問題，但完整攻擊過程未被獨立復現，應視爲“潛在風險”而非已發生的事件。

DeepSeek Super-agent 影響分析

對開發者的影響

• 評估維度需要升級：選工具時不能只看底層模型分數，還要看事件接入、任務隔離、後臺運行和人工審覈機制是否契合團隊流程。
• 原型可用但不省心：社區用戶 xxxxkkkqq 在私有倉庫中成功把一個 Issue 推進到 PR，但也遇到通知收不到、部署檢查正常但消息未到達、中文系統語言導致測試斷言失敗等問題；另一位用戶在 WSL2 上一小時內發現 Node.js 24 進程識別和 GitHub 評論漏收兩個缺陷。
• 二次開發價值明顯：對能維護 TypeScript、GitHub 集成和模型 API 的團隊，這是一份完整的 Router、事件、工單、Worker、權限規則參考實現。

對行業的影響

• 競爭焦點外移：AI 編程的競爭不再只是模型對模型，Agent Harness、工作流設計和開發者體驗正在成爲同等重要的變量。
• “主動 Agent”走向規範化：DeepSeek 把“主動工作”與授權策略、observe 模式、人工驗收綁定，回應了“Agent 會不會浪費團隊注意力”的現實擔憂。

結合上述能力，可以按工作模式做出如下選擇：

🎯 選擇建議：工具組合並不互斥，很多團隊會讓 Claude Code 或 Codex 負責日常編碼，再用自建調度層處理事件和路由。搭建自建層時，可以先通過 API易 apiyi.com 獲取免費測試額度，對比不同模型擔任 Router 與 Worker 的效果。

用 API 復現 DeepSeek Super-agent 的 Router 思路

理解調度系統最好的辦法是動手寫一個最小版本。下面的示例用 OpenAI 兼容接口實現“輕量模型做路由判斷”，只演示思路，不代表 DeepSeek 原型的實際代碼：

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # API易 OpenAI 兼容接口
)

event = "PR #42 評論：CI 在 test_auth.py 失敗，請幫忙看看"
resp = client.chat.completions.create(
    model="ROUTER_MODEL",  # 替換爲控制檯中可用的輕量模型名
    messages=[{"role": "user", "content": f"判斷該事件是否需要建任務，只回答 YES/NO：{event}"}]
)
print(resp.choices[0].message.content)

import openai
from dataclasses import dataclass, field

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # 一個 Key 接入多家模型
)

ROUTER_MODEL = "ROUTER_MODEL"   # 輕量模型：負責路由判斷
WORKER_MODEL = "WORKER_MODEL"   # 強模型：負責具體任務
AUTHORIZED_USERS = {"alice", "bob"}  # 確定性規則：授權名單

@dataclass
class Ticket:
    thread_id: str
    task: str
    history: list = field(default_factory=list)

tickets: dict[str, Ticket] = {}

def router_eval(event: dict) -> bool:
    """先規則過濾，再由模型判斷是否建任務"""
    if event["user"] not in AUTHORIZED_USERS:
        return False  # 未授權：僅觀察，不執行
    resp = client.chat.completions.create(
        model=ROUTER_MODEL,
        messages=[
            {"role": "system", "content": "你是任務路由器，只回答 YES 或 NO。"},
            {"role": "user", "content": f"該消息是否是需要執行的工作請求？\n{event['text']}"}
        ],
        max_tokens=5
    )
    return "YES" in resp.choices[0].message.content.upper()

def worker_run(ticket: Ticket, text: str) -> str:
    """Worker 使用獨立上下文處理任務"""
    ticket.history.append({"role": "user", "content": text})
    resp = client.chat.completions.create(
        model=WORKER_MODEL,
        messages=[{"role": "system", "content": "你是代碼修復助手，給出修復思路。"}] + ticket.history
    )
    answer = resp.choices[0].message.content
    ticket.history.append({"role": "assistant", "content": answer})
    return answer

def handle(event: dict) -> str:
    tid = event["thread_id"]
    # 訂閱直通：已有 Ticket 的後續事件直接交給對應 Worker
    if tid in tickets:
        return worker_run(tickets[tid], event["text"])
    if router_eval(event):
        tickets[tid] = Ticket(thread_id=tid, task=event["text"])
        return worker_run(tickets[tid], event["text"])
    return "已記錄，未建任務"

print(handle({"thread_id": "pr-42", "user": "alice", "text": "CI 在 test_auth.py 失敗"}))
print(handle({"thread_id": "pr-42", "user": "alice", "text": "補充：只在 Python 3.12 下失敗"}))

這個示例體現了三件事：確定性規則先於模型判斷、Router 與 Worker 使用不同模型、同一 Thread 的後續事件直接進入已有 Worker 上下文。真實系統還需要工作目錄隔離、權限沙箱、狀態持久化和人工審覈，這些正是原型仍在完善的部分。

🚀 快速上手：上面代碼只需替換 API Key 和模型名即可運行。推薦在 API易 apiyi.com 控制檯查看當前可用模型列表，新用戶有免費測試額度，適合先低成本驗證調度思路再決定是否投入二次開發。

常見問題 FAQ

DeepSeek Super-agent 對比 Claude Code、Codex 核心要點 Key Takeaways

• 層級不同：Super-agent 是調度系統原型，Claude Code、Codex 是編程 Agent 產品。
• 多 Agent 不是獨佔：Claude Code、Codex 已有子 Agent、並行會話、後臺與事件能力。
• 真正差異在系統化：常駐 Router、跨任務路由、訂閱直通與統一上下文是設計重點。
• 實驗數據有邊界：合成調度實驗只反映調度表現，不代表編碼質量或三方排名。
• 速度換 Token：緩存讀取約爲單會話方案的 3.8 倍，費用需按模型組合具體覈算。
• 安全需前置：高權限運行與外部輸入注入風險，要求獨立賬號與人工驗收。
• 動手驗證更可靠：可通過 API易 apiyi.com 一個 Key 試驗多模型 Router/Worker 分工。

總結

DeepSeek Super-agent 對比 Claude Code、Codex 的核心結論：

1. 區別首先是層級：模型能力、編程工具能力、調度系統能力是三件事，混在一起比較沒有意義。
2. DeepSeek 的價值在調度設計：它把常駐監聽、跨任務路由和統一上下文系統化，並用授權與 observe 模式約束主動性。
3. 成熟度差距真實存在：原型已有 Issue 到 PR 的真實案例，但安裝、可靠性與安全仍待打磨，Claude Code 與 Codex 仍是日常編碼的穩妥選擇。

AI 編程的競爭正在從“模型誰更強”擴展到 Agent Harness、工作流和開發者體驗的綜合比拼。對大多數團隊來說，更務實的路徑是用成熟產品處理日常編碼，同時小規模試驗自建調度層。

推薦通過 API易 apiyi.com 統一接入多家主流模型，快速驗證不同模型在 Router 與 Worker 角色下的表現與費用。

📚 參考資料

1. DeepSeek Super-agent 官方原型倉庫：項目狀態、源碼與適用範圍
2. 鏈接：github.com/deepseek-ai/dsh-superagent-prototype

3. 說明：包含 README、部署文檔、授權機制與設計哲學文檔

4. DeepSeek API 官方定價：模型價格與 Search/Fetch 費用

5. 鏈接：api-docs.deepseek.com/quick_start/pricing

6. 說明：覈算 Router/Worker 模型成本的依據

7. Claude Code Subagents 與 Agent Teams 文檔：多 Agent 能力說明

8. 鏈接：code.claude.com/docs/en/sub-agents、code.claude.com/docs/en/agent-teams

9. 說明：瞭解子 Agent 獨立上下文與團隊協作機制

10. Claude Code Channels 與定時任務文檔：事件推送與持續運行

11. 鏈接：code.claude.com/docs/en/channels、code.claude.com/docs/en/scheduled-tasks

12. 說明：瞭解研究預覽功能的使用條件與限制

13. Codex Cloud 與 Worktrees 文檔：雲端任務與並行工作區

14. 鏈接：help.openai.com/en/articles/20001545-using-codex-cloud、learn.chatgpt.com/docs/environments/git-worktrees

15. 說明：區分 Codex 產品功能的官方依據

16. OpenAI Agents API Multi-agent 指南：API 層面的多 Agent 編排

17. 鏈接：developers.openai.com/api/docs/guides/agents-api/multi-agent

18. 說明：與 Codex 產品功能區分閱讀

19. DeepSeek Harness 社區實測討論：Issue 到 PR 的端到端報告

20. 鏈接：github.com/deepseek-ai/deepseek-harness/discussions/11706
21. 說明：瞭解原型真實運行情況與常見問題

作者：APIYI 技術團隊
技術交流：歡迎在 API易 官網首頁聯繫我們，更多多模型接入與 Agent 編排資料可訪問 docs.apiyi.com 文檔中心

延伸閱讀

• Magpie VS CC Switch：我的 settings.json無法同時愛上兩個人:對比 magpie 與 CC Switch 兩款 AI 編程工具切換器：改配置文件與本機網關兩條路線的差異、發佈節奏、場景推薦、五類人如何選，以及爲什麼兩者不能同時寫同一份 settings.json。
• 手把手教程：一個 Key 接上所有 Agent，用開源 magpie 統一接入 API 網關（以 Claude Code、Codex、Pi、Hermes 爲例）:一份能照着做完的教程：約 30 分鐘讓你機器上所有編程 Agent（以 Claude Code、Codex、Pi、Hermes 爲例）共用一個 API Key 和一個網關地址。含 magpie 界面截圖、逐步接入流程、原生配置對照和報錯排查表。
• T3 Code 上手教程：8 個步驟在手機上遙控 Claude Code、Codex、OpenCode:面向已在電腦上使用 Claude Code、Codex、OpenCode 的開發者，用 8 個步驟把編碼 agent 接到手機，講清遠程路線、權限模式、額度坑與 API易 網關接入方式
• Gemini 4 Argon vs Claude Opus 5.5：拆解谷歌 19 項評測表，4 個維度看清誰更強:基於 Google 官方 Gemini 4 Argon 評測表，逐項對比 Gemini 4 Argon 與 Claude Opus 5.5 在知識工作、智能體編程、長上下文、多模態等 19 項基準上的成績，結合 Artificial Analysis、Vals 獨立評測與價格、輸出上限、可用性差異，給出場景化選型建議。
• 科研人狂喜：177 個科研 Skills 一條命令裝完，直接起飛:手把手接入 K-Dense-AI 的 177 個科研 Agent Skills：先看清單、只裝需要的、補齊 Python 依賴、觸發並驗收，附排錯表與風險提示