连AI都有领导了！DeepSeek让它们自己抢活干|deepseek|代码|调用|上下文|智能体

分享至

出品 | 网易智能·今日硬核

作者 | 辰辰

编辑 | 王凤枝

给AI也配上“领导”了。

10月31日，DeepSeek团队发布《Super-agent设计探索》，并将配套的原型以MIT协议开源。这套系统让多个AI组队干活，接需求、派任务、写代码，各司其职。不过，目前公开的仍是研究原型，还不是面向普通用户的正式产品。

按照团队的设计，用户只需要跟负责统筹的“AI领导”沟通，它会把任务分派给手下的AI分头推进。干活中途要是用户临时加需求、改方案，也由这位“领导”统一接住再往下安排，省得用户自己在好几个聊天窗口之间来回当传话筒。

这群AI还会“眼里有活”，主动找事干。在DeepSeek公布的一个内部案例里，有人在群里反馈软件问题，没有点名让AI帮忙，它就按预设规则在后台尝试复现问题、寻找修法。群里还在讨论怎么解决，AI已经把改好的代码提交上去，等着开发者审核了。

团队给它设定的规矩叫“静默复现并修复”：只有确认问题存在、修法又比较简单时，它才会把结果交出来；要是没找到合适的解法，就保持安静，不用一连串“正在处理中”打断群聊。

01一个人，能同时盯几个AI窗口？

如今，让AI帮忙写代码已经有不少工具可选。从读项目、定位问题，到修改文件、运行测试，不少任务都可以交给智能体一气呵成。但要是同时开上好几个任务，人还是得在脑子里记着：哪个窗口正在改什么，哪个已经跑完，刚收到的新要求又该贴给谁。

DeepSeek团队在文章中写道，据他们观察，一个人通常只能同时跟进三到五个活跃会话。这是团队日常积累的使用经验，并非测出来的硬性上限。模型的单项能力虽然还在往上走，但人能同时照看的窗口数量，却未必能跟着增加。

一旦任务跨了平台，交接还会更麻烦。比如团队先在工作群里商量好采用方案A，后来到了GitHub的代码评审里又临时改成方案B；如果两边各自对应一个独立的AI会话，人就得手动去补齐背景，免得两边还在各干各的。

Super-agent想把这部分交接接过去。按团队描述，他们内部运行的实例能够在群聊和GitHub之间继续同一个开发任务，理解后来补充的修改要求。用户换了说话的地方，也不用把前因后果从头交代一遍。

单纯给一个聊天窗口接上更多工具，还不能解决这些问题。如果把几件事都塞进同一个会话里处理，前一项操作耗时太久，后面的需求就可能得排队；可要是每件事都另开新窗口，又容易丢掉任务之间的上下文联系。为此，DeepSeek把“协调”和“执行”拆开了。

02一个AI派活，一群AI同时开工

负责统筹全局的是路由层（Router），也就是开头提到的“AI领导”。它负责接收来自不同入口的消息，记清楚各个任务之间的关系，并决定该把新需求派给谁。按照设计，这位“领导”自己并不动手写代码，也不操心每项任务内部的具体规划，甚至可以不给它配备执行命令的工具。

团队在实践中发现，这份协调工作其实没有想象中那么复杂，哪怕用相对轻量的模型，也能兼顾响应速度与调度效果。

具体执行交给工作层（Worker）。每个执行智能体都有自己独立的会话和工具，专心处理手头的一项任务；至于怎么改代码、怎么跑验证，由它继续推进。遇到复杂任务时，执行端还可以进一步调用子智能体。由于代码质量主要取决于这一层，团队建议给它配能力更强的模型。

在这套双层架构下，各个执行智能体的中间步骤留在自己的会话里，把关键结果交回协调层，最后由协调层统一向用户汇报。多项工作可以同时推进，也不用让好几个AI轮番跑到群里汇报。

它们接收的信息并不局限于人专门写给AI的指令。设计文章把工作群消息、邮件、日程提醒、代码评审意见以及自动化测试结果等，都列为了可能触发工作的信号。究竟接入哪些来源、允许处理哪些消息，还要由使用者自己配置。

工作群里每天都有大量闲聊，显然不值得每条都调动大模型去判断一遍。为此，系统设了两道关卡：先用普通程序检查消息来源、群组范围和用户白名单，把不在范围内的内容直接筛掉；剩下的消息需要理解语义，再交给模型结合上下文去判断。

等任务派出去之后，后续的跟进消息也不必每次都经“领导”转手。同一个代码修改请求（Pull Request，简称PR）或同一个群聊话题里的更新，可以直接送到正在处理它的执行智能体；新要求超出了原定范围，再交回协调层统筹安排。

如果碰巧有几个执行智能体在同一个PR上干活，它们也能收到这个PR的后续消息，有机会发现彼此的改动与潜在冲突。少数需要跨任务协调的复杂情况，再由Router介入。

团队在模拟实验中试着关掉了这条消息直通路径，结果发现任务完成时间几乎没变，但协调层需要做的决策次数增加了约30%，缓存读取的token消耗也增加了约37%。让消息少绕一圈，主要省下的是协调过程中的推理开销。

03后台还在跑任务，中途也能随时改方案

开头提到的主动修Bug案例，用到了团队所说的“投机执行”（Speculative Execution）：还不知道结果最后会不会被采纳，就先在后台尝试，做出有用的结果再交付。

在团队设想的个人助手场景里，收到会议邀请后，AI可以先在后台核对日程冲突、搜集背景资料、拟好回复草稿，最后交由用户过目确认。研发群里的自动修复，则是这套思路在团队内部已经出现的实际用法。

除了提前动手，干活中途还能不能听进去新要求，也影响使用体验。按照传统的一类串行执行流程，模型发起耗时的工具调用后，要等工具把结果传回来，才能继续处理下一条消息。测试还在跑着，用户想临时改个条件，可能也得跟着等。

DeepSeek的做法是把耗时命令和子任务改为后台执行。工具先返回“已启动”，会话随后就能继续接收用户的新消息，等后台任务跑完了再把结果送回来。如果情况有变，模型也可以根据上下文叫停耗时过长的后台命令。团队表示，这套异步机制已在DeepSeek Harness中实现，但尚未默认开启。

另一个问题是电脑休眠或断网。现在很多本地智能体把运行程序、会话记录和代码环境都放在同一台设备上，电脑一休眠，AI也就跟着停工了。

设计文章提出，把负责推进任务的程序放到云端，会话记录存进数据库，代码库和本地工具依然留在用户自己的电脑上。用户的设备只需要跑一个轻量程序，负责执行命令、传回结果。这样不用为了让AI工作，把整套本地开发环境搬上云端；遇到必须在某台本地电脑上执行的任务，等它重新上线后再接着跑。

要想让系统长期稳定运转，还得防着中途卡死或跑偏。团队在主系统之外单配了一个独立的监控智能体（Watchdog），定时巡检任务状态。它不仅看接口有没有报错、中断后能不能恢复，还会盯着执行智能体是不是一直在那儿空转调用工具、却拿不出实质进展，或者干脆已经偏离了原本的目标。

X用户“山景城小路”评价称，这是他最近读过最有条理的智能体系统设计文章，吸引他的地方在于：全文几乎不谈模型本身有多强，而是讨论当模型足够强之后，系统究竟该怎么搭。

另一位X用户“暗蓝Alan Hu”认为，当大模型的推理和工具调用能力跨过门槛后，构建高自主性智能体的难题，越来越多地落在并发调度、缓存管理、异步交互和容错恢复上。这些也是传统计算机系统长期处理的问题。

04模拟测试确实变快了，代价有多大？

为了验证这套架构的调度效果，DeepSeek跑了一组模拟测试。每次实验大约有300条群聊和自动化测试消息，其中约20条是真正的工作需求，其余包括闲聊、进度跟进、中途叫停和自动化测试消息。每种方案重复跑五轮，团队把实际写代码的环节替换成了一个只消耗时间的模拟工具。这组实验测的是任务怎么被分派和推进，并未评估代码质量。

从任务完成时间来看，Super-agent的中位数为12.4分钟，95分位数为15.7分钟；作为对照，同样配有子智能体工具的单会话方案，在中性提示词下分别为20.4分钟和29.5分钟。后一个指标反映的是耗时较长的那部分任务。

拉开差距的关键，在于有没有真正把活分出去。在中性提示词下，系统虽然允许主模型在合适的时候调用子智能体，但在五轮实验里，它一次都没调用过。所有工作都挤在主会话里，又不断被新进来的消息打断。

当团队把提示词改成“优先委派”后，单会话方案在五轮里有四轮把工作派了出去，完成时间的中位数降到了13.8分钟，已经和Super-agent接近。不过，还是有一轮测试里，模型觉得手头的活儿“很小”，决定自己顺手办了，拖长了部分任务的等待时间，95分位数仍为29.0分钟。

Super-agent则从架构上限定协调层不执行具体任务，把不同工作发往独立会话，减少了模型临场决定“这点小事要不要自己顺手做了”带来的波动。

多开会话干活，用量也会增加。单次实验里，Super-agent读取缓存的token量约为2323万，约为中性提示词单会话方案的3.8倍。这里增加的是读取缓存上下文的用量，不是总账单；实际花多少钱，还得看具体调用的模型、缓存计价以及其他输入输出消耗。

05装好之后，先看看它会接什么活

与文章一同开源的原型项目名为dsh-superagent-prototype，基于DeepSeek Harness运行。项目文档写明，目前公开的代码与团队内部运行的版本、文章里的完整设计并不完全一致，还有部分设计尚未实现。

目前，这个原型主要围绕单个GitHub代码仓库运转，同时支持接入飞书。使用者需要先指定目标仓库、设置允许哪些人派活、订阅哪些群聊消息，并专门为智能体准备一个独立的GitHub账号。安装文档特别提醒，最好不要直接拿开发者自己的个人账号给AI用，而是让AI提交的代码和评论清清楚楚地顶着它自己的身份出现。

主动接活默认处于“观察模式”（observe）。对于没人明确交办、由AI自行判断值得做的事，系统先评估并记下“本来会接哪些活”，暂不执行。获准用户明确交办的任务，不受这项观察模式限制。

使用者可以先翻翻记录，看看AI的接单判断是否合适，再决定要不要切到“自动模式”（auto）。即便开启，主动任务也要符合预设规则，消息来源和权限限制仍然有效。

原型运行的系统权限同样需要留意。项目文档提醒，程序沿用所在操作系统账号的权限，并没有隔离的安全沙箱，建议为它单独建一个系统账号，只放智能体需要的密钥和凭据。它不是装进日常电脑，就能撒手不管的普通聊天软件。

11月1日，开发者拉文德拉·库马尔（Ravindra Kumar）把这套代码克隆到本地，完成构建后跑了四遍测试套件。据他记录，1197项测试里有1196项通过，剩下一项四次都失败：飞书消息处理程序遇到格式错误的数据时，测试用例期待它报错，实际却仍显示“就绪”。他没有进一步查清原因。

库马尔也试跑了底层的DeepSeek Harness。因为没有配置DeepSeek API密钥，第一次调用报错；换成Claude Sonnet 4.6后，Harness完成了一项简单的代码生成与计算任务。完整的仓库协作流程则停在了账号和授权配置环节，他没有继续配置专用GitHub账号，也没有看到执行智能体提交PR。

系统真正跑起来后，公开的沟通规则还约束着它什么时候向人汇报。光建好一个PR不算完事；还没跑完的检查、中间草稿、反复尝试，都应留在内部。可以交付的结果、需要人拍板的决定，以及确实无法继续的阻碍，才值得发到工作群里。

为了减少打扰，团队在设计文章中给出过一条规定：即时通讯中的单次回复不超过100词。详细的问题背景、代码改动和验证结果，可以放进PR，群里只发简短的结论和链接。

机器之间的代码评审也不能无限循环。公开规则要求，针对每个PR、每个自动评审者，最多处理三轮评审；一轮指一次机器评审运行，而非一条评论。面对修改建议，AI要先核实，不能为了获得评审工具的认可，盲目修改和重跑。三轮之后若仍有重要问题，应如实告诉人，严重阻碍仍需提醒。

X用户“深夜提灯人”关心的是最后谁来验收。他写道，一个智能体接需求、几个智能体分头干，听上去省事，但PR到底合不合格、责任由谁承担，仍得有人拍板。

06想要长期跑下去，还有哪些问题没解决？

DeepSeek没有把这套架构称为全新的理论。团队在文末写道，许多做法借用了传统计算机系统已有的经验，而当前实现也依赖一些工程和场景上的简化。

首先是长期记忆。系统可以顺着消息、讨论和任务之间的引用关系，找回最近的上下文；连续跑上几个月之后，怎么从历史记录里准确找回更早的关键背景，仍是开放问题。

组织规模扩大以后，也会出现新的分工问题。任务变多，负责统筹的“AI领导”要不要拆成好几个？目前还没有固定答案。拆得越细，能并行处理的事越多，但各自掌握的信息也越容易分散。放到更大的企业里，还要决定哪些部门之间可以共享上下文，哪些信息必须隔离，不能把所有人的消息都汇到同一个地方。

主动读取外部消息还会带来安全风险。团队指出，云端智能体持续接收外部事件，本地设备上又存着私有代码、敏感数据和账号凭据。一旦云端遭到入侵，或被恶意提示注入（Prompt Injection）诱导，其连接的本地设备就可能面临被控制的风险。怎么让智能体能使用凭据，却不直接看到凭据内容，是文章提出的待解决方向之一。

X用户Doppel也表达了类似的担忧：如果AI把陌生人在仓库或群聊里留下的信息转成任务，攻击者可能借此诱导它行动。他还提出另一层疑问：如果任务由AI自己发起，完成情况也主要由它自己报告，使用者该怎样确认它真的做了，而不是相信一句“已完成”？