DeepSeek 发布 Super Agent 设计方案技术文章

以下是视频口播的自动转写，可能有错字。

我们来看看 deepseek 刚发的一篇技术文章，super agent 设计探索。他要解决的问题是，ai 已经能自己写代码了，现在卡住效率的反而是人。他们观察到，一个人同时最多只能盯3~5个 agent 的绘画，每开一个窗口，你都得记住他聊到哪了。

单任务的上限看模型，多任务的上限看的是人的注意力。所以，super agent 的目标是，不管你在哪说话，面对的始终是同一个 agent。比如你先在群聊里说用方案 a，后来在 github 评论里改成方案 b，他能接上，直接调整方向。问题来了，如果所有消息都塞给一个绘画，他只能一件件串行干。

如果每条消息都新开一个绘画，大家又各干各的，互相不知道，还会抢着回你消息。他们的办法是拆成两层，上层叫 router，像公司前台，所有消息都先到他这里。他只负责理解、分派和对外回复。自己不下场干活，连命令行工具都可以不给。下层是一群 worker，每个只干一件事，上下文互相隔离，干完把结论交回 router，由 router 统一回复你。

绘画从此变成系统内部的细节，不再是你的负担。第二个关键是主动，驱动它的不再是你一句句打字，而是环境里的事件，群聊消息、邮件、代码评审评论、ci 结果，统称 trigger。可群里绝大多数消息都不需要他管，每条都让大模型判断，又慢又贵。所以分两级过滤，先用程序按来源、群组、白名单直接筛掉大部分。

这叫快路径。剩下的候选才交给模型判断要不要出手，这叫慢路径。已经在处理的话题，比如同一个 pull request 下的后续评论，负责的 worker 会直接订阅这条线程。新消息由程序直通给他，不用再绕 rotor 一圈。更进一步是投机执行，他们在内部群里配了一条规则，有人反馈问题，agent 先在后台悄悄复现，找修复，确认能修才把结果交出来。

修不了就全程不出声，结果是没人艾特他，他自己提了修复 pr。后台干长活时还能跟他说话吗？能。耗时工具被改成异步的 start 和 stop，一调用就立刻返回已启动，对话不被卡住，结果出来再作为一条新消息送回来。说话方式也分场合，在 im 里像同事一样只给结论，一次回复不超过100个词。

在 github 上，就写完整的背景、改动和验证结果。最后是持久在线，本地 agent 一合上电脑就停了。他们把三样东西拆开，计算放进云端无状态容器，绘画状态存进数据库，而代码仓库、本地凭据这些执行环境。留在你自己的机器上，只装一个轻量 demon 负责执行命令。

光活着还不够，很多故障不是进程崩了，而是模型在原地打转。所以外面再挂一个 watchdog，定时检查每个 worker 有没有实质进展，有没有跑偏。发现问题就介入修复。效果怎么样？他们用大约300条消息模拟群聊加 ci，其中20条是真正的工作请求，每种方案跑5次。

对照组是单绘画加 sub agent 的工具。在中性提示下，模型五次，一次都没委派，所有活自己干，还不停被新消息打断。95分位耗时29.5分钟。而 super agent 中位数12.4分钟，95分位15.7分钟，又快又稳。订阅直通有什么用？

完成时间差不多，但关掉它，router 要多做约30%的决定。读缓存 token 从2323万涨到3177万。多了约37%。还有个反直觉的点，消息越堵，router反而越划算。积压的事件会合并成一批一次处理，而模型读输入是并行算的。批次从1涨到2.8，单次请求只从2.5秒变成3.9秒，摊到每个决定从6.4秒降到1.6秒。

一句话总结，把会话管理交给系统，人只负责决策和验收。要注意，文末 github 上的代码只是验证思路的原型，不是 deepseek 的正式产品。下期想看哪一块拆细讲？评论区告诉我。