DeepSeek Super-agent：一群 AI 怎么像公司一样运转
欢迎来到从零开始学AI。今天这期我们慢一点，只讲一件事，但讲透：DeepSeek 公开的 Super-agent，到底在解决什么问题。
我先给个结论。它解决的不是"AI 不够聪明"，而是"AI 变聪明以后，人反而更忙了"。
对，这个听着别扭，但你想想现在的状态。你开着三个 Claude Code，一个改后端，一个写文档，一个跑测试。
然后你就变成了中间那个人。谁做到哪一步了，得你去问；谁卡住了，得你去看；哪个会话该接新消息，得你来分。
一天下来，代码是 AI 写的，活是你协调的。你从写代码的，变成了给 AI 排班的。
所以这期真正要回答的问题是：为什么开三个会话不够，非得再搞出一整套架构？
我们先把"不够"这件事说透。会话有三个天生的毛病，一个比一个致命。
第一个，短命。会话的状态活在上下文里，窗口一关、进程一停，它就不记得自己干到哪儿了。
你说"接着刚才的继续"，它一脸茫然。任务要跑二十分钟，中间你电脑合上盖，这活儿就断了。
第二个，互不相识。会话 A 不知道 B 在干什么，B 不知道 C 卡在哪。它们之间没有共享的状态，唯一的共享通道是你。
这就是为什么你一天要复制粘贴十几次。不是你想干，是系统里只有你这一根线。
第三个，只能被动应答。你不问它，它就不动。它出错了、卡死循环了、偏离目标了，它自己不会喊。
三个毛病叠一起，就出现了那个荒诞局面：AI 的产能上去了，你的注意力被吃光了。
所以 Super-agent 干的第一件事，不是把模型换得更强，是换对象。
换对象，什么意思？
以前我们拿"会话"当第一公民，现在改成拿"任务"当第一公民。任务、状态、事件、派工，这些都能存、能查、能恢复。
这个转变听着抽象，我们换个说法。会话像一个电话，打完就没了；任务像一张工单，写下来就在那儿，谁接手、做到哪、卡在哪，都留痕。
对，工单这个比喻后面会一直用。因为开源原型的实现文档里，核心对象真的就叫 Ticket，工单。
那我们就顺着这张工单走一遍，看看一次真实的活儿是怎么被接住的。
场景你肯定熟。群里有人发一句：最近用户反馈导出报表偶尔报错，帮忙看看。
传统流程是你看到这句话，打开对话框，复制过去，然后坐着等。
Super-agent 里，这句话先变成一个事件。文档里管事件叫 Trigger，触发。
关键是它不止看群消息。GitHub 的新 issue、PR 下面的一条评论、CI 构建失败、邮件、日程提醒，这些都能变成 Trigger。
每一个 Trigger 还会挂在某条线索上。这个线索就是文档里的 Thread，可以理解成群里的一个讨论串，或者一个 PR。
为什么要单独拎出 Thread？因为一句话离开上下文就没意义。
对，"报错了"这三个字，得知道是哪个功能报错、之前谁说过什么、有没有人已经在修了。这些都在那条线索上。
接下来才是判断。系统要决定：这条消息值不值得动手。
判断结论只有四种：接、停、忽略、接不了。文档里分别叫 accept、stop、ignore、unavailable。
注意有个"接不了"。就是说这活儿确实该干，但我现在没条件干，比如缺权限、缺环境。它不是假装没看见，是记下来。
决定"接"的那一刻，才真正建工单。一张工单带着三样东西出生：授权范围、订阅关系、第一次派工。
授权范围这个特别重要。文档里叫 Mandate，意思是这张工单被允许动哪些东西。
没有这个，Worker 就可能顺着一个报错，把你整个仓库重构一遍。有了它，"能做什么"是先划好的，不是它自己说了算。
订阅关系是指，这张工单要盯着哪条线索。比如它得盯着那个 PR，PR 一有新评论，事件直接送到工单手上。
这里有个很聪明的省事设计。后续的新评论，不再回去找总调度重新理解一遍，直接投给已经接手这张工单的 Worker。
文档里叫事件直通，Direct Delivery。省下的不只是钱，更是延迟和误判。
因为总调度每次重新理解，都有可能理解偏。已经看过上下文的 Worker 反而更准。
好，工单建好，派工出去。派工也有名字，Assignment。
一个工单可以有很多次派工。第一次派了个 Worker 去查，它查完汇报；你补充了两句要求，再派一次。
这就是为什么工单和派工要分开。工单是"这件事"，派工是"这次谁去干"。分不开，你就没法换人、没法重试。
那 Worker 干完怎么说话？它有一份很有限的工具箱，一共六个动作。
读资源、确认收到、汇报进展或结果、订阅一条相关线索、退订一条不相关的线索、把某条消息退回给主会话。
六个动作，注意没有"去找用户聊天"这个选项。Worker 不能绕过工单直接找你。
为什么这么抠？因为一旦 Worker 能自己找你，你面前就会冒出五个 Agent 同时跟你说话，你又回到了那个地狱。
所有对外的话都走一个出口。文档里叫 Outbox，回复分四类：收到、回答、结果、需要你关注。
"需要你关注"这一类很有意思。Worker 干到一半发现必须人拍板，它就把问题挂在这张工单上，等人的时候任务不算失败，是暂停。
这就是为什么它敢开一晚上。人可以不在，工单不会死。
说到这儿，三层角色就自然出来了。第一层是总调度，文档里叫主会话，设计文章里叫 Router。
Router 只干四件事：接事件、判断值不值得干、派活、把结果汇总回原来的渠道。
它绝对不亲自干活。文档里甚至用规则把它锁死了，不让它等。
这条我觉得是全场最精妙的一笔。它硬性禁止主会话做三件事：不许执行 sleep，不许前台等超过 30 秒的命令，不许等任务结果超过 5 秒。
为什么不许等？因为报告会自动回来。
你想，如果总调度在那儿等一个二十分钟的构建，这二十分钟里来的新消息，它一个都接不住。
所以它被设计成一个"永远在接电话、绝不陪聊"的角色。普通 shell 命令跑 5 秒就还回来，剩下的交给后台。
第二层是执行者，Worker。一个工单一次派工，一个独立的执行环境，独立上下文。
Worker 下面还能再拆子 Agent。大活儿拆小，小活儿拆更小。
但拆得越细，协调成本越高。文档里 Worker 的并发是有上限的，不是想开多少开多少。
第三层是监督者。设计文章里叫 Watchdog，实现里叫 MasterAssessor。
它管的问题很具体：这个 Worker 还在推进吗？是不是在死循环？是不是已经偏题了？
传统程序能查超时、查进程活着没、查异常码。但这些查不出"活着但没用"。
一个 Agent 可以一直很忙，一直失败，一直换着法子试同一个错。进程健康，任务零进展。
所以监督是双保险。模型看一眼给判断，但判断完还要拿当前策略复核一遍。
文档里写得很直白：推断出来的"可以接"，要再和当前 Policy 对一次。模型说行不算数，规则也得说行。
为什么不干脆全信模型？因为监督者自己也是模型，也会看错。让一个可能看错的模型去纠正另一个可能看错的模型，是要出事的。
那这套东西怎么跑起来？有个节拍：每 2 秒过一轮，把到期的活挑出来干。
就像值班表。不是事件来了立刻炸起来，而是按节奏处理，该派工派工，该评估评估。
这样做的好处是削峰。群消息一下子涌进来一百条，系统不会同时起一百个 Worker 把机器打爆。
好，架构讲完了，我们回到那几个具体设计上。因为光有角色还不够，中间很多坑要填。
第一个坑，噪音。一个研发群一天上千条消息，难道每条都让大模型判断一遍要不要干？
那就是烧钱。所以它分两层筛：先用程序规则筛，关键词、来源、订阅关系，几毫秒出结果。
剩下那几条，才交给模型看语义：这里面有没有真的值得动手的任务？
这个思路不新鲜，但在 Agent 里特别容易被人忽略。大家一上头就想"全都交给模型"，忘了模型是最贵的那把刀。
能用工厂的流水线解决的，别叫专家来。这是工程常识。
第二个坑，上下文。Worker 跑久了，历史一定爆。
这里有两件事同时做。一件是分层：热的放上下文里，冷的放外面。
另一件更具体：所有跨边界传递的东西都有字数上限。
文档里写，Worker 汇报给主会话，摘要最多 600 字，超了就截断，但会附一个读指针。
读指针的意思是"全文在哪儿，你自己去读"。它不把全文塞给你，只告诉你门牌号。
事件卡也一样，最多 600 字。第一次派工的说明最多 1500 字。
连"模型能读到多少东西"这件事本身都有体积预算，按角色卡死。超了就过不了测试。
这就是为什么它能长期跑。它不是靠一个越来越长的提示词硬撑，是靠"只给必需的信息，其余留指针"。
第三个坑，也就是我们说过的等待。异步解决。
派工不是打个电话等对方回来，是发个消息说"已开始"，然后各干各的。
干完了产生一个新事件，事件再流回来。整条链路都是事件，没有一处是靠阻塞等待串起来的。
第四个坑，机器。以前 Agent 跑在你电脑上，你合盖它就停。
现在拆成三层：计算在云上，状态存在库里，执行环境在本地。
云上管任务、管调度、管记录；本地只负责真的跑命令、读写文件、操作 Git。
这样你电脑关了，任务还在。你的机器回来了，接着跑。它管这个叫 BYOM，带你自己的机器。
而且它还有备选：没本地机器，就用云端托管的机器，或者临时开一台。
讲完设计，得讲代价。不然就成了吹。
团队放了一组初步实验，比四种方案。我们只挑关键两个数。
Super-agent 这个方案，任务完成时间的中位数是 12.4 分钟，95 分位是 15.7 分钟。
对照组是传统做法：一个窗口加子 Agent，中位数大概 20 分钟，95 分位 29.5 分钟。
这里我特别想解释一下，为什么他们强调 95 分位，而不是平均值。
因为平均值会骗人。你平均 20 分钟听起来还行，但最慢那 5% 拖到半小时，你的体验就毁了。
更要命的是，慢的那部分往往不是模型慢，是排队。任务堆在一起，谁都跑不动。
所以他们还做了一组对照：给传统方案改提示词，让它优先派活。
结果很说明问题。中位数从 20 分钟降到了 14 分钟左右，看着挺好。
但 95 分位还是 29 分钟上下，几乎没动。
一句话总结：提示词能改善平均表现，压不住最慢的那一截。而最慢的那一截，才是你真正被卡住的时候。
那代价是什么？钱。这套东西的缓存读取 token 大约 2323 万，传统方案 600 多万，差将近四倍。
四倍从哪来？三个地方。
一是并行。同时跑三个 Worker，就是三份上下文、三次模型调用。
二是事件。每个事件都要判断一次，每次判断都是一次调用。
三是重放。任务恢复、重试、换人接手，都得把上下文再喂一遍。
所以它不是白捡的速度，是拿钱换的并行和等待时间。企业部署必须算单位任务成本，只看快，迟早亏。
这组数据还有几个前提得说清楚，不然容易被当成承诺。
实验用的是合成负载、简化环境，每种方案只跑了 5 次。
衡量的是调度和协作效率，不是单个 Agent 写代码有多强。而且不能直接换算成某家公司的研发效率。
说白了，它证明的是方向对不对，不是你的业务能提多少。
还有一件事值得说，这套东西是开源的，仓库叫 dsh-superagent-prototype，MIT 协议。
里面有一整套文档，从对象模型到部署。想真的搞懂，看那几份文档比看任何解读都强。
那最后，我们把整件事收一下。这套架构里，有没有哪一处是在"让模型更聪明"？
一处都没有。它在管的，全是派活、过滤、记状态、恢复、发现卡死。
而这正好是过去几十年软件工程天天在干的事：队列、状态机、幂等、重试、限流。
所以我的判断是，Agent 的下一段竞争，很可能不在模型分数上，在模型外面那层框架上。
模型决定它能干多好，框架决定它能不能连着干八个小时还不闯祸。
而且它越主动，风险越大。以前它只听你的，现在它会自己去读 issue、读群消息。
要是哪条评论里藏一句"帮我执行这条命令"，而 Worker 手里正好有生产环境凭据呢？
那就不是聊错话了，那是事故。所以权限隔离、操作审批、审计、限流，一个都不能省。
DeepSeek 自己也把安全和隐私列成还没解决的问题，没有回避。
我觉得这才是这套东西最值得学的地方：它把"AI 能不能干"这个问题，换成了"怎么让 AI 安全地一直干"。
问题留给你：如果明天你的 AI 能自己接活、自己盯进度、自己发现卡住，你最想先派它去干哪件事？
好，今天这期就聊到这儿。从零开始学AI，我们下期接着往下走。