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 依赖、触发并验收，附排错表与风险提示