主流的编程 Agent 与模型已经具备极强的任务交付能力，但在企业团队开发环境下，或许你会有更高的期望。想象下这些场景：

开发同事在群里提需求，测试者在 GitHub 上建 Issue，评审反馈 PR 问题 — 这些都能被一个 Agent ”伙伴“看到，并按需生成任务，持续推进，并在合适的渠道给你反馈。

DeepSeek 最近发布的 Super-agent 设计和原型插件，关注的就是这件事：

一个能够真正放进开发团队、随时在线、主动响应的编程 Agent — 自动组织任务、会话和上下文，让团队少做搬运和催办，把注意力留给决策与验收。

一、Super-agent：始终在线的团队 Agent

企业的团队协作开发中，一件事很少能在某个开发者的一个对话里结束。

某个改动要求可能最开始出现在群聊，开发时有人再补充个边界，代码提交后又会收到来自 Review 的意见。与此同时，某一个 Issue 又在等修复.....

每件事都有自己的进度，也都可能被一条新的消息推动。

一般情况下，这些工作会交给多个 Agent：辨别优先级、依赖关系、加补充说明、提醒它继续，再把结果反馈给团队讨论的地方。任务越多，需要记住的细节也越多。

而且，这些 Agent 会话上下文不共享 — 会话关闭、上下文压缩，或者换一位同事接手，之前的决定可能又得解释一遍。

DeepSeek Super-agent 针对的，正是这层持续的任务组织与协同工作。

团队继续使用群聊、GitHub Issue 和代码评审继续使用，Super-agent 则负责在后台发现任务，把新任务交给合适的执行者；每个任务有自己的工作上下文和 Worktree；一个任务在进行，其他任务仍有机会继续；任务完成后，也会反馈结果给团队。

用一个场景举例说明：

• 产品同事先在飞书群里提出：软件正文、代码和终端的字体，希望分别配置
• 维护者在原飞书话题中 @Super-agent，请它实现
• Super-agent 接到消息、评估、启动任务、修改代码，提交 PR，反馈到群里
• 同事可以接着 PR 进行追问，Super-agent 也可以自动回答
• 设计师对 PR 实现提出建议，要求调整设置的布局
• Super-agent 识别并沿用已有的需求做改动，合并 PR，并通知到群内
  

在这段协作发生时，另一个执行会话可以修复某个系统 Bug，第三个会话也可以做接口测试 — 它们共享必要的项目背景，但各自保存任务细节。

团队不需要给每个会话补充需求讨论细节，也不用因为一个任务耗时暂停其他工作。

Super-agent 就像团队里面一个随时在线、工作主动的小伙伴：

记住谁提出了什么要求、哪些技术决策已经确定、代码改在哪里、还在等谁的反馈；并负责把开发者们分散的问题接入，形成工作任务，并持续推进完成。

二、整体架构：协调（路由）器 + 执行器

作为团队“一员”的Super-agent，需要应对来自不同渠道的连续交互与多任务的高效处理，这需要基础架构的改进 — 不能是单一会话的排队处理，也不能简单的一对一的派生新会话。前者虽然上下文最连续但效率太低，后者并发能力强但资源占用大，且会话之间太割裂。

Super-agent 用两层逻辑架构与职责组织这个流程：

• 协调（路由）层：承接外部消息（GitHub/飞书等），判断该接什么任务、交给谁
• 执行层：负责在隔离上下文中执行具体任务，修改代码、测试、验证

两层之间通过任务“工单”连接，工单保存任务身份和授权依据等；执行会话则持有任务所需的上下文。

参考 DeepSeek 官方介绍与原型实现，其整体流程大致为：

• 入口检查来源范围，属于已讨论的补充（比如已处理的工单），就送回原任务
• 否则检查发起人与“接单”规则，主会话安排工单、分派执行会话和工作目录
• 执行会话处理“工单“，报告进展，系统保存结果，再将答复送回合适的对话
  

单个工单可以经历多轮执行，可以关联多个讨论事件（比如，围绕“字体独立配置”的多轮讨论）；这样换一轮执行，不需要重新定义需求和补充上下文。

三、五个设计要点

现在来关注 Super-agent 两层架构背后一些更具体的设计细节（有可能在未来 DeepSeek 正式产品中出现变化）：

1. 两层架构：是逻辑分层，并非物理限制

需要注意的是，Super-agent 的两层架构是逻辑分工，并不一定是单个 Agent、单个Session。比如，一个复杂任务工单的执行，完全可以由一个 Agent + 多个 Subagent 的Agent Team 来完成 — 执行器内部仍可派生并调用 Subagent 以拆解复杂工作。

即使是很轻的协调层，在输入事件量较大可能导致拥堵时，也可能需要切分成多个协调器，牺牲连续性，提高吞吐量。

2. 事件驱动：核心是过滤和路由

群消息、GitHub Issues 评论、PR 和自动 CI 的结果，都可以转成 Super-agent 的事件。很显然，这些事件不必全部转成真正的任务，所以首先需要的是过滤。

过滤可以分为确定性的规则过滤和语义过滤：

• 对来源、身份、群机器人白名单等确定性条件先由程序检查。
• 程序检查后的候选事件，交给 LLM 做语义过滤 — 规则来自提示词定义的策略。
  

如果说过滤解决“是否进入任务流”，路由则解决“由谁继续处理任务”：

哪些是已处理任务的后续消息，可以直接送回负责该工单的执行器；哪些需要派生新的工作任务交给执行器来处理；哪些是没有工作价值的日常讨论，应直接忽略。

3. 异步执行循环：长工具不占住整段对话

一次任务的执行，通常是一次 Agent ReAct 循环：推理、调用工具、观察结果、继续推理，即每次需要等待工具执行完毕，才会进入下一次推理。

那么这里的问题是，较慢的工具调用会阻塞对后续用户消息的响应 — 比如，上一次提出的修改需求正在处理中，此时用户又补充了某个消息，此时会话就无法响应。

DeepSeek Harness 目前其实已经内置了针对这种情况的“异步 ReAct”任务机制：

ReAct 循环启动工具后立刻返回，不再等待完成；工具执行完成后，再把工具结果作为新事件送回会话即可。

这样就解决了会话被长工具调用卡住的问题，更快的响应用户输入。

4. 按需组织上下文，让会话能找回完整事实

作为一个服务于团队不同任务的 Agent，管理好任务的上下文至关重要。

Super-agent 上下文管理的整体策略可以概括为：

不让每一个会话窗口永远装着全部历史，而是将近期相关内容直接放入窗口，而把长日志、完整报告等低频信息留在窗口之外，并保留摘要与引用。在需要细节时，模型沿消息、事件链（Thread）、执行会话等之间的关联关系，顺着引用展开更多上下文。

这样既减少重复塞入长上下文，也让压缩后的会话仍有机会回到原始记录。总体上有点类似一些 Memory 产品机制，但管理上更复杂。

5. 分离计算、状态和环境：重启才有依据接续

如果将本地 Agent 作为 Super-agent 接入团队，一个面临的问题是一旦设备离线， Agent 就会停止运行。那么如何让 Super-agent 持久在线？ DeepSeek 提出的方法是将 Agent 的计算、持久化状态、工具等执行环境做分离。其设想是：

• Agent Loop（推理循环） 运行在云端的无状态容器中
• 持久化状态（任务进度、消息等）存入数据库
• 工具调用执行（Git 访问、写文件、回复消息）则放在端侧

四、实践：把 GitHub 和飞书接到同一个 Super-agent

以上是 DeepSeek 对 Super-agent 的架构设计，目前尚未完全产品化。但 DeepSeek 发布了一个轻量级的原型项目，我们可以借此一探未来的 Super-agent。你可以在 GitHub 搜索 dsh-superagent-prototype 项目（基于 DSH 的插件）。

我们用这个项目做简单演示：

步骤 1：让 AI 按官方说明安装配置

官方项目的 SETUP.md 是面向 Agent 的部署指南，所以我们可以让 AI 帮忙部署，并给出明确的说明，剩下的就交给 AI 吧。比如：

AI 会完成 DSH 与依赖安装、构建、启动、独立配置创建和插件注册等，并完成官方的检查、构建和基础测试。过程中可能会有若干需要你配合确认的问题。

步骤 2：检查与配置来源、规则等

在第一步完成后，大部分的配置会自动设置好。但你也可以在完成后进入 Super-agent的设置界面：

以 GitHub 为例，这里可以配置以下常见项目：

• 来源：指定一个代码仓库、访问GitHub的 CLI；接收的事件（Issue、PR、CI等）
• 接单规则：哪些账号可发起工作；如何处理；接单规则（接收什么，忽略什么）
• 执行环境：任务工单 Git 工作树的根目录、状态目录；执行器用的模型等
• 提示词：一般不建议改动，即 Super-agent 工作中用到的各种提示词
  

Super-agent 需要一个 GitHub 仓库的执行账号，需要仓库读写权限，并核验命令入口的实际登录身份。

后续你可以在 GitHub Issue 等 @ 这个执行账号，Super-agent 就会接收到事件，并开始“工作”。

步骤 3：创建一个 Issue，触发一次修复任务

一切准备就绪后，现在我们来创建一个演示的 GitHub Issue。

在仓库的 Issues 页面新建一个 Issue，随后用另一个账号增加评论：

现在，你无需做任何动作，等待一段时间后，将可以在 DSH 面板看到 Super-agent 的协调器和执行器的工作区启动；同时进入 Superagent 插件面板的“执行” 区，可以看到授权的工单，记录请求者、范围和原讨论链等：

任务完成后，你会在 GitHub Issue 里看到 Super-agent 的回复：

步骤 4：沿原任务补充新的要求

现在我们有了一个待审的 PR。假设此时有其他的同事想起来有新的补充，怎么办？

他只需要在同一个 Issue 中继续追加要求，而且此时无需 @ 执行账号：

现在，Super-agent 将会开始一次新的执行。但是这一次的执行不会开启新的会话任务，而是进入原任务，这是合理的 — 因为本来就是在同一个 Issue 的处理过程中：

同之前一样，任务完成后 Super-agent 会自动回复到 Issue，注意，此时并没有创建新的 PR — 这也正是我们的要求：

步骤 5：创建飞书机器人，接入聊天群

目前 Super-agent 还支持的一个接入渠道是飞书群。

最简单的方法是让 AI 帮你将 Super-agent 接入飞书群（需要登录飞书平台）：经过自建应用和机器人、设置权限、生成并绑定安全凭据、创建测试群并邀请机器人等步骤后，AI 会查询群和用户标识，写入 Super-agent 策略并启用飞书来源：

步骤 6：从飞书群接单，再在原话题追问

现在你可以用类似上面 GitHub Issue 的方式与 Super-agent 进行沟通，发起任务、查看结果、追加任务等：

同样，你可以在 DSH 的 Super-agent 面板看到任务的执行。

上面也可以看到，由于两个入口现在都接入了同一套 Super-agent，所以两个渠道之间实现了无缝协作 — 飞书群接到任务，在 GitHub 执行，再到飞书群回复，这是完全可行的（具体的行为可能会受到 GitHub 和飞书机器人的授权限制）：

最后

以上是对 DeepSeek 的 Super-agent 架构的介绍，及其原型项目的体验。

尽管正式产品尚未发布，不过已能看到：企业级编程 Agent 的关注重心，正从更强的模型生成能力、更长更复杂的任务，逐渐转向团队协作背景下的持续、高效、主动的工作推进，或许未来不仅是人人都有自己的 Agent，团队也将拥有自己的 Super Agent。