刚刚，DeepSeek 重磅发布全新 Agent 架构：AI 开始指挥 AI 干活- 大数跨境

刚刚，DeepSeek 重磅发布全新 Agent 架构：AI 开始指挥 AI 干活

APPSO

2026-10-31

导读：AI Agent 的下一个瓶颈，可能是人类自己

当程序员还在群聊中讨论 Bug 修复方案时，AI 可能已经默默完成了问题复现，并将修复代码提交至 GitHub。

近日，DeepSeek Harness 团队发布技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，详细介绍了其正在探索的 Super-agent 架构。按照 DeepSeek 的设想，未来的 AI Agent 将突破单个聊天窗口的限制，实现持续在线、多任务并行处理，并能根据外部环境变化主动采取行动。

GitHub 项目地址（原型）

目前，DeepSeek 已基于 DeepSeek Harness 构建了一套内部 Super-agent 实例，并应用于日常研发协作。例如，当团队成员在群聊中反馈软件问题时，即使无人主动 @ AI，它也能识别潜在缺陷，在后台尝试复现问题、寻找修复方案，甚至直接提交 GitHub Pull Request 等待审查。

此外，同一项开发任务可在群聊和 GitHub 之间连续推进。开发者先在群聊确定方案，随后在 GitHub 评论中修改要求，Agent 能够理解上下文变化并调整执行方向。

需要明确的是，Super-agent 目前仍是一套面向工程实践的架构探索，部分设计已通过开源原型实现，尚非 DeepSeek 正式推出的独立产品。

AI Agent 的下一个瓶颈：人类注意力局限

过去一年，以 Coding Agent 为代表的 AI 工具已能独立阅读代码、定位 Bug、运行测试乃至完成复杂开发任务。然而，随着模型能力增强，人类管理任务的注意力并未同步增长，成为新的瓶颈。

目前，大多数 Agent 仍以 Session（会话）为基本工作单位。用户需在不同窗口间切换，记忆上下文并跟踪进度。DeepSeek 团队观察发现，一个人通常只能同时跟进 3 到 5 个活跃 Session。即便通过 CLI、MCP 等工具接入更多平台，单会话串行执行、多任务上下文混乱及设备离线导致任务中断等问题依然难以解决。

为此，DeepSeek 提出 Super-agent 概念，旨在让 Agent 从单次会话中解放出来，成为能够长期运行、跨平台保持上下文、并行推进任务的连续实体。Super-agent 需具备四项核心能力：跨会话连续交互、多任务高效并行、主动响应环境事件，以及长期在线和异常恢复。这意味着人类可更多专注于目标确定与结果验收，而将任务调度与执行交由 AI 管理。

双层架构：Router 统筹，Worker 执行

为实现上述目标，DeepSeek 设计了由 Router 和 Worker 组成的双层架构，宛如一个由 AI 组成的虚拟团队。

Router：全局协调节点

Router 是持续运行的全局协调节点，负责统一接收来自群聊、GitHub、邮件等多平台信息，判断任务分配策略，并维护跨任务上下文。由于主要负责信息理解和分派，相对轻量的模型即可胜任。

Worker：具体任务执行者

Worker 拥有独立上下文和工具能力，分别负责问题复现、代码审查、功能开发等具体任务，必要时可调用 Subagent。任务完成后，Worker 将关键结果汇报给 Router，由后者统一与用户沟通。对于用户而言，面对的始终是同一个 AI 助手；而对于系统，背后可能有多个独立 Agent 同时工作。

为减少协调开销，DeepSeek 引入订阅机制。当 Worker 接手如 GitHub Pull Request 等任务后，后续评论和状态变化可直接发送给它，无需每次经 Router 重新分配。

DeepSeek 认为，传统 Agent 让用户手动管理 Session 延续了底层大模型 API 的设计习惯。随着 Agent 能力提升，Session 应逐渐成为系统内部的技术细节，而非用户负担。

主动智能：没人 @ 它，AI 也能修 Bug

相比多任务并行，Super-agent 更具价值的能力在于主动性。传统 AI 助手通常需用户先提出问题再行动，而 DeepSeek 希望 Agent 能直接根据外部环境事件（Trigger）采取行动，如群聊消息、邮件、日程提醒、GitHub 评论及 CI 测试结果等。

考虑到多数群聊消息无需 AI 介入，DeepSeek 设计了两级过滤机制：先由程序规则快速排除无关消息，再交给大模型结合上下文判断是否行动。此外，还引入了计算机系统“投机执行”思想，即在未确定结果是否被采用前，提前利用后台算力尝试，有价值则提交，无价值则放弃。

例如，DeepSeek 内部配置了“静默复现并修复”策略。当有人反馈 Bug 时，Super-agent 提前在后台复现问题、分析原因并寻找方案。只有确认问题存在且找到简单修复方法后，AI 才会提交结果给开发人员，否则保持安静。案例显示，团队成员尚在讨论方案时，Super-agent 已提交修复 PR。

类似机制也可应用于个人助手，如收到会议邀请后，AI 提前核对日程、搜集资料并准备回复草稿，等待用户确认。

云端协同：电脑关机，AI 继续工作

为解决传统 Agent 的响应阻塞和设备依赖问题，DeepSeek 设计了异步 ReAct Loop。耗时任务转入后台执行，前台会话继续接收新指令，任务完成后再返回结果。用户可在执行过程中要求改变方向或终止任务。

该机制已在 DeepSeek Harness 中实现，但尚未默认开启。同时，借鉴存算分离思路，Agent 执行循环放在云端，会话状态存入数据库，而代码仓库、文件和工具链等工作环境保留在用户设备。本地仅需部署轻量级 daemon 接收云端命令并返回结果。即使电脑离线，任务也可在重新上线后继续执行。

此外，DeepSeek 引入独立的 Watchdog 机制，作为 AI 监督员检查任务进展，防止陷入无效循环，并在发现异常时尝试修复。

实测效果：效率提升与 Token 消耗平衡

DeepSeek 团队通过模拟群聊和 GitHub CI 消息流（单次约 300 条消息，含 20 条工作请求）进行了初步实验，对比 Super-agent 与传统单 Session 加 Subagent 方案。

结果显示，Super-agent 的任务完成时间 p50 为 12.4 分钟，p95 为 15.7 分钟；而采用中性提示词的传统单 Session 方案，p95 高达 29.5 分钟。差异主要源于任务调度：传统方案中，模型在中性提示下往往不调用 Subagent，导致所有任务在主会话串行执行并受新消息干扰；Super-agent 则通过双层架构明确分工，减少了不确定性。

然而，效率提升伴随成本增加。由于需维护多个独立会话，Super-agent 消耗的缓存读取 Token 高于单 Session。取消事件直通机制后，Router 决策量增加约 30%，总缓存读取量从 2323 万增至 3177 万 Token，增幅约 37%。但在高并发场景下（每分钟 40 条事件），Router 通过批量处理可将单次请求耗时控制在较低水平（从 2.5 秒增至 3.9 秒）。