DeepSeek 深夜开源「Agent 操作系统」：模型不再是胜负手，调度才是

原创

asaotomo
asaotomo

Hx0极客圈

2026年11月1日 10:12
安徽

去阅读

前沿 · Agent 架构

DeepSeek 深夜开源
Agent「操作系统」

从 Harness 0.2.2 到 Super-agent，竞争开始转向系统层

10 月 31 日晚，DeepSeek Harness 团队把 Super-agent 原型挂上 GitHub；几天前，0.2.2-alpha.2 刚刚更新。它想解决的不是「模型会不会写代码」，而是「一个人到底能同时盯几个 Agent」。

· 情报等级：高　· 来源：官方页面 / GitHub / 公开报道　· 2026-11-01

过去两周，DeepSeek Harness 的更新节奏明显加快：10 月 28 日连发 0.2.1-rc.4 与 0.2.2-alpha.2，10 月 30 日更新 0.2.1-rc.5，10 月 31 日晚又公开了《Super-agent 设计探索》与配套原型。把这些动作连起来看，方向很清楚——DeepSeek 不再只想做一个更强的编程 Agent，而是在给 Agent 造一层常驻的系统底座。

01先厘清：Harness 不是模型

Harness 原意是「挽具」。套在模型外面的这层工程外壳，负责读文件、调工具、管上下文、执行命令，也负责在模型跑偏时把它拉回来。DeepSeek 官方给过一个很直白的公式：Model + Harness = Agent。

图1 | Agent 的三段式——模型提供推理，Harness 提供执行与上下文。（图源：本文制图）

DeepSeek Harness（简称 DSH）在 8 月 14 日随 DeepSeek-V4 Pro 一起放出开发者预览版，采用 MIT 协议开源，核心是 Cordis 的「一切皆插件」架构。仓库里有超过 230 个 workspace 成员，文件系统、终端、浏览器、技能、子智能体、工作流、会话持久化、凭据管理，几乎每项能力都有自己的包。官方也明确提醒：开发者预览期会持续快速迭代，会有破坏兼容性的变更。

它可以作为 macOS 桌面应用运行，也可以一条命令拉起 Web UI：

npx @deepseek-ai/dsh web

所以它不是一个新模型，也不是单纯的 API 客户端。更准确地说，它是一套用来组装、运行和扩展 Agent 的框架。这也解释了为什么同一个模型，放进不同的 Agent 产品里，完成同一件事的体验会差很多：差距往往不在参数，而在外面那层壳。

020.2.2 的真正信号：从「写代码」到「派活」

如果只看更新日志，0.2.2-alpha.2 像一次常规迭代：新增插件、修修补补、升级依赖。但把几项能力放在一起，意图就不太一样了。

图2 | Super-agent 双层架构——Router 管连续与分派，Worker 管隔离执行。（图源：本文制图）

最值得玩味的是「外部 CLI 委派」。过去，开发者要在 Codex、Claude Code、DSH 之间来回切窗口，复制上下文、分配任务、再人工汇总。现在 DSH 想站到更上层：主 Agent 拆需求，把实现派给 Codex CLI，把审查派给 Claude CLI，最后自己收结果。

这件事的象征意义大于当下实用性。它意味着 DSH 的假想敌不是某一个编程助手，而是「多个 Agent 各干各的、人负责当交换机」这种工作方式。只不过目前它还只是实验性插件，上下文怎么共享、权限怎么管、复杂任务怎么协作，都还没有答案。

升级要谨慎：0.2.2-alpha.2 仍是 Alpha，Node.js 最低版本抬到 24.9，旧 tools.mode 配置要迁移，SSH 协议从 v2 升到 v3，Session 投影与模型路由接口也有变化。生产环境不建议直接替换。

03Super-agent：一个 Agent，为什么要拆成两层

10 月 31 日晚公开的 Super-agent，把问题往前推了一步：如果模型已经能独立完成单个任务，限制生产力的是什么？DeepSeek Harness 团队的判断是——人的注意力。

现在的 Agent 大多以单个 Session 为单位。开三个任务，就要开三个窗口；人要在不同上下文之间来回切换，记住哪个任务进行到哪一步。任务一多，人反而成了系统的瓶颈。Super-agent 想做的，是一个跨会话保持上下文、并行推进多任务、还能主动找活干的连续实体。

单个 ReAct Loop 无法同时满足这四个特征。于是团队把系统拆成五块：双层架构、事件驱动、异步多信道交互、存算分离、外部 Watchdog。听起来像分布式系统，实际也确实是在用经典计算机系统思想，重做 Agent 的运行时。

Router 层像总调度台，维护全局连续性，但不执行具体任务，甚至可以不配 Bash 工具；Worker 层各自隔离上下文、挂完整工具，专注把一件事做完。Worker 不直接对人说话，推理过程和工具调用都收在里面，只把状态和结论汇报给 Router，由 Router 统一对外回复。

这和常见的 Agent Team 不完全一样。Agent Team 通常是在一个复杂任务内部拆步骤、分角色，Team Lead 要深入理解细节；Super-agent 的 Router 只管任务与任务之间的高层关联和分派，不介入单任务内部。团队还发现，Router 的工作往往没有想象中复杂，用较轻量的模型就能兼顾速度与效果。

04主动性是怎么做出来的：事件、过滤、直通、提前行动

Super-agent 的输入不再主要是人敲进对话框的提示词，而是环境里的半结构化事件：群聊消息、邮件、日程提醒、代码审查评论、CI 结果。团队把这些事件叫 Trigger。

1先过滤，再叫模型——程序层用白名单、来源、群组范围做 Fast Path，快速筛掉大部分噪音；剩下的候选事件再交给 LLM 做语义判断，作为 Slow Path。

2已订阅的事件，不再绕 Router——同一个 PR、IM 话题或邮件串构成一条 Thread。Worker 创建后直接订阅 Thread，后续事件由程序直通 Worker；只有新任务才回到 Router 分派。

3上下文当 Cache 管——常用信息 Inline 进窗口，长内容 Spill 到窗口外只留摘要和入口；需要时顺着对象 ID 逐跳召回，形成「链式召回」。

4投机执行，先干再交付——收到会议邀约，先在后台查日程、找资料、起草回复；群里有人报 Bug，先在后台复现和修，确认有价值才把结果拿出来，否则保持安静。

文章里有一句话很值得记下来：「浪费上下文窗口，就是浪费模型的智能。」当输入从几百字提示词变成持续不断的环境事件，上下文怎么组织，已经不只是 Prompt 技巧，而是系统设计。

团队透露，内部已有 Super-agent 实例在 IM 与 GitHub 之间连续推进任务：同一个问题先出现在群聊，随后在 PR 评论里继续；它也会持续关注公共群聊，在没人 @ 的情况下识别缺陷并提交修复 PR。

05持久在线：把「脑、手、记忆」拆开

今天的本地 Agent，大多把三样东西绑在同一台机器上：推进 Agent Loop 的计算、需要持久保存的会话状态、代码仓库与本地工具链。设备一休眠，Agent 就停；换一台电脑，环境就断。

Super-agent 借用了「存算分离」：先把计算与会话状态拆开，让 Agent 摆脱单机生命周期；再把云端 Agent Loop 与重状态执行环境拆开，让真实工作环境留在原地，按需接入。团队把这称为类 Anthropic 的「脑手分离」，但场景不同——Anthropic 描述的是托管服务和沙箱，DSH 首先要接的是用户日常使用、可能间歇在线的个人电脑，上面还有未提交修改和本地凭据。

这带来一个很实际的能力：Agent 不再受限于一台机器，可以在不同执行设备之间切换；某台个人设备重新上线后，云端 Agent 还能自动触发，把需要在这台设备上完成的任务做完。

长期在线还需要「自愈」。团队在主系统之外放了一个独立的 Watchdog Session，用定时消息驱动。它不只盯进程存活和接口报错，还会让模型判断各个 Worker 是否有实质进展、方向是否跑偏。发现异常就介入修复，偶发故障则持续复查。因为 Watchdog 本身也是一个有完整工具能力的 Agent，维护者可以用自然语言问它「为什么卡住」，也可以让它在线改提示词、调触发规则。

06实验数字：更快更稳，但拿 token 换

团队用群聊和 GitHub CI 消息流做了消融实验：单次约 300 条消息，其中约 20 条工作请求，编码工作用只耗时工具代替，每种方案跑 5 次。结果如下：

这组数字说明两件事。第一，双层架构在中高并发下确实更快、更稳，尤其是长尾任务，不再被新消息不断打断。第二，稳定是买来的：多会话维护带来更高的读缓存 token；订阅直通不提升速度，但能为 Router 省下约 37% 的 token 与推理开销。

Router 批处理则解释了「越堵越便宜」：事件积压时，多条 Trigger 会合并进下一次模型调用，单次请求耗时从 2.5 秒增至 3.9 秒，远慢于 batch 的增长，于是单个决定分摊的推理时间反而从 6.4 秒降到 1.6 秒。当然，上限取决于上下文长度，以及模型一轮能准确处理多少条 Trigger。

07冷静看：还有四道坎

文章没有回避问题，反而把四个开放问题列得很清楚：双层架构如何扩展，单 Router 承载超限后何时切分、粒度多细、Worker 之间何时直接通信；脱离 Session 后如何协作，聊天窗口未必是最终形态；组织扩大后如何划分上下文边界，多个隔离实例之间怎么做 A2A；以及最现实的安全与隐私——云端 Agent 接入端侧凭据，既有被入侵风险，也有提示词注入风险。

最后一条尤其关键。Agent 越自主、权限越大，一次误判的代价就越高。团队提出的方向是让 Agent「不接触凭据本身也能使用凭据」，但在真正落地之前，这仍是所有常驻型 Agent 的共同难题。

需要明确边界：Super-agent 目前是研究原型，不是 DeepSeek 正式产品；实验基于合成负载与简化环境，只跑 5 次，结论只能作初步参考。部分设计已在 dsh-superagent-prototype 实现，但原型不等于可上生产的系统。

08对开发者和团队，意味着什么

如果你只是偶尔让 AI 改几行代码，DSH 这轮更新还不会立刻改变你的工作流。但如果你已经在同时跑多个 Agent，或者团队里有人负责「盯 Agent」，它值得提前研究。

第一，把 DSH 当编排层试，而不是当又一个聊天工具。先用 npx @deepseek-ai/dsh web 跑起来，选一个真实的小项目，观察它怎么拆任务、怎么调工具、什么时候需要你介入。外部 CLI 委派仍是实验性的，先别把关键流程压上去。

第二，评估指标要换。不要只看「模型跑分」和「代码能不能过测试」，还要看任务完成时间的 p95、人工介入次数、token 成本、异常恢复时间。Super-agent 的实验已经说明，系统层的调度能把 p95 拉下来，但代价是更高的 token 消耗。这笔账，团队迟早要算。

第三，关注「人机接口」而不只是「模型接口」。当 Agent 常驻在 IM、GitHub、邮件里，交互设计就变成了产品体验的一部分：什么时候该说话、说多长、什么时候该安静、用户怎么中途接管。这些细节，可能比多接一个模型更能决定它好不好用。

09结语：竞争不在聊天框里

从 8 月的开发者预览，到 10 月的 0.2.2，再到 10 月 31 日的 Super-agent，DeepSeek Harness 的路线越来越清楚：它不想只做一个「更会写代码的 Agent」，而是想把会话调度、上下文组织、异常恢复、环境接入这些脏活累活，收进一层常驻的系统底座。

这也解释了为什么它要把 Router 和 Worker 拆开、把计算和状态拆开、把 Watchdog 放到主系统之外——这些设计并不新奇，甚至很「传统」。但恰恰是这些传统工程思想，决定了 Agent 能不能从演示走向日常。

模型决定 Agent 一次能想多深，Harness 决定它能不能一直想、同时想几件事、出错了能不能自己爬起来。DeepSeek 这次押注的，是后者。

至于 Super-agent 会不会成为下一代 Agent 的标准形态，现在下结论还太早。但可以肯定的是：Agent 的下一场竞争，可能不在聊天框里，而在调度器、上下文和故障恢复里。

10参考资料

1. DeepSeek Harness 官方页面
https://www.deepseek.com/en/harness/

2. DeepSeek Harness GitHub 仓库
https://github.com/deepseek-ai/deepseek-harness

3. Super-agent 原型代码
https://github.com/deepseek-ai/dsh-superagent-prototype

4. 0.2.2-alpha.2 发布说明
https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.2.2-alpha.2

5. 智东西：DeepSeek 又开源了，公布 Super agent 架构
https://tech.sina.com.cn/csj/2026-11-01/doc-inixepty4335109.shtml

6. 机器之心：DeepSeek Harness 开源报道
https://www.36kr.com/p/3937964598590855

说明：本文基于 2026 年 11 月 1 日前公开的官方页面、GitHub 发布记录与公开报道整理。Super-agent 仍为研究原型，相关实验数据来自团队自述，未经过第三方复现。