如果你最近高频使用 Claude Code、Cursor 或各类 Coding Agent，大概率经历过这样一种微妙的转变：

最开始只开一个窗口让 AI 写功能时，你会觉得自己像个潇洒的指挥官；可一旦手头的活变多，你试着同时打开四五个终端窗口——窗口 A 修线上 Bug、窗口 B 写单元测试、窗口 C 重构接口、窗口 D 查文档——画风就会突然失控：
窗口 A 卡在权限确认上等你敲回车，窗口 B 跑偏了方向需要你重新贴报错，窗口 C 改坏了公共模块、跟窗口 A 撞了车。你像个在火炉前同时颠五口锅的厨师，在不同黑框之间疯狂切换，不到半小时就大脑发胀，彻底忘了哪个窗口改到了哪一步。

当 AI 越来越能干，制约生产力的往往不再是模型不够聪明，而是人类的注意力最先被切碎。

2026 年 10 月底，DeepSeek Harness 团队发布了技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，并同步在 GitHub 上开源了研究原型 dsh-superagent-prototype 与底层运行时 deepseek-harness（简称 dsh）。

在这套设计里，DeepSeek 点破了一个很多工程团队正在撞上的真相：

单任务的上限取决于模型能力，而多任务的上限取决于人类的注意力。

---

一、为什么传统单会话 Agent 走到了瓶颈？

目前绝大多数 AI 编程工具或通用智能体，基本单元都是一个单会话（Single Session）。它在单点任务上足够好用，但一旦进入团队协作或多任务并行场景，就会撞上三道死胡同：

1. 人类注意力上限（3～5 个会话定律）：人类的工作记忆极其有限，同时盯住 3 到 5 个活跃的 Agent 会话就是生理极限。会话一多，人就成了整个系统的“人肉路由器”和最大瓶颈。
2. “一锅炖”与“散装化”的两难：
   • 如果把所有任务全塞进同一个大 Session：虽然上下文连贯，但单线程 ReAct 循环只能串行干活，吞吐量极低；而且修 Bug A 的报错日志和写功能 B 的代码混在一起，极易引发严重的上下文污染。
   • 如果为每个任务手动开新 Session：并发虽然上去了，但会话之间彼此失忆、各自为战，连改了同一份文件都互相不知道。
3. 被动等待与脆弱的生命周期：传统 Agent 是典型的“算盘珠子”——你戳一下，它动一下。它不会主动盯着 GitHub 新提的 Issue 或群聊里的报错，而且一旦终端关闭或陷入死循环，任务就悄无声息地断了。

要打破这个僵局，不能靠人去练“八爪鱼操作”，而是要在系统层把 Agent 从 “单兵临时工” 升级成一套 连续（Continuous）、高效（Efficient）、主动（Proactive）、持久（Persistent） 的自治系统。

DeepSeek 给出的解法非常经典：向成熟的计算机操作系统（OS）和现代软件工程团队借智慧。

---

二、核心调度：Router 与 Worker 的双层解耦架构

想象一下，一家成熟的软件公司是怎么避免老板被细节累死的？

答案很简单：老板不会直接冲进工位去盯每个程序员敲每一行代码，而是设立一位“项目主管（Router）”，由主管对接需求、拆解工单，再分派给后排独立工位上的“专项工程师（Worker）”。

DeepSeek Super-Agent 最核心的骨架，正是这套 Router-Worker 双层解耦架构：

1. Router（常驻路由层：绝不下场写代码的“项目主管”）

Router 是整个系统中唯一持续在线、拥有全局视野的协调节点：

• 统一对外窗口：无论是 GitHub 上的评论、飞书群里的消息，还是管理面板的指令，所有人类交互都只和 Router 对话。
• 严守职责边界：在 dsh-superagent-prototype 的系统提示词设计中，有一条铁律——Router 自己绝不亲自执行繁重的编码和调试任务。它只负责理解意图、盘点全局状态、创建结构化的内部工单（Ticket），然后把脏活累活派发出去。
• 轻量而敏捷：正因为不被几千行的编译报错和代码 diff 塞满上下文，Router 始终保持头脑清醒，能够随时响应人类的追问或调整优先级。

2. Worker（隔离执行层：独立工位上的“专项打工人”）

每当 Router 签发一张工单（Ticket），系统就会在后台动态拉起一个对应的 Worker 会话：

• 上下文与目录双隔离：每个 Worker 都在自己专属的工作目录和独立 Session 中运行，只关心手头这一个 Ticket（比如“修复 #42 号 Issue 的空指针异常”）。
• 用完即走，只交结果：Worker 在自己的沙箱里历经多少次编译失败、查阅了多少文件、跑了多少遍测试，这些嘈杂的中间过程全部留在它自己的隔离区里。等任务彻底完成、测试通过并提好 Pull Request 后，Worker 只向 Router 交回一份干净的结果摘要，随后功成身退。

Router 像前台笃定的项目主管，挡住杂音、派发工单；Worker 在各自独立的隔间里专心攻关，最后把干净的成品交回人类手中。

从“人盯过程”到“人审结果”
引入 Router-Worker 分层后，人类不再需要同时盯 5 个黑框里的中间输出，只需要对接 1 个 Router，在工单完成时点开最终的 PR 做一次 Code Review 即可。

---

三、从“被动等指令”到“主动找活干”：两阶段过滤与最小打扰

有了项目主管和执行团队，下一个问题是：怎样让这套系统像真正的团队成员一样“眼里有活”，同时又不会变成令人抓狂的“刷屏噪音制造机”？

在 dsh-superagent-prototype 的设计哲学文档（000-philosophy.md）中，开篇第一句话就写着：

“Take as little human attention as possible, and give as much value as possible.”
（消耗尽可能少的人类注意力，交付尽可能多的实际价值。）

1. 两阶段事件过滤（Two-Stage Filtering）

如果把 GitHub 仓库的所有 Webhook 事件和飞书群里的每一句聊天都直接喂给大模型，不仅 Token 账单会瞬间爆炸，模型也会被大量无关闲聊干扰。因此系统将过滤拆成了两步：

• 第一阶段：程序层快速筛选（代码逻辑）：用确定性的程序规则过滤掉明显无关的系统事件，并严格校验发送者是否在团队受信任的授权白名单（Authorization）内。绝大部分噪音在这一步就被零成本挡在了门外。
• 第二阶段：语义层深度判断（模型识别）：只有通过初筛的半结构化事件，才会交由模型判断“这是否是一个需要推进的研发需求或 Bug 汇报”。

2. Observe（观察模式）与 Proactive（主动模式）

当团队群聊或 GitHub Issue 里有人反馈了一个明确的 Bug，哪怕没有人特意 @ 智能体，处于 Proactive（主动模式） 下的 Super-Agent 也能识别出这个机会，悄悄在后台拉分支、尝试复现、编写修复补丁并跑通测试。

而且它严守**“闭嘴原则”：在后台折腾的过程中绝不发消息刷屏，只有当它真正拿出了可直接合并的 PR 成果**，或者遇到了必须人类拍板的卡点时，才会开口说话。

考虑到安全性，开源原型默认开启的是 Observe（观察模式）：在这个模式下，它会像一个见习主管一样，把“我发现了什么问题、我打算怎么派单修复”完整记录在面板日志里供人类检阅，但不会贸然修改线上仓库。

---

四、上下文工程：把操作系统的“内存换页”搬进大模型

思考一个工程难题：Router 作为 7×24 小时常驻的全局主管，随着团队日积月累处理几百个 Issue 和上千条讨论，它的上下文窗口（Context Window）岂不是迟早会被撑爆？

如果简单粗暴地按时间截断旧消息，Router 就会变成“金鱼脑”，忘了三天前刚修过的关联 Bug；如果把所有历史工单全塞进 Prompt，不仅推理越来越慢，模型还会在海量无关文本中迷失重点。

DeepSeek 在文章中给出了一句极具洞察力的总结：“浪费上下文窗口，就是浪费模型的智能。”

为此，团队借鉴了操作系统中经典的 Page Cache（页缓存）与虚拟内存换页机制，为 Router 设计了 Inline & Spill（内联与溢出） 与 Chain of Recall（链式召回） 两大机制。

我们可以把 Router 的工作环境想象成一张办公桌加上身后的整排档案柜：

对比维度	Inline（内联 = 办公桌上的便签）	Spill（溢出 = 身后的档案柜）
类比操作系统	CPU 高速缓存 / 常驻物理内存 (RAM)	磁盘交换空间 (Swap / Disk)
存放内容	当前活跃工单摘要、近期高频讨论串、核心全局状态	历史工单详情、长篇文档、Worker 完整执行日志
上下文表现	直接展开在模型当前的 Context Window 中	移出当前上下文，仅在桌面留下一张带 ID 的索引卡片（指针+摘要）
访问成本	零延迟，每次推理直接可见	按需读取，平时不占分毫 Token 预算

顺着红线找档案：Chain of Recall（链式召回）

只把历史细节塞进档案柜还不够，万一三天后有人在一个新 PR 下追问：“上次那个登录超时的问题，最后改了哪个配置？” Router 该怎么精准找回记忆？

这就是 Chain of Recall（链式召回） 发挥作用的地方。系统中的每一个核心领域对象之间，都维护着严格的引用链条：

当 Router 收到追问时，它不需要把过去一周的所有聊天记录全翻出来，而是像侦探顺着线索板上的红线一样：从当前评论（Trigger）定位到讨论串（Thread），顺着讨论串上的索引卡片找到历史工单（Ticket），再按需从档案柜里抽出那一次 Worker Session 的变更记录。

办公桌上只放最关键的活跃便签（Inline），厚重的历史卷宗整齐收进档案柜（Spill）；需要追根溯源时，再顺着索引卡片的链条精准调取（Chain of Recall）。

通过这套组合拳，Router 用极小的常驻 Token 开销，换取了近乎无限的跨周期全局记忆。

---

五、高可用保障：存算分离与 Watchdog（看门狗自愈）

当一个 Agent 系统开始在后台运行几十分钟甚至数小时的长周期任务时，工程上的稳定性挑战就会陡然上升：万一某个 Worker 进程意外崩溃怎么办？万一模型在某个报错上钻了牛角尖、陷入死循环怎么办？

DeepSeek 同样用非常正统的系统工程手段给出了保障：

1. 存算分离（State & Compute Separation）

在传统单会话工具里，“任务做到哪一步”是和“当前活跃的模型会话进程”死死绑在一起的，终端一关，前功尽弃。

而在 Super-Agent 架构中，状态（State）与计算（Compute）是彻底解耦的：

• 所有的任务目标、拆解进度、关联分支和阶段性结论，都持久化保存在独立的工单与状态存储层；
• Worker 进程本身则是无状态或轻状态的纯计算单元。就算某个 Worker 因为网络抖动或机器重启挂掉了，任务图纸依然完好无损，系统只需重新拉起一个新的 Worker 接过图纸就能继续往下干。

2. Watchdog（看门狗监控闭环）

做过嵌入式或操作系统的同学对 Watchdog（看门狗） 一定不陌生：它是一个独立于主业务流程之外的巡检机制，专门盯着系统有没有“卡死”。

在 Super-Agent 中，Watchdog 持续在后台巡视所有活跃会话与长耗时命令：

• 长命令后台化与超时保护：当 Worker 执行耗时较长的编译或测试脚本时，达到阈值会自动转为后台受控任务，防止阻塞主消息循环；
• 异常自愈与升级汇报：一旦发现某个 Worker 长时间停滞、原地打转重复相同的失败操作，Watchdog 会及时介入中断、尝试恢复，或者通过 Router 向人类发出结构化的求助信号，绝不让故障在后台静默腐烂。

图纸与工位分离保存（存算分离），再加上尽职巡逻的看门狗（Watchdog）：即使某个执行单元意外卡壳，也能迅速重启接力，确保长任务稳健交付。

---

六、走进开源项目：dsh-superagent-prototype 与 dsh

理解了上面的四大架构支柱，再去翻看 DeepSeek 开源的两个仓库，你会发现每一份代码和文档都能严丝合缝地对上号。

1. 底层基座：万物皆插件的 deepseek-harness (dsh)

deepseek-ai/deepseek-harness 是 DeepSeek 打造的模块化 Agent 运行时底座：

• “Everything is a Plugin”：基于 Cordis 框架构建，将模型接入、工具调用、Skills 技能、会话管理、文件系统、沙箱乃至 Web UI 全部抽象为可热插拔的插件，支持灵活组合且不留脏状态。
• 不绑定单一模型：虽然出自 DeepSeek 团队，但 dsh 完全是模型无关（Model-Agnostic）的，支持接入 DeepSeek、OpenAI、Anthropic Claude 等任意兼容接口。

2. 上层原型：dsh-superagent-prototype 的领域划分

deepseek-ai/dsh-superagent-prototype 则是跑在 dsh 之上的 Super-Agent 插件包。它的 docs/ 目录堪称一份极佳的 Agent 系统设计教科书：

核心文档 / 模块	对应的架构职责
docs/000-philosophy.md	确立“最小化消耗人类注意力”的第一性原理与行为边界
docs/001-domain.md	定义 Trigger（触发器）、Ticket（工单）、Router 与 Worker 核心领域模型
docs/002-authorization.md	严格区分“谁有资格提要求”与权限白名单边界
docs/003-execution.md	规定 Worker 独立目录隔离与长耗时命令的异步调度机制
docs/004-prompts.md	通过 Prompt 约束强制实现 Router 与 Worker 的职责隔离
docs/005-panel.md	提供本地 Web 管控面板，集中展示需人工审批的决策项
docs/006-deployment.md	阐述宿主机权限风险与生产环境隔离部署规范

3. 极具极客感的“用 Agent 安装 Agent”体验

如果你想在本地动手把玩一下这套系统（需准备 Node.js >=22.19.0 与 pnpm），可以先一行命令体验底层的 dsh Web 面板：

npx @deepseek-ai/dsh web

而在部署 dsh-superagent-prototype 时，官方没有写几百行的复杂配置手册，而是采用了一种非常符合 AI Native 时代的交互方式——仓库根目录放了一份结构化的 SETUP.md，你只需要把仓库克隆下来，然后对你的 Coding Agent 说一句话：

Read SETUP.md in this repository and set up dsh-superagent with me.

你的 Coding Agent 就会自动读取安装指南，每次只问你一个简短的配置问题（例如模型 API Key、要监听的 GitHub 仓库、授权用户列表），生成完整执行计划，并帮你把整套服务跑起来。

提醒
官方明确标注 dsh-superagent-prototype 目前是用于验证技术路线的研究原型（Research Prototype），Worker 默认使用当前操作系统用户的权限执行命令。若要开启自动修改代码的模式，请务必将其部署在独立的 Docker 容器、虚拟机或受限专用账户中。

---

七、总结：一张图收起 Super-Agent 的心智地图

回顾全文，DeepSeek Super-Agent 最有价值的地方，在于它跳出了“怎么写一段更花哨的 Prompt”的局部优化，用计算机系统工程的视角回答了“如何让 AI 真正融入研发团队”。

最后，我们用一张图把这套心智模型完整串联起来：

当大模型本身的单点推理能力越来越强大，下半场的胜负手正在转向 Harness（运行时底座）与系统架构。把调度交给 Router，把执行交给 Worker，把记忆交给分层缓存，把人类宝贵的注意力留给真正的创造与决策——这或许就是下一代自主 Agent 系统最清晰的演进方向。