Super-agent 设计探索：DeepSeek 如何让 Agent 摆脱「Session 的引力」

过去一年，Coding Agent 已经证明了一件事：只要给模型工具，它能自己把复杂问题解决掉，人越来越不需要盯着每一步。

但另一个瓶颈紧接着浮出水面——不是模型不够聪明，而是人跟不上。

DeepSeek Harness 团队在 2026 年 10 月 31 日发布的这篇《Super-agent 设计探索》，把这个瓶颈讲得很直白：单任务的上限取决于模型能力，多任务的上限取决于人的注意力。据他们观察，一个人通常只能同时跟进 3 到 5 个活跃 Session。

这篇文章值得认真读的原因在于，它不是在讲某个产品的功能，而是在讲一套系统架构：如果把 Agent 从「一次手动会话」里解放出来，让它成为一个持续在线、能并发推进多任务、还会自己找活干的实体，底层需要什么样的设计？

本文是对原文的完整梳理与解读，涉及双层架构、事件驱动、全双工交互、存算分离与 Watchdog 五个模块，以及一组初步实验结果。

一、先看清问题：Agent 被「Session」锁住了

现有主流 Agent 的工作模式，基本单位是 Session（会话），而不同 Session 之间彼此独立。

这带来三个连锁问题：

1. 上下文要人肉搬运。你并行推进三件事，就得在三个窗口之间来回切换，还得自己记住「方案 A 是在哪个窗口里定的」。
2. 同步阻塞。经典 ReAct Loop 里，模型发起一次 run() 调用后会一直阻塞到工具返回，这期间你跟它说什么都没用。
3. 设备离线即停摆。计算、状态、执行环境全绑在一台机器上，笔记本一合盖，Agent 就没了。

很多团队的做法是给本地单会话 Agent 加 CLI、MCP 或外部连接器，让它能接入 IM、能读邮件。但原文的判断是：这样做仍然受制于单会话同步阻塞、多任务上下文混乱、本地设备离线即停止运行，需要大量人工维护。

换句话说，在旧结构上加接口，解决不了结构本身的问题。

二、Super-agent 的四个基础特征

原文把这类新形态的 Agent 及其系统架构称为 Super-agent，并给出四个基础特征。这四个词看着像宣传语，其实是四组很硬的技术约束：

特征	用户侧感受	技术侧要求
连续	始终只有一个 Agent，不用想「Session X 里有没有 Y 信息」	跨信道共享全局上下文
高效	响应快，能同时推进多个复杂任务，不用等上一条命令跑完	并发执行 + 非阻塞交互
主动	会自己盯着环境变化推进该做的事，不需要你时保持安静	事件驱动，而非提示词驱动
持久	始终在线，直接接入你真实的工作环境，出异常能自愈	计算、状态、环境解耦 + 外部控制回路

一个具体的例子能说明「连续」到底意味着什么：用户先在 IM 里说「这个用方案 A」，随后在 GitHub PR 评论里改成「还是方案 B 吧」——它能理解这是同一个任务的两次表态，并调整执行方向。在单 Session 模型下，这需要人自己保证两条信息落在同一个窗口里。

而「主动」的一个真实例子是：这个实例会持续观察公共群聊，在没有任何人 @ 它的情况下，自己定位到问题根因并提交修复 PR。

单个 ReAct Loop 显然撑不起这四个特征。原文的观察是：相似的设计约束会导出相似的架构选择——无论是个人助手还是研发协作 Agent，只要目标是「持续在线、并发响应环境事件」，底层架构就会趋同。

三、整体架构：五个模块对应四个特征

五个模块的分工很清晰，而且每个模块都对应着解决某一个特征：

• 双层架构（第 2 节）→ 同时拿到连续与高效
• 事件驱动（第 3 节）→ 拿到主动
• 面向人的交互（第 4 节）→ 在交互过程中同时做到连续与高效
• 计算、状态与环境的分离（第 5 节）+ Watchdog（第 6 节）→ 拿到持久

下面逐个拆。

四、双层架构：把「连续性」和「吞吐量」拆到两层

这里是全文最关键的一个权衡（Trade-off）。

如果所有事件都塞进同一个 Session：上下文最连续，但受限于单个 ReAct Loop 的串行执行速度，吞吐低；多任务的中间细节还会混在一起，互相污染。

如果每条事件都新开一个 Session：并发吞吐最高，但任务之间只要不完全独立，缺全局上下文就会让结果彼此割裂；多个 Session 各自回复用户，交互也会乱。

解法是把这两件事拆开：由常驻的 Router 层统一承接人类交互与全局协调，由上下文隔离的 Worker 层并发执行具体任务。

4.1 Router 层：只做决策，不做执行

Router 是全局的路由层，所有跨任务的信息与决策都在这里汇总，它充当全局的序点（Sequence Point）、协调点和记忆。

为了避免这个全局节点变成性能瓶颈，原文做了一个很克制的设计选择：Router 层不直接执行具体任务，只负责人类交互与任务分派，甚至可以不配备 Bash 工具。

这一点和常见的 Agent Team 有本质区别。Agent Team 的 Team Lead 通常要深入理解任务细节、拆解子任务、高频协调成员，自身推理负载很重。而 Super-agent 的 Router 只处理任务之间的高层关联与分派，不介入单任务内部的拆解。

反过来看，原文还提了一个有意思的等价说法：如果一个 Agent Team 通过提示词约束主会话「不亲自干活，只负责对外交互并把任务分派给成员」，那它其实也就变成了这种双层架构。

实践中的一个反直觉结论是：Router 层用轻量模型往往就够，速度和效果都能兼顾。

4.2 批处理：单 Router 为什么没有成为瓶颈

这是我在读原文时最欣赏的一段——它没有停在「设计如此」，而是解释了为什么单点不会崩。

关键机制是：上一轮推理期间到达的环境事件（Trigger）会积压下来，在下一轮一并处理，形成批处理（Batching）。

• 事件流平稳时，Trigger 逐条进入 Router Session，单次响应延迟低；
• 事件密集涌入、Router 开始排队时，积压的多条 Trigger 会自动合并，在下一次 LLM 调用中一起注入。

为什么合并不会让单次请求变慢很多？因为 Router 每步是长输入、短输出，合并多条 Trigger 后，Prefill 阶段是并行计算的，单次请求耗时的增长远慢于批处理大小的增长。结果就是：在一定范围内，积压越多，单个决定分摊的推理时间越低。

上限当然存在：上下文长度，以及模型在一轮里能准确处理多少条 Trigger。

规模再大怎么办？原文给的方案是 Router 层内部做多层过滤，或**水平切分（Sharding）**为多个会话。但这里又回到同一个权衡：切得越细，并发吞吐越高，分片之间的记忆与上下文连续性越低。在全局记忆问题被解决之前，这个权衡始终存在。

4.3 Worker 层：隔离上下文，专心干活

Worker 是真正执行的会话，彼此上下文隔离，挂载完整执行工具，在独立上下文中专注完成单一任务。因为直接决定任务结果与代码质量，通常要配能力最强的模型。

两个细节值得注意：

Worker 不直接与人类交互。 它的推理过程和工具调用不输出到外部信道，只向 Router 汇报状态，由 Router 统一回复。这样既保住了并发度，又避免了多个会话各自回复的混乱。

同层 Worker 之间通常不需要直接通信。 那它们怎么解决冲突？靠共享的 Thread 订阅——多个 Worker 在同一个 PR 上干活时，都订阅了这个 Thread，就会收到相同的事件通知，从而有机会自行发现并解决冲突。少数跨任务协同才由 Router 中转。

另外，每个 Worker 内部也不必局限于单会话：执行复杂任务时可以再创建 Subagent，或者本身就是一个 Agent Team，这些对 Router 都是透明的。

4.4 Session 应该是系统的实现细节，不是用户的认知负担

这一节是我认为全文最有产品洞察力的一句话：

让用户手动管理 Session，在很大程度上是从底层 LLM API 延续下来的设计惯性；Session 应当是系统的实现细节，而不应是用户的认知负担。

在旧设计里，Session 同时承担了两件事：技术上的上下文管理，和面向用户的项目管理。一旦把产品形态与底层 Session 解耦，「向用户暴露怎样的交互与任务管理方式」就变成了一个独立的产品问题——这个问题原文没有给出答案，留在了第 8 节的开放问题里。

五、事件驱动：从「人喂提示词」到「环境喂事件」

要让 Agent 具备主动性，首先得换掉驱动方式：主要输入不再是人在 Session 里逐条键入的提示词，而是环境中的半结构化事件。

群聊消息、邮件与日程提醒、代码审查评论、CI 运行结果——这些在 Super-agent 里统称 Trigger。

一条 Trigger 从进入系统到被处理，要回答四个递进的问题。

5.1 怎么过滤噪音：Fast Path / Slow Path

接入真实群聊和代码平台后，事件流呈现出典型的「高噪音、低触发率」特征——绝大多数日常消息根本不需要 Agent 介入。每条都调大模型判断，延迟和成本都不可接受。

解法直接借鉴了计算机系统里的 Fast Path / Slow Path 思想：大模型推理是灵活但高成本的 Slow Path，把已经明确且稳定的高频判断固化成确定性代码，就是低延迟、低成本的 Fast Path。

• 程序层策略（Fast Path）：按事件来源、群组范围、用户或机器人白名单等确定性条件做快速准入检查。比如对不同来源分别设置「仅响应明确请求」「作为候选事件」「直接忽略」。
• 语义层策略（Slow Path）：通过准入的候选事件交给 LLM，按提示词里的策略和上下文判断要不要行动。

语义层还有一个附带价值：它是面向人类的自然语言扩展点，想加策略、改策略，写提示词就行，不用改代码。

5.2 怎么路由：Thread 与订阅直通

过滤之后是路由。如果已分配任务的每条后续事件都要经 Router 转发，这个全局节点又会承受大量负载——Fast/Slow Path 的思路在这里同样适用。

先明确一个概念：同一个 GitHub PR、同一个 IM 话题、同一封往来邮件串下的连续事件，构成一条事件流，叫 Thread。

• 已订阅（Fast Path）：同一 Thread 的后续事件由程序直通给已订阅的 Worker，Router 不再介入转发。若新事件超出当前任务范围，Worker 也可以取消订阅或交回 Router 重新分派。
• 未订阅（Slow Path）：Router 仍能观测所有事件以掌握全局状态，但只负责判断和分派尚未被订阅的新事件。

这里有个容易被忽略的设计：Thread 与 Worker 之间的订阅是多对多的。一个 Worker 可以订阅多个 Thread，一个 Thread 也可以被多个 Worker 订阅。当多个 Worker 在同一个工作环境里发生交集时，新事件会同时直通给所有订阅者——这就是 4.3 节里「Worker 之间无需点对点通信也能自行解决冲突」的实现基础。

5.3 怎么组织上下文：把窗口当 Cache 管

这是全文技术密度最高的一节。核心判断只有一句：浪费上下文窗口，就是浪费模型的智能。

系统输入从有限的人类提示词变成了环境持续产生的半结构化事件，注入多少信息就成了关键设计。注入太多挤占窗口、稀释注意力；注入太少又迫使模型反复调工具读取，增加执行步数。

原文借编译优化与计算机系统的概念，归纳出两个基本操作：

• Inline：把近期很可能用到的信息直接内联进当前窗口，省掉额外的工具调用往返。
• Spill：把超出预算或低频使用的完整信息留在窗口外，窗口内只保留引用或摘要，按需读取。

再叠加经典的**局部性（Locality）**思想，就有了三步优化路径：

1. 从最少信息开始：只给当前对象的 ID 和内容摘要。
2. 利用局部性逐步 Inline：先附紧密关联对象的 ID，再附时空相邻的内容——内容前 50 字、IM 消息的前后相邻消息与所回复的那条、代码评论所在评审讨论中的相邻评论。
3. 超出上限则 Spill：对长内容设一个较小的长度上限，超出部分截断并保留续读入口，模型需要时再调工具读全。

把 Inline & Spill 一致地应用到系统里各类对象上，就自然得到了一个按需展开的多跳检索机制——链式召回（Chain of Recall）。

具体做法是：给 Trigger、Thread、Worker Session 等对象各分配唯一 ID，注入时内联紧密关联对象的 ID，这些对象在底层就构成一张引用图。因为每次召回的结果本身也遵循 Inline & Spill，返回内容里又会带上下一跳的摘要与 ID，模型便能从当前事件出发，顺着引用关系逐跳找回上下文。

举个例子：从一条当前消息读到所在 Thread → 从 Thread 内联的 ID 追到相关 Worker Session → 再找到该 Worker 关联的另一个代码评审 Thread。

这解决的是 Router 在长程运行中丢失先前信息的问题。

5.4 怎么提前行动：投机执行

最后一个问题带点哲学味道：Agent 能不能在还不确定结果会不会被采用时就先做？

原文借用了投机执行（Speculative Execution）：根据环境信号在后台提前尝试，用额外的后台算力换人类更少的等待与介入。结果有价值就交付，没价值就丢弃。

两个场景：

• 个人助手：收到会议邀约邮件，先在后台核对日程冲突、搜集背景资料、备好回复草稿，用户过目即可确认发出。
• 研发协作：在内部用户群里配了一条「静默复现并修复」策略——有人反馈问题或讨论改动方案时，Agent 先在后台尝试复现并找修复方案，只有在确认问题并找到简单修复后才会交付结果，否则全程保持安静。

后面这半句其实比前半句更重要：主动性的另一半是知道什么时候不说话。

六、面向人的交互：全双工 + 分信道

双层架构从上下文层面保证了连续性，但要在真实交互里同时做到连续与高效，还得解决两个问题。

6.1 异步 ReAct Loop：把阻塞拆掉

经典 ReAct Loop 里，模型发起同步 run() 调用后循环就阻塞，直到工具执行完返回结果，期间会话无法响应任何新输入。

改法是：把耗时的命令与子任务工具调用换成异步的 start() 和 stop()。

• 模型调 start() 后立即收到「已启动（Started）」的返回，循环不再等待；
• 后台工具执行完成后，系统把最终结果作为一条新的事件消息投递进会话；
• 模型也能根据上下文调 stop()，主动终止跑太久的后台命令。

由此，前台对话响应与后台任务执行解耦：新输入在当前推理步结束后就会被处理，不必等后台工具完成。

原文也交代了实现状态：这一异步任务机制已在 DeepSeek Harness 中实现，但尚未默认开启。

6.2 多信道：不同信道有不同的带宽

如果把面向单人终端的交互方式直接搬进群聊——把冗长的推理过程和密集的工具调用原样输出——在多人协作里就是信息灾难。

双层架构已经解决了一部分：冗长的推理和密集的工具调用都被隔离在 Worker 内部，对外由 Router 统一负责。在此之上，还要针对不同信道定制交互规范：

信道类型	交互定位	具体做法
IM 等即时通讯	低打扰的轻量沟通	像人类同事一样只在需要决策或验收时发通知；只问直接问题、给简短结论。原文验证过一条硬性规定：单次回复不超过 100 词
GitHub / 邮件 / 文档等异步信道	结构化、高信息密度的异步交付	建 PR 时按项目规范写完整的问题背景、改动说明与验证结果；个人助手场景下直接起草结构化邮件与文档摘要

「单次回复不超过 100 词」这条规定朴素得有点可爱，但它其实是在用硬约束对抗模型天生的表达欲。

七、持久在线：计算、状态、环境三者解耦

本地 Agent 默认把三样东西绑在同一台设备上：推进 Agent Loop 的计算、需要持久保存的会话状态、以及代码仓库与工具链等执行环境。设备一休眠，Agent 就停了。

解法借鉴了存算分离（Compute-Storage Separation），分两步走。

第一步：计算与状态分离。 把推进 Agent Loop 的计算放进云端无状态的弹性计算容器，把 Session 等持久化状态存入数据库。无状态容器可以水平扩展、重启、替换，会话连续性由持久化存储保障。Agent 从此摆脱单台设备的生命周期限制。

第二步：计算与执行环境分离。 这里原文的分析很到位——为什么不能直接把环境搬到云上？

• 一种常见思路是在云端起沙箱、拉代码、重建环境。但真实工作环境往往包含未提交的本地修改、私有凭据、内网服务依赖、特定硬件或工具链，同步成本极高且容易遗漏。
• 另一种思路是要求用户放弃本地环境迁往云端，但迁移成本对很多人来说过高。

原文的推理是：既然难以复制和同步的是环境本身，就不必让执行环境跟着 Agent Loop 上云。

于是第二层解耦是：Agent Loop 在云端跑，重状态的执行环境留在原地，端侧只部署一个不保存会话状态的轻量 daemon，它只负责执行命令、返回结果。

这一思路与 Anthropic 提出的「脑手分离（Decoupling the brain from the hands）」一致——同样让 harness 保持无状态，会话日志存在 harness 之外，通过统一接口按需接入执行环境。区别在场景：Anthropic 那篇讲的是托管服务（按需创建的沙箱、客户 VPC 内的资源），而这里首先要接入的是用户日常使用、可能间歇在线的个人机器。

因此这套设计既支持 BYOM（Bring Your Own Machine），也支持接入云端托管机器或按需创建的计算环境。一个 Agent 可以在不同执行设备之间切换，甚至能在某台个人设备重新上线后，自动触发并完成需要在那台设备上执行的任务。

八、Watchdog：主系统之外的控制回路

存算分离解决了「不停」，但没解决「出错能自己爬起来」。

持久在线的分布式系统很难仅靠主系统内部逻辑保证长期可靠，需要在主系统之外引入独立的外部控制回路（Control Loop）。

而在 Agent 系统里，仅靠进程存活探测或监控脚本是不够的——很多异常不是进程崩了，而是模型陷入无效循环或偏离了目标。

原文的做法是在主系统外部配一个独立的 Watchdog Session，用定时消息驱动它。它要巡检三类问题：

1. 基础设施故障——接口报错、状态恢复失败；
2. 任务是否在推进——各个 Worker 有没有实质进展，是否陷入无效循环；
3. 方向是否偏离整体目标。

发现异常就及时介入修复，遇到外部偶发故障则持续复查直到恢复。

有个细节很有意思：Watchdog 本身也是一个具备完整工具能力的 Agent Session。所以维护者可以用自然语言问它「刚才为什么挂了」，也可以让它在线修正主系统行为——增删提示词、调整触发规则。

这相当于给系统配了一个能用自然语言运维的值班同事。

九、实验：数据说了什么

原文的初步实验分两块：端到端消融实验，以及单独压测 Router 层的批处理。

9.1 消融实验：双层架构到底赢在哪

实验设置：用群聊和 GitHub CI 消息流同时驱动四种方案。单次实验约 300 条消息，其中约 20 条是工作请求，其余是闲聊、跟进、叫停和 CI 消息。编码工作用一个只消耗时间的工具代替，所以衡量的是调度与协作能力，不是单任务执行能力。每种方案重复 5 次。

四种方案是：Super-agent、去掉直通的 Super-agent、以及两种提示词配置下的「单 Session + Subagent 工具」。

方案	p50	p95	观察
Super-agent	12.4 分钟	15.7 分钟	完成时间短且稳定
单 Session（中性提示）	—	29.5 分钟	5 次运行一次都没调用 Subagent，全在主会话执行，不断被新消息打断
单 Session（提示优先委派）	—	仍慢于 Super-agent	5 次里 4 次委派了；剩下 1 次判断工作「很小」自己干，形成长尾
Super-agent（去掉直通）	与完整版基本一致	与完整版基本一致	但 Router 决定数 +30%，读缓存 token 2323 万 → 3177 万（+37%）

几个结论值得记下来：

第一，单 Session + Subagent 的效果高度依赖提示词工程和模型临场判断。 中性提示下模型一次都没委派——这不是模型笨，而是「要不要分工」这个判断本身就该由系统结构来保证，而不是靠提示词祈祷。

第二，直通机制不提升完成质量与速度，但省下可观的 token 与推理开销。 去掉直通后 Router 的决定数增加约 30%，token 增加约 37%，而完成时间几乎不变。也就是说，直通的价值在成本，不在性能。

第三，Super-agent 用更多 token 换更短更稳定的完成时间。 因为维护了多个独立会话，单次实验的读缓存 token 高于单 Session。这笔账划不划算，取决于你更在意延迟还是成本。

9.2 批处理压测：单 Router 能扛多少

这一组让 Router 调真实模型、Worker 用 Mock 模型，把需要决定的 Trigger 到达速率从每分钟约 1 条逐步提到约 40 条：

Trigger 到达速率	平均 batch 大小	单次请求耗时	单个决定分摊的推理时间
约 1 条/分	1.0	2.5 秒	6.4 秒
约 40 条/分	2.8	3.9 秒	1.6 秒

单次请求耗时只从 2.5 秒涨到 3.9 秒，远慢于 batch 大小的增长，于是单个决定分摊的推理时间从 6.4 秒降到 1.6 秒。

这解释了 9.1 节里的一个现象：即使去掉直通让 Router 峰值负载上升，也仍未触及单 Router 的吞吐瓶颈。所以在目前的团队规模下，不必过早对 Router 做水平切分而牺牲全局上下文的连续性。

原文也坦白了局限：实验基于合成负载与简化环境，部分设置还可以更严谨，结果仅作初步参考。

十、四个还没解决的问题

这套系统能以较低复杂度运转，很大程度上是因为做了一系列工程和场景简化。超出这些简化，问题就来了。

1. 双层架构怎么扩展？ 「单常驻 Router + 订阅直通 + Worker 间不直接通信」覆盖了当前大多数日常任务。但任务规模扩大、耦合度提高之后，Router 何时该水平切分、粒度怎么划、同层 Worker 何时需要引入直接通信、用什么协作拓扑，都还没有定论。另外还有一个方向值得探索：系统与模型的协同设计（Co-design）——针对 Router 的事件判别、批量分派、上下文召回做专项训练。更长远的问题是长程记忆：当运行周期拉到跨月甚至更长，链式召回也撑不住。

2. 脱离 Session 之后怎么协作？ Session 不再是产品设计的首要问题之后，「如何向用户呈现任务」成了新问题。原文的判断是：以聊天窗口为中心的交互有一定路径依赖成分，交互可以更多地发生在领域特化的界面里（比如直接在 GitHub 的 Issue 和 PR 里工作）；Session 也可以为了使用习惯在界面上保留，但用户看到的一个会话，底层未必只对应一个 Session。此外，过渡期内很多任务仍需要人中途参与，怎么兼顾「逐步干预」与「后台自主推进」，同样待解。

3. 上下文边界怎么划，A2A 怎么做？ 组织决定如何配备 Super-agent，本质上是在划分上下文共享与隔离的边界：需要共享的共用一个实例，需要隔离的各配各的。一旦存在多个彼此隔离的实例（比如每个成员的个人助手 vs 团队共用的实例），跨边界协同就是 Agent 间通信（A2A，不特指某个协议）。在互不共享上下文、各自代表不同权限边界的前提下，怎么做到安全可靠，仍需探索。

4. 安全与隐私怎么保？ 事件驱动让 Agent 能被更广泛的环境驱动，也扩大了接触不可信输入的面。云端 Agent Loop + 端侧 daemon 这套设计，默认建立在云与端彼此受信任的前提上。但云端一旦被入侵或遭提示词注入攻破，它连接的所有端侧设备都面临被控制的风险。即使云端没被攻破，只要端侧凭据能进入模型上下文，正常执行中同样存在泄露风险——所以还需要设计机制，让 Agent 在不接触凭据本身的情况下使用凭据。

十一、我的三点解读

原文结语说得很克制：「我们并没有提出全新的理论，而是将计算机系统中经典的工程思想应用到了 Agent 系统的构建中。」

但恰恰是这种「老思想新用」最值得学。我把全文的可迁移经验收成三条：

第一，很多 Agent 工程问题，本质是操作系统问题。 Fast/Slow Path、Cache 与局部性、投机执行、存算分离、外部 Watchdog——这五个概念没有一个是新发明的，但它们精准地对应了 Agent 系统的五类真实痛点：噪音过滤、上下文预算、延迟优化、状态持久化、故障自愈。当你卡在某个 Agent 工程问题上时，先问一句：这个问题在操作系统/数据库/编译器里叫什么？ 通常已经有成熟答案。

第二，能用结构解决的，不要用提示词解决。 消融实验最有说服力的一点是：中性提示下模型 5 次里 0 次调用 Subagent，加了强提示后 5 次里 4 次——剩下那 1 次它判断「工作很小」自己干了。同一个模型、同一套工具，行为完全取决于提示词措辞。这不是可靠的工程基础。双层架构的价值就在于：它让「Router 不干活、Worker 只收自己订阅的消息」成为系统层面的保证，而不是模型层面的自觉。

第三，主动性的另一半是克制。 「静默复现并修复」策略里最关键的约束是「否则全程保持安静」；IM 信道规范里最硬的一条是「单次回复不超过 100 词」。一个真正好用的常驻 Agent，衡量标准不是它说了多少，而是它在不该说话的时候有没有闭嘴。

最后，原文注明本文的部分设计已在 dsh-superagent-prototype 中实现，并明确说明：该插件只是为了验证技术路线而提供的原型，并非 DeepSeek 的正式产品。

原文信息

• 标题：Super-agent 设计探索：迈向更自主的 Agent 系统
• 作者：Yujia Qiao（系统实现与本文写作），DeepSeek Harness 团队
• 发布时间：2026 年 10 月 31 日
• 说明：本文是一篇面向工程实践的架构思路探讨，并非对 DeepSeek Harness 现有产品功能的介绍