DeepSeek Super-agent 设计解析：Router-Worker 架构与本地连接挑战

DeepSeek 公开了名为 Super-agent 的 AI 代理构想。它能在与用户持续对话的同时推进多项任务，并响应 GitHub 或聊天中的变化。本文总结了它如何减轻人类管理工作或会话的负担，以及它与现有代理的区别。

TL;DR

• Super-agent 将工作进度和会话管理交由系统处理，旨在减少人类进行细致指示和确认的负担。
• Router 负责与用户的对话及任务分发，Worker 则负责具体的作业。它还能接收 GitHub 和聊天的通知，并将需要应对的事项分派给相应的负责人。
• 该构想还设想了一种架构：在云端运行 Router 和 Worker，同时利用本地 PC 上的代码和开发工具来执行作业。
• 人们期待 AI 供应商能够将用户在多个服务中构建的机制系统化并提供出来。
• 由于 Worker 也位于云端，因此令人担忧的是，它与家用 PC 的连接以及 GUI/浏览器操作的稳定性如何。

前言

DeepSeek Harness 团队发布了一篇题为Exploring Super-agent Design: Towards a More Autonomous Agent System的设计文章。

原文建议将任务分配和会话间的信息传递交给系统处理，从而减少人工进行详细指示和确认的负担。其目的是让人能够专注于确定工作目标、设定优先级，以及确认和批准成果。

此前，我曾撰写过一篇关于从 Work 或 dot 向家用 PC 上的 Codex 请求工作的文章。在本构想中，将用户对话与实际执行相分离的机制被作为代理的执行平台来处理。

为了自己也能理解这套机制，我结合现有的代理对原文的设计进行了整理和总结。

DeepSeek 的超级代理构想

超级代理旨在减少人们通过逐个操作会话来推进工作的负担，使多个任务能够持续交由代理处理。人们只需传达目标和优先级，并在需要时进行判断和批准。在此过程中，系统负责工作分配和信息交接的设计。

原文指出，随着模型能力的提升，对单个任务的监控和细致指令逐渐减少。同时，协调多个代理的能力也在增强，使得将任务分配到不同会话中成为可能。

在使用 Claude Code 或 Codex 推进多项工作时，有时会为实施和调查分别开设会话。虽然这避免了上下文混淆，但用户仍需自行确认进度并向相应会话添加额外指示。

即使能够将单个任务委托出去，如果人类仍需记住每个会话掌握了哪些信息，那么同时委托的任务数量就会受到人类注意力的限制。原文说明，随着模型能力的提高，这种人为负担将成为生产力的瓶颈。

因此，我们将确定职责并传递必要信息的功能纳入代理机制。除了接收来自人类的指示外，代理还会监听 GitHub 和聊天中的变化，并推进需要处理的任务。当途中需要判断或要求确认成果时，任务会返回给人工处理。

即使用户改变对话对象或场所，系统也会基于之前的请求进行应对。工作中也能承接其他任务，若出现异常则进行恢复。Super-agent 的构想正是重新设计代理的执行基础架构，以持续实现这些操作。

作为比较的起点，如果描绘为按工作启动本地代理的配置，如下所示。

用户管理每个工作会话的配置

在 Super-agent 中，将负责与用户交互的 Router（路由器）和负责执行工作的 Worker（工作者）分开。对话和工作记录保存到执行流程之外，并连接到拥有代码和开发工具的环境。

DeepSeek 的 Super-agent 构想

即使用户在委托实现后要求另一项调查，也可以继续与同一个 Router 对话。后台各自推进相应的工作，并将结果和需要咨询的问题返回给 Router。还设想从聊天开始的工作，后续通过 GitHub PR 接收追加指示并继续推进。

元記事が挙げる性質は次のとおりです。

我们通过路由器与工作者的分工、事件处理以及异步交互来实现这一点。其中包括将执行处理与状态/环境分离，以及从外部进行监控的机制。整个以Harness为核心的执行平台的设计是讨论的重点。

每个工作的会话将保留在内部。我理解这是指将管理交由系统负责，从而无需用户每次考虑打开哪个会话的方案。

与用户的对话和工作任务的分工

Router 在持续与用户进行对话的同时，将新任务分派给 Worker。它还处理正在进行中的任务之间的关系，以及涉及多个任务的判断。

例如，在请求修复某个 bug 之后，又要求调查另一个库。此时，修复工作由 Worker A 负责，调查工作由 Worker B 负责，而 Router 则掌握两者的状况并继续与用户交谈。

Router 本身并不执行实际作业。原文指出，即使没有 Bash 工具，使用轻量级模型也往往能兼顾速度与质量。这是因为如果负责对话的模型开始进行编码或长时间调查，那么期间的对话或对其他请求的响应也会变慢。

Worker 拥有各自独立的任务上下文以及执行作业所需的工具。负责排查 bug 原因并修改代码的任务，与负责调查库规范的任务，无需持续共享中间日志或推理过程。各 Worker 推进作业，并将重要结果报告给 Router。对用户的回复由 Router 统一汇总完成。

将工作交由其他角色承担的做法，与一般的 orchestrator/worker 架构及子代理（sub-agent）是共通的。不过，orchestrator 将复杂工作细分为具体任务，而此处的 Router 在职责范围上有所不同。Router 负责独立任务的分配与整体协调，而单个任务的详细计划与拆分则由 Worker 侧负责。

Worker 可以根据工作需要使用额外的子代理。例如，负责功能增强的 Worker 可以运行一个由 Agent Team 组成的团队，该团队分担设计、实现和测试工作。Router 和 Worker 是角色划分，因此并不意味着它们各自必须对应一个会话。

外部事件与作业中的附加指示

为了持续推进工作，除了最初的请求外，还需要接收随后发生的事件。

对已修改的 PR 进行审查。CI 失败。在聊天中讨论变更。原文将这些外部事件作为 Trigger（触发器）处理。

如果将所有判断都交给模型，那么即使是无关的消息也需要进行推理。因此，对于可以通过固定条件（如发送者或目标群组等）判定的情况，先通过程序进行筛选。然后，将那些必须阅读内容才能判断是否需要应对的情况交给模型处理。原文中的 Fast Path / Slow Path 正是这种分工。

在确定负责人后，后续的汇报并不需要每次都经过 Router 的判断。

例如，如果 Worker A 负责 PR 的修改，则将其会话注册为该 PR 相关通知的接收方。当评论或 CI 结果的通知到达时，程序会按照此注册直接将通知发送给 Worker A。无需在每次通知时由 Router 模型重新选择负责人。

原文中的 subscription（订阅）指的是这种接收方的注册。为每个 PR 或聊天线程注册接收方，并通过程序分发后续通知。阅读收到的内容并考虑应对措施的是 Worker。

尚未分配负责人的新工作或跨负责人的协调工作由 Router 处理。Worker 也会将重要结果报告给 Router，因此 Router 可以在掌握整体情况的同时与用户进行交互。

为了接收作业过程中的附加指令，工具的执行也采用异步方式。启动长时间构建后，不必在该调用中一直等待直到完成，而是让结果作为事件稍后到达。在此期间到达的附加指令也可以在当前模型的推理步骤结束时进行处理。

这样即使构建过程中方针发生变化，也不必中断对话直到构建结束。这不仅是后台执行命令的设计，还允许在作业过程中接收输入。

对于随着运行时间延长而增加的历史记录也有相应的策略。将最近需要的信息放入上下文，将长内容和旧记录移出但保留引用。如果过去的工作再次成为话题，则通过追踪这些引用来重新读取所需的记录。原文中称之为 Inline & Spill、Chain of Recall 机制。

执行处理、历史记录与工作环境的分离

在该构想中，将代理的执行处理与历史记录置于云端，并根据需要连接实际的工作环境。

Agent Loop 是向模型发起查询、将返回的工具调用连接到执行环节、并将结果反馈给模型的处理流程。我们将负责执行此流程的程序与希望保留的对话及工作记录区分开来。

即使Agent Loop进程崩溃，记录也会保留在外部。如果其他进程能够重新读取这些记录，就可以继续处理相同的工作。我们将保持正在运行的单个进程与工作的连续性分开考虑。

原文也引用了Anthropic的Managed Agents设计文章。同样采用将Harness与会话记录、工作环境分离并允许交换它们的设计。

DeepSeek 特别提到的连接对象是用户日常使用的个人电脑。家庭电脑上存有未提交更改以及在该电脑上使用的开发工具。与其将所有内容复制到云端，不如直接使用现有的工作环境。

在 PC 端放置一个轻量级守护进程（daemon），用于执行命令并返回结果。对话和工作状态由云端管理，Agent Loop 将需要处理的任务委托给 PC 端。原文称之为 BYOM（Bring Your Own Machine）。云环境以及按需创建的环境也包含在连接对象中。

采用这种配置，即使关闭家庭电脑，也能在云端维持对话和记录。该电脑所需的工作会处于等待连接的状态，待再次上线时继续推进。

为了持续运行，还设置了从外部监控状态的 Watchdog。它不仅检查进程停止或 API 错误，还会确认是否因重复相同操作而停滞不前，以及是否偏离目标。Watchdog 本身也是拥有工具的智能体会话，在主要执行处理之外进行监控和恢复。

在我之前的配置中，是由云端的 dot 向本地运行的 Codex 等工作代理发出请求。在 Super-agent 构想中，Worker 的 Agent Loop 也放置在云端，而在本地 PC 上仅放置执行命令并返回结果的守护进程。

以前工作代理在 PC 上运行，因此可以直接使用该 PC 的 GUI 或浏览器操作工具。当 Worker 位于云端时，为了查看和操作本地屏幕，需要在云端与 PC 之间建立交互机制。在云端提供的浏览器中进行调查的任务，与使用家庭电脑应用程序或现有浏览器的任务相比，其连接对象也会不同。

可以考虑由云端侧进行判断，然后让 PC 端的程序执行屏幕获取或点击操作。即使对话或工作记录得以保留，通信中断前打开的屏幕也不一定仍然处于打开状态。连接恢复后，需要确认操作对象的状态，并根据该状态继续推进后续步骤。

由于操作指令和结果在云端与 PC 之间来回传输，因此令人担心的是过程中是否会停滞，或者结果能否顺利返回。我们期待基础平台能够稳定地处理从屏幕获取、操作结果确认到通信中断后恢复的全过程。

dsh-superagent-prototype 也已公开，它是部分构想的实现版本。README 中明确指出，其内部版本与设计文章并不完全相同，文章中提到的未来构想也有尚未实现的部分。看来此处阐述的整体愿景尚不能直接作为完成的产品使用。

与现有代理的比较

Claude Code 和 Codex 也支持将任务分配给子代理、在云端进行作业以及从远程终端发出额外指令。Cowork 具备将多阶段工作委托给它并在云端并行推进或定期执行的功能。

Super-agent 的构想旨在整理如何将上述功能组合成持续的工作流程。它不仅设计了负责与用户交谈的角色和接收后续报告的渠道，还涵盖了记录保存和工作环境的连接。

作为使用体验，它与 Grok Bot、ChatGPT dots 和 Claude Duet 也有相似之处。

Claude Duet 目前处于研究预览阶段，会定期检查已连接的应用程序。

观察 Grok Bot、dots 和 Duet，可以很容易想象出在保持日常对话的同时后台推进工作的使用方式。DeepSeek 的文章有趣之处在于具体说明了实现这种使用方式的执行基础架构。

\n结语

追溯其机制，感觉它接近于近期常见的从 Grok Bot 向其他代理委派工作的结构。我之前搭建的 dots 基础架构，在将负责对话的代理与负责实际工作的代理连接起来这一点上，也是相同的思路。

如果 AI 厂商能够将用户通过组合多个服务所构建的这些机制进行体系化并提供，那就很有趣了。如果无需自行配置服务之间的连接方式和任务交接，我认为会有更多人愿意将工作委托给代理。

由于我之前曾遇到 dot 连接不畅的问题，最终放弃了使用。基于这一经验，我关心 Worker 迁移至云端后，如何处理与本地 PC 的交互。如果能稳定支持包括日常开发环境以及 GUI/浏览器操作在内的各种场景，那将非常接近我理想中的使用形态。