DeepSeek Super-agent 工作原理深度拆解

10月31日晚DeepSeek 干了一件不大张旗鼓、但后劲很足的事。Harness 团队发了篇技术文章《Super-agent 设计探索迈向更自主的 Agent 系统》顺手把原型代码开源了。两天9000 star。但你可能已经发现了这两天刷屏的文章讲的都是同一句口号——让 AI 指挥 AI。口号很好记问题是它没告诉你任何能用的东西。我把仓库的 README、docs/000–008、还有src/core、src/app、src/executor的核心代码翻了一遍发现两件事真正的干货全在代码里以及官方文章里有些模块开源原型里根本没有。这篇写给做 Agent 系统的人。不聊口号聊机制——而且顺手帮你把几处被媒体带偏的数据掰回来。01 它到底在解决什么问题先说清楚问题否则后面全是空中楼阁。官方的观察是现在让 AI 改个 Bug、写个功能它做得越来越好几乎不用你盯。但你想同时推进 5 个任务呢切换会话、复述背景、逐个验收——你变成了瓶颈。于是有了全文最狠的一句判断单任务的上限取决于模型能力多任务的上限取决于人的注意力。还有一句值得每个做 Agent 产品的人抄在墙上Session 应当是系统的实现细节而不应是用户的认知负担。翻成大白话凭什么要用户记住这个需求我说在第 3 个会话里这是系统的锅不是用户的。基于这个判断官方给出四个目标特征——注意这里就有个坑四个特征是连续、高效、主动、持久。很多报道写成主动/持久/并行/面向人错了。并行只是手段连续才是体验目标。连续在 IM 里提方案 A、在 GitHub PR 评论里改方案 B它都能接上你感觉始终只有一个 Agent高效并行推进多任务不用等上一个跑完就能接下一条指令主动持续观察环境事件主动干活但不需要介入时保持安静持久始终在线异常时自动恢复看到没——安静和主动是并列写进目标的。这一点后面会反复出现。02 五个模块怎么分工先看骨架。五个模块支撑上面四个特征① 双层架构Router 常驻是全局的序点、协调点和记忆不直接执行任务甚至可以不配 Bash 工具用轻量模型就够Worker 上下文隔离、挂完整工具、配最强模型不直接对用户说话只向 Router 汇报。这里官方坦白了一个取舍它表面上看和常见的 Agent Team 相似但侧重点不同——Agent Team 的 Lead 需要深入任务细节Router 只管任务之间的高层关联。这就是为什么 Router 能又轻又便宜。② 事件驱动输入不再是人逐条敲提示词而是环境里的半结构化事件——群聊消息、邮件日程、代码评审评论、CI 结果。③ 面向人的交互把耗时的run()改成异步的start()/stop()Agent 起了后台任务就立刻返回已开始结果作为新事件回注前台该聊继续聊。④ 计算/状态/环境分离借鉴存算分离云端跑 Agent Loop、状态进数据库本地只留一个轻量 daemon——官方管这叫BYOMBring Your Own Machine。所以你合上电脑任务还在跑。⑤ Watchdog主系统之外的独立控制回路不只盯进程活着没还由模型判断各个 Worker有没有实质进展、方向有没有跑偏。⚠️ 第五个模块有情况我在第 07 节单独说。03 核心一条消息进来之后发生了什么这部分是全文最值钱的。我把 17 步时序压成 7 个关键节点每一步都标了它写入什么状态。① 幂等去重同 id 的 Trigger 再来一次直接返回duplicate后面全不执行。分布式系统的第一课人家做得很规矩。② 程序层快筛先按谁说的、在哪说的、是不是 bot过滤。被判filtered的消息不进 Eval、不唤醒任何 Ticket——噪音在这一层就死掉了一个 Token 都不花。③ 扇出订阅直通系统找出订阅了这个 Thread 的所有 Ticket把消息直接塞给它们。注意已结束的 Ticket 也能被唤醒。④ 批处理成 Eval这个 Thread 上排队的所有 Trigger 被整批搬进一个 Eval——也就是说同时到达的 5 条群消息 一次模型调用。⑤ 原子开票判定 accept 后在同一个事务里一口气完成建 Ticket → 建 Mandate授权→ 挂首个 Assignment → 给相关 Thread 建 Subscription → 发受理回执 → 入队启动任务。任一步失败整个事务回滚。⑥ Worker 执行独立目录、独立 Session、独立上下文工具白名单。⑦ 事务性发件箱对外发消息时回执和发送动作在同一个事务里commit 之后才真的发出去。第 ⑦ 点我要多说一句因为它是整个系统不翻车的地基。源码里有一行注释特别坦率DshExecutor.stop被刻意挂在afterCommit上理由写着——一个被回滚的结束不会真的停掉 worker。做 Agent 的人都懂这个痛说了但没做和做了但没说都是事故。事务性发件箱就是解这个的。04 主动性是怎么不变成刷屏机器的让 AI 主动干活不难难的是让它知道什么时候闭嘴。Super-agent 用了四道闸门道道都能抄。闸门一两级过滤。便宜的程序规则先筛活下来的才交给模型判断。成本结构一目了然。闸门二accept mode 三档。这是我最想安利的设计——off— 一切推测性候选都不接observe默认— 照常评估但正向评估只记录本会接什么都不做auto— 真的接单看懂了吗observe 就是个影子模式让 Agent 先跑一段记录我本来会干什么人审过再放行。任何想上主动能力的团队都应该先做这一档。闸门三订阅直通。订阅 Thread 上的每条消息包括 bot 和 CI都直达 Ticket但——文档里有句加粗的话消息、评论、被引用的文档只是决策的输入不能改变权限。这是听得见和能做主的分离。听得见是为了上下文连续能做主必须走授权。闸门四投机执行 静默交付。官方原话还不确定结果是否会被采用时根据环境信号在后台提前尝试……有价值就交付没有价值就丢弃。内部实例特别生动有人在群里反馈 BugAgent 后台默默复现、定位原因只有确认问题真实存在、并且找到了简单修复方案才提交结果否则全程安静。⚠️ 顺手纠个偏有技术媒体把投机执行解释成预判下一步、命中就省一次往返——这跟官方定义完全是两回事。别被带跑。05 上下文是被当成 Cache 来管的官方一句狠话浪费上下文窗口就是浪费模型的智能。它的做法是三步最少信息起步 → 利用局部性 Inline → 超上限就 Spill截断但保留续读入口。代码里的预算卡得极死这些数字建议直接收藏单条 Trigger 文本最多 4000 字符关联 Ticket最多8 个开放者优先Thread 窗口前 5 条 触发点前后各 5 条单条一般 400 字符窗口外的消息降级成50 字符的 stub需要时按 id 展开分页读取每页4000code units列表20条配合的是链式召回给 Trigger、Thread、Worker Session 都发唯一 ID注入时内联关联 ID构成一张引用图。模型可以顺着引用一跳一跳往回找——当前消息 → Thread → Worker Session → 另一个评审 Thread。还有个细节很见功力权限即视图。Worker 读资源时页面会隐去它读不了的 id——别的 Ticket、Decision 决策记录它连 id 都看不到。06 任务怎么收口Ticket 的三层建模这块是工程上最见真章的地方。Super-agent 的 Ticket没有状态枚举而是三层正交建模第一层二值生命周期open !ended结束时记清楚是被谁结束的人还是 Agent、什么结局。第二层派生列 active有未投递输入、或最新任务还在跑就是 active。这一列不存储由 SQLite 生成列直接算出来。第三层stage仅 open 时有效自上而下首个匹配投递失败 → 等回答 → 等评审 → 卡住/失败 → 排队中 → 空闲 → 执行中。三个谓词撑起了大部分智能waitsForPerson报了 blocked/failed 且此后没有人的消息 →自动输入一律挂起等人followupOwners只要某个 Ticket 还持有这条人类追问decide就只允许 stop——防止同一个人的追问被两个 Agent 抢followsDone自己开的 PR 全关了才算完一个都没开过就等它 follow 的所有 PR 关完再送一个反直觉的细节Report 里的waiting 不是 Worker 写的是 host 在回合静默之后代写的。真正由 Worker 主动写的是progress / ready / blocked / failed / dropped。人怎么介入五个命令stopTicket撤回授权、retryTicket同一目录/分支/PR 上重开、reevaluate、unsubscribe、dismiss。还有一个设计我很喜欢在群里说停只是一个普通消息要由 Eval 判断是否该停Agent 不能自称人让我停的而面板上的 Stop 才是命令。话语权和命令权是分开的。07 数据三处被带偏的地方我帮你掰回来做技术的人最怕什么被二手数据忽悠。这三处媒体几乎全写错了。❌ 误读一编码快了一倍不是。中位数的提升20.4 → 13.8 分钟大半来自提示词是否要求优先委派不是架构。架构真正卖的是尾部p95 从 29.5 压到 15.7 分钟。而且实验里真实的编码工作被只消耗时间的工具替代了测的是调度不是编码质量。❌ 误读二订阅直通省了 37% Token是加速器官方原话是反过来的取消事件直通后Router 决策次数增加约 30%Token 从 2323 万涨到 3177 万。而完成时间几乎没变p50 12.4→12.6p95 15.7→15.5。订阅直通省的是调度开销不是时间。把它写成提速神器是错的。❌ 误读三批处理让回复更快了实测单次请求耗时是上升的2.5 → 3.9 秒下降的是每个决定分摊的推理时间6.4 → 1.6 秒。吞吐提升 ≠ 单条延迟降低。补一句那个被到处引用的一个人只能同时跟进 3~5 个会话官方措辞是据我们观察——团队经验值没有文献支撑。别写成研究结论。08 那道缝原型里其实没有 Watchdog这是我读代码时最意外的发现。我把 docs/000–008 和src/core/model.ts翻了个遍Watchdog 既不是领域对象也没有任何对应代码模块。它是官方文章第 6 节描述的模块属于部署侧的外部控制回路在开源原型里压根没实现。代码里功能最接近的是这四组机制Passes 心跳每 2 秒跑一次先跑到期副作用再跑到期评估Eval 截止时间从候选送达主 Session 才开始计时过期重排两次第三次记unavailable指数退避 健康看板同一类副作用连败 3 次才报错资源暂时不够用Later异常顺延不算失败启动恢复重启时把被打断的任务带恢复说明重新拉起顺便说下原型的真实状态README 明写这是research code不是生产级软件仓库1 个 commit、0 个 release、issues 已关闭。这不是挑刺——承认文章讲的和代码有的之间有缝本身就是一种专业。怕的是把 PPT 当产品。09 可以抄走的 8 条设计说了这么多最后给你一份能直接用的清单影子模式observe让主动能力先只记录不执行跑一段再放行。上线主动 Agent 的最低成本路径两级过滤便宜规则先筛贵模型兜底。任何事件驱动系统都该有这道成本闸门订阅直通已开工的任务直接订阅后续消息绕过中央调度上下文当 Cache 管Inline 摘要 Spill 按需展开 引用图逐跳召回。给每条内容一个 id让模型自己决定要不要展开事务性发件箱命令在事务内入队副作用commit 后才执行用生成列算工作集把哪些是活跃的交给数据库调度循环只读活跃行Later 不计失败资源暂时不够和真的出错必须分开否则健康检查会被正常波动淹死用影响而非努力来停止官方哲学原话——局部改动做到可评审的结果就停需要设计决策的改动停在一个清晰的问题上写在最后DeepSeek 在文章结尾写了句特别清醒的话我们并没有提出全新的理论而是将计算机系统中经典的工程思想应用到了 Agent 系统的构建中。调度、缓存、存算分离、看门狗、投机执行——全是操作系统和分布式系统几十年前就打磨好的东西。他们做的事是把这些思想搬进 Agent 系统然后用一份 MIT 代码 一组带消融实验的数据摊开给你看。我的判断是Anthropic 和 OpenAI 的 subagent、handoff都是在一次用户会话内部做拆分Super-agent 的 Router 是跨会话、跨信道、跨时间常驻的。这是层级差异不是能力差异。2026 年 Agent 的竞争正在从卷模型转向卷系统。下一个跑出来的产品可能不是模型最强的那个而是把用户注意力算得最清楚的那个。最后一个问题上面那 8 条设计你的 Agent 最该先抄哪一条评论区聊聊。#DeepSeek #智能体 #Agent架构 #AI开发 #开源 #大模型 #架构解析 #系统设计 #AI编程 #开发者