DeepSeek 公开 Super-agent 架构探索：让 AI 指挥 AI 干活
“ DeepSeek 公开 Super-agent 架构探索：让 AI 指挥 AI 干活 DeepSeek 公开了一篇关于 Super-agent 的技术文章，描述了一套 Router + Worker 的双层 Agent 架构：一个协调节点统 ”
DeepSeek 公开 Super-agent 架构探索：让 AI 指挥 AI 干活
DeepSeek 公开了一篇关于 Super-agent 的技术文章，描述了一套 Router + Worker 的双层 Agent 架构：一个协调节点统筹全局，多个执行单元并行干活。需要先说明的是，这属于架构层面的探索，尚不是产品发布——但它抛出的问题很实在：当 AI 能同时接的活越来越多，人类有限的注意力该怎么分配。
一、真正的瓶颈，可能不是模型，而是人的注意力
过去一年，以 Coding Agent 为代表的 AI 工具已经能独立阅读代码、定位 Bug、运行测试，甚至完成相当复杂的开发任务。但能力越强，另一组矛盾就越明显：AI 能同时推进的任务在变多，人类管理这些任务的注意力却没有同步增长。
目前绝大多数 Agent 仍以 Session（会话）为基本工作单位。用户需要在不同窗口之间反复切换，自己记住每个任务的上下文，还要持续跟踪执行进度。人对并行任务的管理能力存在明显上限，一旦超过这个量级，“多任务并行”就会退化成“多任务互相打断”。
即使通过 CLI、MCP 等工具让 Agent 接入更多平台，仍然绕不开三个结构性问题：
- 单会话串行执行：一个窗口一次只能推进一条线；
- 多任务上下文割裂：跨任务的记忆无法打通，用户成了人肉上下文搬运工；
- 本地设备离线即中断：任务挂在个人电脑上，人一走，活就停。
DeepSeek 的判断是，这种设计很大程度上延续了底层大模型 API 的习惯——Session 本应是系统内部的技术细节，而不是需要用户手动管理的对象。为此，Super-agent 被定义为具备四项能力的连续实体：跨会话的连续交互、多任务高效并行、主动响应环境事件、长期在线与异常恢复。换句话说，人负责确定目标和验收结果，任务怎么调度、怎么执行，交给系统自己管。
需要强调的是，这四项是设计目标，不是已交付的能力清单。
二、Router + Worker：一个 AI 当主管，一群 AI 同时干活
为了实现上述目标，DeepSeek 设计了一套由 Router + Worker 组成的双层架构，可以理解为一个由 AI 组成的虚拟团队：Router 统筹协调，Worker 具体执行。
Router 是持续运行的全局协调节点。 它统一接收来自群聊、GitHub、邮件等不同平台的信息，判断一个任务该不该接、该分给谁，并维护跨任务的全局上下文。
Worker 才是真正干活的角色。 每个 Worker 拥有独立的上下文和工具能力，可以分别负责问题复现、代码审查、功能开发等不同任务，必要时还能继续向下调用 Subagent，形成更细的分工层级。任务完成后，Worker 把关键结果汇报给 Router，再由 Router 统一与用户沟通。
由此带来一个对用户体验很关键的变化：你面对的始终是同一个 AI 助手，但系统背后可能已经有多个独立 Agent 同时在跑。
架构里还有两个值得注意的设计。其一是订阅机制：当某个 Worker 接手一个 GitHub Pull Request 后，后续的评论和状态变化可以直接推送给它，不必每次都经过 Router 重新分配，从而压低协调开销。其二是模型分工：Router 主要负责信息理解和任务分派，相对轻量的模型就能胜任；能力更强的模型则留给复杂任务的执行环节。这是一种典型的“贵模型干难活、便宜模型管调度”的成本思路。
三、没人 @ 它，AI 也会主动来判断
相比多任务并行，Super-agent 更值得关注的能力是主动寻找值得处理的事情。
传统 AI 助手的工作方式是“你问—它做”，必须由用户先提出问题，才会调用工具。DeepSeek 想改变这一点：让 Agent 直接根据外部环境中的事件采取行动。群聊消息、邮件、日程提醒、GitHub 评论、CI 测试结果，都可以成为触发 Agent 的 Trigger。
难点在于噪声。绝大多数群聊消息并不需要 AI 介入，如果每条都唤醒一次大模型，成本高且容易帮倒忙。因此设计中引入了两级过滤机制：先由程序规则快速排除明显无关的消息，再交给大模型结合上下文判断是否真的需要行动。
这里体现的是一种克制的产品思路——主动性并不等于话多。一个真正有用的 Agent，应当在该沉默的时候保持沉默。这也正是下一层“投机执行”策略的前提。
四、把体系结构里的“投机执行”搬进 Agent
DeepSeek 在这套架构里引入了一个来自计算机体系结构的概念：投机执行（Speculative Execution）。它的核心是：在结果是否会被采用尚不确定时，先利用后台闲置算力去尝试，有价值的结果提交给用户，没价值的直接丢弃。
落到具体做法上，技术文章描述过这样一类设想：当有人在群里反馈 Bug 或讨论修改方案时，Agent 可以在后台提前复现问题、分析原因、寻找修复方案，只有在确认问题真实存在、并且找到了相对简单的修复方法时，才把结果推给开发人员；否则全程保持安静。
需要注意，这套做法把成本结构也改变了：算力从“按需调用”变成“提前下注”。好处是用户感知到的响应速度大幅提升，代价是可能有一部分后台计算最终被浪费。以“相对简单、可靠”作为提交门槛，本质上是在用保守策略对冲误报风险。
也要说明，这类后台静默修复的具体触发条件、启用范围与落地程度，无法从公开渠道独立核实，宜视为设计意图而非既成事实。
五、从群聊到 GitHub，一条任务线不断
多任务并行的真正价值，不在于同时开几个窗口，而在于同一件事能在不同平台之间接续推进而不丢失上下文。
技术文章举的例子是：开发者先在群聊中确定方案，随后又在 GitHub 评论里修改了要求，Agent 能够理解前后变化，并相应调整执行方向。在传统 Session 模型下，这往往意味着跨平台复制粘贴、重新解释背景，甚至要重新开一个会话从头讲一遍需求。
把这条线拉通后，人与 AI 的协作边界也随之后移：
- 人负责的部分：定义目标、判断优先级、验收结果、对最终代码负责；
- AI 负责的部分：任务拆分、上下文维护、执行调度、异常恢复。
这种分工听起来理想，但也意味着开发者需要信任一个“看不见的进程”在后台持续动作。因此审查环节变得比以往更关键——Agent 提交的 Pull Request 是等待开发人员审查的，而不是直接合并。
六、需要先澄清的事，和几个开放问题
在讨论细节之前，有一个事实必须摆在前面：Super-agent 目前仍是一套面向工程实践的架构探索，而非 DeepSeek 正式发布的独立产品。 团队公开的是技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，不是产品发布公告。把“技术构想”读成“已上线功能”，是这类内容传播中最常见的误读。
即便只作为架构探索看，它也留下了几个开放问题：
一是权限边界。 一个能主动读群聊、读邮件、读 CI 结果并提交代码的 Agent，实际上拿到了相当宽的访问面。哪些数据可读、哪些动作可执行、出错后由谁回滚，都需要工程上的硬性限制。
二是不同的过滤方式各有代价。 两级过滤加投机执行，本质上都是在用工程手段压低误报率和算力浪费，但无法归零。一个“自信地修错了地方”的 PR，比不提 PR 更消耗团队时间。
三是可观测性。 当 Session 从用户界面退化为系统内部细节，任务到底跑到哪一步、卡在哪个 Worker 上，就需要新的观测手段来补位。
这些问题不是否定，而是任何“AI 管理 AI”的系统走向生产环境都必须回答的题。
七、结语：Agent 的竞争，正在从模型转向系统
从单会话到持续在线，从被动应答到主动触发，从一个人盯几个窗口到一群 Agent 并行推进——Super-agent 指向的方向是清晰的：Agent 的下一阶段竞争，重点可能不再是模型能力本身，而是围绕模型搭建的调度、上下文与协作系统。 Router/Worker 的分层、订阅机制压低协调开销、两级过滤控制噪声、投机执行换取响应速度，这些设计单看都不惊艳，组合起来却构成了一个“AI 组织”的雏形。
当然，从一篇架构文章到日常可用的基础设施，中间还隔着权限、可靠性、成本与信任四道关。Super-agent 能否真正落地，取决于它能否让开发者放心地把后台交给它——而这份放心，只能靠一次次不出错的判断慢慢积累。
📚 参考来源
