时代互联资讯中心
当下的智能体，到底卡在哪
DeepSeek 团队近期推出了一种全新的 Agent 架构——Super-agent，意图正面攻克当前主流智能体在多任务处理上的固有短板。抛开原文里不少晦涩术语，我们换个更接地气的方式，把它解决的是什么、又是怎么做到的，一条条捋清楚。
先从现在的 Agent 是怎么干活的讲起。如今无论是 Claude Code、Codex 还是 DeepSeek Harness，绝大多数主流智能体都以「会话」作为基本工作单位。用户开一个会话、布置一个任务，智能体便在这个会话里「思考—执行—观察—再思考」，一步步推进直到收尾。这套循环有个学名，叫 ReAct Loop。
单看一个任务时，这种模式确实顺手，所以一直流行至今。但真正让它显出毛病的，往往是同时处理好几件事的时候。
你想象一下：一边开着会话修 Bug，一边开着会话写文档，另一边还在跑测试，这时同事随口来一句「这需求改一下」，你又得另开一个会话。问题是，这些会话彼此完全不知道对方在做什么，跨任务的信息只能靠人脑记住、再手动搬来搬去。不知不觉中，人就成了多个 AI 之间传声筒。
DeepSeek 官方点破了要害：单任务的能力上限取决于模型本身，而多任务的上限却取决于人的注意力。.observe下来，一个人一般只能同时跟进三五活跃会话。AI 越来越能干，人却越来越累。
于是有人冒出个念头：那给 Agent 接上飞书、GitHub，让它自己进群看消息、接任务不就行了？借助 CLI、MCP 确实能做到，但只要底层仍是单会话结构，很快会撞上三道坎。第一，执行耗时命令时整个循环会卡死，必须等命令跑完才能处理新消息；第二，多个需求塞进同一会话，上下文日益混乱；第三，Agent 跑在本地电脑上，电脑一休眠它直接罢工。
拿第一点举例。曾让人让 DeepSeek Harness 跑一个模拟 45 秒的构建命令，期间顺便问了句周会时间，结果这个问题直接被丢进排队区，一直拖到构建结束才等到回答，前前后后耗了近半分钟。也正是这次体验让人意识到，把 Agent 从「单次会话」里解绑，让它能跨会话记忆上下文、同时推进多件事且互不干扰，才是真正的方向。Super-agent 就在这个逻辑下诞生了。
Super-agent 是什么
如果传统 Agent 是一次只干一件事的外包工，那 Super-agent 更像一支配合默契的团队——团队内部或许人多事杂，但对外你只要对接一个入口就够了。
DeepSeek 为它归纳了四个基础特征。连续性：无论你在飞书群还是 GitHub 上聊，前面说的方案 A、后来改成方案 B，它都能跟上；高效性：它能并行推进好几件事，前一件没干完也能接着接指令；主动性：它会自己盯住群消息和工单，该出手时出手，不该管的保持安静；持久性：它始终在线，出问题还能自恢复。
官方给出了两个内部真实运行的案例。其一是一个需求跨平台推进的过程：群里有用户希望正文、代码、终端字体能各自独立配置，维护者 @ 了一下 Super-agent，它很快提交了 PR；随后用户追问字号，维护者与设计师又在 GitHub 上掰扯了几轮，它在群聊与 GitHub 之间来回穿梭，一路把需求推到了合并。其二更添看点：某用户群里有人随口抱怨桌面端窗口没聚焦时、点击会被误判成双击，每天要误触几十次。当时谁都没 @ 它，它却自行判定这是一处具体缺陷，在后台复现、定位根因，直接把修复 PR 和前后对比截图甩了出来。换句话说，不用你去催，该干的活它自己就扛了。
看到这里，大概率会有人追问：它跟 Agent Team 智能体团队到底差在哪？听起来不也是一个「领头羊」带着一群小弟干活吗？区别其实很明显。Agent Team 解决的是「一个大任务怎么拆」，那个领头者如同亲自下场的技术组长，得扎进细节、频繁协调，脑力消耗极大；Super-agent 解决的是「多个任务怎么分」，领头者只管这条消息派给谁、这两件事是否有关联，单个任务内部怎么拆，它并不插手。
再拿它和 Personal Agent 比，可以这么理解：Personal Agent 是一种产品形态，而 Super-agent 是撑起这类产品的底层架构。一个是壳，一个是骨。
这套架构怎么转起来
DeepSeek 把整套架构拆成五个模块，类比进现实里的项目团队，就非常好懂了。
双层架构：项目经理与工程师
假设你手头同时压着 20 件事。全交给一个人，信息虽不会断，但他只能依次排队、越办越乱；要是每件事都派个新人，大家能并行开工，却又互不通气，最后还得一个个跑来向你汇报。既要信息连贯，又要干得飞快，本质上就是连续性与吞吐量的权衡。现实团队早就给了答案——招一个项目经理，再配几名工程师。
Super-agent 同样分上下两层。上层的 Router 层相当于项目经理，常驻在线，所有渠道的消息先汇聚到这儿，由它掌握全局、对外沟通、给工程师派活；下层的 Worker 层相当于工程师，每个 Worker 守着独立的上下文，专注把一件事做好，完成后向项目经理汇报，再由项目经理统一回话。这样一来，你面对的始终是同一个对接人，团队内部怎么分工，你压根不必关心。
DeepSeek 认为，让用户手动去管会话，很大程度是从底层大模型 API 继承下来的设计惯性——会话本该是系统内部的实现细节，不该变成用户的负担。这个「项目经理」还有个别致之处：不亲自下场干活。DeepSeek 明确要求 Router 层只负责沟通与派活，甚至可以不给它配终端工具，就像不给项目经理发开发机，免得他一时手痒写起代码、忘了回消息。由于只做轻量判断，Router 用轻量模型就够了，真正决定交付质量的 Worker 才需要配最狠的模型——好钢确实要用在刀刃上。
那么问题来了：所有消息都从项目经理手里过，他会不会被淹没？实践中答案是否定的。因为项目经理在处理上一批消息时，新消息会先攒着，等他忙完再一并查看、统一派活，这就是所谓的批处理。打个比方，就像你开完会出门，一口气回完五条未读。对大模型而言，读 5 条消息和读 1 条消息耗时相差无几，真正慢在「写」，而项目经理每次只需写几句话派活。有意思的是，消息越多，平均下来处理得反而越快。
另外，工程师彼此之间的协调，也不必项目经理操心。Worker 之间一般不直接对话，若两个 Worker 在改同一份 PR，它们会同时收到这份 PR 的新动态，自己就能对齐；任务实在复杂时，Worker 还能再拉几个 Subagent 帮手，相当于工程师自己带了实习生。
事件驱动：不用等老板发话的员工
团队架起来了，可好团队不能老板掉一句才动一下。传统 Agent 是“你一句、它一次”，Super-agent 则是由环境里发生的事来驱动的——群里来了新消息、PR 下冒出一条评论、CI 跑挂了，DeepSeek 把这些统一叫做 Trigger 触发事件。
可一旦让 AI 去盯群消息，你马上会发现，群里的废话实在太多。DeepSeek 用了两级过滤机制：门口放个“门卫”，后面跟个“秘书”。门卫只看消息从哪来——是不是监听的群、发消息的人是否在白名单里，普通代码就能瞬间判定；秘书负责读内容，通过门卫的消息再交给大模型，按提示词里写好的规则判断到底处不处理。比如闲聊群里问“中午去食堂还是点外卖”，门卫直接拦下；用户群里说“新版界面挺清爽”，门卫放行了，但秘书判断无需理会；用户群里反馈「切换会话偶发白屏」，秘书一眼便知这必须管。
这其实就是计算机系统里常说的快慢路径（Fast Path / Slow Path）思想。这种设计对任何拥有用户群的产品都格外贴切——若能接入那样的产品交流群，秘书就能从海量闲聊里筛出真正的缺陷反馈，省得人工一条条去翻。
过滤完消息就该派活，可若每条消息都让项目经理转一手，他迟早被累垮。现实里的团队，一个工单第一次进来时经理分给小王，之后同一工单的消息直接抄送小王就成了。Super-agent 同理：同一份 PR、同一个话题、同一串邮件里的连续消息构成一个 Thread，你可以理解为一个工单；Worker 接手后会“订阅”它，后续新消息由程序直接送达，不再绕回项目经理。
DeepSeek 做过对照：一旦去掉这套直通机制，任务完成速度几乎纹丝不动，但项目经理需要做的决定却多出约三成，token 消耗也涨了近四成。省下来的，全是实打实的成本。
上下文管理：给多少资料合适
活派下去了，一个问题随之而来：该让干活的人看多少资料？给多了，重点被淹没；给少了，又得反复回头追问。DeepSeek 有句话讲得很透：浪费上下文窗口，就是浪费模型智能。
为此他们搬来了编译器里的两个概念。Inline 内联，如同同事转消息时顺手把前后几句和相关工单号一起带上，让你一眼看清来龙去脉；Spill 溢出，如同拿到一份上万字的文档，只丢给你摘要加一句“全文见此处”，真需要时再翻。这个思路抽离到整套系统里，就形成了链式召回（Chain of Recall）：系统为每条消息、每个工单、每个 Worker 都编排了编号，每张“卡片”上只写摘要和关联编号。当你跨平台提起一件旧事，项目经理不必把历史全部背下来，顺着编号一路往下翻便行，宛如 Conway 顺着墙上红线追线索。
另一个概念源于投机执行（Speculative Execution）——CPU 在拿不准某段计算用得上用不上时，先提前算好，用上了是赚、用不上就扔。Super-agent 把它挪到了干活上：收到一封会议邀请，它先在后台核好日程、备齐背景资料、写好回复草稿，你点一下确认便能直接发出去。DeepSeek 在自己的用户群里就配置了一条“静默复现并修复”的规则，曾有一次用户反馈模型输出里的波浪号被渲染成了删除线，群里还在争论该从训练入手、让模型转义，还是去改渲染规则，Super-agent 却已经把修复 PR 交上去了。不过主动从不等于乱来——在开源原型里，没人吩咐的主动工做，必须依赖团队提前写好的规则才能启动，而且默认先进入“观察模式”，只记录自己打算做什么、并不真正动手，等你确认它的判断靠谱了才肯放开。
面向人的交互：像人一样说话
传统 Agent 一动手就听不到消息，根子在于 ReAct Loop 是“半双工”的，好比对讲机，同一时刻只能一方开口。Super-agent 想做的，是把对讲机换成电话，也就是切换到“全双工”。具体手法是把耗时的工具调用改成异步的——命令一启动立刻返回，Agent 照样能陪你闲聊，等命令跑完，结果再作为一条新消息送回来。
这么一改，执行一条耗时命令时，Agent 三秒就能回一句“已启动”，你可以接着让它琢磨周会开场白，它还会不忘提醒你构建仍在进行。等构建落定，会话里蹦出一条“后台任务状态更新”，它会立刻主动跑来汇报。跟前面那种近乎干等的体验相对比，简直是两个世界。
不过，Agent 能边干活边聊天之后，还得讲究在不同渠道里怎么开口。要是把终端里那番长篇的思考过程原样甩进群里，群里的人怕是要炸锅。好在冗长的推理都被关在 Worker 内部，对外发声的始终是项目经理；而且 DeepSeek 还给各渠道立了规矩：飞书里只有在需要你拍板时才发声，单次回复不超过 100 词；到 GitHub、邮件里，则必须把问题背景、改动与验证结果交代清楚。
存算分离与 Watchdog：不下班，也不怕出错
最后要啃的，是电脑一合、Agent 就“下班”的老大难。当下的本地 Agent 把计算、状态（会话记录）、执行环境（代码与工具）三样东西捆在同一台机器上，电脑一休眠，三样一并停摆。
DeepSeek 借用“存算分离”分两步来解绑。第一步，把计算与状态拆开——就像靠谱的团队把工作存进档案室，谁来接班都能接着往下干。Super-agent 把计算放在可随时替换的云端容器里，会话状态则存入数据库，容器一旦损坏，换一个顶上即可，一条记录都不丢。不少开发者把智能体部署到服务器后都深有体会：它不再跟着本地电脑一起休眠，手机、电脑随时能接进来，连常驻运行都不再挑设备。为了让这类常驻智能体7×24小时稳定在线，不少人会直接交给像时代互联这样提供托管与弹性云服务的平台去承载，省心不少。而 Super-agent 又比这再往前迈了一步。
第二步，把计算与执行环境拆开。Agent 上了云，可它要用的代码、密钥、内网服务往往还锁在你的本地机器上，很难整套搬上云端。DeepSeek 的法子是：既然环境搬不动，那就别搬了。大脑留在云端，你的电脑上只装一个极轻量的前台小程序（daemon），它不存任何会话记录，只管按云端发来的指令执行命令、回传结果，犹如一位远程专家在指挥现场助手。DeepSeek 把这套叫作 BYOM（Bring Your Own Machine），也就是带上你自己的机器——哪怕笔记本今天没开机，等它重新上线，云端也会自动把原本该在这台机器上补完的事项安排到位。
Agent 能常驻在线了，可万一它干着干着拐了弯呢？DeepSeek 在主系统之外单独挂了一个 Watchdog（看门狗）会话，相当于值班的主管，会定时巡查。它看的不只是员工在不在岗，更要看任务有没有真正在推进——因为 Agent 出问题时，程序未必真的挂掉，很可能是模型在原地打转或者跑偏了方向。只要察觉异样，便及时上手纠正。
真的管用
技术掰扯了一大堆，你可能忍不住想：费这么大劲，Super-agent 到底有没有用？DeepSeek 做了一组对照实验。每轮约 300 条消息里，真正算正经活儿的只有 20 条左右，其余全是闲聊、跟进和 CI 通知。参赛的是 Super-agent 与传统的“单会话 + Subagent”方案，后者又被拆成普通提示、以及劝它多派任务两种打法。
结论是 Super-agent 又快又稳：一半任务在十二分钟出头就收尾，95% 的任务堆在近分钟内完成。反观单会话方案在普通提示下，五轮实验一次都没舍得把任务甩给 Subagent，全靠单打独斗，还被打断得频率不断，95% 的任务要拖到近半小时。哪怕你在旁边不停劝它多派活，五轮里也只有四轮听劝，剩下那一轮它觉得活儿太小、索性自己扛，结果 95% 的任务依旧耗到近半小时。
这太像职场里那种什么都舍不得放手的组长了——你劝他放权，他一忙起来照樣忍不住自己上手。所以与其用提示词去苦劝模型分工，不如直接从架构层把规矩立死。靠制度去管人，总比靠自觉来得牢靠。
当然，天下没有白吃的午餐，代价同样存在：一边维护多个会话，Super-agent 读缓存耗掉的 token 是单会话方案的两三倍到近四倍。再者，这场实验跑在模拟环境里，成效也只能当作初步参考。
没解决的几个坎
DeepSeek 在文章末尾，倒也坦诚地抛出几个悬而未决的问题。第一，任务规模继续膨胀，一个项目经理到底够不够用？连轴跑上几个月，长期记忆又该怎么安顿？第二，不再盯着会话之后，人究竟该用什么姿态去和 Agent 协作，聊天窗口还是那块最优屏吗？第三，每个人的私人助理和团队公用的 Super-agent 之间，如何在不泄露隐私的情况下彼此配合？第四，Agent 越主动，吃进的不可信信息就越多，一旦 tempted 提示词注入被攻破，防线该往哪撤？
在我眼里，安全始终是 Agent 落地路上最硬的那道坎。你就敢放心让 AI 24 小时盯着群、替你把玩你的电脑吗？万一哪天滑进来一条恶意消息，顺手把 AI 给忽悠瘸了，你的数据和隐私又要谁来兜底？
最后说两句
DeepSeek 说自己并没有发明什么新理论，不过是把计算机系统里的经典套路用到了 Agent 身上。但在我看来，它更像是把一套团队管理的成熟玩法，整套搬进了 AI 的世界。过去是我们自己守着一扇扇窗口当传话筒，往后或许更像是领着一支 AI 团队，你只负责拍板与验收。说到底，AI 越来越不缺干活的力气，缺的是组织活的骨架。
眼下这套架构还停留在设计探索阶段，部分设计已经放进了开源仓库，上线没几天就攒上了上万 Star。官方也明话说这只是研究原型、不是正式产品。但对正在为多智能体协作、云端常驻部署或是高并发任务调度挠头的开发者来说，它提供的思路相当值得借鑑——哪怕是挑一个架构切点，借助时代互联这类成熟托管云把常驻智能体先稳定跑起来，再回头打磨分层与事件驱动的设计，未必不是条务实的起步路径。
