介绍#

super-agent是deepseek开源的用来解决模型能力提高后，多任务并行下人的注意力瓶颈而提出的一套解决方案或架构。

架构或解决方案#

持续监听环境，自主选择和完成任务

特点#

连续：直接在聊天软件、GitHub评论等熟悉界面交互，不用考虑上下文是否有相关信息（Maybe大模型组织上下文？）
高效：响应迅速、可并行、高质量完成多个复杂任务，无需等上一个任务完成就可以处理下一个任务
主动：无需等用户下达命令，能持续观察环境事件，主动推进待办事件（有没有安全问题？开放问题有讲）
持久：长期运行，遇到异常自动恢复

双层架构#

维护全局连续性与高并发执行拆分到两个层级：

Router层统一承接人类交互与全局协调
Worker层上下文隔离，并发执行任务

Router层#

Router层是常驻的全局路由层，不深入任务细节，主要是高层关联和分配任务。Router层的任务，没有那么复杂。用轻量模型就能兼顾速度与效果。

Worker层#

可以调用subagent，需要强力模型

事件驱动#

两级策略过滤噪音#

Fast Path 程序层策略：通过确定事件来源、范围、用户或机器人白名单，分别设置“仅响应明确请求”、“作为候选事件”、“直接忽略” 在调用模型前就过滤掉无关消息
Slow Path 语义层策略：程序层准入后交给模型，由提示词策略和上下文判断是否需要行动

事件路由#

成功分配任务的后续事件，不应走Router，因通过程序直接发往对应的Worker会话，降低负载。同一话题因构成同一事件流，即Thread。

Router层根据某个Thread的初始事件创建Worker Session后，该Worker会订阅对应Thread。已订阅的后续事件走Fast Path，通过程序直通Worker。若新事件超出当前任务范围，Worker也可取消订阅或交给Router层重新分派（？有点模糊）。

Thread和Worker是多对多，同一个Thread可能需要多个Worker解决（多个worker冲突怎么办？），同一个Worker可能订阅多个相关的Thread（可能Thread要解决的问题基本一致）。

在输出侧，Worker讲关键结论汇报给Router，并有Router同一向用户回复并同步全局记忆

上下文组织#

上下文窗口当作Cache来管理。借用编译优化和计算机系统概念。

Inline 将近期可能用到的信息直接内联进上下文窗口，省去额外工具调用往返
Spill 将超出窗口预算或低频使用的信息留在Context外面，窗口内仅保留引用或摘要。局部性思想对事件注入和工具调用优化：

从最少信息开始：只提供对象ID和内容摘要
利用局部性逐步Inline关键信息：将近期很可能用到的信息 Inline 到上下文中，先附上紧密关联对象的 ID，再附带时空相邻的内容，例如内容前 50 字、IM 消息的前后相邻消息与所回复的消息，或代码评论所在评审讨论中的相邻评论。
超出上限则 Spill：对无法全部 Inline 的长内容设定较小的长度上限，将超出部分 Spill 到窗口之外。一种简单直接的做法是截断超出部分并保留续读入口，模型需要完整内容时再调用工具读取。

在大量后续事件直通 Worker、且系统在长期运行中累积了许多历史任务后，Router 层既不能把所有任务的全量历史都放入自己的上下文窗口，又需要在用户跨信道提起某个旧任务时找回上下文。将 Inline & Spill 一致地应用到系统中的各类对象后，就得到了一种按需展开的多跳检索机制，即链式召回（Chain of Recall）。这种链式召回过程缓解了 Router 层在长程中丢失先前信息的问题。具体来说，系统为 Trigger、Thread 和 Worker Session 等对象赋予唯一 ID，并在注入时内联紧密关联对象的 ID，使这些对象在底层构成一张引用图。

提前行动#

不确定结果能否被采用时，消耗额外算力在后台提前尝试，减少人类等待和介入成本。结果有价值就交付，没有就丢弃，并采取下一步操作。

面向人的交互#

异步ReAct Loop。不同信道，让系统输出的方式匹配信道特点或带宽，顺应人的使用习惯

全双工交互#

消除一问一答半双工。发送消息后，模型调用 start()，用户收到已启动，然后返回。在后台工具执行完成后，系统再将最终结果作为一条新的事件消息投递进会话。模型也可以根据上下文调用 stop() 主动终止执行时间过长的后台命令。

多信道交互#

Router负责对外交互，针对不同信道，有不同交互规范

计算、状态与环境分离#

为了持久化在线（会话状态、工具链、代码仓库）引入存算分离思想。

将推进Agent Loop的计算与持久化会话状态分离，是Agent摆脱单机，实现云端持久在线
将云端Agent Loop与重状态的执行环境解耦，工作环境留在原地，支持跨设备访问

计算与状态分离#

将推进 Agent Loop 的计算放入云端无状态的弹性计算容器中，而将 Session 等持久化状态存入数据库。无状态计算容器可以水平扩展、重启或替换，会话与任务的连续性则由持久化存储保障，从而使 Agent 摆脱单台本地设备的生命周期限制，实现云端持久在线。

计算与执行环境分离#

让 Agent Loop 在云端运行，而让重状态的执行环境留在原地，仅在端侧部署一个不保存会话状态的轻量 daemon（守护进程，后台长期运行），它只负责执行命令与返回结果，相当于把执行环境留在云端之外，由 Agent 按需读取其中的上下文。

Watchdog#

为持久化，除了存算分离，还需要有能从异常中自动恢复的能力。持久在线的分布式系统很难仅靠主系统内部逻辑保证长期可靠运行（解释：主系统内部逻辑只能处理它“想得到”的问题，比如业务异常、参数校验、可预期的超时重试；但它管不了自己所在的那台机器挂掉、网络被切断，也不具备在卡死时自我唤醒的能力。），需要在主系统之外引入独立的外部控制回路，即 Control Loop。

在 Agent 系统中，仅靠传统的进程存活探测或监控脚本是不够的，因为许多异常并非进程崩溃，而是模型在执行中陷入无效循环或偏离目标。因此，长期运行的 Agent 系统不仅需要监控基础设施的存活，还需要监控任务本身的进展。

Watchdog 除了处理接口报错、状态恢复失败等基础设施故障，还会由模型判断各个 Worker 是否有实质进展、方向是否偏离整体目标。发现异常时及时介入修复，遇到外部偶发故障则持续复查直至恢复正常。