刚刚，DeepSeek 重磅发布全新 Agent 架构：AI 开始指挥 AI 干活

程序员还在群里讨论 Bug 怎么修，AI 可能已经复现问题、跑完测试，把修复代码提交到了 GitHub。DeepSeek Harness 的 Super-agent 架构，让 Router 负责调度、Worker 并行执行，AI 从会话工具变成长期在线的数字同事。

当程序员还在群聊里讨论 Bug 怎么修时，AI 可能已经完成了问题复现，分析了代码，跑完测试，甚至把修复代码提交到了 GitHub。真正改变工作方式的，不是又多了一个聊天窗口，而是 Agent 开始自己管理任务、上下文和执行节奏。

DeepSeek Harness 团队最近公开探索中的 Super-agent 架构，目标是让 AI 从“等待人类发指令的会话工具”，变成能够长期在线、跨平台接收事件、并行推进任务的数字同事。相关设计已经有部分原型实现，但目前仍是工程实践探索，并非 DeepSeek 正式推出的独立产品。

这套架构最值得开发者关注的地方有三个：Router 负责统一调度，Worker 负责隔离执行；外部事件可以主动触发任务；耗时工作进入后台后，用户仍能继续发新指令。它解决的不是模型会不会写代码，而是多个 AI 任务如何持续、可控地协同运行。

AI Agent的下一个瓶颈：人类只能盯住几个会话

过去一年，Coding Agent 已经能够阅读代码、定位 Bug、运行测试，甚至完成复杂的软件开发任务。但大多数 Agent 仍然以 Session，也就是单个会话，作为基本工作单位。

这会带来几个很现实的问题：用户需要在不同窗口之间来回切换；每个窗口都有独立上下文；多个任务同时推进时，很容易忘记哪个任务正在等待输入；电脑关机或网络中断后，执行状态也可能丢失。

DeepSeek 团队观察到，一个人通常只能同时跟进 3 到 5 个活跃 Session。即使使用 CLI、MCP 等工具让 Agent 接入更多平台，单会话串行、多任务上下文混乱和本地设备依赖仍然存在。

Super-agent 的思路，是把 Session 从用户界面中隐藏起来。用户只需要描述目标和验收标准，系统在后台为不同任务分配独立执行单元，并持续维护任务状态。

按照这套定义，一个真正的 Super-agent 至少需要四种能力：跨会话连续交互、多任务并行、主动响应环境事件，以及长期在线和异常恢复。人类更多负责确定目标、做出决策和验收结果，任务调度与重复执行则交给 AI 系统。

Router和Worker：一个AI当主管，多个AI同时干活

Super-agent 的核心是 Router 和 Worker 组成的双层架构，可以把它理解成一个由 AI 组成的虚拟团队。

Router 是持续运行的全局协调节点，统一接收群聊、GitHub、邮件等平台的消息，判断消息是否构成任务，决定交给哪个 Worker，并维护跨任务的总体状态。Router 不负责把每一行代码都写完，它的职责是理解上下文、拆解任务和分配工作。

Worker 才是真正执行任务的节点。每个 Worker 拥有独立上下文和工具权限，可以分别负责问题复现、代码审查、功能开发、测试验证或文档整理。遇到更复杂的工作时，Worker 还能继续调用 Subagent。

任务完成后，Worker 将关键结果汇报给 Router，再由 Router 统一和用户沟通。对用户来说，始终面对同一个 AI 助手；对系统来说，背后可能已经有多个相互隔离的 Agent 在并行工作。

这层拆分带来两个工程收益。第一，单个任务的上下文不会被其他任务污染；第二，Router 可以使用相对轻量的模型，而复杂代码执行交给能力更强的 Worker。模型路由也因此从“一个模型包打天下”变成了按职责分工。

为了减少重复调度，系统还引入了订阅机制。当某个 Worker 接手 GitHub Pull Request 后，后续评论和状态变化可以直接发给这个 Worker，不需要每条消息都绕回 Router 重新判断。

没人@它，AI也能主动修Bug

传统 AI 助手通常需要用户先提问，再调用工具。Super-agent 更进一步，把群聊消息、邮件、日程提醒、GitHub 评论和 CI 测试结果都视为可能触发行动的事件，也就是 Trigger。

绝大多数消息并不值得启动 Agent，所以系统采用两级过滤：第一层由程序规则快速排除无关消息，第二层再让模型结合上下文判断是否应该行动。

更有意思的是投机执行。系统可以在尚未确定结果是否会被采用时，提前使用后台算力进行尝试；确认有价值后提交给用户，没有价值就直接丢弃。

例如，团队可以配置“静默复现并修复”策略。当有人在群里反馈 Bug 或讨论修改方案时，Super-agent 在后台读取相关代码、复现问题并寻找修复方式。只有确认问题存在，并找到相对简单且风险可控的方案后，系统才提交 Pull Request 等待开发者审查。

这里的关键不是让 AI 获得无限自主权，而是把“主动发现”和“最终提交”分开。复现、分析和生成补丁可以在沙箱内自动进行，合并代码、修改生产配置和发送外部消息仍要经过人工或权限网关批准。

异步ReAct：电脑关机后任务还能继续

在常见的 ReAct Loop 中，模型发起耗时工具调用后，当前会话往往要等待结果返回。工具执行时间一长，Agent 既不能及时响应新指令，也容易让用户误以为任务已经停止。

Super-agent 引入异步 ReAct Loop，把耗时任务转移到后台，前台会话继续接收用户消息。任务完成后，系统再把结果发送回来；执行过程中，用户也可以要求 Agent 改变方向或终止任务。

这套机制已经在 DeepSeek Harness 中实现，但尚未默认开启。它要求任务状态能够持久化，前台交互和后台执行必须共享同一份可恢复状态，而不是把所有进度都留在模型上下文里。

为了解决设备依赖，系统借鉴存算分离的思路：Agent 执行循环放在云端，会话状态保存到数据库，代码仓库、文件和工具链仍然可以留在用户设备上。本地只部署一个轻量级 daemon，负责接收云端命令并返回结果。电脑暂时离线时，任务可以等设备重新上线后继续执行。

另外，Watchdog 负责检查任务是否取得进展、是否陷入无效循环，并在发现异常时尝试修复。对长时间运行的 Agent 来说，监督器不是可选装饰，而是避免“任务看似运行、实际一直原地循环”的必要组件。

实验结果：任务更快，但Token消耗更高

DeepSeek 团队用群聊和 GitHub CI 消息流做了一组初步实验。每次模拟约 300 条消息，其中约 20 条是真正的工作请求；Super-agent 与“单 Session 加 Subagent”方案各重复运行五次。

结果显示，Super-agent 的任务完成时间 p50 为 12.4 分钟，p95 为 15.7 分钟；采用中性提示词的传统单 Session 方案，p95 达到 29.5 分钟。

差异主要来自任务调度。传统方案虽然支持 Subagent，但模型是否真的分派任务取决于提示词和临场判断；五次实验中，中性提示下模型一次都没有调用 Subagent，所有任务都挤在主会话里执行，还不断受到新消息干扰。Super-agent 则把调度职责固定交给 Router，把执行职责交给 Worker。

代价也很清楚：多个独立会话需要更多缓存读取 Token。取消事件直通机制后，Router 需要做出的决定增加约 30%，总缓存读取量从 2323 万增加到 3177 万 Token，增幅约 37%。当事件速率从每分钟约 1 条增加到 40 条时，Router 可以通过批量处理提高吞吐，单次请求耗时从 2.5 秒增加到 3.9 秒。

这组实验使用的是合成消息和模拟耗时工具，主要验证任务调度与协作能力，并没有直接评估真实编码质量。因此，12.4 分钟和 15.7 分钟不能直接当成生产环境的交付承诺，真实仓库还需要单独测量测试通过率、错误修复率和人工返工量。

Super-agent落地前，安全边界要先设计

长期在线、跨平台接收消息、云端访问本地设备，会让 Agent 的能力边界显著扩大，也会把安全问题从“提示词是否安全”扩展到整个执行系统。

首先是长期记忆。任务运行数周甚至数月后，系统如何准确恢复历史上下文，如何删除过期信息，如何避免把一个项目的权限和记忆带到另一个项目，都会影响实际可用性。

其次是提示词注入和服务端入侵。Agent 可能读取群聊、邮件、GitHub 评论和 CI 输出，这些外部内容都可能携带恶意指令。云端调度器一旦被误导，就可能把危险操作传给本地 daemon，进而影响代码仓库、凭据和内部数据。

建议至少设置四道边界：

1. Router 只负责调度，不直接拥有生产写权限。
2. Worker 使用项目级沙箱和路径白名单，不能跳出工作区读取文件。
3. 本地 daemon 对命令、网络、凭据和外部副作用实施独立审批。
4. 每个任务保存事件轨迹、工具调用、文件 diff 和可恢复检查点。

另一个容易被忽视的问题是用户控制权。Agent 能同时推进更多任务后，界面必须让用户看见任务树、当前状态、等待原因、已执行操作和待确认动作。没有可观测性，多 Agent 不是效率工具，而是一组难以追责的后台进程。

从聊天机器人到数字同事，还差哪些工程能力

Super-agent 的价值不在于提出一个全新的模型理论，而在于把任务调度、事件驱动、缓存管理、存算分离和异常监控这些经典系统能力组合到 Agent 工作流里。

如果要在自己的团队里验证类似架构，可以先从一个低风险闭环开始：让 Router 监听 GitHub Issue 和 CI 失败事件；让 Worker 在临时分支里复现问题、运行测试并生成补丁；让 Watchdog 监控执行进度；最后由开发者审查 diff 并决定是否合并。

这个闭环需要记录的不是一句最终回答，而是完整轨迹：事件何时到达、Router 为什么分派、Worker 调用了哪些工具、花了多少 Token、改了哪些文件、测试是否通过、失败后如何恢复。只有这些数据齐全，才能判断 Agent 的效率提升是否抵消了额外成本。

目前 DeepSeek 已将部分设计实现为 dsh-superagent-prototype 原型插件，相关架构仍在持续探索。它更适合作为研究和工程验证的起点，而不是可以直接替代生产流程的成品。

国内开发者如果需要将 Claude Code 等工具接入兼容 API，可通过 Code80(https://code.ai80.vip/home) 配置 endpoint；Router、Worker 的权限、密钥隔离、预算和审计仍应由项目侧管理。

常见问题

Super-agent是DeepSeek已经正式发布的产品吗？

不是。目前公开的是 DeepSeek Harness 团队的架构探索和部分开源原型，不能等同于已经商业化发布的独立产品。

Router和Worker分别负责什么？

Router 负责接收事件、维护全局状态和分派任务；Worker 拥有独立上下文和工具能力，负责具体执行、验证和结果汇报。

Agent为什么需要主动监听外部事件？

因为很多工作并不是由一条聊天指令开始的。GitHub 评论、CI 失败、邮件和日程变化都可能构成任务触发器，但系统必须先过滤无关消息，再决定是否行动。

异步ReAct能解决什么问题？

它把耗时工具调用放入后台，让前台会话继续接收新指令；任务完成后再回传结果，也支持用户中途改变方向或终止执行。

实验中的速度提升能直接复制到生产吗？

不能。实验使用合成消息和模拟工具，主要验证调度效率。生产环境还要重新评估代码质量、测试通过率、Token 成本、人工返工和安全风险。

国内开发者如何接入类似工作流？

可以通过 Code80 了解兼容 API 接入方式，同时自行控制模型权限、工具网关、密钥、数据留存和审计日志。