DeepSeek 把 Agent 拆成 Router 和 Worker：多任务瓶颈不是模型，是人

DeepSeek 团队发了一篇很长的技术文章，讲他们内部跑的一个叫 Super-agent 的系统。核心观点一句话就能说完：单任务的上限是模型能力，多任务的上限是人的注意力。

他们观察到一个很具体的数字：一个人同时最多跟进 3 到 5 个活跃 Session。再多，上下文就开始串台。有网友在评论区说，自己同时开三个 Session 就把 A 的需求贴进 B 了。这个上限很真实。

传统 Agent 以 Session 为基本单位，每个 Session 相互隔离。用户并行推进多项工作时，得手动切换、记住每个 Session 的上下文。DeepSeek 的解法是把工作拆成两层：Router 层和 Worker 层。

Router 层常驻，只负责跟人聊天、分派任务、维护全局上下文。它不直接执行任务，甚至可以不配 Bash 工具。Worker 层由多个隔离的 Session 组成，每个 Worker 专注一个任务，拥有完整的执行工具，但不直接跟人交互，只向 Router 汇报。所有对外回复都由 Router 统一出口。

这个结构像什么？像一个项目经理带一群工程师。项目经理不写代码，只拆任务、盯进度、对外沟通。工程师在各自的环境里并行干活，互不干扰。文章里还提到一个细节：Worker 之间通常不需要直接通信，冲突往往出现在共享工作环境里，比如同一个 Pull Request。只要 Worker 都订阅了对应的 Thread，就能收到相同的事件通知，自行发现和解决冲突。少数跨任务协同由 Router 中转。

除了双层架构，文章还讲了几个配套设计：事件驱动，用程序策略加模型策略两级过滤环境里的噪音；全双工交互，把耗时的工具调用改成异步的 start() 和 stop()，后台任务运行时前台还能继续对话；计算、状态与环境分离，Agent Loop 跑在云端，执行环境留在本地，通过轻量 daemon 连接；外加一个独立的 Watchdog，监控 Worker 有没有陷入无效循环或偏离目标。

实验数据也有意思。他们用群聊和 GitHub CI 消息流驱动四种方案，每种跑 5 次。Super-agent 的任务完成时间 p50 是 12.4 分钟，p95 是 15.7 分钟。作为对比，单 Session 加 Subagent 工具、用中性提示词的那组，p95 到了 29.5 分钟。差距接近一倍。原因也不复杂：单 Session 方案下，主会话经常决定自己直接干活，新消息一来就被打断，完成时间又长又不稳定。双层架构把这个问题从系统层面解决了，不依赖提示词工程和模型的临场判断。

这套设计里最值得琢磨的一点：它把 Session 从用户的认知负担里拿掉了。文章的原话是，让用户手动管理 Session，很大程度上是从底层 LLM API 延续下来的设计惯性。Session 应该是系统的实现细节，不是用户的项目管理单位。这个判断有道理。现在多数 Agent 产品让用户自己开新会话、自己记上下文，本质上是把系统该干的活推给了人。

当然，文章也列了没解决的问题。比如规模扩大后 Router 层怎么切分，长期记忆怎么处理，脱离 Session 后产品交互长什么样，还有安全与隐私。尤其最后一点：云端 Agent Loop 接入大量端侧设备，一旦被提示词注入攻破，所有连着的设备都可能被控制。这个问题不解决，Super-agent 只能在小范围可信环境里用。

有网友在讨论里提到一个更隐蔽的难点：员工在 IM 里说“按常规标准执行”，AI 就懵了。什么是常规标准？可能是某次线下会议达成的，可能是公司很早以前的惯例，员工都知道，但没有文档。这种隐形的约束、团队默契、口头承诺，Agent 不知道。这可能是比架构更难的骨头。

原型已经开源，叫 dsh-superagent-prototype。文章明确说这只是验证技术路线的原型，不是 DeepSeek 的正式产品。不过方向已经清楚了：Agent 不再是一个等你敲指令的聊天窗口，而是一个持续在线、能同时推进多件事的协作者。至于它最终长什么样，可能还得看产品设计怎么把 Session 藏好。