10 月 31 日,DeepSeek Harness 团队在微信公众号放出《Super-agent 设计探索:迈向更自主的 Agent 系统》,同一天开源了参考实现 deepseek-ai/dsh-superagent-prototype。仓库 README 第一句就写明:这是研究原型,不是 DeepSeek 官方产品。

文章开头抛出一个观察:一个人通常只能同时跟进 3 到 5 个活跃 Session。在单会话为单位的 Agent 设计里,单任务的天花板取决于模型能力,多任务的天花板取决于人的注意力。作者的解法是把 Session 从用户面前撤走,退化成系统内部的实现细节。

双层架构:Router 与 Worker 分工

第一个设计是拆成两层。常驻的 Router 层承接所有入口的人类交互,汇总跨任务信息与决策,是全局的序点、协调点和记忆。它不直接执行具体任务,甚至可以不配备 Bash 工具。作者的解释是,Router 的任务没想象中复杂,轻量模型就够。

Worker 层负责真正干活。每个 Worker 上下文隔离、挂载完整的执行工具,专注完成单一任务;因为直接决定任务结果与代码质量,通常需要配置能力最强的模型。Worker 内部还能再创建 Subagent,对上层 Router 保持透明。用户看到的一直是同一个助手,背后是多个会话并行推进。

事件驱动:两级过滤与 Thread 直通

第二个设计是让 Agent 由环境事件驱动,而非等用户下指令,触发源包括群聊消息、邮件与日历提醒、代码评审评论、CI 结果。真实群聊噪音极大,官方用计算机系统的 Fast Path / Slow Path 思路做两级过滤:程序层按来源、群组、白名单等确定性条件先做准入,通过的候选再交给 LLM 按提示词策略判断是否行动。

同一 GitHub PR、同一 IM 话题下的连续事件构成一条 Thread。Router 用首条事件创建 Worker 后,该 Worker 订阅它,后续事件由程序直通,不再经过 Router。上下文则按缓存思路管理:Inline 内联近期信息,Spill 把超预算内容留在窗外只留引用,再由各类对象的唯一 ID 串成引用图,支撑按需多跳的链式召回。

消融实验:12.4 分钟对 29.5 分钟

官方文章的自评实验同时驱动群聊与 GitHub CI 消息流:单次实验约 300 条消息,其中约 20 条是工作请求,编码工作用一个只消耗时间的工具代替,衡量调度与协作能力;消息间隔与工作时长按 1/4 缩放,每种方案跑 5 次。

按原文给出的数字,Super-agent 的任务完成时间 p50 与 p95 分别是 12.4 分钟和 15.7 分钟。同一份消融表里,带 Subagent 工具的单 Session 方案在中性提示下 p50/p95 为 20.4/29.5 分钟,提示优先委派时为 13.8/29.0 分钟。原因写在原文里:中性提示下模型 5 次运行一次都没调用 Subagent,工作全在主 Session 里被新消息反复打断;改成优先委派后 5 次里有 4 次委派,剩下 1 次模型判断工作"很小"自己执行,形成 p95 长尾。

代价写在同一张表上

同一张表还列了另一半账。Super-agent 单次实验的读缓存 token 高于单 Session,官方正文只给了方向;第三方对同一张消融表的整理显示,Super-agent 为 23.23M,单 Session 两种提示配置分别是 6.05M 与 10.82M。去掉 Thread 直通机制后,完成时间与完整版基本一致,但 Router 需要做出的决定增加约 30%,总读缓存 token 从 23.23M 涨到 31.77M。

Router 自己还有一层批处理。官方数据是:Trigger 到达速率从每分钟约 1 条升到约 40 条时,平均 batch 大小从 1.0 升到 2.8,单次请求耗时仅从 2.5 秒增到 3.9 秒,单个决定分摊的推理时间因此从 6.4 秒降到 1.6 秒。据此官方判断,当前团队规模下一个常驻 Router 够用。

开源原型给了什么

原型仓库是 MIT 协议、TypeScript 实现,定位是单仓库部署的主动式编码智能体,监听 GitHub 事件,可接入飞书。请求进来后被记成工作项,在独立会话与目录里执行,最后回到原对话交付结果,比如一个 PR;Web 面板只列出还没人处理的事项。仓库自述的工程量指标是 4.1k star、375 fork。

设计哲学很直白:尽可能少占用人的注意力,尽可能多地交付价值。规则是:被点名或被规则允许时才动手,干活时沉默,需要人决策时才开口。免责声明同样直白:这是研究原型,大量工程由编码智能体完成,可能仍有 bug,与内部版本并不相同,文章里讨论的部分设计并未实现。

还有三件事没解决

安全是最硬的一条:Agent Loop 部署在云端、端侧只留轻量 daemon,默认云端与端侧互信;一旦云端 Agent Loop 遭入侵或提示词注入被攻破,它连着的全部端侧设备都面临被控制的风险。即使云端没被攻破,凭据进入模型上下文也存在泄露风险,还需要让智能体不接触凭据也能用凭据的机制。其余是长期记忆,以及多个隔离实例的协作边界。

所以呢

这份设计没有提出新理论,作者说得很清楚:它把计算机系统里经典的工程思想搬进了 Agent 系统。真正有意思的是那个 3 到 5 个 Session 的观察——过去两年,模型能力把单任务的门槛抹平了,瓶颈上移到了人的注意力,而这次 DeepSeek 把它当成可以用系统设计解决的问题:把会话管理、上下文同步和事件路由沉到底层,让人只做决策与验收。

不过实验是合成的、只跑 5 次,原型也明说不是产品。官方内部实例已在持续运行,参与问题复现与修复、代码审查响应,甚至参与 Harness 自身的迭代。