跳到正文
爱范儿· 莫崇宇·· 2 小时前精选AI 评分78

DeepSeek Harness 团队发布 Super-agent 架构设计探索

DeepSeek 重磅发布全新 Agent 架构:AI 开始指挥 AI 干活

AI 导读

DeepSeek Harness 团队发表技术文章《Super-agent 设计探索:迈向更自主的 Agent 系统》,提出由 Router 和 Worker 组成的双层架构,让 Agent 跨会话持续在线、并行处理任务并主动响应群聊、GitHub 等事件。

推荐理由

DeepSeek 公开 Super-agent 架构设计与内部实测数据,可看到多智能体调度在真实协作场景中的收益与 Token 成本。

正文

当程序员还在群聊里讨论 Bug 怎么修时,AI 可能已经默默完成了问题复现,甚至把修复代码提交到了 GitHub。

就在刚刚,DeepSeek Harness 团队发表技术文章《Super-agent 设计探索:迈向更自主的 Agent 系统》,详细介绍了他们正在探索的 Super-agent 架构。

按照 DeepSeek 的设想,未来的 AI Agent 将不再局限于单个聊天窗口,而是能够持续在线、同时处理多项任务,并根据外部环境变化主动采取行动。

更值得关注的是,DeepSeek 已经基于 DeepSeek Harness 构建了一套内部 Super-agent 实例,并将其用于日常研发协作。

例如,当团队成员在群聊中反馈软件问题时,即使没有人主动 @ AI,它也能识别潜在缺陷,在后台尝试复现问题、寻找修复方案,甚至直接提交 GitHub Pull Request,等待开发人员审查。

Image

同一项开发任务还能在群聊和 GitHub 之间连续推进。开发者先在群聊中确定方案,随后又在 GitHub 评论中修改要求,Agent 能够理解前后变化,并调整执行方向。

Image

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

AI Agent 的下一个瓶颈,可能是人类自己

过去一年,以 Coding Agent 为代表的 AI 工具已经能够独立阅读代码、定位 Bug、运行测试,甚至完成复杂的软件开发任务。

然而,随着模型能力越来越强,另一个问题也开始显现。

AI 能够同时完成的任务越来越多,人类管理这些任务的注意力却没有同步增长。

目前,大多数 Agent 仍以 Session,也就是会话为基本工作单位。用户需要在不同窗口之间反复切换,记住各个任务的上下文,并持续跟踪执行进度。

DeepSeek 团队提到,根据他们的观察,一个人通常只能同时跟进 3 到 5 个活跃 Session。

即使通过 CLI、MCP 等工具让 Agent 接入更多平台,仍然难以解决单会话串行执行、多任务上下文混乱,以及本地设备离线后任务中断等问题。

为此,DeepSeek 提出了 Super-agent,希望让 Agent 从单次会话中解放出来,成为一个能够长期运行、跨平台保持上下文、并行推进任务的连续实体。

按照文章中的定义,Super-agent 需要具备四项能力,包括跨会话的连续交互、多任务高效并行、主动响应环境事件,以及长期在线和异常恢复。

换句话说,人类可以更多地负责确定目标和验收结果,具体的任务调度与执行过程则交给 AI 管理。

Image

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

为了实现这一目标,DeepSeek 设计了一套由 Router 和 Worker 组成的双层架构。

可以将其理解为一个由 AI 组成的虚拟团队,Router 负责统筹协调,Worker 负责具体执行。

Router 是持续运行的全局协调节点,统一接收来自群聊、GitHub、邮件等不同平台的信息,判断任务应该如何分配,并维护跨任务上下文。

真正执行任务的则是 Worker。每个 Worker 拥有独立的上下文和工具能力,可以分别负责问题复现、代码审查、功能开发等任务,必要时还能继续调用 Subagent。

任务完成后,Worker 将关键结果汇报给 Router,再由后者统一与用户沟通。

对于用户而言,面对的始终是同一个 AI 助手;对于系统而言,背后可能已经有多个独立 Agent 同时工作。

Image

为了减少协调开销,DeepSeek 还引入订阅机制。当某个 Worker 接手 GitHub Pull Request 后,后续评论和状态变化可以直接发送给它,无须每次经过 Router 重新分配。

Image

Router 主要负责信息理解和任务分派,因此相对轻量的模型也可能胜任,能力更强的模型则用于复杂任务执行。

DeepSeek 认为,传统 Agent 让用户手动管理 Session,很大程度上延续了底层大模型 API 的设计习惯。随着 Agent 能力提升,Session 应该逐渐成为系统内部的技术细节。

没人 @ 它,AI 也能主动修 Bug

相比多任务并行,Super-agent 更值得关注的能力,是主动寻找值得处理的事情。

传统 AI 助手通常需要用户先提出问题,再调用工具完成任务。DeepSeek 希望改变这种工作方式,让 Agent 直接根据外部环境中的事件采取行动。

群聊消息、邮件、日程提醒、GitHub 评论以及 CI 测试结果,都可以成为触发 Agent 行动的事件,技术上称为 Trigger。

Image

考虑到绝大多数群聊消息并不需要 AI 介入,DeepSeek 设计了两级过滤机制,由程序规则快速排除无关消息,再交给大模型结合上下文判断是否需要行动。

Image

更进一步,DeepSeek 还引入了计算机系统中的投机执行思想。

所谓投机执行,就是在尚未确定结果是否会被采用时,提前利用后台算力进行尝试,有价值的结果再提交给用户,没有价值则直接放弃。

例如,DeepSeek 在内部用户群中配置了一项「静默复现并修复」策略。

当有人反馈 Bug 或讨论修改方案时,Super-agent 可以提前在后台复现问题、分析原因,并寻找修复方案。

只有确认问题存在,并找到相对简单的修复方法后,AI 才会把结果提交给开发人员,否则全程保持安静。

DeepSeek 展示的案例中,团队成员还在群聊里讨论解决方案,Super-agent 就已经在后台提交了修复 Pull Request。

Image

类似机制也可以应用于个人助手,例如收到会议邀请后,AI 可以提前核对日程、搜集背景资料,并准备邮件回复草稿,等待用户确认。

电脑关机,AI 也能继续工作

除了主动性,DeepSeek 还尝试解决传统 Agent 的响应阻塞和设备依赖问题。

在常见的 ReAct Loop 中,模型发起耗时工具调用后,需要等待结果返回,期间可能无法及时响应新的指令。

DeepSeek 因此设计了异步 ReAct Loop,让耗时任务转入后台执行,前台会话继续接收用户消息,任务完成后再将结果发送回来。

AI 可以一边执行复杂任务,一边接受新指令,用户还能在执行过程中要求它改变方向或终止任务。

Image

该机制已经在 DeepSeek Harness 中实现,但尚未默认开启。

与此同时,DeepSeek 借鉴存算分离的思路,将 Agent 的执行循环放在云端,将会话状态保存到数据库,而代码仓库、文件和工具链等工作环境仍然可以留在用户设备上。

本地只需部署一个轻量级 daemon,负责接收云端命令并返回结果。即使电脑暂时离线,相关任务也可以在设备重新上线后继续执行。

Image

此外,DeepSeek 还引入独立的 Watchdog 机制,相当于给 Agent 安排了一个 AI 监督员,负责检查任务是否取得进展、是否陷入无效循环,并在发现异常时尝试修复。

实测效率提升,但也更费 Token

为了验证新架构,DeepSeek 团队进行了一组初步实验。

实验模拟群聊和 GitHub CI 消息流,单次包含约 300 条消息,其中约 20 条是真正的工作请求。研究人员将 Super-agent 与传统单 Session 加 Subagent 的方案进行对比,每种方案重复运行五次。

Image

结果显示,Super-agent 的任务完成时间 p50 为 12.4 分钟,p95 为 15.7 分钟;采用中性提示词的传统单 Session 方案,p95 则达到 29.5 分钟。

Image

差异主要来自任务调度。传统方案虽然支持 Subagent,但模型是否真正分派任务,仍取决于提示词和临场判断。

在中性提示配置下,五次实验中模型一次都没有调用 Subagent,所有任务都在主会话中执行,不断受到新消息干扰。

Super-agent 则通过双层架构,让 Router 专注任务分派,Worker 独立执行,减少了这种不确定性。

不过,效率提升也有代价。由于需要维护多个独立会话,Super-agent 消耗的缓存读取 Token 高于单 Session。

取消事件直通机制后,Router 需要做出的决定增加约 30%,总缓存读取量从 2323 万增加至 3177 万 Token,增幅约 37%。

另外,当事件到达速率从每分钟约 1 条升至 40 条时,Router 可以通过批量处理提高吞吐量,单次请求耗时仅从 2.5 秒增加至 3.9 秒。

Image

需要注意的是,实验使用合成消息和模拟耗时工具,主要验证任务调度与协作能力,并未直接评估真实编码质量。

DeepSeek 想让 AI 成为真正的数字同事

尽管 DeepSeek 已经在内部运行 Super-agent,但距离大规模应用仍有不少挑战。

首先是长期记忆。当任务积累到数周甚至数月后,如何准确恢复历史上下文,仍然是一个难题。

其次是安全与隐私。由于 Super-agent 会持续接收外部消息,并通过云端访问本地设备,一旦遭遇提示词注入或服务端入侵,就可能威胁代码仓库、敏感数据和本地凭据。

此外,当 Agent 能够同时推进大量任务时,用户应该如何查看进度、介入执行,以及决定哪些操作必须人工批准,也需要重新设计。

目前,DeepSeek 已将部分设计实现为 dsh-superagent-prototype 原型插件,相关架构仍在持续探索。

值得注意的是,DeepSeek 团队在文章结尾坦言,他们并没有提出全新的理论,而是将任务调度、缓存管理、事件驱动、存算分离等经典计算机系统思想应用到了 Agent 架构中。

但随着模型完成单个任务越来越少需要人工干预,人类能够同时管理多少个 AI,正在成为新的问题。

过去,我们需要不断向 AI 发送指令,告诉它下一步做什么。按照 Super-agent 的设想,未来人类可以更多地负责确定目标、做出决策和验收成果,让 AI 自己发现问题、协调任务并完成执行。

或许未来真正成熟的 AI 助手,不会一直待在聊天窗口里等待提问,而是像一位能够长期参与工作的数字同事,在你没有主动找它的时候,也知道自己应该做些什么。

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

来源:爱范儿 · ifanr.com