刚刚，DeepSeek重磅开源：Agent底座架构！ (2026)

本文转载自微信公众号「量子位」。原文发表于 2026 年 10 月 31 日，作者梦瑶，《刚刚，DeepSeek 重磅开源：Agent 底座架构！》。

10 月 31 日晚上，DeepSeek 一次放出了两样东西。1

一样是一篇文章，《Super-agent 设计探索：迈向更自主的 Agent 系统》，署名 DeepSeek Harness 团队，作者 Yujia Qiao。1

另一样是一个 GitHub 仓库 dsh-superagent-prototype，采用 MIT 许可。2

到 11 月 1 日上午，这个仓库收到 2.3k 星标、194 次 fork，提交记录只有一条。2

量子位这篇报道把两件事合在一起写，标题落在「开源」上。读之前值得分清一件事：文章讲的是完整设计，仓库给的是其中一部分的实现。

开源出来的是一段原型

仓库的 README 第一段就把定位写清楚了。3

四句话，依次是：

这是供参考的研究原型，并非 DeepSeek 官方产品。
代码来自团队的日常工作，其中大量工程由 coding agent 完成。
为公开发布做过改写，与内部版本、以及文章描述的实现存在差异。
文章里讨论的部分设计属于后续方向，原型中还没有实现。3

原型眼下能做的事也写在同一段里：它面向一个 GitHub 仓库干活，打包成 DeepSeek Harness 的插件。3

它监听 GitHub，可选接入飞书。有人允许它做事时，它开一个工作项，在自己的会话和目录里推进，再回到原来的对话里答复，比如提交一个 PR。3

另外带一个网页面板，列出需要人接手的事项。3

对照文章里写的 IM 群聊、邮件、日程提醒、跨设备执行，原型覆盖的是其中一个场景。

没人 @ 也能干活，靠的是两层分工

原文的起点是一个观察：一个人通常只能同时跟进 3 到 5 个活跃 Session。1

多项工作并行时，人得记住每个会话做到哪一步，再把上下文重新交代一遍。模型做单项任务的能力越强，卡住多任务的就是人的注意力。1

Super-agent 想让用户始终面对同一个 Agent，底层有多个会话并行，会话管理交给系统自己。1

原文把这种形态的特征归成四条。1

连续：在 IM、GitHub 评论这些界面里直接交互，方案在群里定、在 PR 里改，它知道这两条说的是同一件事。
高效：上一个任务还在跑，下一条指令就能进来。
主动：持续观察环境，该出手时出手，不需要时保持安静。
持久：长期在线，遇到异常能自己恢复。

撑起这四条的是五个模块：双层架构、事件驱动、面向人的交互、计算与状态及环境的分离，以及主系统之外的 Watchdog。1

上层 Router 常驻，接下所有入口的人类消息，维护全局上下文，负责分派。它不亲自执行具体任务，原文说它甚至可以连 Bash 工具都不配。1

下层 Worker 是一组会话，各自隔离上下文，工具挂满，专心做完一件事。Worker 不直接与人对话，结论交回 Router，由 Router 统一回复。1

原文把这种结构和常见的 Agent Team 分了开：Team Lead 要拆子任务、跟细节，自身推理负载很重；Router 只处理任务之间的关联与分派，用较轻的模型就够。1

用户面对的始终是同一个 Agent，底层的多个会话则由系统自行管理，而且它开始主动参与工作。

原文用这句话总结这套双层分工。

Super-agent 的整体架构，标号 [2] 至 [6] 对应原文第 2 至第 6 节；事件从左侧进入，经两级过滤交给 Router，Worker 隔离执行，执行环境留在原地，Watchdog 在主系统之外。

同一个任务，在两个平台之间接着做

原文举了一个内部实例：一项开发任务从 IM 群聊开始，一路延续到 GitHub 的 PR 评审。1

用户先在群里决定用方案 A，后来在 GitHub 评论里要求改成方案 B。它认出这两条消息属于同一项工作，据此调整方向。1

一项字体配置需求从 IM 提出、在 GitHub 评审里改动的完整往返，同一个 Agent 在两种界面里接住同一条线；出自 DeepSeek Harness 团队的设计文章。

支撑这件事的机制叫订阅与直通。1

Router 依据某条 Thread 的初始事件建好 Worker 之后，这个 Worker 直接订阅该 Thread。同一 Thread 下后续的消息由程序直接发给它，不必再经 Router 转发。1

Thread 指的是一条事件流：一个 GitHub PR、一个 IM 话题、一封邮件串下面接连发生的事件。1

订阅是多对多的。一个 Worker 能订阅多条 Thread，一条 Thread 也能被多个 Worker 订阅。1

多个 Worker 在同一个 PR 里碰头时，新消息会同时送到每一家，它们凭同一份信息自己避让，不需要点对点通信。1

这条快路径省下多少，原文在实验里量过：关掉直通，Router 的决定次数增加约 30%，读缓存 token 从 2323 万涨到 3177 万，多出约 37%。1

群里没人 @，它自己复现了 Bug

接入真实的群聊和代码平台之后，环境事件是「高噪音、低触发率」：绝大多数日常消息不需要 Agent 介入。1

每条都调一次大模型判断，延迟和成本都扛不住。原文借了 Fast Path 与 Slow Path 的分法，做成两级过滤。1

程序层先按事件来源、群组范围、人和机器人白名单这类确定条件过一遍，把大部分无关消息挡在模型之前。1

过了这道门的候选事件才交给大模型，由它按提示词里的策略和上下文判断要不要行动。策略因此可以随时用自然语言加一条。1

判断完要不要动，还有一步是提前动。原文叫它投机执行：结果还没人确认要不要，先在后台试，有价值就交，没价值就丢掉。1

他们在内部用户群里配了一条「静默复现并修复」的策略：有人反馈问题或在讨论改法，Agent 先在后台复现、找修法，确认问题存在并且找到简单修法后才交付，否则全程不说话。1

群里的用户 A 抱怨 macOS 端窗口失焦时点会话会被识别成双击，全程没有人 @ 它；它自己复现、定位到 Electron 吞掉激活窗口那次点击，再回来附上前后的对比截图。

同一个思路也用在个人助手上：收到会议邀约，先核日程冲突、收集背景资料、备好回复草稿，等用户过目。1

后台跑着，前台还能回你新消息

经典的 ReAct Loop 里，模型发起一次同步的 run() 调用，整个循环停在那里等工具返回，期间新消息进不来。1

原文把耗时的工具调用改成异步的 start() 与 stop()，拼成异步 ReAct Loop。模型调 start() 后立刻收到「已启动」，循环不再等这件工具。1

后台工具跑完，结果作为一条新事件投递回会话。模型觉得某条命令拖得太久，也可以调 stop() 主动掐掉。1

这一机制已经在 DeepSeek Harness 里实现，但还没有默认开启。1

上排是同步调用，虚线框里整段耗时都卡在等工具；下排改成异步调用后立刻返回 Started，后台工具运行期间仍接得住新消息。

不同信道的输出规范，原文也写了。IM 里按低打扰处理，只在需要决策或验收时说话，一次回复不超过 100 词，这条是他们验证过的硬规定。1

GitHub、邮件和文档属于异步信道，交付要完整：问题背景、改动说明、验证结果都按项目规范写全。1

12.4 分钟是在什么条件下测出来的

转述里最容易被单独拎出来的是 12.4 分钟。它的测量条件在原文第 7 节。1

实验用群聊和 GitHub CI 消息流同时驱动四种方案。一次实验约 300 条消息，其中约 20 条是工作请求，其余是闲聊、跟进、叫停和 CI 消息。1

编码工作由一个只消耗时间的工具代替，所以这组实验衡量的是调度与协作，不是模型解决任务的能力。每种方案重复跑 5 次。1

四种方案是：完整 Super-agent、去掉直通的 Super-agent，以及两种提示词配置下的单 Session + Subagent 工具。1

结果里，Super-agent 的任务完成时间中位数 12.4 分钟，95 分位 15.7 分钟。1

单 Session 那一组波动大得多。中性提示下，模型 5 次运行一次都没调用 Subagent，所有活都在主会话里做，被新消息反复打断，95 分位拖到 29.5 分钟。1

换成「优先委派」的提示后，5 次里有 4 次真的委派了，整体仍然慢于 Super-agent。剩下那一次它判断任务「很小」自己做了，图上就多出一条长尾。1

黑线是工作请求的到达节奏，另外四条是完成曲线；消息间隔与工作时长按 1/4 缩放，模型调用耗时为真实值，每种方案重复 5 次。

代价也写在原文里：维护多个独立会话，Super-agent 单次实验的读缓存 token 高于单 Session，用更多 token 换来更短、更稳的完成时间。1

Router 层的批处理另有单独压测。

把需要决定的 Trigger 从每分钟约 1 条提到约 40 条，平均 batch 从 1.0 升到 2.8，单次请求耗时从 2.5 秒只涨到 3.9 秒，单个决定分摊的推理时间从 6.4 秒降到 1.6 秒。1

原文自己给这组结果加了限定：基于合成负载与简化环境，部分设置还能更严谨，只作初步参考。1

24 小时在线，要把三样东西拆开

本地 Agent 默认把三样东西绑在一台设备上：推进 Agent Loop 的计算、需要持久保存的会话状态、以及代码仓库和工具链构成的执行环境。设备一休眠，Agent 就停了。1

第一步，把计算和状态分开。计算放进云端无状态的弹性容器，会话状态存进数据库，容器可以重启、替换、水平扩展。1

第二步，把 Agent Loop 和执行环境分开。环境留在原地，端侧只部署一个不保存会话状态的轻量 daemon，它只负责执行命令、把结果送回去。1

为什么不把环境搬上云，原文给了理由：真实工作环境里有未提交的本地修改、私有凭据、内网服务依赖和特定工具链，复制成本高，还容易漏。1

这套做法支持把用户日常用的开发机或个人电脑接进云端 Agent，原文叫它 BYOM（Bring Your Own Machine）。1

原文也点了它的出处：思路与 Anthropic 提出的「脑手分离」一致，区别在场景——那篇讲的是托管服务里的按需沙箱与客户 VPC，这里先要接的是间歇在线的个人机器。1

在线之外还要自愈，于是有 Watchdog：一个在主系统之外、由定时消息驱动的独立 Session。1

它既处理接口报错、状态恢复失败这类基础设施故障，也由模型判断各个 Worker 有没有实质进展、方向有没有偏。1

Watchdog 本身是一个工具齐全的 Agent Session，维护者可以用自然语言问它故障原因，也能让它在线改主系统，比如增删提示词、调整触发规则。1

官方自己列出的四个开放问题

原文第 8 节写的是四件还没解决的事。1

一是双层架构怎么扩。什么时候该把 Router 水平切分、切多细，同层 Worker 什么时候需要直接通信，都还没有定论。1

二是会话不再对应用户界面之后，人机协作长什么样。用户看到的一个会话，底层未必只对应一个 Session；中途介入、接管、实时协同怎么做，也没定。1

三是 A2A。组织里存在多个彼此隔离的实例时，怎么在互不共享上下文、各自代表不同权限边界的前提下协作。1

四是安全与隐私。这一条原文写得最直接：云端 Agent Loop 持续接外部事件，端侧设备上存着私有代码、敏感数据和本地凭据，一旦云端被入侵或被提示词注入攻破，它连接的所有端侧设备都面临被控制的风险。1

原文还补了一层：即使云端没被攻破，凭据一旦进入模型的上下文，正常执行过程中也可能泄露，所以需要一套让 Agent 不接触凭据本身也能用凭据的机制。1

想自己跑一遍，还得配齐这些

仓库是 DeepSeek Harness 的一个插件，跑之前要有 Harness。4

安装流程写在 SETUP.md 里，交给 coding agent 执行：让它读这份文件，带着你装。5

仓库里的说明是，它一次只问一个短问题，先把完整计划摆出来，再安装和配置。3

装完有一套按编号的技术文档，从设计原则、领域模型、授权、执行一路读到部署，仓库也给了用 pnpm check 跑类型检查、测试和构建的命令。3

许可为 MIT，改和用都不需要额外申请。3

README 末尾提醒了一句：这是研究代码，用它之前先审一遍、按自己的环境改。3

原文在最后一节写了自己的判断：整套设计没有提出新理论，只是把计算机系统里那些经典工程思想搬进了 Agent 系统。

目前内部的实例已在持续运行，日常参与问题复现、修复、代码审查和 DeepSeek Harness 自身的迭代。1

当 AI 逐渐能够独立完成复杂任务，如何让它长期、稳定地推进多项工作，也开始成为 Agent 系统需要解决的新问题。

量子位原文的收尾落在这一句。想自己试的，先确认手上有 DeepSeek Harness；只想借这套思路的，读那张架构图和按编号的九份文档，比读代码快。

References

1
Super-agent 设计探索：迈向更自主的 Agent 系统
mp.weixin.qq.com
2
deepseek-ai/dsh-superagent-prototype
github.com
3
README
raw.githubusercontent.com
4
DeepSeek Harness
deepseek.com
5
SETUP.md
github.com

本文转载自微信公众号「量子位」。原文发表于 2026 年 10 月 31 日，作者梦瑶，《刚刚，DeepSeek 重磅开源：Agent 底座架构！》。

10 月 31 日晚上，DeepSeek 一次放出了两样东西。1

一样是一篇文章，《Super-agent 设计探索：迈向更自主的 Agent 系统》，署名 DeepSeek Harness 团队，作者 Yujia Qiao。1

另一样是一个 GitHub 仓库 dsh-superagent-prototype，采用 MIT 许可。2

到 11 月 1 日上午，这个仓库收到 2.3k 星标、194 次 fork，提交记录只有一条。2

量子位这篇报道把两件事合在一起写，标题落在「开源」上。读之前值得分清一件事：文章讲的是完整设计，仓库给的是其中一部分的实现。

开源出来的是一段原型

仓库的 README 第一段就把定位写清楚了。3

四句话，依次是：

这是供参考的研究原型，并非 DeepSeek 官方产品。
代码来自团队的日常工作，其中大量工程由 coding agent 完成。
为公开发布做过改写，与内部版本、以及文章描述的实现存在差异。
文章里讨论的部分设计属于后续方向，原型中还没有实现。3

原型眼下能做的事也写在同一段里：它面向一个 GitHub 仓库干活，打包成 DeepSeek Harness 的插件。3

它监听 GitHub，可选接入飞书。有人允许它做事时，它开一个工作项，在自己的会话和目录里推进，再回到原来的对话里答复，比如提交一个 PR。3

另外带一个网页面板，列出需要人接手的事项。3

对照文章里写的 IM 群聊、邮件、日程提醒、跨设备执行，原型覆盖的是其中一个场景。

没人 @ 也能干活，靠的是两层分工

原文的起点是一个观察：一个人通常只能同时跟进 3 到 5 个活跃 Session。1

多项工作并行时，人得记住每个会话做到哪一步，再把上下文重新交代一遍。模型做单项任务的能力越强，卡住多任务的就是人的注意力。1

Super-agent 想让用户始终面对同一个 Agent，底层有多个会话并行，会话管理交给系统自己。1

原文把这种形态的特征归成四条。1

连续：在 IM、GitHub 评论这些界面里直接交互，方案在群里定、在 PR 里改，它知道这两条说的是同一件事。
高效：上一个任务还在跑，下一条指令就能进来。
主动：持续观察环境，该出手时出手，不需要时保持安静。
持久：长期在线，遇到异常能自己恢复。

撑起这四条的是五个模块：双层架构、事件驱动、面向人的交互、计算与状态及环境的分离，以及主系统之外的 Watchdog。1

上层 Router 常驻，接下所有入口的人类消息，维护全局上下文，负责分派。它不亲自执行具体任务，原文说它甚至可以连 Bash 工具都不配。1

下层 Worker 是一组会话，各自隔离上下文，工具挂满，专心做完一件事。Worker 不直接与人对话，结论交回 Router，由 Router 统一回复。1

原文把这种结构和常见的 Agent Team 分了开：Team Lead 要拆子任务、跟细节，自身推理负载很重；Router 只处理任务之间的关联与分派，用较轻的模型就够。1

用户面对的始终是同一个 Agent，底层的多个会话则由系统自行管理，而且它开始主动参与工作。

原文用这句话总结这套双层分工。

同一个任务，在两个平台之间接着做

原文举了一个内部实例：一项开发任务从 IM 群聊开始，一路延续到 GitHub 的 PR 评审。1

用户先在群里决定用方案 A，后来在 GitHub 评论里要求改成方案 B。它认出这两条消息属于同一项工作，据此调整方向。1

一项字体配置需求从 IM 提出、在 GitHub 评审里改动的完整往返，同一个 Agent 在两种界面里接住同一条线；出自 DeepSeek Harness 团队的设计文章。

支撑这件事的机制叫订阅与直通。1

Router 依据某条 Thread 的初始事件建好 Worker 之后，这个 Worker 直接订阅该 Thread。同一 Thread 下后续的消息由程序直接发给它，不必再经 Router 转发。1

Thread 指的是一条事件流：一个 GitHub PR、一个 IM 话题、一封邮件串下面接连发生的事件。1

订阅是多对多的。一个 Worker 能订阅多条 Thread，一条 Thread 也能被多个 Worker 订阅。1

多个 Worker 在同一个 PR 里碰头时，新消息会同时送到每一家，它们凭同一份信息自己避让，不需要点对点通信。1

这条快路径省下多少，原文在实验里量过：关掉直通，Router 的决定次数增加约 30%，读缓存 token 从 2323 万涨到 3177 万，多出约 37%。1

群里没人 @，它自己复现了 Bug

接入真实的群聊和代码平台之后，环境事件是「高噪音、低触发率」：绝大多数日常消息不需要 Agent 介入。1

每条都调一次大模型判断，延迟和成本都扛不住。原文借了 Fast Path 与 Slow Path 的分法，做成两级过滤。1

程序层先按事件来源、群组范围、人和机器人白名单这类确定条件过一遍，把大部分无关消息挡在模型之前。1

过了这道门的候选事件才交给大模型，由它按提示词里的策略和上下文判断要不要行动。策略因此可以随时用自然语言加一条。1

判断完要不要动，还有一步是提前动。原文叫它投机执行：结果还没人确认要不要，先在后台试，有价值就交，没价值就丢掉。1

同一个思路也用在个人助手上：收到会议邀约，先核日程冲突、收集背景资料、备好回复草稿，等用户过目。1

后台跑着，前台还能回你新消息

经典的 ReAct Loop 里，模型发起一次同步的 run() 调用，整个循环停在那里等工具返回，期间新消息进不来。1

原文把耗时的工具调用改成异步的 start() 与 stop()，拼成异步 ReAct Loop。模型调 start() 后立刻收到「已启动」，循环不再等这件工具。1

后台工具跑完，结果作为一条新事件投递回会话。模型觉得某条命令拖得太久，也可以调 stop() 主动掐掉。1

这一机制已经在 DeepSeek Harness 里实现，但还没有默认开启。1

上排是同步调用，虚线框里整段耗时都卡在等工具；下排改成异步调用后立刻返回 Started，后台工具运行期间仍接得住新消息。

不同信道的输出规范，原文也写了。IM 里按低打扰处理，只在需要决策或验收时说话，一次回复不超过 100 词，这条是他们验证过的硬规定。1

GitHub、邮件和文档属于异步信道，交付要完整：问题背景、改动说明、验证结果都按项目规范写全。1

12.4 分钟是在什么条件下测出来的

转述里最容易被单独拎出来的是 12.4 分钟。它的测量条件在原文第 7 节。1

实验用群聊和 GitHub CI 消息流同时驱动四种方案。一次实验约 300 条消息，其中约 20 条是工作请求，其余是闲聊、跟进、叫停和 CI 消息。1

编码工作由一个只消耗时间的工具代替，所以这组实验衡量的是调度与协作，不是模型解决任务的能力。每种方案重复跑 5 次。1

四种方案是：完整 Super-agent、去掉直通的 Super-agent，以及两种提示词配置下的单 Session + Subagent 工具。1

结果里，Super-agent 的任务完成时间中位数 12.4 分钟，95 分位 15.7 分钟。1

单 Session 那一组波动大得多。中性提示下，模型 5 次运行一次都没调用 Subagent，所有活都在主会话里做，被新消息反复打断，95 分位拖到 29.5 分钟。1

换成「优先委派」的提示后，5 次里有 4 次真的委派了，整体仍然慢于 Super-agent。剩下那一次它判断任务「很小」自己做了，图上就多出一条长尾。1

黑线是工作请求的到达节奏，另外四条是完成曲线；消息间隔与工作时长按 1/4 缩放，模型调用耗时为真实值，每种方案重复 5 次。

代价也写在原文里：维护多个独立会话，Super-agent 单次实验的读缓存 token 高于单 Session，用更多 token 换来更短、更稳的完成时间。1

Router 层的批处理另有单独压测。

原文自己给这组结果加了限定：基于合成负载与简化环境，部分设置还能更严谨，只作初步参考。1

24 小时在线，要把三样东西拆开

第一步，把计算和状态分开。计算放进云端无状态的弹性容器，会话状态存进数据库，容器可以重启、替换、水平扩展。1

第二步，把 Agent Loop 和执行环境分开。环境留在原地，端侧只部署一个不保存会话状态的轻量 daemon，它只负责执行命令、把结果送回去。1

为什么不把环境搬上云，原文给了理由：真实工作环境里有未提交的本地修改、私有凭据、内网服务依赖和特定工具链，复制成本高，还容易漏。1

这套做法支持把用户日常用的开发机或个人电脑接进云端 Agent，原文叫它 BYOM（Bring Your Own Machine）。1

在线之外还要自愈，于是有 Watchdog：一个在主系统之外、由定时消息驱动的独立 Session。1

它既处理接口报错、状态恢复失败这类基础设施故障，也由模型判断各个 Worker 有没有实质进展、方向有没有偏。1

Watchdog 本身是一个工具齐全的 Agent Session，维护者可以用自然语言问它故障原因，也能让它在线改主系统，比如增删提示词、调整触发规则。1

官方自己列出的四个开放问题

原文第 8 节写的是四件还没解决的事。1

一是双层架构怎么扩。什么时候该把 Router 水平切分、切多细，同层 Worker 什么时候需要直接通信，都还没有定论。1

二是会话不再对应用户界面之后，人机协作长什么样。用户看到的一个会话，底层未必只对应一个 Session；中途介入、接管、实时协同怎么做，也没定。1

三是 A2A。组织里存在多个彼此隔离的实例时，怎么在互不共享上下文、各自代表不同权限边界的前提下协作。1

想自己跑一遍，还得配齐这些

仓库是 DeepSeek Harness 的一个插件，跑之前要有 Harness。4

安装流程写在 SETUP.md 里，交给 coding agent 执行：让它读这份文件，带着你装。5

仓库里的说明是，它一次只问一个短问题，先把完整计划摆出来，再安装和配置。3

装完有一套按编号的技术文档，从设计原则、领域模型、授权、执行一路读到部署，仓库也给了用 pnpm check 跑类型检查、测试和构建的命令。3

许可为 MIT，改和用都不需要额外申请。3

README 末尾提醒了一句：这是研究代码，用它之前先审一遍、按自己的环境改。3

原文在最后一节写了自己的判断：整套设计没有提出新理论，只是把计算机系统里那些经典工程思想搬进了 Agent 系统。

目前内部的实例已在持续运行，日常参与问题复现、修复、代码审查和 DeepSeek Harness 自身的迭代。1

当 AI 逐渐能够独立完成复杂任务，如何让它长期、稳定地推进多项工作，也开始成为 Agent 系统需要解决的新问题。

量子位原文的收尾落在这一句。想自己试的，先确认手上有 DeepSeek Harness；只想借这套思路的，读那张架构图和按编号的九份文档，比读代码快。

References

1
Super-agent 设计探索：迈向更自主的 Agent 系统
mp.weixin.qq.com
2
deepseek-ai/dsh-superagent-prototype
github.com
3
README
raw.githubusercontent.com
4
DeepSeek Harness
deepseek.com
5
SETUP.md
github.com

刚刚，DeepSeek重磅开源：Agent底座架构！

开源出来的是一段原型

没人 @ 也能干活，靠的是两层分工

同一个任务，在两个平台之间接着做

群里没人 @，它自己复现了 Bug

后台跑着，前台还能回你新消息

12.4 分钟是在什么条件下测出来的

24 小时在线，要把三样东西拆开

官方自己列出的四个开放问题

想自己跑一遍，还得配齐这些

References

Related content

刚刚，DeepSeek重磅开源：Agent底座架构！

开源出来的是一段原型

没人 @ 也能干活，靠的是两层分工

同一个任务，在两个平台之间接着做

群里没人 @，它自己复现了 Bug

后台跑着，前台还能回你新消息

12.4 分钟是在什么条件下测出来的

24 小时在线，要把三样东西拆开

官方自己列出的四个开放问题

想自己跑一遍，还得配齐这些

References

Related content