deepseek-super-agent深度解析与思考

10 月 31 日晚上，deepseek 发布技术性文章《Super-agent 设计探索：迈向更自主的 Agent 系统》。

熬夜看了一下，为大家解析一下主要内容和我自己的思考。

总的来说呢，感觉很适合改进dots、grokbot这类个人助手，文中的很多思想和架构都很适合直接拿来给个人助手用。

主要解决了任务局限与单个session的问题，同时提高任务处理速度、提高agent效率，感觉这是后面agent发展的方向。

发现和解决的问题

在主流agent中，工作模式仍然是以sessions为单位，需要人工手动创建许多session与工作区的隔离，彼此相互独立，协调各个session主要还是靠人手动维护。一个人大概只能同时维护3-5个sessions，也就是说，多任务的瓶颈取决于人的注意力，需要人工频繁维护sessions。

设计理念

因此，根据问题，super-agent主要的设计理念是打破 Agent 与单次手动会话的绑定，使其成为一个能跨会话保持上下文、同时推进多项复杂任务且互不干扰的连续实体。

具体来说，super-agent需要有以下几个特征：

• 连续：用户可以直接在 IM 聊天、GitHub 评论等熟悉的工作界面与它交互，感觉始终只存在一个 Agent，不需要去想“Session X 的上下文中是否有 Y 信息”。例如，用户先在 IM 上提出采用方案 A，随后在 GitHub Pull Request 评论里改为方案 B，它能理解并调整执行方向。
• **高效：**交互响应迅速，同时能并行、高质量地完成多个复杂任务。无需等上一个命令或任务完成，就能接受下一条指令。
• **主动：**无需等待用户逐条下达指令，能持续观察环境事件并主动推进值得处理的事项，不需要介入时则保持安静。
• **持久：**始终在线、直接接入用户真实的工作环境，并在长期运行中遇到异常时自动恢复。

架构

双层架构

根据以上理念，deepseek设计了一套双层架构，分为Router层和Worker层。

可以看出来，核心是router层。所有会调用agent的任务都称之为trigger，trigger触发之后，分为fast path和slow path。slow交给router进行全局调度，fast path直接交给worker sessions。所以，用户面对的永远是一个入口，而不是复杂的session，所有的内容都会给内部调用不同的session，因此在用户层面淡化了session的概念。

router层

router层可以不具有任何的工具，保持轻量，大部分信息在此汇总，主要承担任务分发和信息调度，看上去有点像子代理。

router可以不局限于单个session，但是原文采用了最直接的单个session的方式。

router是整个架构的核心。遇到吞吐瓶颈时，会将阻塞的trigger在下一轮一起执行，形成一个batch。

worker

worker是负责具体执行的地方，由多个sessions组成，彼此隔离，它直接决定了任务质量。

worker的所有结果都不会交给用户，而是返回router层，由router层统一汇总后汇报给用户。

同时与router一样，不局限于单个session，worker内部可以再创建subagent，本质上，这里就是一个可以独立运行的agent应用。

不同的worker可以对应不同的功能、不同的工具和不同的环境，由router进行任务分配。

事件处理

在这里，官方的思想是：主要输入不再是人类在 Session 中逐条键入的提示词，而是环境中的半结构化事件。

是什么意思呢？就是将群聊消息、定时任务、邮件等行为定义为trigger，也就是一个触发器，实现自动触发，而不是每次人类明确下达指令。

其实这里就是类似dots、grokbot等个人助手产品。

大家还记得前面的fast path和slow path吧，在trigger触发后，首先由程序，也就是固定的代码，进行fast path过滤，设置不同的过滤规则，配置直通（将fast path直接交给worker），slow则交给router进行调度。

上下文处理

将上下文窗口当作 Cache 管理，将上下文分为Inline、Spill。

• Inline（内联）：将重要、近期可能使用的信息直接写入 Prompt（上下文），模型可以立即读取，无需调用工具。
• Spill（溢出）：将不重要或过长的信息保存在外部存储中，只在上下文中保留摘要、ID 或引用，需要时通过工具调用获取，按需调用。

那么我想的就是：在每个种类的任务中分配一个类似上下文数据库，这里交给router进行调用，在分配worker的时候，指定对应的上下文数据库供worker进行使用，同时在router的上下文数据库中增加相应的信息，实现Thread的复用。

在这里引入一个新概念，thread，就是同一个事件所产生的所有相关事件。

主要有三个作用：

1. 关联事件：把同一个 GitHub PR、IM 话题或邮件串中的多个 Trigger 组织起来。
2. 自动路由：Worker 订阅 Thread 后，后续事件直接发送给 Worker，不需要 Router 重新分配。
3. 上下文追踪：通过 Thread ID 关联历史消息、Trigger 和 Worker Session，方便按需召回上下文。

回复

提前行动

模型可能会在不确定的时候在后台进行尝试，例如：收到一封会议邀约邮件或待办消息时，Agent 可以先在后台核对日程冲突、搜集相关背景资料并备好回复草稿，当用户确认以后直接发送，也就是结合信息，推测用户的任务请求。

异步执行

在传统ReAct的时候，有大量的时间在等待工具结果，因此采用了异步ReAct Loop，架构如下：

也就是启动工具后立刻返回Started，在后台完成后注入到会话中，模型中间不停止。

环境处理

现有的agent模型大部分都是本地进行，依赖本机环境等。

根据这个特点，superagent借助存算分离的思想，在云端存储session状态、任务记录、数据库等。

同时在云端保留worker，同时在本地运行daemon，当本地daemon在线的时候，可以通过对应的工具调用本地环境、读取文件等，相当于只执行代码。本地掉线时云端继续运行，本地上线后可以使用本地环境。

也就是说本机只相当于执行代码的边缘执行节点。

这样可以实现以下好处：

• 持久运行：本地电脑关闭，云端 Agent 仍然可以运行；依赖该电脑的任务则需要等设备重新上线。
• 故障恢复：计算容器异常重启，可以恢复已保存的 Session 状态。
• 弹性扩展：计算容器可以按需增加或减少。
• 跨设备执行：同一个 Agent 可以调用不同机器上的工具和环境。

感觉这里非常适合个人助手啊，dots之类，openai快点实现，哈哈哈。

最终效果

这里引用原文了。

可以看到，速度显著优于带 Subagent 工具的单 Session。

从系统开销看，由于维护了多个独立会话，Super-agent 单次实验的读缓存 token 高于单 Session，是以更多的 token 消耗换取更短且更稳定的完成时间。

开放问题

在这里，官方留下了几个问题。

引用原文了：

8.1 如何扩展双层架构 前文通过“单常驻 Router Session + 订阅直通 + Worker 间不直接通信”的简化组合，以较小的工程代价覆盖了我们目前的大多数日常任务。但当任务规模扩大、耦合度提高，超出单个 Router Session 的承载范围时，具体的层内结构并无定论，Router 层何时需要水平切分、粒度如何划分，以及同层 Worker 之间何时需要引入直接通信、采用何种协作拓扑，仍有待在更多场景中检验。同时，系统与模型的协同设计（Co-design）也是一个值得探索的方向，针对 Router 层的事件判别、批量分派与上下文召回等任务进行专项训练，有可能进一步提升 Router 层的吞吐与决策性能。 与此同时，前文中常驻的 Router 层配合基于引用图的链式召回，主要解决的是近期任务与会话历史的按需检索。当运行周期拉长到跨月甚至更长的时间跨度时，长程记忆便成为制约可扩展性的主要瓶颈。 8.2 脱离Session之后如何与Agent协作 前文通过双层架构将底层的多会话管理对用户隐藏，使 Session 不再是产品设计的首要问题；但当底层的执行会话不再直接对应用户界面上的会话后，如何向用户呈现任务并提供自然的交互与项目管理形式，便成为了新的问题。我们认为，以聊天窗口为中心的交互在一定程度上是路径依赖的结果。交互可能可以更多地发生在领域特化的交互界面中，例如像本文的实例那样，让 Super-agent 直接在 GitHub 的 Issue 和 Pull Request 中工作；Session 也可以出于用户的使用习惯而在界面上保留，但用户看到的一个会话在底层未必只对应一个 Session。 同时，前文主要讨论了人类在任务发起与结果验收阶段的交互；但在模型能力快速演进的过渡期内，许多任务仍需要人类在中途参与，如何在产品设计中兼顾用户对关键细节的逐步干预与后台自主推进的效率，例如让用户在后台执行过程中随时介入、接管或与 Agent 实时协同工作，同样值得探索。 总的来看，用户所需的项目管理与交互形式与具体的工作领域和个人风格密切相关，最终形态很可能是高度定制化的；而 DeepSeek Harness 由于采用开放的架构设计，也更容易支持这种定制化。 8.3 如何划分上下文边界并进行A2A协作 前文讨论的始终是单个 Super-agent 实例内部的设计，默认其服务范围内的信息都汇总在同一个全局上下文中。但当使用范围从个人或小团队扩展到更大的组织时，组织在决定如何配备 Super-agent 时实际上是在划分上下文共享与隔离的边界。需要共享上下文的范围共用同一个实例，需要隔离的范围则各自独立配备。 进一步看，一旦组织内或组织间存在多个彼此隔离的实例，例如每个成员各自的个人助手与团队共用的 Super-agent 之间，此时跨边界的协同就是 Agent 间通信（A2A，不特指某个协议）。在互不共享底层上下文、各自代表不同权限边界的前提下，如何实现安全、可靠的 A2A 通信与协作，仍需进一步探索。 8.4 如何保障安全与隐私 第 3 节的事件驱动设计让 Agent 能够被更广泛的环境驱动，但也增加了接触不可信输入的风险。如果没有办法很好的解决安全与隐私问题，那么 Super-agent 只有在一个很小且可信的范围才能工作。 例如，第 5 节将 Agent Loop 部署在云端、并在各类执行设备上安装轻量 daemon，这一设计默认建立在云端与端侧环境彼此受信任的前提之上。但当云端的 Agent Loop 持续接入外部环境事件、而端侧设备上又存有私有代码、敏感数据与本地凭据时，这种跨设备连接便引入了显著的安全与隐私隐患。一旦云端的 Agent Loop 遭遇服务端入侵或提示词注入而被攻破，其连接的全部端侧设备都面临被控制的潜在风险。 此外，即使云端未被攻破，只要端侧环境中的凭据能够进入模型的上下文，正常执行过程中同样存在凭据泄露的风险；因此还需要设计相应的机制，让 Agent 能够在完全不接触凭据本身的情况下使用凭据。如果这一架构要走向更广泛的应用，就需要在能够从多样化的环境中召回上下文的同时，解决上述安全与隐私问题。

原文:

https://zhuanlan.zhihu.com/p/2099987320443237060