DeepSeek开源Super-agent，AI开始自己给AI派活，Agent竞争有了新方向

一个程序员，同时指挥五个AI干活，会是什么体验？

一个负责修Bug，一个负责写代码，一个负责测试，另外两个在推进其他项目。看上去，五个AI同时开工，效率应该大幅提升。可现实往往没那么简单。

程序员需要在五个窗口之间来回切换，记住每个任务进行到哪一步、哪个需求发生了变化、哪个AI还缺少信息。忙活一圈，代码是不用自己写了，人却成了五个AI的项目经理。

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

10月31日晚，DeepSeek Harness团队发布技术文章《Super-agent设计探索：迈向更自主的Agent系统》，并同步开源Super-agent技术原型，试图解决这一难题。

与过去接到指令后执行任务的Agent不同，Super-agent希望让AI自己分配工作、主动发现问题，并持续跟进任务，不再事事等待程序员安排。

目前，DeepSeek已经将这套系统用于内部研发，参与Bug复现与修复、代码审查等实际工作。

当AI开始自己给AI派活，Agent行业的竞争，是否也将迎来新的变化？

Agent新难题：AI越来越能干，程序员却管不过来了 

如今，Coding Agent已经能够独立写代码、修Bug、运行测试，甚至完成一些复杂的开发任务。

但一个现实问题是：单个AI越来越能干，多个AI一起工作时，却仍然离不开人的协调。

比如，一个Agent负责开发功能，另一个修Bug，第三个检查代码。虽然每个Agent都能独立完成自己的任务，但工作群里出现新需求、GitHub上收到修改意见，程序员仍需要逐一同步信息、跟进进度。

为什么会这样？ DeepSeek Harness团队在技术文章中指出，当前Coding Agent大多以Session（会话）为中心开展工作。每个Session通常只负责自己的任务，缺少跨会话的统一协调机制。

根据DeepSeek的观察，一个人通常只能同时跟进3至5个活跃Session。

为了解决这一问题，DeepSeek提出Super-agent架构，希望由系统统一接收需求、分配任务、跟进进度，让程序员不必再逐个管理AI会话。

按照官方设想，Super-agent需要具备四项能力：连续、高效、主动、持久。简单来说，就是能够记住不同平台上的工作信息，同时处理多项任务，根据外部消息主动采取行动，并在较长时间内持续运行。

目前，DeepSeek已经在内部研发中运行Super-agent实例。不过，此次对外开源的仍是部分技术验证原型，距离成熟的商业产品还有一定距离。

AI自己派活、主动找活，Super-agent有何不同？ 

让多个AI一起写代码，并不是什么新鲜事。如今，能够调用子Agent、并行处理任务的Coding Agent已经不少。 DeepSeek此次更进一步的尝试，是让AI不仅能够执行任务，还能参与安排和推进工作。

具体来看，主要体现在三个方面。

第一，派活的从人，换成了AI。

假设一名程序员正在开发新功能，工作群里突然有人反馈支付系统出现Bug，GitHub上又收到新的代码审查意见。

过去，程序员可能需要分别打开多个Agent会话，交代任务、同步信息，再逐一检查进度。

而在Super-agent的设计中，这些工作可以由系统统一接收，再交给不同的AI执行。

为此，DeepSeek设计了Router–Worker双层架构。

Router相当于调度员，负责接收消息、判断任务归属；Worker则负责具体执行，可以独立调用工具、修改代码、运行测试，必要时还可以调用子Agent。

例如，支付Bug交给一个Worker，代码审查交给另一个Worker，原本正在进行的功能开发则继续推进。不同任务拥有独立的上下文，可以同时开展工作。

一旦Worker接手某项任务，后续相关消息还可以直接发送给它，不必每次都由Router重新分配。

第二，从等人下指令，到主动找活干。

按照DeepSeek介绍的内部实践，当研发人员在群聊中讨论软件故障时，即使没有人主动要求AI介入，Super-agent也可以识别相关信息，提前尝试复现Bug、分析原因，甚至提交修复代码的Pull Request，等待人工审查。

也就是说，AI开始尝试根据工作环境中的变化，判断哪些问题值得主动处理。

不过，工作群每天可能产生大量消息，如果AI对每条信息都作出响应，不仅浪费算力，也容易频繁打扰用户。

因此，DeepSeek采用两级消息过滤机制：先通过程序规则排除明显无关的信息，再由大模型结合上下文判断是否值得介入。

同时，系统还可以利用缓存和历史信息检索，帮助Agent理解此前的讨论与当前任务之间的关联。

第三，从完成一次指令，到持续跟进一项工作。

真实的软件研发，很少能够通过一条指令就全部完成。

一个Bug从发现到修复，可能经历问题复现、代码修改、测试验证、人工审查等多个环节，期间还会不断出现新信息。

为此，DeepSeek引入了异步执行、存算分离和Watchdog等机制。

其中，异步执行让Agent在后台运行测试等耗时任务时，仍能接收新消息；存算分离让系统可以在云端保留任务状态，同时连接用户自己的开发设备；Watchdog则负责监测任务是否停滞、偏离目标，并在发现异常时尝试恢复。

例如，一个Worker正在运行测试，用户又提出新的修改意见，系统可以在不必等待全部测试结束的情况下处理新消息。如果本地设备暂时离线，相关任务状态也能够保留，等待设备重新连接后继续执行需要本地环境的操作。

需要注意的是，异步执行虽然已经实现，但目前尚未默认开启，此次开源的原型也只覆盖了部分设计。

那么，这套架构究竟能带来多大的效率提升？ DeepSeek进行了一组模拟实验：在包含约300条消息、20项工作请求的测试中，Super-agent的任务完成时间P95为15.7分钟，而采用中性提示词的Session+Subagent方案为29.5分钟，前者缩短约47%。

多Agent协作已经不新鲜，DeepSeek为何还要自研新架构？ 

如今的AI编程赛道，已经聚集了不少实力强劲的玩家。

从Cursor、Devin，到Claude Code、Codex，AI不仅能写代码、修Bug，还能调用子Agent，并行处理复杂开发任务。

既然如此，DeepSeek为什么还要专门研发一套Super-agent架构？

一方面，现有Coding Agent已经具备多Agent能力，但不同方案的协作重点并不相同。

Claude Code、Codex等产品正在通过子Agent和并行任务提高开发效率。一类常见方案是围绕具体开发任务进行分工，让不同Agent分别完成代码编写、测试和审查。

而Super-agent此次重点探索的，是多个独立任务之间的持续协调。

例如，当任务来自不同项目和工作平台、不断收到新消息时，系统如何持续跟进并协调工作，而不是只围绕某项具体开发任务组织多个Agent。

这并不意味着现有产品无法处理多个独立任务，而是DeepSeek此次选择了不同的架构研究重点。

另一方面，仅靠提示词指挥多个Agent，协作行为还不够稳定。

一种常见做法是让主Agent负责分配任务，再调用子Agent执行。但模型是否主动委派工作，可能受到提示词的明显影响。 DeepSeek的模拟实验发现，使用中性提示词时，五轮测试中没有一次主动调用子Agent；明确鼓励任务委派后，五轮中有四轮使用了子Agent。

同样具备调用能力，仅仅改变提示词，协作行为就出现明显差异。

因此，DeepSeek希望通过独立的系统架构，将任务路由、消息过滤、状态管理等工作交给明确的工程机制，减少多Agent协调对模型临场判断的依赖。

这些并不是什么全新的技术原理。消息路由、规则过滤、状态管理和异常监测，早已广泛应用于传统软件系统。

DeepSeek此次探索的重点，是将这些成熟的工程方法引入多Agent管理，让协作不再完全依赖模型每次自行判断。

相比直接推出另一款商业化Coding Agent，DeepSeek此次选择以MIT协议开源部分技术原型，尝试在多Agent协调这一尚未形成统一方案的领域提供新的技术思路。

当然，Super-agent目前仍处于技术探索阶段，其实际开发效果、运行成本和大规模协作能力，都需要进一步检验。

Agent竞争进入下一阶段：不只比能力，更要拼效率和可靠性 

DeepSeek此次Super-agent仍处于技术验证阶段，但它所关注的问题，已经超出单一AI编程工具的范畴。

随着Agent逐渐具备独立执行任务、调用工具和协同工作的能力，行业需要进一步考虑：如何让这些能力在真实业务中持续发挥价值？

沿着这一方向，未来Agent的发展可能呈现三个趋势。

首先，Agent将从完成一次性任务，走向长期参与企业业务。

过去，Agent的典型使用方式是接收一项指令，完成任务后返回结果。但企业的真实业务往往持续数周甚至数月，期间还会不断出现新需求、新信息和新问题。

未来，Agent有望从按需调用的工具，逐渐变成能够持续参与业务的执行单元。

例如，一个Agent今天参与修复Bug，几周后项目再次出现类似问题，它不仅需要找回此前的修改记录，还要理解当时为什么这样处理，以及最新需求是否已经发生变化。

这意味着，长期运行的关键不只是记住更多信息，还要能够根据新情况调整工作，避免过时信息影响判断。

谁能让Agent在长期运行中保持稳定和准确，谁才更有机会将其真正融入企业日常工作。

其次，多Agent协作将从追求并行数量，转向追求整体效率。

同时运行多个Agent，并不必然带来更高效率。

当多个Agent参与同一项目时，任务之间可能存在依赖，不同Agent可能重复处理相同问题，甚至同时修改一份代码，造成冲突。

尤其对于企业而言，真正有价值的指标，是任务完成时间、交付质量和投入产出比，而不是系统中Agent的数量。

因此，未来衡量多Agent系统的效率，不能只看单个任务完成得有多快，还要看整个任务队列的完成效率，以及为此付出了多少模型调用成本。

最后，安全与治理能力，将成为Agent规模化落地的关键门槛。

过去，AI主要负责生成内容，即使出现错误，往往还需要用户进一步操作。但当Agent能够直接调用工具、修改代码、访问业务系统，错误决策就可能产生实际后果。

特别是在多Agent系统中，任务和信息会在不同执行单元之间流转，权限管理也会更加复杂。

例如，一个Agent可以读取哪些数据，能否将信息传递给其他Agent，哪些操作必须经过人工审批，出现异常后又该如何停止和追溯，都需要明确规则。

因此，权限控制、行为审计、异常恢复和人工接管等能力，有望从附加功能逐渐成为Agent系统的基础配置。

Agent的自主权限越大，系统对人工审批、操作追溯和异常接管的要求就越高。自主性与可控性，将成为企业级Agent必须同时解决的两道题。

总体来看，长期运行、整体效率和安全治理，将共同影响Agent能否从技术演示走向企业生产环境。

结语 

从代码补全到自主编程，AI已经越来越擅长完成具体任务。DeepSeek此次Super-agent探索，则把问题推向了下一步：当AI程序员越来越多，如何让它们真正形成一支能够持续工作的团队？

目前，Super-agent仍是一套有待验证的技术原型，距离成熟应用还有不少挑战。 

但它释放出的信号值得关注：AI编程的竞争，正在从让单个Agent更能干，延伸到让整个Agent系统更高效。

未来，决定Agent能走多远的，或许不只是模型有多聪明，还有这些AI能否被可靠地组织起来，真正完成复杂的现实工作。