DeepSeek Super-agent 架构解析：AI 开始指挥 AI，人类成为验收者

当程序员还在群聊里讨论 Bug 怎么修时，AI 可能已经默默完成了问题复现，甚至把修复代码提交到了 GitHub。这不是科幻场景，而是 DeepSeek Harness 团队在最新技术文章中公开的 Super-agent 架构实测效果。该架构的核心设想是：未来的 AI Agent 不再局限于单个聊天窗口，而是能够持续在线、同时处理多项任务，并根据外部环境变化主动采取行动。这标志着 Agent 系统正从「被动应答」走向「主动协作」的新阶段。

实测提效与真实的成本代价

过去一年，以 Coding Agent 为代表的 AI 工具已能独立阅读代码、定位 Bug、运行测试，完成复杂的软件开发任务。但随着模型能力越来越强，另一个问题开始显现：AI 能同时完成的任务越来越多，人类管理这些任务的注意力却没有同步增长。目前大多数 Agent 仍以会话为基本工作单位，用户需要在不同窗口间反复切换、记住各任务上下文。据 DeepSeek 观察，一个人通常只能同时跟进 3 到 5 个活跃会话，即便接入更多平台，仍难以解决单会话串行执行、上下文混乱和设备离线中断等问题。

Super-agent 的解法，是一套由 Router 和 Worker 组成的双层架构，可以理解为一个由 AI 组成的虚拟团队。Router 作为持续运行的全局协调节点，统一接收来自群聊、GitHub、邮件等不同平台的信息，判断任务如何分配并维护跨任务上下文；Worker 则拥有独立的上下文和工具能力，分别负责问题复现、代码审查、功能开发等具体工作，任务完成后向 Router 汇报结果。对用户而言，面对的始终是同一个 AI 助手；对系统而言，背后可能已有多个独立 Agent 同时工作。

从多年企业级 Agent 落地实践经验来看，这套架构中最具借鉴价值的是主动性设计。DeepSeek 引入 Trigger 事件机制，群聊消息、邮件、日程提醒、GitHub 评论、CI 测试结果都可以触发 Agent 行动，并通过两级过滤机制——先用程序规则快速排除无关消息，再交给大模型结合上下文判断——避免无效介入。更巧妙的是「投机执行」思想：在尚未确定结果是否被采用时，提前利用后台算力尝试，有价值的结果才提交给用户。例如内部用户群配置的「静默复现并修复」策略，团队成员还在讨论方案时，Super-agent 已在后台提交了修复 Pull Request。配合异步 ReAct Loop 与存算分离设计，耗时任务转入后台、执行循环放在云端、本地仅部署轻量 daemon，即使电脑离线，任务也能在重新上线后继续执行。

为验证架构效果，DeepSeek 进行了对比实验：模拟群聊与 GitHub CI 消息流，单次约 300 条消息中仅 20 条为真实工作请求，每种方案重复运行五次。结果显示，Super-agent 任务完成时间 p50 为 12.4 分钟、p95 为 15.7 分钟，而传统单会话方案 p95 达 29.5 分钟。差异主要来自任务调度——传统方案中模型是否真正分派任务取决于提示词与临场判断，中性提示下五次实验模型一次都没调用 Subagent，所有任务都在主会话中受新消息干扰。Super-agent 通过双层架构消除了这种不确定性。但效率提升有代价：维护多个独立会话使缓存读取 Token 高于单会话，取消事件直通机制后总缓存读取量增幅约 37%。此外，长期记忆恢复、提示词注入与服务端入侵的安全风险、以及大规模并行任务下的人工审批界面，都是规模化应用前必须解决的问题。

DeepSeek 团队坦言，他们并未提出全新理论，而是将任务调度、存算分离、事件驱动等经典计算机系统思想应用到 Agent 架构中。当 AI 完成单个任务越来越少需要人工干预时，人类能同时管理多少个 AI 正成为新命题。未来，人类将更多负责确定目标、做出决策和验收成果，AI 则自主发现问题、协调任务并完成执行——一位真正的数字同事，正在到来。