DeepSeek 的 Super-agent，到底想解决什么？
Harness 团队在 2026 年 10 月 31 日发布的《Super-agent 设计探索：迈向更自主的 Agent 系统》，从一个用 Agent 时很容易碰到的麻烦讲起：单件事越来越能交给 AI，但同时推进几件事，仍要人记住每个会话的进度、补充变化、来回切换。
作者想把这部分管理工作交给系统。人可以在群聊、代码评审等熟悉的地方继续说话，底下由系统决定该找回哪段上下文、让哪个 Agent 接着做。
这是一篇工程实践与架构探索文章。署名说明中，Yujia Qiao 负责系统实现与文章写作，其他团队成员参与讨论和审阅。文中既有内部使用的例子，也有设计思路、初步实验和仍未解决的问题。它不是一份正式产品的功能清单。[1]
原文的主线很清楚：先说明需要怎样的 Agent，再讲五个模块怎样支撑它，接着用实验检查核心调度设计，最后交代这套方案还受哪些条件限制。下面按原文第 1—9 节展开，保留主要机制和实验条件，再把难懂的地方拆开解释。
本文以官方长文为主。赛博禅心的《动态图解》帮助理解图示，Datawhale 的速读稿用于对照；它们不算另外两套系统，也没有增加独立实验。官方公开的代码只是研究原型，和内部实例不同，文章中的部分设计尚未在原型中实现。[2]
1. Super-agent：把多会话的管理负担接过去
原文首先给出一个判断：模型完成单个任务的能力变强了，多任务继续往上扩时，人的注意力可能成为限制。
团队观察到，一个人通常只能同时跟进 3—5 个活跃会话。这里的“3—5”是作者的实践观察，不能当作所有人的能力上限。它要表达的是：每多开一个会话，人都多一份记住背景、检查进度和传递变化的工作。
他们也讨论了一个直接的办法：给现有本地 Agent 接上命令行工具（CLI）、连接外部工具和数据源的接口（如 MCP）或其他连接器，让它接收外部消息。
但仅仅接通消息，还会遇到单会话阻塞、几件事的上下文混杂、本地电脑离线就停止运行等问题。连接器解决了消息从哪里进来，后面的协调和长期运行仍需要设计。
作者把能跨会话保持上下文、同时推进多项工作、持续存在的 Agent 形态，以及背后的系统架构，称为 Super-agent。个人助手是其中一种应用，研发团队里的协作者也是。
原文先展示了两个内部例子
第一个是字体设置。用户在群里提出，希望正文、代码和终端能分别配置字体。维护者叫来 Agent，Agent 提交了等待审核的代码改动，在 GitHub 上称为 Pull Request，简称 PR。
随后，用户在群里追加了独立字号的要求；维护者又在 PR 评审里提出，设置项太多，要折叠起来；设计师继续补充展开方式。Agent 把这些反馈接在同一个任务上，完成调整，随后同一个 PR 合并。
原文的字体设置实例：需求在群聊提出，追加字号后转到 GitHub 评审继续修改，最后合并同一个 PR。来源：官方 PDF 第 1 页。
这个例子说明“连续”：人换了沟通地点，系统仍能接上同一件事。后文会解释架构怎样支持这种连续性，但图里没有给出每一步内部调用的运行日志，不能把后面的架构解释都说成这次任务已经逐步验证过。
第二个例子是主动修复。团队的内部实例持续观察用户群，在无人 @ 的情况下识别问题，定位根因并提交修复 PR。原文后面补充，这种行为有预先配置的“静默复现并修复”策略，并非看到任何消息都可以自由行动。
作者据此提出四个基础特征：
| 特征 | 原文希望用户得到什么 |
|---|---|
| 连续 | 在群聊、GitHub 等地方说话，仍感觉是在和同一个 Agent 协作 |
| 高效 | 新指令不用等上一项任务完成，几项工作可以并行推进 |
| 主动 | 根据环境变化推进值得处理的事项，不需要介入时保持安静 |
| 持久 | 长期在线，接入真实工作环境，遇到异常能够恢复 |
这四条要一起看。只会并行但接不上前文，或者能记住所有事却一直排队，都还没有达到作者想要的形态。
原文认为，单个 ReAct Loop 难以同时满足这些目标。ReAct Loop 可以先理解成模型“判断下一步—调用工具—看结果—继续判断”的工作循环。
作者为它补了五个模块：双层架构、事件驱动、面向人的交互、计算与状态及环境分离，以及独立的 Watchdog。
原文整体架构图：事件经处理后进入 Router 或直通 Worker；Worker 使用执行环境，会话状态持久保存，Watchdog 在外部监督。图中编号对应原文第 2—6 节。来源：官方 PDF 第 2 页。
读这张图时，可以先分清五件事：谁负责协调，谁负责执行，消息怎样进来，人怎样参与，以及系统怎样持续运行。后面的章节就是依次回答它们。
2. 双层架构：一层管协调，一层做具体任务
2.1 为什么要拆开
原文先比较了两个极端。
所有事件都交给同一个会话，上下文容易连续，但执行容易排队，多项任务的细节还会混在一起。每条事件都开独立会话，并发方便了，又会缺少全局关联，几个会话也可能各自向用户回复。
因此，作者把“维护全局连续性”和“并发执行”分到两层。上层是 Router，负责交互与协调；下层是 Worker，在各自上下文里执行具体任务。
以后你在群里追加字号要求，或到 PR 里调整折叠方式，面对的仍是同一个协作入口。底下开了多少执行会话、哪一项需要继续，由系统管理。
这里的“两层”是职责划分，不规定每层只能有一个会话。它还把两个原来混在一起的问题拆开了：技术上怎样管理上下文，产品上怎样呈现任务和项目。用户看到一个聊天页，并不要求底下只有一个执行会话。
2.2 Router 管到什么程度
原文把 Router 放在全局信息与决策汇总的位置，称它为序点、协调点和记忆。序点可以理解为：需要统一处理的跨任务信息，在这里协调先后关系。
为了让它保持轻快，Router 不直接执行具体任务，甚至可以不配 Bash 这类执行命令的工具。它负责接人说的话、判断关联和分派工作，不跟着完成每项任务的所有细节。
这和常见 Agent Team 的侧重点不同。Agent Team 经常围绕一个复杂任务拆步骤、分角色，负责人需要深入任务内部并频繁协调。
Super-agent 的 Router 主要处理几件任务之间的高层关系，单项任务内部怎样拆，交给 Worker。
作者也没有把两者划成互斥类别：如果一个 Agent Team 的主会话只负责交互和分派，也可以视为这种双层结构。
从团队实践看，Router 常能用较轻量的模型；Worker 直接影响结果质量，通常使用更强的模型。这是配置取舍，不是所有场景都必须照抄的模型组合。
2.3 一个常驻 Router，会不会被消息堵住
团队目前采用单个常驻 LLM 会话作为 Router 的核心，部分逻辑也可以由普通代码承担。
原文给出的一个解释是批处理：上一轮模型推理时，新来的事件先积累，下一轮合在一起处理。消息少时逐条处理，消息集中涌来时自动合批。
Router 通常读入较多信息，只输出较短的判断与分派结果。模型读取输入的阶段叫 Prefill，合批输入可以并行计算；因此在一定范围内，一批消息增加，单次请求耗时不必按同样比例增加，每个决定分摊的推理开销就可能下降。
但这不意味着队列越长越好。上下文能放多少、模型一轮能正确处理多少条事件，都会限制批量。吞吐提高，也不能直接当作每位用户等待时间都会缩短。
规模继续扩大，可以把 Router 做成多层结构，或水平切成几个会话，这叫 Sharding。代价也很直接：切开后各自能更快处理，但分片之间的记忆与上下文更难保持连续。原文没有宣布这个权衡已经解决。
2.4 Worker 怎样并行，又怎样避免各说各话
Worker 挂载完整执行工具，在独立上下文里专注一项任务。执行过程和工具细节留在内部，关键状态与结果报告给 Router，再由 Router 统一对外沟通。
多个 Worker 在同一个 PR 等共享环境碰到一起时，可能发生冲突。原文主要依靠共同订阅相关话题，让它们看到同样的更新，有机会自己发现和处理冲突；少数跨任务协同由 Router 中转。
这提供了感知冲突的机会，并不等于获得了自动无冲突的保证。
Worker 内部也可以再调用 Subagent，或者本身就是一个 Agent Team。对上层 Router 来说，这些内部安排可以保持透明。
由此，研发场景里可以同时做问题复现、评审响应和功能开发；个人助手也可以在一个前台聊天页下，让不同话题分别推进。
3. 事件驱动：环境里发生的事，怎样变成任务
原文把驱动输入从逐条手输的提示词，扩展到了半结构化的环境事件：群聊消息、邮件、日程提醒、评审评论、CI 结果。CI 是代码改动后的自动检查。这些事件在文中统称 Trigger。
这一节沿一条事件的处理过程，依次讲过滤、路由、上下文组织和提前行动。
3.1 先过滤：明确的条件交给代码，需要理解的再找模型
群里大多数消息不用 Agent 介入。如果每条都调用大模型重新判断，响应和算力开销都会增加。
作者借用了 Fast Path / Slow Path 的思路：可以确定的高频判断，用代码快速处理；需要灵活理解的部分，才走模型这条较慢、较贵的路径。
程序层先检查来源、群组、允许的用户或机器人等条件。不同来源可以配置成只响应明确请求、作为候选事件，或者直接忽略。语义层再结合提示词策略和上下文，判断候选事件是否值得处理。
自然语言策略也成了扩展点。团队想增加某类处理规则，可以调整提示词。不过，从产品上说，确定的准入条件仍应有明确规则，不能把所有判断都交给模型临场发挥。
3.2 再路由：新事情分派一次，后续变化尽量直通
原文把同一个群聊话题、PR 或往来邮件串下的连续事件称为 Thread。它是一串相关讨论，不必等同于一项任务。
Router 根据初始事件创建 Worker 后，Worker 可以订阅对应 Thread。后续同一话题的事件由程序直接送达，省去 Router 每次再调用工具转发。
遇到超出范围的消息，Worker 可以退订或交回 Router 重新分派。
Router 仍能观测全局事件，但主要对未订阅的新事件作判断和分派。这样既保留协调入口，又减少它处理重复转发的负担。
订阅直通的简化解释图：新任务经 Router 判断分派，已订阅的后续事件进入对应 Worker；关键结果仍由 Router 对外沟通。此图为本文绘制，不是原文截图。
订阅是多对多的。字体需求的 Worker 可以同时跟踪群聊与 PR；同一 PR 也可能被几个 Worker 订阅。交集上的更新会通知这些订阅者，不一定需要它们逐个点对点沟通。
公开原型的授权说明也强调：订阅只投递上下文，不授予新的权限，工作仍受原授权范围限制。[3]
3.3 上下文放多少：眼前够用，完整记录随时能找
消息找到对应会话之后，还要决定往模型窗口放多少信息。
原文把窗口当作容量有限的缓存。Inline 是把近期很可能用到的信息直接放进去，减少额外读取；Spill 是把低频或超预算的完整内容留在窗口外，里面保留摘要与引用，需要时再取。
作者给了一个逐步调整的办法：先提供对象 ID 和内容摘要；再根据关联性，把相邻消息、被回复的消息、相关评审评论等常用信息加进来；长内容超出上限，就截断并保留续读入口。
文中“前 50 字”是局部注入的例子，不是所有内容都必须统一截成 50 字。
这利用了局部性：当前正在讨论一项修改，近期相邻的信息通常更可能用得上。它是信息摆放的判断依据，不保证附近的内容一定最重要。
长期运行后，Router 既放不下所有完整历史，又要在用户换个地方提旧任务时找回背景。于是，原文继续引入链式召回，也叫 Chain of Recall。
消息、话题和 Worker 等对象有唯一 ID，关联对象的 ID 与摘要随读取结果一起返回。模型从当前消息找到话题，再找到关联 Worker，再找到它参与的另一个评审话题，就可以沿关系逐步展开。
链式召回的解释图：沿评论、话题与任务的关联读取历史；窗口内留摘要和引用，窗口外保存完整内容。此图为本文绘制。
回到字体例子，在 PR 里问“这些设置能否折叠”，系统需要找回最初的独立字体和字号要求。这里是用原文案例帮助理解召回关系，不是说原文已经公布了这次任务的全部检索日志。
这种设计减轻了全量历史塞入窗口的压力。关联是否保存完整、读取有没有找对，仍会影响效果；跨月的长期记忆也没有因此自动解决。
3.4 提前行动：先做一些准备，减少人的等待
原文借用了投机执行的思想：还不确定结果最终会不会采用，也可以根据环境信号，先消耗一些后台算力尝试。结果有用就交付，没有价值就丢弃。
作者给了两类例子。个人助手收到会议邀约后，可以先检查日程冲突、搜集背景、准备回复草稿，等用户看过再确认发出。这个例子是设计中的应用设想。
研发场景则有内部实践：团队在用户群配置了“静默复现并修复”策略。有人反馈问题或讨论改动时，Agent 先尝试；只有确认问题，并找到简单修复方案，才交付结果，否则保持安静。
原文展示的一次讨论是，模型输出里的波浪号被渲染成删除线，影响阅读。群里还在讨论该改模型还是改渲染规则，Agent 已提交修复 PR，并继续解释修改依据。
原文的提前行动例子：围绕波浪号渲染问题，群内仍在讨论时，Super-agent 已提交修复并说明依据。来源：官方 PDF 第 6 页。
我的理解是，这里交换的是后台计算与人的等待、注意力。可丢弃一个准备结果，不代表已经产生的外部影响也能撤回。核对日程、准备草稿和直接发信，尝试修复和直接合并，应分别定义行动范围。
4. 面向人的交互：后台继续做，前台还能说
4.1 全双工：工具没结束，也能继续接输入
双层架构减少了任务上下文之间的混杂，但人在交互时还可能被工具执行卡住。
经典同步 ReAct Loop 中，模型调用一次 run，循环就等待工具给出最终结果。这期间，新输入不能及时进入后续处理。原文把耗时命令与子任务调用改成 start 和 stop，组成异步循环。
start 先返回“已启动”，工具在后台运行；最终结果作为新事件回投会话。模型也可以根据上下文调用 stop，终止运行过久的后台命令。
这里最容易读过头的一点是响应时机。原文说，新输入在当前推理步骤结束后处理，不需要等后台工具完成。它没有承诺任意时刻立即中断正在进行的模型推理，也没有给出固定的秒回保证。
异步交互解释图：会话继续处理新输入，后台工具运行到完成，再以事件回投结果。此图为本文绘制。
按文章发布时的说明，这项异步任务机制已在 DeepSeek Harness 实现，但尚未默认开启。这是 2026 年 10 月 31 日文章的状态描述，不代表此后所有版本的默认配置。
4.2 多信道：群里少打扰，交付处写完整
原文还强调，终端里适合展示的信息，不一定适合直接搬进多人群聊。把每次推理和工具调用都发出来，会占用其他人的注意力。
Worker 的细节留在内部，Router 统一对外。IM 群聊侧重简短结论，只在需要决策或验收时通知；GitHub、邮件和文档等地方，则承载完整背景、改动说明与验证结果。
团队验证过一条简单的提示词要求：单次回复不超过 100 词。这里要保留原文的“词”，不能擅自换成“100 个汉字”，也不应把它当成所有团队的通用阈值。
个人助手也可沿用这种区别：聊天里给简短提醒，邮件或文档里准备结构化的交付。输出位置与内容密度，应该随协作场景调整。
5. 计算、状态与环境分离：别把所有东西绑在一台电脑上
原文把本地 Agent 经常绑在一起的三样东西拆开：推进工作循环的计算，需要保存的会话状态，以及代码、文件和工具链等执行环境。
这三样都放在本机，设备休眠或离线，工作就会停；想换台机器，也会碰到环境不一致。作者提出分两步解耦。
5.1 先分开计算与状态
推进 Agent Loop 的计算可以做成无状态的，放到云端弹性容器里；会话等持久状态存入数据库。
容器重启、替换或扩展时，状态不随它一起消失，系统因此有机会继续推进任务。这里说的是架构保障的方向，恢复一项外部操作时怎样避免重复执行，还需要具体实现，不能从“有数据库”直接推出任何命令都能无损接续。
5.2 再分开工作循环与执行环境
循环上云后，怎么访问真正干活的环境？作者讨论了两种常见做法：在云端建沙箱，把环境同步过去；或者要求用户直接迁到云端工作。
困难在于，日常开发机可能有未提交的修改、私有凭据、内网依赖、特殊硬件和工具链。完整复制容易遗漏，强制迁移的成本也高。
因此，原文的方案是把环境留在原处，端侧只部署轻量 daemon，也就是后台服务。它不保存会话状态，只接收执行命令并返回结果；云端 Agent 按需访问环境、取得上下文。
原文的两层解耦图：Agent Loop 与会话数据库分开，再按需连接个人开发机、托管环境或间歇在线的设备。来源：官方 PDF 第 8 页。
作者还把它与 Anthropic 所说的“脑手分离”作了对照。
按原文的概括，共同点是让 harness 保持无状态、日志存在外部、执行环境通过接口接入；那篇文章主要讨论托管沙箱和客户 VPC，也就是客户自己的云内私有网络，本篇更关注可能间歇在线的个人机器。
它既支持把自己的机器接进来，也就是 BYOM，亦可接托管机器或按需创建的环境。不同任务可以选择不同设备；依赖某台离线机器的工作，等它重新上线后再触发。
这一点需要分清：协调端可以持续存在，但依赖离线设备的步骤仍要等。把会话状态放到云端，不能让已经离线的硬件继续执行命令。
6. Watchdog：进程活着，任务也可能停住
长期运行的系统，光靠自己的主循环处理所有异常并不可靠。原文在主系统外增加了独立的控制回路：一个定时消息驱动的 Watchdog 会话。
它既处理接口报错、状态恢复失败等基础设施故障，也让模型判断 Worker 是否有实质进展、有没有偏离目标。遇到偶发的外部故障，就持续复查，直到恢复。
原因很好理解：进程还在，模型也可能一直重复尝试同一件事。传统的“进程是不是活着”检查，只能覆盖其中一部分问题。
Watchdog 本身有完整工具能力，维护者可以用自然语言问故障原因，也可以让它在线增删提示词、调整触发规则。
这给了维护者一个外部介入入口。与此同时，“判断有没有进展”的仍是模型，原文没有给出它的误判率、恢复成功率或长期可用性数据；不能把多加一个监督会话当成可靠性已经得到证明。
7. 初步实验：哪些设计起了作用，代价是什么
作者把实验明确称为初步参考：负载是合成的，环境经过简化，部分设置还可以更严谨。两组实验分别检查端到端调度，以及 Router 的批处理。
7.1 消融实验：拿掉一个设计，再看有什么变化
消融可以理解为，保留其他部分，去掉某项机制，看结果怎样改变。这里对比的是四种方案：完整 Super-agent、去掉直通的 Super-agent，以及两种提示词下的单会话加 Subagent 工具。
中性提示的大意是，合适时用 Subagent；优先委派提示则进一步要求，把工作优先交给独立 Subagent，主会话只做小事。区别在提示词，没有把“主会话必须分工”写成硬性架构。
每次实验约 300 条群聊和 GitHub CI 消息，其中约 20 条是工作请求，其余是闲聊、跟进、叫停和检查结果。每种方案运行 5 次。
具体编码被一个只消耗时间的工具代替。消息间隔和工作时长按四分之一缩放，模型调用耗时保留真实值。因此，它测的是调度与协作，不能据此判断真实代码写得好不好。
原文累计曲线：黑线是工作请求到达，彩色线是各方案累计完成；曲线为 5 次运行均值。它展示了任务积压与追赶过程，不是代码质量评分。来源：官方 PDF 第 9 页。
下面按原表重排。任务完成时间从请求到结果消息计算；P50 是中位数，P95 用来观察较慢任务的耗时。Token 是模型处理文本的计量单位；这里统计所有会话读取缓存文本的总量，不能直接当作费用。
| 方案 | 完成时间 P50 / P95，分钟 | 单次实验读缓存 Token |
|---|---|---|
| Super-agent | 12.4 / 15.7 | 2323 万 |
| 去掉订阅直通 | 12.6 / 15.5 | 3177 万 |
| 单会话加 Subagent，中性提示 | 20.4 / 29.5 | 605 万 |
| 单会话加 Subagent，优先委派提示 | 13.8 / 29.0 | 1082 万 |
中性提示下，5 次运行一次都没调用 Subagent。优先委派提示下，5 次有 4 次进行了委派，另一次觉得工作很小，自己直接做，形成长尾。
作者据此认为，Router 不亲自执行、Worker 只接相关话题，可以在系统层面减少模型临场决定是否分工带来的波动。
直通机制的结果则要分开看：去掉它，完成时间基本一致，Router 需要做的决定约增加 30%，总读缓存 Token 从 2323 万增至 3177 万，约增加 37%。
这组负载下的主要收益是减少调度开销，没有显示出明显的完成时间改善。
同时，多会话结构本身消耗了更多读缓存 Token。原文的取舍是，用更多消耗换取更短、更稳定的完成时间。总费用还取决于实际模型、计费与完整负载，表里没有给出这些结果。
补充算一个容易混淆的口径：关闭直通后多 37%，不等于开启后少 37%。如果以关闭后的 3177 万为分母，重新开启相对减少约 26.9%。这是按原文数据计算的补充说明，不是新的实测结果。
7.2 Router 批处理：消息变多时，一个会话还能不能承担
第二组实验只让 Router 调真实模型，Worker 使用 Mock，也就是模拟实现。需要作决定的事件到达速率，从每分钟约 1 条提高到约 40 条。
下表沿用原文报告的指标。两项耗时的统计口径不同，原文提供的信息不足以互相换算。
原文 Router 压测图：左侧观察批大小与单次请求耗时，右侧观察单个决定分摊的推理时间。来源：官方 PDF 第 10 页。
| 原文报告的指标 | 低到达速率 | 高到达速率 |
|---|---|---|
| 需要决定的事件 | 约 1 条／分钟 | 约 40 条／分钟 |
| 平均 batch 大小 | 1.0 | 2.8 |
| 单次请求耗时 | 2.5 秒 | 3.9 秒 |
| 单个决定分摊推理时间 | 6.4 秒 | 1.6 秒 |
作者的解释是，积压事件合批后，一次请求处理的事件增加，请求耗时增长较慢，有效吞吐随之提高。它也解释了前一组实验里，去掉直通增加了 Router 负担，却还没有明显拖慢完成时间：在该负载下，单 Router 尚未成为瓶颈。
表中的 1.6 秒是原文报告的单个决定指标，不能当作用户从发消息到收到回复的等待时间。
团队据此判断，在其当前规模下，无需过早拆开 Router、牺牲全局上下文。它没有给出所有团队适用的规模阈值，更没有证明消息量可以无限增加。
8. 四类开放问题：作者主动留下了哪些边界
原文强调，这套系统能以较低复杂度运行，是因为做了工程与场景上的简化。把这些简化拿掉，仍有四类问题需要解决。
8.1 双层架构怎样继续扩展
目前的组合是：单个常驻 Router、订阅直通、同层 Worker 通常不直接通信。
任务规模更大、耦合更紧时，Router 什么时候拆、按什么粒度拆，Worker 什么时候需要直接通信、采用什么协作拓扑，都没有定论。
作者还提出系统与模型协同设计的方向：针对事件判别、批量分派、上下文召回专项训练 Router，可能提高吞吐与决策表现。这里是探索方向，不是文中已验证的训练成果。
长程记忆也被单独点出。链式召回主要帮助近期任务与会话历史检索，时间跨度扩大到数月，仍会成为制约扩展的瓶颈。
8.2 隐藏 Session 后，人怎样协作
底层会话不再直接对应界面上的聊天窗口，用户需要的任务视图、项目管理和交互方式就得重新设计。
原文认为，聊天窗口居于中心有路径依赖的成分。协作也可以发生在领域界面，例如直接在 Issue 或 PR 中工作。Issue 可以理解成代码平台上的问题或工作条目；保留熟悉的聊天页也可以，只是它不必等于一个底层会话。
还有人的中途参与。许多任务仍需要逐步确认细节，如何让人随时介入、接管或实时协同，又不拖累后台自主推进，仍是产品设计问题。异步接收消息是其中一项机制，不是全部答案。
8.3 上下文怎样隔离，实例之间怎样合作
前面的设计一直围绕单个 Super-agent，默认服务范围内的信息可以汇到同一个全局上下文。
扩到组织后，配几个实例，也是在划共享与隔离的边界。需要共享的范围可以共用一个实例，需要隔离的就应分开，例如个人助手与团队公共助手。
这些实例不共享底层上下文、各自代表不同权限，再跨边界协作，就涉及 A2A，也就是 Agent 间通信。原文特意说明，这里不指某个特定协议。怎样安全、可靠地合作，仍待探索。
8.4 安全与隐私怎样保障
事件来源增加，也增加了接触不可信输入的机会。原文直说，如果安全与隐私问题解决不好，Super-agent 只能在很小、很可信的范围工作。
云端循环连接个人设备的方案，默认云端与端侧互相信任。云端持续接收外部消息，端侧却有私有代码、敏感数据和本地凭据。一旦云端遭入侵或被提示词注入攻破，连接的端侧设备都可能受到影响。
即使没有入侵，只要凭据进入模型上下文，正常执行也存在泄露风险。因此，作者要求进一步设计让 Agent 使用凭据、却不直接接触凭据内容的机制，并没有声称文中已经给出了完整解决方案。
在主动接单上，公开原型默认采用 observe，也就是观察模式：对推断出的工作，只记录“本来会接单”，不实际接单。切到 auto 自动模式，也必须匹配启用的规则；明确请求则另按准入规则处理。
observe 不等于所有任务都不能执行。[3]
补充核对公开原型的部署文档：Router 和 Worker 的工具预设使用 danger-full-access，以操作者的系统身份运行，账号包装脚本不隔离进程。
官方建议使用只包含 Agent 凭据的专用系统账户。独立会话和工作目录不能代替这一层隔离。[4]
9. 原文最后想说明什么
作者没有把这套方案包装成全新的理论。他们强调，过滤快慢路径、批处理、缓存与局部性、投机执行、存算分离和外部控制回路，都来自长期积累的计算机系统思想。
内部实例已经持续参与问题复现、修复、评审响应，以及 Harness 自身的迭代；这说明团队有实际运行经验，但文中并未提供长期可靠性或真实业务收益的完整验收数据。
从产品设计看，值得沿着原文继续追问的是：当人越来越少介入单项执行后，系统能否接过多任务的协调、上下文同步和异常跟进，让人更多在决策与验收时参与？五个模块都是围绕这个目标组织的。
读完后也应把几条线留清楚：内部实例、公开研究原型与完整架构设想不是同一个交付范围；调度实验不能替代真实任务质量与成本验证；跨月记忆、跨权限协作和安全问题，仍在作者列出的开放问题里。
这能帮助判断哪些机制值得借鉴，也提醒我们在自己的场景里验证哪些条件。本文的解读没有替代这些尚未完成的验证。
来源与阅读范围
本篇覆盖官方原文第 1—9 节的主要论述、五个架构模块及其子机制、两组实验、四类开放问题和结语。字体需求与波浪号修复来自原文图示；会议准备是原文的应用设想。文中没有增加作者亲测经历，也不把补充推断写成团队实测。
作者及团队背景已在导读说明，未逐一复刻文末全部致谢名单。原图从用户提供的官方 PDF 提取，图注标明来源；三张蓝色解释图为此前基于原文制作的辅助图。
- DeepSeek Harness 团队：《Super-agent 设计探索：迈向更自主的 Agent 系统》，2026-10-31。本文的主要学习对象。
- dsh-superagent-prototype 官方仓库，用于区分公开原型与内部版本、未来设计。
- 官方文档：002 Authorization，补充核对订阅、授权和 observe／auto，2026-11-02 核对。
- 官方文档：006 Deployment，补充核对公开原型权限与隔离，2026-11-02 核对。
- 赛博禅心《动态图解：DeepSeek 的 Super-agent 架构》，用户提供 PDF。辅助理解，不作独立实验证据。
- Datawhale《突发！DeepSeek重磅开源：超级Agent架构！》，用户提供 PDF。用于对照，涉及实验口径时以官方原文为准。