1. 同时开 5 个 Agent，人先盯不过来

作者：DeepSeek Harness · 11-02 · 约 20 分钟

[!abstract] 全文速览

• 问题：单会话 Agent 跑长任务会阻塞；多开会话又会撞上人的注意力上限——原文给出的经验值是 3~5 个活跃会话。
• 方案：Router / Worker 两层架构，Router 只做接待、调度与全局记忆，Worker 在各自独立的上下文里执行；再叠加事件过滤、全双工交互、存算分离与外部 Watchdog。
• 实验：合成负载下，完整方案 p50 12.4 分钟、p95 15.7 分钟；代价是每轮 Cache-read Token 从 6.1M 升到 23.2M。
• 边界：数据来自合成负载与简化环境；原型插件 dsh-superagent-prototype 不是官方产品，异步任务默认未开启。
• 提醒：能并行不等于该并行。任务是否独立、写冲突能否隔离、人是否审得过来，决定了加并发是提效还是放大返工。

DeepSeek Harness 团队公开了一套名为“超级 Agent（Super-agent）”的系统架构设计。这套设计针对当前 Agent 落地中最现实的瓶颈——当任务变得复杂、多任务并发增加时，限制生产力的往往不再是大模型的单次推理能力，而是人类自己的注意力上限。

1.1. 一、一个人只能盯 3~5 个窗口：为什么今天的 Agent 跑不起多任务

不管是写代码还是日常办公，用过 Agent 的人都会遇到同一个尴尬局面：你在终端或网页里开了一个 Agent 跑长任务，整个窗口就进入了阻塞等待；你想同时推进第二件、第三件事，就只能手动多开几个标签页。

在现有的产品逻辑里，“会话（Session）”既是底层模型管理上下文的单位，又是人类用来管理项目的唯一单位。但人类的注意力极其有限，一个人通常最多只能同时盯住 3~5 个活跃会话。一旦并行的任务再多几个，你就必须充当“人肉调度器”，在各个窗口之间来回切换，回忆哪一个窗口聊到了哪一步、有没有遗漏上下文。

[!note] 3~5 是经验值
原文没有给出这个数字的来源，标题里的“5 个”取的是上限。它更接近团队观察，而不是经过验证的普遍常数。

试图给现有的单会话 Agent 挂载外部插件或命令行工具，并不能从根本上化解这个问题。长任务一跑，前端依然卡死；如果把多个任务混在同一个窗口里，不同任务的上下文会互相污染，最终导致模型回答变形；要是电脑合盖休眠，挂在本地的所有任务更是直接中断。

要打破这种限制，Agent 必须从单个、由人工一步步推着走的对话框，变成一个常驻后台、全天候在线、能自主并发推进多个复杂任务的实体。DeepSeek Harness 团队将这种系统形态定义为“超级 Agent（Super-agent）”，并提出了它的四大核心特征：

• 全场景连贯（Continuous）：无论你在即时通讯群聊（IM）、邮件还是 GitHub 评论区发起讨论，面对的都是同一个 Agent。它能跨平台记住前情，不会出现“在聊天软件里说了方案 A，切到代码平台它又忘干净了”的情况。
• 高并发产出（Productive）：多个复杂任务可以在后台并行推进，且互不干扰。上一个任务还在跑，前台就能立刻接收下一条新指令。
• 环境驱动主动干活（Proactive）：不再傻等人类按回车发号施令，而是全天候监听工作环境中的事件（如群聊里的 Bug 讨论、代码评审意见、自动化测试报警）。值得处理就主动接手解决，不值得处理就保持安静，绝不刷屏打扰。
• 长期在线与自愈（Persistent）：摆脱单台电脑的硬件限制，运行在云端，直连真实工作环境。遇到网络抖动或模型死循环等异常，能够依靠外部机制自动恢复。

同一个任务跨越聊天群与代码评审平台持续推进。用户先在 IM 群聊里提出字体独立设置的需求，维护者 @Super-agent 介入并创建 Pull Request；随后用户在 IM 追加字体大小设置，维护者和设计师在 GitHub PR 下提出折叠控件与排版改进，Agent 均在同一个 PR 中跟进修改，最后在群聊中同步合并结果。

无需人工 @ 提醒，Agent 自主从群聊对话中识别出具体缺陷。在用户群里，成员在没有 @ Agent 的情况下抱怨 macOS 窗口未激活时单选变重命名的 Bug；Agent 静默在后台复现问题并定位到底层 Electron 的 detail=2 机制，直接附带前后对比截图提交了修复 Pull Request。

没有任何单一的 ReAct 循环（思考-行动-观察循环）能够凭空兼顾这四点。要实现这种协作体验，必须将经典计算机体系结构中的工程思想借用到 Agent 系统中。

整个 Super-agent 架构由五个紧密配合的模块组成，分别对应并支撑上述四大特性：

• 两层架构：同时提供全场景连贯与高并发产出。
• 事件驱动：赋予其主动性。
• 全双工多渠道交互：保障每次人机交流的连贯与高效。
• 计算、状态与环境分离：让 Agent 不再绑死在一台机器上。
• 外部看门狗（Watchdog）：维持跨设备的长期在线与异常自愈能力。

支撑四大特性的五大系统架构模块全景。涵盖事件触发与两级过滤、保持全局连贯的 Router 路由层、负责上下文隔离执行的 Worker 层、全双工多渠道交互通道、计算与状态及环境分离的存储层，以及运行在外部的独立监控看门狗（Watchdog）。

1.2. 二、把决策与搬砖拆开：用两层架构化解连贯性与吞吐量的死结

在组织多任务会话时，系统面临一个最根本的技术取舍：在单个会话内，上下文连贯性与并发吞吐量不可兼得。

如果把所有事情都塞进同一个会话，这个会话能看到全局所有信息，连贯性最好；但大模型的一问一答是串行的，长任务一跑整个会话就会被卡住，吞吐量极低，而且不同任务的杂乱过程混合在一起，会直接稀释模型的注意力。反过来，如果每来一个新事件就开一个全新的会话，并发吞吐量确实上去了，但各会话之间缺乏共享记忆，得到的结果往往支离破碎；多个会话同时跑出来抢着在群里向用户汇报，更是会让交互彻底陷入混乱。

组织方式	连贯性	并发吞吐	主要代价
全部塞进一个会话	最好，能看到全局	低，长任务会卡住前台	注意力被混合任务稀释
每个事件开新会话	差，缺少共享记忆	高	结果碎片化，多会话抢着汇报
Router + Worker 两层	全局连贯	高	需要更多 Token 与调度设计

化解这个死结的办法，是将职责划分为逻辑上的“两层架构”：一个长期存活的 Router 层（路由层） 负责人类交互与全局统筹，维持连贯性；多个上下文严格隔离的 Worker 层（工作层） 负责高并发执行独立任务，提供吞吐量。

通过两层解耦实现全局连贯与局部高并发。中心的长周期 Router 层直接连接即时通讯、GitHub、邮件日历等各类交互渠道，维护共享记忆与全局调度；具体的耗时开发或排查任务被派发给彼此上下文隔离的 Worker 会话（Worker Session 1、2、3）。

这两层的分工边界非常清晰，且有着严格的纪律约束。

1.2.1. 路由层（Router Layer）：只当接待与调度，绝不亲自下场写代码

Router 层是整个系统的全局序列点、协调中心与全局记忆库。来自聊天软件、邮件或代码仓库的所有人类输入和外部事件，第一时间都汇聚到这里。

为了防止这个单点成为全系统的性能瓶颈，Router 层在设计上被严格限制为“只做沟通与分发，绝不执行具体任务”，系统甚至可以完全不给它配备命令行（Bash）等执行工具。它不需要像传统 Agent Team 的队长那样把一个复杂任务深度拆解成极其琐碎的执行步骤，它只判断高层次的目标该交给谁，并在宏观上记录任务之间的关联。

因为不承担重度推理，Router 层可以使用响应更快、成本更低的轻量模型。更关键的是，它在工程上拥有极强的 批处理（Batching）抗压能力：当外部突发事件密集到达时，正在进行推理的 Router 会将排队积攒的事件自动合并，统一注入到下一次大模型 API 调用中。在大模型的输入处理阶段（Prefill），这些合并的文本是在 GPU 上高度并行计算的，单次请求耗时增长极其缓慢，分摊到每个事件上的平均决策时间反而大幅下降。

1.2.2. 工作层（Worker Layer）：专心埋头搬砖，绝不直接打扰用户

Worker 层的每一个会话就是一个执行单元。每个 Worker 拥有完全独立的上下文窗口和完整的执行工具链，只专注搞定被派发给它的那一个任务。

因为 Worker 的输出直接决定了代码改动和分析的质量，所以这里通常调用能力最强的旗舰大模型。更重要的是，Worker 会话绝不允许直接向人类或公共渠道输出。它们的详细推理思考、中途报错和频繁的工具调用日志，全部被锁在会话内部，最终只向 Router 汇报阶段性状态和最终结果。用户在聊天群或 PR 评论里看到的，永远是 Router 整理后的精炼答复，不会被底层大量的命令行刷屏。

在 Worker 内部，如果遇到极度复杂的专项问题，单个 Worker 也可以自行开辟子 Agent 或本身作为一个 Agent Team，这种内部细节对上层的 Router 是完全透明的。这种结构同样适用于个人 Agent 场景：尽管用户面对的通常只有一个单页聊天窗口，但当同时讨论多个话题时，前台界面维持对话连贯，后台则能为每个话题派发独立的 Worker 并行推进任务和起草回复。

[!warning] 同一仓库并发写入，原文没有给出隔离方案
原文只说多个 Worker 订阅同一 Thread 后，会“在共享环境里自行察觉对方的动作、协调冲突”，没有提到 Git 工作树（worktree）一类的写入隔离。真要多个 Worker 同时改同一个仓库、甚至同一批文件，冲突怎么防、怎么合，仍需按具体实现核实。

1.3. 三、不等人类敲回车：四道机制让 Agent 主动干活

把架构拆成两层之后，驱动 Agent 运转的动力源也必须发生根本改变。它不再是人类在输入框里一条一条敲出来的 Prompt，而是来自日常协作软件中的半结构化事件流（Triggers，如群聊发言、邮件、日历日程、代码评审意见、自动化测试结果）。

让 Agent 直连真实工作环境，立刻会引来海量的噪音。为了让 Agent 做到“该出手时才出手”，事件从进入系统到被模型处理，需要经历四道关键机制。

1.3.1. 两级过滤（Event Filtering）：用代码规则挡掉绝大部分闲聊

日常群聊里绝大多数消息都是日常问候或无关闲聊（比如“中午吃什么”），并不需要 Agent 介入处理。如果把每一条消息都送进大模型做推理判断，不仅会有不可承受的延迟，还会产生巨大的 Token 账单。

借鉴计算机系统设计中的“快慢路径（Fast/Slow Path）”设计，系统将大模型语义理解视作灵活但昂贵的 Slow Path，而将确定性的过滤逻辑固化为极速、零成本的代码规则（Fast Path）：

• 代码规则过滤（Fast Path）：用普通程序代码做准入检查，比如检查消息来源频道、发件人群组、白名单列表等。比如某个闲聊群直接设为“忽略”，测试报警群设为“只对明确指令响应”。绝大多数无关事件在这一步就被代码直接掐掉，不消耗任何大模型 Token。
• 大模型语义过滤（Slow Path）：通过代码规则初筛的候选事件，才会交给轻量大模型。大模型根据写在 Prompt 里的判断准则，决定是保持沉默还是采取行动。这也为人类维护者提供了一个用自然语言随时热更新规则的入口。

代码规则与大模型语义判断结合的两级过滤。未监控群的闲聊（Trigger 1）被代码规则直接丢弃（0 Token）；普通讨论（Trigger 2）通过规则初筛但在语义判断阶段被静默；具体的缺陷报告（Trigger 3）通过两级过滤后正式进入后续路由。

1.3.2. 线程直通路由（Thread & Subscription Pass-through）：别让 Router 变成传话筒

如果每一个过滤后的事件都要由中央 Router 逐一审查转交，Router 依然会被海量的跟进消息淹没。

在真实的协作流中，针对同一个 PR、同一个讨论话题或同一封邮件的往来互动，自然构成了一条事件链，系统称之为 Thread（线程）。

连续相关的事件自然归入同一个 Thread 序列。左侧为群聊中针对缺陷由浅入深的讨论串（Thread #08），右侧为 GitHub 上针对 PR #128 的开单、CI 失败与代码评审评论串（Thread #15）。

当一个 Thread 的首条事件到达时，Router 会创建对应的 Worker 并让 Worker 直接订阅该 Thread。从这一刻起，事件路由直接分化为两条通道：

• 已订阅直通（Fast Path）：这个 Thread 之后产生的所有跟进事件（例如追问、CI 跑完后的日志、同事的代码评审），代码会通过旁路直接透传给负责该任务的 Worker，完全不需要 Router 再调用一次工具进行二次转交！
• 未订阅新事件（Slow Path）：Router 只保留全局视角的感知，把计算力集中在那些尚未分配给任何 Worker 的冷启动新事件上。

后续事件跳过 Router，直接透传已订阅的 Worker。初始事件（虚线）走 Slow Path 经由 Router 创建 Worker 并建立订阅；后续相同 Thread 内的事件（实线）走 Fast Path 直通 Worker，消除了中心节点的转发瓶颈。

这种订阅是多对多的。如果有两个 Worker 共同处理一个大型 PR，它们可以同时订阅同一个 Thread。这样一来，任何代码变更和讨论都会同时推送给它们，它们无需建立点对点的复杂通信，就能在共享环境里自行察觉对方的动作、协调冲突。

1.3.3. 上下文缓存与多跳召回（Inline & Spill + Chain of Recall）

面对源源不断流入的环境事件，大模型的上下文窗口就像计算机的内存缓存，极其宝贵。塞得太多，注意力被稀释；塞得太少，模型又得频繁调用工具去翻历史，增加延迟。

系统在这里引入了两个经典优化策略：Inline（内联） 与 Spill（外置）：

• 内联高频信息：根据时间与空间局部性，把最可能马上用到的信息直接塞进窗口，比如当前事件的 ID、核心摘要、正文前 50 个字，以及聊天记录的前后两条上下文。
• 外置超长内容：对于又长又冷门的内容（如几千行的报错日志），系统做硬性截断，把大头存放在窗口之外，只在上下文里留一个引用指针或 ID。模型需要看细节时，再通过工具按需拉取。

长周期运行时，Router 不可能把几个月前的历史记录全塞在窗口里。为了让用户在重提旧事时 Agent 能立刻想起来，系统利用对象之间的引用关系构建了一张“有向图”——每一个 Trigger、Thread、Worker 会话都有全局唯一 ID，它们彼此内联对方的 ID。

当用户提起一件旧事时，Router 可以顺着这些 ID 一跳一跳地精准捞取所需信息，这被称为 召回链（Chain of Recall）。

顺着对象 ID 引用图实现按需多跳召回。从当前的 Trigger #42 出发，根据其内联的 thread_id 调取 Thread #08；再从 Thread #08 关联的 worker_id 检索 Worker #03，进而追溯到相关的代码评审 Thread #15。全流程按需展开，无需在窗口中常驻巨量历史。

1.3.4. 推测执行（Acting Ahead）：不等确认，后台预先写好方案

日常协作中最省心的下属往往具备这种能力：听到团队在讨论某个问题，在领导还没正式拍板派活之前，他就已经在后台悄悄把复现环境搭好、把补丁代码写出来了。

Super-agent 借用了计算机系统的“推测执行（Speculative Execution）”：利用额外的后台算力，在人类还没明确下达指令前，根据环境信号预先在后台跑起来，以此减少人类等待和介入的频率。被证明有用的结果就交付，其余则直接丢弃。

在个人 Agent 场景中，当收到会议邀请邮件或待办消息时，Agent 可以在后台自动检查日历冲突、整理背景资料并起草回复，用户只需确认即可发送。在研发协同中同样如此：比如群里有人反馈波浪号 ~ 被错误渲染成删除线的问题，团队还在讨论该怎么修，Agent 已经在后台完成了代码修改并提交了 PR。只有当它确认复现了 Bug 并给出了完备补丁时，才会带着成果发言；如果中途发现无法复现，它就会悄悄清理现场并彻底闭嘴，绝不发出毫无意义的刷屏消息。

讨论尚未结束，推测执行已在后台完成代码验证并交付。群成员还在探讨波浪号渲染错误该改模型还是改规则，Agent 已经提交了「只把双波浪号 ~~ 当删除线」的补丁 PR，并精准解答了 Pandoc、markdown-it 与 GFM 规范之间的语法差异。

1.4. 四、边跑长任务边秒回：全双工通信与分渠道交互规范

解决了背后的调度与路由，前台的交互体验同样需要彻底重构。要让日常协作真正丝滑，必须解决两个最直观的痛点：后台跑长任务时前台不能被卡死，以及在不同聊天软件里不能像个复读机一样胡乱发日志。

1.4.1. 全双工通信（Full-Duplex）：把同步阻塞变成异步打断

在传统的 ReAct 模式下，大模型调用一个运行工具 run() 时，整个对话就死死挂起了。直到命令行跑完返回输出，模型才能说下一句话。在此期间，用户如果在输入框发新指令，Agent 根本无法理会。

为了实现真正的全双工交互，系统将原本单向阻塞的 run() 工具拆分成异步的 start() 和 stop()：

异步化工具调用打破了前台聊天的阻塞死锁。上方的传统 ReAct 在工具执行期间前台彻底卡死；下方的全双工机制中，调用 start() 之后前台立刻收到就绪通知，用户随时可以发送第二条消息，后台工具跑完后以新事件形态推送结果。

大模型发出 start() 命令后，系统立刻返回一个“已启动”的简短状态，当前推理步骤随即结束。前台对话窗口瞬间恢复响应，用户随时可以插话、追加条件或直接下达新任务；如果在审查过程中发现后台任务跑偏了，模型也可以主动调用 stop() 强行掐断耗时任务。后台真正运行完毕后，系统以一条全新的异步事件通知会话收尾，彻底实现了“前台秒回、后台长跑”。

1.4.2. 分渠道自适应：群聊要克制，代码平台要详实

不同工作场景对信息密度的要求天差地别：

• IM 即时通讯（飞书、钉钉、微信群）：追求极致轻量，非必要不打扰。必须像一个知进退的人类同事，只有在需要人类审批、做关键二选一决策时才发起询问，且结论必须先行。团队在实践中摸索出一条极其有效的硬规则：群聊单次回复长度严格限制在 100 词以内。
• 异步协作平台（GitHub、邮件、技术文档）：要求高度结构化、信息密集。提交一个 Pull Request 时，必须按照仓库规范写清背景、改动点分析、测试验证截图与潜在风险。

两层架构在这里发挥了天然优势：繁琐的工具链报错、代码行级排查全被封印在 Worker 会话内部，只有精炼后的结论才会由 Router 分渠道投递出去。

1.5. 五、电脑合盖也能跑：计算、状态与本地环境的两级解耦

传统的本地 Agent 把三样东西死死捆绑在一台机器上：运行推理循环的计算算力、维持任务记忆的会话状态，以及存有代码和工具链的本地运行环境。

只要笔记本合盖休眠或网络断开，整个 Agent 的生命周期就宣告终结；而且这种单机结构完全无法触达其他服务器或同事电脑上的环境。为了做到长期在线，系统借鉴了经典“存算分离”思想，进行了两级深度解耦。

将云端 Agent 循环与各端轻量执行环境解耦。云端运行无状态的 Agent Loop 弹性容器，会话与持久化数据托管在数据库中；下层的开发者电脑、云端环境和断续在线设备仅运行极轻量的守护进程（daemon）。

1.5.1. 第一级：计算与状态分离

运行 Agent 决策循环的容器被设计为完全无状态的，所有的会话记录、任务进度和全局记忆全部沉淀到底层独立的会话数据库（Session Database）中。

这样一来，云端容器就算发生故障重启、或者为了应对流量扩容进行迁移，任何会话的状态都不会丢失。Agent 不再受制于任何单台虚拟机的存活，获得了真正的云原生高可用性。

1.5.2. 第二级：计算与执行环境分离（自带设备 BYOM）

把计算和状态放到云端之后，最棘手的问题来了：Agent 怎么去跑开发者的代码？

业界的常规做法要么是逼用户把整个开发环境全盘迁移到云端容器中，要么是在云端启动一个临时沙箱、再尝试把代码库克隆过去。但这在实际研发中困难重重——开发者的本地电脑上往往有大量未提交的代码改动、复杂的内网调试代理、私有权限证书，以及极其个性化的依赖环境，要在云端沙箱完全镜像一份不仅成本高昂，而且极易遗漏配置。

Super-agent 采取了反向思路：既然重状态的本地开发环境最难搬迁，那就干脆不要搬。

系统让 Agent Loop 留在云端，而把本地执行环境原样留在开发者的电脑上。用户只需要在自己的电脑里运行一个极轻量的守护进程（Daemon）。这个 Daemon 本身没有任何 Agent 智能、也不存储任何会话状态，它唯一的职责就是作为“手脚”，接收来自云端 Agent 的具体终端指令并回传标准输出。

Anthropic 在《将大脑与双手解耦》（Decoupling the brain from the hands）中也采用了无状态 Harness 与外置环境按需连接的类似思路，但其面向托管服务，主要讨论按需创建的云端沙箱和客户 VPC 内部资源；而 Super-agent 优先要连接开发者日常使用、存有未提交代码和本地凭据且可能断续在线的个人电脑，因而重点支持“自带设备（Bring Your Own Machine，BYOM）”，同时也兼顾云端托管机器与按需创建的环境。

当开发者合上笔记本下班时，云端 Agent 继续监控群聊和 PR；一旦第二天开发者重新开机联网，Daemon 自动重新报到，云端积攒的本地测试任务立刻开始自动补跑。

1.6. 六、进程还活着，模型却卡住了：独立看门狗如何监控目标漂移

长期运行的分布式系统要想保持稳定，绝不能仅仅依赖系统内部的代码逻辑，必须在外部设立一套独立的控制循环。

在传统的服务端运维中，监控通常只看“进程心跳”——只要进程没崩溃，系统就认为它是健康的。但对于 Agent 系统而言，这种指标是远远不够的。Agent 最致命的异常往往不是进程死掉，而是“进程还活着，但大模型陷入了原地打转的死循环，或者在多次工具调用后彻底偏离了最初的目标（Goal Drift，目标漂移）”。

针对这种特有顽疾，系统在主业务流程之外独立部署了一个由定时任务驱动的 看门狗（Watchdog）会话：

• 双层体检机制：Watchdog 既做底层的连通性巡检（如 API 报错重试、数据库状态恢复），更会调取大模型来审查每一个 Worker 的实际产出记录，判断该 Worker 是否在真正取得实质性进展，还是在机械地重复犯错。
• 带工具的交互式纠偏：Watchdog 本身就是一个拥有完整工具权限的独立 Agent。运维工程师可以直接在聊天窗口里用大白话询问 Watchdog：“为什么刚才那个构建任务失败了？”；同时，工程师还可以通过它在系统运行中动态更新 Prompt 规则或调整触发阈值，实现免重启的热修复。

1.7. 七、初步实验：多任务分流不能靠 Prompt，要靠架构

为了验证核心调度与路由机制，团队在整套系统与单 Router 节点两个层面进行了初步实验。需要说明的是，这组实验使用的是合成负载与简化环境，部分设置有待更严谨，因此数据结果仅供参考。

1.7.1. 端到端任务消融实验

第一组实验在群聊与 GitHub 混合的模拟消息流下，对比了四种不同的系统设计。每轮测试包含约 300 条消息，其中约 20 条为工作请求，其余均为日常聊天、追加取消与 CI 状态消息。

四种参测方案包括：完整的 Super-agent、关闭了直通旁路的 Super-agent without Pass-through，以及两种依赖单一会话、仅通过 Prompt 尝试调用子 Agent 的传统方案（一组使用中立提示词，另一组使用强委派提示词）。

两层架构展现出极短且高度稳定的任务完成周期。Super-agent 及其无直通版本（蓝实线与绿虚线）在 30 分钟内平稳完成了绝大多数任务；而传统单会话即使配置了强委派提示词（紫色线），个别轮次依然拖长至近 50 分钟，形成明显的长尾。

系统设计方案	任务完成耗时 p50 / p95（分钟）	每轮总缓存读取 Token 数（Cache-read）
完整 Super-agent	12.4 / 15.7	23.2 M
Super-agent（无直通旁路）	12.6 / 15.5	31.8 M
传统单会话（中立提示词）	20.4 / 29.5	6.1 M
传统单会话（强委派提示词）	13.8 / 29.0	10.8 M

注：每种方案独立测试 5 轮。耗时统计区间为从收到工作需求到最终交付结果。为纯粹对比系统调度效率，代码执行耗时由统一时长工具模拟。

从实验数据中可以提炼出两个极其深刻的工程结论。

第一，多任务并发必须靠系统架构强行把关，绝不能寄托于大模型的自我节制。在单会话设计中，即便工程师千叮咛万嘱咐（强委派提示词），大模型在 5 轮测试中依然有 1 轮自作聪明地认为任务很小、选择亲自下场执行。这直接导致前台主会话被新涌入的聊天消息不断打断，p95 被拉长到 29.0 分钟，个别轮次甚至逼近 50 分钟。而在中立提示词下，单会话模型更是 5 轮全部选择自己单挑、一次子任务都没分发出去。只有两层架构从系统层剥离了 Router 的执行能力，才换来了 p50 12.4 分钟、p95 15.7 分钟的极速且稳定的表现。

第二，Super-agent 本质上是用更多的 Token 换取更短、更稳定的完成时间，而直通机制大幅削减了调度开销。由于维持多个独立会话，Super-agent 每轮总缓存读取 Token（23.2M）明显高于单会话方案（6.1M 与 10.8M），这是以算力换取执行速度与稳定性的必然代价。而对比表中前两行可以看出，关闭直通旁路后任务耗时变化不大（12.6 分钟对比 12.4 分钟，p95 15.5 对比 15.7），但由于每个跟进事件都要经由 Router 转手一次，Router 决策次数增加了约 30%，总缓存读取 Token 暴涨了约 37%（从 23.2M 升至 31.8M）。在这组负载下，直通机制虽未让任务跑得更快，却大幅削减了 Router 会话的 Token 消耗与推理开销。

1.7.2. 路由层高并发压力测试

第二组实验针对核心的单个 Router 节点进行了极限施压：当外部每分钟需要决策的事件数从 1 次逐渐拉高到 40 次时，观察系统的响应曲线。

突发高并发下，大模型的输入并行度反而摊薄了单次决策时间。左图显示随着事件到达率从 1 上升到 40 次/分，平均批大小从 1.0 增至 2.8，单次请求耗时仅增至 3.9 秒；右图显示单决策摊销耗时从 6.4 秒降至 1.6 秒。

数据展现出了批处理带来的性能优势。需要先理解的是，一次分发决策可能跨越多次大模型 API 请求（Router 在派发前可能需要多步推理，或通过工具调用按需召回上下文），因此单决策耗时会高于单次请求耗时。

同时，由于 Router 仅处理轻量交互与分发，每一步通常是“长输入、短输出”，合并到同一请求中的多个事件在 Prefill 阶段高度并行计算，单次请求耗时增长极其缓慢（从 2.5 秒增至 3.9 秒），远慢于批大小的增长（从 1.0 增至 2.8）。这意味着，分摊到每一个具体决策上的平均推理时间，反而从 6.4 秒下降到了 1.6 秒。当然，这种批处理收益存在上限，取决于上下文窗口长度以及模型在单轮中能够准确处理的事件数量。

外部事件越是集中爆发，系统的摊销处理效率反而越高。在这组压测负载下，单个常驻的 Router 会话足以扛住日常并发；至少目前没有必要过早做复杂的横向分片。

原文在这一节末尾附有一个可交互的调度与吞吐量沙盒（可调事件到达率、切换架构模式，观察批处理与直通对延迟和 Token 的影响）。沙盒在纯 Markdown 环境里无法运行，这里只保留它在默认参数（事件到达率 10 次/分）下的读数：

沙盒指标（10 次/分）	读数
平均批处理大小	1.5
单决策摊销耗时	4.5 秒
任务完成耗时 p50 / p95	12.4 / 15.7 分钟
每轮 Cache-read Token	23.2 M
直通旁路的节省	相对关闭直通（31.8M）约 27%

沙盒曲线是示意图，端点和表格数字来自上一节的初步实验。

[!warning] 并行不是免费的
这组数据里，两层架构是用 23.2M 的 Cache-read Token 换 12.4 分钟的中位完成时间，单会话只要 6.1M。任务彼此不独立、改动会撞车，或者人根本审不过来时，把并发数加上去，只会把排队和返工一起放大。

1.8. 八、走向真实世界的四大阻碍：分片、接管界面、上下文边界与安全

这套设计目前仅有部分在原型插件 dsh-superagent-prototype 中实现。需要说明的是，该插件只是验证技术路线的原型，并非 DeepSeek 官方产品，其中的异步任务机制也尚未默认开启。

尽管团队内部基于这些理念搭建的 Super-agent 实例每天都在协助修复缺陷与推进开发，但如果要让它走出当前受控环境、迈向更大规模的通用场景，还有四个尚未彻底攻破的技术深水区。

1.8.1. 规模化扩展与数月级长期记忆

单 Router 结构配合 Chain of Recall 召回链，目前已足以应对当前规模团队的日常协作。但一旦任务规模与耦合度超过单个 Router 会话的承受极限，Router 层终究需要进行横向分片（Sharding）。然而分片越细，各分片之间的共享记忆与上下文就越割裂。

此外，当前的按需召回图谱主要解决的是“找回几周前的相关任务”。当系统连续运行数月乃至数年时，海量陈旧信息的沉淀将触及长程记忆的理论上限，如何在不遗失关键技术资产的前提下对全局记忆进行有效的蒸馏与归档，目前仍无定论。

1.8.2. 扔掉会话框后，人该怎么中途接管？

两层架构将底层的会话细节对用户完全屏蔽了。但这也带来了一个新的产品设计挑战：当底层的会话不再等同于聊天窗口时，人与 Agent 的协作界面该长成什么样？

很多时候，聊天对话框纯粹是过去十年人机交互的路径依赖。对于研发而言，最自然的交互场所本来就是代码平台的 Pull Request、代码高亮行或 Issue。更重要的是，在模型能力尚未达到绝对完美的今天，人类往往需要在 Agent 后台自主推进的过程中适时“插手接管”。如何设计一种产品形态，既不破坏后台自主推测执行的效率，又能让人类随时随地在关键技术细节上轻松无缝介入，是下一步人机协同体验的探索核心。

1.8.3. 上下文边界与跨主体协作（A2A）

在一个大型组织中，不可能把所有机密数据与代码统统倒进一个全局的超级 Agent 中。财务、法务、核心算法与普通业务团队之间有着严格的权限隔离。

这就意味着未来必然会并存多个独立的 Super-agent 实例。跨越这些隔离边界的协作属于 Agent 间通信（A2A），例如每位成员的个人 Agent 与团队共享的 Super-agent 之间的协作。这里的 A2A 泛指 Agent 之间的通信协作，并不特指某种具体协议。在这些互不共享底层上下文、各自代表不同权限边界的 Agent 之间，如何实现安全可靠的通信与协作，仍是一个有待解决的开放问题。

1.8.4. 最致命的软肋：云端大脑直连本地设备的安全与凭证风险

这套架构最大的工程便利在于支持开发者“自带设备（BYOM）”，由云端大脑远程指挥本地机器上的轻量 Daemon。然而，这一设计在安全专家眼里是高度敏感的。

在全天候开放的工作环境中，Agent 每天接收来自公开群聊、开源社区 PR 和外部邮件的非受信事件流。一旦系统遭遇恶意的 Prompt 注入攻击（比如在 PR 代码或群消息中植入隐藏的越狱指令），被攻击者劫持的云端 Agent 循环就可能反向向开发者的个人电脑下发破坏性指令，造成严重的本地代码篡改或系统提权。

与此同时，本地开发环境常驻有各类私有 Git Token、数据库密码与内网访问证书。如果这些凭证直接被读入模型的上下文窗口，哪怕云端未被攻破，在模型正常的推理输出中也极易发生凭证意外泄露。如何在让模型正常调取工具执行任务的同时，做到对本地敏感凭据“可用而绝对不可见”，是这套架构迈向商业化之前必须筑牢的安全底线。

1.9. 九、结语：从人肉调度到自主协作

这套 Super-agent 架构并未提出全新的理论，而是将计算机系统领域的经典工程思想应用到了 Agent 系统构建中。具体的技术实现虽会随模型与工具的演进而改变，但其背后的系统设计思想却具有更长期的价值。

当大模型在单项任务上越来越少依赖人工介入时，生产力提升的瓶颈已经转移到了人类有限的注意力上。通过两层架构、事件驱动、全双工交互、存算分离与外部看门狗的协同，系统接管了繁琐的会话管理与上下文同步，人类得以从底层执行细节中抽身，聚焦于更高层次的决策与把关。在这个形态下，Agent 不再是一个被动等待敲回车的聊天窗口，而是一个真正长期常驻、主动并行的数字化协作者。

[!tip] 一句话结论
瓶颈已经从模型的单次能力，转移到人能同时跟进的会话数。解法不是让人多开窗口，而是让系统接管会话管理与上下文同步，人只对目标和结果负责。

这是原文的设计主张；支撑它的实验是合成负载下的初步结果，不是通用定律。

1.10. 附：8 张速记卡

原文结尾附有 8 张阅读器卡片，「回原文」链接指向原站锚点，在本地笔记里无效；这里只保留卡片上的文字。

• 01 / 判断｜一人最多盯 3~5 个 Agent 会话：再多就别手动切窗口，把会话交给系统管，人只跟一个 Agent 说话。
• 02 / 判断｜派活的不动手，动手的不跟人说话：派活的用轻量模型、不配 Bash；动手的用旗舰模型，只向派活的汇报。
• 03 / 行动｜代码先挡闲聊，剩下的才交给模型：按频道、发件人、白名单写规则，闲聊群直接忽略，这一步不花 Token。
• 04 / 行动｜长任务别阻塞——启动就返回，跑完再通知：把 run() 拆成 start() 和 stop()，等待时用户能插话，跑偏了能掐断。
• 05 / 反常识｜Agent 放云端，开发环境留在你电脑：电脑只跑一个轻量守护进程；合盖后云端继续盯群和 PR，开机再补跑本地测试。
• 06 / 判断｜进程活着不等于 Agent 还在干正事：另开一个定时的看门狗会话，让模型查产出——有实质进展，还是在重复犯错。
• 07 / 反常识｜Prompt 强调委派，模型仍会自己干：拿掉 Router 的执行工具；合成负载下 p95 由 29.0 分钟降到 15.7，Token 由 10.8M 升到 23.2M。
• 08 / 判断｜常驻 Agent 被注入，可能接管你电脑：公开群、外部 PR 接进来前先想清——本地凭证要能用，但不能进模型上下文。