dsh-superagent-prototype 学习的项目地址

项目学习官方仓库

项目仓库 github.com/deepseek-ai/dsh-superagent-prototype

参考学习：

基本基础概念

Agent 能干的活越来越多了，但你的负担反而没轻多少？

来回切会话、手动派任务、挨个盯进度……

这篇文章要聊的，就是怎么把这些事从你手里接过去——从架构思路，到已经落地的能力，再到还在设想中的设计。

本文拆解的是 DeepSeek 公开的研究原型 dsh-superagent-prototype。注意：它只是个研究原型，不是正式产品，也不代表 DeepSeek 内部真正在用的实现。

双层架构

传统 Agent 架构里，一个工作区下挂着多个会话，每个会话各自跑一个任务。刚多开几个的时候很爽——效率直接拉满。

但很快瓶颈就来了：每个 Agent 跑到关键节点都会跳出来问你「这个怎么做？」「下一步往哪走？」。你刚在盯 A 的进度，B 又弹出来打断思路；你刚回复完 C，D 又卡住了。来回切换之下，同时开 3-5 个会话就差不多到顶了。

DeepSeek 推出的 Super-Agent 架构，就是冲着这个痛点来的——把你的注意力收敛到一个入口，同时接入外部消息源，让 Agent 真正能「自己跑下去」。

核心思路就一句话：把「协调」和「执行」彻底分开。

跨任务的交互、评估、分派，全归一层管；单个任务的具体执行，全归另一层管。

负责交互、评估与分派的那层，叫 Router（路由层）；负责调查、写代码和验证的那层，叫 Worker（执行层）。Worker 碰到复杂任务时，还可以再开 Subagent 往下钻。

注意：这里说的「双层」是职责划分，不是说每层只能有一个会话，也不意味着要搞无限延伸的管理层级。

打个比方：就像一个主管带一个执行团队——你只跟主管对接，主管在底下组织好几条独立的工作线跑着；遇到关键决策、卡住了、或者结果要验收的时候，才把你叫过来。

模型也可以按角色配：Router 干的是轻量判断和协调的活，完全可以用更快、更便宜的模型；Worker 才是真正写代码、做执行的，按任务难度和质量要求选模型就行。

不过有两点要注意：公开原型支持分角色配置，但不会自动帮你选好模型，得自己调；另外多会话带来的额外上下文和调用开销，也可能把总 token 成本推上去。

一句话总结双层架构的精髓：职责稳定分离——Router 管交互、评估和跨任务协调，Worker 专注干具体活。

那它和常见的 Agent Team 有什么不一样？核心差别就在职责怎么分、活怎么组织。

很多 Agent Team 的主会话是「既当运动员又当裁判」——自己既要写代码干活，又要拆任务、管子智能体，两头的负担都压在一个会话上。

Super-Agent 的做法是让 Router 彻底不碰单任务的具体实施，把这部分活全甩给 Worker。

最后补个客观说明：Router 也不是真的「永远不会被打断」——它照样要处理新事件、Worker 汇报和人工消息，也有串行排队和吞吐上限。

它解决的，是「协调被耗时的执行工作堵住」这个问题，不是让 Router 变成完全不卡的神。说白了：普通 Agent Team 只要也把职责这么拆开，一样能做出双层架构。

事件驱动

不过光有双层架构还不够——它不会自己动起来。要让系统在环境变化时自动推进工作，还得给它接上「外部感官」。

理论上，聊天、邮件、日历、监控告警……各种信息源都能接进来，由规则和模型判断哪些事件值得处理。

但要注意：当前公开原型只内置了 GitHub 和可选的飞书两个 Source；微信、QQ、邮件、日历这些都还得自己写适配，不能算这个仓库已经做好的能力。

但真实信息流哪有那么干净——大部分消息根本不需要 Agent 插手。要是每条都丢给大模型从头判断一遍，不光慢，Token 成本也扛不住。

所以得做筛选，而且是两层筛选——先靠程序硬卡一道，再交给模型精判。

第一层走确定性代码：按来源、接收范围、发送人、白名单这些条件，先把明显不合格的事件直接筛掉，又快又便宜。剩下那些需要动脑子的，再交给模型——结合规则和上下文，判断这条到底是该接单、忽略，还是直接停掉。

把外部事件转成系统能认的格式，这个转换器就叫 Source；转出来的东西，就是 Trigger（触发事件）。

Trigger 不只是群消息——GitHub Issue、PR 评论、CI 状态变了……都能当 Trigger。理论上啥事件都能加个 Source 接进来。

但有一点要拎清楚：「收到事件」不等于「获准开工」。真要动手干活，还得过 Policy 和工单授权范围这一关。

订阅和直通

Worker 把结果交上来了，但事情没完——你可能要补充要求、要返工，CI 也可能又报了个新失败。

这些后续跟进，如果每次都重新走一遍 Router 分派，不光 Router 累，之前的工作上下文也容易断片。

怎么解决？公开原型用 Subscription（订阅） 把 Ticket（工单）和 Thread（讨论线程）绑在一起，而不是把「一串消息」永久钉死在某个 Worker 身上。

一个 Thread 可以关联多个 Ticket，一个 Ticket 也可以关注多个 Thread；就算后面换了 Worker，工单关系还在。

已经在工单范围内的人工跟进消息，直接送给对应的 Worker，不用重新跑一遍 Eval。主会话照样会收到通知；但如果你的请求超出了这个工单的范围，或者属于别的工单，Worker 可以退回来，让系统重新评估路由。

说白了：直通省的是反复分派的功夫，不是把边界判断也省了。

Router 正在处理手上的活，新消息又涌进来了。每条都单独调一次模型？太浪费了。

解法就是攒一批一起算。

同一个 Thread 在一次 Eval 运行期间收到的新 Trigger，先攒着，等下一批评估的时候一起处理；主会话也会在后续推理步骤里集中消化积压的消息。

注意：不是等整个 Worker 任务全做完才处理，而是按评估批次和模型步骤一步步往前推。

实测数据很能说明问题：

· 流量低的时候（1条/分钟）：单次判断耗时 2.5s

· 流量高的时候（40条/分钟）：单次判断耗时 3.9s——只多了 1.4s

但分摊到每条消息上算总账：单条处理耗时从 6.4s 直接砍到 1.6s，效率翻了 4 倍。

说白了：多攒几条再一起判断，单次只多花一点点时间，平均到每条上便宜得多。

全双工

经典的同步 ReAct Loop 有个硬伤：Agent 发起一个耗时的工具调用，就得死等结果返回才能往下走。这段时间里，你说什么它都听不见。

（当然，这里说的是同步阻塞式的实现，不是所有 Agent 都这样。）

那「全双工」到底是什么？一句话：后台任务跑着的同时，前台照样能处理你的新输入；等后台干完了，结果再作为新事件送回来。

还是拿「让助手烧水」举例子，好懂。

水壶开始烧水，就相当于 Agent 在后台跑一个测试任务：

• 水还没烧开，你突然想起什么补充一句——Agent 当场就能接住，不用等水开。

• 发现方向不对，你喊停它就能停，不会闷头烧到底。

• 等水真开了（测试跑完了），结果再递回来给你。

把烧水换成你实际用的场景——后台跑一个测试任务，逻辑一模一样：

• 测试还没跑完，你突然补充个要求：系统会把你的消息塞进会话，等当前这步推理做完就响应，不用等整套测试结束。

• 发现方向不对，你喊停：系统会去请求取消正在跑的工作。但注意——取消得看当前步骤和工具本身支不支持；已经发出去的外部操作，也不会自动撤销。

• 测试跑完了：结果作为新消息自动弹回来，Agent 再判断接下来该干嘛，然后报告给你。

三个最容易搞混的概念，放一起对比一下就清楚了：

最后说下公开原型的实际情况：它是靠后台作业 + 消息注入来实现全双工体验的。Worker 的前台 shell 命令默认跑 5 秒就自动转后台，新输入会等当前推理步骤结束后再处理。

所以别神化它：全双工不是完全不排队，也不保证你说句话它就秒回——它只是把「必须等任务全做完才能说话」这个死限制拆掉了。

存算分离-未明确

传统 Agent 所有东西都绑在你这一台机器上：思考循环跑在本地、会话记录存在本地、运行环境也在本地。机器一关，整个 Agent 直接停摆——Trigger 消息收不到，任务全断。

现在 Super-Agent 把这层拆开了：

• 思考循环 + 会话记录 → 搬上云端，存在云数据库里

• 运行环境 → 留在你本地，不动

为什么不把环境也搬上去？因为本地环境太复杂了——里面有你的私人密钥、内网服务、还没提交的代码变动，迁移成本极高。所以每台机器上只跑一个很轻的小程序，负责把本地环境「接」上云端。

这就是存算分离：脑子和记忆在云上，手在你本地。

云端的 Agent 一直在线接活。就算你本地电脑关机了，不影响它在别的环境里继续干活；只有那些必须用你特定电脑才能做的任务，才会先挂着，等你开机上线了自动接着跑。

Watchdog-未明确

整套系统都在云上跑，Worker 数量一多、跑的时间一长，难免出状况：有的陷入死循环出不来，有的跑着跑着方向就偏了。

怎么办？在整个系统外面，放一个独立的 Watchdog Agent。它被定时唤醒，一轮一轮地巡检：用模型去检查每个 Worker 是不是有实质性进展、方向有没有跑偏，发现问题就及时介入修复。

普通 Agent 跑偏了怎么办？只能你自己盯着、手动拉回来。开多了会话根本顾不过来，等你发现的时候可能已经跑偏十万八千里了。

有了 Watchdog 就不一样——它帮你定期巡逻，自动发现问题、自动调整，不用你当那个盯梢的人。

总结

讲了这么多机制，现在可以拼出 Super-Agent 的完整图景了。

Super-Agent 的本质，就是把一群需要你分别盯着的 AI，组织成一个能统一接事、自动分工、持续跟进的「AI 管家」。你只需要做两件事：关键决策，以及结果验收。

它有四个核心特性：

1. 连续：你始终感觉在跟同一个助手对话。背后 Router 帮你协调多个 Worker，不用你自己切会话、来回传话。

2. 主动：群聊、GitHub、测试系统有新消息，系统自动按规则筛一遍，把相关信息送给对应的 Worker，任务自己往前推。

3. 高效：多个 Worker 并行干活；加上全双工，跑任务的时候你照样能补充要求、随时插话。

4. 持久：云端运行 + 多机连接，系统 7×24 小时在线，不绑死在你某一台电脑、某一个聊天窗口上。

最终效果就是——你不用再花精力盯进度、协调各个 AI，把注意力真正放在两件事上：决定要做什么，以及检查做得对不对。

最后补一句：目前公开的还是研究原型，上面说的这些设想，有些还没完全落地。

▼
mermaid
复制代码
flowchart LR
  S[Source] -->|Trigger| T[Thread]
  T -->|batch| E[Eval]
  T -->|Subscription fan-out| K[Ticket]
  E -->|accept with Mandate / stop| K
  E -->|ignore / unavailable| X[recorded]
  P[Policy change] -->|notice| K
  K -->|Assignment| W[Executor]
  K -->|Channel| S

使用体验

1. Token 消耗的隐藏巨兽

任务启动流程表面上很轻：消息源进来 → 生成 Trigger → 分发给订阅了对应 Ticket 的 Worker，没有匹配项就交给 Eval 评估，决定是创建工单还是直接忽略。

但真正跑起来才发现，Token 的黑洞藏在 Thread 与 Ticket 的多对多关系里——一个 Thread 可以挂多个 Ticket，一个 Ticket 又关联多条 Thread。一旦任务被中止后重启，主 Router 和所有分支 Worker 都会被唤醒一遍，各自核对"我这条线是不是完成了"。大量调用花在了状态对齐上，而不是业务推进，这部分开销完全是结构性浪费。

2. 轻量得意外：这就是下一代 Agent 的样子

抛开 Token 问题不谈，整体框架的设计相当克制：没有厚重的中间件，没有冗余的抽象层，每个组件都待在它该在的位置。跑通之后确实能感受到官方所说的"下一代 Agent 概念模型"的味道。

3. 毕业设计就选它了**-前言**

软件、论文、PPT 三件套，我打算整套用这个框架来搭。Token 开销直接走公司账面——也算是给它一次正式的实战检验。

4. 一个人驱动一个项目，太累了**-后话**

算了一个周末，结论很明确：单靠自己拍脑袋提需求，根本喂不饱这个框架。它更需要一个外部消息收集器，像 Magpie 那样从 Twitter、GitHub Issues 里自动捞用户反馈，作为源源不断的 Trigger 来源。

但这一切的前提是项目本身得有日活——不然连"被收集"的内容都没有。我的项目现阶段还做不到，那就老老实实干，自己一点点把需求磨出来吧。

（注：部分内容由豆包工作 AI 生成）