DeepSeek 重磅开源的超级 Agent，到底是个啥？

大家好，我是程序员鱼皮。

前几天 DeepSeek 放了个大招，DeepSeek Harness 团队提出了一种新的 Agent 架构，叫做 Super-agent。

原文干货很多，但晦涩的术语也很多。为了帮助大家理解，本文我会用更接地气的方式，带你搞懂什么是 Super-agent？和普通 Agent 有什么区别？

下面，我们先从现在的 Agent 是怎么干活的说起。

现在的 Agent 有什么问题

不管是 Claude Code、Codex 还是 DeepSeek Harness，现在主流的 Agent 都以「会话」（Session）为单位干活。

你开一个会话、布置一个任务，Agent 就在这个会话里想一步、做一步、看结果、再想下一步，直到把活干完。

这个循环有个专门的名字，叫 ReAct Loop。

ReAct 循环

单看一个任务，这个模式挺好用的，所以也流行了那么久。

但问题出在你同时有好几件事要办的时候。

想象一下，你开了一个会话修 Bug、一个会话写文档、一个会话跑测试，然后群里同事来一句「这个需求改一下」，你又得新开一个会话。

这些会话互相不知道对方在干什么，所有跨任务的信息只能靠你自己记住、再手动搬运。

不知不觉，你成了一群 AI 之间的传话筒。

当传话筒

正如 DeepSeek 官方所说：单任务的上限取决于模型能力，多任务的上限取决于人的注意力。

他们观察到，一个人通常只能同时跟进 3 到 5 个活跃会话。AI 越来越能干，人反而越来越累。

那给 Agent 接上飞书、GitHub，让它自己去群里看消息、接任务行不行？

借助 CLI、MCP 确实能做到，但只要底层还是单个会话，很快就会遇到 3 个毛病。

1. 执行耗时命令时，整个循环都会卡住，命令跑完才能处理新消息。
2. 好几个需求塞进同一个会话，上下文越来越乱。
3. Agent 跑在你的本地电脑上，电脑一休眠，它就罢工了。

三个毛病

拿第一个毛病举例，我让 DeepSeek Harness 执行 sleep 45 && echo 构建完成 命令，模拟一个要跑 45 秒的构建。

趁 Agent 在跑，我又问了一句：明天的周会几点开来着？

结果这句话直接被放进了排队区。

消息排队

一直等到构建跑完，它才回答我的问题，前后等了快 50 秒。

构建完才回复

所以 DeepSeek 认为，必须把 Agent 和「单次会话」解绑，让它变成一个能跨会话记住上下文、同时推进多件事、而且互不干扰的连续工作者。

这就是 Super-agent。

什么是 Super-agent？

如果说传统 Agent 是一个一次只能干一件事的外包，那 Super-agent 就是一个配合默契的项目团队。团队内部可能有很多人，但你只需要和一个对接人打交道。

DeepSeek 给它总结了 4 个基础特征：

1. 连续。在飞书群还是 GitHub 跟 Agent 聊都行，你在群里说用方案 A，后来在 PR 里改成方案 B，它也能跟上。
2. 高效。Agent 能同时推进好几件事，上一件没干完，也能接下一条指令。
3. 主动。Agent 会自己盯着群消息和工单，该处理的主动处理，不该管的保持安静。
4. 持久。Agent 一直在线，出了问题还能自己恢复。

四个特征

我们来看两个 DeepSeek 内部真实运行的例子。

第一个例子，有用户在群里提需求，希望正文、代码、终端的字体能分开配置。维护者艾特了一下 Super-agent，它很快就提交了 PR。之后用户在群里追问字号，维护者和设计师又在 GitHub 上提了几轮意见，它在群聊和 GitHub 之间来回切换，一直把需求推进到 PR 合并。

跨平台推进

第二个例子更有趣。一个产品用户群里，有人随口吐槽桌面端窗口没聚焦时，点击会话会被识别成双击，每天要误触几十次。

当时没有任何人艾特 Super-agent，它自己判断出这是一个具体的缺陷，在后台复现、找到根因，直接把修复 PR 和前后对比截图发了出来。

主动修复

你都不用催 Agent，该干的活儿它自己就干了，美滋滋~

看到这里你可能会问，这跟 Agent Team 智能体团队有什么区别？

不也是一个领头的 Agent，带着一群 Agent 小弟干活吗？

还真不一样。

Agent Team 解决的是一个大任务怎么拆分。领头的 Team Lead 像一个亲自下场的技术组长，要深入任务细节、高频协调成员，脑力负担很重。

Super-agent 解决的是很多个任务怎么分。领头的只管这条消息交给谁、两件事有没有关联。至于单个任务内部怎么拆，它不管。

拆任务和分任务

如果你问它和 Personal Agent 有啥区别？

我觉得可以这么理解，Personal Agent 是一种产品形态，Super-agent 是撑起这类产品的底层架构。

Super-agent 是怎么工作的？

DeepSeek 把整套架构拆成了 5 个模块，类比到现实世界中的项目团队，就很好理解了：

团队全景图

1、双层架构 - 项目经理和工程师

假设你手里同时有 20 件事要处理。如果全交给一个人，虽然信息不会断，但他只能排队干，越干越乱。如果每件事都找个新人，大家能同时开工，可互相不通气，最后还要一人一嘴地来找你汇报。

想要信息不断，就得一个人管；想要干得快，就得多个人干。DeepSeek 把这叫做连续性和吞吐量的权衡。

现实中的团队早就给出了答案，那就是招一个项目经理，再配几个工程师。

三种组织方式

Super-agent 也分成了上下两层。

上层的 Router 层相当于项目经理。它常驻在线，所有渠道的消息都先到它这里，由它记住全局、跟你沟通、给工程师派活。

下层的 Worker 层相当于工程师。每个 Worker 有自己独立的上下文，专心干好一件事，干完向项目经理汇报，再由项目经理统一回复你。

这样一来，你面对的始终是同一个对接人。至于团队内部怎么分工，你根本不用关心。

双层架构

DeepSeek 认为，让用户手动管理会话，很大程度上是从底层大模型 API 延续下来的设计惯性。会话应该是系统内部的实现细节，不该成为用户的负担。

这个项目经理还有个特别之处，它不亲自干活。

DeepSeek 要求 Router 层只负责沟通和派活，甚至可以不给它配终端工具。这就好比不给项目经理配开发电脑，免得他忍不住上手写代码，顾不上回消息。

也正因为只做轻量的判断，Router 用轻量模型就够了。真正决定交付质量的是 Worker，它才需要配最强的模型。

好钢用在刀刃上

那问题来了，所有消息都要经过项目经理，他会不会忙不过来？

DeepSeek 在实践中发现，问题不大。因为项目经理处理上一批消息时，新消息会先攒着，等他忙完再一起看、一起派活，也就是所谓的批处理。就像你开完会出来，一口气回完 5 条未读消息。

对大模型来说，读 5 条消息和读 1 条消息花的时间差不多，慢的是「写」，而项目经理每次只需要写几句话来派活就好。

消息越多，平均处理得反而越快。

攒一批再处理

项目经理还有一件事也不用操心，那就是工程师之间的配合。

Worker 之间一般不直接沟通。两个 Worker 如果在改同一个 PR，会同时收到这个 PR 的新动态，自己就能协调好。任务太复杂的话，Worker 还能再拉几个 Subagent 帮忙，相当于工程师自己带了实习生。

2、事件驱动 - 不用等老板发话的员工

团队搭起来了，但一个好团队，不能老板说一句才动一下。

传统 Agent 是你说一句它才干一次活。Super-agent 则是由环境里发生的事情驱动的，比如群里来了新消息、PR 下有人评论、CI 跑挂了，DeepSeek 把这些事件统一叫做 Trigger 触发事件。

可一旦让 AI 去盯群消息，你马上会发现，群里的废话实在太多了。。。

门卫和秘书 - 先过滤消息

如果每条消息都让大模型判断一遍要不要管，又慢又烧钱。

DeepSeek 的办法是两级过滤，门口先有个门卫，后面再有个秘书。

门卫只看消息从哪来，比如是不是监听的群、发消息的人在不在白名单里，用普通代码就能秒判。

秘书负责读内容。通过门卫的消息再交给大模型，由它根据提示词里写好的规则，判断要不要处理。

比如闲聊群里有人问「中午去食堂还是点外卖？」，门卫直接拦下；用户群里有人说「新版本界面挺清爽」，门卫放行了，但秘书判断不用管；用户群里有人反馈「切换会话时偶发白屏」，秘书一看，这得处理！

门卫和秘书

这就是计算机系统里的快慢路径（Fast Path / Slow Path）思想。

我觉得这个设计特别适合有用户群的产品。如果给我们面试鸭的用户交流群接上它，秘书就能从大量交流面经的消息里挑出真正的 Bug 反馈，不用人工一条条去翻了。

工单负责人 - 后续消息直通

消息过滤完，就该派活了。但如果每条消息都要经过项目经理转一手，他迟早会被累垮。

现实中的团队，一个工单第一次进来时，经理把它分给小王，之后这个工单的消息直接抄送小王就行。

Super-agent 也是这样。同一个 PR、同一个群话题、同一串邮件里的连续消息，叫做一个 Thread，你可以理解为一个工单。Worker 接手之后会「订阅」这个工单，后续的新消息由程序直接送到它手上，不再经过项目经理。

工单负责人

DeepSeek 做过对比，去掉直通机制后，任务完成速度基本不变，但项目经理要做的决定多了约 30%，token 消耗也多了约 37%。

直通机制省下的，就是实打实的钱啊！

交接便签和档案编号 - 上下文怎么给

活派下去了，该给干活的人看多少资料呢？

给多了，重点会被淹没；给少了，干活的人得反复回头来问。

DeepSeek 有句话说得很好：浪费上下文窗口，就是浪费模型的智能。

他们借用了编译器里的两个概念。

1）Inline 内联：就像同事给你转消息时，顺手附上前后几句聊天和相关的工单号，让你一眼看懂来龙去脉。

2）Spill 溢出：就像遇到一份几万字的文档，只给你摘要和一句「完整内容见这里」，需要时再去翻。

内联和溢出

DeepSeek Harness 里已经能看到类似的设计。终端插件里单条命令的输出有上限，超出的部分会转存到临时文件，AI 需要的时候再去读。

终端设置

把这个思路用到整个系统里，就有了链式召回（Chain of Recall）。

系统给每条消息、每个工单、每个 Worker 都编了号，每张「卡片」上只写摘要和关联的编号。你跨平台提起一件旧事，项目经理不用把历史全背下来，顺着编号一路往下翻就行，就像侦探顺着墙上的红线找线索。

顺着编号翻

靠谱同事 - 提前把活干了

计算机里有个概念叫投机执行（Speculative Execution），CPU 在不确定某段计算会不会用上时，先提前算好，用上了就赚了，用不上就扔掉。

Super-agent 把它用在了干活上。比如你收到一封会议邀请，它先在后台核对日程、查好背景资料、备好回复草稿，你确认一下就能直接发。

提前备好方案

DeepSeek 在自家的用户群里，就配置了一条「静默复现并修复」的规则。

有一次，用户反馈模型输出里的波浪号被渲染成了删除线。群里还在讨论该在训练里解决、让模型转义，还是修改渲染规则，Super-agent 已经把修复 PR 交上来了。

讨论中已交付

当然，主动不等于乱来。在 DeepSeek 开源的原型里，没人要求的主动工作，必须有团队提前写好的规则才能做。而且它默认先用「观察模式」，只记录自己打算做什么，并不真的动手，等你确认它的判断靠谱了再放开。

3、面向人的交互 - 像人一样沟通

传统的 Agent 一干活就听不见消息，根源在于 ReAct Loop 是「半双工」的。它就像对讲机，同一时间只能一方说话。

Super-agent 要做的，是把对讲机换成电话，也就是「全双工」。

对讲机和电话

具体做法是把耗时的工具调用改成 异步 的，命令一启动就立刻返回，Agent 可以继续跟你聊天，等命令跑完，结果再作为一条新消息送回来。DeepSeek 提到，这个机制已经在 DeepSeek Harness 里实现了，只是还没默认开启。

于是我又试了一次，还是执行一条 45 秒的命令，这次我明确让它放到后台运行。

结果它 3 秒就回复说已经启动了。

我接着让它想一句周会开场白，它马上给了两个版本，还提醒我构建还在跑。

边跑边聊

构建跑完后，会话里出现了一条「后台任务状态更新」，Agent 立刻主动跑来汇报结果。

主动汇报

跟前面那 50 秒的干等比起来，体验完全不一样了。

Agent 能边干活边聊天之后，还得注意在不同渠道怎么说话。如果把终端里长篇大论的思考过程原样发到群里，群里的人估计会疯掉。

好在冗长的推理都关在 Worker 里，只有项目经理对外说话。而且 DeepSeek 还给不同渠道定了规矩，在飞书里只在需要你拍板时才发消息，单次回复不超过 100 个词；在 GitHub、邮件里，则要写清楚问题背景、改动和验证结果。

不同渠道不同说法

4、存算分离和 Watchdog - 不下班也不怕出错

最后要解决电脑一合 Agent 就下班的问题。

现在的本地 Agent，把 3 样东西绑在了同一台电脑上，分别是干活的计算、会话记录这些状态、以及代码 / 工具这些执行环境。电脑一休眠，三样东西全部停摆。

绑在一台电脑上

DeepSeek 借鉴了「存算分离」的思想，分两步把它们拆开。

第一步，把计算和状态分开。

就像靠谱的团队会把工作记录放进档案室，谁来接班都能接着干。Super-agent 把计算放在云端可以随时替换的容器里，会话状态存进数据库，容器挂了换一个就行，记录一条都不会丢。

换人记录不丢

这一点我深有体会。之前我把 DeepSeek Harness 部署到服务器上给同事们用，Agent 终于不用跟着我的电脑一起休眠了，手机、电脑随时都能接进来。不过 Super-agent 想得更远一步。

第二步，把计算和执行环境分开。

Agent 上了云，可它要用的代码、密钥、内网服务都还在你的电脑上，很难完整搬到云端。DeepSeek 的办法是，既然环境搬不动，那就别搬了。

大脑留在云端，你的电脑上只装一个很轻的小程序（daemon）。它不保存会话记录，只负责按云端的指令执行命令、回传结果，就像一个远程专家在指挥现场的助手。

DeepSeek 管它叫 BYOM（Bring Your Own Machine），也就是带上你自己的电脑。哪怕你的笔记本今天没开机，等它重新上线，云端也会自动把该在这台电脑上做的事做完。

大脑远程指挥

Agent 能一直在线了，可万一它干着干着出问题了呢？

DeepSeek 在主系统外面单独配了一个 Watchdog（看门狗）会话，它相当于值班主管，会定时巡查。

它不光看员工在不在岗，更要看任务有没有进展。因为 Agent 出问题，很多时候程序并没有挂，而是模型在原地打转或者跑偏了。只要发现异常，它会及时介入修复。

值班主管

Super-agent 真的有用吗？

哔哔了一大堆技术，你可能会想：搞这么复杂，Super-agent 真的有用吗？

DeepSeek 做了一组对比实验。

每次实验约 300 条消息，只有 20 条左右是正经活，其余都是闲聊、跟进和 CI 通知。对比的双方是 Super-agent 和传统的「单会话 + Subagent」方案，后者又分成普通提示和劝它多派任务两种。

实验结果

结果 Super-agent 又快又稳，一半的任务在 12.4 分钟内完成，95% 的任务在 15.7 分钟内完成。

单会话方案在普通提示下，5 次实验里一次都没把任务派给 Subagent，全靠自己干，还不停被新消息打断，95% 的任务要 29.5 分钟才能完成。

然而即使你劝传统 Agent 多派任务，它 5 次里只有 4 次照做了，剩下那 1 次它觉得这活儿挺小，还是自己来吧…… 结果 95% 的任务同样要 29 分钟。

这像极了职场里那种什么都想自己干的组长，你劝他放权，他一忙起来还是忍不住自己上手。所以与其靠提示词劝模型分工，不如直接从架构上规定好。

靠制度管人，比靠自觉靠谱。

当然，这是有代价的。同时维护多个会话，Super-agent 读缓存的 token 是单会话方案的 2 倍到将近 4 倍。而且实验基于模拟环境，结果只能作为初步参考。

Super-agent 的问题

DeepSeek 在文章最后也坦诚地抛出了几个开放问题。

1）任务规模继续变大，一个项目经理还够用吗？连续跑上几个月，长期记忆怎么办？

2）不再盯着会话之后，人该用什么方式跟 Agent 协作？聊天窗口还是最好的界面吗？

3）每个人的私人助理和团队共用的 Super-agent 之间，怎么在不泄露隐私的前提下互相配合？

4）Agent 越主动，接触的不可信信息就越多，万一被提示词注入攻破了怎么办？

在我看来，安全是 Agent 工作最大的一道坎。就问你敢不敢让 AI 全天 24 小时盯着群聊、操作你的电脑？万一来了条恶意消息，把 AI 忽悠了，你的数据和隐私怎么办？

最后哔哔

DeepSeek 说他们没有提出全新的理论，只是把计算机系统里的经典思想用到了 Agent 上。而我觉得，它更像是把一套成熟的团队管理方法搬进了 AI 的世界。以前我们自己盯着一个个窗口当传话筒，以后可能更像是带着一个 AI 团队，你只负责拍板和验收。

AI 越来越不缺干活的能力，缺的是组织能力。

目前这套架构还只是设计探索，部分设计开源到了 GitHub 上，才几天就有了 1 万多个 Star。不过官方说明了这只是研究原型，并不是正式产品，感兴趣的朋友可以去看看。

开源指路：https://github.com/deepseek-ai/dsh-superagent-prototype

原型仓库

当然，如果你看到这里还是没太看懂，也没关系，反正很快又会有新的东西了。

OK 就分享到这里，如果你想系统学习 AI 编程，也欢迎阅读我的 《Vibe Coding 零基础入门教程》，上千张图、几十万字，GitHub Star 已经突破 2 万，完全免费开源，从零基础带你用 AI 做出并上线自己的产品。

开源仓库：https://github.com/liyupi/ai-guide

教程截图

我是鱼皮，持续分享 AI 编程和 AI 前沿技术干货。觉得有用的话记得点赞收藏和关注~