DeepSeek Proposes Super-agent Concept: Managing Sessions with a Two-Layer Router and Worker Architecture

新增众测推广文案 新增众测推广文案end 添加App专享导流

前两天 DeepSeek 发了篇文章，介绍了一个名为 Super-agent 的设想。

Super 不 Super 咱不晓得，但里面的干货实在太干了，工程设计讲得那叫一个细，给大伙儿整得有点云里雾里的。

但其实这事儿也不复杂，只要结合着最近大火的 Muse、Grok Bot 一起看，你就会发现，其实 DeepSeek 是直接把 Personal Agent 这事儿给搬到台面上说了。

他们提出，要想搞出好使的 Personal Agent，起码得满足 4 个特征：连续、高效、主动、持久。

这里面没一个是善茬儿。

不说别的，就眼下大伙儿一个任务开一堆对话的用法，那就高效不到哪儿去。

专业的说法里，人管这些对话叫 Session，一条 Session 就是一个独立的小环境，里面存着你跟 AI 的聊天记录、工具、环境配置等一堆东西。

而现在基本所有的 Agent，走的都是这种 Session 模式，他们之间可不互通。

一般是先开个对话框，用来查资料；接着再开一个头脑风暴，梳理思路；然后再开一个，写方案；最后再开一个，才开始正式写代码敲项目，后面跟着的其实还有一个核查检验的。。。

这么设计乍一瞅还挺符合直觉，每条 Session 各自独立，代码这边的结果，方便反馈到方案那儿迭代，反过来也一样，干起活来不容易串台。

但别忘了，注意力这块儿，人是很拉胯的，项目架构清晰点咱还能凑合，要是整个多人配合的大活儿，那外面再接俩脑机估计都够呛。

根据 DeepSeek 的估算，咱人类跟 AI 交互，能同时跟进 3 到 5 个 Session 就不错了，多了根本 hold 不住的。

在这种以 Session 为核心的架构下，人就已经不是人了，纯纯一上下文搬运器罢了。

关键你还不能把任务都塞到一个 Session 里，这么整且不说上下文爆炸，任务本身都得慢悠悠的挨个排队，而且细节一多，模型还容易精神分裂。。。

那咋整呢？

DeepSeek 就出马了，人的注意力拉胯，AI 不拉啊，Session 这玩意儿说白了就不该人来操心。

他们索性直接把 Session 从前台隐藏掉，搭了一套 Router + Worker 的双层架构。

简单点说，就是在这些干活儿的 Agent 上面再加一个 Router 路由层，作为大管家，统一派活。

你这边提个需求，Router 接到后就会根据情况，分给适合的 Worker 干，再提，就再分。

虽然后台里面跑着一堆 Worker，但在前台你面对的，始终就只有一个 Agent，完全没有拆分 Session 的冗杂感。

听着有点像 Agent 集群，但其实完全是两码事儿。

Agent 集群是把一件事儿拆给不同的子 Agent，配合着干，干完原地解散。

而 Super-agent 是组了个小团队，它不为某个任务而生，而是根据你的需求持续推进一堆乱七八糟的事儿，即使某个活儿干完了，团队也不会彻底解散。

除了架构，眼下的 Agent 被吐槽的还有 “ 被动 ” 的特性。

因为甭管接的啥模型，骨子里它们还是响应式的大号 ChatBot，你戳一下它走一步，不说话它就装死。

但按咱理想的情况，还是希望 Agent 能主动一些的。

毕竟真实的工作环境里，不可能啥都写成规范的书面报告，很多需求和反馈其实就藏在大伙儿水群的聊天记录里。

如果 Agent 能从这些废话文学中提炼出真实的任务需求，那才是盖了帽了。

所以 DeepSeek 就这么设计了，不止群聊，邮件、日历、GitHub 的 issue 评论等等都能接入。

他们把这些外部消息统称为 Trigger，也就是扳机，能够触发一些事件。

那问题来了，群聊一天少说也能水个几百上千条消息，咋识别哪些是 Trigger，哪些是废话呢？

诶，这就得靠 Super-agent 的双重过滤机制了。

连上 IM 后，消息要送到 Agent 那儿，都得经过两层过滤，一层 Fast Path，一层 Slow Path。

Fast Path 得快，所以用的写死的程序，比如消息来源是不是白名单，是唠闲嗑群的还是讲正事儿的群，直接过一遍，就能滤掉一大堆。

到了 Slow Path 这儿就剩筛出来的候选消息了，这时候再交给大模型判断，有没有价值，能不能提炼成需求。

这就已经相当省 token 了，但为了进一步提高性价比，DeepSeek 还设计了一套订阅机制。

比如某个 Worker 之前已经接手了一个 GitHub 的 PR 需求，后续这个 PR 下面的评论和反馈，就可以直接推送给它，不用每次都绕回 Router 重新分派，专事儿专办了属于是。

而且怕这信息量太大，DeepSeek 借鉴计算机的缓存管理思路，用上了 Inline & Spill。

凡是近期可能用到的，就直接 Inline，放到上下文里；暂时没啥用的历史信息，就挂在外面，Spill 出去，只留个目录索引，需要的时候再去翻找。

这就是经典的链式召回，相当于给 Agent 配了个档案室，甭管多少东西，目录一压就都能装下。

当然，要说整套系统最丝滑的，可能还是它的任务设计。

整体就主打一个以人为主。

为了跟上面的筛选机制搭配，人用了套相当激进的 “ 投机执行 ” 思想。

甭管你人类讨论到哪儿了，我 Agent 只要得到消息，就先搁后台尝试着，能行再告诉你，不行就无事发生，免得你后知后觉再让我从头干，浪费等待的时间。

瞧瞧这眼力见，贴心的秘书根本不用老板张嘴好吧。

而且这任务在后台执行也是有讲究的。

传统的 ReAct Loop 方案里，任务是同步执行的，如果一个 Agent 调用了工具，那它就会一直卡那儿，直到这工具返回执行结果，才能听见用户的下一条消息。

但在 Super-agent 的设想里，给改成了异步执行，把前台聊天和后台执行彻底解耦，你可以一边让它跑代码，一边安排别的活儿，不用傻愣着排队。

Agent 这玩意儿好用就好用在能直接改本地的东西，但这也意味着你电脑一关，它就直接下班了。

这显然不符合 Super-agent 的设想，至少它也得像那些 Personal Agent 一样，给咱 24 小时待命才行。

那咋整呢？诶，可能鼓捣过 Agent 的差友已经想到了，就是云端化。

按 DeepSeek 的思路，Agent 这套东西可以分成三个部分。负责思考的脑子、保存上下文的状态、以及挂载各种依赖和工具的执行环境。

这三个里面，其实前两个都能放云端，最后那个环境虽然不能搬上去，但 DeepSeek 给设计了个叫 “ Daemon ” 的轻量级小玩意儿，放本地就专门负责执行这一件事儿。

这么一来，就给搬到云上去，24 小时随时待机了。

当然，考虑到五花八门的设备兼容问题，人还特意留了条看门狗，没错，就叫 Watchdog，在后台来回巡检。

负责看 Worker 有没有正常干活儿，或者有没有哪儿的进程卡住了，防止陷入死循环。

这么一套搞下来，这 Super-agent 确实就足够 super 了。

当然，光画大饼可不是 DeepSeek 的风格，为了证明这玩意儿可行，他们顺手就在 GitHub 上开源了一个实验原型。

翻看完你就能感觉到，这东西不是一拍脑袋想出来的，很多东西他们内部早就尝试过，甚至已经在用了。

好使的就全写出来，还有一些更棘手的，像跨 Session 的记忆管理、权限边界、还有安全性，这些其实他们自己也拿不定主意，只能说是给大伙儿一个思路，慢慢摸索了。

但甭管怎么说，这么一层层拆解完，大伙儿应该也能看明白 Personal Agent 是为啥香，怎么香的了。

它不像训练模型那么力大砖飞，底子里还得各种精密的工程手段来配合。

DeepSeek 这回干的，就是把思路摆到台面上。

这些问题肯定不光他们碰到了，瞅瞅官方社区就能看见，不止大厂，很多个人开发者其实也做过类似的尝试。

配合上 AI 的技术平权，说白了，这好使的 Agent 也不见得是大厂先搓出来的。

指不定哪天，社区里就能捣鼓出真正的 Super-agent，让咱手里的大肥鱼活成真正的大肥鱼。

不再寄生在百万上下文的对话框里，而是有自己的记忆、工作和节奏，陪你你走完完整的一生。。。article_adlist[

责任编辑：若风

文章内容举报 ]article_adlist 声明：新浪网独家稿件，未经授权禁止转载。 tech_web_article_v2015_block_bottom 非定向300*250按钮 17/09 wenjing begin

非定向300*250按钮 end