科技资讯
10 月 31 日，DeepSeek Harness 团队发布《Super-agent 设计探索：迈向更自主的 Agent 系统》，讨论的不是模型参数，而是一件更偏工程的事：当 Agent 单次只做一件事时，真正卡住效率的往往不是模型，而是人要在多个窗口之间来回切换、盯进度、补上下文【1】。下文配图对应文中展示的两种形态：同一任务在 IM 群聊与 GitHub Pull Request 之间接续推进，以及 Agent 在无人 @ 的群聊里主动认领缺陷。
图：示意图（AI 生成，非原文截图；模型 nano-banana-2）。仅作阅读辅助，事实以正文与参考文献为准。
先把定位说清楚：这是路线图，不是一把即插即用的钥匙
很多转发把这条消息读成「DeepSeek 又发了新产品」，这是误读。据公开报道，该文给出的是名为 dsh-superagent-prototype 的原型实现，团队明确说明它用于验证技术路线，并非 DeepSeek 正式产品【7】。同时，基于这套思路和 DeepSeek Harness 构建的内部实例已在持续运行，参与问题复现与修复、代码审查响应，甚至参与 Harness 自身的迭代【7】。
这两句话要分开看：内部跑得通，说明方向经过真实负载检验；对外只是原型，说明接口、协议和稳定性都还没到可交付的程度。对技术负责人来说，正确的用法是把它当架构参考来对照自家系统，而不是当采购清单。
问题定义：瓶颈不在模型，在人被绑在会话上
按文中描述，现有主流 Agent 仍以单个 Session 为基本单位，Session 之间彼此独立，用户并行推进多项工作时要自己切窗口、自己维护各自上下文【2】。团队给出的观察数字很具体：一个人通常只能同时跟进 3 至 5 个活跃 Session【2】。
更关键的是，靠 CLI、MCP 或外部连接器扩展本地 Agent，并不能消除三个问题：单会话同步阻塞、多任务上下文混乱、本地设备离线后任务直接停摆【2】。这三条正好对应企业里最常见的抱怨——「我开着它就不能干别的」「它记不住上午说过什么」「我合上笔记本任务就断了」。Super-agent 由此提出四项特征：连续（同一 Agent 可跨 IM、GitHub 评论等渠道交互）、高效（并行处理多个复杂任务）、主动（持续观察环境事件并自行推进）、持久（始终在线并能从异常状态恢复）【2】。
架构拆解：五块组件，各自对着一个具体故障
原文把整体设计分为双层架构、事件驱动、面向人的交互、计算与状态及环境分离、Watchdog 五部分【2】。逐块看，会更清楚每一块在补哪个洞。
双层架构把 Router 与 Worker 分开：Router 承接人类交互、维护全局上下文、分派任务；Worker 在相互隔离的会话中并发执行，且不直接回复用户，只把状态和结果汇报给 Router，由后者统一对外沟通【3】。这一层设计解决的是「谁对用户说话」的问题，避免多个执行体同时插话导致信息混乱。
事件驱动把群聊消息、邮件与日程提醒、代码审查评论、CI 运行结果统称为 Trigger；系统先用程序规则过滤，再交给大模型判断是否需要行动；对于已经分配任务的事件流，Worker 可以直接订阅对应 Thread，后续事件由程序直接送达，不再每次都经过 Router，从而降低路由负载【3】。这里的顺序值得注意：先规则、后模型，成本与延迟都能压下来。
上下文管理由两个机制配合。Inline & Spill 把近期可能用到的信息直接放进模型上下文窗口，超出预算或低频使用的内容留在窗口外按需读取；链式召回（Chain of Recall）则利用 Trigger、Thread、Worker Session 等对象之间的引用关系，让模型沿关联 ID 逐步找回历史任务信息【4】。换句话说，长期记忆被外化成了可检索的对象图，而不是硬塞进一次上下文。
减少等待靠投机执行与异步 ReAct Loop。前者根据环境信号在后台提前开工，例如收到会议邀约后先检查日程冲突、搜集背景资料并准备回复草稿；在研发场景中，则先在群聊讨论时尝试复现故障、寻找修复方案，确认问题且找到简单修复后才交付【4】。后者把耗时工具调用改成异步的 start() 与 stop()，Agent 启动后台任务后即返回 Started 状态，结果随后作为新事件进入会话；文中特别说明，该机制已在 DeepSeek Harness 中实现，但尚未默认开启【4】。
运行底座做了解耦：计算与持久化状态放在云端，执行环境可以留在用户本地设备，只部署负责执行命令和返回结果的轻量 daemon，即 BYOM（Bring Your Own Machine），也支持连接云端托管机器或按需创建的计算环境【5】。外层再加一个独立的 Watchdog Session 作为外部控制回路，不仅监控接口报错、状态恢复失败等基础设施问题，还用模型判断 Worker 是否取得实质进展、执行方向是否偏离目标【5】。
实验数字怎么读：看调度能力，别当性能承诺
原文的实验设置是：每次约 300 条消息，其中约 20 条为工作请求，每种方案重复运行 5 次【6】。结果显示，Super-agent 的任务完成时间 p50 与 p95 分别为 12.4 分钟和 15.7 分钟，中性提示下的单 Session 加 Subagent 方案 p95 为 29.5 分钟【6】。
Router 压力测试也给了数据：Trigger 到达速率从每分钟约 1 条升到约 40 条时，平均批处理大小从 1.0 增至 2.8，单次请求耗时从 2.5 秒增至 3.9 秒，而单个决定分摊的推理时间从 6.4 秒降到 1.6 秒【6】。这说明 Router 在事件突发时会合并积压事件来提高有效吞吐——代价是单次响应变慢。
需要克制的地方在于，团队自己标注这些实验基于合成负载和简化环境，主要评估系统调度与协作能力，并不衡量单个任务的实际执行能力【6】。因此别拿这组数字去推算自家业务的提效幅度，它只能说明「多任务调度这一层的设计是有效的」。
对中国团队意味着什么：三种角色，三套动作
**跨境卖家与电商运营。**多平台店铺、多语种客服、广告投放、Listing 优化、物流异常处理天然就是并行场景，而现在很多团队的做法是让运营人员在多个后台之间手动切窗口，与文中描述的「手动维护多个 Session」高度相似【2】。优先级建议：先把「事件收集—任务分派—人工确认—执行回写」做成一条可追踪的管道，再考虑自动化程度。价格、库存、退款这三类动作，起步阶段一律走人工确认。
**企业主与业务负责人。**Super-agent 提示的其实是个组织问题：与其「买一个工具发给员工用」，不如设计一个常驻协作岗位——它看哪些渠道、接哪些事件、哪些动作必须等人批准、谁负责兜底。主动能力越强，权限边界越要先写下来，否则省下的时间会被误操作成本吐回去。
**技术负责人。**把 Router/Worker 分层、事件驱动、状态外置、Watchdog 这几个词翻译成自查清单：任务是否有独立 ID 与状态机；事件是否可重放；Worker 失败能否幂等重试；人工接管是否顺畅；审计日志是否完整到能复盘一次错误决策。这些基础能力，比选哪个框架更能决定 Agent 能不能长期跑下去。
风险清单：主动能力越强，边界越要先划
原文并未回避短板，列出五类待解问题：Router 层如何随任务规模扩展、跨月乃至更长时间跨度的长程记忆、脱离 Session 之后的人机协作方式、不同 Agent 实例之间的 A2A 通信，以及安全与隐私保护【7】。其中特别提示，云端 Agent 接入本地设备后，提示词注入、端侧凭据泄露和跨设备权限风险都需要进一步解决【7】。
对国内团队，这一条要再加一层：把日常开发机接入云端 Agent，本质上是把公司内网的一个入口交给了外部调度系统。上线前建议做三件事——用最小权限的专用账号与隔离环境承载 Worker；对端侧凭据做托管而非明文落盘；在审计日志中记录每一次跨设备调用的发起方与授权依据。
下一步建议：先补「连续」和「持久」，再谈「主动」
第一，选一个高频、低风险、可回滚的场景做 2 至 4 周试点，例如群聊缺陷汇总、客服工单分流、竞品价格监控。先验证事件能否稳定进入系统，再验证 Worker 能否可靠执行。
第二，把「会话」升级为「任务对象」。为每个任务建立任务 ID、状态、负责人、事件日志与产物链接，别让上下文散落在聊天记录里。
第三，设置三层权限：只读观察、建议待批、受限自动执行。涉及价格、库存、退款、代码合并的动作，起步一律放在第二层。
第四，提前设计人工接管与超时熔断。Agent 越主动，越需要明确的停止键、回滚方案和责任归属；异步执行一旦没有超时约束，任务会静默堆积。
第五，评估供应商或自建方案时，固定问四个问题：状态存在哪里、设备离线怎么办、失败如何恢复、审计日志是否可查。
总体看，DeepSeek 这次抛出的是一张架构路线图，价值不在名词，而在它把「人的注意力是稀缺资源」这件事写进了系统设计【1】。短期可以借它的拆分方式审视自己的工作流；中期则要把多任务调度、状态持久化和权限治理提前补齐。等这类产品真正成熟，准备更充分的团队会更容易接住。
参考文献
【1】DeepSeek 提出 Super-agent 架构设计：Router 与 Worker 双层架构，探索更自主的 Agent 系统 — https://www.ithome.com/1/020/615.htm 【2】编辑注：单会话瓶颈、3 至 5 个活跃 Session 与四项特征，基于同一来源的二次整理 — https://www.ithome.com/1/020/615.htm 【3】编辑注：Router/Worker 双层职责与 Trigger、Thread 事件直通机制，基于同一来源的二次整理 — https://www.ithome.com/1/020/615.htm 【4】编辑注：Inline & Spill、链式召回、投机执行与异步 ReAct Loop，基于同一来源的二次整理 — https://www.ithome.com/1/020/615.htm 【5】编辑注：计算与状态及环境分离、BYOM 与 Watchdog 控制回路，基于同一来源的二次整理 — https://www.ithome.com/1/020/615.htm 【6】编辑注：任务完成时间与 Router 压力测试数据及其适用边界，基于同一来源的二次整理 — https://www.ithome.com/1/020/615.htm 【7】编辑注：待解问题清单、内部实例与 dsh-superagent-prototype 原型性质，基于同一来源的二次整理 — https://www.ithome.com/1/020/615.htm
