一个人只能跟 3~5 个会话：DeepSeek Super-agent 用六个权衡，把 Agent 从"窗口"改成"系统"

10 月 31 日晚，DeepSeek Harness 团队发布技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，同步开源原型代码（仓库 deepseek-ai/dsh-superagent-prototype）。

结论先行：这不是一个新模型，也不是一个新产品，而是一份Agent 运行时的架构说明书。它的核心主张是——当模型执行单个任务已经不太需要人盯着，瓶颈就转移到了人的注意力上；一个人的并发上限大约是 3~5 个活跃会话，所以会话管理和上下文同步必须从人手上移到系统层面。

文章真正的价值不在"多智能体协作"这个概念（这个概念已经讲烂了），而在于它把 Agent 架构里的每一个取舍都摊开，并且大部分配了消融数据。这一点在同类的架构文章里很少见——多数文章只告诉你"我们分了两层"，不告诉你"不分两层会怎样"。

本文按六个权衡逐个拆，每个权衡给出"两难是什么、DeepSeek 选了哪条、代价是什么"，最后给一套自建常驻 Agent 系统时的自检清单。

先说一条重要的前提，它决定了后面所有讨论的边界：官方在文末明确声明，这是面向工程实践的架构思路探讨，不是对现有产品功能的介绍。 实验也基于合成负载与简化环境。所以下文所有数字都应当作"方向性证据"，不是生产结论。

前提：瓶颈从哪里转移了

过去一年 Coding Agent 解决的主要矛盾是"模型能不能用工具把事做完"。这个矛盾基本解决了，人的角色上移到定目标和验收。

于是新的矛盾出现了：人管得过来吗。

文章给的经验数字是：一个人通常只能同时跟进 3~5 个活跃会话。超过这个数，人就开始丢上下文、忘记进度、重复交代前情。也就是说，多任务的天花板从"模型能力"变成了"人的注意力"。

这个判断没有引用外部研究，属于团队的经验估计，但方向不难验证——用任何 Agent 工具同时开五个会话干五件事，半小时后你大概率记不清哪件事进行到哪一步。

由此推出 Super-agent 要满足的四个特征：

文章的判断是：单个 ReAct Loop 无法同时支持这四个特征，底层需要一套专门的架构。而这些问题与传统计算机系统长期探讨的问题高度相似——所以调度、缓存、存算分离、看门狗这些经典思想可以直接搬过来。

这句话是全文的骨架。后面六个权衡，本质都是把操作系统课上的老问题在 Agent 场景里重做一遍。

权衡一：连续与吞吐不可兼得，所以要拆两层

这是整篇的核心两难：

• 全交给一个 Session：上下文最连续，但单 ReAct Loop 串行、吞吐低、多个任务的细节混在一起。
• 全开独立 Session：吞吐最高，但缺全局上下文、结果割裂、交互混乱。

DeepSeek 的解法是把"维护全局连续性"和"高并发执行"拆成两层。分工如下：

这张表里有两个反直觉的设计，值得单独说。

第一，Router 不配 Bash 工具，甚至可以不配。 这不是省事，是防止全局节点变成瓶颈。Router 一旦能亲自执行任务，它就会开始执行任务，然后所有请求排在这一个节点后面。团队的做法是用架构约束它的能力边界——让它没有工具可用，比让它"不要用工具"可靠得多。

第二，Router 用轻量模型，Worker 用最强模型。 这跟"哪里都上最强模型"的直觉相反。文章的解释是：Router 的任务常常没有想象中复杂，主要是判断该分给谁、要不要回、要不要叫停，这类判断用轻模型足够；而 Worker 直接决定任务结果和代码质量，必须上最强的。

顺带一个与"Agent Team"的区别，容易混淆但很重要：

文章也承认，如果把一个 Agent Team 的主会话用提示词约束成"只对外交互、不亲自执行"，效果上等价于双层架构。区别在于前者靠提示词，后者靠架构。

权衡二：全局节点必然拥堵，靠批处理摊薄

双层架构把压力集中到了 Router——所有入口交互、所有跨任务决策都要过它。这是设计上的必然代价。

常规思路是加机器、加实例。DeepSeek 走的是另一条：承认它会排队，然后利用排队。

机制是这样的：Router 每步的典型形态是"长输入、短输出"——读一堆事件和上下文，输出一个分派决定。当事件密集涌入、Router 出现排队时，上一轮推理期间积压的多条 Trigger 会自动合并，在下一轮 LLM 调用中一并注入。由于合并发生在 Prefill 阶段，是并行计算的，单次请求耗时增长远慢于批处理大小的增长。

结果是：一定范围内，积压越多，单个决定分摊的推理时间越低。

官方给的数字：单个决定分摊的推理时间从 6.4 秒降到 1.6 秒，降幅 75%。

这个设计的边界也写清楚了：上限取决于上下文长度，以及模型在一轮中能准确处理多少条 Trigger。也就是说它不是无限的——堆到一定程度，模型在一轮里会开始漏掉或误判某些事件。文章没有给这个上限的具体数值。

同一逻辑还用在另一个地方：两级过滤（见权衡四）和 Router 层的水平扩展。文章提到，当规模进一步扩大、单个会话确实承载不了时，Router 层内部可以设计为多层过滤结构，或水平切分为多个会话。但随之而来的是一个新权衡——切分粒度越细，Router 并发吞吐越高，但分片之间的记忆与上下文连续性越低。 在全局记忆问题被解决之前，这个权衡始终存在。

这句话是全文最诚实的一句。它等于承认：分层只是把问题挪了位置，没有消除它。

权衡三：注入得太多会稀释注意力，太少会逼模型反复读

这条属于工程细节里最容易被忽略、但实操中影响最大的一类。

文章有一句原话值得单独拎出来：浪费上下文窗口，就是浪费模型的智能。

传统 Agent 的输入是人写的提示词，长度可控、信息密度高。Super-agent 的输入变成环境持续产生的半结构化事件，密度天然稀。于是"往窗口里塞多少"成了必须设计的事。

它的解法是把上下文窗口当 Cache 管理，用两个基本操作：

具体策略是三个递进动作：

1. 从最少信息开始：最初只给当前对象的 ID 和内容摘要，不给全文。
2. 利用局部性逐步 Inline：根据访问局部性，把近期很可能用到的关联信息逐步内联进来。
3. 链式召回：需要旧任务信息时，顺着 ID 逐跳找回，而不是把历史全量塞进窗口。

这套逻辑跟 CPU 的缓存分层是一回事：L1 放热数据（Inline），主存放冷数据（Spill），通过 ID 寻址（链式召回）。文章自己也是这么类比的。

对实际开发的启示：不要把"上下文管理"当成"多塞点历史"。塞得多不等于记得住，反而容易让模型在无关信息里迷失。

权衡四：每个后续事件都过 Router，等于自己给自己造瓶颈

这是全文数据最硬的一组消融。

问题：Router 负责维持跨信道连续性。但如果一个已分配任务的每个后续事件仍要经 Router 转发，这个全局节点依然承压——你只是把拥堵从第一层挪到了第二层。

解法是把 Fast Path / Slow Path 的思想用在事件路由上，核心概念是 Thread：

同一个 GitHub PR、同一个 IM 话题、或同一封往来邮件串下的连续事件，构成一条事件流，称为 Thread。

路由分两条路径：

几个设计细节值得注意：

• Router 仍然观测所有事件，以掌握全局状态；它只是不再"转发"已订阅的事件。观测与转发是两件事，这一点很容易做混淆。
• 订阅是多对多关系：一个 Worker 可订阅多个 Thread，一个 Thread 可被多个 Worker 订阅。
• 冲突靠共享订阅自解：多个 Worker 在同一 PR 上发生交集时，该 Thread 的新事件会同时直通给所有订阅者，它们无需点对点通信就有机会发现彼此的操作并自行解决冲突。少数跨任务协同才由 Router 中转。
• Worker 可以退订：如果新事件超出当前任务范围，Worker 可取消订阅或交回 Router 重新分派。这一条是防止"订阅了不该订阅的东西"导致上下文被污染。

消融数据（去掉订阅直通机制后的对照）：

这两个数是本文最有说服力的地方。它证明订阅直通不是锦上添花的优化，而是直接影响系统成本结构的设计——没有它，Router 要重复读一遍它已经知道的上下文，token 白烧 37%。

权衡五：主动与打扰只隔一线，所以要先做后报、但只在有结果时开口

比并行更值得关注的是主动性。群聊消息、邮件、日程提醒、GitHub 评论、CI 结果，都可以成为触发行动的事件（Trigger）。

但"主动"的另一面是"烦人"。绝大多数群聊消息与 Agent 无关，如果每条都响应，它很快会被踢出群。

第一道闸：两级过滤

沿用 Fast Path / Slow Path 的思路，把过滤拆成两层：

这个拆法还有一个附带好处：语义层同时是面向人类的自然语言扩展点。想加一条策略，改提示词就行，不用改代码。这在运维上是很大的差别——策略由业务方自己维护，不用等研发排期。

第二道闸：投机执行

过滤只决定"要不要看"，不决定"要不要做"。真正让主动性可控的，是投机执行（speculative execution）：

结果是否会被采用尚不确定时，先在后台提前尝试，有价值再提交，没有就放弃。

内部配置的策略叫"静默复现并修复"：有人反馈 Bug 时，Agent 先在后台复现、分析原因，确认问题确实存在且找到简单可行的修复方法之后才提交，否则保持安静。

这个"否则保持安静"是整个设计的灵魂。它把"主动"从"必须说话"降级成"有资格说话才说话"。同一条逻辑用在个人助手上：收到会议邀请后，先核对日程冲突、整理相关资料、备好回复草稿——做完了才提示，做不完就不打扰。

从工程角度看，投机执行的代价是提前计算的开销：可能复现了半天发现不是 Bug，这部分算力就白扔了。文章没有给出这个浪费率的量化，但从"确认才提交"的保守策略看，他们明显选择了"少打扰"优先于"少浪费"。

权衡六：要常驻就得离开设备，要离开设备就得拆状态

前面五个权衡都在单机内解决。第六个跨越设备。

问题：如果 Agent 跑在本地进程里，电脑一关机它就死了，四个特征里的"持久"直接不成立。

解法是存算分离：

效果：电脑暂时离线，云端 Agent 仍能维持任务状态，设备重新上线后继续执行。

这里有一个容易被误解的点：这不是"把 Agent 搬到云上"那么简单，而是把会话从"进程内存里的东西"变成"可以持久化、可以迁移、可以恢复的运行时状态"。这个转变的意义在于——只有状态被外化，异常恢复才成为可能。

看门狗与异步

配套两个机制：

• 外部 Watchdog：独立进程检查任务是否陷入无效循环，并尝试修复。注意"外部"两个字——如果看门狗和被监督的循环在同一个进程里，循环卡死时看门狗也一起卡死，等于没有。
• 异步 ReAct Loop：执行耗时任务时仍能响应新指令。官方明确说这个机制已在 DeepSeek Harness 中实现，但尚未默认开启。

最后这半句信息量很大。它说明并发收益与资源开销之间的平衡点还没找到，工程上仍在权衡。一个已经实现了却不默认开启的功能，通常意味着"开了之后代价不小"。

实验怎么读：一组漂亮的数字，与三个必须打问号的地方

实验设置：模拟约 300 条消息、20 项工作请求的协作环境，对比 Super-agent 与传统单 Session + Subagent 方案，每种配置重复 5 次。

P95 降低 46.8% 是个很好的数字。对生产系统来说，尾延迟比中位数重要得多——中位数只说明典型任务，P95 才说明"最差的那 5% 会不会让人放弃"。

但有三个地方必须打问号：

问号一：对照组是否被公平对待。
对照组的条件是"中性提示下"的单 Session + Subagent。所谓"中性提示"，通常意味着没有针对多任务场景做专门的提示词优化。而 Super-agent 是把架构整个改了。用"改架构"对"没优化的提示词"，这个对比天然有利于前者。 公平的对照应该是"精心设计的单 Session 提示词 + Subagent"，那个数字文章没给。

问号二：样本量与场景复杂度。
300 条消息、20 项请求、重复 5 次。这个规模能看出方向，但离生产差得远。真实协作环境的消息量是数量级更高的，而且事件分布极不均匀——工作日早上和深夜的密度可能差十倍。批处理机制在"突发密集"下的表现，比在合成负载下重要得多。

问号三：成本是拿 token 换来的。
文章自己承认：“它是拿更多 token 来换取时间和稳定性。“这句话很关键。并行执行意味着同时有多个 Worker 在烧 token，投机执行意味着可能白烧。所以正确的比较不是"15.7 vs 29.5 分钟”，而是"15.7 分钟 + 多少 token vs 29.5 分钟 + 多少 token”。文章给了直通省下的那 37%，但没给总账单。

另外还有一处口径需要留意：那组消融数据（Router 决定数 +30%、缓存 token +37%）方向一致，但两个百分比不是同一个基数算出来的，不能相互印证。+30% 是决策次数，+37% 是缓存 token 量，前者是后者的一个成因但不是全部。

可复用：自建常驻 Agent 系统要回答的九个问题

这套架构最值得抄的不是代码，是它提出的问题清单。如果你打算自己搭一套常驻 Agent（不管是个人助手还是团队工具），下面九个问题每个都要有答案，答不上来的那个就是你的瓶颈所在：

九个问题里，第 3、5、6 个是最容易省钱的三处，也是大多数自建方案最先做错的三处。它们的共同点是：都可以用"更少的模型调用"换"同样的效果"，而实现成本都不高。

未披露清单

按三档标一下，避免把推测当事实：

最后一条要划重点：文章反复强调这是架构思路探讨，不是产品功能介绍。这意味着现在的代码是原型，不是可以直接上生产的框架。权限体系、审计日志、可观测性、成本治理、状态存储一致性，这些企业部署绕不开的东西，原型里基本都没有。

收口：这次发布真正改变了什么

有三件事值得记住。

第一，Agent 的评价指标换了。 过去比的是单轮问答准确率、工具调用成功率；当 Agent 进入多任务、长周期场景后，真正决定体验的是任务完成时间、尾延迟、token 成本、人工接管率、异常恢复能力。12.4 / 15.7 / 29.5 这组数字之所以重要，不是因为它好看，而是因为它第一次把 Agent 当成系统去测，而不是当成模型去测。

第二，架构层面的"抄作业"空间打开了。 这篇文章里没有一个新技术，批处理、缓存分层、存算分离、看门狗、投机执行、快速路径/慢速路径——全是操作系统和编译原理课上的旧东西。DeepSeek 做的事情是把它们逐一映射到 Agent 场景，然后验证映射是对的。对工程团队来说，这比发布一个新模型更有用：新模型你复现不了，旧思想你能直接用。

第三，也是最容易被忽略的一点——它承认了自己的局限。 “切分粒度越细，连续性越低，在全局记忆问题被解决前这个权衡始终存在”、“异步 ReAct Loop 尚未默认开启”、“这是架构探讨不是产品介绍”、“实验基于合成负载”。一篇架构文章愿意把这些写在正文里，比多给两个跑分可信得多。

如果要给一个判断：这套东西现在不能拿来直接上生产，但它提出的九个问题，值得每个在做 Agent 系统的团队对照自查一遍。 答得上的问题不用管，答不上的那一个，就是你明天要改的地方。