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

- 作者：莫崇宇
- 发布时间：2026-10-31 21:59
- 分类：产品
- 原文：https://www.ifanr.com/1687026

![](https://s3.ifanr.com/wp-content/uploads/2026/10/7-1.jpg)

当程序员还在群聊里讨论 Bug 怎么修时，AI 可能已经默默完成了问题复现，甚至把修复代码提交到了 GitHub。

就在刚刚，DeepSeek Harness 团队发表技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，详细介绍了他们正在探索的 Super-agent 架构。

按照 DeepSeek 的设想，未来的 AI Agent 将不再局限于单个聊天窗口，而是能够持续在线、同时处理多项任务，并根据外部环境变化主动采取行动。

更值得关注的是，DeepSeek 已经基于 DeepSeek Harness 构建了一套内部 Super-agent 实例，并将其用于日常研发协作。

例如，当团队成员在群聊中反馈软件问题时，即使没有人主动 @ AI，它也能识别潜在缺陷，在后台尝试复现问题、寻找修复方案，甚至直接提交 GitHub Pull Request，等待开发人员审查。

![Image](https://s3.ifanr.com/wp-content/uploads/2026/10/lark2pad-1793455073241-1.jpg)

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

![Image](https://s3.ifanr.com/wp-content/uploads/2026/10/lark2pad-1793455074784-2.jpg)

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

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

过去一年，以 Coding Agent 为代表的 AI 工具已经能够独立阅读代码、定位 Bug、运行测试，甚至完成复杂的软件开发任务。

然而，随着模型能力越来越强，另一个问题也开始显现。

**AI 能够同时完成的任务越来越多，人类管理这些任务的注意力却没有同步增长。**

目前，大多数 Agent 仍以 Session，也就是会话为基本工作单位。用户需要在不同窗口之间反复切换，记住各个任务的上下文，并持续跟踪执行进度。

DeepSeek 团队提到，根据他们的观察，一个人通常只能同时跟进 3 到 5 个活跃 Session。

即使通过 CLI、MCP 等工具让 Agent 接入更多平台，仍然难以解决单会话串行执行、多任务上下文混乱，以及本地设备离线后任务中断等问题。

为此，DeepSeek 提出了 Super-agent，希望让 Agent 从单次会话中解放出来，成为一个能够长期运行、跨平台保持上下文、并行推进任务的连续实体。

按照文章中的定义，Super-agent 需要具备四项能力，包括跨会话的连续交互、多任务高效并行、主动响应环境事件，以及长期在线和异常恢复。

换句话说，人类可以更多地负责确定目标和验收结果，具体的任务调度与执行过程则交给 AI 管理。

![Image](https://s3.ifanr.com/wp-content/uploads/2026/10/lark2pad-1793455076342-3.jpg)

### 一个 AI 当主管，多个 AI 同时干活

为了实现这一目标，DeepSeek 设计了一套由 Router 和 Worker 组成的双层架构。

可以将其理解为一个由 AI 组成的虚拟团队，Router 负责统筹协调，Worker 负责具体执行。

Router 是持续运行的全局协调节点，统一接收来自群聊、GitHub、邮件等不同平台的信息，判断任务应该如何分配，并维护跨任务上下文。

真正执行任务的则是 Worker。每个 Worker 拥有独立的上下文和工具能力，可以分别负责问题复现、代码审查、功能开发等任务，必要时还能继续调用 Subagent。

任务完成后，Worker 将关键结果汇报给 Router，再由后者统一与用户沟通。

**对于用户而言，面对的始终是同一个 AI 助手；对于系统而言，背后可能已经有多个独立 Agent 同时工作。**

![Image](https://s3.ifanr.com/wp-content/uploads/2026/10/lark2pad-1793455078094-4.jpg)

为了减少协调开销，DeepSeek 还引入订阅机制。当某个 Worker 接手 GitHub Pull Request 后，后续评论和状态变化可以直接发送给它，无须每次经过 Router 重新分配。

![Image](https://s3.ifanr.com/wp-content/uploads/2026/10/lark2pad-1793455079411-5.jpg)

Router 主要负责信息理解和任务分派，因此相对轻量的模型也可能胜任，能力更强的模型则用于复杂任务执行。

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

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

相比多任务并行，Super-agent 更值得关注的能力，是主动寻找值得处理的事情。

传统 AI 助手通常需要用户先提出问题，再调用工具完成任务。DeepSeek 希望改变这种工作方式，让 Agent 直接根据外部环境中的事件采取行动。

群聊消息、邮件、日程提醒、GitHub 评论以及 CI 测试结果，都可以成为触发 Agent 行动的事件，技术上称为 Trigger。

![Image](https://s3.ifanr.com/wp-content/uploads/2026/10/lark2pad-1793455080154-6.jpg)

考虑到绝大多数群聊消息并不需要 AI 介入，DeepSeek 设计了两级过滤机制，由程序规则快速排除无关消息，再交给大模型结合上下文判断是否需要行动。

![Image](https://s3.ifanr.com/wp-content/uploads/2026/10/lark2pad-1793455081452-7.jpg)

更进一步，DeepSeek 还引入了计算机系统中的投机执行思想。

所谓投机执行，就是在尚未确定结果是否会被采用时，提前利用后台算力进行尝试，有价值的结果再提交给用户，没有价值则直接放弃。

例如，DeepSeek 在内部用户群中配置了一项「静默复现并修复」策略。

当有人反馈 Bug 或讨论修改方案时，Super-agent 可以提前在后台复现问题、分析原因，并寻找修复方案。

只有确认问题存在，并找到相对简单的修复方法后，AI 才会把结果提交给开发人员，否则全程保持安静。

DeepSeek 展示的案例中，团队成员还在群聊里讨论解决方案，Super-agent 就已经在后台提交了修复 Pull Request。

![Image](https://s3.ifanr.com/wp-content/uploads/2026/10/lark2pad-1793455083162-8.jpg)

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

### 电脑关机，AI 也能继续工作

除了主动性，DeepSeek 还尝试解决传统 Agent 的响应阻塞和设备依赖问题。

在常见的 ReAct Loop 中，模型发起耗时工具调用后，需要等待结果返回，期间可能无法及时响应新的指令。

DeepSeek 因此设计了异步 ReAct Loop，让耗时任务转入后台执行，前台会话继续接收用户消息，任务完成后再将结果发送回来。

**AI 可以一边执行复杂任务，一边接受新指令，用户还能在执行过程中要求它改变方向或终止任务。**

![Image](https://s3.ifanr.com/wp-content/uploads/2026/10/lark2pad-1793455084900-9.jpg)

该机制已经在 DeepSeek Harness 中实现，但尚未默认开启。

与此同时，DeepSeek 借鉴存算分离的思路，将 Agent 的执行循环放在云端，将会话状态保存到数据库，而代码仓库、文件和工具链等工作环境仍然可以留在用户设备上。

本地只需部署一个轻量级 daemon，负责接收云端命令并返回结果。即使电脑暂时离线，相关任务也可以在设备重新上线后继续执行。

![Image](https://s3.ifanr.com/wp-content/uploads/2026/10/lark2pad-1793455086686-10.jpg)

此外，DeepSeek 还引入独立的 Watchdog 机制，相当于给 Agent 安排了一个 AI 监督员，负责检查任务是否取得进展、是否陷入无效循环，并在发现异常时尝试修复。

### 实测效率提升，但也更费 Token

为了验证新架构，DeepSeek 团队进行了一组初步实验。

实验模拟群聊和 GitHub CI 消息流，单次包含约 300 条消息，其中约 20 条是真正的工作请求。研究人员将 Super-agent 与传统单 Session 加 Subagent 的方案进行对比，每种方案重复运行五次。

![Image](https://s3.ifanr.com/wp-content/uploads/2026/10/lark2pad-1793455087738-11.jpg)

结果显示，**Super-agent 的任务完成时间 p50 为 12.4 分钟，p95 为 15.7 分钟；采用中性提示词的传统单 Session 方案，p95 则达到 29.5 分钟。**

![Image](https://s3.ifanr.com/wp-content/uploads/2026/10/lark2pad-1793455088721-12.jpg)

差异主要来自任务调度。传统方案虽然支持 Subagent，但模型是否真正分派任务，仍取决于提示词和临场判断。

在中性提示配置下，五次实验中模型一次都没有调用 Subagent，所有任务都在主会话中执行，不断受到新消息干扰。

Super-agent 则通过双层架构，让 Router 专注任务分派，Worker 独立执行，减少了这种不确定性。

不过，效率提升也有代价。由于需要维护多个独立会话，Super-agent 消耗的缓存读取 Token 高于单 Session。

取消事件直通机制后，Router 需要做出的决定增加约 30%，总缓存读取量从 2323 万增加至 3177 万 Token，增幅约 37%。

另外，当事件到达速率从每分钟约 1 条升至 40 条时，Router 可以通过批量处理提高吞吐量，单次请求耗时仅从 2.5 秒增加至 3.9 秒。

![Image](https://s3.ifanr.com/wp-content/uploads/2026/10/lark2pad-1793455091676-13.jpg)

需要注意的是，实验使用合成消息和模拟耗时工具，主要验证任务调度与协作能力，并未直接评估真实编码质量。

### DeepSeek 想让 AI 成为真正的数字同事

尽管 DeepSeek 已经在内部运行 Super-agent，但距离大规模应用仍有不少挑战。

首先是长期记忆。当任务积累到数周甚至数月后，如何准确恢复历史上下文，仍然是一个难题。

其次是安全与隐私。由于 Super-agent 会持续接收外部消息，并通过云端访问本地设备，一旦遭遇提示词注入或服务端入侵，就可能威胁代码仓库、敏感数据和本地凭据。

此外，当 Agent 能够同时推进大量任务时，用户应该如何查看进度、介入执行，以及决定哪些操作必须人工批准，也需要重新设计。

目前，DeepSeek 已将部分设计实现为 dsh-superagent-prototype 原型插件，相关架构仍在持续探索。

值得注意的是，DeepSeek 团队在文章结尾坦言，他们并没有提出全新的理论，而是将任务调度、缓存管理、事件驱动、存算分离等经典计算机系统思想应用到了 Agent 架构中。

但随着模型完成单个任务越来越少需要人工干预，人类能够同时管理多少个 AI，正在成为新的问题。

过去，我们需要不断向 AI 发送指令，告诉它下一步做什么。按照 Super-agent 的设想，未来人类可以更多地负责确定目标、做出决策和验收成果，让 AI 自己发现问题、协调任务并完成执行。

**或许未来真正成熟的 AI 助手，不会一直待在聊天窗口里等待提问，而是像一位能够长期参与工作的数字同事，在你没有主动找它的时候，也知道自己应该做些什么。**