2026 年 10 月 31 日，DeepSeek Harness 团队发布了《Exploring Super-agent Design: Towards a More Autonomous Agent System》，介绍了一套面向长期运行、多任务并发和主动协作的 Super-agent 架构，并公开了 dsh-superagent-prototype 研究原型。这次发布的并不是新的大模型，也不是简单地为 DeepSeek Harness 增加几个 Agent 工具，而是尝试解决现有 Agent 系统在多任务管理、跨会话协作和长期运行方面的架构问题。
过去一年，以 Coding Agent 为代表的智能体已经能够独立完成不少复杂任务，但当用户同时运行多个 Agent 时，仍然需要频繁切换 Session、管理上下文、检查任务进度和协调执行结果。单个任务逐渐能够自主完成，但多个任务之间的协调仍然高度依赖人工。
Super-agent 希望将这部分工作交给系统，让 Agent 不再只是接收一次请求、完成一个任务的执行器，而是逐渐成为能够持续接收事件、协调多个任务并交付结果的长期运行系统。需要说明的是，目前公开的 dsh-superagent-prototype 仍属于研究原型，并非 DeepSeek 已经正式发布的生产级产品。官方也明确指出，开源代码与内部使用版本并不完全相同，设计文章中的部分能力尚未在原型中实现。因此，分析这次发布时，需要区分架构设计、已经实现的技术机制以及后续可能发展的方向。
一、Super-agent 解决的核心问题
传统 Agent 通常以 Session 为基本运行单位。用户提出目标，模型根据上下文选择工具、执行操作、获取反馈，直到任务完成。
前面 Agentic AI 系列介绍的 Agent Loop、Tool Calling、Planning 和 State Machine，主要也是围绕这一执行过程展开。但当任务从一个增加到多个时，系统会遇到新的问题。例如开发人员同时安排三个 Coding Agent，分别处理 Bug 修复、功能开发和代码审查。每个 Agent 都能独立调用工具，但开发人员仍然需要维护不同 Session 的上下文、跟踪执行状态，以及决定什么时候需要重新介入。如果将所有任务放进同一个 Session，又容易出现上下文混杂、工具执行阻塞和任务相互干扰。
Super-agent 的核心思路，就是将用户交互、全局任务协调和具体任务执行分离，使系统能够在保持统一交互入口的同时，并发推进多个工作任务。DeepSeek 提出了四个主要目标：Continuous、Productive、Proactive 和 Persistent，分别对应持续交互、多任务执行、主动发现工作以及长期稳定运行。这几个目标实际上意味着 Agent 的组织方式正在从单次会话走向持续任务管理。
二、Router / Worker 双层架构
Super-agent 最重要的设计是 Router / Worker 双层结构。Router 负责全局上下文、事件接收、任务识别、任务分派和对外沟通；Worker 则拥有独立 Session 和工具环境，负责具体工作。
| 组件 | 核心职责 |
| Router | 维护全局任务关系、分派任务、汇总结果 |
| Worker | 在独立 Session 中执行具体任务 |
| Trigger | 表示从外部环境接收到的事件 |
| Thread | 组织同一讨论或工作事项的相关事件 |
| Ticket | 持久化需要跟踪的工作任务 |
| Assignment | 表示某次具体执行安排 |
| Session | 保存执行上下文与历史 |
在这种结构下，Router 不直接承担耗时的代码修改、测试或资料分析工作，而是将任务交给不同 Worker。Worker 之间可以并发执行，完成后再将关键结果或需要人工介入的问题报告给 Router。
整个系统可以简化为：
这里容易与传统 Multi-Agent 混淆。传统 Multi-Agent 通常围绕一个复杂任务进行拆分，由多个专业 Agent 协作完成；Super-agent 的 Router 则面向多个持续存在的任务，每个 Worker 可以执行相互独立的工作，也可以在内部继续使用 Subagent 或 Agent Team。因此，Super-agent 并不只是增加了更多 Agent，而是把跨任务协调提升成了一个独立的系统层次。
三、事件驱动与任务路由
传统 Agent 大多由用户主动输入 Prompt 触发，而 Super-agent 希望能够持续接收环境事件，例如 GitHub Issue、Pull Request 评论、CI 失败、群聊消息等。这些事件被统一表示为 Trigger。但实际环境中，大部分消息都不需要 Agent 处理。如果每个事件都调用大模型判断，不仅成本高，还可能造成大量无意义的任务触发。
DeepSeek 因此采用了类似计算机系统中的 Fast Path / Slow Path 设计。Fast Path 通过确定性规则检查来源、用户、群组、事件类型和授权范围，过滤掉大部分无关消息；Slow Path 则针对需要语义理解的候选事件，由模型进一步判断是否创建任务、关联现有任务或忽略事件。这一思路与前面介绍的 Routing 模式高度一致：能使用规则判断的部分交给代码，真正复杂的语义判断才使用模型。
Thread Subscription
Super-agent 还设计了 Thread Subscription 机制。当某个 Worker 已经负责一项任务以后，后续发生在相关 Thread 中的事件，可以直接交给该 Worker，而不需要每次重新经过 Router 的模型判断。例如 Worker 正在处理某个 GitHub Issue，开发人员随后补充复现步骤或测试反馈，事件可以直接进入已有 Worker Session。这种机制既减少了 Router 的调用压力，也避免了同一任务在多个 Session 之间反复建立上下文。
Proactive Execution
在进一步的设计中，Agent 还可以根据事件主动准备工作，例如发现 CI 异常后尝试复现，或者在用户明确要求之前准备可能有价值的修复建议。但主动执行必须受到规则约束。
当前公开原型中的推断式任务接纳模式包括 off、observe 和 auto。其中 observe 是默认模式，可以评估哪些事件值得处理，但不会真正接受推断出的任务；切换到 auto 后，也只有满足启用规则的事件才能触发自动任务。这说明 Super-agent 的“主动性”并不是完全交给模型自由决定，而是建立在确定性授权和任务规则之上。
四、Context 管理：Inline & Spill 与 Chain of Recall
Router 长期在线以后，还会遇到一个问题：它需要知道大量任务之间的关系，但不可能把所有历史消息、工具结果和完整文档一直放在模型上下文中。
DeepSeek 为此提出了 Inline & Spill。Inline 将当前可能需要的信息直接放入 Context，例如任务摘要、相关 Thread 和近期反馈。Spill 则把完整历史或低频信息保留在外部存储中，只在 Context 中保存摘要和引用标识。这种方式实际上把 Context Window 当作一种容量有限的高速缓存，而不是无限增长的历史记录。进一步地，DeepSeek 提出 Chain of Recall：为 Trigger、Thread、Ticket 和 Session 等对象建立关联关系，模型可以根据这些引用逐步恢复需要的历史上下文。
例如用户在新的 PR 评论中询问某项修改的背景，Router 可以从当前 Thread 找到关联 Ticket，再追溯原始 Issue、Worker Session 和相关处理记录。这一机制与 RAG、Memory 都存在联系，但并不完全相同。
| 技术 | 主要解决的问题 |
| Context Engineering | 当前模型请求应该看到什么 |
| RAG | 从外部知识中检索相关信息 |
| Long-term Memory | 从历史中沉淀长期有价值的信息 |
| Chain of Recall | 根据任务与事件关系恢复历史上下文 |
因此，Chain of Recall 更接近一种面向任务关系的上下文恢复机制，并不意味着 Super-agent 已经解决了长期记忆的全部问题。
五、异步执行、持久化与 Watchdog
为了让 Agent 在执行耗时任务时继续响应用户，Super-agent 进一步提出异步交互机制。传统 ReAct Loop 通常需要等待工具返回以后才能进入下一步。如果工具运行时间较长，当前 Session 就容易阻塞。
异步执行允许系统启动后台任务、暂时返回控制权，并在任务完成时将结果重新注入执行上下文。在此基础上，官方设计还讨论了计算、持久化状态和工具执行环境的分离，使 Agent 可以长期运行，并在不同设备或执行环境之间协调工作。例如，云端保持 Agent 的持续运行能力，而具体工具可以在获得授权的本地或远程环境中执行。不过，存算分离、跨设备 BYOM 和完整的异步执行体系属于设计文章的重要方向，不能直接认为公开原型已经全部实现。
另一个值得关注的设计是 Watchdog。传统系统监控通常关注进程是否存活、接口是否超时，而 Agent 即使没有发生程序错误，也可能陷入无效循环、反复调用工具或偏离原始目标。因此 DeepSeek 提出在主 Agent 系统外设置独立 Watchdog，既检查基础设施状态，也评估 Worker 是否取得实质进展，并在必要时触发恢复或人工介入。
这反映出 Agent Runtime 与普通业务程序的一个重要区别：长期运行的 Agent 不仅需要监控系统是否还在执行，还需要判断执行过程是否仍然有效。
六、公开原型已经实现了哪些能力
当前开源的 dsh-superagent-prototype 基于 DeepSeek Harness，主要面向单个 GitHub 仓库的 Coding Agent。它可以监听 GitHub 事件，并可选接入飞书；获得授权的工作请求会被转换成 Ticket，再交给独立 Worker Session 执行，最终通过原始交流渠道返回结果，例如 Pull Request。从公开代码看，它已经不只是简单的 Router Prompt，而是包含任务状态、持久化、事件处理和执行恢复等工程机制。
| 能力 | 当前公开情况 |
| GitHub 事件接入 | 已实现 |
| 可选飞书接入 | 已实现 |
| Router / Worker 分工 | 已实现 |
| Ticket 与 Assignment 管理 | 已实现 |
| 独立 Worker Session / 目录 | 已实现 |
| 并发 Worker 与容量控制 | 已实现 |
| Thread 关联及事件分发 | 已实现 |
| SQLite 状态持久化 | 已实现 |
| 失败重试与任务恢复 | 已实现一定支持 |
| 主动任务规则与观察模式 | 已实现 |
| 跨设备 BYOM | 尚非完整公开实现 |
| 独立智能 Watchdog | 尚非完整公开实现 |
| 通用企业级多租户隔离 | 不能视为已具备 |
官方 README 也明确说明，该代码仅供研究参考，尚不能作为生产就绪的软件直接部署。这一点对理解项目定位非常重要：设计文章展示的是 Super-agent 希望达到的系统形态，开源原型则只验证其中部分关键机制。
七、官方实验结果与架构收益
DeepSeek 公开了一组初步实验，将 Super-agent 双层结构与单 Session + Subagent 的实现进行比较。实验模拟持续到来的群聊与 GitHub CI 消息，每轮约包含 300 条消息和 20 个工作请求，任务执行通过耗时工具模拟，每种方案重复 5 次。
| 方案 | p50 完成时间 | p95 完成时间 | Cache-read Tokens |
| Super-agent | 12.4 分钟 | 15.7 分钟 | 23.2M |
| Super-agent（无 Pass-through） | 12.6 分钟 | 15.5 分钟 | 31.8M |
| 单 Session + Subagent（普通提示） | 20.4 分钟 | 29.5 分钟 | 6.1M |
| 单 Session + Subagent（优先委派） | 13.8 分钟 | 29.0 分钟 | 10.8M |
从实验结果看，双层结构在该模拟负载下降低了任务完成时间，尤其改善了长尾延迟。原因并不复杂：Router 不参与耗时执行，不同 Worker 的任务不会相互阻塞；而单 Session 方案是否调用 Subagent，仍然受到模型即时决策和 Prompt 的影响。但代价也很明显。Super-agent 使用了多个独立 Session，缓存读取 Token 明显增加。相比普通单 Session 方案，它更接近用额外计算资源换取更高的并发性和更稳定的任务完成时间。
另外，Pass-through 主要减少了 Router 的决策和上下文开销，并没有在本次实验中显著缩短任务完成时间。这些数据只能够说明在特定模拟事件负载下，Router / Worker 架构具有调度优势。由于实验次数较少，Coding 工作也经过简化，不能据此认为 Super-agent 已经证明了更高的代码质量，或者在真实生产环境中一定拥有相同的性能收益。
八、优势、限制与工程成本
Super-agent 的优势主要集中在任务组织层，而不是基础模型能力层。
| 架构设计 | 主要优势 | 代价与限制 |
| Router / Worker | 多任务并发、统一交互 | Router 可能成为调度瓶颈 |
| 独立 Session | 减少不同任务的上下文干扰 | Token 与资源消耗增加 |
| 事件驱动 | 减少人工重复发起任务 | 误触发、重复事件与消息噪声 |
| Thread Subscription | 降低重复路由成本 | 关联错误、订阅生命周期管理 |
| Inline & Spill | 减少上下文冗余 | 可能遗漏需要恢复的信息 |
| 异步执行 | 避免长任务阻塞前台 | 并发、取消及结果顺序更复杂 |
| Watchdog | 改善长任务异常恢复 | 监控本身也可能产生误判 |
| 存算分离 | 支持长期在线与多环境执行 | 远程授权、凭据与安全成本 |
权限隔离是当前最明显的限制
公开原型虽然提供了独立 Worker Session 和目录，但这些并不等同于操作系统级安全隔离。根据官方部署文档，Worker 使用 danger-full-access，并以运行它的操作系统用户身份执行命令。命令包装和目录约束不能可靠阻止 Worker 访问其他路径。因此：Session 隔离不等于文件系统隔离，更不等于安全权限隔离。如果要让 Super-agent 长期接入企业代码、内部 API、数据库或办公系统，必须进一步建设独立执行身份、沙箱、最小权限、凭据隔离和操作审计。
复杂任务之间的协作仍有待完善
Router / Worker 结构比较适合同时处理多个相对独立的任务，但如果多个 Worker 修改相同代码或依赖同一份资源，就可能出现版本冲突和执行依赖问题。这时仍然需要任务依赖管理、资源锁、冲突检测和补偿机制。因此，多 Worker 并发并不自动意味着复杂 Multi-Agent 协作已经得到解决。
九、与主流 Agent 框架的对比
Super-agent 与 Pi、LangGraph、AgentScope 等方案存在明显差异，但它们并不是完全互相替代的产品。
| 项目 | 主要定位 | 核心特点 | 与 Super-agent 的区别 |
| DeepSeek Harness | Agent Harness | Plugin、Session、Tool、Agent Loop | 提供底层运行能力 |
| Pi | 轻量级 Agent Harness | 小核心、Extensions、Skills | 更强调单 Agent 的可扩展性 |
| LangGraph | 状态化 Agent Runtime | State Graph、Checkpoint、Interrupt | 更强调显式工作流与状态控制 |
| AgentScope | Agent 开发与运行框架 | Multi-Agent、Tool、Memory、Runtime | 提供更广泛的 Agent 开发和部署组件 |
| OpenAI Codex | Coding Agent 产品与平台 | 代码执行、隔离工作环境、任务交付 | 更偏向成熟的单任务执行环境 |
| Super-agent | 持续任务协调架构 | Router、Worker、事件驱动、长期任务管理 | 重点是跨任务协调与统一交互 |
从架构层次来看，Super-agent 更像是在现有 Agent Runtime 之上增加一层长期存在的任务协调机制。例如，可以使用 LangGraph 执行一个具有明确状态的复杂任务，也可以使用 Pi 或其他 Agent Harness 作为 Worker 的运行基础；Super-agent 负责的则是这些任务从哪里来、由谁执行、如何持续跟踪，以及什么时候需要用户介入。
这也解释了它与传统 Multi-Agent 的区别。普通 Multi-Agent 通常围绕一个复杂目标拆分和协调子任务；Super-agent 则主要面对多个持续存在的工作事项，每个 Worker 内部仍然可以继续使用 Multi-Agent 或 Subagent。因此，Super-agent 更强调任务之间的协调，而不是替代任务内部的 Agent 执行机制。
十、适用场景与落地边界
从当前设计看，Super-agent 更适合具有持续事件来源、多个独立任务和明确人工确认机制的场景。
| 场景 | 适合探索的能力 |
| 软件研发 | Issue、PR、CI 事件驱动的修复与审查 |
| 自动化测试 | 回归失败分析、问题复现、结果跟踪 |
| IT 运维 | 告警关联、故障分析、受控处置 |
| 企业文档处理 | 文件变更、异常任务与处理结果跟踪 |
| 企业知识维护 | 知识更新、过期检查、文档影响分析 |
| 企业办公流程 | 跨系统事项跟进、异步任务协调 |
例如，在研发平台中，Super-agent 可以持续接收 Issue 和 CI 事件，将不同问题分派给独立 Worker，完成代码排查、测试和修复建议，再通过 PR 交付结果。这也是当前公开原型最接近实际应用的方向。
对于企业文档与知识系统，也可以借鉴类似机制：例如 云文档中的文档变更或处理异常，以及企业知识助手涉及的知识更新和关联检查，都属于可以进一步研究事件驱动任务协调的场景。但这些应用更适合作为现有文档与知识服务之上的辅助能力，不需要因此替换原有的权限体系或确定性处理流程。
需要强调的是，这些属于架构层面的应用延伸，并非 DeepSeek 原型已经支持的通用业务功能。对于单次知识问答、文件转换、固定 Workflow 等任务，现有服务或普通 Agent Loop 通常已经足够，没有必要全部纳入 Super-agent。
十一、后续可能的发展方向
DeepSeek 在设计文章中提出的开放问题，以及现有 Agent Runtime 的发展趋势，主要指向以下几个方向。
Router 专用化。 高频事件分类、任务优先级判断和简单路由可以更多使用规则、轻量模型或专用决策模型，将高成本推理能力留给复杂协调问题。
跨任务 Memory。 Chain of Recall 主要解决关联历史恢复，但长期运行数月甚至更久以后，还需要独立的记忆提取、更新、遗忘与检索机制。
分布式任务协调。 当任务规模继续增加时，单 Router 可能无法承担全部工作，需要研究分层 Router、任务分片、跨 Worker 通信和资源冲突控制。
执行环境安全。 云端 Agent 与本地设备、企业内网、代码仓库之间需要更加严格的权限继承、沙箱隔离、凭据保护与审计。
任务进展监控。 Watchdog 可以从基础设施健康检查扩展到任务质量、目标偏移和无效循环识别，但必须防止监控机制本身引入新的错误。
交互方式变化。 随着后台 Worker 和长期 Ticket 增加，产品界面可能逐渐从 Session 列表转向任务、进度、待确认事项和交付结果的统一管理。
其中值得关注的一点是，未来的 Super-agent 不一定要求所有 Worker 使用同一种模型、框架或执行环境。Router 可以统一协调任务，而 Worker 根据具体工作选择不同的 Harness、工具和计算资源。这可能使 Super-agent 从当前面向 Coding Agent 的研究原型，进一步演进为更加通用的长期任务调度体系。但能否发展到这一阶段，还取决于模型决策质量、系统可靠性、成本和安全治理，而不仅是架构是否支持并发。
十二、总结
DeepSeek Super-agent 的技术价值，主要在于将传统 Agent Runtime 中相对独立的 Session 组织成一个持续运行的任务系统。通过 Router / Worker 双层架构、事件驱动、Thread Subscription、任务持久化和按需上下文召回，系统可以在保持统一交互入口的同时，并发推进不同任务，减少用户管理多个 Session 的负担。
从前面 Agentic AI 系列的技术体系来看，Super-agent 并没有推翻已有的 Agent Loop、Routing、Planning、State Machine、Memory 和 Harness，而是将这些能力重新组合到更高一层的系统架构中。它的创新更多来自任务调度、事件驱动、缓存、持久化和监控等传统计算机系统设计思想与 Agent 技术的结合，而不是一种新的模型推理算法。
当前公开原型已经验证了部分关键机制，但仍存在安全隔离不足、跨任务依赖复杂、长期 Memory 不完善以及运行成本较高等问题，因此不宜直接作为成熟的企业级框架使用。对于开发者而言，最值得借鉴的是这种分层思路：将全局任务协调与具体 Agent 执行分离，把 Session 从用户直接管理的工作单元转变为系统内部的执行资源。
如果说传统 Agent 主要解决的是“怎样完成一项任务”，那么 Super-agent 尝试进一步解决的是：怎样让一个长期在线的系统，同时管理并可靠推进多项任务。这可能是 Agent 从单次任务工具继续走向持续性工作系统的重要演进方向。
