11 月 1 日前后，DeepSeek 的 Harness 团队在官方公众号发了一篇技术长文《Super-agent 设计探索：迈向更自主的 Agent 系统》，提出一套叫 Super-agent 的智能体架构。11 月 2 日，科创板日报、央广网财经、36 氪等陆续跟进报道，行业讨论迅速升温。
这件事值得写，不是因为又出了一个新名词，而是因为它第一次把问题指向了产品的基本单位：如果 Agent 不再以「一次会话」为单位，那聊天窗口、新建对话、手动切上下文这套交互方式，可能整体作废。
事实梳理：一篇文章说了什么
先把可核实的内容列清楚。按媒体报道与文章转述，DeepSeek 的核心判断是：模型能力提升催生了个人助手（Personal Agent）这类新形态，但现有主流 Agent 设计撑不住多任务与团队协作，多任务的上限取决于人的注意力，而不是模型的能力。
给出的解法是三个词：双层架构、事件驱动、存算分离。系统在底层接管会话管理与上下文同步，人则从具体执行细节上移到「决策与验收」。DeepSeek 把这套形态和架构统称为 Super-agent，并称基于该思路构建的内部实例已经在持续运行。
几个被反复引用的细节：团队成员在群聊里反馈软件问题时，即使没有人专门点名，系统也能自主识别缺陷、在后台复现问题并寻找修复方案。这句话信息量很大——它描述的已经不是「你问我答」，而是「常驻观察 + 自主立项」。
双层架构：Router 常驻，Worker 隔离
结构本身不复杂。一个长期在线的 Router 负责承接人的交互、理解需求、拆解并分派任务，它不亲自干活；具体任务交给 Worker，每个 Worker 有独立上下文和独立运行环境，干完把结果汇报回去。
关键在于「隔离」这两个字。过去的做法是一个会话干到底，聊代码聊到一半想让它回封邮件，只能新开一个窗口，回来再重新交代背景——上下文互相污染，人的注意力被消耗在搬运信息上。Worker 隔离之后，多个任务并行互不干扰，执行细节留在 Worker 那边，只有结果汇总到 Router。
这也是它和 Anthropic 动态工作流 最不一样的地方。后者解决的是「谁来决定怎么编排」——让模型自己写调度程序、一次拉起上千个子智能体；DeepSeek 这套解决的是「人和系统怎么长期相处」——Router 是一个持续存在几个月的「主脑」，记得之前发生过什么，也知道现在有哪些事在进行。前者是编排权的转移，后者是会话这个单位的取消。
和 OpenClaw 多 Agent 配置 的区别也在这里：那是工程层面的父子代理与结果聚合，需要人先把拓扑画出来；这一套是产品层面的默认形态，用户只需要说话。
事件驱动与存算分离：脑在云、手在本地
两个配套设计，决定了这套东西能不能真跑起来。
事件驱动 + 全双工：任务在后台跑，前台仍然可以秒回新消息，用的是异步的 ReAct 循环。人的工作本来就不是一问一答，交代完一件事顺手交代第二件，是最自然的节奏。这一条如果做不到，「多任务」就只是名义上的。
存算分离：计算、状态、环境三者拆开。Agent 的「脑」在云端，但「手」可以伸到用户自己的机器上——在端侧部署一个不保存状态的轻量守护进程，云端按需读取本地环境与文件。行业里把这个思路叫 BYOM（Bring Your Own Machine）。
这一步是必须的。只跑在云端沙箱里的 Agent，遇到公司内网代码、本地那份没上云的表格，立刻变瞎。但它的代价也很直接：每台电脑上都多了一个接受云端指令的入口。权限怎么继承、审计怎么留、人离职了怎么回收，这些都得重做一遍。
为什么是现在：注意力成了瓶颈
过去两年 Agent 产品的竞争焦点是模型能力，现在这个瓶颈正在往产品侧转移。有媒体在报道里引用了一个说法：人能同时跟进的活跃会话大概是 3 到 5 个（该说法未标注出处，姑且听之）。不管具体数字是多少，体感是对的——用 AI 最累的部分不是等它回答，是记住「我在哪个窗口交代过什么」。
IDC 中国研究经理孙振亚在接受科创板日报采访时说得很直白：当前智能体的交互逻辑大多还沿用生成式 AI 的思路，让用户自己管理对话和 Session；更好的方案是以任务为中心做路由调度，或者以任务管理为中心，帮用户管并发任务和定时触发任务。他认为 DeepSeek 的 Harness 主要通过 router 路由来解决这个问题，方向与「管家式智能体」一致。
他同时点出了更硬的差距：不在能力，在生态。国内大量服务、数据和交易仍封闭在各自的平台里，单靠技术手段绕不过去。他建议行业建立面向智能体的开放标准——身份怎么标识、能调用哪些服务、交易收益怎么分配、出了问题谁负责。这四条其实就是 Buddy One 那类底座型产品 正在碰的同一堵墙。
影响分析：三层各有各的麻烦
- 对开发者：应用的基本单位从「会话」变成「任务」。这意味着状态要外置、任务要能断点续跑、进度要能被查询。以前一个 chat 接口能凑合，现在得先想清楚任务表长什么样。参考 长时任务设计 里的检查点与恢复思路。
- 对产品团队：入口的价值继续下降，记忆与调度的价值上升。用户不再关心你在哪个 App 里，只关心「我说一句，事情有没有在推进」。这对习惯用界面功能做差异化的团队不是好消息。
- 对企业：最大的变化是验收。人从执行里退出来之后，剩下的动作只有两个——下达目标和验收结果。所以「什么算完成」必须提前写成判据，否则自主性越强，返工越贵。
三盆冷水
第一，这是一篇理念文章。没有开源代码、没有基准测试、没有定价、没有失败率数据。文章描述的能力，与工程上稳定可用的能力之间，通常隔着几个季度的脏活。
第二，「别人早半年就做了」这类叙事要打折看。36 氪的报道梳理了 AFK AI（产品名 Comma）的时间线：4 月 13 日内部定下「一个团队，一个对话」，4 月 28 日 Bridge 发布，5 月 20 日确立团队级单 Session，6 月 3 日上线任务委派；并提到 Anthropic 在 6 月 23 日于 Slack 推出类似理念的 Claude Tag。这些是媒体访谈与公开材料的整理，可以当参考，但「谁先谁后」对使用者来说意义有限——决定你要不要跟进的是它能不能解决你的问题，不是发布顺序。
第三，人是瓶颈这件事，换架构解决不了一半。Router 帮你管住了会话，管不住「你到底想要什么」。很多返工不是因为 Agent 记不住，而是因为目标本身没说清。
老达点评
这套架构图不新鲜，懂行的人看一眼就能画出来。真正难的是三件事，文章里都没细说。
一是「完成」的判据。Router 分派任务很容易，难的是它怎么知道 Worker 干完了、干对了。没有判据的自主系统，只会更快地生产错误结果。这一点上，评测与回归 那套方法得往前挪，挪到任务定义阶段。
二是 Router 是新的单点。它的上下文越长越容易脏。以前改错一条对话成本很低，现在要改的是「一个人的长期记忆」——错了以后怎么定位、怎么回滚、怎么防止错误被反复引用，这是 记忆污染治理 要回答的问题，而多数团队还没开始做。
三是存算分离的安全账。端侧那个无状态守护进程，本质是把本地机器的执行权有条件地让渡给云端。权限粒度、审计留痕、离职回收，一条都不能省。这里可以借用 上下文管理 的最小必要原则：能少给就少给，能只读就别给写。
如果你现在就想动手，不用等这套架构落地，三件事今天就能做：把任务状态从会话里拿出来，落到一张任务表上；给每个任务写一句「怎样算完成」；把所有不可逆动作（发送、付款、删除、对外承诺）前面固定一个人工确认点。这三件事做完，你已经有半个 Router 了。
总结
DeepSeek 这篇文章的价值，是把一个大家都有体感但说不清的问题讲清楚了：限制 Agent 的不是模型智商，是人同时能照看几件事。双层架构、事件驱动、存算分离，都是围绕这个约束做的工程回应。
但它目前仍是一份设计探索，不是可采购的产品。对开发者来说，值得抄的是思路——任务为中心、状态外置、执行隔离；不值得抄的是把它当成「下一代形态已经到来」的结论。真正的分水岭不在架构发布那天，而在第一个「没人点名也能干对」的案例被稳定复现的那天。
