2026 年 10 月 31 日晚，DeepSeek Harness 团队发布架构长文《Super-agent 设计探索：迈向更自主的 Agent 系统》，并同步开源研究原型 dsh-superagent-prototype。本报告核实发布事实、拆解架构设计、核对实验数据，并给出对我方团队自动化体系的借鉴建议。
一句话结论：这不是一篇模型论文，而是一份 Agent 系统架构设计——把"会话管理"从人手上移交给系统，让 AI 调度 AI、人只负责关键决策与验收。它要解决的瓶颈不再是模型能力，而是人的注意力：一个人只能同时盯住 3～5 个会话，Agent 越多，人越累。Super-agent 用 Router/Worker 双层架构、事件驱动、异步交互、存算分离和外部 Watchdog 五个机制，让系统能持续接活、安静干活、只在必要时开口。
本次发布由三部分组成，性质各不相同。其一是技术长文《Super-agent 设计探索：迈向更自主的 Agent 系统》，发布于 DeepSeek Harness 团队官方公众号，面向工程实践讨论系统架构；其二是开源仓库 deepseek-ai/dsh-superagent-prototype（MIT 协议，TypeScript/pnpm 工程，含 000～008 编号文档），README 明确说明它是"仅供参考的研究原型，不是 DeepSeek 正式产品"，经公开化改编，与内部版本及长文描述的实现不完全一致，部分设计尚未落地；其三是官方披露已在内部持续运行的 Super-agent 实例，参与问题复现修复、代码审查响应和 Harness 自身迭代。
需要澄清的是：它不是 arXiv 论文，没有同行评审实验；它是一份架构设计文章 + 参考实现。这一点决定了对它的正确用法——借鉴设计思想，而非把它当作性能基准。
内部推理框架开源，目标"大模型普惠" · IT之家
同期发布 DeepSeek-V4 预览版，Agent 能力为重点升级方向 · IT之家相关报道
发布两天内仓库达到 8.2k star、833 fork · GitHub，2026-11-02 观测
背景：DeepSeek 近期动作集中在"模型之外"的基础设施——推理框架、沙盒训练环境（DSec）、Agent 运行框架（Harness）。Super-agent 是这条线的最新一层。
DeepSeek 的判断是：模型执行单个任务越来越不需要人干预后，真正限制产出的是人的注意力。主流 Agent 以单一 Session 为基本单位，由此带来三个限制——并行工作要靠人在多个会话间手动切换并维护上下文；一个人通常只能同时跟进 3～5 个活跃会话；本地设备离线，任务就停。
任务之间互不相通，A 会话的结论 B 会话不知道；只有用户自己掌握所有任务的全貌。让一个 Agent 同时干所有事，输出变慢、任务细节互相污染。
长文直言：让用户手动管理 Session，很大程度上是从底层 LLM API 延续下来的设计惯性。用户真正想管理的是任务，会话应该由系统在背后接管。
长文将新型 Agent 形态归纳为四个基础特征：连续（在即时通讯、GitHub 评论等不同渠道与同一个 Agent 交互）、高效（并行处理多个复杂任务）、主动（持续观察环境事件并自行推进值得处理的事项）、持久（始终在线、可从异常恢复）。
主动不等于自作主张。长文强调"Super-agent 只在被请求时、或团队书面规则允许时行动"。对没人直接要求、由系统推断出来的工作机会，原型提供三档模式：
不接收任何推断出的主动候选，只执行明确请求。
评估候选并把"本来会接单"记录下来，但不实际开工。先看它会选什么活，发现误判改规则，代价远小于撤回一批已开始的修改。
匹配到已启用的规则后才实际接单开工。自主程度由规则、范围和实际效果共同决定。
官方示例完整走了一遍这条链路：群里有人说"这个项目有 Bug"，没人 @ Agent——消息过两道筛网，命中团队预先写好的"静默复现并修复"策略，Router 派单，Worker 在独立空间复现、定位、修复；修不好或太复杂就保持安静，确认问题且方案简单才提交 PR，交给人验收。后续 GitHub 评论里的修改意见，会经由订阅直接送达同一个 Worker，任务在聊天软件与代码仓库之间连续推进。
长文对比了四种方案（Super-agent、去掉事件直通的 Super-agent、两种提示词配置的单 Session+Subagent）。每次实验约 300 条消息、其中约 20 条为工作请求，每种方案重复运行 5 次；消息间隔与工作时长按四分之一缩放，模型调用耗时保持真实。公开披露的核心数字如下：
Super-agent：p50 = 12.4，p95 = 15.7；单 Session + Subagent（中性提示）：p95 = 29.5（约为此前方案的 1.9 倍；该方案 p50 未在公开报道中给出）。加载失败时请以此文字数据为准。
Router 层压力测试显示，事件突发时系统靠"合并积压事件"保住吞吐：
| 指标（Trigger 速率从低到高） | 约 1 条/分钟 | 约 40 条/分钟 | 变化 |
|---|---|---|---|
| 平均批处理大小 | 1.0 | 2.8 | 合并提效 |
| 单次请求耗时 | 2.5 秒 | 3.9 秒 | 上升 56% |
| 单个决定的分摊推理时间 | 6.4 秒 | 1.6 秒 | 下降 75% |
变化列为本报告依据公开数字计算：3.9/2.5≈1.56，1.6/6.4≈0.25。
另外值得注意行业坐标：Anthropic 的 Claude Duet 走的是同一方向（主动读邮件日历、晨报简报、重要动作留人批准）；而 Anthropic 此前的《构建 Agent》一文主张"单个 Agent 优于子 Agent 舰队"。Super-agent 的回答是：Router 不管任务细节、Worker 上下文隔离靠订阅感知冲突，用极低耦合绕开了"编排者负担"。两条路线的分歧本身就是信号——Agent 系统设计已成为头部实验室的正面战场。
我们的现状是：已有一批围绕猎头业务链路的自动化能力（多平台寻访、简历处理、CRM 同步、定时盯盘与日报），由中枢技能统一调度。这套体系与 Super-agent 的 Router/Worker 结构同构，差距集中在四点：事件驱动不足（多为定时轮询）、授权缺乏分档、任务档案不连续、状态恢复无保障。对应六个动作：
| 借鉴点 | DeepSeek 的做法 | 我们的落地动作 |
|---|---|---|
| 1. 注意力预算 | 把每条消息、通知、提问都视为注意力成本；"尽可能少占用注意力，尽可能多提供价值"；只在结果可用、需要决策或失败时开口。 | 重设计现有日报与播报类产物：合并为"今日需要我决定什么"面板式摘要；砍掉过程性播报，保留待决策、待验收、异常三类信息。 |
| 2. 事件驱动替代轮询 | Trigger 监听环境事件，两道筛网（程序规则→语义研判）过滤后才启动工作，避免每条消息都烧模型。 | 把盯盘、候选人动态、群消息类定时任务逐步改为事件触发：先规则过滤（来源白名单、关键词），命中再进语义研判，降低无效运行成本。 |
| 3. 授权三档制 | 主动接单默认 observe：只记录"本来会接单"，人工复核后再放 auto；明确请求与推断候选分开授权。 | 为所有自动化通道（尤其 Boss、脉脉、领英等有账号风险的平台）建立 off/observe/auto 三档准入；新自动化先观察跑一至两周，审误判日志再逐步放权。 |
| 4. 任务档案连续化 | Trigger/Thread/Ticket/Subscription 四对象让任务跨平台连续推进；收到上下文不等于获得新授权。 | 给候选人推进、客户沟通类长流程建"工单式"档案：跨群聊、邮件、CRM 的事件挂到同一任务，后续消息直达执行端；授权范围随工单单独维护。 |
| 5. 存算分离与恢复 | 云端管计算与状态、本地只留执行 daemon；先记录后执行、持久队列重试，恢复时先核对 Git 历史与外部状态，避免把已完成的操作再做一遍。 | 解决"电脑合盖任务中断"：长任务状态外置（云端文档/数据库），本地只做执行；关键动作（发消息、投递简历）全部幂等化，重启后先核对再续跑，防止重复外呼。 |
| 6. 外置 Watchdog + 新评估口径 | 独立会话巡检"有无实质进展、方向是否跑偏"；社区建议考核人工介入时间、首次可验收率、返工成本，而非产出了多少。 | 给长流程自动化加独立检查任务（判进展与方向，而非仅存活）；按“人工介入时间 / 首次可验收率 / 返工轮次”三个指标建立自动化效果台账。 |
战略层的判断：模型与 Agent 基础设施正在快速商品化，开源方向对我们有利——这份 MIT 协议的原型可以直接研读（000 Philosophy 到 008 Cookbook 的文档结构本身就是一份优秀的系统设计教材），但不建议直接生产部署：它的权限模型、面向单个 GitHub 仓库的定位，与我们的业务通道不匹配。正确姿势是借它的架构词汇（Router、Ticket、observe 档、Watchdog）重构我们自己的技能编排与治理规则，把团队的重心放在工作流数据、授权规则和验收标准这三个不会被商品化的环节上。