DeepSeek Super-agent：双层协作机制-字节棱镜 (Byte Prism)

据 IT之家转述的 DeepSeek Harness 官方团队文章，Super-agent 的重点不是提高单次问答能力，而是把 Agent 从“被动响应指令的单任务工具”，推向持续在线、并行处理多项任务、能够响应外部事件的协作者。

核心分界在编排层：系统级 Router 接收需求、维护全局上下文并分派任务，Worker 在隔离 Session 中并发执行；外部事件先经过程序规则过滤和模型判断，再进入执行链路。这里的 Router 属于系统编排层，与模型内部按 token 选择专家的 MoE 门控网络不在同一层级。

Super-agent 与单会话 Agent 的差异

基于 LLM 的 Agent，通常让模型承担理解、规划、记忆和工具调用，并在环境中采取行动。传统主流方案往往以单一 Session 为基本单位，不同 Session 相互独立。用户并行推进多项工作时，需要手动切换窗口并维护各自上下文。

DeepSeek 团队观察到，一个人通常只能同时跟进 3 至 5 个活跃 Session。即使借助 CLI、MCP 或外部连接器扩展 Agent，仍会遇到单会话同步阻塞、多任务上下文混乱，以及本地设备离线后任务停止等问题。

Super-agent 因而增加了四项系统特征：连续、高效、主动、持久。变化不只是“支持更多会话”，而是把执行单位从一次问答扩展为可并行、可订阅、可恢复的任务与事件流。

Router 与 Worker 的分工

拓扑关系可以概括为：

用户 / 即时通讯 / GitHub
              ⇅
        ┌───────────┐
        │  Router   │
        │ 交互、全局 │
        │ 上下文、分派│
        └─────┬─────┘
              │
    ┌─────────┼─────────┐
    ▼         ▼         ▼
 Worker A  Worker B  Worker C
 独立 Session，并发执行
    └─────────┼─────────┘
              │ 状态与结果
              └──────► Router ──► 统一回复用户

Router 是唯一面向用户的前台，负责承接交互、维护全局上下文、拆分并分派任务。Worker 是相互隔离的后台执行单元，可以并发处理不同任务，但不直接回复用户，只把状态和结果汇报给 Router。

Super-agent 的 Router 容易与 MoE 门控网络混淆。MoE 门控网络处理的是模型推理：针对每个 token 选择少数专家参与计算；Super-agent 的 Router 处理的是系统任务：决定交给哪个 Worker、携带什么上下文、何时重试以及何时需要人工介入。两者虽然都叫“路由”，但对象、粒度和职责完全不同。

Agent 主动性的事件驱动机制

完整执行链路如下：

群聊 / 邮件 / 日程 / GitHub 评论 / CI 结果
                       │ Trigger
                       ▼
                程序规则过滤
                       ▼
                模型判断是否行动
                       ▼
                  Router 分派
                       ▼
           Worker 订阅 Thread 并执行
                       │ 状态与结果
                       ▼
             Router 统一对外回复

已分配事件流的后续事件 ─────────────► Worker

群聊消息、邮件与日程提醒、代码审查评论、CI 运行结果，都可以作为 Trigger。系统先通过程序规则过滤，再交由模型判断是否采取行动；任务确定后，Worker 订阅对应 Thread。后续相关事件可以直接送达 Worker，不必每次重新经过 Router，从而降低路由负载。

这种机制让 Agent 的主动性来自“持续观察事件并推进任务”，而不是脱离约束地自行行动。架构探索描述的场景包括同一任务在 IM 群聊与 GitHub PR 评审之间连续推进，以及在无人主动 @ 时识别缺陷并提交修复 PR。

多任务并行时的上下文连续性

Super-agent 没有简单地把所有历史都塞进提示词，而是提供两种互补机制。

Inline & Spill 解决“哪些信息应该进入当前窗口”：近期可能使用的信息直接放入上下文，超出预算或访问频率较低的内容保留在窗口之外，由模型按需读取。Chain of Recall 解决“如何找回历史任务”：模型沿着 Trigger、Thread、Worker Session 等对象之间的引用关系，逐步召回关联信息。

因此，多 Worker 并行的关键不是共享一个无限膨胀的上下文，而是隔离执行上下文，同时保留可追踪的全局索引。窗口越大也不等于历史越一致，召回顺序、引用完整性和任务状态仍然需要单独设计。

落地所需的模块与护栏

该设计包含双层架构、事件驱动、面向人的交互、计算与状态及环境分离、Watchdog 五部分。可拆分为以下最小工程模块：

架构组成	工程落点
双层架构	Router 服务、Worker 池、Session 隔离
事件驱动	Trigger 连接器、规则过滤器、事件分发器
面向人的交互	多渠道适配、统一回复、审批入口
计算与状态及环境分离	持久状态、执行环境、任务检查点
Watchdog	心跳、健康检查、失败重启与恢复

针对本地设备离线和异常中断，状态持久化、环境分离与 Watchdog 是基础，但还需要明确哪些步骤可以重放、哪些操作必须幂等。高风险动作应采用权限分级，关键操作应设置人工审批，同时保留审计记录、失败重试和人工接管能力。

验收也不应只看演示效果，可以观察路由准确率、任务完成率、上下文恢复率和人工介入率。若使用 DeepSeek API 承载 Worker，其 API 页面列出了 tool-use、最长 1M tokens 的上下文和自动缓存能力。这些属于模型服务能力，不会自动提供 Router、事件分发、状态管理和故障恢复机制。