想象一个画面：你同时指挥五个AI——一个修Bug、一个写功能、一个跑测试，另外两个在忙别的项目。代码是不用亲手敲了，可你得在五个窗口间反复横跳：谁的需求变了、谁还缺信息、谁的进度该催了……一顿操作猛如虎，程序员摇身一变成了“AI项目经理”。

AI越来越能干，人反而越来越忙。

10月31日晚，DeepSeek Harness团队发布技术文章《Super-agent设计探索：迈向更自主的Agent系统》，并同步开源技术原型，想解决的正是这个尴尬：让AI自己接单、自己派活、自己盯进度。目前这套系统已经在DeepSeek内部参与Bug复现与修复、代码审查等实际工作，不过对外开源的仍是部分技术验证原型，离成熟商业产品还有距离。

五个会话管不过来？那就请个“AI包工头”

如今的Coding Agent单打独斗已经很猛：写代码、修Bug、跑测试都不在话下。可一旦多个AI同时开工，协调的锅还是得人来背。

DeepSeek指出，当前Coding Agent大多以Session（会话）为中心，各扫门前雪，缺少跨会话的统一协调机制。而一个人通常只能同时跟进 3至5个活跃Session——这就是瓶颈所在。

Super-agent的破局思路，是让系统统一接收需求、分配任务、跟进进度。它被要求具备四项能力：

  • 连续：记住不同平台上的工作信息
  • 高效：同时处理多项任务
  • 主动：根据外部消息自己采取行动
  • 持久：能够长时间持续运行

具体怎么落地？答案是 Router–Worker双层架构。

Router相当于“调度员”，负责接收消息、判断任务该归谁；Worker是“干活的人”，可以独立调用工具、改代码、跑测试，必要时还能再调用子Agent。支付Bug派给一个Worker，代码审查派给另一个，原来的功能开发继续推进，各任务上下文互不干扰。后续相关消息还能直达对应Worker，不用Router重新派一遍。

没人@它，AI也会主动“找活干”

更有意思的是第二点：从“等人下指令”变成“主动找活”。

按DeepSeek披露的内部实践，研发在群里聊软件故障时，就算没人喊AI，Super-agent也能识别出问题，默默在后台复现Bug、分析原因，甚至直接提交修复代码的Pull Request等人审查。比如有用户反馈macOS桌面端窗口未聚焦时点击会被误判成双击，它就自己定位到Electron吞掉激活点击的根因，连修复PR都交了。

当然，群消息水得很，总不能每条都响应，既烧算力又骚扰人。DeepSeek上了 两级消息过滤：先用程序规则干掉明显无关信息，再让大模型结合上下文判断值不值得介入；缓存和历史信息检索则帮它理解“前因后果”。

一次指令只管一次？它要负责“跟到底”

真实研发里，一个Bug要走复现、修改、测试、审查一连串环节，中途还总有新状况。为此DeepSeek搬出了三件套：

  • 异步执行：后台跑测试这种耗时任务时，照样能接收新消息，不用干等
  • 存算分离：云端留存任务状态，同时连接你本地的开发设备；设备离线也不怕，重连后继续
  • Watchdog：盯着任务有没有卡死、跑偏，异常时自动尝试恢复

效果如何？DeepSeek给了一组模拟实验数据：在约 300条消息、20项工作请求 的测试中，Super-agent任务完成时间P95为 15.7分钟；而使用中性提示词的Session+Subagent方案为29.5分钟——耗时缩短约47%。

【编辑观察】效率数字很漂亮，但也要注意：异步执行目前还没默认开启，开源原型只覆盖了部分设计，跑分来自模拟场景而非大规模生产验证，先别急着神化。

多Agent早不新鲜，DeepSeek为啥还要自己造轮子？

AI编程赛道早就卷成一团：Cursor、Devin、Claude Code、Codex个个能打，也都能调用子Agent并行干活。DeepSeek这时候自研架构，图什么？

第一，协作的重点不一样。 Claude Code、Codex们多是围绕一项具体开发任务分工——写代码的、测试的、审查的各司其职。Super-agent盯着的是 多个独立任务之间的持续协调：任务横跨不同项目和平台、新消息不断涌进来时，怎么持续跟进而不乱。

第二，光靠提示词指挥，协作行为太“看心情”。 实验里，中性提示词下五轮测试没有一次主动调用子Agent；改成明确鼓励委派后，五轮里四轮都用了。同一个模型，改几句提示词行为就天差地别，这在生产环境里显然不够稳。

所以DeepSeek把任务路由、消息过滤、状态管理、异常监测这些传统软件工程里的成熟机制搬进多Agent系统，用明确的工程机制替代模型的“临场发挥”。它没有直接再做一款商业化Coding Agent，而是以 MIT协议 开源部分原型，想给这个还没有统一答案的领域提供一种新思路。

Agent下一阶段：比的不只是聪明，更是靠谱

原型虽早，信号却值得重视。当Agent都能独立干活、调用工具、彼此协同，真正的考题变成了：怎么让这些能力在真实业务里持续产生价值？三个趋势已经浮现。

第一，从一次性任务走向长期驻场。 真实业务动辄持续数周数月，今天修的Bug几周后复发，Agent得翻出当时的修改记录、理解当初为什么这么做，还得判断需求变没变。长期记忆不难，难的是根据新情况更新判断，不被过时信息带偏。

第二，从比拼Agent数量转向整体效率。 同时跑十个Agent不等于高效：任务依赖、重复劳动、同时改一份代码引发冲突，都是坑。企业真正在意的是交付周期、质量和投入产出比，以及整个任务队列的成本——Super-agent单次实验读缓存Token达到2323万，效率背后的成本账同样得算清楚。

第三，安全治理会从“加分项”变成“入场券”。 过去AI生成错内容，用户还能拦一道；现在Agent能直接改代码、访问业务系统，一个错误决策就是实打实的后果。谁能读什么数据、能不能把信息传给别的Agent、哪些操作必须人工审批、出事怎么叫停和追溯——权限控制、行为审计、异常恢复、人工接管，迟早成为基础配置。自主权限越大，可控性要求越高。

写在最后

从代码补全到自主编程，AI已经越来越像一个能干活的程序员；而DeepSeek这次追问的是：当“AI程序员”越来越多，怎么把它们组织成一支能持续作战的团队？

Super-agent还远非成品，成本、稳定性、大规模协作都需要时间检验。但方向已经明牌：AI编程的竞争，正从“让单个Agent更能干”，卷向“让整个Agent系统更高效、更可靠”。 决定Agent能走多远的，恐怕不只是模型有多聪明，而是这群AI能不能被真正可靠地组织起来。