结论先说：DeepSeek 在 10 月 31 日公开了一份 Agent 架构技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，同时把参考实现以 dsh-superagent 的名字开源在 GitHub（MIT 协议）。它的核心不是又一个"更强的模型"，而是一个调度层：用一个常驻的 Router 加一组独立会话的 Worker，把 Agent 从"一次会话干一件事"改成"长期在线、并行干多件事"。官方给出的初步实测是任务完成时间中位数 12.4 分钟、95 分位 15.7 分钟，而传统"单会话 + Subagent"方案在中性提示下 95 分位要 29.5 分钟。

这次 DeepSeek 到底发布了什么？

先把性质说清楚，避免误读。

• 是一篇架构文章 + 一个研究原型，不是新产品。GitHub 仓库 README 明确写着"Research prototype for reference only, not an official DeepSeek product"，作者也说明代码是从日常研发中长出来的、经过改编，与内部版本并不完全一致。
• 发布方是 DeepSeek Harness 团队，时间点 2026 年 10 月 31 日，仓库首个提交也是同一天。
• 原型能力范围比文章窄：仓库说明它目前是一个"面向单个 GitHub 仓库的主动型 coding agent"，监听 GitHub，可选接入飞书（Feishu），被授权的人提出工作请求后，它会开一个工作项、在自己的会话和目录里执行、再回到原对话里答复（例如给出一个 Pull Request），并提供一个网页面板显示"哪些事需要人来处理"。
• 许可宽松：MIT。

所以更准确的说法是：DeepSeek 把自己的 Agent 工程经验摊开给人看，顺手给了一份能跑起来的参考代码。文章讲的是完整设想，代码实现的是其中一部分。

Super-agent 要解决的真问题是什么？

不是模型不够聪明，是人的注意力不够用了。

DeepSeek 团队的观察是：一个人通常只能同时跟进 3 到 5 个活跃 Session。而现在主流 Agent 仍以"会话"为基本工作单位——你在群里讨论方案，切到 GitHub 提 PR，再根据评论改代码，每一步都散在不同会话里，上下文要你自己记着、自己搬运。

于是出现一个很别扭的局面：模型处理单个任务越来越强，多任务协作效率却被人的切换成本卡住。CLI、MCP 这些工具让 Agent 接入了更多平台，但没解决单会话串行执行、多任务上下文混乱、本地设备一关机任务就断这三件事。

DeepSeek 对 Super-agent 的定义就是冲着这三点去的，它列了四项能力：

• 连续：跨会话、跨平台保持任务上下文，用户不用反复解释前情。
• 高效：多个复杂任务并行，耗时任务不阻塞新的交互。
• 主动：持续观察环境变化，必要时自己采取行动。
• 持久：长期在线运行，遇到异常能尝试自动恢复。

Router + Worker 的双层架构是怎么分工的？

可以理解成一个 AI 虚拟团队：一个主管，若干执行者。

Router 是常驻的全局协调节点。它统一接收来自群聊、GitHub、邮件等不同平台的信息，判断任务该分给谁，并维护跨任务的全局上下文。因为它主要负责"理解信息 + 分派任务"，DeepSeek 认为相对轻量的模型也可能胜任，能力更强的模型留给复杂执行。

Worker 是真正干活的会话。每个 Worker 有独立上下文和工具权限，可以分别负责问题复现、代码审查、功能开发，必要时还能再往下调用 Subagent。干完之后把关键结果汇报给 Router，由 Router 统一跟用户沟通。

对用户来说，面对的一直是同一个助手；对系统来说，背后可能已经有好几个 Agent 同时在跑。

这里有个容易被忽略的工程设计：订阅与直通机制。当某个 Worker 接手了一个 GitHub PR，后续评论和状态变化可以直接投递给它，不必每次都经过 Router 转发。DeepSeek 的实测里，取消这个直通机制后，Router 需要做的决策次数增加约 30%，缓存读取 Token 从 2323 万涨到 3177 万，增幅约 37%。反过来理解就是：路由做得好，能实实在在省钱。

没人 @ 它，AI 为什么敢自己动手？

这是全文最值得琢磨的一段，因为它同时涉及效率和风险。

传统助手是"你问—它做"。Super-agent 改成"环境变—它判断—它做"。群聊消息、邮件、日程提醒、GitHub 评论、CI 测试结果都可以成为触发事件（Trigger）。

但群里绝大多数消息不需要 AI 插手，所以 DeepSeek 做了两级过滤：先用程序规则快速筛掉无关消息，再交给大模型结合上下文判断是否需要行动。这一步很关键——如果所有消息都送进大模型判断，Token 消耗会失控。

筛完之后，DeepSeek 借用了计算机体系结构里的投机执行（Speculative Execution） 思路：在结果是否被采用还不确定时，先用后台算力试着做。它在内部用户群配了一项"静默复现并修复"策略——有人反馈 Bug 或讨论改法时，Super-agent 先在后台复现问题、分析原因、找修复方案；只有确认问题存在且修复方案足够简单，才把结果交给开发人员，否则全程保持安静。公开案例里，团队还在群里讨论方案，它已经把修复 PR 提交了。

这个"没有把握就不说话"的约束，我认为是整篇设计里最务实的一条。主动型 Agent 最大的风险不是做错，是吵——一个不停汇报"我检查了，没问题"的助手，会迅速把人的注意力耗光。

顺带解决阻塞问题的是异步 ReAct Loop：耗时工具调用转后台执行，前台继续接收新消息，用户可以中途改方向或叫停。这个机制已经在 DeepSeek Harness 里实现，但尚未默认开启。

关机之后任务还能继续？靠的是存算分离

长时在线这件事，DeepSeek 抄的是"存算分离"的老思路：

• 执行循环放云端；
• 会话状态存数据库；
• 代码仓库、文件、工具链这些工作环境仍留在用户本机；
• 本地只跑一个轻量 daemon，负责接收云端命令、回传结果。

这样即使电脑离线，云端仍能维持任务状态，设备重新上线后继续推进。

另外还有一个Watchdog（看门狗），相当于给 Agent 配了个 AI 监督员，负责判断任务是否取得进展、是否陷入无效循环、是否偏离目标，发现问题时尝试介入修复。注意它是"另一个 AI"，不是硬编码的规则断言——灵活，但也意味着监督者本身也需要被监督。

实测数据到底说明什么，又没说明什么？

实验设定：模拟群聊与 GitHub CI 的消息流，单次约 300 条消息，其中约 20 条是真正的工作请求；每种方案重复运行 5 次。

• Super-agent：任务完成时间 p50 = 12.4 分钟，p95 = 15.7 分钟。
• 传统"单会话 + Subagent"、中性提示词：p95 = 29.5 分钟。
• 差距来源不是模型更强，而是调度。传统方案里"要不要派给 Subagent"取决于提示词和临场判断，中性提示下五次实验模型一次都没调用 Subagent，全部堆在主会话里互相干扰。

代价也很清楚：需要维护多个独立会话，缓存读取 Token 更高。

但必须说清楚实验的边界：DeepSeek 自己说明，实验用的是合成消息和模拟耗时的工具，主要验证调度与协作能力，并未直接评估真实编码质量。也就是说，"快"是被验证了的，"对"还没有。看这类数据时，把"p95 缩短近一半"当成调度效率的证据，而不是 Agent 变强的证据，才不会被带偏。

想落地，还差哪几块？

DeepSeek 在文末列了三个坎，我认为列得挺诚实：

• 长期记忆：任务积累到数周甚至数月后，怎么准确恢复历史上下文还是难题。
• 安全与隐私：Super-agent 持续接收外部消息、又通过云端访问本地设备，一旦遇到提示词注入或服务端被入侵，代码仓库、敏感数据、本地凭据都可能被牵连。这一点对我们站里之前写过的 Agent 安全事件（智能体越界、MCP 指令传染）是同一个坑的不同侧面。
• 人机界面：Agent 同时推进大量任务时，用户怎么查看进度、怎么介入、哪些操作必须人工批准，都得重新设计。

他们也很坦诚地说，这套东西没有新理论，只是把任务调度、缓存管理、事件驱动、存算分离这些经典计算机系统思想搬到了 Agent 架构上。

我个人觉得这个"没有新理论"反而是可信度的来源。2026 年下半年 Agent 赛道最缺的不是新概念，是把操作系统几十年的工程经验认真搬过来的人。

对普通用户和开发者意味着什么？

• 如果你只是用 ChatGPT / Claude 干活：短期不会有直接变化。这套架构属于"Agent 基础设施"层，落到产品上要等 DeepSeek 把它做进 Harness 或正式产品。
• 如果你在自建 Agent：dsh-superagent 的价值在于它给了一份"Router 怎么分派、事件怎么过滤、Worker 怎么隔离目录"的可运行参考，而且是 MIT。想复刻的话，先读 docs/000-philosophy.md（讲"尽量少占用人的注意力"这条原则），再看 002 授权、003 执行、007 架构。
• 如果你在评估 Agent 产品：以后听到"我们的 Agent 可以并行处理多任务"，可以追问一句"你的调度层是谁在做决定、有没有事件过滤、失败怎么自愈"。这三个问题能快速分辨是真架构还是套壳。

常见问题（FAQ）

Q：Super-agent 是 DeepSeek 的新模型吗？ A：不是。它是 Agent 系统架构，模型只是其中一个组件。文章和代码讨论的是调度、会话管理、事件驱动这些工程层问题。

Q：开源代码能直接拿去生产用吗？ A：官方明确不建议。README 原文是"Treat it as research code, not production-ready software"，并提示可能有 bug、工程实践不一致，需要自行审查和适配。许可为 MIT。

Q：它能接微信或 Slack 吗？ A：按仓库说明，当前监听 GitHub，可选接入飞书。其他平台需要自己按 docs/008-cookbook.md 扩展 Source。

Q：12.4 分钟和 29.5 分钟是同一件事的耗时对比吗？ A：是同一套模拟环境下的任务完成时间分位数对比（p50 / p95），实验用合成消息和模拟工具，不代表真实项目里的编码耗时。

Q：主动干活会不会乱改代码？ A：原型的设计前提是"只在被要求、或团队写明的规则允许时才行动"，并配套授权文档与网页面板人工确认。但文章也承认，长期运行下的权限边界和提示词注入防护仍未解决。

来源与说明：本文基于 DeepSeek Harness 团队 2026-10-31 技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》、GitHub 仓库 deepseek-ai/dsh-superagent-prototype（README 与文档目录，2026-10-31 首提交，MIT 协议），以及量子位（2026-10-31）、爱范儿（2026-10-31）的公开报道整理。文中所有数字、时间、模块名称均来自上述公开材料，未作推测性补充；实验局限部分为原文自述。

基于公开报道整理，不构成对产品性能的独立评测。