AI 学会自己接活：DeepSeek Super-agent 架构全拆解

不是新模型，而是一次 Agent 系统的「操作系统化」实验。

过去一年，AI 编程工具最反直觉的一幕是：Agent 越能干，人反而越忙。

程序员可以同时开好几个 Coding Agent，让它们分别写需求、做审查、跑测试、补文档。模型的执行能力越来越强，人却要在不同窗口之间来回切换：看进度、处理报错、回答问题、决定下一步。原本用来减轻负担的 AI，又制造出一份新工作——管理 AI。

2026 年 10 月 31 日，DeepSeek Harness 团队公开了一篇设计文章《Super-agent 设计探索：迈向更自主的 Agent 系统》（英文标题 Exploring Super-agent Design: Towards a More Autonomous Agent System），并同步开源了研究原型 dsh-superagent-prototype。没有更大的模型，没有新的跑分，只有一套试图回答上述问题的系统设计。

这篇文章想讲清三件事：它到底开源了什么；这套架构新在哪里；以及，它离真正可用还有多远。

一句话版本：DeepSeek 把 Agent 的工作单位从 Session 换成了 Ticket，把人的注意力当成一等资源，把授权写成 Mandate。这不是模型能力的胜利，而是 Agent 调度层的设计。

一、先把事实摆清：开源的到底是什么

这次的主角不是模型，而是一个 DeepSeek Harness（DSH）的插件包。

• 项目名：dsh-superagent-prototype，隶属 deepseek-ai 官方 GitHub 组织，MIT 许可证，TypeScript 编写。
• 定位：面向一个 GitHub 仓库的主动式 Coding Agent，可选接入飞书；在授权范围内接收请求、创建工单、在独立 Session 和目录中执行，最后回到原对话交付，例如提交 Pull Request。
• 形态：一个 DSH Bundle，带 Web 管理面板。DSH 本身是「一切皆插件」的开源 Agent 运行时，基于 Cordis 元框架；截至 2026-10-31，DSH 仓库约 26.7 万星，仍处于 Developer Preview。
• 状态：README 写得很直白——研究原型，仅供参考，不是 DeepSeek 官方产品；代码大量由 Coding Agent 参与完成，可能包含 Bug，工程风格未必一致；公开版与内部版、以及设计文章描述的版本并不完全相同，文章中部分设计属于未来方向，原型尚未实现。
• 热度：仓库创建当天即获得约 1,075 星、85 个 Fork（截至 2026-10-31 抓取时），但只有 1 个提交。这更像一次「把设计连同参考实现一起摊开」的发布，而不是一个成熟项目的版本迭代。

理解这一点很重要：它首先是一篇架构论文的参考实现，其次才是一个能跑的工具。 后面我们会把「论文里的设计」和「原型里的代码」分开看。

二、问题定义：多任务的上限，是人的注意力

要理解 Super-agent，先要承认现有 Agent 的一个结构性局限：大多数 Agent 仍然以单次 Session 为中心。

用户发指令，模型理解，调用工具，执行若干步，返回结果。这套模式适合边界清晰的任务：修一个 Bug、做一个功能、查一份资料。但真实研发不是任务的简单叠加。一个问题可能从 GitHub Issue 开始，进入代码修改、PR 审查、CI 测试和持续讨论；今天提需求，明天补约束，几天后又在同一个 PR 里提出新的修改意见。

传统 Agent 的困难在于，它依赖用户主动发起下一轮任务。测试失败，要不要重新提示？PR 里有人补充反馈，Agent 知不知道这属于之前的工作？同时有十几项任务，谁来决定哪些继续、哪些暂停？

DeepSeek 团队给出的观察是：一个人通常只能同时跟进 3 到 5 个活跃 Session。 单任务的上限取决于模型能力，多任务的上限却取决于人的注意力。Agent 越能干，人越容易成为系统的瓶颈。

他们把这套新形态称为 Super-agent，并给出四个基础特征：

这四个特征，单个 ReAct Loop 无法同时支撑。于是问题从「模型会不会写代码」变成了「系统怎么调度工作、怎么保存状态、怎么在恰当的时候把控制权交还给人」。

三、五个模块：一次「Agent OS」式的拆解

论文把架构拆成五个模块：双层架构、事件驱动、面向人的交互、计算/状态/环境的分离、Watchdog。下面按模块拆开讲，并把授权与执行这两层单独展开，因为它们最能体现「原型到底做了什么」。

3.1 双层架构：Router 不干活，Worker 不说话

Super-agent 把「维持全局连续性」和「高并发执行」拆成两层：

• Router 层：常驻的全局路由层，负责承接所有入口的人类交互，汇总跨任务的信息与决策，判断一个新事件是否值得启动任务，并完成分派。它不直接执行具体任务，甚至可以不配 Bash 工具。
• Worker 层：由多个上下文隔离的执行 Session 组成，每个任务一个 Worker，挂载完整执行工具，专心完成单一任务。Worker 不直接与人交互，推理过程和工具调用不会直接输出到外部信道，而是向 Router 汇报状态，由 Router 统一回复。

这听起来像常见的「Agent Team」，但侧重点不同。常见的 Agent Team 用于单个复杂任务内部的步骤拆解，Team Lead 需要深入理解任务细节、高频协调成员；Super-agent 的 Router 只处理任务之间的高层关联与分派，不介入单任务内部的拆解。论文甚至建议 Router 使用较轻量的模型——因为它的工作通常是长输入、短输出。

这个设计最值得记住的一句话是：

Session 应当是系统的实现细节，而不应是用户的认知负担。

传统产品把 Session 同时当作技术上的上下文管理和面向用户的项目管理，于是用户被迫学习「Session 管理」。Super-agent 把这两件事拆开：底层可以有无数 Session，用户看到的仍然是一个连续的 Agent。

3.2 事件驱动：Source、Trigger、Thread、Subscription

第二个模块，是把 Agent 的驱动方式从「人发提示词」改成「环境产生事件」。

• Source：事件流。一个 Source 维护自己的读取位置和机器人身份，定义什么算事件，过滤掉自己的消息和不在监听范围内的内容。DSH 原型里有 GitHub 和飞书两种 Source。
• Trigger：一条不可变事件，带来源元数据（例如谁发的）。Trigger 是审计和幂等的最小单位；同一条 Trigger 被接受两次，只会生成一张 Ticket。
• Thread：按时间排列的 Trigger 序列。同一个 Issue、同一个 PR、同一个群聊话题下的连续事件，构成一条 Thread。Thread 是 Eval 的一致视图和上下文。
• Subscription：Ticket 与 Thread 的多对多订阅关系。已订阅 Thread 的后续事件会直接扇出给对应 Ticket，不再经过 Router 转发；它只增加上下文，不授予新权限。

这套设计直接借用了计算机系统的 Fast Path / Slow Path 思路：

• 已归属的事件走快路径，由程序直接送到订阅它的 Worker；
• 新事件走慢路径，由 Router 判断、评估、分派；
• 事件密集时，Router 把上一轮推理期间积压的 Trigger 合并成一批处理，形成批处理（Batching）。

论文给出的实测是：当需要 Router 决定的 Trigger 从每分钟约 1 条升到约 40 条，平均 batch 从 1.0 升到 2.8，单次请求耗时只从 2.5 秒升到 3.9 秒，单个决定分摊的推理时间从 6.4 秒降到 1.6 秒。换句话说，拥堵时合并处理，反而提高了有效吞吐。

论文还提出「投机执行」：在结果是否被采用还不确定时，Agent 根据环境信号在后台提前尝试，有价值就交付，没价值就丢弃。比如群里有人反馈问题，Agent 先静默复现、找修复方案，确认后再交付。这个设计在论文里很亮眼，但原型文档中未见对应实现，应视为方向而非现状。

3.3 上下文：把窗口当 Cache 管

事件驱动带来一个新问题：环境会持续产生半结构化事件，应该往上下文窗口里塞多少？

论文借用了编译优化和计算机系统的两个概念：

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

再结合局部性（Locality）：从最少信息开始，只给对象 ID 和摘要；然后逐步内联紧密关联的内容，例如前 50 字、相邻消息、所回复的消息、评审讨论中的相邻评论；超过上限就截断并保留续读入口。对 Trigger、Thread、Worker Session 等对象赋予唯一 ID，并在注入时内联下一跳的 ID，就形成一张引用图，模型可以沿引用关系逐跳召回——论文称之为链式召回（Chain of Recall）。

原型实现了其中一部分：Executor 收到的任务说明和输入是内联的 Trigger 卡片，首次任务最多 1,500 字符，后续输入最多 600 字符；被截断的内容只给资源指针，由 Worker 按需读取。这属于 Inline & Spill 的工程化简化版；完整的链式召回图，仍主要是论文设计。

3.4 授权：Ticket、Mandate、Assignment

这是整套设计里最不像「Demo」、也最值得企业团队细看的部分。

Super-agent 把「工作」抽象成三个对象：

• Ticket（工单）：授权的单位。只有 Eval 能创建 Ticket；Ticket 引用自己的 Mandate，持有 Channel、Input 和 Assignment，拥有独立生命周期。它可以结束，也可以在收到人的后续消息时重新打开。
• Mandate（授权）：一次接受所授予的东西——策略版本、范围、强度、匹配的规则、发送者在来源上的身份、来源如何收到这条 Trigger。Mandate 不可变；扩大范围意味着新开 Ticket；只有人的「停止」能撤回它，或者策略不再成立时被撤销。
• Assignment（派工）：Ticket 与一个 Executor 实例的绑定。一个 Ticket 可以先后有多个 Assignment；Assignment 独立地经历 pending → running → ended，只有它的最终报告才能从 Executor 侧结束 Ticket。

授权流程是两段式的：

1. Gate（准入）：确定性程序层。检查发送者是否在白名单、是否在跟已有 Ticket 的 Thread、是否命中准入表；机器人消息最多只能成为「推断候选」，不能成为「明确请求」。
2. Assessment（研判）：模型层。根据启用的规则、Thread 快照、已有 Ticket 和当前 Policy，判断是否接受、继续还是停止。

这套机制的关键不是「让 Agent 更自主」，而是让自主行为有可追溯的授权依据。公开文档明确写着：聊天内容、评论以及引用的文档，只能作为判断输入，不能直接修改系统既有的访问权限和授权范围。模型可以判断「这件事该怎么做」，但不能凭自己的判断扩大权限。

对于未经明确请求、但可能值得主动处理的工作，系统提供三档接纳模式：

默认 observe，团队先观察 Agent 的判断是否合理，再逐步扩大自动执行范围。这个顺序很重要：先建立信任，再放开权限，而不是反过来。

3.5 执行与恢复：30 分钟、额外槽位、重启

原型在执行层做了不少「不性感但决定体验」的工程：

• 每个 Ticket 一个 worker-<ticket id> Session 和一个独立目录；Executor 的预设会把前台 Shell 命令在 5 秒后转入后台，让 Worker 能在下一步继续接收消息。
• 一轮结束后，后台任务最多再跑 30 分钟；到点终止 Shell 任务并记录状态，Subagent 则允许继续。这样既不会因为一个长命令卡死整个任务，也不会让后台无限占用资源。
• 并发槽位之外，永远保留一个额外槽位给人工消息或状态查询。普通任务占满资源时，人仍然能及时介入。
• 交接给人时立即释放槽位；Ticket 结束时杀掉 Shell 任务、释放 Subagent；进程重启时，未完成的 Assignment 会收到恢复说明，并按照「最老 Ticket 优先」重新排队。
• 所有「决定之后要做的外部动作」先落库、再执行；投递失败按 2 秒起步、指数退避到 1 分钟重试；消息按 Ticket 和会话保序。

这些机制看起来琐碎，却正好对应 Agent 落地时最现实的问题：模型能不能完成任务只是第一步，怎么管理资源、保存状态、恢复中断，以及在恰当的时候把控制权交还人类，才决定最终体验。

四、实验：省下的是时间，付出的是 token

论文给出了两组初步实验。它们不是产品基准，但足以说明设计取向。

4.1 消融实验：双层架构 vs 单 Session

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

中性提示下，模型 5 次运行一次都没有调用 Subagent，所有工作都在主 Session 里做，不断被新消息打断；改成「优先委派」后，4 次进行了委派，但仍有 1 次判断工作「很小」而自己执行，形成长尾。论文的结论是：与其依赖提示词工程和模型临场判断分不分工，不如用双层架构在系统层面把「接人」和「干活」分开。

代价是 token。由于维护多个独立 Session，Super-agent 单次实验的读缓存 token 高于单 Session。另一个数字更能说明「直通」的价值：去掉订阅直通后，任务完成时间与完整版基本一致，但 Router 需要做出的决定增加了约 30%，总读缓存 token 从 2,323 万增加到 3,177 万，增幅约 37%。

4.2 Router 批处理：拥堵时反而更高效

当 Trigger 到达速率从每分钟约 1 条升到约 40 条：

• 平均 batch 大小：1.0 → 2.8
• 单次请求耗时：2.5 秒 → 3.9 秒
• 单个决定分摊的推理时间：6.4 秒 → 1.6 秒

单次请求耗时增长慢于 batch 大小，说明积压的事件合并进一次 LLM 调用后，Prefill 阶段可以并行计算，边际成本递减。论文据此认为，在团队规模下，单个常驻 Router Session 还没有成为吞吐瓶颈，不必过早水平切分而牺牲全局上下文的连续性。

4.3 怎么读这些数字

三点提醒：

1. 这是合成负载，工作用「只消耗时间」的工具代替，衡量的是调度，不是代码质量；
2. 样本很小，每种方案 5 次，且只在一个团队的规模下；
3. 它没有直接测量人的注意力。实验测的是任务完成时间，不是人被打断的次数、恢复专注的时长或通知负担。论文用完成时间作为「效率」的代理指标，这个选择合理，但不能等同于「人更轻松了」。

换句话说，这组实验证明了「双层架构在调度上更快、更稳」，但没有证明「人因此更省心」。后者需要用户研究，而不是消融实验。

五、论文很激进，原型很克制

这是整件事最容易被忽略、也最重要的一节。

设计文章描绘了五个模块，但 README 明确提醒：公开原型经过了改编，并不等同于内部版本，也不等同于文章描述的版本；文章中部分设计是未来方向，原型没有实现。 把两者对照，能看到一条清晰的「实现边界」：

更值得注意的是安全边界。部署文档写得很清楚：

两个预设都以 danger-full-access、以部署者的操作系统用户身份运行；账号包装器只负责选择凭据，不隔离进程。Worker 可以按绝对路径执行程序，也可以读取操作者的主目录。需要隔离时，应使用只包含 Agent 凭据的专用操作系统账号。

这意味着：

• 它不是一个沙箱产品，而是一个「在你自己的机器上、以你的权限跑命令」的 Agent；
• 工作目录和命令限制只是默认值，不是安全边界；
• 一旦接入外部事件（Issue、群聊、PR 评论），提示词注入的风险是真实存在的；
• 目前只支持一个 GitHub 仓库，飞书是可选源，不支持 GitHub Enterprise Server。

论文自己也没有回避这些：在「开放问题」一节，团队把安全与隐私单列，指出云端 Agent Loop 一旦被攻破，连接的所有端侧设备都面临风险；即使云端未被攻破，凭据进入模型上下文也可能泄露。他们把「让 Agent 在不接触凭据本身的情况下使用凭据」列为需要继续探索的问题。

所以更准确的判断是：这是一份高质量的研究原型和参考架构，不是可以直接搬进生产的企业级自主 Agent。 它的价值在于把问题、取舍和边界都摊开了，而不是给出一个「开箱即用」的答案。

六、横向对照：它和 Copilot、Codex、Cursor、Jules、Managed Agents 有什么不同

把 Super-agent 放进 2026 年的 Agent 版图，会发现它并不孤独。异步编码 Agent 已经是成熟赛道：

这张表能看出三件事。

第一，商业产品已经把「异步任务」做成了基础设施。 Copilot、Codex、Cursor、Jules 都能接任务、跑沙箱、交 PR，触发入口甚至比 Super-agent 更多。它们优化的是「单个任务的执行效率」和「与现有工作流的集成」。

第二，Anthropic 的 Managed Agents 是最接近的架构对照。 它同样把「大脑（模型 + harness）」「手（沙箱与工具）」「Session（事件日志）」拆成可独立失败、独立替换的接口，并用这个解耦把 p50 首 token 时间降低约 60%、p95 降低超过 90%。DeepSeek 的论文明确提到这一思路，并指出自己的场景差异：Managed Agents 主要面向托管服务和客户 VPC，而 Super-agent 首先要接入的是用户日常使用、可能间歇在线的个人机器，上面有未提交的修改和本地凭据。这引出了 BYOM（Bring Your Own Machine）和端侧 daemon 的设计方向。

第三，DeepSeek 的差异化不在单点，而在组合。 它把「开源、可自托管、团队级授权、跨 GitHub 和飞书保持连续、注意力预算」放在同一个架构里。商业产品通常不开放这些内部机制；开源框架通常提供调度原语，但不提供完整的团队工作域模型。Super-agent 试图补的，是中间那一层。

但也要看到差距：商业产品有成熟的沙箱、配额、审计、企业权限和多仓库支持；Super-agent 目前是一个单仓库、单实例、无沙箱的研究原型。它的架构思想可以借鉴，工程成熟度不能直接对标。

七、真正的创新，与可疑之处

7.1 三个真正的创新点

1. 把 Session 降级为实现细节，把 Ticket 升为产品单位。

这不是改名，而是重新划分了「什么是用户需要管理的」。聊天窗口是交互界面，不是工作本身；一个 Ticket 可以跨 Session、跨 Assignment、跨 PR 生命周期存在。这个抽象一旦成立，产品形态就从「聊天框」变成了「工作台」：用户看到的是待处理、进行中、待审查、受阻的任务，而不是一堆需要自己记住上下文的会话。这是 Super-agent 最值得借鉴的一点。

2. 把「注意力」写进架构约束，而不是当成 UX 口号。

「尽可能少地占用人类注意力，同时提供尽可能多的价值」——这句话被落实成了具体规则：Router 才对外说话，Worker 保持安静；只在结果可用、需要决策、任务无法继续时打扰；面板只显示需要人处理的事项；IM 回复不超过 100 词；一次只问一个具体问题；默认 observe，先记录再放开。这些规则单独看都很小，合在一起构成了一种注意力预算。它和操作系统的调度器一样，核心不是「能做多少」，而是「什么时候不做」。

3. 把授权写成 Mandate，让自主行为有据可查。

很多 Agent 系统的权限模型是「用户给了 API Key，Agent 就能做一切」。Super-agent 把「为什么允许做、做到什么范围、依据哪版规则、谁提出的」记录成不可变的 Mandate，并且规定外部内容不能修改权限。这是 capability-based security 的思路：权限是显式授予的能力，不是隐式的环境特权。 对于要接入企业 GitHub、飞书、CI 的 Agent 来说，这比「更聪明的模型」更重要。

7.2 四个需要追问的地方

1. 「省注意力」没有被直接测量。

实验测的是任务完成时间，不是人的打断次数、恢复成本或决策负担。Agent 把执行接过去，但把审查、验收、异常处理留给了人；如果 PR 质量不够，人可能更累。注意力是否真的被节省，需要用户研究，而不是调度实验。论文的「3 到 5 个活跃 Session」是团队观察，不是普遍规律；「23 分钟恢复专注」这类研究也提醒我们，打断的代价很高，但 Super-agent 是否真的降低了打断，还需要数据。

2. Token 成本与中心化 Router 的取舍。

Super-agent 用更多 token 换取更短、更稳定的完成时间；去掉直通会让读缓存 token 增加约 37%，但整体仍比单 Session 贵。Router 是全局序点，也是潜在瓶颈；论文承认，规模扩大后可能需要多层过滤或水平切分，而切分越细，全局连续性越弱。这个权衡没有通解，只有场景解。

3. 安全边界是最大短板。

无沙箱、以操作者身份运行、可读主目录、可执行任意程序；外部事件可被提示词注入。论文把安全与隐私列为开放问题，原型文档要求使用专用操作系统账号。这些是诚实的，但也意味着：在企业环境里，它现在只能作为受控实验，不能作为默认生产力工具。

4. 产品形态仍未解决。

论文第 8.2 节自己提出：当底层 Session 不再对应用户界面上的会话，如何向用户呈现任务、支持中途干预和实时协同？面板是一个起点，但「工作台」长什么样、如何与 GitHub/飞书原生界面融合、如何处理多人协作中的权限与可见性，都还没有答案。

八、对开发者、团队和行业的启示

对开发者

如果你在做 Agent 产品，Super-agent 提供的不是一套可以照抄的代码，而是一组值得借用的原语：

• 用 Ticket 而不是 Session 作为工作单位；
• 用 Thread + Subscription 处理「同一件事的后续消息」；
• 用 Mandate 记录授权依据，而不是把权限藏在 Prompt 里；
• 用 状态机 区分「在跑」「等外部事件」「等人回答」「等审查」「受阻」；
• 用 快慢路径 把确定性过滤和模型判断分开；
• 用 额外槽位 保证人永远能插队。

这些原语与具体模型无关，可以迁移到 LangGraph、Temporal、Claude Agent SDK 或自研运行时上。

对团队

如果你想试，最稳妥的路径是：

1. 从一个仓库、一个专用 Agent 账号、一个专用操作系统账号开始；
2. 先跑 observe，只记录 Agent 会做什么，不开自动执行；
3. 把允许清单收窄到具体的人、具体的群、具体的触发方式；
4. 先度量「人被打断的次数」和「PR 返工率」，再度量「任务完成时间」；
5. 在没有沙箱之前，不要把它接到生产凭据或敏感仓库。

对行业

Super-agent 释放的信号，比它当前的能力更重要：Agent 系统正在变成一种「工作操作系统」。

操作系统要解决的问题，从来不是「让 CPU 跑得更快」，而是调度、隔离、权限、状态、故障恢复和人与系统的接口。Super-agent 把这些词一个个搬进了 Agent 设计：Router 是调度器，Worker 是进程，Ticket 是作业，Mandate 是能力令牌，Thread 是消息队列，Watchdog 是外部控制回路，面板是系统监视器。这个类比不一定精确，但它指向一个真实的趋势：竞争焦点正在从「模型能做什么」转向「系统能可靠地让模型做什么」。

九、结论：一份指南针，而不是一艘船

回到开头的问题：AI 越能干，人为什么越忙？

DeepSeek 的答案是：因为现有 Agent 把「管理多个 Session」的负担留给了人。要解决它，不能只靠更强的模型，而要靠一套系统设计——把 Session 藏起来，把工作变成 Ticket，把授权写成 Mandate，把注意力当成预算，把异常恢复交给控制回路。

这套设计有不少值得借鉴的地方，也有明显的未完成：没有 Watchdog，没有存算分离，没有沙箱，只支持一个仓库，实验是合成的，注意力节省没有被直接测量。它更像一份指南针，指出方向，而不是一艘可以立刻出海的船。

但方向本身值得重视。当 Agent 从「聊天窗口」变成「持续在线的协作者」，我们需要的就不只是更聪明的模型，而是一套能让人放心放手、随时接管的系统。谁先把这套系统做稳，谁就更有机会赢得下一阶段的 Agent 竞争。

留一个问题给你：如果 Agent 真的能自己接活，你最愿意先交给它的是什么？是写代码，还是替你判断「哪些活值得接」？评论区聊聊。

附：关键事实与出处