Deepseek开源Super Agent架构：让Agent管理Agent

从多Session困境到Super Agent

如果你是一个Agent重度使用者，大概都经历过这样的场景：手头同时开着好几个对话窗口，分别处理不同的任务，每隔一会儿就得切回去看看每个Session的进度。吃个饭或者开个会回来，已经忘了哪个窗口执行到哪一步。这种由人来充当"调度器"的模式，正在成为Agent生产力进一步释放的瓶颈。

据B站UP主Lipsic对Deepseek^广告 Harness团队万字长文的解读，该团队提出了一种名为Super Agent的架构设想，核心目标正是把人的注意力从多Session管理中解放出来。这套架构有两条主线：一是让用户只面对同一个助手，由Agent去管理不同的Worker Agent；二是让Agent能够主动感知环境变化并触发任务执行。

听起来像是Multi-Agent系统的翻版？实际上，Super Agent在分层逻辑、触发机制和记忆设计上都做出了明显不同的取舍。

协调层与执行层：轻量Router的分工哲学

Super Agent的第一层设计是Router Agent + Worker Agent的两级结构。Router Agent是用户直接对话的入口，可以被拉进飞书群、连接GitHub代码仓库、绑定邮箱。用户的输入、群里的讨论、代码仓库的变更都会触发Router Agent，由它判断任务该分配给哪几个Worker Agent执行，再启动Worker去干活。Worker执行完毕后把结果打包回传，Router总结后再呈现给用户。

这与传统Multi-Agent系统的关键差异在于：过往方案往往需要一个能力极强的Manager Agent来管控子Agent，意味着要用上最强的大模型；而Super Agent的设想中，Router Agent只承担协调与沟通职责，是一个轻量化的入口，用较"轻"的模型即可。

这引出一个自然的疑问：Router既要理解用户意图，又要敏锐捕捉环境变化并主动唤起Worker，轻量模型真的扛得住吗？团队给出的答案是两层过滤——第一层用机器学习或代码规则做程序过滤，把环境中无关紧要的信息挡在外面；第二层才交给模型判断。这个设计同时也是"主动执行"能力的基础。

Multi-Agent系统指由多个具备自主决策能力的Agent协同完成任务的架构，常见模式包括层级式（Manager-Worker）、对等式（Peer-to-Peer）和流水线式。其核心挑战在于协调开销：子Agent越多，上下文同步、任务分配与结果聚合的成本越高，容易陷入"协调者本身成为瓶颈"的困境。Super Agent的Router设计正是对这一困境的回应——通过压低协调层的模型成本，把算力集中投放在真正执行任务的Worker上。

Trigger机制：让Agent主动而非打扰

Super Agent引入了Trigger概念，即能够触发Agent行为的机关。设想Agent被拉进一个工作群，群里既有"中午一起吃饭""收到谢谢"这类完全不需要处理的消息，也有"更新后图片一直上传失败"这类需要排查的问题。Agent通过程序过滤和模型判断两层筛选，识别出真正需要处理的任务再启动子Agent，其余时间保持安静。

这种设计同时优化了两个方向：一方面降低了判断"哪些是废话"的时间成本和经济成本，另一方面尽量减少对重要信息的漏判。主动执行不等于频繁打扰，这是Super Agent与简单"消息机器人"的本质区别——它需要的是判断力，而非响应速度。

程序过滤与模型过滤的分工，在工程上属于典型的"级联判断"策略：先用低成本、高确定性的规则（关键词匹配、事件类型白名单、频率阈值）筛掉绝大部分明显无关的输入，再把边界样本交给大模型做语义判断。这样做的经济学意义在于，模型调用是Token成本的主要来源，而规则过滤几乎零成本；同时规则层可承受极高的信息吞吐量，适合群聊、代码提交这类高频事件流。风险在于规则配置过严会漏判，因此两层之间通常保留兜底通道。

Thread订阅与链式召回：记忆问题的两种解法

任务往往不是一次对话就能收尾的。Worker修完一个bug，用户看了Router的回复觉得还有问题，继续反馈——如果每次修改都要经过Router中转，链路会变得冗长。Super Agent的解法是Thread订阅：类似飞书把每条消息变成独立话题，Worker Agent直接订阅该话题，后续每条回复都直达Worker，不再经Router分发。同一个PR下的不同评论同理。更进一步，一个Worker可以同时订阅多个相关Thread，既连着代码库写代码，又连着飞书看用户对bug反馈的新进展，避免上下文遗漏。

记忆层面还有两个设计。Inline：Agent执行任务时不只看当前Session，还会读取近期其他相关Session的任务摘要，解决"新开窗口就丢失历史要求"的麻烦。Spill：把长内容留在对话窗口之外，需要时再展开。比如Router告诉用户方案A更好，用户追问原因，Router本身并不知道Worker的具体执行细节，它会去定位方案A出自哪个Worker、其上下文是什么，再引用回来——这个过程叫做链式召回。

设想一个有点浪漫的场景：三年前你和Agent讨论过一本书里"理想的工作是终身学习者在市场的自由表达"这句话，三年后职业陷入瓶颈时再聊职业规划，Agent从历史对话中把这句话找回来。据UP主评价，这类跨时间尺度的记忆召回目前仍偏玄，但方向值得期待。

上下文窗口是LLM单次推理能看到的Token总量上限，超出部分会被截断或需要摘要压缩。Inline与Spill本质上是在窗口受限条件下做记忆管理：Inline把相关Session的摘要作为"外挂上下文"注入，相当于在不撑爆窗口的前提下扩大视野；Spill则把长文档、大段代码留在窗口外，只在需要时通过引用定位召回，属于按需加载。链式召回进一步要求Agent能追踪某条结论的来源链路，这依赖对会话结构的索引能力，而非单纯的向量相似度检索。

一步推进与云端驻留：效率的另一个来源

一步推进指Agent在执行过程中接收新需求时不打断当前流程，而是并行处理。比如代码已经写完进入测试阶段，用户此时提出改方向，Agent会一边跑测试一边处理新需求，两边同时推进。

与之一脉相承的是云端持续协调设计：GrowthBot和Dot这类Agent已内置云端电脑，从用户本地电脑取信息，在云端执行任务。本地电脑关机不影响云端进展；需要本地信息时，任务会等待下次开机而非直接终止。这为Agent的"持续在场"提供了基础设施。

云端驻留的实质是把Agent的运行态与用户的终端设备解耦。传统本地Agent的生命周期绑定在用户电脑上，关机即中断；云端沙箱则让Agent拥有独立的执行环境与持续会话，本地只作为信息源和结果展示端。这一模式对长时任务（如批量测试、多轮爬取）尤其关键，但也带来新的工程问题：云端与本地之间的状态同步、凭据安全、以及任务在等待本地信息时的超时与恢复策略。

Watchdog：为主系统配一个独立的观察者

架构越复杂，越容易出问题。Super Agent的应对是在主系统之外设置一个独立Agent——Watchdog，它持续运行，检查任务是否有实质进展、是否偏离目标，发现问题就着手修复，保障任务顺利推进。

实测数据：更快，但代价更高

据UP主转述，Deepseek Harness对Super Agent架构做了实际测试：在95%的情况下，Super Agent花费的时间远短于单Session的传统Agent架构；完成一个任务的平均用时不到16分钟，而传统架构接近30分钟。

代价同样明确：更多会话意味着更多Token消耗。架构规模变大后，Router能否真正协调好大量子Agent、长期记忆如何解决、权限与隐私如何保障，都是尚待开发和产品实践回答的问题。

办公场景先行，个人Agent待上下文打通

UP主在解读末尾给出了自己的判断：Super Agent这套设计更适合工作场景，个人生活中的多数场景用不到如此复杂的系统。未来一段时间的重点发展会是办公Agent；而Personal Agent何时起势，更多取决于互联网上不同上下文何时能打通，而非Agent能力本身的演进。

这个判断值得玩味。Super Agent本质上是一次工程架构层面的收敛——把人的调度职责交给Agent，把Agent的调度职责交给更轻的Agent。它解决的是协作复杂度问题，而这个问题的紧迫性，在办公场景中远高于个人生活。