DeepSeek Super Agent 的核心，是把接收需求、判断是否开工与执行任务分开：Router 负责协调，Worker 在独立会话和目录中处理具体工作，任务状态由系统持续保存。用户可以围绕同一件事补充要求，不必始终守着一个聊天窗口，也不必亲自给每个执行者搬运上下文。
AIHOT 汇总的“DeepSeek 开源 Super-agent 双层架构原型”引出了这套方案。本文进一步核对 DeepSeek 官方仓库和设计文档，解释它如何接收事件、延续任务、控制主动工作，以及企业团队可以借鉴什么。资料核对日期为 2026 年 11 月 1 日，本文未安装或实测原型。
Super Agent 是什么？先分清架构设想与公开原型
这里讨论的是 DeepSeek Harness 团队的 Super-agent。公开项目名为 dsh-superagent-prototype，以 DeepSeek Harness 的 bundle 形式运行，面向一个 GitHub 仓库接收工作，也可选接飞书。符合授权条件的请求进入系统后，会形成工作项，执行结果可以通过 Pull Request 等方式返回原对话。
这套方案要解决的问题很具体：当多项工作同时发生时，谁记住每项任务的目标，谁接收后续修改，谁判断哪些消息值得处理，谁在失败后继续推进？如果这些事都由人负责，即使 AI 能独立写代码，人仍要花大量时间切换窗口、解释背景和追问进度。
官方 README明确说明：它是供参考的研究原型，并非 DeepSeek 正式产品，也不是已经达到生产可用标准的软件。公开代码经过发布适配，与内部版本及设计文章并不完全相同，文章中的部分方向尚未实现。因此，不能把完整架构愿景直接当作这个插件已经具备的功能清单。
Router 与 Worker 如何分工？
双层设计把两类节奏不同的工作拆开。Router 要及时理解新消息、判断归属和分派任务；Worker 则需要专注地阅读代码、执行命令和处理测试结果。一个任务在后台运行时，接收需求的一侧仍然可以继续处理其他事项。
| 角色 | 主要处理什么 | 交给下一环节什么 |
|---|---|---|
| Router／主会话 | 评估候选请求，将消息关联到已有任务，决定是否创建工作项 | 任务目标、来源、授权依据和需要继续处理的输入 |
| Worker／执行会话 | 在任务自己的目录和上下文中完成工作，接收后续要求 | 工作结果、进展、失败原因或需要人回答的问题 |
| 运行时与状态存储 | 保存事件、决策、任务、执行记录与待发送消息，安排后续处理 | 可恢复的状态，以及对外发送或启动执行的操作 |
官方实现为主会话和执行会话分别提供 Router 与 Worker preset。架构文档还把领域状态的修改集中到 Engine，由它在事务中处理任务变化；真正的外部操作通过适配器在提交后进行。这让“模型做了一个判断”和“系统真的启动了工作”成为可以追踪的不同步骤。
独立上下文也有实际意义。例如，修复导出错误和修改登录页可以由不同 Worker 处理，各自保留自己的目标、代码和验证记录。需要共享的事实再通过系统传递，减少两项工作互相干扰。不过，独立目录只是工作空间的分开，操作系统权限仍需另行控制。
一条消息如何变成可以持续推进的任务？
公开原型用 Trigger、Thread、Eval、Ticket 和 Assignment 等对象组织工作。理解这些对象，能看清它为什么能够接收后续要求，而不只是“一次提示词生成一次答案”。
- 接收事件。GitHub 或飞书来源把消息送入系统，形成 Trigger；Thread 表示这些事件所属的讨论线程。
- 判断是否处理。来源范围、发送者和授权规则先决定事件能否进入处理路径；需要评估的候选进入 Eval，系统保存决定及理由。
- 创建工作项。接受请求后生成 Ticket，并记录 Mandate，即这项工作的授权依据；Assignment 表示一次具体执行安排。
- 独立执行。Worker 在自己的会话与目录中工作，汇报进展、阻塞或可交付结果。
- 跟随后续讨论。任务订阅关联线程。相关的新消息可以送到原任务，已有关联的人工追问有专门的续办路径，无需每条都重新创建工作项。
- 记录结束结果。系统区分准备就绪、等待人工、PR 合并、讨论关闭和被人停止等情况，避免把一次模型回复结束直接等同于业务完成。
例如，下面是依据上述机制构造的说明场景，并非本文实测：开发者在 Issue 中要求修复一个导出错误，Worker 提交 PR 后，评审者在 PR 评论里补充“空数据时也要保留表头”。如果 PR 已关联到该 Ticket，后续要求便可继续进入这个任务。交付链条由来源消息、工作项和关联讨论连接起来，而不是依赖操作者记住某个窗口。
授权与消息续办的具体规则可查看官方Authorization 文档。其中还区分“作为上下文参考的订阅”和“能够继续推动任务的后续消息”，说明看见一条消息，并不自动获得执行它的权限。
主动找活如何控制？observe 模式尤其值得关注
主动机制最重要的判断是：系统能否把“发现一个可能的问题”与“获得处理授权”分开。公开原型对推断出来的工作提供三种模式：
off：推断类事件不进入候选处理路径。observe：默认模式，评估候选并记录“本来会接受”的决定，但不因此启动工作。auto：符合评估条件、且至少匹配一条启用规则时，允许接受推断任务。
这三个模式主要控制推断任务；满足授权条件的明确请求在各模式下仍可处理。因此，observe 不能简单理解为整个系统只读或所有任务都不执行。团队仍需设置来源、允许名单、消息接收范围与规则，才能限定实际行为。
这一设计给试点提供了一个有用的方法：先观察系统会把哪些讨论识别成工作，再检查是否存在误判。有人说“这个页面有点慢”，可能是在报告缺陷，也可能只是随口交流。先查看判断记录，再决定是否自动接单，比一开始就允许所有候选开工更容易评估边界。
为什么还需要 SQLite、异步队列和恢复机制？
长期运行的 Agent 需要保存的内容超过聊天记录：某条事件是否已经处理、任务为什么被接受、消息是否发出、执行失败后还剩什么，都需要独立状态。公开实现使用 SQLite 保存领域数据，并通过持久化的 Effects 队列执行启动任务、投递输入和发送回复等操作。
其处理顺序是：先在事务里写入状态和待执行操作，提交后再做外部工作；失败操作按规则重试。官方架构文档还描述了宿主重启后恢复中断 Assignment 的路径。这些机制有助于避免一次进程中断就丢失任务去向，但仍不能据此承诺所有第三方操作都恰好执行一次，或任何异常都能自行修复。
这里最值得借鉴的工程思路是让任务事实脱离模型当下的上下文而存在。模型负责理解与决策，系统保存已发生的事实、待执行动作和失败状态。以后更换模型、重建会话或检查争议时，团队仍能回到任务记录核对。
用户通过哪些界面管理它？
用户日常可以在配置好的 GitHub 或飞书入口提出请求、补充要求、接收结果。运营者则在 DeepSeek Harness Web 侧栏打开 Superagent 面板，处理授权配置、执行状态和需要人工介入的事项。
官方Panel 文档列出 Overview、Source、Trigger、Eval、Execution 和 Settings 等页面。Overview 优先呈现需要人处理的任务与系统问题；Eval 可查看判断理由；Execution 可查看工作项、执行安排和待处理输入，并在满足条件时重试；Settings 配置来源、规则、模型、并发和工作目录。
这个界面设计围绕三个问题展开：现在是否需要我，系统是否健康且方向正确，一件工作从触发到交付经历了什么。对于企业内部 Agent，这比只展示对话数量或模型输出长度更接近实际管理需求。
目前能接到哪里，试用前需要准备什么？
当前公开原型绑定一个 github.com 仓库，可选接飞书；官方部署文档写明不支持 GitHub Enterprise Server。不要把架构层面的多渠道设想，扩写成公开原型已接入邮件、企业全部系统或所有代码仓库。
按Deployment 文档，运行条件包括 Node.js 22.19+ 或 24+、pnpm、git 2.32+、Python 3.8+、tmux、GitHub CLI 2.48+，以及为 DeepSeek Harness 配置的模型服务。飞书接入还需要相应应用和命令行工具。项目采用 MIT 许可，但开源许可不等于模型调用、机器和维护没有成本。
权限方面也有一个必须随部署条件一起理解的事实：Router 和 Worker 默认以运行者的操作系统用户权限执行，账号包装工具负责选择凭据，并不隔离进程。官方建议使用仅放置 Agent 所需凭据的独立操作系统账号。工作目录分开、来源名单和模型提示规则，分别解决不同问题，不能互相替代。
企业团队可以怎样借鉴这套方案？
以下是基于官方机制的实施建议，不是 DeepSeek 已交付的企业服务，也不是速优AI的客户实测案例。首个试点适合选择一个测试仓库、一类清楚的任务，例如根据明确的 Issue 复现缺陷并交付可审查的 PR。
- 先复用现有工作入口。继续使用 Issue、PR 评论和现有代码评审流程，写清请求需要包含的复现步骤、预期结果与交付物，减少新增操作入口。
- 再配置请求与任务的关系。限定允许发起工作的人和接收范围，为每项任务保留来源、目标、授权依据、执行记录与结果链接，让后续讨论能找到原工作项。
- 以 observe 检查主动判断。明确请求用于验证执行链条；推断候选用于观察误接单、重复接单和遗漏。只有具体规则的判断记录符合预期，再考虑开放对应自动任务。
- 用真实结果验收。检查需求修改能否到达原任务、失败是否给出可操作原因、重启后任务是否可追踪、PR 是否通过既有检查。模型说“完成”只是一个信号，代码评审与业务验收仍需实际证据。
对于正在规划企业 AI 工作流的团队，Super-agent 提供了一套可以检查代码与状态设计的参考：把消息变成有归属的工作，把主动性放进授权规则，把恢复能力落实为持久状态。需要结合现有业务系统设计接入与交付方式时，可进一步了解速优AI的 FDE 服务与支持，从单一场景的输入、输出和验收条件开始评估。
资料来源与阅读范围
- AIHOT：DeepSeek 开源 Super-agent 双层架构原型，本文选题参考与报道聚合入口。
- DeepSeek 官方仓库与 README，项目定位、公开范围和许可。
- 000 Philosophy，减少人工注意力占用的设计原则。
- 002 Authorization，授权、订阅和主动接单模式。
- 005 Panel，监督界面与管理操作。
- 006 Deployment，运行条件、权限和接入范围。
- 007 Architecture，Engine、状态存储、执行适配器和持久化队列。
本文依据公开文档作方案解读，未测量执行成功率、成本节省或生产环境稳定性；示例与实施建议已在相应段落标明。项目仍在早期，试用时请按官方仓库当时的文档核对配置。