深度求索披露智能体架构：AI自主调度任务

深度求索（DeepSeek）正在探索一种让AI自行组织工作的智能体架构。DeepSeek Harness团队发表技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，介绍如何让一个持续在线的协调者调度多个执行智能体，在群聊、GitHub等平台之间连续推进任务。团队已经构建内部Super-agent实例并用于日常研发：即使没有人主动@它，系统也能从群聊反馈中发现潜在软件缺陷，尝试复现和修复，甚至提交GitHub Pull Request，等待开发人员审查。这仍是一项面向工程实践的架构探索，部分设计已通过开源原型实现，尚非正式推出的独立产品。

从管理聊天窗口，到管理工作目标

过去一年，以Coding Agent为代表的工具已经能够阅读代码、定位Bug、运行测试，并承担复杂的软件开发任务。但模型执行能力提升后，人类的注意力开始成为新的限制。多数Agent仍以Session，即会话，作为基本工作单位，用户需要在不同窗口之间切换，记住每项任务的背景并跟踪进展。DeepSeek团队观察到，一个人通常只能同时跟进3到5个活跃Session。即便借助CLI、MCP等工具接入更多平台，单会话串行执行、多任务上下文混杂，以及本地设备离线造成的任务中断，也不会自动得到解决。

Super-agent试图把这些管理责任转移到系统内部。团队提出四项核心能力：跨会话连续交互、多任务高效并行、主动响应环境事件，以及长期在线和异常恢复。其内部实践展示了跨平台连续工作的方式：开发者先在群聊中确定方案，随后在GitHub评论里修改要求，Agent可以结合前后信息调整执行方向。对用户而言，同一项工作不必因为交流地点变化而重新说明背景；对系统而言，则需要识别不同渠道中的消息究竟是在创建任务、补充信息，还是改变已有目标。

架构的核心是Router与Worker组成的双层结构。Router作为持续运行的全局协调节点，接收群聊、GitHub、邮件等平台的信息，负责理解消息、分配任务和维护跨任务上下文；Worker拥有各自独立的上下文与工具能力，分别开展问题复现、代码审查或功能开发，必要时还能调用Subagent。执行完成后，Worker向Router汇报关键结果，由Router统一对用户沟通。团队认为，要求用户手动管理Session，很大程度上延续了底层大模型API的设计习惯；随着系统能力提升，会话应逐渐成为内部技术细节。Router主要承担理解与分派，相对轻量的模型也可能胜任，而更强模型可以用于复杂执行任务，这为按职责配置模型提供了空间。

事件驱动，让AI在后台提前行动

为了降低多智能体之间的协调开销，DeepSeek引入订阅与事件直通机制。例如，一个Worker接手某个GitHub Pull Request后，后续评论和状态变化可以直接发送给它，无须每次都让Router重新判断归属。更进一步，群聊消息、邮件、日程提醒、GitHub评论和CI测试结果，都能作为触发行动的Trigger。考虑到大多数群聊内容不需要AI参与，系统设置两级过滤：先用程序规则快速排除无关消息，再由大模型结合上下文判断是否有必要行动。这意味着主动性需要建立在筛选之上，否则持续接收消息很容易变成持续消耗算力和打扰用户。

团队还借鉴计算机系统中的“投机执行”思想，在尚不确定成果是否会被采用时，先利用后台算力尝试，有价值才交付，无价值则放弃。内部用户群中配置的“静默复现并修复”策略就是一个例子：当有人反馈Bug或讨论修改方案时，Super-agent可以在后台复现问题、分析原因并寻找修复方法；只有确认问题存在，且找到相对简单的修复方案后，才向开发人员提交结果，否则保持安静。团队展示的案例中，人类还在群聊讨论解决方案，系统已经提交了修复Pull Request。这里交付的是待审查的代码变更，后续仍需开发人员判断能否采用。类似机制也可以用于个人助手：收到会议邀请后，提前核对日程、搜集背景资料并准备回复草稿，等待用户确认。

主动执行还要求系统在忙碌时保持可交互。常见的ReAct Loop中，模型发起耗时工具调用后，需要等待结果返回，期间可能无法及时处理新指令。DeepSeek设计的异步ReAct Loop将耗时任务移到后台，前台继续接收消息，完成后再返回结果，用户因而能够在执行过程中改变方向或要求终止。该机制已经在DeepSeek Harness中实现，但尚未默认开启。其实际意义在于，长任务不再必然占住整条交互通道，系统可以同时处理执行进展与人类新增要求。

持续在线的基础设施与实验表现

针对设备依赖，DeepSeek借鉴存算分离思路，将Agent执行循环放在云端，把会话状态保存到数据库，而代码仓库、文件和工具链等工作环境仍可保留在用户设备上。本地只需运行轻量级daemon，接收云端命令并返回结果。这里的“电脑关机后仍能保持工作连续性”需要准确理解：云端保留执行与状态管理能力，依赖本地环境的相关任务可以等设备重新上线后继续，并不意味着离线设备上的工具仍能运行。此外，独立的Watchdog机制负责检查任务有没有进展、是否陷入无效循环，并在发现异常时尝试修复，为长期运行提供额外监督。

团队用一组初步实验检验调度效果：模拟群聊和GitHub CI消息流，单次包含约300条消息，其中约20条是真正的工作请求，将Super-agent与传统“单Session加Subagent”方案对比，每种方案重复运行5次。Super-agent的任务完成时间p50为12.4分钟，p95为15.7分钟；使用中性提示词的传统单Session方案，p95达到29.5分钟。差异主要出在任务如何分派：传统方案虽然具备调用Subagent的能力，但是否使用依赖提示词和模型当时的判断。中性提示配置下，5次实验中模型一次也没有调用Subagent，所有任务都留在主会话执行，并持续受到新消息干扰。双层架构则通过明确分工，让Router专注分派、Worker独立执行，减少了这种不确定性。

效率收益伴随着额外成本。维护多个独立会话使Super-agent的缓存读取Token消耗高于单Session方案，而事件直通机制能够缓解协调负担：取消该机制后，Router需要作出的决定增加约30%，总缓存读取量从2323万Token升至3177万Token，增幅约37%。另一项测试中，当事件到达速率从每分钟约1条升至40条，Router通过批量处理提高吞吐量，单次请求耗时仅从2.5秒增加至3.9秒。这些结果说明，协调机制会直接影响系统速度与资源消耗。不过，实验使用合成消息和模拟耗时工具，主要验证任务调度及协作能力，并未直接评估真实编码质量，因此不能据此推断它在真实项目中的代码正确率或全面生产效率。

走向数字同事，仍需解决记忆与控制

持续运行将放大短会话中不明显的问题，首先是长期记忆。当任务积累到数周甚至数月后，系统如何准确恢复历史上下文，仍是团队指出的难题。跨平台协作不仅需要保存消息，还需要在新指令到来时找出真正相关的旧决策。如果历史要求、当前任务状态和后续修改无法被可靠衔接，智能体即使始终在线，也可能沿着过时目标继续执行。从架构目标看，连续性必须同时包含状态保存与正确理解，数据库解决了保存环节，却不等于长期记忆问题已经完成。

安全与隐私同样影响应用边界。Super-agent持续读取外部消息，并通过云端访问本地设备；提示词注入或服务端入侵可能进一步威胁代码仓库、敏感数据与本地凭据。群聊内容、邮件或代码评论既是工作线索，也可能成为不可信指令的载体，因此系统需要可靠区分外部信息与实际授权。同时，当Agent可以并行推进大量任务，用户怎样查看进度、及时介入，以及哪些操作必须经过人工批准，都需要重新设计。减少窗口切换能够节省注意力，但任务增多后，进度呈现和干预入口也必须让人能够掌握局面。

目前，DeepSeek已将部分设计实现为dsh-superagent-prototype原型插件，相关架构仍在持续探索。团队在文章结尾坦言，并没有提出全新的理论，而是将任务调度、缓存管理、事件驱动、存算分离等经典计算机系统思想应用到Agent架构中。这也解释了此次探索的重点：在模型已经能够承担不少单项任务的基础上，进一步组织任务之间的信息流、执行顺序和恢复机制。内部使用案例说明这条路线具备实践价值，但长期运行的可靠性、真实开发质量和整体成本，仍需要更广泛的场景验证。

Super-agent描绘的后续方向，是让人类更多负责确定目标、作出决策和验收成果，由AI发现可处理的问题、协调执行者并持续推进工作。它能否成为真正可依赖的数字同事，取决于调度提速能否与可控成本、准确记忆、清晰权限和有效的人类监督同时成立。深度求索此次披露的架构，将这些问题放进同一个工程系统中讨论，也让智能体竞争的关注点从单次回答和单项执行，进一步延伸到长期协作能力。