DeepSeek Super-agent 深度：P95 15.7 分钟对比 29.5 分钟

一句话结论：DeepSeek 在 10 月 31 日晚公开的 Super-agent 架构，把多智能体系统的瓶颈从模型能力搬到了调度工程上，实测在 300 条消息、20 项真实请求的混合负载下，任务完成时间 P50 12.4 分钟、P95 15.7 分钟，比传统单 Session 方案的 P95 29.5 分钟快接近一半。

这篇架构长文没有发布新模型，也没有公布 API 价格。它交出来的是一套可以照着搭的系统设计：常驻的 Router 层负责全局协调，一批上下文隔离的 Worker 层负责并行执行，中间用事件驱动把主动性做出来，靠存算分离和外部 Watchdog 保证长期在线不崩。

值得注意的是，这套思路并不是凭空冒出来的。DeepSeek 内部跑 Super-agent 用的底座是自家开源的推理框架 DeepInfer，把算力和调度这两件事放在同一套栈里讨论。而在这之前，Vercel 推出的 durable-harness、微软开源的 Agensh，都在解决同一个问题的不同侧面：让编码智能体在长任务里活得更久、更并行。

瓶颈在人，不在模型

DeepSeek 提出 Super-agent 的起点是一个观察：一个人通常只能同时跟进 3 到 5 个活跃会话。

主流智能体的基本工作单元是单个 Session，不同 Session 之间彼此独立。用户想并行推进三件事，就得手动来回切窗口、自己记住每个会话聊到哪了。团队把这套状态称为 Session 认知负担。结论直接得有点扎人：单任务的上限取决于模型能力，多任务的上限取决于人的注意力。

这个瓶颈靠给现有 Agent 接个 CLI、MCP 或者外部连接器解不掉。硬扩会带出三个新问题：单会话同步阻塞、一个会话里多个任务的上下文互相污染、本地设备一离线后台任务就停摆。

DeepSeek 的解法是把 Session 从用户的认知负担里摘出去，变成系统的实现细节。用户面对的始终是同一个 Super-agent，它跨渠道记住自己说过什么。

双层架构：Router 调度，Worker 干活

Super-agent 整体分成两层。Router 层是常驻的全局路由节点，接管所有入口的人类交互，把跨任务的信息和决策汇总起来，充当全局的序点、协调点和记忆。Worker 层由若干上下文彼此隔离的执行会话组成，每个 Worker 专注啃一个任务，挂载完整的执行工具。

这个分工的取舍写得很直白。如果所有事件都塞进同一个 Session，上下文最连续，但受单个 ReAct Loop 串行执行的限制，吞吐上不去。如果每条事件都新开一个独立 Session，吞吐最高，可任务之间失去全局上下文，各个 Session 各自回话直接把交互搅乱。拆成两层，等于把连续性和吞吐量分别交给不同层负责。

Router 和常见的 Agent Team 有明显区别。Agent Team 是把一个复杂任务拆成若干步骤让成员协作，Team Lead 需要吃透细节、高频协调、推理负担很重。Super-agent 的 Router 只管任务之间的高层关联和分派，不介入单个任务内部的拆解。团队从实践里得出一个反直觉的结论：Router 的任务往往没想象中复杂，用轻量模型就够。

Router 也不容易被流量压垮，原因是批处理机制。外部事件平稳时，触发事件逐条进入 Router 会话，响应延迟很低。事件密集涌入时，上一轮推理期间积压的触发事件会攒起来，下一次模型调用一次性灌进去。Router 每步都是长输入短输出，合并的多个事件在 Prefill 阶段并行计算，单次请求耗时的增幅远慢于批处理规模本身。

Worker 之间默认不互相通信，各自汇报状态给 Router，由 Router 统一回给用户。冲突主要发生在共享工作环境里，比如两个 Worker 改同一个 Pull Request。只要它们都订阅了同一个事件流，就会收到同样的通知，有机会自己发现并化解冲突。

事件驱动：把主动性做出来

主动性是 Super-agent 和常规编码智能体最明显的分野。驱动它的不再是人手敲的提示词，而是环境里的半结构化事件，团队称之为 Trigger：群聊消息、邮件、日程提醒、代码审查评论、CI 运行结果。

真实工作场景的事件流是高噪音、低触发率的，绝大多数日常消息不需要智能体介入。每条事件都调一次大模型从头判断，延迟和算力都撑不住。DeepSeek 借用了计算机系统里的 Fast Path 和 Slow Path 概念，做成两级过滤。程序层作为 Fast Path，按事件来源、群组范围、用户白名单这类确定性条件直接放行或丢弃。过了程序层的候选事件交给语义层 Slow Path，由大模型结合上下文判断该不该行动。语义层同时是留给人的自然语言扩展点，改策略只要动提示词。

事件路由也分了两条路径。已经归属到某个任务的后续事件，比如同一个 Pull Request 下的评论、同一封邮件串里的往来，由程序直接发往对应的 Worker 会话，不再经 Router 转发，这就是订阅直通。没订阅的新事件才走回 Router，由它判断是新建任务还是改派。

上下文管理上，文章把上下文窗口当作缓存来经营。Inline 是把近期很可能用到的信息直接内联进窗口，省掉额外的工具调用往返。Spill 是把超出预算或低频使用的完整内容留在窗口外，只留引用和摘要，需要时再由模型调用工具读取。渐进式的做法是先给对象 ID 和内容摘要，再利用局部性把紧密关联的内容按需内联，比如内容前 50 字、相邻的聊天消息、被回复的那条消息。放不下的部分被 Spill 出去，并保留续读入口。

再往上一层是链式召回。系统给每个触发事件、每条事件流、每个 Worker 会话都赋予唯一 ID，内联时把关联对象的 ID 一并带进上下文，底层就构成了一张引用图。模型需要历史细节时，可以从当前事件出发沿引用关系一步步按需召回。走通一条典型路径是：从当前消息找到所属事件流，从事件流内联的 ID 追到相关 Worker 会话，再从 Worker 找到它关联的另一个代码评审事件流。

投机执行：先动手，再看要不要提交

投机执行这一节是整套设计里最有意思的部分。Agent 在结果是否会被采用还不确定的时候，根据环境信号先在后台尝试，有价值就交付，没价值就丢弃。代价是额外的后台算力，换来的是更少的人类等待和介入。

在个人助手场景里，收到会议邀约时，智能体在后台核对日程冲突、搜集背景资料、备好回复草稿，等人过目后直接确认发送。研发协作场景里，Harness 内部用户群配了静默复现并修复策略：有人在群里反馈问题，智能体在后台尝试复现并寻找修复方案，只有确认问题存在且找到简单修复路径时才提交，否则全程保持安静。

论文里描述的场景是这样的：群内还在讨论解决方案时，Super-agent 已经在后台提交了修复 Pull Request。

存算分离与外部 Watchdog

传统本地 Agent 把三类资源绑在同一台设备上：推进循环的计算、需要持久保存的会话状态、以及代码仓库和本地工具链这些执行环境。设备一休眠，智能体就停。

DeepSeek 分两步解耦。第一步把计算和状态分开，Agent Loop 跑在云端无状态弹性计算容器里，会话状态存数据库。无状态容器可以水平扩展、可以重启替换，Agent 因此摆脱单台设备的生命周期限制。

第二步是计算和执行环境分离。没有把整个环境搬到云端，是因为云端重建真实环境要面对未提交的本地修改、私有凭据、内网服务依赖、特殊硬件和工具链，同步成本高还容易漏信息。做法是 Agent Loop 常驻云端，重状态执行环境留在原地，端侧只部署一个轻量守护进程。这个守护进程不保存会话状态，只负责执行命令和返回结果。云端智能体通过统一接口按需访问端侧环境，可以是日常开发机、也可以是云端托管机器或按需创建的计算环境，BYOM 这个模式因此成立。即使设备间歇在线，重新上线后云端智能体也能自动触发并执行相应任务。

Watchdog 解决的是另一类问题。常规监控只看进程还活着、接口还能不能用，但智能体的异常往往是进程活着而事情没进展：模型陷在无效循环里、任务没有实质进展、执行方向跑偏、状态恢复失败。文章在主系统之外配置了一个独立的 Watchdog 会话，用定时消息驱动，构成外部的控制回路。它会处理接口报错、处理状态恢复失败、判断各个 Worker 有没有实质进展、方向有没有偏离整体目标，异常时及时介入修复，外部偶发故障则持续复查直到恢复正常。Watchdog 本身也是具备完整工具能力的智能体会话，维护者可以直接用自然语言问它故障原因、让它在线修正主系统行为。

与 Anthropic 提出的脑手分离思路对照来看，差别主要在场景。Anthropic 那套假设托管服务、按需创建的沙箱、客户 VPC 内的资源；DeepSeek 这套面向的是用户日常使用、可能间歇在线的个人机器，目标是保留本地未提交的修改和本地凭据。

实验数字：延迟降一半，token 多花三成

文章做了两层实验。端到端实验用群聊消息和 GitHub CI 消息混合驱动，单次约 300 条消息，其中约 20 条是真实工作请求，其余是闲聊、跟进、叫停和 CI 消息。编码工作换成一个只消耗时间的工具，测的是调度协作能力，编码执行能力被刻意排除在外。每种方案重复跑 5 次，消息间隔和工作时长都按四分之一缩放，模型调用耗时用真实值，累计曲线是 5 次均值。

对比四种方案：完整 Super-agent、去掉订阅直通的 Super-agent、单 Session 加 Subagent 工具配中性提示、单 Session 加 Subagent 工具配优先委派提示。

中性提示那组最能说明问题。5 次运行里一次都没调用 Subagent，所有工作都在主 Session 里执行，主会话不断被新消息打断，P95 拖到 29.5 分钟。优先委派提示组 5 次里有 4 次成功委派，完成时间缩短，但剩下 1 次模型认为工作很小而自行执行，这次形成图里那条长长的尾部。

订阅直通的效果体现在 token 上。去掉直通之后，任务完成时间和完整版基本一致，Router 需要做出的决定多了约 30%，总读缓存 token 从 2323 万涨到 3177 万，增幅约 37%。也就是说在这套负载下，直通机制并没有明显加快任务完成速度，价值在于让 Router 少做决策、省下可观的 token 和推理开销。

Router 层的压力测试单独做了一遍，Router 调真实模型，Worker 用 Mock 模型，需要 Router 决策的触发事件到达速率从每分钟约 1 条逐步提到每分钟约 40 条。

这组数据解释了为什么端到端实验里即使去掉直通、Router 峰值负载上升，仍没撞上吞吐瓶颈。批大小增长快于单次请求耗时的增长，拥堵时自动合并积压事件。也正因如此，在当前团队规模下没有必要过早把 Router 水平切分成多个会话，那样会牺牲全局上下文连续性。

成本层面还有一组可查的数据。DeepSeek V4-Pro 每百万 token 的输入与输出价格约为 1.32 美元和 3.96 美元，量级上低于同期的 GPT-5.5 和 Opus 5.5。把这个价格放进 Super-agent 的语境里看才有意义：这套架构要用多个独立会话换并发速度，多会话意味着读缓存 token 消耗更高，模型的单位价格直接决定这套调度架构能不能跑得划算。这和 AKV 缓存工程让智能体成本降 27.7% 指向的是同一件事，缓存命中率和 token 单价决定智能体的经济性。

值得一提的是模型侧的进展。DeepSeek V4.1 Flash 的因果编码器解码器架构把输入激活压到 8B、KV Cache 缩小 437 倍，具体拆解见 这篇。更轻的模型和更省的缓存，恰好是 Super-agent 这种多会话架构成本模型成立的前提。

还没解决的问题

文章末尾主动列了四类开放问题，这种坦白在技术长文里并不常见。

一是双层架构如何扩展。当前是单个常驻 Router 会话加订阅直通、Worker 之间不通信的简化组合，什么时候需要水平切分 Router、切多细、Worker 什么时候需要直接通信、用什么协作拓扑，以及如何针对 Router 的事件判别、批量分派、上下文召回做专项训练，都还是开放问题。跨月甚至更长周期的长程记忆瓶颈同样没解。

二是脱离 Session 之后人怎么跟智能体协作。聊天窗口还是不是最佳产品形态，会不会更多进入 GitHub Issue、Pull Request 这类领域特化界面，用户界面里的一个会话怎么对应底层多个会话，人怎么在后台执行过程中介入接管，都取决于工作领域和个人风格。

三是上下文边界与 A2A。单个 Super-agent 实例内部共享一个全局上下文，组织需要按共享或隔离需求划分实例边界，多个隔离实例之间的 Agent-to-Agent 通信难点集中在安全、可靠通信、权限边界和上下文不共享。

四是安全与隐私。云端 Agent Loop 被入侵或遭遇提示词注入，所有已连接的端侧设备都可能受控，私有代码、敏感数据和本地凭据会进入模型上下文。需要的能力是让智能体使用凭据却不接触凭据本身，以及端侧执行环境与云端智能体之间的信任与权限隔离。

与 Anthropic 在编码智能体上的另一条路线对比会更清楚。Claude Code 走的是把审批模式做细的路子，比如 免批准变量的 6 种权限模式差异，它假设人始终在场并保持掌控。Super-agent 的前提是人会逐步从底层执行上移到高层决策和验收，人的角色是定目标和验收结果，而不是逐条盯住每次工具调用。

另一条并行的多智能体路线来自 Kimi 的 Swarm 与 Tower 多智能体架构，走的是桌面编程助手的形态。两者共同的地方是都承认单会话装不下真实工作，差别在于 Super-agent 把重点放在跨会话的连续性和事件驱动上。

开源原型与真实状态

跟长文同步公开的还有研究原型 dsh-superagent-prototype，以插件组合包的形式运行，主要围绕 GitHub 仓库工作，也可以接入飞书。官方明确说明这是为了验证技术路线而提供的原型，不是 DeepSeek 的正式产品，与内部版本和长文中的完整实现不完全一致，部分设计尚未落地。原型采用 MIT 协议。

文章还点明了一件事：异步任务机制已经在 DeepSeek Harness 里实现，但尚未默认开启。多信道规范同样偏保守，团队验证过的一条硬性规定是即时通讯渠道单次回复不超过 100 词，GitHub、邮件和文档这类异步渠道则要求结构化、高信息密度，创建或更新 Pull Request 时得给完整问题背景、改动说明和验证结果。

DeepSeek 内部基于这套架构构建的 Super-agent 实例已经在持续运行，日常参与问题复现与修复、代码审查响应，以及 DeepSeek Harness 自身的迭代。

常见问题

Super-agent 和多智能体系统有什么区别？

普通多智能体系统围绕单个复杂任务做步骤拆解和角色协作，Team Lead 承担很重的推理负载。Super-agent 的分工是任务之间的，Router 只做高层分派不碰任务内部拆解，Worker 各自上下文隔离并行推进。两者可以嵌套使用，Worker 内部照样能再开子智能体。

Super-agent 会不会乱发邮件、乱改代码？

设计上做了三层防护。程序层过滤按来源、群组、白名单做确定性准入，语义层再由模型判断是否值得行动，投机执行只在确认问题存在且找到简单修复路径时才提交结果，其余情况保持安静。安全与隐私被官方列为尚未解决的核心问题，包含凭据隔离与端侧环境信任边界。

这套架构现在能用吗？

可以用的是原型。dsh-superagent-prototype 已开源，MIT 协议，官方定位是验证技术路线的原型而非正式产品。异步任务机制已经在 DeepSeek Harness 中实现但未默认开启，DeepSeek 内部运行的实例不对外开放。成本侧的参考是 V4-Pro 每百万 token 约 1.32/3.96 美元。

相关阅读

• DeepSeek 开源推理框架 DeepInfer：GPU 占用减 35%、成本降 28%
• Vercel 开源 durable-harness：5 个编码智能体框架崩溃续跑机制拆解
• 微软开源 Agensh：1024 智能体协同，通过率 55.06%
• DeepSeek V4.1 Flash 深度解读：8B 输入激活、KV Cache 缩 437 倍
• Kimi Code Desktop 深度：Swarm 与 Tower 多智能体架构，桌面编程助手的下一阶段