DeepSeek Super Agent双层架构解析：Router与Worker如何分担人的协调负担

当AI已经能写代码、查问题、提交修改，真正的瓶颈就不再是单任务能力，而是人能同时照看多少件事。DeepSeek Harness团队公开的Super Agent设计探索，核心正是把「协调」从人手里接过去。

问题不在模型，在人的注意力

据B站UP主娜娜的梳理，团队的观察很直接：一个人通常只能同时跟进三到五个活跃会话，继续增加窗口意味着要记住更多背景、切换更多现场。单项任务的上限由模型能力决定，多项任务能推进到什么程度，却越来越取决于人的注意力。

Harness被定义为围绕模型搭建的运行系统，安排消息、工具、上下文和执行流程。同一个模型如何接收工作、等待结果、回应变化，都受这套系统影响。DeepSeek^广告已基于该思路运行内部实例，参与问题复现、修复和代码审查响应。

一个直观例子发生在他们自己的工作群里：有用户反馈macOS上窗口未聚焦时点击被识别成双击，导致聊天记录被放大。没有人点名要求Agent处理，内部实例已开始尝试复现，随后提交了修复的代码合并请求。另一例中，同一项功能开发从即时通讯群聊推进到GitHub代码评审，交互入口换了，背景不需要重新讲一遍。

双层架构：Router不亲自干活

把所有消息塞进一个大对话框会遇到麻烦：一个会话通常沿着思考、调用工具、读取结果的循环往下走，常任务会挡住后面的事，中间细节也容易混在一起。反过来每条消息都开新会话，并行是并行了，任务之间的关系又断了。

DeepSeek的办法是把全局协调与具体执行拆成两层。上层Router是统一协调入口，接收来自不同平台的信息，掌握跨任务关联，分派工作并统一向人反馈。下层Worker负责具体干活，各自拥有独立上下文，可以同时推进不同任务。

关键设计在于：Router不亲自执行具体工作，甚至可以不给它运行命令的工具。它要保持清亮，避免一头扎进某个复杂问题让整个系统等它出来。真正决定代码质量和任务结果的Worker，通常配置能力更强的模型。这与「总负责人配几个助手」不同——复杂任务里的负责人需要深度拆解步骤，而Router主要管理任务之间的高层关系，一项工作内部要不要再分工，由Worker自己处理。

Router/Worker的分层设计在工程上常被称为"协调者-执行者模式"（orchestrator-worker pattern）。它与"单Agent+工具调用"的差别不在单次推理能力，而在系统可以把"等待"和"思考"解耦：Worker在等待工具返回时不会阻塞Router接收新事件，Router做分派时也不需要装载某个任务的全部上下文。代价是系统状态变多——每个Worker有自己的会话历史、订阅关系和执行环境，一旦某个Worker卡住，需要有独立机制发现，这也是后文watchdog要解决的问题。

订阅机制与事件流：已知送谁，直接送达

协调入口也可能成为新的堵点。如果每条后续消息都要请Router判断一次再转给Worker，任务越多转发成本越高。

这套设计引入订阅机制：同一个代码合并请求、同一个群聊话题或同一封往来邮件串，构成一条连续的事件流。Router创建Worker后让它订阅相关事件流，后续属于这件事的消息由程序直接送到对应Worker，不必每次都重新分派。需要跨任务协调时，再交回Router；Worker的关键结论也会汇总到Router对外回复。

订阅还支持多对多关联：一个Worker可以跟进几个相关话题，同一个代码合并请求也可被多个Worker订阅，它们收到同样的更新，就有机会发现彼此的操作、处理冲突。工程思路很朴素——已经知道该送给谁，直接送过去；需要理解新意图、判断新任务的信息，再调用模型。

同样的原则用在消息入口：群聊、邮件和代码平台不断产生事件，大部分不需要Agent行动。系统先用程序检查来源、群组范围、白名单等明确条件过滤无关消息，通过这一层的候选事件再交给模型结合语义判断。DeepSeek内部配置的一条策略叫「静默复现并修复」：群里有人反馈问题或讨论改动时，Agent先在后台尝试，确认问题并找到简单修复方案才交付结果，没有形成有价值的结果就保持安静。这相当于拿额外的后台计算换取人的等待时间。

事件流（event stream）在这里指围绕同一实体持续产生的一组相关消息，例如一个PR下的所有评论、一次群聊话题里的连续发言。它与"消息队列"的区别在于：队列通常按先来后到消费，而事件流强调归属关系——系统先要知道这条消息属于哪个正在进行的任务，再决定送达对象。订阅本质上维护的是一张"实体—Worker"的映射表，映射命中就走程序直送，未命中才升级给模型判断意图。这种"先规则后模型"的漏斗结构，是控制推理成本最直接的手段。

上下文缓存与异步执行

一个持续工作的Agent该记住多少东西？全部历史装进上下文，窗口很快占满；只给消息编号，又迫使模型反复查工具。DeepSeek借用计算机缓存的思路：近期很可能用到的信息放进当前上下文，较长较少用的内容留在外面，保留摘要和读取入口。这些编号还能串成引用关系——从当前消息找到所属话题，从话题找到负责的Worker，再找到该Worker关联的另一处代码评审，跨平台上下文可以沿线索逐步找回。

经典的同步工具调用会让执行循环等到工具跑完，后台任务一慢，前台对话也被拖住。DeepSeek提出的异步方式是启动命令后先返回一个启动信号，让工具在后台运行，完成后再把结果当成新事件送回来。用户追加要求或改变方向，新输入可以在当前推理结束后被处理，不必等后台命令全部完成。

异步机制已在DeepSeek Harness中实现，尚未默认开启。团队验证过的输出规则是：群聊里单次回复不超过100词，只给简短结论和直接问题；到了代码合并请求、邮件或文档，再完整说明背景、改动和验证结果。

异步工具调用与同步调用的关键区别在于控制流归属。同步模式下，模型发出工具调用后整个推理循环暂停，直到结果返回才能继续；异步模式下，模型发出的是"启动"指令，拿到一个句柄（handle）后即可结束本轮推理，结果稍后以新事件形式重新进入上下文。这让前台对话的响应延迟不再受后台命令耗时影响。但异步也带来新问题：结果返回时任务目标可能已经变化，系统需要能判断"这个结果是否还属于当前意图"，否则容易把过期结果当成有效输入。

摆脱本地生命周期与独立watchdog

本地Agent往往把运行循环、会话记录、代码和工具放在同一台机器，电脑休眠工作就停了。DeepSeek把Agent计算推进云端、会话状态保存在数据库，真实执行环境继续留在用户机器上。之所以不把环境直接复制到云端，是因为工作现场包含的远不只是代码仓库，还可能有未提交的修改、本地凭据、内网依赖和特定工具链，重建既有成本也容易遗漏。他们的做法是在执行设备上部署轻量程序，负责执行命令、返回结果，云端Agent按需介入。

长期运行还有一种故障：进程活着，任务却没有进展。模型可能反复尝试同一种无效办法，也可能逐渐偏离目标，单纯检查服务是否在线发现不了。为此团队在主系统外设置了独立的watchdog会话，用定时消息驱动，既检查接口报错、状态恢复等故障，也用模型判断Worker是否有实质进展、方向是否偏离，再介入修复。

watchdog在系统设计中指独立于主进程运行的监控组件，其核心假设是"被监控者可能自己报告健康，但报告本身不可信"。常见做法有两种：心跳式（组件定期发信号，超时则判定异常）和进展式（检查任务状态是否发生实质性推进）。DeepSeek的方案同时用了两类——接口报错、状态恢复属于心跳能覆盖的故障，而"反复尝试同一种无效办法""逐渐偏离目标"只能靠模型对进展做语义判断。把watchdog放在主系统之外，是为了避免主系统整体卡死时监控也一起失效。

实验结果：中位数12.4分钟，尾部才是关键

团队做了初步调度实验：每次输入约300条群聊和自动检查消息，其中约20条是工作请求，其余包括闲聊、跟进和叫停，每种方案运行5次。编码工作由只消耗时间的工具代替，消息间隔和模拟工作时长按比例缩放，模型调用耗时保留真实值。

Super Agent的任务完成时间中位数为12.4分钟，95分位为15.7分钟。作为对照，单会话虽然也配备子Agent工具，但在中性提示词下5次运行都没有调用它，工作由主会话执行并不断被新消息打断，95分位达到29.5分钟；把提示词改成优先委派后，5次里有4次进行了委派，表现有所改善，剩下一次模型判断工作很小仍然亲自执行，留下了较长的等待尾部。

代价也存在：Super Agent要维护多个独立会话，缓存Token消耗高于单会话方案，用更多的上下文处理开销换到了更短更稳定的任务完成时间。订阅直通的价值则体现在另一处：去掉直通后完成时间基本相同，但Router做出的决定增加约30%，总缓存Token从2323万涨到3177万，约多出37%——在这个实验负载下，省掉中间转发主要降低了推理开销。

团队还单独测试了协调层的批处理：Router在上一轮推理时收到多条事件，可以合并到下一次模型调用。压力测试中Worker使用模拟模型、Router调用真实模型，当需要它做决定的事件从每分钟约一条升到约40条，平均批次大小从1.0增到2.8，单次请求耗时从2.5秒增到3.9秒，耗时增长慢于批次大小，让合并处理具备了收益。

这些结果来自合成消息和简化环境，支持的是调度设计在该负载下的效果，真实任务难度、工作之间的耦合以及更大规模团队的表现仍需检验。

权限与记忆：仍未闭合的开放问题

云端Agent持续读取外部消息，本地设备又保存着私有代码、敏感数据和凭据。如果云端被入侵或被提示词注入攻破，连接的端侧设备就可能受到控制；即使系统正常运行，凭据进入模型上下文也可能产生泄露风险。团队提出需要让Agent在不接触凭据本身的情况下使用凭据，更大组织还要划清上下文边界——哪些人共享一个实例、哪些信息必须隔离、多个隔离实例之间如何协作，仍是开放问题。

长程记忆同样没有结束探索：用关系找回近期任务和跨越保存、理解工作历史，是不同尺度的问题；用户如何在后台执行中随时介入、接管，也需要更成熟的产品设计。

这套探索值得关注的地方，是它把自主协作拆成了具体的系统责任：工作怎样分派、信息怎样送达、结果怎样交付、异常由谁发现，每一项都直接影响人要付出多少协调成本。如果用户仍要不断切换窗口、补充背景、催问进度，再强的单任务能力也会被管理负担抵消。把这些负担接过去，人才更有空间决定目标、处理关键分歧、判断结果是否合格。