当程序员还在群里争论 Bug 怎么修时，AI 可能已经默默完成了问题复现、定位根因，甚至把修复代码提交到了 GitHub，等人审查。

这不是科幻设定。DeepSeek Harness 团队刚刚发表技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，详细披露了一套正在内部研发协作中跑通的 Super-agent 架构。

核心变化很直接：AI 不再是一个等你提问的聊天框，而是一个长期在线、能同时干多件事、还会主动找活干的"数字同事"。

没人 @ 它，AI 已经把 Bug 修了

DeepSeek 已经基于 DeepSeek Harness 构建了内部 Super-agent 实例，直接接入日常研发流程。

典型场景是这样的：产品用户群里每天产生大量消息，没人主动 @ Super-agent。它静默监听、不介入日常讨论。但当有人反馈一条具体缺陷——比如"macOS 桌面端窗口未聚焦时点击会话会被识别为双击，每天误触发几十次"——它会在后台自动识别、复现问题、排查代码，然后直接提交 Pull Request，并附上根因分析和前后对比截图。

同一个任务还能在 IM 群聊和 GitHub 之间无缝流转。开发者先在群里提出字体配置需求，Agent 提交 PR；随后又在 GitHub 评论里反复修改 UI 方案——从折叠控件到直接展开，Agent 都能理解前后变化、持续调整，直到 PR 最终合并。

【编辑观察】最让人头皮发麻的是"无人指派"这个细节。传统 Agent 是"你喊它才动"，Super-agent 直接把工作逻辑倒过来了：它在环境里自己判断该不该动手。

需要说明的是，Super-agent 目前仍是面向工程实践的架构探索，部分设计通过开源原型实现，尚不是 DeepSeek 正式推出的独立产品。

瓶颈不是 AI 不够强，是人管不过来

过去一年，Coding Agent 已经能独立读代码、定位 Bug、跑测试。但 DeepSeek 团队观察到一个反直觉的问题：AI 能干的活越来越多，人类管理这些任务的注意力却没跟着涨。

当前主流 Agent 都以 Session（会话）为基本单位。用户要在多个窗口间反复切换，记住每个任务的上下文，持续跟踪进度。一个人通常只能同时跟进 3 到 5 个活跃 Session。即便用 CLI、MCP 把 Agent 接入更多平台，单会话串行、多任务上下文混乱、设备离线任务中断等问题依然存在。

Super-agent 的目标就是把 Agent 从单次会话里解放出来，变成一个长期运行、跨平台保持上下文、并行推进任务的连续实体。按定义，它需要四项核心能力：

  • 跨会话连续交互：不在一个窗口聊完就失忆
  • 多任务高效并行：同时推进多项工作不串线
  • 主动响应环境事件：没人喊也能发现问题
  • 长期在线与异常恢复：关机、断网后任务还能续上

一个 AI 当主管，多个 AI 同时干活

架构层面，DeepSeek 设计了 Router + Worker 双层结构，本质上是搭了一个 AI 虚拟团队。

Router 是持续运行的全局协调节点，统一接收群聊、GitHub、邮件等不同平台的信息，判断任务怎么分配，维护跨任务上下文。它是用户面对的"同一个 AI 助手"。

Worker 是真正干活的执行单元，每个 Worker 拥有独立上下文和工具能力，分别负责问题复现、代码审查、功能开发，必要时还能继续调用 Subagent。干完活把关键结果汇报给 Router，由后者统一跟用户沟通。

为了减少协调开销，DeepSeek 还引入了订阅机制：Worker 接手某个 GitHub PR 后，后续评论和状态变化直接推给它，不用每次都经 Router 重新分配。Router 主要做信息理解和任务分派，轻量模型就能胜任；复杂执行才动用能力更强的模型。

DeepSeek 团队的观点很鲜明：传统 Agent 让用户手动管理 Session，本质是沿用了大模型 API 的底层设计习惯。随着 Agent 能力增强，Session 应该退化为系统内部的技术细节，而不是甩给用户的操作负担。

Trigger 机制：从"被动应答"到"主动出手"

Super-agent 最具颠覆性的能力，是主动寻找值得处理的事情。

群聊消息、邮件、日程提醒、GitHub 评论、CI 测试结果，都可以成为触发 Agent 行动的事件，技术上叫 Trigger。一个 IM 话题里从 Bug 报告到复现确认，一条 PR 从提交到 CI 失败再到审查意见，每一步都可以驱动 Agent 介入。

但群里 99% 的消息都是闲聊，不能让 AI 什么都插一脚。DeepSeek 设计了两级过滤：

  • Fast Path（程序层策略）：用确定性规则按群组范围、来源白名单快速排除无关消息，不调用 LLM
  • Slow Path（语义层策略）：剩下的交给大模型结合上下文判断，无需介入就保持静默，真正需要时才开始路由

更进一步，DeepSeek 把 CPU 的**投机执行（Speculative Execution）**思想搬了过来：在结果是否会被采用还不确定时，先拿后台算力偷偷试，有价值再提交，没价值直接扔掉。

内部用户群配置了"静默复现并修复"策略：有人反馈 Bug 或讨论修改方案时，Super-agent 提前在后台复现、分析、找修复方案。只有确认问题存在且修复相对简单，才把结果抛给开发者；否则全程安静。

典型案例是波浪号渲染问题：群里还在争论"该让模型转义还是改渲染规则"，Super-agent 已经提交了 PR，还顺手引用 Pandoc、markdown-it 和 GFM 的规范差异解释了为什么单个 ~ 不该渲染成删除线。

这套机制同样适用于个人助手：收到会议邀请后，AI 可以提前核对日程、搜集背景资料、写好邮件回复草稿，等你点确认。

电脑关机，任务照样跑

传统 Agent 还有两个老毛病：工具调用时阻塞前台，以及任务绑定本地设备。

DeepSeek 用异步 ReAct Loop解决第一个问题：耗时工具调用转入后台执行，立即返回 Started 通知，前台会话继续接收新消息。用户可以一边让它跑复杂任务，一边发新指令，甚至中途改方向或终止任务。

设备依赖则借鉴了存算分离：Agent 的执行循环跑在云端无状态弹性容器，会话状态持久化到数据库；代码仓库、文件、工具链等工作环境仍可留在用户设备上，本地只跑一个轻量 daemon 接收云端命令。电脑离线没关系，重新上线后任务继续。

此外还有独立的 Watchdog 机制，相当于给 Agent 配了个 AI 监督员，专门检查任务有没有进展、是否陷入无效循环，发现异常就尝试自愈。

实测：速度快一倍，Token 翻几倍

为了验证架构，团队做了一组对照实验：模拟群聊和 GitHub CI 消息流，单次约 300 条消息，其中约 20 条是真正的工作请求，每种方案跑 5 次。

结果相当能说明问题：

  • Super-agent：p50 完成时间 12.4 分钟，p95 为 15.7 分钟，缓存读取 Token 约 2323 万
  • 传统单 Session + Subagent（中性提示）：p50 为 20.4 分钟，p95 高达 29.5 分钟，Token 仅 605 万
  • 加上"提示优先委派"后，传统方案 p50 缩到 13.8 分钟，但 p95 仍有 29.0 分钟

差距主要在调度稳定性。传统方案虽然支持 Subagent，但模型到底派不派活，全看提示词和临场发挥——中性提示下，五次实验模型一次都没调用 Subagent，所有任务挤在主会话里被新消息反复打断。Super-agent 靠架构硬保证 Router 专职分派、Worker 独立执行，消除了这种不确定性。

代价同样真实：维护多个独立会话意味着 Token 消耗显著上升。取消事件直通后，Router 决策量增加约 30%，缓存读取量从 2323 万涨到 3177 万，增幅约 37%。

高并发场景下 Router 表现还不错：事件到达速率从每分钟 1 条升到 40 条时，靠批量处理，单次请求耗时只从 2.5 秒涨到 3.9 秒，单个决定的分摊推理时间反而大幅下降。

【编辑观察】效率和算力成本的交换非常赤裸——Super-agent 本质是用更多 Token 买更确定的多任务调度。对企业研发场景这笔账可能划算，但个人用户能不能承受，还得看产品化后的定价。需要注意的是，实验使用合成消息和模拟工具，主要验证调度协作能力，并未直接评估真实编码质量。

从聊天机器人到数字同事，还差几道坎

尽管已经在内部跑起来，Super-agent 距离大规模应用仍有硬骨头：

  • 长期记忆：任务积累数周甚至数月后，如何准确恢复历史上下文仍是难题
  • 安全与隐私：持续接收外部消息、云端访问本地设备，一旦遭遇提示词注入或服务端入侵，代码仓库、敏感数据、本地凭据都会暴露
  • 人机权责重设计：Agent 同时推进大量任务时，进度怎么看、何时介入、哪些操作必须人工批准，交互范式要重来

目前部分设计已实现为 dsh-superagent-prototype 原型插件，架构仍在迭代。DeepSeek 团队在文章结尾很坦诚：他们并没有提出全新理论，而是把任务调度、缓存管理、事件驱动、存算分离这些经典计算机系统思想重新组合到 Agent 上。

但真正的趋势已经很清晰：当模型完成单个任务越来越不需要人盯，人类能同时管理多少个 AI，正在取代"AI 能不能干活"成为新瓶颈。未来成熟的 AI 助手或许不会一直待在聊天框里等提问——它更像一位长期在编的同事，在你没找它的时候，也知道该干什么。