连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 自己发起，完成情况也主要由它自己报告，使用者该怎样确认它真的做了，而不是相信一句“已完成”？

　　X 用户 Supersocks 看重的则是这次公开的工程细节。他把它概括为，其他实验室在卖智能体，DeepSeek 把设计方案摆了出来。他列举了过滤消息、分派任务、控制回复长度、检查进展等环节，并称其中不少做法与自己正在搭建的智能体系统相似。

　　对准备把这套原型装进团队试用的开发者，安装文档已经把几个选择摆在面前：让它看哪些消息，替谁接活，用什么账号提交代码，以及是否允许自动合并修改。

　　其中，自动合并的建议默认值是“不”。先由人审查并合并，等它提交的修改在一段时间里表现可靠，再决定是否放开这项权限。