背景：瓶颈从执行移到了注意力
过去一年，编码智能体一类单任务形态已经证明模型能借助工具解决复杂问题，人在底层执行上的介入越来越少，角色上移到决策与验收。团队据此判断：当执行不再是瓶颈，剩下的瓶颈是人的注意力——一个人同时能盯住几条会话、能在多少个信道之间来回切换，直接决定了这套系统一天能推进多少事。
现有智能体普遍以单一 Session 为单位。这个单位带来三个具体制约：同步阻塞让一个耗时工具调用卡住整条会话；上下文混杂让多个不相关任务挤在同一个窗口里互相稀释；设备休眠或离线即整体停摆。简单地把 Session 数量往上加并不能解决，反而会让上下文割裂、交互混乱。
因此团队提出 Super-agent：一个跨会话保持上下文、能并行推进多任务且互不干扰的连续实体。它具备四个基础特征——连续（用户感觉始终只存在一个智能体，不必关心某段信息在哪个 Session 里）、高效（不必等上一条命令完成就能接受下一条）、主动（持续观察环境事件并主动推进值得处理的事项，不需要介入时保持安静）、持久（始终在线，长期运行遇到异常能自动恢复）。文章给出的两个内部实例很具体：同一个任务在 IM 群聊与 GitHub Pull Request 评审之间连续推进；持续关注公共群聊，在无人 @ 的情况下主动识别缺陷并提交修复 Pull Request。
文章反复强调一句话：相似的设计约束会导出相似的架构选择。也就是说，无论目标是个人助手还是软件开发场景的智能体，只要要求「持续在线、并发响应环境事件」，底层很可能收敛到相近的架构。这让本文的拆解价值超出了单一产品——它更像一份约束推导记录。
五个模块与仓库的真实形态
支撑上述四个特征的基本框架由五个模块构成。团队给出的对应关系是：通过双层架构兼顾连续交互与高效并发；通过事件驱动实现主动响应；通过面向人的交互在交互过程中同时做到连续与高效；通过计算、状态与环境分离实现跨设备持久在线；通过 Watchdog 实现异常自愈。
| 模块 | 解决的特征 | 核心机制 | 借用的经典思想 |
|---|---|---|---|
| 双层架构 | 连续 + 高效 | 常驻 Router 层分派，上下文隔离的 Worker 层并发执行 | 调度分层、读写分离 |
| 事件驱动 | 主动 | 环境半结构化事件作为 Trigger，两级过滤后路由 | Fast Path / Slow Path |
| 异步多信道交互 | 连续 + 高效 | start 与 stop 构成异步 ReAct Loop；按信道定制输出规范 | 全双工通信 |
| 存算分离 | 持久 | 计算与会话状态分离，再与重状态执行环境解耦 | 存算分离、无状态服务 |
| 外部 Watchdog | 持久 | 主系统之外的独立控制回路，定时消息驱动 | 看门狗、Control Loop |
需要把仓库形态与文章区分开。GitHub 上的 dsh-superagent-prototype 于 2026 年 10 月 31 日以单个提交创建，README 首句即为「Research prototype for reference only, not an official DeepSeek product」，并说明代码源自团队日常开发、相当一部分工程由编码智能体完成，可能存在缺陷、风格与工程实践未必一致。仓库以 MIT 许可发布，包含 docs、examples、locale、prompts、scripts、skills、src、tests 八个目录，文档从 000 Philosophy 到 008 Cookbook 共九篇编号文档。
README 还给出了两处关键限定：其一，为便于公开发布做过适配，因此与内部版本、与文章《Exploring Super-agent Design: Towards a More Autonomous Agent System》所描述的实现并不完全相同；其二，文章讨论的若干设计属于未来发展方向，并未在该原型中实现。这条限定很重要——读者不能把文章里的五模块当成已经交付的功能清单。
从 README 看，原型的落地形态比文章收敛得多：它是一个面向单个 GitHub 仓库的主动式编码智能体，以 bundle 形式打包给 DeepSeek Harness，监听 GitHub 并可选监听飞书；当被允许的人提出工作请求时，它开一个工作项，在自己的智能体会话与目录中处理，然后在原始会话中回复（例如提交一个 Pull Request）；另有一个 Web 面板显示哪些事需要人介入。README 里那句产品哲学也值得记下：尽量少占用人的注意力，尽量多交付价值——能为一个团队行动的智能体，也能浪费一个团队的注意力，因此它只在被要求时、或团队写下的规则允许时才行动，只在有人必须决策或能使用结果时才发声。
双层架构：一层分派，一层干活
跨信道连续交互与多任务高效并发之间存在根本权衡。全部交给一个 Session，上下文最连续，但单个 ReAct Loop 串行、吞吐低、细节混杂；全部开独立 Session，吞吐最高，但缺全局上下文、结果割裂、交互混乱。团队的解法是把「维护全局连续性」与「高并发执行」拆成两层，并主张 Session 应当成为系统实现细节，而不是用户的认知负担。
Router 层：只分派不干活
Router 层是常驻的全局路由层，承接所有入口的人类交互，跨任务的信息与决策都在这里汇总，由它充当全局序点、协调点和记忆。为避免这个全局节点成为瓶颈，Router 层在设计上不直接执行具体任务，只负责人类交互与任务分派，甚至可以不配备 Bash 工具。
文章特别区分了它与常见 Agent Team 的差异：Agent Team 主要用于单个复杂任务内部的步骤拆解与角色协作，子步骤耦合较紧，Team Lead 往往需要深入理解任务细节、规划子任务并高频协调，自身承担很重的推理负载；而 Router 层只处理任务之间的高层关联与分派，不介入单任务内部拆解。团队实践显示 Router 层的任务常常没有想象中复杂，使用较轻量模型往往就能兼顾速度与效果。
Worker 层：只干活不抢话
Worker 层由负责具体执行的会话组成，各 Worker 彼此上下文隔离，挂载完整执行工具，在独立上下文中专注完成单一任务。由于 Worker Session 直接决定任务结果与代码质量，通常需要配置能力较强的模型。
Worker 不与人类直接交互——它的推理过程与工具调用不直接输出到外部信道，而是向 Router 层汇报状态，由 Router 层统一回复用户。这一条同时保住了并发度与交付质量，也避免了多个会话各自回复带来的混乱。
冲突处理是这一层最有意思的设计。多任务并发时，同层 Worker 之间通常不需要直接通信；冲突往往出现在同一个 Pull Request 这类共享工作环境里。只要这些 Worker 都订阅了对应 Thread，就会收到相同事件通知，从而有机会自行发现并解决冲突，少数跨任务协同才由 Router 层中转。这是一个用「共享订阅」代替「点对点协调」的取舍。
两层内部都不必局限于单个会话：Worker 内部可以再创建 Subagent，甚至本身就是一个 Agent Team，这些对上层 Router 保持透明。当规模继续扩大、单个 Router 会话确实不够用时，Router 层内部也可设计为多层过滤结构或水平切分为多个会话，但切分粒度越细，分片之间的记忆与上下文连续性越低。文章直言：在全局记忆问题被解决之前，这个权衡始终存在。
事件驱动：程序快筛，模型慢判
要让智能体具备主动性，先要改变系统驱动方式。驱动它的主要输入不再是人类在 Session 中逐条键入的提示词，而是环境中的半结构化事件——群聊消息、邮件与日程提醒、代码审查评论、CI 运行结果，这些被统称为 Trigger。
接入真实群聊与代码平台后，环境事件流呈现显著的「高噪音、低触发率」特征，绝大多数日常消息并不需要智能体介入。如果对每个事件都调用大模型从头判断，延迟与算力成本都难以承受。团队借用了计算机系统的 Fast Path / Slow Path 思想：大模型推理是灵活但高成本的 Slow Path；把已经明确且稳定的高频判断固化为确定性代码，则构成低延迟、低成本的 Fast Path。
| 层级 | 手段 | 判定对象 | 特点 |
|---|---|---|---|
| 程序层策略（Fast Path） | 确定性代码 | 事件来源、群组范围、用户或机器人白名单 | 直接快速准入，可在调用模型前滤除大部分无关消息 |
| 语义层策略（Slow Path） | 大模型按提示词策略判断 | 通过准入的候选事件是否需要行动 | 同时作为面向人的自然语言扩展点，可随时开关或新增策略 |
把语义层设计成「自然语言扩展点」是一个实用选择：策略的调整不必改代码，改提示词即可。代价是策略本身变成了一种需要版本管理与回归测试的配置，文章未讨论这部分工程。
Thread 与订阅直通：后续事件不再绕 Router
如果已分配任务的每个后续事件仍要经由 Router 层转发，全局节点依然会承受大量负载。因此 Fast / Slow Path 同样适用于事件路由：Router 层只负责新任务冷启动与跨任务协调，已确定归属关系的后续事件由程序直接发往对应 Worker 会话。
这里的关键抽象是 Thread。同一个 GitHub PR、同一个 IM 话题或同一封往来邮件串下的连续事件，构成一条 Thread。Router 层根据某个 Thread 的初始事件创建 Worker Session 后，该 Worker 会直接订阅对应 Thread，于是事件路由分成两条路径：
- 已订阅，Fast Path：同一 Thread 下的后续事件由程序直通已订阅 Worker，无需 Router 层再次调用工具转发。若新事件超出当前任务范围，Worker 也可取消订阅或交回 Router 层重新分派。
- 未订阅，Slow Path：Router 层仍可观测所有事件以掌握全局状态，但只负责判断和分派尚未被订阅的新事件。
Thread 与 Worker 之间的订阅是多对多关系：一个 Worker 可同时订阅多个相关 Thread，同一个 Thread 也可被多个 Worker 订阅。当多个 Worker 在同一个工作环境或讨论中发生交集时，该 Thread 下的新事件会同时直通给所有订阅它的 Worker，使它们无需点对点通信就能获知彼此操作。输出侧仍然收敛：Worker 把关键结论汇报给 Router 层，由 Router 统一向用户回复并同步全局记忆。
Inline 与 Spill：把上下文窗口当缓存管
事件经过过滤与路由进入目标 Session 后，下一个问题是向模型上下文窗口注入多少信息。系统输入从有限的人类提示词转向环境持续产生的半结构化事件，注入过多会挤占窗口、稀释注意力，注入过少又迫使模型反复调用工具读取、增加执行步数。文章的措辞很直接：浪费上下文窗口，就是浪费模型的智能。
解法是把有限的上下文窗口当作 Cache 管理，借用编译优化里的两个基本操作：
- Inline（内联）：把近期很可能用到的信息直接放进当前上下文窗口，省去额外的工具调用往返。
- Spill（溢出）：把超出窗口预算或低频使用的完整信息留在窗口之外，只在窗口内保留引用或摘要，供模型按需读取。
结合局部性思想，具体做法分三步递进：
- 从最少信息开始：最初只提供当前对象 ID 与内容摘要。
- 利用局部性逐步 Inline 关联信息：先附上紧密关联对象 ID，再附带时空相邻内容——内容前 50 字、IM 消息前后相邻消息与所回复消息、代码评论所在评审讨论中的相邻评论。
- 超出上限则 Spill：对无法全部内联的长内容设定较小长度上限，截断超出部分并保留续读入口，模型需要完整内容时再调用工具读取。
这套做法把「上下文工程」从一门经验手艺变成了一个可描述的缓存替换策略：什么进窗口、什么留外面、什么时候换入换出，都有明确规则。对工程团队来说，这比一句「精简提示词」可操作得多。
链式召回：旧任务靠 ID 顺藤摸瓜
把 Inline 与 Spill 一致地应用到系统中各类对象后，就得到一种按需展开的多跳检索机制，即链式召回。系统为 Trigger、Thread 和 Worker Session 等对象赋予各不相同的 ID，并在注入时内联紧密关联对象 ID，使这些对象在底层构成一张引用图。由于每一次调用工具召回的对象本身同样遵循 Inline 与 Spill，其返回结果中又会内联下一跳关联对象的摘要与 ID，模型便可以从当前事件出发，顺着引用关系逐步按需召回上下文。
文章给的例子是：从一条当前消息读取所在 Thread，再从 Thread 内联的 ID 追踪到相关 Worker Session，进而找到该 Worker 关联的另一个代码评审 Thread。这种机制缓解了 Router 层在长程运行中丢失先前信息的问题——Router 既不能把所有任务全量历史都放进自己的窗口，又需要在用户跨信道提起某个旧任务时把上下文找回来。
要注意它的代价：每一次跳转都是一次工具调用，因此召回深度与步数成本正相关。文章没有给出链式召回的命中率、平均跳数或失败模式，这部分属于未披露项。
投机执行：先干着，有用再交付
借鉴计算机系统中的投机执行，智能体可以在还不确定结果是否会被采用时，根据环境信号在后台提前尝试，用额外的后台算力换取更少的人类等待与介入。结果有价值就交付，没有价值就丢弃。
两个例子。个人助手场景：收到会议邀约邮件或待办消息时，先在后台核对日程冲突、搜集背景资料并备好回复草稿，待用户过目后直接确认发出。研发协作场景：团队在 DeepSeek Harness 内部用户群中配置了一条「静默复现并修复」策略——群里有人反馈问题或讨论改动方案时，智能体先在后台尝试复现并寻找修复方案，只有在确认问题且找到简单修复方案后才把结果交付给用户，否则全程保持安静。
这条策略把「主动性」约束成了一个有明确交付条件的动作，而不是无限发散的自主行为。它同时回答了主动式智能体最容易招致的质疑：会不会制造噪音。判断标准被写成了策略——确认问题、方案简单，两条都满足才出声。
全双工与多信道：后台不卡前台
经典 ReAct Loop 中，模型发起一次同步的 run 工具调用后循环会阻塞，直到工具执行完毕返回最终结果，期间会话无法响应任何新输入。团队把耗时命令与子任务工具调用改为异步的 start 与 stop，构成异步 ReAct Loop：模型调用 start 后立即收到「已启动」返回，循环不再等待；后台工具执行完成后，系统把最终结果作为一条新事件消息投递进会话；模型也可根据上下文调用 stop 主动终止执行过久的后台命令。
这样一来前台对话响应与后台任务执行解耦，新输入在当前推理步结束后即被处理。文章透露：这一异步任务机制已在 DeepSeek Harness 中实现，但尚未默认开启。这是一处值得留意的状态标注——机制存在与机制默认可用是两回事。
多信道交互方面，不同工作信道的信息密度与使用习惯不同，输出需要匹配。双层架构已经解决了一部分：具体任务中冗长的推理过程与密集的工具调用被隔离在 Worker Session 内部，不直接输出到外部信道。在此基础上还需按信道定制交互规范：
- IM 等即时通讯信道：侧重低打扰的轻量沟通，像人类同事一样只在需要决策或验收时发送通知，只问直接问题、给简短结论。团队验证过一条简单有效的硬性规定：单次回复不超过 100 词。
- GitHub、邮件与文档等异步信道：侧重结构化、高信息密度的异步交付，例如创建或更新 Pull Request 时按项目规范撰写完整的问题背景、改动说明与验证结果。
存算分离：与脑手分离的异同
现有本地智能体默认把推进 Agent Loop 的计算、需要持久保存的会话状态、以及代码仓库与本地工具链等执行环境绑定在同一台设备上。设备一旦休眠或离线，智能体就停止运行，也无法访问其他设备上的环境。
团队主张分两步解耦。先是把推进 Agent Loop 的计算与持久化会话状态分离，让智能体摆脱单机生命周期限制、实现云端持久在线；再把云端 Agent Loop 与重状态执行环境解耦，让真实工作环境留在原地并支持跨设备访问。
文章指出这与 Anthropic 提出的「脑手分离」一致：让 harness 保持无状态，把会话日志存放在 harness 之外，通过统一接口按需接入执行环境。差异在场景——Anthropic 那篇文章描述的是托管服务，主要讨论按需创建的沙箱和客户 VPC 内资源；这里首先要接入的是用户日常使用、可能间歇在线的个人机器，上面有未提交修改和本地凭据。因此这套设计既支持 BYOM（把用户日常的开发机或个人电脑接入云端智能体），也支持接入云端托管机器或按需创建的计算环境。
由此一个智能体不再受限于单台机器，可以在不同执行设备之间切换，甚至支持间歇在线设备——用户某台个人设备重新上线后，由云端智能体自动触发并完成需要在该设备上执行的任务。
托管沙箱与 BYOM 的风险模型完全不同。前者的数据边界由服务商划定，后者的边界包含用户本地未提交修改与凭据。文章在开放问题里也承认：云端智能体接入端侧凭据存在被入侵和提示词注入的风险，还需让智能体不接触凭据本身也能使用凭据。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
外部 Watchdog：盯进程，也盯进展
持久在线的分布式系统很难仅靠主系统内部逻辑保证长期可靠运行，需要在主系统之外引入独立外部控制回路。在智能体系统里，仅靠传统进程存活探测或监控脚本还不够——许多异常并非进程崩溃，而是模型在执行中陷入无效循环或偏离目标。因此长期运行的智能体系统不仅需要监控基础设施存活，还需要监控任务本身的进展。
团队的做法是在主系统外部配置一个独立的 Watchdog Session，用定时消息驱动它，构成外部 Control Loop。Watchdog 除了处理接口报错、状态恢复失败等基础设施故障，还会由模型判断各 Worker 是否有实质进展、方向是否偏离整体目标；发现异常时及时介入修复，遇到外部偶发故障则持续复查直至恢复正常。
由于 Watchdog 本身也是一个具备完整工具能力的 Agent Session，维护者可以用自然语言向它询问故障原因，也可以让它在线修正主系统行为，例如增删提示词、调整触发规则。最后这一点是双刃剑：能在线修正意味着响应快，也意味着一个有权修改主系统的组件本身需要有变更记录与回滚手段，文章未讨论这部分。
三组实验读数与本文五条推算
实验设置需要先说清楚。团队用群聊和 GitHub CI 消息流驱动四种方案，单次约 300 条消息、其中约 20 条工作请求，编码工作用只耗时工具代替，每种方案跑 5 次。端到端结果如下：
| 方案 | p50 完成时间 | p95 完成时间 | 读缓存 token | 备注 |
|---|---|---|---|---|
| Super-agent | 12.4 分钟 | 15.7 分钟 | 较高（多会话） | 本文基准组 |
| 带 Subagent 工具的单 Session，中性提示 | 未单独披露 | 29.5 分钟 | 较低 | 5 次运行一次都没调用 Subagent，全在主 Session 里干，不断被新消息打断 |
| 带 Subagent 工具的单 Session，优先委派提示 | 未单独披露 | 未单独披露 | 较低 | 5 次中有 4 次委派，仍慢于 Super-agent；剩余 1 次模型判断工作「很小」自己执行，形成长尾 |
| Super-agent 去掉订阅直通 | 与完整版基本一致 | 与完整版基本一致 | 2323 万 → 3177 万 | Router 决定数增加约 30% |
Router 层批处理单独压测：Router 调真实模型、Worker 用 Mock 模型，Trigger 到达速率从每分钟约 1 条升至约 40 条。结果平均 batch 从 1.0 升至 2.8，单次请求耗时仅从 2.5 秒增至 3.9 秒，单个决定分摊的推理时间从 6.4 秒降至 1.6 秒。
| 指标 | 低速率 | 高速率 | 变化 |
|---|---|---|---|
| Trigger 到达速率 | 约 1 条 / 分钟 | 约 40 条 / 分钟 | 约 40 倍 |
| 平均 batch 大小 | 1.0 | 2.8 | +180% |
| 单次请求耗时 | 2.5 秒 | 3.9 秒 | +56% |
| 单个决定分摊推理时间 | 6.4 秒 | 1.6 秒 | 约 −75% |
基于以上读数，本文给出五条原文没有直接写出的推算。
推算一：p95 的改善幅度大于中位数的直觉
Super-agent 的 p50 与 p95 分别为 12.4 与 15.7 分钟，分位间距 3.3 分钟，相当于 p50 的约 26.6%。而带 Subagent 工具的单 Session 在中性提示下 p95 达 29.5 分钟。以 p95 对 p95 计，Super-agent 快约 1.88 倍（29.5 除以 15.7）。这里真正值钱的不是中位数，而是尾部——文章自己也点出，单 Session 方案受提示词影响极大，5 次里一次都没调用 Subagent，被新消息不断打断。也就是说，双层架构买到的主要收益是尾部的稳定性，而不是平均速度。
推算二：直通省下的 token 有两种算法，结果不同
去掉直通后，读缓存 token 从 2323 万增至 3177 万。以增量除以原值，增幅约 36.8%（文章表述为约 37%）；以增量除以新值，则相当于完整版比无直通版少用约 26.9%（854 万除以 3177 万）。两个数字都对，但含义不同：前者说「去掉直通要多花约 37%」，后者说「直通省下了约 27%」。对外沟通时混用这两个口径会造成明显误解，本文建议统一采用后者（节省比例）或同时标注。
推算三：6.4 秒与 2.5 秒不相等，说明分摊时间含排队
表中有两处值得停下来看：低速率下平均 batch 为 1.0、单次请求耗时 2.5 秒，而对应的「单个决定分摊推理时间」是 6.4 秒，不是 2.5 秒。若分摊时间纯粹由请求耗时除以 batch 得到，batch 为 1 时两者应当相等。差出的约 3.9 秒只能来自排队等待或调度开销。反过来验算高速率：3.9 秒除以 2.8 约等于 1.39 秒，与披露的 1.6 秒同量级，说明在最高速率下排队几乎被批处理吸收干净。这组数字最重要的含义是：批处理真正压缩的是排队，不是推理本身。
推算四：噪音比约为 15 比 1，这正是两级过滤存在的理由
实验用单次约 300 条消息、其中约 20 条工作请求。工作请求占比约 6.7%，即约每 15 条环境事件才有一条真正需要处理。这个比例解释了为什么必须把程序层快筛放在模型层慢判之前——如果 20 条请求要消耗 300 次模型判断，成本结构就完全不成立。同时也提示了一个迁移风险：真实环境中这个比例会随群聊活跃度大幅波动，文章只用了单一合成负载。
推算五：原型与文章之间存在明确的落差
文章列了五个模块，README 却说部分设计属于未来方向、未在原型中实现，且原型只面向单个 GitHub 仓库、可选监听飞书。把两者对照可以推断：五模块是一份架构主张，原型是一份 proofs of concept，二者之间至少隔着多信道接入、存算分离部署与 Watchdog 的完整实现三段距离。任何打算照着文章自建的团队，都应该先从 README 的 docs 006 Deployment 与 008 Cookbook 入手核对已实现范围，而不是从文章入手。
四道开放问题与原型的边界
文章列出四个尚未解决的问题，措辞相当坦率。
- 双层架构如何扩展：单 Router 承载超限后何时切分、粒度如何、Worker 之间何时直接通信，均无定论；跨月长程记忆也是瓶颈。
- 脱离 Session 后如何协作：聊天窗口未必是最终形态，交互可更多发生在 GitHub 等领域界面；还需支持用户中途介入、接管与实时协同。
- 组织扩大后如何划分上下文边界：多个隔离实例之间的 A2A 通信与协作待探索。
- 安全与隐私：云端智能体接入端侧凭据存在被入侵与提示词注入风险，还需让智能体不接触凭据本身也能使用凭据。
除此之外，本文认为还有三项属于需要补齐但未披露的信息：其一，实验只用合成负载与简化环境，编码工作由只耗时工具代替，真实编码任务的完成质量未被评估；其二，多会话带来的 token 成本增加没有给出绝对值，只给了相对比例，无法折算成单位任务的美元成本；其三，Watchdog 的误报率与介入成功率没有读数。以上各项目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
冷静判断：它改变了什么，没改变什么
把这套设计放进本栏目已经拆过的坐标里看，位置会更清楚。AWS 与伯克利 Hydro 项目的 Infinity 运行时（见本栏目 R-TECH-49）解决的是同一个「等待」问题，但路径相反：Infinity 把每次工具调用当成无栈协程的挂起点，运行时保存会话历史后丢掉全部内存状态，由任意进程接手恢复；Super-agent 则保留一个常驻 Router，把并发拆到多个隔离 Worker 上。前者优化的是资源占用与调度粒度，后者优化的是上下文连续性与人的交互体验。两条路不是替代关系，前者更像基础设施层，后者更像应用架构层。
它真正改变的东西有三点。其一，把「上下文工程」从经验变成了可描述的缓存策略（Inline 与 Spill 加链式召回），这是可迁移的方法论，与具体产品无关。其二，把「主动性」约束成了有交付条件的动作（投机执行加静默策略），回应了主动式智能体的噪音质疑。其三，明确提出了「监控任务进展而不只是监控进程存活」这一条——Watchdog 由模型判断 Worker 是否有实质进展，这是智能体运维与传统服务运维的分界线。
它没有改变的东西同样清楚。模型能力本身没有被提升，多会话换来的是更多 token 消耗；实验在简化环境下完成，只覆盖调度与路由机制，未评估交付质量；Scope 内的安全模型（BYOM 与端侧凭据）被列为开放问题而非已解决问题。对多数团队来说，五模块里最容易先落地、也最不需要等待的是两级事件过滤与 Inline / Spill 上下文管理——这两条不依赖任何新基础设施，今天就能在现有智能体上试。
最后重复一遍边界：dsh-superagent-prototype 是 MIT 许可的研究原型，README 明确声明仅作参考、非 DeepSeek 正式产品，可能存在缺陷，且不等同于文章描述的实现。把它当成一份架构参考来读是合适的，当成一份可用产品来评估则超出了它自己声明的范围。