10 月 31 日晚，DeepSeek Harness 团队发了一篇长文，叫《Super-agent 设计探索：迈向更自主的 Agent 系统》，同时把原型代码放上了 GitHub。
仓库名叫 dsh-superagent-prototype，MIT 协议，TypeScript，两天 star 涨到八千左右，冲上 GitHub 日榜第一。彭博社的定性很直接：这是冲着 Claude Code 来的。
但如果你只把这当成“DeepSeek 又开源了个 Agent 框架”，你会错过它真正的野心。
因为这次发布的不是模型、不是跑分、也不是一个产品，而是一份关于「人该被系统管到什么程度」的架构答案。
一、一个反常识的诊断：瓶颈不在模型，在人
DeepSeek 在文章开头抛了一个观察，我认为是整篇文章最值钱的一句：
随着模型能力提升，AI 完成单个任务越来越不需要人工干预。但人类管理多任务的注意力并没有同步增长——一个人通常只能同时跟进 3 到 5 个活跃会话。
所以真正的瓶颈，正在从“模型能力”转向“人的注意力”。
这个诊断可以解释你最近可能已经感受到的一种别扭。程序员现在能同时开好几个 Coding Agent，分别做需求开发、代码审查、测试和文档。模型的执行能力确实变强了，但人类不得不在不同窗口之间来回切换：查进度、处理报错、回答问题、决定下一步。
原本是为了减轻负担的 AI，某种程度上又制造出了一份新工作——管理 AI。
一个人指挥十几个 Agent 的时候，真正限制生产力的已经不是模型能写多少代码，而是人类还有多少精力盯着它们。
注意这个诊断和市面上主流 Agent 的分岔。主流做法是继续增强单会话能力——更好的工具、更好的推理、更多的上下文窗口。而 DeepSeek 选择换问题：既然单个会话的边际收益在递减，那能不能让“会话”这件事本身从用户面前消失？
它的答案是：Session 应该成为系统的实现细节，而不是用户的认知负担。
二、把六十年的计算机系统思想，搬进 Agent 里
Super-agent 的架构可以概括成一句话：把会话管理和上下文同步，从人手上移到系统层面。
具体是五个模块。但真正值得看的不是模块本身，是它们背后的思维惯性——DeepSeek 团队没有在发明 AI 专用架构，他们是把计算机系统几十年前解决过的问题，重新拿来用了一遍。
双层架构：一个分派，一个干活
第一层是常驻的 Router（路由层），负责承接所有入口的人类交互、汇总跨任务信息、做分派。第二层是 Worker（执行层），各自上下文隔离，挂载完整工具，并行干具体活。
关键设计是：Router 不干活。 它只负责交互和分派，甚至可以不配 Bash 工具。这是为了防止这个全局节点变成性能瓶颈——所有跨任务的信息都在它这儿汇总，它是全局序点、协调点和记忆，但它不执行。
团队的实际经验是：Router 层的任务往往没想象中美，用较轻量的模型就能兼顾速度和效果。
Worker 层同理，只干活不抢话。它的推理过程和工具调用不直接输出到外部信道，只向 Router 汇报状态，由 Router 统一回复用户。多个 Worker 同时推进时，同层之间通常不需要直接通信；冲突多发生在同一个 Pull Request 这种共享环境里，而只要它们都订阅了对应的 Thread，就会收到同样的事件通知，有机会自己发现冲突。
这里有个细节我觉得比架构图更有意思：DeepSeek 团队说，如果通过提示词去约束一个普通 Agent Team 的主会话不亲自执行、只负责分派，也可以视为这种双层架构。它主动指出自己这个设计和 Agent Team 的边界是模糊的——这说明它关心的是设计约束，不是自己的独创。
事件驱动：不等指令，环境事件当输入
Super-agent 里，驱动 Agent 的不再是人类逐条敲的提示词，而是环境中的半结构化事件——DeepSeek 称之为 Trigger：群聊消息、邮件与日程提醒、代码审查评论、CI 运行结果。
其中一个决策我认为非常聪明：两级过滤。
接入真实群聊后你会发现事件流是“高噪音、低触发率”的，绝大多数日常消息根本不需要 AI 介入。如果每条消息都调大模型从头判断，延迟和算力都撑不住。
所以借鉴计算机里的 Fast Path / Slow Path：程序规则先筛（按事件来源、群组范围、白名单等确定性条件直接准入检查），大模型再慢判（通过程序的候选事件才交给模型判断要不要行动）。语义层还留了个口子——提示词就是面向人的扩展点，随时可以开关或加策略。
而路由上有个更精巧的操作，叫订阅与直通：
同一个 GitHub PR、同一个 IM 话题、同一条邮件串下的连续事件，构成一条事件流，叫 Thread。Worker 接手后，会直接订阅这条 Thread。此后该 Thread 上的新评论由程序直接发给它，不再绕 Router。
这不是可选优化，是成本结构的关键。数据后面会讲。
上下文管理：把窗口当缓存管
这部分是全篇技术含量最高的地方。DeepSeek 借了编译优化和操作系统的“局部性”思想，提出两个操作：
Inline 是把近期很可能用到的信息直接内联进上下文窗口，省掉额外的工具调用往返；Spill 是把超出预算或低频使用的内容留在窗口之外，只留引用或摘要，模型按需再读。
原文有一句话很值得抄下来：「浪费上下文窗口，就是浪费模型的智能。」
更妙的是链式召回。系统给 Trigger、Thread、Worker 都赋予唯一 ID，注入时内联紧密关联对象的 ID，于是这些对象在底层构成一张引用图。模型从当前事件出发，顺着引用关系按需展开：从消息找到所在 Thread，再从 Thread 找到 Worker，再从 Worker 找到它关联的另一个评审 Thread。
这解决了 Router 的一个真实困境：它不能把全部任务历史都塞进窗口，但用户跨信道提起一个旧任务时，它必须能把上下文找回来。
投机执行：不说话比说话重要
借鉴 CPU 的投机执行：结果是否会被采用尚不确定时，先在后台提前尝试，有价值再提交，没有就丢弃。
DeepSeek 内部配置了一条「静默复现并修复」策略：群里有人反馈 Bug 或讨论方案时，Agent 先在后台复现、找原因，只有在确认问题存在且找到简单修复方案后，才把结果交付出来，否则全程保持安静。
这跟“AI 主动干活”给人的直觉印象正好相反。真正的主动性不是话多，而是知道什么时候闭嘴。
存算分离与 Watchdog：让它一直活着
现在的本地 Agent 默认把三件事绑在同一台设备上：推进 Agent Loop 的计算、持久化的会话状态、以及代码仓库和工具链。于是设备一休眠，Agent 就停了。
Super-agent 分两步拆开：先把计算和会话状态分离（云端跑 Loop，状态存数据库，本地只留一个轻量 daemon），再把云端 Loop 和重状态执行环境解耦（真实工作环境留在原地，支持 BYOM——把用户日常的开发机接进云端 Agent）。这跟 Anthropic 提的「脑手分离」思路一致，但场景不同：Anthropic 讲的是托管服务，这里首先要接的是用户日常使用、可能间歇在线的个人机器，上面有未提交修改和本地凭据。
然后是 Watchdog。它的存在理由很实在：传统进程存活探测不够用，因为 Agent 的很多异常不是崩溃，而是模型在执行中陷入无效循环或偏离目标。所以 Watchdog 不只看进程活不活，它由模型判断每个 Worker 有没有实质进展、方向是否偏离整体目标，发现异常就介入修复。
而且因为 Watchdog 本身就是一个完整工具能力的 Agent，维护者可以直接用自然语言问它故障原因，也能让它在线修正主系统行为——比如增删提示词、调整触发规则。
用一个 AI 来看着一群 AI，这是整个架构里最科幻也最实用的一层。
三、几个数字，以及它们没说的另一半
DeepSeek 给了实验数据。实验用群聊和 GitHub CI 消息流驱动四种方案，单次约 300 条消息、其中约 20 条工作请求，编码工作用只耗时工具代替，每种跑 5 次。
速度方面：Super-agent 的 p50 是 12.4 分钟，p95 是 15.7 分钟（p50 即中位数，p95 是 95% 的任务能在这个时间内完成，衡量的是最慢的那一截）。作为对照的「带 Subagent 工具的单 Session」，在中性提示下 5 次运行一次都没调用 Subagent——全在主 Session 里干，不断被新消息打断——p95 达到 29.5 分钟。
这里有个值得玩味的数据。DeepSeek 试过改提示词、让对照组优先委派：p50 从 20 分钟提到了 14 分钟，但 p95 还是卡在 29 分钟，剩下一次是模型判断工作“很小”自己执行，形成长尾。
这句话值得记住：提示词救不了调度，这种事得靠系统设计。
成本方面，团队自己的说法是「用更多 Token 换更短、更稳的完成时间」。
这句话本身没错，但它只说了半句。另外半句是：Super-agent 的读缓存 Token 是 2323 万，单会话基线是 605 万，大约 3.84 倍。
还有一组消融数据：去掉订阅直通机制之后，完成时间基本一致，但 Router 决定数增加约 30%，读缓存 Token 从 2323 万增到 3177 万，增幅约 37%。
这说明订阅直通不是锦上添花的优化，而是控制成本的关键结构。 一旦取消，Router 要重新处理每一条后续事件，Token 立刻往上走。
还有一个数字容易被忽略：Router 批处理能把单个决定分摊的推理时间从 6.4 秒降到 1.6 秒（平均 batch 从 1.0 升到 2.8，单次请求耗时只从 2.5 秒增到 3.9 秒）。
这个优化降低的是延迟，不是 Token。速度收益和成本代价，是两个账本。
而且这套数据还必须打折看。DeepSeek 自己在文里写明：实验基于合成负载与简化环境，部分设置还可更严谨，仅作初步参考。公开原型也没有发布任何基准、成功率或成本数字。
所以更准确的说法是：这不是“Super-agent 比单会话快”，而是“在一次合成负载实验里，多层调度换来了更短的尾延迟，代价是近四倍缓存读取”。
四、真正的对手，以及它自己承认的四个未解问题
彭博社说这套东西是冲着 Claude Code 去的，这个判断有依据。
Claude Code 是待在你的终端里，等你下指令。Super-agent 是坐在团队群里，不用 @ 它，它自己识别缺陷、后台复现、提交修复 PR。
形态差异比模型差异更重要。 一个在你编辑器里，一个在你的同事群里。后者能做的事，前者天然做不到。
而 DeepSeek 团队本身的定位也很清醒——文章结语明确说：他们并没有提出全新的理论，而是把任务调度、缓存管理、事件驱动、存算分离等经典计算机系统思想应用到 Agent 架构中。 文章标题里那个「设计探索」，是认真的。
但架构跑得再漂亮，也掩盖不了他们自己列出的四道坎：
一，双层架构如何扩展。 单 Router 承载超限后何时切分、粒度如何、Worker 之间何时直接通信，都没有定论。跨月长程记忆也是瓶颈。
二，脱离 Session 后如何协作。 聊天窗口未必是最终形态，交互可以更多发生在 GitHub 这类领域界面，还需要支持用户中途介入、接管与实时协同。
三，组织扩大后如何划分上下文边界。 多个隔离实例之间的 A2A 通信与协作，待探索。
四，安全与隐私。 这条最要紧，后面单独说。
值得注意的是第一道坎里那句「在全局记忆问题被解决前，这一权衡始终存在」——切分粒度越细，吞吐越高，但分片之间的记忆连续性越低。这和上个月 Buddy One 那篇里“记忆层”的问题其实是同一个：Agent 时代最难的不是算力，是上下文归谁管。
五、真正的风险不在模型，在权限
这一节我要写得具体些，因为它是这次发布里最容易被忽略、也最该被讲清楚的部分。
Super-agent 的 Worker 有独立的会话和独立的工作目录。文件层面，一个 Worker 改的东西和另一个 Worker 改的东西是分开的。
但这只是「文件去哪儿」的隔离，不是「进程能碰到什么」的隔离。
仓库的部署文档写得很直白：worker 和 router 预设都以 danger-full-access 在操作者的 OS 账户下运行；账户包装器（gh-agent、lark-bot 这类）只切换默认身份，并不隔离进程。一个 Worker 可以按绝对路径执行程序，也可以读取操作者的 home 目录。
文档里还有一句更狠的：目录和命令名拦截是默认值，不是安全边界。
那么问题来了：官方推荐给 Agent 单独开一个 GitHub 账户。这个建议的出发点是对的——Agent 提的 PR、留的评论用独立身份，不跟你的个人账户混在一起。但要注意，GitHub 账户只切了「对外身份」，没有切「执行进程的操作系统权限」。
有位开发者在分析里给出了我认为最准确的一句概括：独立工作目录解决的是「Agent 之间不打架」，不解决「Agent 能碰到什么」。
而 OpenAI 内部正在做的那 50 PB 日志审查、以及最近一个多月全球集中出现的「给智能体造笼子」热潮，指向的是同一个问题。智能体需要的权限等级，正在接近它能造成的破坏等级。
所以官方文档给出的隔离办法其实相当土，但也相当有效：另开一个只放 agent 凭据的 OS 账号。社区里还总结出几条别乱开的清单——日常账号裸跑、白名单全开、过早 auto、个人 gh 凭据暴露、误选 worker 预设、面板端口暴露到公网。
顺带一提，最小权限设计其实体现在产品里：默认 accept mode 是 observe——对推断出来的候选任务，只记录「本来会接」，不真接。三种模式 off / observe / auto，observe 是默认。官方还明确写了消息、评论、引用文档都只是输入，永远不构成权限变更。
还有几条硬限制：Shell 命令 5 秒超时，后台任务每轮 30 分钟，状态存在单个 SQLite 文件里。GitHub 侧，agent 必须是真人用户账号（GitHub App 当不了，因为要读该账号的 notifications），只支持 github.com（企业版 Server 直接说不支持），只有新 Issue 和新评论里的提及才会进入下一轮轮询（去改旧正文补一个 @，它当没看见）。
这些设计细节比任何架构图都更能说明这套东西的成熟度。 一个真正想让 AI 半夜自己干活的产品，必然要在权限上保守——否则没人敢让它半夜干活。
六、几件对开发者有实际用的事
如果你是开发者，想试的话有几个实操结论。
别在日常账号上裸跑。 单独开 OS 账号、单独开 GitHub 账号、单独开一个 profile（superagent 插件会改进程级的 PATH 和 git 设置，所以不要装在日常 profile 里）。
先 observe 一周。 官方哲学写在 docs/000-philosophy.md 第一句：尽量少占人的注意力，尽量多给可用结果。先让它只看不碰，看一周它「本来会接哪些单」，比第一天就 auto 更接近这个哲学。
auto-merge 有硬条件。 默认只允许 PR 是为该 Ticket 开的、状态为 ready、有 required approvals 且覆盖 head commit、增删行数少于 200。而且 Agent 永远不能用自己的账号开启 auto-merge——因为 GitHub 把合并归因于开启它的那个账号。所以官方文档建议用第二个账号的 CLI 来做这件事，并强烈建议用 GitHub branch protection 在服务端强制同样的条件。
升级前备份 orchestrator.sqlite。 新版本数据库打不开旧版本。
最后说一句社区里出现的两种反应，因为它们比官方叙述更能说明这套东西的价值和局限。
一种来自技术圈，看法是正面的：把事件驱动架构引入 Agent，用 Thread 组织事件、让不同数据源并行处理，这个思路可以类比 Linux 的 epoll；异步 ReAct Loop 也不是 DeepSeek 独创——有人早在 2025 年初就提过异步 ReAct，GPT-6 已原生支持异步工具，这次算是终于在工程实践里落地了。
另一种是质疑：这套架构混合了太多不同来源的设计思路，很难判断哪些真正提升了性能、哪些只是增加了负担。Router + Worker 未必是最佳实践——对于一个简单交互，为什么还要经过 Router 分给 Worker、Worker 再返回 Router、最后才反馈给用户？
我认为这个质疑是成立的，也是最值得你带着去读原文的：这套架构的收益不是线性的。 它在“多任务并发 + 长时运行”这个场景里收益巨大，在简单交互里就是纯粹的调度开销。DeepSeek 自己也承认不同场景会有不同变体。
有开发团队在 issue 里明确说他们故意不跟——不会把「永久 observe、永远窄名单」当终态气质，也拒绝「一工单绑一条长寿 Session」，因为长上下文会 compact、任务做到一半死掉，所以改用 fresh-context 的定时班次。
能公开写出「我们保持不同」的团队，比只会转发 star 的人更值得听。
结尾
DeepSeek 这次开源的不是产品，是一份架构作业。
但它提出的那个诊断是真实的：当一个人只能同时盯住 3 到 5 个会话，而 AI 可以同时干十件事，被卡住的就不是模型，是人。
过去一年所有 Agent 产品的迭代方向都是“让它更会干活”。DeepSeek 这次换了个方向：让它干活的时候，你少点几下屏幕。
这件事的代价写在实验数据里——近四倍的缓存读取 Token，更长的工作区，更重的权限要求。这个交换划不划算，取决于你的任务密度和 token 单价。
但有一点是确定的：AI 时代的管理者，不是那个最会写提示词的人，是那个最早把管理动作从自己身上卸下来的人。
DeepSeek 内部的那个实例，已经在他们的日常研发里跑着，修 bug、响应代码审查、参与 Harness 自身的迭代。
而你手上那个开源原型，还只是一个原型。README 里那句英文写着：这段代码是从我们团队的日常开发工作里长出来的，其中相当一部分工程工作是由编码 Agent 完成的。
一个宣称 AI 能自己找 bug、自己提 PR 的项目，主体代码是 AI 写的。
这件事本身，也许比任何一项技术细节都更值得记住。