从单会话Super-agent
DeepSeek 的常驻 Agent 架构解读与思考
开场：这次就是一起读一篇文章。DeepSeek Harness 团队 10 月 31 日发了一篇讨论 agent 系统架构的长文，同时开源了一个研究原型。
文章自己说明：这是在讨论架构思路，不是 DeepSeek Harness 的现有功能介绍；原型也只是研究用途。
右边这张小图，就是今天要讲的整体样子：各种消息进来，一个前台接住，后面几个 Worker 干活。
今天分五段
先讲问题，再讲他们的思路和五个模块，然后看实验数字和开源原型，最后是我们自己的几个疑问和可以马上试的小做法。
第三段最长，每个模块右上角会标当前讲到第几个。
01
问题
模型越来越能干，
第一段，先把问题讲清楚。
瓶颈换了地方
做一件事
同时做很多件
文章开头的判断：做单个任务，瓶颈是模型能力；同时做很多任务，瓶颈变成了人的注意力。
上面一行是过去的体验：我们等模型想清楚。下面一行是现在：好几个 Agent 都在等你看结果、等你确认。
文章还说，人的角色正在往上走，从盯执行细节，变成做更高层的决策和签字。
一个人，同时能跟住几个会话？
个活跃会话，大概就到头了
作者的经验值，不是实验数据
在跟
在跟
在跟
在跟
在跟
等你
等你
等你
等你
等你
等你
等你
等你
等你
等你
再多开几个，Agent 跑得再快，也只能排队等人。
3 到 5 是作者的经验值。可以问一下大家：你自己同时开几个 Agent 窗口会开始乱？
右下角可以点开一个小模拟：会话越开越多时，排队等你的会越积越多；换成「入口替你盯」之后会好很多。模拟参数是假设的，只演示机制。
给 Agent 多接几个工具，也解决不了
很多人的第一反应是：给现有的单会话 Agent 接 CLI、MCP、各种连接器，让它能收外部消息。
文章说这样能做的事是变多了，但根本问题还在：它还是一个同步的会话，长操作会卡住；不同任务的上下文混在一起；本地设备一离线就全停。维持这样一套东西本身也很费人。
02
思路
不再是「一个会话」，
第二段，他们想要的到底是什么。
想要的是：像一个一直在线的同事
Continuous
一直是
IM 里说方案 A，
Productive
同时
上一件没做完，
Proactive
自己
值得做就做，
Persistent
一直
常驻在线，
原文把这种 Agent 和它的系统架构叫 Super-agent，给了四个特征：Continuous、Productive、Proactive、Persistent。
连续：你在哪找它都是同一个它，不用想「这个会话里有没有那段上下文」。
并行：能同时把几件复杂的事做好，上一个命令没结束也能接新指令。
主动：不用一步步指挥，监听环境事件，值得处理就处理，否则安静。
持续：一直在线，直连真实工作环境，长期运行中出问题能自己恢复。
他们内部有一个跑在 DeepSeek Harness 上的实例，能在 IM 和 GitHub 之间延续同一个开发任务，也会盯公开群里的反馈，没人 @ 它也能自己定位根因、提 PR。
四个特征，靠五个模块撑起来
一个 ReAct 循环再强也给不了，得靠系统架构
这页是整篇文章的地图。原文的对应关系：
两层架构 → 连续 + 并行；事件驱动 → 主动；全双工多通道 → 让日常交互也连续、并行；计算/状态/环境分离和 Watchdog → 持续在线。
文章很坦白：他们没有提新理论，是把计算机系统里的经典思路搬到 Agent 上——Fast/Slow Path、缓存与局部性、投机执行、存算分离、外部控制回路。后面每个模块都能看到这个影子。
他们还预测：只要目标是常驻、并发响应事件的系统，个人 Agent 和研发用的 Agent 最后会长得很像。
03
五个模块
他们具体是怎么拆的
1 两层架构2 事件驱动3 全双工 · 多通道4 计算、状态、环境分开5 Watchdog
第三段是重点，五个模块一个个过。
全塞一个会话？每件事开一个？都不行
一句话：一个会话太挤，五个会话太散，所以分两层。
别说错：「多个会话不好并发」是错的——多个会话本来就能并行，卡的是人要来回切。真正会被同步工具卡住的，是「一个会话里塞所有事」。
被问到「单会话加 subagent 不也行吗」：可以，但要靠 prompt 让它记得委派，后面实验会看到这不稳。
（按 → 逐个出现）
这是连续性和吞吐之间的取舍。
全塞一个会话：上下文最连贯，因为它什么都看得到；但 ReAct 一次走一步，任务一多就慢，几件事的中间过程混在一起，结果也会变差。
每件事开一个新会话：并发最高；但任务之间不完全独立时，没有全局上下文，结果对不上；几个会话分别回复你，也很乱。
所以分两层：一个常驻的前台保证连贯，后面一层隔离的会话负责并发。
原文有句话值得记：让用户自己管会话，很大程度上是从底层 LLM API 带过来的习惯。会话应该是系统的实现细节，不该是用户的心智负担。
前台只接话和派活，干活的在后面
前台 · 常驻
Router
接话 · 派活 · 汇总给你
一句话：前台管「对人说话、派给谁」，Worker 管「把事做完」。
别说错：别说「所有消息都由 Router 转发」——已经有主人的后续消息是代码直送的（后面第 16 页）。
Router 层：所有和人的交互、跨任务的信息和决策都汇在这里，是全局的顺序点、协调点和记忆。为了不让它自己变成瓶颈，它不执行任务，只和人打交道、派活，可以完全不给 Bash。
Worker 层：每个任务一个隔离会话，全套执行工具，直接决定代码质量，所以一般用最强的模型。Worker 不直接跟人说话，推理过程和工具调用不外泄，状态汇报给前台，由前台统一回复。
两层是逻辑分工，内部不一定各是一个会话：Worker 内部可以再开 subagent，甚至本身就是一个 Agent Team，前台不用关心。
右下两个按钮：一个是可点击的完整结构图，一个是 7 步动画。
和 Agent Team 的区别：只派活，不拆活
队长
步骤 1 步骤 2 步骤 3
一件大事拆成步骤，
Router
修 bug 审 PR 写功能
几件互不相干的事，
一句话：DeepSeek 限制的是前台的「执行职责」，不是它的「智力」。
别说错：别说「作者主张 Router 越轻越好、越笨越好」。原文是：前台不拆解、不执行，所以活比想象中简单，轻模型「通常」够用。能力和职责是两个维度，第 40 页会展开我们的看法。
乍一看，一个中心派活给几个执行者，很像常见的 Agent Team。但关注点不同：
Agent Team 通常把一个复杂任务拆成紧耦合的步骤，队长要深入理解任务、规划子任务、频繁协调成员，推理负担很重。
Super-agent 的前台只派发任务、在高层跟踪任务之间的关系，不拆解单个任务。
所以作者的经验是：前台的活往往比想象中简单，轻一点的模型通常就能兼顾速度和质量。注意原文是「通常」，不是规定。
反过来，Agent Team 也可以当两层架构用，只要用 prompt 限制主会话不自己干活、只对外交互和派活。
可以顺带一句：我们自己做的 Hive，Orchestrator 要规划、拆解、验收，其实更像左边这种；第 42 页会对照。
一个前台扛得住吗？越忙，每个决策越便宜
1.0
2.8
2.5s
3.9s
6.4s
1.6s
一批合几条
单次请求耗时
摊到每个决策
很多人会担心：所有事都经过一个前台，它会不会成瓶颈？
他们的做法：前台推理的这一轮里到达的事件先排队，下一轮合成一批一起送进模型。前台每一步都是长输入、短输出，合在一起的事件在 Prefill 阶段并行计算，所以单次请求耗时涨得比批大小慢得多。
压测数字：需要决策的事件从每分钟约 1 条加到约 40 条，平均一批从 1.0 条涨到 2.8 条，单次请求从 2.5 秒到 3.9 秒，摊到每个决策的推理时间反而从 6.4 秒降到 1.6 秒。
（一个决策可能要好几次 LLM 请求，比如先召回上下文再派活，所以每决策时间可以大于每请求时间。）
结论：按他们现在团队的规模，不需要为了吞吐提前把前台拆成多个，拆了反而丢全局连续性。真要扩展，可以多级过滤或水平分片，但分得越细，共享的记忆越少。
一大堆消息里，真要动手的没几条
第一道 · 代码
先用规则筛
来源 · 哪个群 · 白名单
第二道 · 模型
再判断值不值
策略写在 prompt 里
约 300 条
约 20 条
一句话：两道筛子管的是「要不要处理」；下一页的直送管的是「交给谁」。
举例：CI 失败、群里随口一句「这个页面好像有点慢」——第一道看来源和名单，第二道让模型判断值不值得管。
注意：CI 成功也不能一律丢掉，如果有 Worker 正在等这个结果，就得通知它。规则看的是事件加上系统当前状态。
Super-agent 的主要输入不再是人一句句敲的 prompt，而是环境里的半结构化事件：群聊、邮件、日历提醒、代码评审评论、CI 结果……原文统一叫 Trigger。
接进真实群聊和代码平台，事件流噪声大、需要动手的比例很低。每条都让大模型从头判断，延迟和算力都受不了。
他们借了计算机系统的 Fast Path / Slow Path：
第一道是代码：按来源、群、用户或 bot 白名单做确定性准入。每个来源可以设成「只响应明确请求」「当作候选」或「忽略」。大部分消息在这里就被挡掉，不花一个 token。
第二道是模型：过了第一道的候选，才交给 LLM 结合上下文判断，策略写成 prompt。这一层也是自然语言的扩展点，团队随时可以用一段话开关、增加策略。
原型里的规则也是这样：名单里的人 @ 它或私聊算明确请求；其它按准入表判断；已经在处理的话题里的消息算跟进。
同一件事的后续消息，直接送到在做的那个
没订阅时：先绕前台判断一圈
代码查订阅表，直接送
话题 = 同一个 PR、同一串群聊回复、同一封邮件往来
一句话：已经有主人的消息，用代码查订阅表直接送，不用再让前台的模型判断一次。
别说错：别说两件事「强一致」——那是分布式里讲数据读写的术语。这里说「有明确的归属关系」就行。
被问到「省的是什么」：省的是前台多一轮模型判断、多读一遍长上下文；Worker 照样要读这条消息、照样要干活。
Fast/Slow 的思路也用在路由上：前台只处理新任务的冷启动和跨任务协调，已有主人的后续事件由代码直接送达。
同一个 PR、同一串话题回复、同一封邮件往来，原文叫一个 Thread。前台为一个 Thread 的第一个事件派了 Worker 后，这个 Worker 就订阅这个 Thread；之后的事件由代码直接送过去，前台不用再调一次工具去转发。前台仍然能看到所有事件，用来掌握全局，但只评估还没有订阅者的新事件。
如果新事件不属于当前任务，Worker 可以退订，或交还给前台重新派。
（按 →）订阅是多对多的：几个 Worker 订阅同一个 Thread，就能同时收到同样的事件，自己发现并解决冲突，不需要点对点通信。
原型里：飞书按话题根消息归并，GitHub 按 issue/PR 号。主聊天里不带话题的新消息，前台只有在它明确指向某个工单时才归过去——原型文档原话是「话题相似不够」。
谁收到消息，和谁来拍板，是两回事
筛子管「要不要处理」，直送管「交给谁」，都不管「谁说了算」
PR #42 下的新评论
「这个先停一下，
一句话：消息由谁接收，和消息由谁决策，是两个问题。
这页是我们自己加的一个例子，用来回答一个很自然的追问：如果用户在 PR 下面说「先停，优先做另一个项目」，这条还走直送吗？
答案：照样直送给 Worker A，它读完会发现里面有两件事——（按 →）停下自己的活，在它职责之内，按规则处理；（按 →）调整别的项目的优先级，超出了它的范围，要交给前台做全局协调。
（按 →）还有一个安全前提：不是谁在 PR 下留言，Worker 都照办。评论的人得有权限；原型文档也写了，消息、评论只是决策输入，不能改变权限。
所以直送并没有绕开前台的全局协调，它只是省掉了不必要的那一次模型判断。
把上下文窗口当缓存：先放索引，要用再翻
1 先给最少的：
2 按「局部性」
3 太长就截断，
上下文窗口
#T-812 · 群话题：Safari 登录白屏
相关：PR #42 · Worker W-3
前 50 字：「Safari 上点登录没反应……」
被回复的那条 + 前后两条消息
……其余 3,000 字 → 指针
一句话：Inline 是「提前放进来」，Spill 是「先放外面、留个引用」——它们决定信息放在哪；下一页的 Chain of Recall 决定怎么把外面的找回来。
别说错：Inline 不是「从任务里直接拿到的信息」，而是系统挑出来、提前塞进上下文的信息；Spill 也不是「往回追溯」，追溯是下一页的事。
事件到了目标会话之后，要往上下文里放多少？放太多，窗口被塞满，模型注意力被冲淡；放太少，模型得反复调工具去读，步骤变多。原文一句话：浪费上下文窗口，就是浪费模型的智力。
所以把有限的窗口当缓存。两个基本操作：Inline，把马上可能要用的信息直接放进窗口，省掉工具往返；Spill，超预算或很少用的完整信息放在窗口外，窗口里只留引用或摘要。
（按 → 逐步）配合「局部性」：
第一步，只给当前对象的 ID 和内容摘要；
第二步，按局部性逐步内联：先放紧密相关对象的 ID，再放时间或空间上相邻的内容，比如原文前 50 个字、这条消息前后的 IM 消息、它回复的那条、同一个代码评审讨论里相邻的评论；
第三步，超出长度的就截断，留个指针，模型需要时再调工具读后面的。
这页的话题和 PR 编号都是示意。
顺着 ID，一跳一跳找回来
场景：有人在另一个渠道，提起一个老任务
当前消息 · IM 私聊
「上次那个登录问题
Thread · 群话题
#T-812
有人报了 Safari 白屏
Thread · 代码评审
PR #42
评审意见都在这
每个对象都有 ID，连成一张引用图。前台不用记住全部历史，需要时顺着找。
一句话：靠的是系统里存好的 ID 关系，模型顺着关系一跳跳查，而不是靠 prompt 让它自己去猜去哪找。
被问到「这比项目里放几个 markdown 记忆文件好吗」：不一定，也不冲突。可以把项目知识存在文件里，顺着 ID 链找到这些文件，再把最相关的部分 Inline 进来。哪种更省、更准，要实测。
前台有自己的上下文难题：很多后续消息直送给了 Worker，长期运行下来历史任务越积越多，它不可能把每个任务的完整历史都留在窗口里。但用户在另一个渠道提起一个老任务时，它还得能找回来。
做法是把 Inline & Spill 一致地用在系统里所有对象上：Trigger、Thread、Worker 会话都有唯一 ID，注入一个对象时，顺带内联与它紧密相关的对象 ID。这些 ID 把对象连成一张引用图。
每次通过工具召回一个对象，返回结果也遵循 Inline & Spill，带上下一跳对象的摘要和 ID。于是模型可以从当前事件出发，按需要一跳跳召回下去。原文叫 Chain of Recall。
原文举的例子正是这条链：从当前消息的 Thread 出发，顺着内联的 ID 找到相关的 Worker 会话，再找到和那个 Worker 关联的另一个代码评审 Thread。
窗口有 100 万 token，还要管上下文吗？
装得下 ≠ 便宜
每次调用都要读一遍，
装得下 ≠ 用得好
无关的历史会干扰
装得下 ≠ 还有效
历史里混着讨论、草案
三个月前：定了方案 A
→
一个月前：讨论过 B
→
昨天：正式改成 C
当前有效：C
上下文管理不只管「放多少」，还要管「放什么」「还对不对」
这页是一个常见追问：既然模型窗口越来越大，干嘛不把所有历史全塞进去？
一句话：容量不等于成本，不等于用得好，也不等于信息还有效。
第一，装得下不等于便宜：每次调用都要处理这些输入，缓存能降价，但不是零。
（按 →）第二，装得下不等于用得好：修一个布局 bug，你塞给它几十万 token 的发布计划、别的项目讨论、旧方案，帮不上忙，还可能干扰判断。很多任务需要的信息其实很聚焦。
（按 →）第三，最容易被忽略：装得下不等于还有效。历史里三个月前定了 A，一个月前讨论过 B，昨天正式改成 C。全量塞进去，模型得自己分辨哪个是讨论、哪个作废了。维护好的项目状态可以直接告诉它：当前有效的是 C。
（按 →）所以外部记忆的价值不只是压缩，还有维护时效、来源和有效状态。反过来，按需检索也有额外的工具调用和延迟，哪种更好，还是要拿真实任务比。
先悄悄做，有把握再开口
确认了？
个人场景也一样：收到会议邀请 → 先查冲突、找背景、起草回复，你只要看一眼再发
这一招借的是计算机系统里的「投机执行」：根据环境信号，在还不知道结果会不会被用上的时候，就先在后台开始做。多花一点后台算力，换人少等、少插手。用上的就交付，用不上的丢掉。
他们在 DeepSeek Harness 内部用户群里配了一条「静默复现和修复」策略：有人报问题或讨论改动时，Agent 先在后台尝试复现、找修复；只有确认了问题、并且找到了简单修复，才交付结果，否则全程沉默。
（按 → 逐步出现两条分支和个人场景的例子）
个人场景：会议邀请邮件或待办消息一到，先查日程冲突、收集背景、起草回复，用户只需要看一眼草稿再发。
这里有个前提要提醒：后台先做的动作最好没有对外副作用。
慢的工具不再卡住对话
以前run() 一直等
run(跑测试)……等结果
你：顺便改下文案
排队
→ 这时才能回你
现在start() 马上返回
start()
测试在后台跑
你：顺便改下文案
马上回
结果当成一条新消息回来
一句话：异步 ReAct 解决的是「一个会话内部」被慢工具卡住的问题。
别说错：异步 ReAct 不等于「把任务交给 Worker」。交给 Worker 是任务之间的并行；这里是同一个会话等工具时不卡。下一页专门对比。
经典 ReAct 循环里，模型调一个同步的 run() 工具，循环就一直阻塞到工具结束、返回最终结果。这期间会话没法回应任何新消息。
要去掉这个阻塞，对话得从轮流说话的半双工，变成全双工。做法是把耗时的命令和工具换成异步的 start() 和 stop()：start() 立刻返回「已启动」，循环不等；工具在后台跑完后，系统把结果作为一条新事件送回会话。跑太久，模型也可以根据上下文调 stop() 结束它。
这样前台对话和后台任务解耦了：耗时任务跑着，Agent 照样回应人；新输入在当前推理步结束时就能处理，不用等后台工具。
注意：回得快，不等于你的新指令已经安全地作用到正在跑的任务上，取消、版本这些还要另外处理。
两种「不卡」，别混在一起
Router
任务 A 任务 B 任务 C
不同的事，
前台 你：再加个用例 好，加上了
npm test 跑 10 分钟，结果回来当新消息
同一个会话，
两层可以同时存在：派给了 Worker，它自己跑长测试时照样可能被卡住
这页专门防一个容易说混的点。
一句话：两层架构解决「几件事之间」并行；异步 ReAct 解决「一个会话之内」不被卡住。
左边：前台把不同任务派给不同 Worker，多个独立会话同时执行。
（按 →）右边：同一个 Worker 里，start() 让测试在后台跑，它在等的时候还能接新消息、回话，测试跑完结果作为新事件送回来。
（按 →）两者可以同时存在：任务已经派给 Worker A 了，但 A 自己要跑一个 10 分钟的测试，如果工具是同步的，A 照样没法及时处理发给它的后续消息。
类比：Claude Code 的后台终端更像右边（同一个 Agent 起个后台命令接着聊）；后台 subagent 更像左边（另开一个执行上下文）。
再严谨一点：后台工具在跑，不等于模型在同一个会话里同时做两次推理；是工具等待期间，会话被释放出来，可以在下一步推理时处理新事件。所以我们认为这更多是 Runtime 层面的工程优化。
同一件事，换个地方换种说法
fix: Safari 登录页点击无响应
背景
改动
验证
人在群聊、邮件、GitHub 讨论里说话方式不一样，Agent 也要跟着调整详细程度和回复方式。终端里一大段推理和工具日志没问题，原样贴进群里就是刷屏。
两层架构已经解决了一半：每个任务啰嗦的推理和频繁的工具调用都留在 Worker 里，只有前台对外说话。
剩下的靠为每个渠道定交互规范：
IM 这类即时渠道：轻、少打扰。像一个人类同事一样，只在需要决策或签字时通知，只问直接的问题，给简短结论。原文说他们验证过的一条简单有效的硬规则：每条回复不超过 100 词。
GitHub、邮件、文档这类异步渠道：给结构化、信息密度高的输出。比如提 PR 时按项目规范写清楚问题背景、改动说明和验证结果。
把「脑子」「记性」和「手」分开放
云上
执行环境 · 留在原地
三样东西分开，谁掉线都不拖垮别人
开发机合上了：云上照常接活、记状态
重新连上：需要这台机器的活，自动接着做
本地 Agent 默认把三样东西绑在一台设备上：跑 Agent 循环的计算、要持久保存的会话状态、执行环境（代码仓库、本地工具链）。设备一睡眠或离线，Agent 就停；也够不着别的设备上的环境。
他们借的是存算分离，分两步解耦：
第一步，计算和状态分开：Agent 循环跑在无状态、可弹性扩缩的云容器里，会话和其它持久状态进数据库。容器可以扩、重启、替换，任务的连续性靠存储保住。
第二步，计算和执行环境分开：真实环境里有未提交的改动、私有凭证、内网依赖、特定硬件，同步到云上又贵又容易漏；让用户整个搬去云上，迁移成本又太高。所以环境留在原地，每台端只装一个轻量 daemon，不存会话状态，只负责执行命令、回结果。
这就是 BYOM：把自己的开发机或个人电脑接到云上的 Agent，也支持云上机器和按需环境。设备断断续续在线也行：重新连上后，需要在这台设备上跑的任务会自动开始、做完。
文章自己对比了 Anthropic 的《Decoupling the brain from the hands》：思路一样，区别是 Anthropic 那篇讲托管服务，DeepSeek 先要接的是每个人每天用的开发机。
（页面底部的小动画演示开发机掉线再重连。）
进程活着，不等于活在往前走
● 进程在线
● 进程在线
● 进程在线
原地打转？
查接口报错 判断有没有进展 问它：为什么挂了 让它改规则
发现不对，逐级来： 先问它在干嘛 →给恢复建议 →重启任务 →高风险的找人
一句话：普通监控看「活没活着」，Watchdog 还要看「有没有在往前走」。
我们补充的一个好处：职责分离。持续巡检交给 Watchdog，前台就能专心对人和做全局协调（用户问起进度时它照样可以去读状态）。
被问到「怎么判断没进展」：跑得久不等于有问题，复杂调试本来就慢。要看几样证据——离目标近了没有、测试是不是在重复失败、代码是不是在反复改同一处、Worker 自己有没有报阻塞、执行轨迹是不是在打转。这些都只是信号，不是硬标准。
（按 → 第二步）发现不对就逐级来：先问它在干嘛，再给恢复建议，必要时重启任务，高风险的改动找人批准。
光有存算分离还不够持续在线：长期运行的系统还得能自己从异常里恢复。一个常驻的分布式系统，只靠内部逻辑，很少能长期可靠，需要一个主系统之外的独立控制回路。
Agent 系统又比传统的存活探针、监控脚本多一层：很多异常不是崩溃，而是进程还在跑，模型却在原地打转，或者已经偏离目标。所以既要看基础设施活没活着，也要看任务有没有进展。
他们的做法是一个独立的 Watchdog 会话，跑在主系统之外，由定时消息驱动：处理 API 报错、状态恢复失败这类基础设施故障；也用模型判断每个 Worker 是否有实质进展、是否偏离整体目标；及时修，遇到临时的外部故障就一直复查到恢复。
（按 →）因为它本身就是一个带全套工具的 Agent 会话，维护的人可以直接用大白话问它为什么失败，也可以让它在运行中修正主系统的行为，比如增删 prompt、调整触发规则。
可以想一下：这种「让另一个模型来监督」本身会不会误判？额外的调用和人读报告的成本值不值？
可以顺带一句对照：Hive 是反过来的选择，故意不做卡死检测，因为从外面看「在想」和「卡死」一样；但它拒绝的是靠信号判定，DeepSeek 是让模型读内容判断，两者不矛盾。我们 bot 团队的系统观察员类似 Watchdog，但一天才看一次。
04
实验与原型
数字怎么说，代码怎么写
第四段，看他们的实验和开源原型。
实验怎么做的
写代码用一个「只耗时间」的工具代替
→ 测的是调度和协调，不是代码写得好不好
端到端的消融实验：四种设计同时跑，喂同一股群聊加 GitHub CI 的消息流。每次大约 300 条消息，其中约 20 条是工作请求，其余是闲聊、追问、取消和 CI 消息。
关键一点（按 →）：编码工作用一个只消耗时间的工具模拟，所以测的是系统的调度和协调能力，不是单个任务做得好不好。
四种设计：完整 Super-agent；去掉话题直送的 Super-agent；单会话 + subagent 工具，分别配两种 prompt。每种跑 5 次。
完成时间：两层架构更快，也更稳
完整 Super-agent
去掉话题直送
单会话 + 子 agent中性 prompt
单会话 + 子 agent提示优先委派
12.4 15.7
12.6 15.5
20.4 29.5 分钟
13.8 29.0 分钟
单会话的 p95 都在 29 分钟上下：主会话常常自己动手，被新消息不停打断
p50 是中位数，p95 可以理解成「最慢的那 5% 要多久」，代表长尾。
完整 Super-agent：p50 12.4 分钟，p95 15.7 分钟。去掉话题直送：12.6 / 15.5，几乎一样。
单会话 + subagent、中性 prompt：20.4 / 29.5；换成优先委派的 prompt：中位数降到 13.8，但 p95 还在 29.0。
（按 →）为什么单会话慢且不稳？因为它高度依赖 prompt：主会话经常决定自己干，新消息不断打断它。下一页细看。
靠 prompt 让模型「记得委派」，靠不住
中性 prompt
「合适的时候用 subagent……」
0/5
提示「优先委派」
「每条消息都会打断你，
4/5
剩下那 1 次，模型觉得活「小」，自己上了 → 长尾
该不该委派，交给结构定，别交给模型临场判断
中性 prompt 下，5 次运行里模型一次都没有调用 subagent，所有活都在主会话里干，新消息不停打断它，p95 到了 29.5 分钟。
写明优先委派后，5 次里有 4 次委派了，完成时间有所下降，但整体还是比 Super-agent 长。剩下那 1 次，模型判断活「小」就自己干了，拖出了长尾。
原文的结论：单会话只能靠 prompt 工程和模型临场判断来决定是否委派；两层架构在系统层面缓解了这个问题——前台自己不干活，每个 Worker 只收到它订阅的话题的消息。
（按 →）这一点我觉得是整篇最值得带走的：要它守的规矩，尽量放进结构里。
多花的 token，换来了什么
每次运行、所有会话加起来「读缓存」的 token
完整 Super-agent
去掉话题直送
单会话 · 中性
单会话 · 优先委派
23.2M 31.8M 6.1M 10.8M
去掉直送：+37% ，前台多做约 30% 的决策，完成时间几乎没变
多会话各读各的缓存 → 用 token 换更短、更稳的完成时间
别说错：+30% 是前台的「决策次数」，+37% 是「读缓存的 token」，两个数别记混。
被问到「token 多了，时间为什么没变」，可以讲三个原因（是推测，原文没有逐项拆开测）：
1）前台的活本来就轻，多判断一次只多几秒；
2）前台会批处理，几条事件攒成一批一起算（第 14 页）；
3）最关键：前台不在任务完成的关键路径上。Worker 干活要十几分钟，前台多几秒，还能和 Worker 执行重叠，总时间几乎看不出来。
（按 → 逐条）
第一个看点：话题直送没让任务变快，但省下了一截。去掉直送后完成时间差不多，但前台每次运行多做约 30% 的决策，所有会话读缓存的 token 从 23.2M 涨到 31.8M，约多 37%。原文原话大意：在这个负载下，直送不会让任务完成得更快或更好，但能显著减少前台的 token 和推理开销。
为什么时间没变？前台不是关键路径上的瓶颈，加上批处理，多出来的负载被吸收了。
第二个看点：Super-agent 维护着多个独立会话，读缓存的 token 是单会话的好几倍。它是在用 token 换更短、更稳的完成时间。
注意：这里是「读缓存」的 token，不是总花费，也不是推理 token。
这些数字怎么读
01
合成负载
简化环境，作者自己说
02
读缓存 ≠ 花费
cache-read token 不等于总账单，
03
只测了调度
不说明代码写得更好；
这页是给大家打个预防针，避免把实验结论说过头。
一、作者明确说是合成负载、简化环境，部分设置可以更严谨，结果仅供参考。
二、表里是 cache-read token。缓存读取通常比普通输入便宜很多，所以不能把 +37% 直接读成「多花了 37% 的钱」。
三、写代码是用耗时工具模拟的，测的是调度和协调。真实任务的质量、人工介入次数、总成本，都要在我们自己的负载上测。
他们测了什么，还没测什么
· 多任务下的调度和完成时间
· 读缓存的 token、前台决策次数
· 前台的批处理吞吐
· 真实开发任务做成了几个、质量如何
· Worker 之间的冲突能不能发现、解决
· 人工介入次数、返工、总成本
评价一个架构：花了多少，换来多少真正有用的产出
一句话：实验验证了「模拟负载下的调度效率」，还没回答「真实复杂任务里做得好不好」。
左边是他们测了的：第 7.1 节的四方案消融（完成时间、读缓存 token、决策次数），第 7.2 节的前台批处理压测。
（按 →）右边是如果我们来补，最想测的三样：
一、真实开发任务的成功率和质量——模拟工具只耗时间，反映不了代码质量、测试和架构冲突；
二、跨 Worker 的协调质量——前面说过，Worker 不直接沟通时，协调压力可能往前台集中，这一点现有实验没回答；
三、综合成本——token 之外，还有机器、返工和人的介入时间。
（按 →）最后落到一句：架构是手段，最终看它以多大成本创造了多少有效价值。
开源原型：一个盯着 GitHub 仓库的主动 Agent
示意
另外 9 个工单在跑，不打扰你
一事一工单
每个工单一个 Worker 会话、一个独立目录
权限不听聊天的
白名单、规则由宿主程序强制，消息只是参考
原型 dsh-superagent-prototype，MIT 许可，是 DeepSeek Harness 的一个 bundle：面向单个 GitHub 仓库的主动 coding agent，可以选配接飞书。
几个概念：Ticket（工单）、Executor（每个工单一个 Worker 会话和目录/worktree）、Mandate（授权）、SQLite 账本。Web 面板只显示需要人处理的事，左边这个面板是示意。
权限由宿主强制：白名单、规则、Mandate。原文档说：消息、评论和引用文档只是决策输入，不能改变权限。为看上下文而订阅一个话题，也不会因此获得权限。
主动做事需要团队写规则，并且先以「只记录会做什么」的模式起步。
说话原则很朴素：尽量少占人的注意力，尽量多给价值；只在有人必须行动或能用上结果时开口；一次只问一个具体问题。
工单结束后保留订阅，人再说话就按原授权复活。安装方式也有意思：让 coding agent 照着 SETUP.md 带着你装。推荐看 docs/000-philosophy。
也要看清楚：这还是一份研究代码
权限给得很宽
默认完全访问、用你的系统用户跑；
安全是公开难题
常驻、主动、吃群聊输入，
原型自己声明是研究代码，不是生产可用；文章里部分设计原型没有实现。
两个预设都以 danger-full-access 模式、用运维者的系统用户运行，Worker 能读到用户 home 目录，所以文档建议用专门的系统账号隔离。
也有第三方评论指出：主会话能改团队的 skills、策略和接受模式，靠的只是 prompt 里要求它先等人确认。这和前面「规矩写进结构」的结论正好形成对照。
原文把安全列为开放问题：云端循环一旦被注入，所有连着的端设备都可能被接管。
05
我们的思考
下面是我们的看法和疑问，
最后一段，从文章出来，说说我们读完之后的几个疑问，以及能马上试的东西。这一段都是讨论，不代表原文观点。
入口合成一个，脑子里还是五件事
要盯的窗口
5 → 1
脑子里要装的
5 → 5
省掉的是找窗口；在几件事之间切换的脑力还在，出了问题接手可能更难
这是我们读的时候第一个冒出来的疑问。
把五个会话合成一个入口，省掉的是「入口管理成本」：不用记哪个窗口在干嘛。但你要在五个项目之间切换，五套项目背景还是得装在脑子里，这是「认知切换成本」，入口合并并不直接减少它。
反而有一个反面：Agent 越自主，平时人参与越少，真出问题时，人要恢复上下文、接手，成本可能更高。
所以我会把「省注意力」拆成三件事看：入口管理、认知切换、做决策。原文这套架构主要解决第一件，第三件靠「只在需要拍板时开口」在压，第二件还是开放的。
可以这样收：Super-agent 是把管理会话的责任从人身上挪给了系统，但没有替人把五件事想完。下一页再往前推一步。
更糟一点：五件事挤进同一条聊天流
你：A 先等等，我看下测试……
你：……刚才 C 问的是啥来着？
1 入口统一一个地方说话 · Super-agent 主要做到这
2 交互组织每件事有自己的卡片、线程和状态
3 少让人拍板低风险的自己办，要你定的带证据排好队
接着上一页，再往前推一步：统一入口不仅没有消掉认知切换，还可能带来新的混乱。
原来是在五个窗口之间切换；现在五个项目要你拍板的事、汇报的事，全挤在同一条聊天流里。你回第一个问题回到一半，前台又插进来别的项目的消息；再回头找第二个问题，只能往上翻。跨窗口切换，变成了同一个窗口里的跨任务切换。
要说严谨一点：人不是绝对只能想一件事，简单的事可以穿插着做；但需要深入推理、要装复杂背景的工作，注意力和工作记忆确实有限。而且这是界面设计的问题，不是所有实现都必然这样——任务卡片、独立讨论线程、引用回复都能缓解。
（按 → 逐层）我会把它拆成三层：
一、入口统一：不用管多个窗口。DeepSeek 的两层架构主要解决的是这一层。
二、交互组织：每件事有自己的上下文、状态和决策入口，而不是全混在一条聊天流里。
三、减少决策：低风险的系统自己办，真正要人参与的，按优先级排好、附上证据和背景。
后两层正好对应原文第 8 节的开放问题「没有会话之后怎么协作」。第一层做好了，不代表后两层自然成立。下一步值得优化的，不只是统一入口，而是怎么组织多任务交互、怎么减少人真正要参与的决策。
看到同一条消息，不等于说好了
Worker 之间不直接沟通时，前台可能先卡在决策质量，而不是吞吐
第二个疑问是关于多对多订阅。
几个 Worker 订阅同一个话题，大家都能收到同样的事件，这解决的是第一级：信息可见。但信息可见之后，还有两级：状态是否一致（我看到的版本和你看到的是不是同一个），行动是否协调（两个 Worker 都想改同一处，谁让步）。
原文的说法是 Worker「有机会」自己发现并解决冲突，少数需要跨任务协调的由前台转达。这在独立任务为主的场景下够用；但如果任务耦合变紧，冲突多了，压力就会往前台汇聚。那时前台的瓶颈可能不是每分钟能处理多少条，而是它拍板拍得对不对。
原文自己也把「Worker 之间什么时候该直连、用什么拓扑」列为开放问题。
前台：脑子可以强，手上的活要少
简单的冲突
前台自己判断，或者 Worker 自己解决
一句话：能力可以很强，执行职责要有边界。
先公平地讲作者的动机：前台不执行、不拆解，是为了不被某件复杂的事占住，耽误处理别的消息，也避免任务上下文混进来。
我的不同意见：前台不该被严格限制成一个简单的分发器。比如一个项目有三个 Worker 在做三个 PR，可能出现代码冲突、技术依赖、优先级调整，甚至架构分歧。要识别这些，前台得懂一定的技术背景。
但「冲突一定要前台解决」也太绝对：（按 → 逐个）
简单的——改不同文件没冲突，或者普通的 merge 冲突——Worker 自己或前台顺手就能处理；
要长时间分析的——比如三个 PR 有架构层面的冲突——前台识别出来后，开一个专门做协调的 Worker，深入分析依赖和取舍，输出方案，前台继续接别的消息，不被卡住；
重大取舍——比如两个 PR 代表两种产品方向——带着证据交给人。
被问到「前台用强模型，会不会又变回单会话那样又慢又膨胀」：所以才要有第二级——复杂分析交给专门的协调 Worker，前台只负责识别和最后拍板。也要注意别每次都开新的协调 Worker，不然协调层级会越叠越多。延迟和成本到底增加多少，要实验验证。
补充：我们的看法是，前台的模型能力和它承担的职责是两回事。前台的模型能力和它承担的职责是两回事。前台要多强，取决于系统留给它多少判断空间。代码规则挡掉不用判断的、话题直送绕过它、Worker 交回来的结果格式固定（结论 / 前提 / 需要你决定的事），判断空间就被压小了，轻模型够用。反过来，如果它要从一团聊天里猜意图、处理跨任务冲突、决定要不要打扰人、把长报告压成一句话，就需要强模型。
还有一个常被忽略的成本是延迟：前台在每条消息的必经路上，它慢一点，人每说一句都要等。
所以折中是：默认轻量，低置信度、涉及对外或不可逆动作、要合并多个结果时，升级到强模型或者问人。原文把「为前台专门训练模型」列为开放方向。
拆多细？交接本身就有成本
一个两分钟的小改动
派给新会话
派单 加载背景 执行 汇报 转述
主会话顺手做
执行
拆太粗
得靠 Worker 够强，再加 Watchdog 兜底
每一次交接至少包括：前台写派单，新会话读入派单和背景，执行，汇报，前台再读结果转述给人。每多一轮，就多一轮 token 和等待。
所以有个下限：拆得太细，不如主会话顺手做掉。实验里「优先委派」的中位数 13.8 分钟和 Super-agent 接近，但长尾拉到 29 分钟，也说明委派与否本身是个要权衡的决定。
反过来，拆得粗，一个会话负责一件完整的事，交接少，但更依赖下层能力：自己规划、自己判断做完没有，偏了也没人知道。兜底就是两件：Worker 够强，加一个看进展的 Watchdog。
我们的原则：按完整任务拆，不按步骤拆；相关的后续回原会话，交接走代码固定的路径和固定格式。
顺带一个常见误解：每个任务开新会话不等于放弃缓存。提示缓存按前缀命中，固定的系统提示和项目背景在新会话里照样命中；用不上的只是上个任务积累的过程上下文，而这部分在单会话里本来就越滚越贵。
对照一下：Hive 和我们的 bot 团队
DeepSeek Super-agent Hive 开源 · 本地多 Agent 工作台 我们的 bot 团队 日常在跑 入口做什么 只派活，不拆解 规划、拆解、验收更像 Agent Team 只分活，不深挖、不写代码 后续消息 按话题，代码直送 经 Orchestrator 派单 经入口读一遍再转 卡住了谁发现 Watchdog 读内容判断 故意不做，人来判断 系统观察员，一天一次 跑在哪 云上循环 + 端上 daemon 本机，真实 CLI 进程 手机发指令，Mac 上执行
骨架很像；我们差在 直送、持续值守、主动性
这页拿我们自己做过的两样东西对照一下，点到为止，两分钟以内。
一句话：骨架很像，但取舍不同；我们的 bot 团队差在直送、持续值守和主动性。
（按 →）Hive：开源的本地多 Agent 工作台，把 Claude Code、Codex 这些 CLI 当成真实进程跑在本机，浏览器里看成一个团队。
- 它的 Orchestrator 是真实的 CLI 进程，负责规划、派单、对整体结果负责，还要验收——这更接近原文说的 Agent Team，而不是只派活的 Router。这不是缺点：Hive 面对的是「一个人当场带一个开发小队」，不是「常驻、事件驱动、多渠道」。
- 后续消息靠 Orchestrator 用 team send 派单、Worker 用 team report 汇报，没有按话题直送。
- 最有意思的一点：Hive 故意不做心跳和卡死检测。设计文档的理由是：长时间思考、慢构建和真卡死，从外面看一模一样，任何启发式要么误报要么漏报，所以由人判断、手动停或重启。运行时重启后也不自动拉起 Agent，因为在免审批权限下静默恢复风险太大。
- 和 DeepSeek 的 Watchdog 并不矛盾：Hive 拒绝的是「靠信号自动判定」，DeepSeek 做的是「让模型读工作内容来判断」。
（按 →）我们的 bot 团队：一个入口 bot 只分活，几个各管一摊的 bot 干活，交接写文件、不走聊天，对外动作（发消息、合并、删除）每次都等人点头。
- 对照 Super-agent，骨架几乎一一对应：入口≈Router，各 bot≈Worker，定时任务≈Trigger，共享文件≈外置状态，系统观察员≈Watchdog，手机发指令、Mac 上执行≈三分离。
- 差距：同一话题的后续消息还要经入口读一遍再转，没有直送；观察员一天看一次，不是持续值守；主动性弱，主要是定时做固定的活。
（按 →）还没解决的：一条不带上下文的新消息到底该归哪件事。
别说过头：不要说「我们早就做了 Super-agent」。DeepSeek 的增量在常驻、事件驱动、直送和状态外置这些运行层面的工程整合。
如果只记住三句话
1 瓶颈从模型，换到了人的注意力 原文
2 要它守的规矩，放进结构，别只写在 prompt 里 实验与原型
3 入口统一只是第一步，接下来是组织交互、减少决策 我们的看法
（按 → 一条条出）最后收一下，今天只想留下三句话。
一、瓶颈换了地方：单任务等模型，多任务等人。DeepSeek 的整套设计，都是为了少占人的注意力。
二、规矩放进结构：实验里靠 prompt 让模型「记得委派」，5 次里有 1 次没守住；原型里「先等人确认」只写在 prompt 里，也被人挑出了问题。前台不给 Bash、话题直送、权限由宿主强制，这些才是靠得住的。顺带一提，原型里几件马上能试的小事：接话的 Agent 不给干活的工具、后续消息按话题直送、IM 回复限长、主动先从「只记录」开始。
三、入口统一只是第一步：原文自己也把「没有会话之后人怎么协作」、上下文边界与 A2A、安全和凭证列为开放问题。我们觉得下一步值得做的，是怎么组织多任务交互、怎么减少人真正要拍板的事。
谢谢.
欢迎一起讨论
原文：DeepSeek Harness《Exploring Super-agent Design: Towards a More Autonomous Agent System》，2026-10-31
资料都在这两个链接里。原型的 docs 目录写得很清楚，推荐先看 000-philosophy。