DeepSeek开源Super-agent架构：给企业多智能体协同提供新方案

• 类别： 智能体与编程
• 事件时间： 2026-10-31 晚（DeepSeek Harness 团队公布架构与原型仓库；11 月 1 日经中文媒体扩散）
• 主要来源： [P0] GitHub deepseek-ai/dsh-superagent-prototype（MIT 许可）及仓库文档 000–008；[P1] 智东西、IT之家、通信世界
• 证据强度： A（架构、原型代码、消融数据与设计取舍来自公开仓库与团队文章，可 clone 核验；但实验使用合成负载与简化环境，仓库 README 自述为研究原型、非官方产品、可能含 bug）
• 技术锚点： B（架构与工程：双层调度、事件驱动、存算分离、Watchdog）、E（成本：token 消耗与吞吐的交换关系）、D（适用边界：主动行为的触发条件与噪声控制）
• 本篇关键词： Super-agent、DeepSeek、Router、Worker、事件驱动、订阅直通、Inline & Spill、Watchdog、存算分离、BYOM、读缓存 token、MIT

深度求索（DeepSeek）是中国大模型公司，DeepSeek 系列模型开发方；DeepSeek Harness 团队是 DeepSeek 内部负责 Agent 运行时与工具链的团队，本次开源其 Super-agent 研究原型。goto:AIDeep☀Think.cnDeepSeek 这次开源的不是一个新产品，而是一套"怎么让 Agent 少占人的注意力"的工程答案。它把计算机系统里的调度、缓存、存算分离与看门狗搬进了 Agent 架构，并且把实验数据连同消融结果一起公开——包括那条不太好看的数字：更快的代价是约 3.8 倍读缓存 token。

一、关键参数

下表回答"这套原型到底是什么、跑在哪、能不能直接用"。

二、产品背景

团队给出的判断是：过去一年编码 Agent 已证明模型能用工具解决复杂问题，人越来越少介入底层执行，角色上移到决策与验收。于是瓶颈从"模型会不会干"转向"人跟不跟得过来"——一个人通常只能同时跟进 3 到 5 个活跃会话，单 Session 再聪明也解决不了人只有一份注意力这件事goto:AIDeep☀Think.cn。

仓库 docs/000-philosophy 里那句话是整套设计的入口："Take as little human attention as possible, and give as much value as possible."（尽可能少占用人的注意力，尽可能多地交付价值。）配套的行为规则是：只在被请求、或团队写明的规则允许时行动；只在人必须行动或有可用结果时说话。

三、采用的技术原理或方法

1. 双层架构

根本矛盾是连续性与吞吐量不可兼得：所有事件塞进一个会话，上下文最连续但串行、吞吐低；每个事件新开会话，吞吐最高但全局上下文散掉。解法是拆成两层——Router 层常驻、统一承接人类交互与任务分派，充当全局的序点、协调点和记忆，只调度不执行；Worker 层由上下文彼此隔离的会话组成，专注单一任务，结果向 Router 汇报，由 Router 统一对外回复goto:AIDeep☀Think.cn。

Router 层不出意料地没有成为瓶颈：上一轮推理期间到达的环境事件会积压下来，在下一轮一并处理形成批处理。由于 Router 每步通常是长输入、短输出，多条 Trigger 合并在 Prefill 阶段并行计算，单次请求耗时增长远慢于批处理大小。

2. 事件驱动

群聊消息、邮件与日程、代码审查评论、CI 结果等环境事件统称 Trigger。处理链分四步：

• 两级过滤： 程序层策略作为 Fast Path，按来源、群组范围、用户或机器人白名单等确定性条件快速准入；通过准入的候选事件交给语义层 Slow Path，由 LLM 按提示词策略判断是否需要行动。
• 订阅与直通： 同一 GitHub PR、同一 IM 话题或同一封往来邮件串下的连续事件构成一条 Thread。Router 为某个 Thread 的初始事件创建 Worker 后，该 Worker 直接订阅该 Thread，后续事件由程序直通，不再经 Router 转发。Thread 与 Worker 的订阅是多对多关系。
• Inline & Spill 与链式召回： 把上下文窗口当 Cache 管理——近期很可能用到的信息直接内联进窗口（Inline），超预算或低频的完整信息留在窗口外只保留引用或摘要（Spill），需要时沿 Trigger／Thread／Worker Session 的引用链逐步召回。
• 投机执行： 在结果不确定时先在后台尝试；群里有人讨论一个 Bug，Agent 可先行复现、定位并交付修复，没修好就默默丢弃，不打扰人goto:AIDeep☀Think.cn。

3. 持久化与自愈

经典 ReAct Loop 调用同步工具时会阻塞，会话无法响应新输入。改为异步 start()／stop() 后，模型调用 start() 立即收到已启动返回，后台结果作为新事件投递回会话，前台对话与后台执行解耦，从半双工变为全双工。计算与持久化状态放云端无状态弹性容器，重状态的执行环境留在原地，端侧只跑轻量 daemon，并支持 BYOM（Bring Your Own Machine）。主系统之外配置独立的 Watchdog 会话，不只盯进程存活，还用模型判断各 Worker 是否有实质进展、方向是否跑偏，维护者可用自然语言在线修正提示词与触发规则。

需注意：异步 ReAct Loop 在 Harness 中已实现但默认未开启，不要默认当成已打开的功能。

四、相比较上一代方案有哪些提升

团队的实验设计是：每次约 300 条消息、其中约 20 条工作请求，四种方案各跑 5 次，比较的是调度与协作，不是单任务执行力。下表数字来自团队公布结果。

Router 压测是另一组数字：Trigger 到达速率从约 1 条／分钟提升到约 40 条／分钟时，平均 batch 从 1.0 升到 2.8，单次请求耗时从 2.5 秒增至 3.9 秒，而单个决定分摊的推理时间从 6.4 秒降到 1.6 秒。也就是说，事件越拥堵，积压合并带来的吞吐红利越大。

五、相关产品横向对比

下表是形态对照，不是同口径性能对比：目前没有公开的统一基准把 Super-agent 与其他产品放在同一负载下测量，任何"谁更快"的说法都缺乏依据。

DeepSeek 与 Anthropic 官方页面均未说明两者关系，本表只列形态差异，不构成能力比较。

六、定价或者使用策略

原型以 MIT 许可开源，无许可费用。goto:AIDeep☀Think.cn实际成本来自三部分：自托管所需的 GPU／容器算力、调用模型的 token 费用，以及接入 GitHub 与飞书等平台所需的账号与权限。团队未公布任何托管服务或定价。

七、应用场景、方法或者案例

1. 编码协作

• 目标用户与行业： 软件开发团队、开源项目维护者。
• 具体做法： 被允许的人提需求，系统开 Ticket，在独立 Session 与目录中完成工作，在原对话回复（例如提交 PR）；Web Panel 只展示需要人的事项。
• 当前状态： 研究原型；团队内部基于这套思路的实例已在跑，参与复现修复、审 CR 与 Harness 自身迭代。
• 准入条件： 需专用 GitHub 账号、隔离环境，默认先 observe（主动工作先只记录不真干）。

2. 个人助手

• 目标用户与行业： 需要跨渠道连续处理的个人用户。
• 具体做法： 前端单一聊天页维持交互连续性，底层可为每个话题分别分派 Worker 并行推进、起草回复；会议邀约可先查冲突、备资料、打草稿。
• 当前状态： 文章中描述的方向，原型当前面向单个 GitHub 仓库，仓库自述部分设计"属于未来方向，未在本原型实现"。
• 准入条件： 同上。

八、局限与待验证事项

1. 适用范围

• 实验使用合成负载与简化环境，团队自己把适用范围写得很窄：看调度，不看单任务能力。不能外推为"写代码一定快一倍"。
• 仓库明确为研究原型，团队称已为发表做过改写，与内部版本和实现并不完全一致；文章中讨论的部分设计属于未来方向，未在原型中实现。
• 更快的代价是更多 token：2323 万对 605 万的差距，意味着这套架构在 token 单价高的模型上未必划算。

2. 待验证指标

• 在真实 GitHub 仓库与真实群聊噪声下的表现（目前只有合成负载）。
• 不同模型组合下 Router 用轻量模型的边界——什么规模开始需要水平切分。
• 长期运行的 Watchdog 命中率与误报率。
• 外部复现：是否有第三方在自有环境中跑出相近的 p50／p95 与 token 消耗。

九、安全与伦理

1. 突破的边界

被突破的是"Agent 只在人下指令时行动"的默认约定。Super-agent 会在无人 @ 的情况下主动识别缺陷并提交修复 PR，判断依据是团队用提示词写明的规则。

2. 新增风险面与安全措施

新增风险面很具体：Worker 以操作者 OS 用户的身份执行命令且无审批提示。团队与转述媒体给出的缓解措施包括——使用专用 GitHub 账号而非操作者本人账号、在隔离机或容器中运行、默认先 observe 只记录不真干、自动 merge 默认不由 agent 账号开启（Delivery requirements 另配合并账号）。Watchdog 作为主系统之外的独立会话提供第二层控制回路。

3. 硬性约束与价值争议

价值争议在于"主动"与"打扰"的界线：投机执行失败时默认不制造噪声，这与"Agent 事事汇报"的产品习惯相反。团队把这条写进了设计原则，但没有公布用户侧的主观满意度或打扰率数据，因此无法判断这条界线在实践中是否合适。