DeepSeek 旗下 Harness 团队发布技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，披露其正在构建一套名为 Super-agent 的 AI 代理架构。与当前主流 Agent 以单次会话为工作单位不同，该架构旨在让 AI 持续在线、跨平台保持上下文、并行推进多项任务，并主动根据外部事件采取行动。团队已基于 DeepSeek Harness 搭建内部实例用于日常研发协作，但强调这仍是工程实践层面的架构探索，部分设计以开源原型呈现，并非正式独立产品。

文章指出，当前 AI Agent 的核心瓶颈已从模型能力转向人类注意力。多数 Agent 仍以 Session（会话）为基本单位，用户需在不同窗口间切换、手动跟踪进度。DeepSeek 团队观察发现，一个人通常只能同时跟进 3 到 5 个活跃 Session。即便通过 CLI、MCP 等工具接入更多平台，单会话串行执行、多任务上下文混乱、本地设备离线导致任务中断等问题依然存在。为此，Super-agent 被定义为具备四项能力：跨会话连续交互、多任务高效并行、主动响应环境事件、长期在线与异常恢复。

架构上，Super-agent 采用 Router 与 Worker 双层设计。Router 是持续运行的全局协调节点，统一接收来自群聊、GitHub、邮件等平台的信息，判断任务分配并维护跨任务上下文；Worker 则拥有独立上下文和工具能力，分别执行问题复现、代码审查、功能开发等具体任务，必要时可调用 Subagent。任务完成后，Worker 将关键结果汇报给 Router，由后者统一与用户沟通。为减少协调开销，系统引入订阅机制：当某个 Worker 接手 GitHub Pull Request 后，后续评论和状态变化可直接发送给它，无需每次经过 Router 重新分配。Router 侧重信息理解与任务分派，因此相对轻量的模型即可胜任，能力更强的模型则用于复杂任务执行。

主动性是 Super-agent 的另一核心。传统 AI 助手需用户先提问再调用工具，而 Super-agent 将群聊消息、邮件、日程提醒、GitHub 评论及 CI 测试结果等视为触发事件（Trigger）。考虑到绝大多数群聊消息无需 AI 介入，DeepSeek 设计了两级过滤机制：先由程序规则快速排除无关消息，再交给大模型结合上下文判断是否需要行动。更进一步，团队引入计算机系统中的投机执行思想——在结果尚未确定是否被采用时，提前利用后台算力尝试，有价值的结果再提交用户。内部用户群中已配置「静默复现并修复」策略：当有人反馈 Bug 或讨论修改方案时，Super-agent 可提前在后台复现问题、分析原因并寻找修复方案，仅在确认问题存在且找到相对简单修复方法后，才将结果提交给开发人员，否则全程保持安静。展示案例中，团队成员还在群聊讨论解决方案时，Super-agent 已在后台提交了修复 Pull Request。

针对传统 Agent 的响应阻塞和设备依赖问题，DeepSeek 设计了异步 ReAct Loop，让耗时任务转入后台执行，前台会话继续接收用户消息，任务完成后再将结果送回。该机制已在 DeepSeek Harness 中实现，但尚未默认开启。同时，团队借鉴存算分离思路，将 Agent 执行循环放在云端，会话状态保存至数据库，而代码仓库、文件和工具链等工作环境仍留在用户设备上，本地仅需部署轻量级 daemon 接收云端命令并返回结果。即使电脑离线，任务也可在设备重新上线后继续。此外，独立的 Watchdog 机制充当 AI 监督员，检查任务是否取得进展、是否陷入无效循环，并在发现异常时尝试修复。

为验证架构，DeepSeek 团队进行了一组初步实验：模拟群聊和 GitHub CI 消息流，单次包含约 300 条消息，其中约 20 条为真正工作请求，对比 Super-agent 与传统单 Session 加 Subagent 方案，每种重复五次。结果显示，Super-agent 任务完成时间 p50 为 12.4 分钟、p95 为 15.7 分钟；采用中性提示词的传统单 Session 方案 p95 达 29.5 分钟。差异主要源于任务调度：传统方案虽支持 Subagent，但模型是否真正分派任务取决于提示词和临场判断，中性提示下五次实验模型一次都未调用 Subagent，所有任务在主会话中执行并不断受新消息干扰。Super-agent 则通过双层架构让 Router 专注分派、Worker 独立执行，减少不确定性。

效率提升亦有代价。由于需维护多个独立会话，Super-agent 消耗的缓存读取 Token 高于单 Session。取消事件直通机制后，Router 需做出的决定增加约 30%，总缓存读取量从 2323 万增至 3177 万 Token，增幅约 37%。当事件到达速率从每分钟约 1 条升至 40 条时，Router 可通过批量处理提高吞吐量，单次请求耗时仅从 2.5 秒增至 3.9 秒。需注意，实验使用合成消息和模拟耗时工具，主要验证任务调度与协作能力，并未直接评估真实编码质量。

尽管已在内部运行，Super-agent 距大规模应用仍有挑战。长期记忆方面，任务积累数周甚至数月后如何准确恢复历史上下文仍是难题；安全与隐私方面，Super-agent 持续接收外部消息并通过云端访问本地设备，一旦遭遇提示词注入或服务端入侵，可能威胁代码仓库、敏感数据和本地凭据；交互设计方面，当 Agent 能同时推进大量任务时，用户如何查看进度、介入执行及决定哪些操作必须人工批准，也需重新设计。目前，DeepSeek 已将部分设计实现为 dsh-superagent-prototype 原型插件，架构仍在持续探索。

值得玩味的是，DeepSeek 团队在文末坦言，他们并未提出全新理论，而是将任务调度、缓存管理、事件驱动、存算分离等经典计算机系统思想应用到 Agent 架构中。但随着模型完成单个任务越来越少需要人工干预，人类能够同时管理多少个 AI 正成为新问题。过去用户需不断向 AI 发送指令，而 Super-agent 的设想是让人类更多负责确定目标、做出决策和验收成果，由 AI 自己发现问题、协调任务并完成执行。或许未来成熟的 AI 助手不会一直待在聊天窗口等待提问，而更像一位能长期参与工作的数字同事，在无人主动找它时也知道该做什么。