一切皆插件:DeepSeek Super Agent 架构拆解

154 万日活、3.5 万个第三方插件。难的不是让 Agent 会干活，是让它别把活干坏。

引子

11 月 5 日晚上，DeepSeek Harness 团队晒了一组数字：官方 API 日活 154 万，第三方插件 3.5 万个。

第二天，一个插件作者在社区里吐槽：Harness 更新一次，我的插件挂一次。

两句话放在一起看，才是这个生态真实的温度。

01｜Router 不是更大的模型，是调度层

10 月 31 日深夜，团队发了《Super-agent 设计探索：迈向更自主的 Agent 系统》，在 GitHub 上以 MIT 协议开源。文里给了四个词：连续、高效、主动、持久。

落到架构上其实只有三样东西：一个常驻 Router、多个独立 Worker、一套插件运行时。

Router 不负责"更聪明"，它负责"不乱"。所有入口——群聊里 @ 一下、GitHub 的 PR、工单系统、本地终端——先到它这里，由它判断这活该谁干、干完怎么汇报。Worker 才是真正动手的那个，每个带着自己的上下文。

关键在"独立"两个字。做代码的 Worker 不该被周报的措辞带偏，查资料的 Worker 也不该继承上一轮的错误结论。上下文隔离，本质上是故障隔离。

图 1｜Router、Worker 与插件运行时

02｜连续：会话不死，才有复利

单 Session 常驻，是这套架构里最不像技术、却最难做的一条。

传统聊天是一次性的：关掉窗口，状态清零。Super Agent 要的是反过来——会话活着，任务队列、未完成项、上次的决策都还留着。官方举的例子很具体：同一个开发任务，Agent 在群里听到需求，自己去 GitHub 提 PR，再把结果回到群里。

但窗口就那么大。所以状态必须分三层：窗口里放目标、当前步骤、最近结论；会话里放任务队列和交接说明；再往外是长期存储，放偏好、产出、历史任务和检索索引。

写进去容易，取回来难。取不回来的记忆等于没发生——这是所有长期在线的 Agent 最后都会撞上的墙。

图 2｜三层状态：窗口、会话、长期存储

03｜一句话，怎么变成一次插件调用

插件是这个生态的毛细血管。官方显然没打算自己写完所有能力，于是有了 3.5 万个第三方插件。

一次调用要过六道关：意图进来、能力匹配、权限校验、沙箱执行、结果校验、记录回放。

最容易被低估的是第二道。3.5 万个插件里选错一个，后面五道全白做——权限再严，也只是让错误发生得更规范。

所以插件不能只声明"我能干什么"，还得写清"我在什么条件下不该被调用"。能力声明里缺了边界，匹配就会退化成猜。

图 3｜一次插件调用的六个阶段

04｜3.5 万个插件，不可能人人过审

插件市场只解决"找得到"，不解决"敢不敢用"。

现实的做法只能是分级。官方插件随版本走，拿全量能力，出问题官方兜底；认证插件由合作厂商提供，声明式权限加人工审核，出问题降级处理；社区插件默认进沙箱，自动扫描，出事一键卸载。

分级的本质不是信任开发者，是控制爆炸半径。

一个插件能读文件、能发消息、能调 API，它就是一段有权限的代码。审核要回答的不是"这个作者靠不靠谱"，而是"它出错的时候，损失停在哪一层"。

图 4｜插件分级：官方、认证、社区

05｜版本兼容：最贵的坑不在代码里

"更新一次挂一次"这句吐槽，指向的是契约，不是 bug。

插件和 Harness 之间有一份隐式合同：输入什么、输出什么、什么时候回调、失败了怎么报。合同一变，插件就挂，哪怕它一行代码都没改。

兼容性只有三种状态：向后兼容，旧调用照跑；破坏性变更，升主版本并写迁移说明；还有最要命的静默漂移——版本号没变，行为变了。第三种让插件作者根本没法防。

工程上的解法不复杂：语义化版本、契约测试、兼容矩阵、灰度 5% 只看失败率、一条命令回滚。难的不是这些手段，是愿不愿意为了别人的插件，放慢自己的发布节奏。

生态的信任是这么攒出来的：改接口，提前两周说；破兼容，写清楚怎么迁。做不到这两条，3.5 万个插件就是 3.5 万份负债。

图 5｜发布流水线与三种兼容状态

写在最后

Super Agent 这轮竞争，表面看是模型能力，实际拼的是运行时。

谁能让会话活得更久，谁能让插件接得更稳，谁能让一次错误只错在一个格子里。

模型可以换，插件可以重写，真正难补的是那层秩序。所以看一个 Agent 架构好不好，别只看它演示时多能干——看它更新那天，生态里有多少人失眠。

创作不易，如果这篇文章对你有启发，欢迎点个"关注"，"星标"，一起交流AI行业动态和技术。