10 月 31 日晚，DeepSeek Harness 团队发布技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，并在 GitHub 以 MIT 协议开源了原型 dsh-superagent-prototype。

这不是一个新产品，而是一份架构思路。核心判断只有一句：模型能力继续提升后，Agent 的瓶颈不再是单任务做得好不好，而是人的注意力。

为什么现有 Agent 撑不住

主流 Agent 以单个 Session 为基本单位。用户并行推进多项工作时，必须手动切换、自己记住每个 Session 的上下文。DeepSeek 团队观察到一个经验值：一个人通常只能同时跟进 3 到 5 个活跃 Session。

于是形成一个结构性上限——单任务的上限取决于模型能力，多任务的上限取决于人的注意力。

简单扩展也不行：多开会话，同步阻塞、上下文割裂、设备离线即停。DeepSeek 给 Super-agent 定了四个必须同时成立的特征：

• 连续：在 IM、GitHub 评论等不同渠道和同一个 Agent 接着聊，不用想"某个 Session 里是不是有那条信息"
• 高效：并行推进多个复杂任务且互不干扰，上一条命令没跑完也能接下一条
• 主动：持续观察环境事件，自己推进值得做的事，不需要时保持安静
• 持久：始终在线，异常时自己恢复

单个 ReAct Loop 撑不起这四条。所以 DeepSeek 的结论是：Agent 系统遇到的问题，和操作系统几十年解决的问题高度相似，那就把经典设计思想搬过来。

五大模块

一、双层架构：Router 只分派不干活，Worker 只干活不抢话

维护全局连续性和高并发执行，本质是一对矛盾。全交给一个 Session，上下文最连续但吞吐最低；全开独立 Session，吞吐最高但结果割裂。

解法是拆两层：

Router 层常驻，承接所有入口的人类交互与全局协调，负责跨任务信息汇总、任务分派、对外回复。关键设计约束是它不直接执行具体任务，甚至可以不给它配 Bash 工具。团队实践发现 Router 层任务往往没那么复杂，轻量模型就够。

Router 层最容易成为吞吐瓶颈——但实测它没有想象中脆弱，因为上一轮推理期间到达的事件会积压下来，在下一轮一并处理，形成天然批处理。Router 每步是"长输入、短输出"，把多条 Trigger 合并进一次 LLM 调用，Prefill 阶段并行计算，单次请求耗时增长远慢于批处理大小。积压越多，单个决定分摊的推理时间越低。

Worker 层由上下文隔离的执行会话组成，挂载完整工具，配最强模型，但不直接与人类交互——推理过程和工具调用不外泄到外部信道，只向 Router 汇报状态。多个 Worker 在同一个 PR 等共享环境中冲突时，不靠点对点通信，而是都订阅同一 Thread、各自看到相同事件、自行发现并解决冲突。

二、事件驱动：环境事件才是输入

驱动 Agent 的输入不再是人类逐条敲的提示词，而是群聊消息、邮件与日程提醒、代码审查评论、CI 结果——统称 Trigger。

真实环境是"高噪音、低触发率"，对每条消息都调大模型判断，延迟和成本都受不了。于是借 Fast Path / Slow Path 思路做两级过滤：程序层按来源、群组范围、用户/机器人白名单做确定性快筛；语义层把候选事件交给 LLM 判断，同时作为面向人类扩展策略的自然语言入口。

路由同样分快慢：已订阅的后续事件由程序直通对应 Worker，不经 Router 转发；只有新任务冷启动和跨任务协调才走 Router。Thread 与 Worker 是多对多订阅关系。

三、上下文即 Cache：Inline & Spill

输入从有限提示词变成环境持续产生的半结构化事件后，注入多少信息成了核心问题。文章有句话很直白：浪费上下文窗口，就是浪费模型的智能。

做法借鉴编译器优化：Inline 把近期很可能用到的信息直接内联进窗口，省掉工具调用往返；Spill 把超出预算或低频内容留在窗口外，只保留引用或摘要供按需读取。配合链式召回，从"只给 ID 和摘要"开始，按局部性逐步内联。

四、投机执行

收到会议邀约，先查日程冲突、备好回复草稿——按环境信号在后台提前动手，等人确认时结果已经在了。

五、存算分离 + 外部 Watchdog

计算与状态放云端，执行环境留在用户自己电脑上（BYOM，Bring Your Own Machine），解决"设备离线即停"。另有一个独立的 Watchdog 会话，专门盯 Worker 有没有实质进展、方向有没有跑偏。

Watchdog 是独立进程而非 Agent 自我检查，这点值得注意——自我监督在长程任务里不可靠，这是被反复验证过的结论。

实验数据

每次约 300 条消息、其中约 20 条工作请求，每种方案跑 5 次：

去掉订阅直通后，Router 决定数增加约 30%，读缓存 token 从 2323 万涨到 3177 万。

结论是双向的：多任务更快更稳，Router 靠直通省开销、靠批处理扛突发；但代价是用更多 token 换时间和稳定性。 而且实验基于合成负载与简化环境，只评估调度与协作，不衡量单任务执行能力，不是产品结论。

值得关注的原因

第一，它把 Agent 竞争从"模型多聪明"拉到"系统多会调度"。 2026 年 harness 层的创新密度已经超过模型层：分支搜索、场景自适应训练、GitHarness 降 token、agent 团队编排，现在是"用操作系统原理重写 Agent 运行时"。这类工作的共同点是——不换模型，只换骨架，就能拿到数倍收益。

第二，开源姿态很坦诚，反而增加可信度。 README 写得很清楚：这是研究原型，不是正式产品；大量工程由编程 Agent 完成；公开版和内部版、和文章描述的实现都不完全一样；文中有些设计是未来方向，原型里还没做。文章末尾也列了没解决的问题：Router 层怎么随任务规模扩展、跨月长程记忆、Agent 间 A2A 通信，以及云端 Agent 接进本地设备后的提示词注入与凭据泄露风险。

第三，内部的 Agent 已经在跑真实的活。 团队成员的群里反馈软件问题，即使没人 @ 它，它也能识别潜在缺陷，在后台尝试复现并提交修复 PR。它同时在参与 DeepSeek Harness 自身的迭代——Agent 写 Agent 框架这件事，从演示进入了日常。

对我们意味着什么

如果注意力真的是新瓶颈，那企业评估 Agent 的指标就该改：不再是"单次对话多准"，而是"能替人省下多少次切换"。

落地路径也可以更务实：先把客服邮件、异常告警、CI 失败归因这类"事件触发、结果明确、需要人拍板时再开口"的重复事务交出去，而不是一上来就让 Agent 做端到端业务决策。

一个人同时盯几个店铺、几个账号、几个项目的团队，是这套架构最直接的受益者——因为它的设计目标从来不是"更强的助手"，而是"不用你盯着的同事"。