DeepSeek Super-agent开源：云端编程智能体控制权归谁？

2026 年 10 月 31 日晚，DeepSeek Harness 团队发布技术长文《Super-agent 设计探索：迈向更自主的 Agent 系统》，同步在 GitHub 开源了研究原型 dsh-superagent，MIT 许可证，版本 0.1.0。这件事的信息量不在于 “DeepSeek 又开源了一个 Agent”，而在于它选择了一条与 Claude Code、GitHub Copilot 云端智能体、Devin 都不同的路径：把调度层、状态存储和模型选择留在使用者自己手里，而不是封装进供应商的托管环境。

一、云端编程智能体是什么，以及它为什么在此时出现

这一类别有一个相对清晰的三段式定义：触发不需要打开编辑器，任务可以来自 Issue、聊天中的 @提及、API 调用或 CLI 移交；执行不在本地设备上，智能体克隆仓库、安装依赖、在沙箱或远程工作区中运行；输出是一个分支、一组差异或草稿 PR，供人审核后决定是否合并。它与本地 IDE 智能体的区别不在能力高低，而在“人可以离开”：本地智能体在你注视下操作，云端智能体在你合上电脑后继续运行，回来时交付可审查的结果。

这一形态在 2026 年集中出现，背后是三个条件的叠加。模型在长时间工具调用流程中的稳定性提升，使 “无人监督运行” 从演示走向可用；沙箱和预配置环境的成本下降，让每个任务拥有独立执行空间变得经济；拉取请求成为智能体与审核者之间的默认接口，团队不需要另建一套审核流程。DeepSeek 设计文章给出的解释更直接：单项任务的上限受模型能力约束，但一个人同时跟进多个任务的产能受注意力约束 —— 它观察到，一个人通常只能同时跟进 3 到 5 个活跃会话，再多就会退化为 “在一群 AI 之间当传话筒”。

二、托管阵营的现状：便利与边界的交换

目前主流的云端编程智能体几乎都以托管形态交付。Claude Code 云端会话在 Anthropic 管理的隔离 VM 中运行，默认限制网络访问，git 凭据留在沙箱之外，由代理代表会话完成身份验证；组织可以选择转到自托管环境，但此时隔离责任转移到组织一侧。GitHub Copilot 云端智能体运行在云端沙箱或 Actions 环境中，输出分支或 PR，其隔离边界由 GitHub 侧的基础设施承担。OpenAI Codex Cloud 使用按任务配置的云工作区，每任务环境可独立设定出口规则。Devin 的交互入口更偏向 Slack、Teams 和 Linear，返回草稿 PR，官方文档对 VM 架构和隔离保证的公开程度相对有限。

这些产品的共同逻辑是：以控制权换取便利。代码和有时包括凭据离开本地设备，隔离细节由供应商定义，“沙箱” 一词在不同产品中可能指向强化 VM，也可能指向一个网络可达范围较宽的容器。计费通常绑定订阅套餐而非可独立核算的运行时间，供应商锁定在多仓库支持、企业控制和迁移成本上表现为不同形态的摩擦。这不是产品缺陷，而是托管模式的固有结构：把运维和隔离外包出去，就必须接受外包方设定的边界。

三、Super-agent 的不同选择：调度层自持，代价自担

DeepSeek Super-agent 最值得拆解的设计是 Router–Worker 双层架构。Router 是长期运行的协调节点，负责接收外部事件、判断任务归属、维护全局上下文，并把具体工作分派给 Worker；Worker 在独立会话和独立目录中执行，彼此上下文隔离，完成后向 Router 汇报，由 Router 统一对外回复。Worker 内部仍可调用子 Agent 或组织 Agent Team，但对 Router 保持透明。

一个容易被忽略但很有信息量的细节是两层模型的配置差异。官方设计文章指出，Router 层的推理负担较轻，使用较轻量的模型往往就能兼顾速度与效果；Worker 承担实际代码修改、测试和工具调用，通常需要配置能力最强的模型。这意味着 Super-agent 在架构层面预设了模型异构：调度和执行的模型选择可以分离，而不是由一个模型同时承担两种角色。

事件驱动是第二个关键机制。系统监听 GitHub 仓库（原型阶段不支持 GitHub Enterprise Server），可选接入飞书。外部消息先经过 Fast Path 的确定性规则过滤 —— 来源、用户、群组、事件类型和授权范围 —— 只有需要通过语义判断的候选事件才进入 Slow Path 由模型处理。Proactive 任务默认以 observe 模式运行：记录智能体 “原本会接受” 的任务，但不实际执行；切换到 auto 后，也只有满足启用规则的事件才能触发自动工单。主动性在这里不是模型自由裁量，而是被确定性授权规则约束的行为。

上下文管理采用 Inline & Spill 分层策略：当前任务摘要、相关 Thread 和近期反馈进入 Inline 上下文；完整历史和低频信息留在外部存储，Context 中只保留摘要和引用标识。Chain of Recall 则通过 Trigger、Thread、Ticket、Session 之间的关联关系，按需恢复历史上下文，而不是把全部历史塞进窗口。这种设计把上下文窗口当作容量有限的高速缓存来管理，而不是无限增长的日志。

四、性能数据的真实位置：合成负载下的调度效率

DeepSeek 公布的实验数据需要放在正确的参照系中阅读。测试使用模拟的群聊和 GitHub CI 消息流，每次运行约 300 条消息、约 20 个工作请求，每种配置运行五次，使用模拟工具而非真实代码质量评估。

在这个设定下，Super-agent 的任务完成时间 P50 为 12.4 分钟，P95 为 15.7 分钟；采用中性提示词的单会话加子 Agent 基线，P95 为 29.5 分钟，且五轮测试中没有一次主动调用子 Agent。移除 Worker 订阅直通机制后，Router 决策量增加约 30%，缓存读取 Token 从 2323 万升至 3177 万；Router 批处理将单个决策分摊的推理时间从 6.4 秒降至 1.6 秒。

这组数字证明的是系统层接管会话调度在模拟环境下的可行性，而不是 Super-agent 在真实软件项目中的代码质量或长期稳定性。它同时揭示了一个明确的成本结构：更快、更稳的调度是以更多 Token 消耗换来的。官方对此没有回避，原型本身也被标注为研究代码，并非生产级产品。

五、自持的代价：没有默认沙箱

Super-agent 的部署形态与托管产品形成对照。Router 和 Worker 预设以操作员的 OS 用户身份运行，使用 dangerous-access；账号封装程序选择智能体的凭据，但不隔离进程。部署指南建议使用一个专用 OS 账号，只存放智能体所需的凭据，并配置独立的 GitHub 身份。状态存储在 stateDir 下的 SQLite 数据库中，原型要求 Node.js 22.19 或 24 以上、Git 2.32 以上、Python 3.8 以上、tmux 以及 GitHub CLI 2.48 以上。

这套设计把隔离责任完全转移给了部署者。托管产品中由供应商承担的沙箱边界、网络策略和凭据隔离，在这里需要使用者自己构建。这是控制权自持的直接代价，也是 “研究原型” 标签的实质含义：它适合愿意承担运维和安全配置的技术团队，不适合期待开箱即用隔离的使用者。

六、多模型环境下的接入层问题

Super-agent 本身不硬编码模型，它使用 Harness 配置文件中的默认模型，团队可以为 Router 和 Worker 分别指定不同的模型来源。当同一套工作流需要在 DeepSeek、Claude、Codex 等模型之间按任务类型切换时，接口协议、鉴权方式和参数结构的差异会从 “可管理” 变成 “需要专门维护一层适配”。把模型调用抽象到统一的接入层，可以让 Router 的模型选择和 Worker 的执行模型保持解耦，而不必在业务代码中分散处理各家 SDK 的差异。

在这一层上，星链 API 提供 OpenAI 兼容的统一入口，适合作为多模型路由的接入选项之一；但 Super-agent 原型本身的事件模型和工单生命周期仍然需要按照 DeepSeek Harness 的实际配置来部署，不能把通用接入层等同于对调度架构的替代。

七、选型的判断顺序

如果团队需要供应商管理的隔离、多仓库组织级支持、以及在 GitHub、Slack 或 Web 应用中直接触发任务的能力，托管云智能体仍然是更短路径的选择。如果代码不能离开自有基础设施、需要修改编排逻辑、或希望按角色拆分模型，Super-agent 代表了一条值得用专用机器和专用 OS 账号去验证的自托管路线。两条路线并不互斥：日常仓库使用托管智能体，数据边界敏感的仓库使用自托管原型，审核步骤在两种情况下相同。

真正需要记住的区分不在于 “开源还是闭源”，而在于谁承担调度层的运维责任、谁定义隔离边界、以及模型选择权握在谁手里。Super-agent 的发布把这三个问题摆到了台面上，但没有替任何人回答它们。