11 月 1 日，DeepSeek 公开了面向个人 Agent 场景的 Super-agent 原型架构，并在 GitHub 开源相关原型代码。与其说这是一次单点技术发布，不如说它把 Agent 系统的 " 底座问题 " 摆到了台前：当模型单任务能力逐步增强，如何让智能体跨会话、跨平台持续在线，并行处理多项任务，并在无人下指令时主动发现和推进工作。DeepSeek 披露的初步实测显示，在模拟多任务环境中，Super-agent 任务完成时间中位数为 12.4 分钟，95 分位为 15.7 分钟；作为对照，传统单 Session 方案在中性提示下 95 分位达到 29.5 分钟。对通信行业而言，这组数据释放的信号不只是 Agent 更 " 能干 "，而是 Agent 运行方式开始从 " 一次问答 " 转向 " 常驻系统 "，算力调度、网络服务和开源生态都将被重新定义。

一、Router+Worker：Agent 底座被拆成 " 调度层 " 和 " 执行层 "

从公开信息看，Super-agent 的核心设计并不追求把一切能力塞进一个会话，而是把智能体系统拆成两层：上层 Router 负责接收消息、分配任务、维护全局上下文，下层 Worker 负责具体执行，多个任务可以并行推进、互不干扰。这个架构的关键在于，用户面对的是同一个 Agent，底层多个会话由系统自行管理。对开发者而言，这意味着不必再手动记住每个会话进行到哪一步，也不必反复向 AI 交代前情。

更值得关注的是 " 订阅与直通 " 机制。某个 Worker 接手一条 GitHub PR 后，可以直接订阅后续评论；有人提出修改意见，消息直接交给该 Worker 处理，无需再经过 Router 层层转发。DeepSeek 的测试也说明，取消事件直通后，Router 决策次数增加约 30%，读取缓存 Token 增加约 37%。这说明直通不是锦上添花，而是影响系统成本结构的关键设计。

在工具调用层面，Super-agent 的变化是从 " 单次函数调用 " 走向 " 持续事件订阅 "。它要跨 IM 群聊、GitHub、邮件等平台工作，消息不再是孤立的指令，而是持续流入的事件流。投机执行则进一步强化了主动性：群里有人讨论一个 Bug，Agent 可以先行复现、查找原因，找到简单可行的修复方案再交给用户；没有有效结果则保持安静，避免打扰。同样的逻辑也可用于个人助手，比如收到会议邀约后提前检查日程冲突、整理资料、准备回复草稿。

模型协同方面，原文并未披露 Router、Worker 和 Watchdog 是否采用不同参数规模的模型，但分层本身为异构协同留出了空间。从工程逻辑看，调度层可以用较轻量的模型做意图判断和路由，执行层按任务调用更强模型，监督层持续做异常检测。这种按角色分配模型能力的思路，比单纯堆一个大模型更贴近生产系统。DeepSeek 还设计了两级事件过滤：先由程序规则筛除无关消息，再由大模型判断剩余事件是否需要行动，以减少不必要的 Token 消耗。异步 ReAct Loop 则让 Agent 在执行耗时任务时仍能响应新指令，该机制已在 DeepSeek Harness 中实现，但尚未默认开启，说明工程上仍在权衡并发收益与资源开销。

二、实测数据背后：Agent 评价指标从 " 答得对 " 转向 " 任务完成得稳 "

DeepSeek 的初步实验模拟了约 300 条消息、20 项工作请求的协作环境，对比 Super-agent 与传统单 Session 加 Subagent 方案，每种配置重复测试 5 次。结果显示，Super-agent 任务完成时间中位数为 12.4 分钟，95 分位为 15.7 分钟；传统单 Session 方案在中性提示下 95 分位达到 29.5 分钟。中位数反映典型任务效率，95 分位则更能说明尾延迟和稳定性。对生产系统而言，后者往往比平均表现更重要。

这组数据也提示，Agent 系统的评价指标正在变化。过去行业更关注单轮问答准确率、工具调用成功率；当 Agent 进入多任务、长周期运行场景后，任务完成时间、尾延迟、Token 成本、人工接管率、异常恢复能力会成为更关键的指标。DeepSeek 同时披露了效率提升带来的 Token 开销：取消直通机制后，Router 决策和缓存读取成本明显上升。这意味着 Agent 底座的竞争不只是 " 谁更聪明 "，而是 " 谁能在可接受成本下稳定完成任务 "。

三、算力调度新命题：从 " 按请求分配 " 到 " 按任务常驻 "

Super-agent 提出的四个特征——连续、高效、主动、持久——直接对应着算力需求形态的变化。传统大模型服务以请求为粒度，算力调度相对简单；常驻 Agent 则要维持会话状态、监听事件、并行执行任务，算力需求从 " 瞬时高峰 " 变成 " 长尾常驻加突发执行 "。Router 的持续决策、Watchdog 的巡检、Worker 的并行任务，都会产生不同粒度的算力消耗。

DeepSeek 采用计算、状态与执行环境分离的思路：计算逻辑可在云端运行，会话状态独立保存，本地设备保留原有工作环境；即便电脑暂时离线，云端 Agent 也能维持任务状态，等设备重新上线后继续执行。这实际上把 Agent 会话变成了可迁移、可恢复的运行时状态。对算力网络而言，调度对象不再只是 GPU 利用率，还包括状态存储、缓存命中、任务优先级和异常恢复策略。投机执行会带来提前计算开销，两级事件过滤和直通机制则用于压低无效调用，系统需要在 " 提前做 " 和 " 少做无用功 " 之间找平衡。

这为通信行业提供了新的切入点。国内运营商近年在算力网络、智算中心和 MaaS 服务上持续投入，云网融合能力是其相对优势。Agent 常驻化之后，企业客户需要的不只是一块 GPU 或一次 API 调用，而是可托管、可审计、可计费的 Agent 运行环境。运营商有机会把边缘节点、云上状态存储、专网连接和运维体系组合起来，提供面向行业场景的 Agent 底座。挑战也很直接：计费方式可能从 Token 或时长，转向任务完成、并发数和 SLA 保障的混合模式。

四、网络服务新变量：事件总线、API 网关与安全隔离

Super-agent 跨 IM、GitHub、邮件等平台协作，本质上依赖持续的消息订阅和事件通知。订阅直通机制类似发布订阅：Worker 直接订阅自己关心的后续评论，减少 Router 转发。放到企业网络里，这要求消息总线、API 网关、长连接管理和事件通知具备更高可靠性。Agent 长期在线后，连接数、消息队列积压、跨平台回调时延都会成为影响任务完成时间的变量。

对通信企业而言，机会不只在 " 提供连接 "。企业 Agent 接入工作群、邮件、代码平台和内部系统后，网络服务需要为关键任务提供确定性时延和优先级保障；边缘节点可以承载部分事件过滤和轻量推理，减少云端往返；专网和云网融合方案则可为政企客户提供隔离的运行环境。安全层面，Agent 主动执行意味着权限必须最小化，工具调用需要审计，跨平台访问需要零信任隔离。Watchdog 可以监督程序故障、无效循环和目标偏离，但权限设计、数据边界和操作审计必须前置。

五、开源生态：底座开源降低门槛，生产级能力仍是分水岭

DeepSeek 此次开源的是 Super-agent 原型架构和相关代码，不是开箱即用的成熟商业产品。它的价值在于把 Agent 运行时的关键问题公开出来：如何做多会话编排，如何让工具调用变成持续订阅，如何分离计算与状态，如何用监督机制提升长期运行稳定性。对国内开源生态来说，这意味着竞争从模型层进一步延伸到 Agent 运行时层。开发者可以复现、验证和二次开发，云厂商、运营商和设备商也可以基于原型探索行业版本。

但原型到生产之间仍有距离。权限体系、审计日志、可观测性、成本治理、工具接口标准、状态存储一致性，都是企业部署绕不开的工程问题。通信行业可以发挥标准组织和产业协同优势，推动工具调用、事件订阅、状态管理等接口规范化，避免行业 Agent 平台重复造轮子。对中国通信产业而言，更现实的路径不是再做一个通用 Agent 框架，而是把开源底座与云网资源、边缘算力、政企场景和运维数据结合，形成可落地、可运营的行业能力。

DeepSeek 这次开源释放的信号很清楚：Agent 的竞争正在从 " 模型能不能做 " 转向 " 系统能不能持续做 "。当智能体开始常驻在线、并行执行、主动响应和异常自愈，算力调度要从请求粒度走向任务粒度，网络服务要从连接供给走向事件与运行时支撑，开源生态也要从模型开放走向底座共建。对通信行业来说，这不是旁观者的话题，而是算网融合下一阶段必须回答的问题。