Super-agent 设计探索：让 Agent 只有一个，Session 变成实现细节
DeepSeek Harness 团队把他们内部在用的 Agent 架构写成了文章，由 Yujia Qiao 实现系统并执笔。原文末尾有两句自我限定，值得先摆在前面：这讨论的是架构想法，不是 DeepSeek Harness 现有功能的介绍；文中部分设计已在 dsh-superagent-prototype 里实现，但那只是验证技术路线的原型，不是 DeepSeek 的正式产品。
文章想解决的问题很朴素：单任务的 Agent 已经够能干了，可一个人同时盯得住几个会话？答案是三到五个。再往上，瓶颈就不在模型，在人。
一、Super-agent：从「切会话」到「一个持续的实体」
过去一年，coding agent 这类单任务 Agent 证明了模型能用工具解决复杂问题，人越来越少插手底层执行，位置慢慢上移到决策与验收。模型协调多个 Agent 的能力也在变强，跨会话组织和调度开始变得可行。
模型变强之后，新形态冒出来了。个人助手一类的应用接连出现：直接接上日常的 IM、日历、邮件、工作平台，盯着信息流，顺手把活干了。但这只是「持续在线、事件驱动」这套工作方式的一种应用，它同样适用于软件开发这样的商业场景。
问题在于，今天主流的 Agent 设计撑不住多任务和团队规模。它们仍然以单个会话为基本工作单位，会话之间彼此隔离。用户并行跑几个任务，就得手动在会话之间切换，还得记住每个会话里有什么。按他们的经验，一个人通常同时跟不住超过 3 到 5 个活跃会话。于是成了一个别扭的局面：单个任务的上限由模型能力决定，多任务的上限由人的注意力决定。
给本地单会话 Agent 加 CLI、加 MCP、加外部连接器，能让它收到外部消息，但底子没变：它仍在一个同步会话里跑，长时间操作会阻塞；不同任务的上下文搅在一起；本地设备一离线，一切停摆。维持这么一套东西运转，要花大量手工。
要跨过这些限制，得把 Agent 从「任何一个需要人手动驱动的会话」上解耦。它应该是一个连续的实体：跨会话保持上下文，同时推进几个复杂任务，任务之间互不干扰。他们把这类 Agent 及其系统架构叫作 Super-agent。
他们内部的实例跑在 DeepSeek Harness 上，能在 IM 与 GitHub 之间连续推进同一个开发任务；也会盯着公共群聊里的反馈，即使没人 @ 它，也能自己定位根因并开 Pull Request 去修。
这样的 Agent 有四个基础特征：
- 连续：用户在自己本来就在的地方和它交互，比如 IM 聊天、GitHub 评论，感觉始终只有一个 Agent。不用去想「会话 X 的上下文里到底有没有 Y 这条信息」。举个具体的：用户在 IM 里说要方案 A，后来在 PR 评论里改成方案 B，它能理解这个变化，调整正在做的事。
- 高效：响应快，能并行、高质量地完成几个复杂任务。上一条命令或任务还没结束，就能接下一句指令。
- 主动：不等用户一条条下指令。它观察环境里的事件，值得处理的就动手，不值得的就保持安静。
- 持久：始终在线，直接接入用户真实的工作环境，长期运行中出异常能自动恢复。
单个 ReAct Loop 撑不住这四点，它们只能来自外面那套系统架构。而且相似的设计约束往往导出相似的架构：目标都是「持续在线、并发响应环境事件」时，个人助手和软件开发这类商业场景的 Agent，最后多半会走到相近的设计上。搭这种系统会碰到不少和传统计算机系统长期研究过的问题很像的难题，那些经典思路照样能用。
具体实现会有变体，但他们认为五个模块构成了支撑这四个特征的基本框架：双层架构负责连续交互与高效并发，事件驱动让 Agent 主动，面向人的全双工多信道交互让每次交流既连续又高效，计算/状态/环境分离加上 Watchdog 让它跨设备持久在线、异常自愈。
下图是整体架构，标号 [2] 到 [6] 对应后面的第二到第六节：
二、双层架构：连续与吞吐不必二选一
既要跨信道连续交互，又要多任务高效并发，这就逼出一个根本权衡：会话该怎么组织。
把所有事件都灌进一个会话，上下文最连续，因为那个会话什么都看得见。可 ReAct Loop 一次只走一步，单个会话的速度有上限：任务耗时长，吞吐低。不同任务的中间细节还会在同一个上下文里交错，结果变差。
反过来，每条事件都新开一个会话，权衡就翻过来了：并发吞吐最大化，但任务之间但凡不是完全独立，缺少共享的全局上下文就会让结果彼此断开。几个会话分别回复用户，交互也变得混乱。
要同时拿到连续性和吞吐，可以把活分给两层：一个常驻的 Router 层（2.1 节）承接所有人类交互与全局协调，维持全局连续性；一个上下文隔离的 Worker 层（2.2 节）以高并发执行任务。
有了双层架构，上下文管理和并发执行由系统接管，用户很少需要去想会话这回事，始终和同一个 Super-agent 打交道。反过来说，让用户手工管理会话，很大程度上是从底层 LLM API 带过来的一种设计习惯。会话应该是系统的实现细节，而不是用户的心智负担。
在现有设计里，一个会话身兼两职：既管模型的上下文，又是用户做项目管理的单位。一旦产品与底层会话解耦，项目管理就不必再跟着会话边界走。给用户提供什么样的交互和任务管理，就变成一个独立的产品问题——这一点他们后面再谈。
两层是职责上的逻辑划分，不是物理实现。哪一层都不必是单个会话，各自可以有内部结构。
2.1 Router 层
Router 层是一个常驻的全局路由层，接收来自所有入口的人类交互。跨任务的信息和决策都在这里汇合，所以它同时是系统的全局序点、协调点和记忆。
为了让这个唯一全局节点不至于变成性能瓶颈，Router 层被设计成不亲自执行任务：它只和人交互、分派任务，甚至可以完全不挂 Bash 工具。
一个中心节点把任务分给几个执行节点，这结构看着像典型的 Agent Team，但两者关注的东西不同。Agent Team 通常是把一个复杂任务拆成若干步骤，协调干这些步骤的角色。因为这些步骤往往耦合很紧，Team Lead 常常得深入理解任务、规划子任务、频繁协调成员，推理负担不轻。Super-agent 里，Router 层只负责分派任务、在高层面上追踪任务之间的关系，不拆解单个任务。
反过来也成立：Agent Team 也可以做成双层架构。前提是提示词要让主会话不亲自执行任务，只管对外交互，以及把各自独立的任务分派给成员。按他们的经验，Router 层的工作往往比想象中简单，一个更轻的模型通常就能兼顾速度和质量。
Router 层内部也不必是单个会话，有些逻辑甚至不需要 LLM。他们选了最直接的做法——一个常驻的 LLM 会话，结果发现它比看上去更不容易成为吞吐瓶颈。原因在于：一次推理回合内到达的环境事件（也就是第三节的 Trigger）会排队，在下一回合一起处理。这就是批处理，而合并处理增加的额外开销很小。
- 外部事件匀速到达时，Trigger 一条条抵达 Router 会话，每条都很快拿到响应。
- 事件成批涌入、开始在 Router 会话前排起队时，上一个回合期间攒下的 Trigger 会被自动合并，一起注入下一次 LLM 调用。因为 Router 会话只做轻量交互和分派，每步通常是长输入、短输出。合并进一次 LLM API 调用的 Trigger 在 Prefill 阶段并行计算，所以单请求耗时随批大小增长得慢得多。于是在一定范围内，积压越多，每个决策分摊的推理时间越低。上限取决于上下文长度，以及模型在一轮里能准确处理多少个 Trigger。
7.2 节用实验量化了批处理的效果。再加上订阅与直通（3.2 节）和链式召回（3.3 节），一个常驻的 Router 会话既保住了上下文的连续性，对目前这个规模的团队也够用了。
如果系统长到一个会话真的撑不住，Router 层内部可以做多级过滤结构，也可以按水平分片拆成几个会话。这时它的内部设计又回到同一个「连续 vs 吞吐」权衡上：分片越细，Router 层拿到的并发吞吐越多，但各分片之间共享的记忆和上下文越少。这个权衡会一直存在，直到全局记忆问题被解决。
2.2 Worker 层
Worker 层就是执行任务的那些会话。每个 Worker 上下文隔离、挂满执行工具，只负责一个任务。Worker 会话直接决定每个任务的结果和代码质量，所以通常要用最强的模型。
Worker 从不直接和人类交互，它的推理过程和工具调用也不会出现在外部信道里。每个 Worker 向 Router 层汇报状态，由 Router 统一负责对用户的全部回复。这样系统既保住了并发，也保住了输出质量，还不会出现几个会话分别回复造成的混乱。
任务并发跑时，各干各的，平级的 Worker 之间通常不需要直接通信。Worker 之间的冲突往往出现在共享的工作环境里，比如同一个 Pull Request。只要相关 Worker 都订阅了那个环境的 Thread，它们就收到同样的事件通知（3.2 节），有机会自己发现并解决冲突。少数需要跨任务协调的情况，由 Router 层转达。
和 Router 层一样，Worker 内部也不必是单个会话。一个复杂任务里，Worker 可以再开子 Agent，也可以自己就是一个 Agent Team，这对上层 Router 是透明的。同样的结构也适合代码协作：复现问题、评审 PR、开发功能这些独立任务可以同时推进，互不阻塞。它也适合个人助手场景——哪怕个人助手通常只给一个聊天页面：用户在一个页面里同时聊几个话题，页面维持对话的连续，后台则可以给每个话题分派一个独立 Worker 并行干活、并行起草回复。
三、事件驱动：把输入从提示词换成 Trigger
要让 Super-agent 主动，先得换掉系统的驱动方式。Agent 的主要输入不再是人类一条条敲进会话的提示词，而是来自环境的半结构化事件。这些环境事件——群聊消息、邮件、日程提醒、代码评审评论、CI 结果——被叫作 Trigger。因为 Agent 在监听并响应 Trigger，它不用像单会话 Agent 那样，每次运行前都得等人下命令。
下面四小节按「一个环境事件从抵达到被处理」的顺序展开，一节接一节：先是代码与模型组合的两段式策略把大量噪声滤掉（3.1 节）；然后是订阅与直通机制把事件送到 Worker（3.2 节）；接着 Inline & Spill 和链式召回把密集上下文注入模型，并在需要时按需召回更多（3.3 节）；最后，投机执行让 Agent 依据环境信号在后台提前动手（3.4 节）。
3.1 事件过滤
一旦接上真实的群聊和代码平台，系统面对的就是一条噪声极大、触发率极低的事件流：日常消息里绝大多数不需要 Agent 做任何事。让大模型从零判断每一条事件，延迟和算力都吃不消。
借用计算机系统里的快慢路径（Fast Path / Slow Path）思路：大模型推理是灵活但昂贵的慢路径；那些高频、定义清晰、判断稳定的工作，可以固化成确定性代码，作为低延迟、低成本的快路径。
于是每条进来先过滤。确定性策略在任何大模型被调用之前就把噪声去掉，只有需要语义理解的候选事件才交给模型。他们用的是程序化策略加大模型的两段式过滤：
- 程序化策略（快路径）：代码对确定性条件做快速准入检查，比如事件来源、群、用户或机器人的白名单。举例来说，每个来源可以设成「只响应明确请求」「当作候选事件」「忽略」三档。这些检查在调用任何模型之前就挡掉了大部分无关消息。
- 语义策略（慢路径）：通过程序化检查的候选事件进入 LLM，由它根据上下文和写成提示词的策略决定要不要动手。语义这一层同时也是个自然语言扩展点：人随时可以通过提示词开启、关闭某项策略，或者加一条新的。
3.2 事件路由
第二节那个全局 Router 层负责跨信道的交互连续。但如果一个已分派任务的后续事件也都要过 Router 层，这个唯一全局节点就会背上重负载，响应变慢。所以快慢路径的分法同样适用于过滤后的事件：Router 层只处理新任务的冷启动和跨任务协调，后续事件由代码直接送到拥有它的 Worker 会话。
真实工作流里，同一个 GitHub PR、同一个 IM 话题、同一条邮件链上接连发生的事件会形成一个事件流，他们把它叫作 Thread。
Router 层为 Thread 里的第一条事件创建 Worker 会话时，那个 Worker 就直接订阅了这条 Thread。此后的事件路由走下面两条路径之一：
- 已订阅（快路径）：代码把 Thread 里的后续事件直接透传给已订阅的 Worker，Router 层不需要再调一次工具去转发。如果新事件超出了当前任务范围，Worker 可以退订，或者把事件交回 Router 层重新分派。
- 未订阅（慢路径）：Router 层仍然能看到每一条事件，这让它能追踪全局状态，但它只评估和分派那些还没有订阅者的事件。
Thread 与 Worker 之间的订阅是多对多的。一个 Worker 可以订阅几条相关的 Thread，一条 Thread 也可以有几个订阅的 Worker。当几个 Worker 在同一个工作环境或讨论里重叠时，共享 Thread 里的每条新事件会同时透传给所有订阅者。这些 Worker 就有机会了解彼此在做什么，自己解决冲突，不需要点对点通信。在输出侧，Worker 仍然把关键结论汇报给 Router 层，由 Router 负责全部对用户的回复，并保持全局记忆同步。
3.3 上下文组织
事件被过滤、路由到目标会话之后，下一个问题是：往模型上下文窗口里放多少信息。输入不再是有限几条人类提示词，而是环境持续产出的半结构化事件，于是工具调用和事件注入的设计变得更要紧。注入太多，窗口被塞满，模型注意力被稀释；注入太少，模型得一次次调工具读上下文，执行步数上去了。浪费上下文窗口，就是浪费模型的智力。
于是可以把有限的上下文窗口当成一块缓存。借编译优化和计算机系统的说法，上下文注入归结为两个基本操作：Inline 是把很快可能用到的信息直接放进当前窗口，省掉额外的工具调用往返；Spill 是在信息超出预算或很少被用到时，把完整内容留在窗口之外，窗口里只留一个引用或摘要，模型需要时再顺着它读全文。
配合计算机系统设计里的局部性（locality）这个经典概念，Inline & Spill 可以一步步改善事件注入和工具调用：
- 先给最小信息：一开始只给模型当前对象的 ID 和一段内容摘要。
- 靠局部性渐进 Inline：把模型很快可能用到的信息 Inline 进来。先放紧相关对象的 ID，再加空间或时间上相邻的内容。比如正文前 50 个字符、某条 IM 消息前后的几条消息以及它回复的那条、同一段代码评审讨论里的相邻评论。
- 超限就 Spill：对无法完整 Inline 的长内容设一个较小的长度上限，超出部分 Spill 到窗口外。最简单的方式是截断并留一个「后面还有」的指针，模型需要时调工具读剩下的部分。
Router 层有它自己的上下文难题。大量后续事件直接透传给 Worker，跑久了任务也会积压，Router 层不可能把所有任务的完整历史都放在窗口里。可当用户换个信道提起一个旧任务时，Router 层还是得把这个任务的上下文找回来。把 Inline & Spill 一致地用在系统里每一类对象上，就得到一个按需、多跳的检索机制：链式召回（Chain of Recall）。它减少了 Router 层在长期运行中丢失早期信息的程度。
系统给 Trigger、Thread、Worker 会话这些对象分配唯一 ID，在注入某个对象时一并 Inline 紧相关对象的 ID。这些 ID 把对象连成一张引用图。每个通过工具调用召回的对象同样遵循 Inline & Spill，所以返回结果里会 Inline 下一跳对象的摘要和 ID。从当前事件出发，模型就能顺着引用一跳一跳地召回上下文，需要多远走多远。
举个例子：模型从当前消息所在的 Thread 出发，顺着 Inline 的 ID 找到相关的 Worker 会话，再从那个 Worker 找到另一条与之关联的代码评审 Thread。
3.4 提前行动
投机执行（speculative execution）的思路也借了过来。依据环境信号，Agent 在还不知道结果会不会被用到的时候就先在后台开工——用多花一点后台算力，换人少等一会儿、少插手几次。最后有用的结果交付出去，没用的丢掉。
个人助手场景里，一封会议邀请或一条待办消息进来，Agent 可以先去查日程冲突、收集背景资料、起草回复。用户只需要扫一眼草稿按下发送。研发协作里同样管用：他们内部 DeepSeek Harness 的用户群里配了一条「静默复现并修复」策略——有人报 issue 或讨论一个改动时，Agent 先在后台试着复现问题、找修复方案。只有确认了问题、找到了简单修法，才交付结果；否则全程保持安静。
四、全双工多信道交互
第二节的双层架构在上下文层面保住了跨信道的交互连续。但要让日常交互既连续又高效，还有两个问题要解决：交互怎么进行，以及在哪里进行。第一个是别让耗时操作阻塞前台对话，异步 ReAct Loop 解决它，会话因此能随时接受新指令，不必等上一条命令或任务结束（4.1 节）。第二个是按每个信道的习惯和人在那里的沟通方式，调整回复的内容与详细程度（4.2 节）。
4.1 全双工
经典 ReAct Loop 里，模型发起一次同步的 run() 工具调用，循环就阻塞，直到工具执行完、返回最终结果。这段时间里，会话无法响应用户的任何新输入。要消除阻塞，对话得从一问一答的半双工模式变成全双工模式。
做法是把耗时的命令和工具调用换成异步的 start() 和 stop()，把循环变成异步 ReAct Loop。调 start() 立刻返回「Started」，循环不等这个工具。工具在后台跑完，系统把最终结果当作一条新事件消息投递进会话。模型也可以根据上下文调 stop()，主动终止一个跑得太久的后台命令。
前台对话与后台任务解耦之后，耗时任务在后台跑的同时，Agent 也能响应人。新输入在当前推理步结束时就得到处理，而不是等后台工具全部完成。
DeepSeek Harness 已经实现了这套异步任务机制，但还没有默认开启。
4.2 多信道
人在群聊、邮件、GitHub 讨论里的沟通方式不一样。Agent 得为每个信道调整详细程度和表达方式。详尽的推理过程和工具调用日志，放在单人终端里合适，原样贴进群聊就会把人淹了。
这一点双层架构已经解决了一部分：每个任务冗长的推理过程和频繁的工具调用留在它自己的 Worker 会话里，不会直接进入外部信道；对外交互全部由 Router 层处理。在此之上，系统还要接上用户每天依赖的工作环境，并用提示词给每个信道定交互规范：
- IM 等即时通信信道：沟通要轻，尽量少打扰。像人类同事那样，只在需要决策或签核时通知，只问直接的问题，给简短的结论。他们验证过一条简单有效的硬规则：每条回复不超过 100 词。
- GitHub、邮件、文档这类异步信道：给结构化、信息密度高的输出。比如创建或更新 PR 时，按项目惯例写清问题背景、改动说明和验证结果。个人助手场景下，直接起草结构化的邮件和文档摘要。
五、计算、状态与执行环境分离
默认情况下，本地 Agent 把三样东西绑在一台设备上：跑 Agent Loop 的计算、必须持久保留的会话状态、以及执行环境（代码仓库、本地工具链这类）。设备一休眠或离线，Agent 就停了，也够不到别的设备上的环境。要让 Super-agent 持续在线、接得上任务需要的真实工作环境，他们借了计算机系统里的存算分离，分两步解耦。第一步，把计算和会话状态分开，让 Agent 不再被单台机器的生命周期绑住，在云端持续在线（5.1 节）。第二步，把云端的 Agent Loop 和状态很重的执行环境解耦，让环境留在原地，由 Agent 跨设备够过去（5.2 节）。
5.1 计算与状态分离
跑 Agent Loop 的计算可以无状态，只有会话状态需要持久。所以第一层解耦是把这份计算放进无状态、弹性的云容器，会话和其他持久状态放进数据库。容器可以水平扩容、重启、替换，持久存储保住会话和任务的连续性。本地设备休眠或离线，都不再让 Agent 停下，它在云端持续在线。
5.2 计算与执行环境分离
Agent Loop 和会话状态上了云，下一个问题是怎么够到任务需要的执行环境。模型用到的大量上下文来自针对代码仓库、本地文件、依赖服务等执行环境的工具调用。把上下文宽泛地看，执行环境本身就是上下文的一部分。
常见做法有两种。第一种是在云上起一个沙箱，拉下代码，试着重建并同步环境。但真实工作环境往往带着未提交的本地改动、私有凭据、对内网服务的依赖、特定的硬件或工具链。把这些全都同步过去代价很高，还容易漏东西。第二种是让用户放弃本地环境、把工作迁到云上，对很多用户来说这个迁移成本太高。
既然难复制、难同步的正是环境本身，那就不必把它跟 Agent Loop 一起搬到云上。第二层解耦是：Agent Loop 跑在云上，状态很重的执行环境留在原地。每个端点只需要一个轻量 daemon，它不保存会话状态，只做两件事——执行命令、返回结果。执行环境留在云外，Agent 按需从里面读上下文。
Anthropic 的 Decoupling the brain from the hands 走的是同一条路：harness 保持无状态，会话日志存在外面，执行环境通过统一接口按需连上。差别在目标场景。Anthropic 那篇讲的是托管服务，主要讨论按需创建的沙箱和客户 VPC 内的资源。DeepSeek 这边首先要接的是人们每天在用的个人机器——上面有未提交的改动、本地凭据，还可能只是偶尔在线。所以他们的设计支持 BYOM（Bring Your Own Machine），把用户自己的开发机或个人电脑连到云端 Agent；同时也支持云主机和按需创建的计算环境。
结果是，Agent 不再绑在一台机器上。它可以在执行设备之间切换，在任务需要的那个环境里跑命令、读上下文。它甚至能和只是间歇在线的设备配合：用户的个人设备一重新连上，云端 Agent 就自动开始并完成那些需要在这台设备上运行的任务。
六、Watchdog
要持续在线，光有第五节的存算分离还不够：系统得在长期运行中自动从异常里恢复。一个持续在线的分布式系统，只靠自身内部逻辑，很难长期可靠。它需要在主系统之外，有一个独立的 Control Loop。
Agent 系统需要的也不止传统的进程存活探测或监控脚本。很多异常不是崩溃：进程还跑着，但模型卡在无产出的循环里，或者偏离了目标。所以长期运行的 Agent 系统既要盯基础设施存活，也要盯任务进展。
他们这个外部 Control Loop 是一个独立的 Watchdog 会话，跑在主系统之外，由定时消息驱动。Watchdog 处理基础设施故障，比如 API 报错和状态恢复失败；它也用模型判断每个 Worker 是在实质推进，还是在原地打转、偏离整体目标。它及时修异常，并持续复查外部瞬时故障，直到问题解决。
因为 Watchdog 本身就是一个带全套工具的 Agent 会话，维护者可以用自然语言问它某件事为什么失败；也可以在系统运行期间让它纠正主系统的行为，比如增删提示词、调整触发规则。
七、初步实验
他们在两个层面做了初步实验：整个系统，以及单独的 Router 层。端到端实验对比双层架构与单会话设计，并测量订阅直通机制的效果（7.1 节）；第二个实验测 Router 层的批处理（7.2 节）。
实验用的是合成负载和简化环境，部分设置还可以更严谨，所以下面的结果只作参考。
7.1 消融实验
四个端到端设计同时跑，输入是一条群聊加 GitHub CI 的消息流。每次运行约 300 条消息，其中约 20 条是工作请求，其余是闲聊、追问、取消和 CI 消息。编码工作由一个只消耗时间的假工具模拟，所以这个实验测的是系统的调度与协调，不是它执行单个任务的能力。每个设计各跑 5 次。
四个设计是：Super-agent、去掉直通的 Super-agent、以及两个提示词不同的「单会话 + Subagent 工具」版本。
中性提示词是「在合适的时候用 subagent 处理一件工作……」；委派优先的提示词是「群聊的每条消息都会到你这里，所以你亲自跑的工作会不断被新消息打断。尽量把每件工作交给它自己的 subagent，你只做小事……」。
| 设计 | 任务完成时间 p50 / p95（分钟） | 每次运行的缓存读 token（全部会话） |
|---|---|---|
| Super-agent | 12.4 / 15.7 | 23.2M |
| 去掉直通的 Super-agent | 12.6 / 15.5 | 31.8M |
| 单会话 + Subagent 工具，中性提示词 | 20.4 / 29.5 | 6.1M |
| 单会话 + Subagent 工具，委派优先提示词 | 13.8 / 29.0 | 10.8M |
注：每个设计各跑 5 次。任务完成时间从工作请求算到它的结果消息。
Super-agent 的 p50 是 12.4 分钟，p95 是 15.7 分钟，明显快过单会话加 Subagent 工具。单会话设计慢，是因为在这个实验里它太依赖提示词：主会话经常决定自己干，完成时间又长又不稳。用中性提示词时，模型在 5 次里一次都没调 subagent，所有工作都在主会话里跑，新消息不断打断它，p95 到了 29.5 分钟。换成委派优先的提示词，5 次里有 4 次做了委派，完成时间有所下降，但整体仍比 Super-agent 长。剩下那次，模型判断这活「小」，自己做了，于是图上多出一条紫色长尾。
也就是说，单会话只能靠提示词工程和模型的临场判断来决定要不要委派。双层架构是在系统层面缓解这个问题：Router 不自己执行工作，每个 Worker 只收到它订阅的 Thread 里的消息。
因为要维持几个独立会话，Super-agent 每次运行用的缓存读 token 比单会话设计多——它是拿 token 换更短、更稳的完成时间。去掉直通的 Super-agent 完成时间跟原版差不多，但 Router 每次运行的决定数多了约 30%，缓存读 token 从 23.2M 涨到 31.8M，多了约 37%。所以在这个负载下，直通既不让任务更快，也不让任务更好，但它明显减少了 Router 会话的 token 用量和推理开销。
7.2 Router 层的批处理
为了弄清一个常驻 Router 会话在 2.1 节那套批处理下能扛多少负载，他们单独对 Router 层做了压力测试。Router 调真模型，Worker 用 mock 模型。他们把需要决策的 Trigger 到达速率一步步从每分钟约 1 条提到约 40 条，在每个速率下测平均批大小、单请求耗时、每个决策的摊销推理时间。一个决策可能跨几次 LLM 请求，因为 Router 可能推理几步、或者通过工具调用召回上下文之后才分派，所以每个决策的耗时可以超过单请求耗时。
需要决策的 Trigger 到达速率从每分钟约 1 条升到约 40 条时，平均批大小从 1.0 涨到 2.8，单请求耗时只从 2.5 秒涨到 3.9 秒，涨得比批大小慢，于是每个决策的摊销推理时间从 6.4 秒降到 1.6 秒。换句话说，外部事件成批涌入时，Router 层靠自动合并堆积的事件提高了有效吞吐。这也解释了 7.1 节的结果：去掉直通抬高了 Router 的峰值负载，可单个 Router 仍然没到吞吐上限。所以在他们目前的团队规模下，没必要为了吞吐提前分片 Router 层，那会牺牲全局上下文的连续性。
八、还没解决的问题
第二到第六节是构成 Super-agent 基本架构的五个模块，第七节的实验说明核心调度与路由机制在多任务并发下能工作。系统能保持相对简单，很大程度上是因为现阶段他们把工程设计和支持的场景都简化了。简化之外，四个方向的问题仍然开放：双层架构怎么扩（8.1 节）、没有会话时怎么和 Agent 协作（8.2 节）、上下文边界与 Agent 之间的通信（8.3 节）、安全与隐私（8.4 节）。
8.1 双层架构怎么扩
到目前为止，一个简单的组合以很低的工程成本覆盖了他们日常的大部分任务：单个常驻 Router 会话、订阅直通、Worker 之间不直接通信。一旦任务变得比一个 Router 会话能处理的更大、耦合更紧，每一层该长什么样，还没有定论。他们还需要测更多场景，弄清 Router 层该在什么时候分片、分多细，平级 Worker 该在什么时候直接通信、用什么样的协作拓扑。
系统与模型的联合设计是另一条值得探索的路。专门为 Router 层的工作训练模型——判断事件、批量分派、召回上下文——可能进一步提升 Router 层的吞吐和决策质量。
记忆同样限制系统能扩多远。常驻的 Router 层加上引用图上的链式召回，主要解决近期任务和会话历史的按需检索。一旦系统跑上几个月甚至更久，长期记忆就成了主要瓶颈。
8.2 没有 Session 时怎么和 Agent 协作
双层架构把多会话管理挡在用户视野之外，会话因此不再是产品设计的主要关注点。可一旦底下的执行会话不再直接对应界面上的对话，新问题就来了：任务该怎么呈现给用户，什么样的交互和项目管理方式是自然的。他们认为聊天窗口能成为交互中心，部分原因是路径依赖。更多交互可能会移进领域专属的界面，就像他们那个直接工作在 GitHub Issues 和 Pull Requests 里的实例。会话也可以继续留在界面里，因为用户习惯了，但用户看到的一段对话，不必对应底下的一个会话。
前面几节主要讲任务开始和验收这两端的人际交互。但在这个过渡期、模型还在快速变强的阶段，很多任务中途仍然需要人。产品设计怎么让用户在关键细节上分步介入，又不丢掉后台自主工作的效率，也值得探索。比如用户可以在后台执行的任何时刻介入、接管，或者和 Agent 实时协作。
总的来说，用户需要的项目管理和交互方式，跟他的工作领域和个人风格关系很大，最终设计大概率高度定制化。DeepSeek Harness 是开放架构，这让这种定制更容易支持。
8.3 上下文边界与 A2A
前面讨论的都是单个 Super-agent 实例的设计，并假设它范围内的所有信息汇在一个全局上下文里。当使用范围从个人、小团队扩到更大的组织，怎么给 Super-agent 划编制，实际上就是在决定哪些上下文共享、哪些隔离：需要共享上下文的部门共用一个实例，需要隔离的部门各用各的。
一旦组织内部或跨组织出现了彼此隔离的实例，跨边界的协作就是 A2A 通信，比如每个成员的个人 Agent 与团队共享的 Super-agent 之间。这里的 A2A 泛指 Agent 之间的通信，不是某个具体协议。不共享底层上下文、各自代表不同权限边界的 Agent 之间，怎么安全可靠地通信协作，还有待解决。
8.4 安全与隐私
第三节的事件驱动设计让更多环境能驱动 Agent，同时也让它暴露在更多不受信任的输入下。安全与隐私处理不好，Super-agent 就只能在一个极小的可信范围里工作。
比如第五节的设计把 Agent Loop 跑在云上、在执行设备上装轻量 daemon，它隐含假设云和端点互相信任。可云端 Agent Loop 持续接收外部事件，端点设备上则放着私有代码、敏感数据和本地凭据，把这两边连起来会带来显著的安全与隐私风险。一旦服务端入侵或提示词注入拿下了 Agent Loop，连在它上面的每台端点设备都可能被接管。
即使云从未被攻破，凭据也可能泄漏。只要端点上的凭据能进入模型的上下文，正常执行就可能把它们暴露出去。因此 Agent 需要一种「用得上凭据但从不看见凭据」的办法。这套架构要被更广泛地使用，就得在保住「从多种环境召回上下文」能力的同时，解决这些安全与隐私问题。
九、结语
这篇文章没有提出新理论，而是把计算机系统里的经典工程思想用到 Agent 系统的搭建上。随着技术发展，具体实现会变，但他们认为背后的系统设计思路会更持久地有用。他们那个基于这些思路、跑在 DeepSeek Harness 上的内部 Super-agent 实例已经在持续运行，每天参与问题复现与修复、响应代码评审，也参与 DeepSeek Harness 自身的开发。
回到开头的观察：大模型在单个任务上需要的人为干预越来越少，于是进一步提升生产力的瓶颈，正在移向人的注意力。双层架构、事件驱动、异步多信道交互、存算分离、外部 Watchdog 合起来，让系统接管了管理会话和同步上下文这些繁琐工作。人则可以往上走一步，从执行细节移到更高层的决策与验收。
这样搭出来的 Agent，不再只是一个等着指令的聊天窗口，而是常驻在人们使用的数字环境里的自主协作者。对个人来说，它可以是跨设备帮忙处理日常事务的个人助手；对团队来说，它成为研发流程的一部分，接过任务并把它往前推。他们相信，随着模型和系统架构一起演进，这种更自主的工作方式有希望成为人机协作的常态。
文中部分设计在 dsh-superagent-prototype 里实现。这个插件只是验证技术路线的原型，不是 DeepSeek 的正式产品。