调度能力开始影响智能体效率

一个能独立修复问题的 Agent，未必就能高效处理不断涌入的工作。任务增多后，谁来分派、如何避免相互干扰、怎样把结果交还给用户，都会影响整体效率。DeepSeek 探索的 Super-agent 架构，关注的正是这些发生在单项任务之外的问题。

爱范儿介绍的初步实验提供了一组对照：Super-agent 的任务完成时间 p95 为 15.7 分钟，中性提示配置下的传统单会话方案则为 29.5 分钟。不过，这组差异首先反映的是任务调度方式的不同，不能直接理解为代码写得更快或更好。

把会话管理交给系统

DeepSeek 团队观察到，一个人通常只能同时跟进 3 到 5 个活跃会话。这不是普遍适用的人类能力上限，但指出了一项实际负担：用户需要在窗口间切换，记住每项工作的背景，并跟踪执行进度。即使 Agent 可以承担更多任务，人也未必有精力逐一管理。

Super-agent 尝试把这部分工作转入系统内部。它采用 Router 与 Worker 两层结构：Router 统一接收不同平台的信息，维护跨任务上下文并分派工作；Worker 拥有独立的上下文和工具能力，负责具体执行，再把关键结果汇报给 Router，由后者与用户沟通。

这种分工的意义，在于让任务分派和任务执行各有明确位置。用户面对同一个助手，具体工作则可以交给多个 Worker 并行处理，不必由用户手动组织多个会话。

实验中的传统方案也支持 Subagent，并非完全不能分工。但在中性提示配置下，五次实验都没有调用 Subagent，任务全部留在主会话中执行，不断受到新消息干扰。由此看，工具具备分工能力，与系统能否稳定采用分工，是两个问题。Super-agent 用明确的架构安排，减少了对临场判断的依赖。

调度收益也有资源成本

独立执行并不意味着所有消息都要重新分配。Worker 接手某个 GitHub Pull Request 后，后续评论和状态变化可以通过订阅机制直接发送给它，无须每次都经过 Router。这让已经确定归属的事件继续进入对应任务，减少重复协调。

爱范儿列出的实验数据也显示了这一机制的作用：取消事件直通后，Router 需要做出的决定增加约 30%，总缓存读取量从 2323 万增加至 3177 万 Token，增幅约 37%。这说明，设计多智能体系统时，不仅要考虑能启动多少个执行者，还要考虑信息如何在它们之间流转。

不过，即使保留事件直通，Super-agent 的缓存读取 Token 消耗仍高于单会话方案，因为它需要维护多个独立会话。调度效率的改善伴随着额外资源开销，不能仅凭完成时间就认定它在所有场景下都更划算。

这组实验的边界同样重要。它模拟群聊和 GitHub CI 消息流，单次约有 300 条消息，其中约 20 条是真正的工作请求，各方案重复运行五次。实验采用合成消息和模拟耗时工具，主要检验调度与协作，没有直接评估真实编码质量。它支持的是特定实验条件下的调度收益，而非真实研发效率的全面结论。

Super-agent 目前仍是架构探索，虽已有内部实例和部分开源原型，并非正式推出的独立产品。本文的判断是：当 Agent 能独立完成更多工作时，分派任务、隔离上下文和汇总结果，正在成为值得单独优化的环节。它能否真正减轻人的管理负担，还需要把节省的协调时间、增加的资源消耗与实际任务结果放在一起衡量。