Super-agent 设计探索：DeepSeek Harness 想让你忘记 Session 的存在
2026-11-01 · 最新速递
本文挂在 最新速递。原文发布于 2026-10-31。
一个被低估的瓶颈：人的注意力
过去一年，以 Coding Agent 为代表的单任务 Agent 已经证明，模型能使用工具解决复杂问题，并且越来越少需要人类持续监控和逐步干预。随着人类在底层执行中的参与减少，人的角色正逐步上移到更高层的决策与验收。但 DeepSeek Harness 团队最近发布的技术长文《Super-agent 设计探索：迈向更自主的 Agent 系统》提出了一个尖锐的判断：现有主流 Agent 的设计，上限已经被人的注意力卡住了。
现在的 Agent 工作模式仍然以单一 Session 为基本单位，不同 Session 彼此独立。用户并行推进多项工作时，必须手动切换并记住各个 Session 的上下文。文章给出一个观察数字：一个人通常只能同时跟进 3 到 5 个活跃 Session。在这种设计下，单任务的上限取决于模型能力，多任务的上限取决于人的注意力。
如果只在现有的本地单会话 Agent 上借助 CLI、MCP 或外部连接器做简单扩展，Agent 虽然也能接入外部消息，但仍受制于单会话同步阻塞、多任务上下文混乱、本地设备离线即停止运行等问题，需要大量人工维护。要突破这些限制，需要打破 Agent 与单次手动会话的绑定，使其成为一个能跨会话保持上下文、同时推进多项复杂任务且互不干扰的连续实体。他们把这种 Agent 形态及其系统架构称为 Super-agent。
四个基础特征
文章把 Super-agent 定义为具备四个基础特征的 Agent：连续、高效、主动、持久。
连续，指用户可以直接在 IM 聊天、GitHub 评论等熟悉的工作界面与它交互，感觉始终只存在一个 Agent，不需要去想 “Session X 的上下文中是否有 Y 信息”。比如用户先在 IM 上提出采用方案 A、随后在 GitHub Pull Request 评论里改为方案 B，它能理解并调整执行方向。高效，指交互响应迅速，同时能并行、高质量地完成多个复杂任务，无需等上一个命令或任务完成，就能接受下一条指令。主动，指无需等待用户逐条下达指令，能持续观察环境事件并主动推进值得处理的事项，不需要介入时则保持安静。持久，指始终在线、直接接入用户真实的工作环境，并在长期运行中遇到异常时自动恢复。
文章强调，单个 ReAct Loop 无法同时支持这四个特征。但相似的设计约束会导出相似的架构选择：无论是面向个人的助手，还是面向软件开发的 Agent，只要目标是构建持续在线、并发响应环境事件的系统，底层就可能会采用相近的架构。这一过程中面临的许多问题与传统计算机系统长期探讨的问题具有很高的相似性，经典系统设计思想在这里同样适用。
五个模块构成基本框架
文章认为以下五个模块构成了支撑四个基础特征的基本框架：通过双层架构兼顾连续交互与高效并发，通过事件驱动实现主动响应，通过面向人的交互在交互过程中同时做到连续与高效，并通过计算、状态与环境的分离及 Watchdog 实现跨设备的持久在线与异常自愈。
双层架构：Router 层与 Worker 层
要同时实现跨信道的连续交互与多任务的高效并发，系统在底层会话组织上面临连续性与吞吐量之间的根本权衡。如果每条事件都交给同一个 Session 处理，虽然上下文最连续，但受限于单个 ReAct Loop 串行执行的速度上限，任务完成耗时长、吞吐低，且多任务中间细节混杂影响效果。反过来，如果每条事件都直接新开独立 Session，虽然并发吞吐最高，但缺少全局上下文会让各 Session 的结果彼此割裂，多个 Session 各自向用户响应也会造成交互混乱。
解法是把 “维护全局连续性” 与 “高并发执行” 拆分到两个层级：由常驻的 Router 层统一承接人类交互与全局协调，由上下文隔离的 Worker 层并发执行具体任务。Router 层是常驻的全局路由层，负责承接所有入口的人类交互，所有跨任务的信息与决策都在这里汇总，充当全局的序点、协调点和记忆。为了避免成为性能瓶颈，Router 层不直接执行具体任务，只负责人类交互与任务分派，甚至可以不配备 Bash 工具。从实践来看，Router 层的任务常常没有想象中复杂，使用较轻量的模型往往就能兼顾速度与效果。
一个关键洞察：这种中心节点分派多个执行节点的结构，表面与常见的 Agent Team 相似，但侧重点不同。Agent Team 用于单个复杂任务内部的步骤拆解与角色协作，子步骤耦合紧，Team Lead 需要深入理解任务细节并高频协调，自身承担很重的推理负载。而 Super-agent 的 Router 层只处理任务之间的高层关联与分派，无需介入单任务内部的拆解。反过来，如果通过提示词约束一个 Agent Team 的主会话不亲自执行具体任务、仅负责对外交互并把不同任务分派给成员独立推进，它也可以视为这种双层架构。
在内部实现上，Router 层选择了最直接的单个常驻 LLM Session 作为核心实现。它并没有表面看起来那么容易成为吞吐瓶颈，因为上一轮推理期间到达的环境事件会积压下来、在下一轮一并处理，形成批处理：事件流平稳时 Trigger 逐条进入，延迟低；事件密集涌入时，积压的多条 Trigger 自动合并，在一次 LLM 调用中一并注入。Router Session 只做轻量交互与分派，每步通常是长输入、短输出，合并进一次调用会在 Prefill 阶段并行计算，单次请求耗时的增长远慢于批处理大小。所以在一定范围内，积压越多，单个决定分摊的推理时间越低。当规模进一步扩大时，Router 层内部也可以设计为多层过滤结构或水平切分，此时本质上还是连续性与吞吐量的权衡。
Worker 层由负责具体执行的会话组成，各 Worker 彼此上下文隔离，挂载完整执行工具，在独立上下文中专注完成单一任务。由于 Worker Session 直接决定任务结果与代码质量，通常需要配置能力最强的模型。Worker 不直接与人类交互，推理过程和工具调用不直接输出到外部信道，而是向 Router 层汇报状态、由 Router 层统一向用户回复，从而避免多个会话各自回复的混乱。多任务并发时各 Worker 独立推进，同层 Worker 之间通常不需要直接通信；冲突往往出现在同一个 Pull Request 等共享工作环境，只要它们都订阅了对应 Thread，就会收到相同事件通知，从而有机会自行发现和解决冲突，少数跨任务协同由 Router 层中转。每个 Worker Session 内部也不必局限于单个会话：执行复杂单任务时可以再创建 Subagent，也可以本身就是一个 Agent Team，这些对上层 Router 层保持透明。
文章在这里点出一个很有价值的观点：让用户手动管理 Session，在很大程度上是从底层 LLM API 延续下来的设计惯性。Session 应当是系统的实现细节，而不应是用户的认知负担。在现有设计中，Session 同时承载了技术上的上下文管理与面向用户的项目管理；将产品形态与底层 Session 解耦后，面向用户的项目管理便不再受 Session 限制，向用户暴露怎样的交互与任务管理方式成了一个独立的产品问题。
事件驱动：从提示词到 Trigger
要让 Super-agent 具备主动性，首先需要改变系统的驱动方式。驱动 Agent 的主要输入不再是人类逐条键入的提示词，而是环境中的半结构化事件。群聊消息、邮件与日程提醒、代码审查评论、CI 运行结果等环境事件被称为 Trigger。通过监听并响应 Trigger，Agent 不必等人类下达指令才被动执行一次。围绕一条环境事件的生命周期，文章依次讨论了四个递进的问题：事件过滤、事件路由、上下文组织、投机执行。
事件过滤。接入真实的群聊与代码平台后，事件流呈现出显著的 “高噪音、低触发率” 特征，绝大多数日常消息并不需要 Agent 介入。如果对每个事件都调用大模型从头判断，延迟和算力成本都难以承受。文章借鉴计算机系统的 Fast Path / Slow Path 思想：大模型推理是一条灵活但高成本的 Slow Path，将已经明确且稳定的高频判断固化为确定性代码，则构成低延迟低成本的 Fast Path。两级过滤机制即：程序层策略先做确定性准入检查（针对事件来源、群组范围、用户或机器人白名单），在调用模型前滤除大部分无关消息；通过准入的候选事件再交给 LLM，由它根据用提示词编写的策略和上下文判断是否需要行动。语义层同时作为面向人类的自然语言扩展点，方便随时通过提示词开关或新增策略。
事件路由。如果已分配任务的每个后续事件仍需经由 Router 层转发，全局节点会承受大量负载。因此 Fast / Slow Path 同样适用于路由：全局 Router 层仅负责新任务的冷启动与跨任务协调，已确定归属关系的后续事件由程序直接发往对应 Worker。同一个 GitHub Pull Request、同一个 IM 话题或同一封往来邮件串下的连续事件构成一条 Thread。Router 层根据 Thread 初始事件创建 Worker Session 后，该 Worker 直接订阅对应 Thread，形成两条路径：同一 Thread 下的后续事件由程序直通已订阅的 Worker，无需 Router 再次调用工具转发；Router 层仍可观测所有事件以掌握全局状态，但只负责判断和分派尚未被订阅的新事件。Thread 与 Worker 之间的订阅是多对多的：一个 Worker 可以订阅多个相关 Thread，同一个 Thread 也可以被多个 Worker 订阅，使它们无需点对点通信也有机会获知彼此操作并自行解决冲突。
上下文组织。系统输入从有限的人类提示词转向环境持续产生的半结构化事件后，注入过多会挤占窗口、稀释模型注意力，注入过少又会迫使模型反复调用工具读取，增加执行步数。文章把有限的上下文窗口当作 Cache 来管理，借用编译优化与计算机系统的概念归纳为两个基本操作：Inline 是把近期很可能用到的信息直接内联进当前上下文窗口，省去额外的工具调用往返；Spill 是把超出窗口预算或低频使用的完整信息留在窗口之外，仅在窗口内保留引用或摘要，供模型按需读取。结合局部性思想，可以逐步优化：从最少信息开始（只提供当前对象的 ID 和内容摘要），利用局部性逐步 Inline 关联信息（先附上紧密关联对象的 ID，再附带时空相邻的内容，例如内容前 50 字、IM 消息的前后相邻消息、代码评论所在讨论中的相邻评论），超出上限则 Spill（截断超出部分并保留续读入口）。将 Inline 与 Spill 一致地应用到各类对象后，就得到按需展开的多跳检索机制，即链式召回：系统为 Trigger、Thread 和 Worker Session 等对象赋予唯一 ID，注入时内联紧密关联对象的 ID，使对象在底层构成引用图，模型从当前事件出发顺着引用关系逐跳按需召回上下文。
投机执行。借鉴计算机系统中的投机执行思想，Agent 可以在还不确定结果是否会被采用时，根据环境信号在后台提前尝试，通过消耗额外后台算力减少人类的等待与介入成本，结果有价值就交付，没有价值就丢弃。个人助手场景下，收到会议邀约邮件或待办消息时，Agent 可以先在后台核对日程冲突、搜集背景资料并备好回复草稿，待用户过目后直接确认发出。研发协作场景中，他们在公司内部用户群配置了一条 “静默复现并修复” 策略：群里有人反馈问题或讨论改动方案时，Agent 先在后台尝试复现并寻找修复方案，只有在确认问题并找到简单修复方案后才把结果交付给用户，否则全程保持安静。
面向人的交互：全双工与多信道
经典 ReAct Loop 中，模型发起一次同步的 run() 工具调用后，循环会阻塞，直到工具执行完毕返回最终结果，期间会话无法响应任何新的用户输入。要消除这一阻塞，需要把对话从一问一答的半双工模式转变为全双工模式。做法是把耗时的命令与子任务工具调用改为异步的 start() 和 stop()，构成异步 ReAct Loop：模型调用 start() 后立即收到 “已启动” 返回，循环不再等待该工具；后台工具执行完成后，系统把最终结果作为一条新的事件消息投递进会话；模型也可以根据上下文调用 stop() 主动终止执行过长的后台命令。由此前台对话响应与后台任务执行解耦，Agent 在后台运行耗时任务的同时也能响应人类输入。文章注明，这一异步任务机制已在 DeepSeek Harness 中实现，但尚未默认开启。
多信道交互方面，不同工作信道具有不同信息密度与交互习惯，系统的输出需要与之匹配。如果把面向单人终端的交互方式直接搬入群聊，把冗长推理过程与密集工具调用原样输出，在多人协作中极易造成信息过载。双层架构已经解决了一部分：冗长推理与密集工具调用被隔离在 Worker Session 内部，由 Router 层统一对外交互。在此基础上，IM 等即时通讯信道侧重低打扰的轻量沟通，像人类同事一样只在需要决策或验收时发送通知，只问直接问题、给简短结论。文中验证过的一条简单有效硬性规定是单次回复不超过 100 词。GitHub、邮件与文档等异步信道侧重结构化、高信息密度的异步交付，例如创建或更新 Pull Request 时按项目规范撰写完整的问题背景、改动说明与验证结果。
计算、状态与环境的分离
现有本地 Agent 默认把推进 Agent Loop 的计算、需要持久保存的会话状态、以及代码仓库与本地工具链等执行环境绑定在同一台设备上。一旦设备休眠或离线，Agent 就会停止运行，且无法访问其他设备上的环境。文章借鉴存算分离思想，分两步解耦：第一步把推进 Agent Loop 的计算与持久化的会话状态分离，计算做成无状态的、放入云端无状态弹性计算容器，Session 等持久化状态存入数据库。无状态计算容器可以水平扩展、重启或替换，会话与任务的连续性由持久化存储保障，从而摆脱单台本地设备的生命周期限制，实现云端持久在线。
第二步再把云端的 Agent Loop 与重状态的执行环境解耦。模型工作所需的上下文很大一部分要通过工具调用从代码仓库、本地文件、依赖服务等执行环境中获取，广义的上下文也包含执行环境本身。常见的两种思路都不理想：在云端启动沙箱、拉取代码重建环境，成本高且容易遗漏未提交的本地修改、私有凭据、内网服务依赖等；直接要求用户放弃本地环境迁往云端工作，迁移成本过高。既然难以复制的是环境本身，就不必让执行环境跟着 Agent Loop 上云：让 Agent Loop 在云端运行，重状态执行环境留在原地，仅在端侧部署一个不保存会话状态的轻量 daemon，它只负责执行命令与返回结果，相当于把执行环境留在云端之外，由 Agent 按需读取其中的上下文。
文章明确指出，这一思路与 Anthropic 提出的 “脑手分离” 一致：同样让 harness 保持无状态，把会话日志存放在 harness 之外，通过统一接口按需接入执行环境。区别在于场景：Anthropic 那篇文章描述的是托管服务，主要讨论按需创建的沙箱和客户 VPC 内的资源；这里首先要接入的是用户日常使用、可能间歇在线的个人机器，上面有未提交的修改和本地凭据。因此这种设计既支持 BYOM（Bring Your Own Machine），即把用户日常使用的开发机或个人电脑接入云端 Agent，也支持接入云端托管机器或按需创建的计算环境。一个 Agent 不再受限于单台机器，可以在不同执行设备之间切换，甚至能支持间歇在线的设备：在用户的某台个人设备重新上线后，由云端 Agent 自动触发并完成需要在该设备上执行的任务。
Watchdog：主系统之外的控制回路
要实现持久在线，除了存算分离，还需要让系统在长期运行中能从异常中自动恢复。持久在线的分布式系统很难仅靠主系统内部逻辑保证长期可靠运行，需要在主系统之外引入独立的外部控制回路（Control Loop）。同时，在 Agent 系统中，仅靠传统进程存活探测或监控脚本是不够的，因为许多异常并非进程崩溃，而是模型在执行中陷入无效循环或偏离目标。因此长期运行的 Agent 系统不仅需要监控基础设施的存活，还需要监控任务本身的进展。
文章的做法是在主系统外部配置一个独立的 Watchdog Session，用定时消息驱动它构成外部 Control Loop。Watchdog 除了处理接口报错、状态恢复失败等基础设施故障，还会由模型判断各个 Worker 是否有实质进展、方向是否偏离整体目标，发现异常时及时介入修复，遇到外部偶发故障则持续复查直至恢复正常。由于 Watchdog 本身也是一个具备完整工具能力的 Agent Session，维护者可以用自然语言向它询问故障原因，也可以让它在线修正主系统的行为，例如增删提示词、调整触发规则。
初步实验：双层架构到底值不值
文章用两类实验评估了核心调度与路由设计。消融实验用群聊和 GitHub CI 消息流同时驱动四种端到端方案，单次实验约 300 条消息，其中约 20 条是工作请求，其余是闲聊、跟进、叫停和 CI 消息；编码工作用只消耗时间的工具代替，衡量的是系统的调度与协作能力而非单任务执行能力。对比方案包括 Super-agent、去掉直通的 Super-agent、以及两种提示词配置下的单 Session + Subagent 工具（中性提示与提示优先委派）。
从任务完成时间看，Super-agent 的 p50 与 p95 分别为 12.4 分钟与 15.7 分钟，显著优于带 Subagent 工具的单 Session。带 Subagent 的单 Session 受提示词影响较大：中性提示下，模型在 5 次运行中一次都没有调用 Subagent，所有工作都在主 Session 中进行并不断被新消息打断，p95 达到 29.5 分钟；改为提示优先委派后，5 次运行中有 4 次进行了委派，完成时间缩短但整体仍慢于 Super-agent，且剩下 1 次它判断工作 “很小” 而选择自己执行，形成了长尾。结论是：相比于在单 Session 中依赖提示词工程和模型临场判断分不分工，双层架构通过让 Router 不直接执行具体工作、Worker 仅接收所订阅 Thread 的消息，在系统层面上缓解了这个问题。
从系统开销看，Super-agent 维护多个独立会话，单次实验的读缓存 token 高于单 Session，是以更多 token 消耗换取更短且更稳定的完成时间。而在 Super-agent 内部去掉直通机制后，任务完成时间与完整版基本一致，但单次实验中 Router 需要做出的决定增加了约 30%，总读缓存 token 从 2323 万增加到 3177 万，增幅约 37%。这表明在实验负载下，直通机制不提高任务完成质量与速度，但为 Router Session 节省了可观的 token 与推理开销。
Router 层批处理压测中，让 Router 调用真实模型、Worker 使用 Mock 模型，把需要决定的 Trigger 到达速率从每分钟约 1 条逐步提升至约 40 条：平均 batch 大小从 1.0 升至 2.8，单次请求耗时仅从 2.5 秒增至 3.9 秒，增长慢于 batch 大小，单个决定分摊的推理时间从 6.4 秒降至 1.6 秒。这说明当外部事件突发拥堵时，Router 层能通过自动合并积压事件提高有效吞吐，也解释了为何在团队规模下无需过早对 Router 层做水平切分而牺牲全局上下文的连续性。
四个开放问题
这套系统之所以能以较低复杂度运作，很大程度上因为当前阶段做了一系列工程和场景简化。文章坦承了超出简化适用范围后的四个开放问题。一是双层架构如何扩展：Router 层何时需要水平切分、粒度如何划分，同层 Worker 之间何时需要引入直接通信、采用何种协作拓扑，仍有待检验；系统与模型的协同设计也值得探索，针对 Router 层的事件判别、批量分派与上下文召回做专项训练可能进一步提升吞吐与决策性能。二是脱离 Session 之后如何与 Agent 协作：当底层执行会话不再直接对应用户界面上的会话后，如何向用户呈现任务并提供自然的交互与项目管理形式成为新问题。以聊天窗口为中心的交互在一定程度上是路径依赖的结果，交互可能更多发生在领域特化的界面中（例如直接在 GitHub 的 Issue 和 Pull Request 里工作）；同时，过渡期内许多任务仍需要人类中途参与，如何在产品设计中兼顾用户对关键细节的逐步干预与后台自主推进的效率同样值得探索。
三是如何划分上下文边界并进行 A2A 协作：前文讨论的是单个 Super-agent 实例内部的设计，默认其服务范围内的信息汇总在同一个全局上下文中；当使用范围从个人或小团队扩展到更大的组织时，组织在决定如何配备 Super-agent 时实际上是在划分上下文共享与隔离的边界。一旦存在多个彼此隔离的实例，例如每个成员各自的个人助手与团队共用的 Super-agent 之间，跨边界的协同就是 Agent 间通信（A2A），在互不共享底层上下文、各自代表不同权限边界的前提下，如何实现安全可靠的 A2A 通信与协作仍需探索。四是安全与隐私：事件驱动设计让 Agent 能被更广泛的环境驱动，也增加了接触不可信输入的风险；云端 Agent Loop 持续接入外部环境事件、端侧设备上又存有私有代码与本地凭据时，跨设备连接引入了显著隐患。一旦云端 Agent Loop 遭遇服务端入侵或提示词注入而被攻破，其连接的全部端侧设备都面临被控制的潜在风险；即使云端未被攻破，只要端侧环境中的凭据能进入模型上下文，正常执行过程中同样存在凭据泄露风险，因此还需要设计机制让 Agent 能在完全不接触凭据本身的情况下使用凭据。
怎么理解这篇文章
文章结尾有一段值得反复读的话：整套设计并没有提出全新的理论，而是将计算机系统中经典的工程思想应用到了 Agent 系统的构建中。双层架构对应的是控制面与数据面分离、路由与执行解耦；事件驱动对应的是事件溯源与消息队列；Inline 与 Spill 对应的是缓存分层与局部性；投机执行直接就是 CPU 的乱序执行思想；存算分离对应的是数据库与无状态计算的经典架构；Watchdog 对应的是外部控制回路。把 Agent 系统当作一个分布式系统来设计，是这篇文章最大的方法论价值。
对做 Agent 工程的人，这篇文章给出了几个可以直接迁移的判断：Session 应该是系统的实现细节，而不是用户的认知负担；单个常驻 Router + 订阅直通 + Worker 隔离，是以较小工程代价覆盖大多数日常任务的现实组合；Router 层的批处理能力意味着很多系统不需要过早引入复杂路由；多任务的上限不在模型，而在人的注意力，系统设计的目标是接管那些让人分心的上下文管理工作。
目前，DeepSeek Harness 团队基于这套思路构建的内部 Super-agent 实例已经在持续运行，日常参与问题复现与修复、代码审查响应与 DeepSeek Harness 自身的迭代。文章的部分设计已在 dsh-superagent-prototype 中实现，该插件只是为了验证技术路线提供的原型，并非 DeepSeek 的正式产品。
参考来源
DeepSeek Harness 团队《Super-agent 设计探索：迈向更自主的 Agent 系统》（微信公众号，Yujia Qiao 执笔，2026-10 发布）。原型仓库 dsh-superagent-prototype。