五家的 Agent 越来越像：DeepSeek 是第五个

10 月 31 日，DeepSeek 发了一篇 Super-agent 设计长文。同一条赛道上，这已经是 71 天里的第五份答卷。把五份并排放，会发现一件比“谁更强”更值得说的事：骨架已经收敛了。

时间线与产品能力取自各家官方发布页与公开报道，截至 2026-10-31。DeepSeek 的实验数据引自其公开长文第 7 节，数字未做二次加工；产品侧描述以官方页面为准，未验证的功能不予采信。

同一道题，五份答卷

10 月 31 日，DeepSeek 产品部与 Harness 团队发了一篇长文，《Super-agent 设计探索》。开头先压预期：这是面向工程实践的架构思路探讨，不是产品介绍。文末又补一句，相关实现只是验证技术路线的原型，不是正式产品。

往回倒 71 天，这条赛道上已经站了四家。8 月 11 日 Grok Bot 进入测试，9 月 8 日 Meta 的 Muse 上线，9 月 29 日 OpenAI 的 Dots 发布，10 月 21 日 Anthropic 的 Claude Duet 开放研究预览。DeepSeek 是第五个，也是唯一一个用一篇长文、而不是一个产品来表态的。

把这五份放在一起，第一反应不是“谁更强”，而是“怎么长得这么像”。四家产品对外披露的能力项几乎可以逐条对齐；DeepSeek 那篇长文里画的架构图，也能和 Duet 的产品说明一一映射过去。

这种相似不是抄来的。它来自同一组约束：环境事件是持续到达的，人的注意力是稀缺的中断源，上下文窗口是有限的缓存。约束一样，就导出相近的结构，这在工程史上反复发生过。当年从单机进程到多线程、从单体到服务网格，走的也是这条路。

指标	数值	说明
71 天	四家入场	从 Grok Bot 到 Claude Duet
5 份	同一道题	含 DeepSeek 的设计长文
6,000+	连接器	Duet 官方口径可调用数量
40 条/分	Router 压测	DeepSeek 单次实验的触发速率上限

五家的入场顺序

五家主动式 Agent 的发布顺序横向条形图，从 8 月 11 日 Grok Bot 到 10 月 31 日 DeepSeek Super-agent

条形长度按距 8 月 1 日的天数计，标签为实际发布日。四家用 71 天完成入场，节奏是 28 天、21 天、22 天；DeepSeek 在第 81 天发出一篇长文。

骨架确实一样，五个模块对得上

Duet 和 Super-agent 分处产品与原型两端，但只要把两边的公开描述并排放，会发现它们回答的是同一串问题，而且答案高度重合。

Duet 的路子是：云端独立虚拟机上跑一个常驻 Agent，自带浏览器，继承你原有账户里的记忆、技能和授权应用，每天早上推一份晨报，白天持续监控，只在需要你拍板时出声，发消息、付款、签字、删除这类动作一律先给审批。

Super-agent 的路子是：常驻的 Router 会话负责承接人类交互与全局记忆，上下文隔离的 Worker 各自订阅事件流并行执行，执行环境留在用户原来的机器上，端侧只放一个不保存状态的 daemon。

两套话术背后，是同一张图。

两端的能力映射

问题	Claude Duet	DeepSeek Super-agent
常驻在哪	云端独立虚拟机 + 自带浏览器	云端无状态容器，执行环境留在原地
记忆从哪来	继承 Claude 账户的记忆与技能	常驻 Router 会话 + 引用图链式召回
被什么驱动	晨报 + 全天后台监控	环境事件 Trigger + 两级过滤
何时打断人	只在需要决策时出声	有价值才交付，否则保持安静
谁能动手	发消息、付款、签字、删除均需批准	未展开，归入开放问题
凭证怎么管	由 Managed Agents 托管，模型不见密码	列为 8.4 开放问题

左列为共同问题，中右两列为两家各自的答案。前四项同构，第五项开始分叉。

六行里前四行几乎同构，连措辞都能对上。“只在需要你拍板时出声”和“没有价值就保持安静”，说的是同一件事；一个用了晨报加监控，一个用了事件驱动加两级过滤，抽象掉实现细节也是同一件事。

后两行开始分叉，而且分叉的位置很关键：一个把它写成了上线的前提，另一个把它写进了待解决问题清单。这个差别比架构图上的任何一处都更值得说。

没收敛的两件事之一：什么算急

主动式 Agent 真正难的不是干活，是决定“现在要不要找你”。这件事做不对，产品就退化成一天推八十条通知的看板，用户三天就关掉。

Anthropic 的处理是把判断实体化：一个专门的分类器加一套安全系统提示词，逐条检查消息；模型侧则靠 Opus 5.5 的判断力。他们在发布里引了内部一句话，说这是他们第一个“有足够判断力、能以合适方式主动做事”的模型。同时也很坦白地写了限制：可能误读对话线索，可能把紧急程度判断错。

DeepSeek 走的是另一条路：把判断拆成两层。程序层用确定性规则先滤掉大部分噪音，剩下交模型判语义；确定归属的后续事件由程序直接发往对应的 Worker，不再经过中心节点。它甚至做了一组压测，证明单个 Router 会话扛得住——触发速率从每分钟 1 条升到 40 条，单次请求耗时只从 2.5 秒涨到 3.9 秒，摊到每个决定上是 6.4 秒降到 1.6 秒。

但真正值得看的是另一组数据。

5 次运行里，模型主动把活分出去了几次

三种方案在五次运行中主动派发子任务的次数对比，中性提示为零次，提示要求委派为四次，双层架构为五次

DeepSeek 公开的消融实验原始结果。同一场景、同一个模型，只换提示词，5 次运行里一次都没主动派活；换成系统层的订阅分派，不需要模型自觉。编码工作被替换成只消耗时间的工具，所以衡量的是调度能力。

左侧那根柱子是 0。中性提示下，模型在 5 次运行里一次都没有调用子 Agent，所有活都在主会话里干，不断被新消息打断，p95 完成时间 29.5 分钟。改成明确要求优先委派之后，4 次派了，但还有 1 次它判断“这活很小”又自己干了，形成长尾。

这一组数字真正说清的事是：分工不是意愿问题，是机制问题。你可以在提示词里写一百遍“请优先委派”，它每次都会重新判断一遍；而如果归属关系落在库里、事件直接路由过去，就不需要它判断。

我在自己的体系里踩过同一个坑。曾经把“什么时候该派给子 Agent”写成提示词规则，结果它每次都觉得“这活不大，我自己来”，然后在主循环里被后续事件打断。后来改成任务归属落库、新事件按订阅直接进对应执行单元，这个问题才消失——不是模型变自觉了，是它不再有机会偷懒。

要点：一个能干活的 Agent，和一个能自己组织工作的系统，中间隔的不是模型能力，是机制。模型再强，也不该被要求每一轮都重新回答“这件事该谁做”。

没收敛的两件事之二：谁有权按下确认

第二处是安全，也是我更在意的。

Anthropic 把安全写在了功能前面。凭据由 Managed Agents 托管，模型从头到尾看不到密码和登录令牌；发消息、动钱、签文件、删数据一律弹审批；prompt injection 的防御来自他们做浏览器操作时积累的那套研究；上线前过了内部红队、一家外部渗透测试公司，再加公开漏洞赏金。分类器的职责也写得很具体：检查每条消息里有没有信用卡号这类高敏信息被带出来。

DeepSeek 的处理更诚实，也更刺眼。它在 8.4 节自己写下了这两句：一旦云端的 Agent Loop 遭遇服务端入侵或提示词注入而被攻破，其连接的全部端侧设备都面临被控制的潜在风险；即使云端没被攻破，只要端侧环境中的凭据能够进入模型上下文，正常执行过程中同样存在凭据泄露的风险。

写得很准。然后它把这一段归进了“开放问题”。

注意：我不认为这是开放问题，这是这套形态唯一的否决项。BYOM 把执行权铺到用户每一台机器上，攻击面随设备数量线性放大，而整个设计里没有一处是默认安全的——它的安全性全部押在“云端那个 loop 不被攻破”这一件事上。押注型的架构可以拿来做原型，不能拿来做产品。

这不是说 DeepSeek 想得少。恰恰相反，它把风险描述得比谁都清楚——清楚到能直接当作攻击方的路线图。问题在于它选择了先证明调度可行，把信任问题留到下一阶段。这是个合理的工程排序，但它决定了两篇文章的读者不是同一批人。

交付形态的差别，比架构差别更大

四家交出来的是产品：有候补名单、限定国家、限定订阅档位、真实用户在用、误判有真实代价。Duet 的公开演示里，那位咖啡品牌老板要为一个 640 美元的卫生许可在支付链接上点批准，要点头一封录用邮件的措辞，要决定要不要试两周包邮。这些动作做错了，损失是真金白银和真人员工。

DeepSeek 交出来的是原型加一篇长文。它的验证范围写得同样清楚，藏在实验小节的小字里：编码工作用一个只消耗时间的工具代替，因此实验衡量的是系统的调度与协作能力，而非对单个任务的执行能力。

这句话很关键。它意味着那组 12.4 分钟的中位数、15.7 分钟的 p95，证明的是“这套调度比单会话调度得好”，而不是“这套东西能把活干对”。前者是系统问题，后者是模型问题，两者不该混为一谈。

所以这两件事的性质不同：一个在验证产品能不能交付，一个在验证架构成不成立。拿长文的深度去要求产品，或者拿产品的完成度去要求原型，都是错位的比较。

顺带说一个容易被忽略的细节。那篇长文的成本数字并不好看：同样一次实验，完整方案的读缓存 token 是 2323 万；去掉订阅直通后涨到 3177 万，增加 37%，而任务完成时间几乎没变。多会话各自维护上下文，这是纯粹的增量开销。文章自己也承认，这是用更多 token 换更短更稳的完成时间。这笔账在团队规模内可以不算，规模化之后会是主要成本项。

所以差别落在哪

我同意一个判断：这五家的实现，本质上是差不多的。

但这个“差不多”不是贬义。骨架收敛是必然结果——约束相同，最优结构就那么几个。真正的问题是，当骨架不再构成差异，选型该看什么。

我看两处，都是可校准性。

第一处是判据能不能被你调。什么叫急、什么值得打断你、哪些事它自己决定就好——这些不该是模型出厂时的一次性判断，应该是你能看见、能改、改完立刻生效的配置。DeepSeek 那套两级过滤里，语义层被明确设计成“面向人类的自然语言扩展点”，这一点比它的架构图更值得抄。

第二处是权限能不能被你收。哪些动作必须过你的手，是产品设计问题，不是模型能力问题。把审批门做在动作层，比写在提示词里可靠得多——同一个道理，分工不该靠自觉，放权也不该。

至于 DeepSeek 这篇长文真正的价值，我认为不在它提出了什么。它提出了五个模块，每一个都能在操作系统教科书里找到出处，作者自己也这么说。它的价值在于把“人的注意力是瓶颈”这句体感，写成了一条可测量的工程约束：一个人同时只能跟进 3 到 5 个活跃会话，所以多任务的上限不在模型，在人。然后用一组能复现的实验补了一刀：靠提示词管不住分工。

这两件事，比任何一张架构图都有用。