DeepSeek Harness 团队发了一篇架构长文，讲他们怎么做出一个"永远在线"的 Agent。文章有一句话很精辟：
单任务的上限取决于模型能力，多任务的上限取决于人的注意力。
他们观察到，一个人通常只能同时跟进 3 到 5 个活跃 Session。因为现有 Agent 都以单个 Session 为单位，Session 之间彼此独立——你并行推进多项工作时，得手动切换、还得记住每个 Session 里聊到哪了。
他们的解法叫 Super-agent，四个特征：连续（在 IM、GitHub 评论这些熟悉界面里跟它聊，感觉始终只有一个 Agent）、高效（不用等上一条命令跑完就能下一条）、主动（不等指令，自己观察环境事件）、持久（始终在线，异常自动恢复）。
架构上最核心的是双层设计：一个常驻的 Router 层承接所有人类交互和全局协调，多个上下文隔离的 Worker 层并发执行具体任务。
这个拆分解决的是一个根本权衡。如果所有事件都塞进同一个 Session，上下文最连续，但受单个 ReAct Loop 串行执行所限，吞吐上不去，多个任务的中间细节还会互相污染。反过来每条事件都新开 Session，并发最高，但缺少全局上下文，各自的结果会割裂。
关键洞察是："维护全局连续性"和"高并发执行"是两件事，不该由同一层承担。
Router 层刻意不执行具体任务——"甚至可以不配备 Bash 工具"，只做交互和分派。Worker 不直接跟人对话，只向 Router 汇报状态。他们提到一点特别值得注意：Router 层的任务常常没想象中复杂，用较轻量的模型往往就能兼顾速度与效果。
文章还抛了个尖锐观点：让用户手动管理 Session，很大程度上是从底层 LLM API 延续下来的设计惯性。"Session 应当是系统的实现细节，而不应是用户的认知负担。"
然后是几个从操作系统借鉴来的设计，这部分最有意思。
事件过滤用 Fast Path / Slow Path：接进真实的群聊和代码平台后，事件流是"高噪音、低触发率"的——绝大多数日常消息不需要 Agent 介入。所以先用确定性代码做第一道筛（来源、群组范围、白名单），只把需要语义理解的候选交给模型。大模型推理是灵活但高成本的 Slow Path，确定性代码是低延迟低成本的 Fast Path。
事件路由同样分快慢路径：同一个 GitHub PR、同一个 IM 话题下的连续事件构成一条 Thread。Router 只在初始事件时创建 Worker 并建立订阅，之后同一 Thread 的事件由程序直通给已订阅的 Worker，不再经过 Router。实测下来：去掉直通机制后，任务完成时间基本不变，但 Router 需要做的决定多了约 30%，读缓存 token 从 2323 万涨到 3177 万（+37%）。
上下文按 Cache 管理，两个操作：Inline（把近期很可能用到的信息直接内联进来，省掉工具调用往返）和 Spill（超出预算的内容留在窗口外，只保留引用或摘要）。配合局部性原理层层展开，最后形成"链式召回"——每个对象内联下一跳关联对象的 ID，模型可以顺着引用关系逐跳找回上下文。
还有两个词用得挺准：
投机执行（Speculative Execution）——在还不确定结果会不会被采纳时，先在后台试。"结果有价值就交付，没有价值就丢弃。"他们内部有条"静默复现并修复"策略：群里有人反馈问题时，Agent 先在后台尝试复现和修复，只有确认问题并找到简单修法才交付，否则全程保持安静。
全双工交互——把经典 ReAct Loop 里同步阻塞的 run() 改成异步的 start()/stop()。start() 立即返回"已启动"，后台跑完再把结果作为新事件投递回会话。前台对话和后台任务就此解耦。
部署层面他们借了存算分离：先把 Agent Loop 的计算和持久化状态分开（计算进无状态容器、状态进数据库），再让执行环境留在原地——端侧只放一个不保存会话状态的轻量 daemon，只负责执行命令和返回结果。这样支持 BYOM（Bring Your Own Machine），也能接云端托管机器。他们提到这和 Anthropic 的"脑手分离"思路一致，区别在场景：那边是托管服务，这边首先要接的是用户日常用、可能间歇在线的个人机器。
外部还有个 Watchdog Session，用定时消息驱动，构成独立的控制回路。它不只盯进程存活——"许多异常并非进程崩溃，而是模型在执行中陷入无效循环或偏离目标"，所以还要由模型判断 Worker 有没有实质进展、方向有没有跑偏。因为 Watchdog 本身也是有完整工具的 Agent，维护者可以用自然语言问它故障原因，甚至让它在线改主系统的提示词和触发规则。
实验数据也给了。端到端消融实验里，Super-agent 的 p50、p95 完成时间分别是 12.4 分钟、15.7 分钟。对比之下，带 Subagent 工具的单 Session 方案严重依赖提示词：中性提示下模型 5 次运行一次都没调用 Subagent，全在主会话里被新消息反复打断，p95 达到 29.5 分钟。
文章也把开放问题列清楚了，没有粉饰。最实在的一条是安全：云端 Agent Loop 一旦被入侵或提示词注入攻破，它连接的所有端侧设备都面临被控制的风险；而且即使云端没被攻破，只要端侧凭据进入模型上下文，正常执行过程中同样有泄露风险——"还需要设计相应的机制，让 Agent 能够在完全不接触凭据本身的情况下使用凭据"。
这套设计目前跑在他们内部，原型代码开源在 dsh-superagent-prototype，官方强调"只是一种为了验证技术路线而提供的原型，并非 DeepSeek 的正式产品"。
参考来源