原文：Super-agent 设计探索：迈向更自主的 Agent 系统（DeepSeek，知乎专栏，2026-10-31）

讨论：如何评价 Deepseek Harness 发布的 super-agent 构想？（知乎问题，390 个回答）

本文由我和 Claude Code 一起整理。前五节是原文和讨论的摘要，数字都出自原文；最后两节是我们结合 Enchanted 的看法。

DeepSeek Harness 团队在 10 月底发了一篇架构探讨，把“一个常驻的路由层，加一群上下文隔离的执行者”定为下一代 Agent 的骨架。知乎问题下赞数最高的回答，来自一位说自己做了半年、快完工时被这篇撞上的作者。我在做的 Enchanted / a2a 也走在这条路上，所以把原文、评论和自己的对照放在一起记下来。

一、DeepSeek 想解决什么

他们的判断是：单任务的上限已经取决于模型，多任务的上限却取决于人的注意力。一个人同时盯 3～5 个会话就到头了。所以要把“会话”从用户眼前拿掉，让用户面对的始终是同一个 Agent。会话应该是系统的实现细节，不该是用户要记住的东西。

他们给这个形态定了四个特征：

特征 含义
连续 在 IM 里说方案 A、在 PR 评论里改成 B，它能接上，用户不用想“哪个会话知道这件事”
高效 上一件事没做完也能接下一条指令，多个复杂任务并行
主动 持续看环境事件，值得做就推进，不需要就安静
持久 始终在线，接真实工作环境，出了异常自己恢复

名字里的 super- 是 sub- 的反义：subagent 是在主 Agent 下面加一层，super-agent 是在上面加一层。这是 DeepSeek 产品部崔添翼在回答里专门解释的。

二、五个模块

模块 做法 借来的系统思想
双层架构 Router 管全局连续性和对外回复，不干具体活，甚至可以不给 Bash；Worker 隔离上下文、用最强模型干活，不直接对人说话。Router 是单个常驻会话，积压的事件下一轮合并处理 序点、批处理
事件驱动 程序过滤加模型判断两级；同一 PR、同一话题构成 Thread，已认领的 Thread 后续事件直接送到订阅它的 Worker；上下文里只放 ID 和摘要，沿 ID 一跳一跳召回（链式召回）；后台投机执行，比如群里有人报问题就静默复现修复，修不出来就不出声 Fast/Slow Path、Cache、局部性、投机执行
面向人的交互 耗时工具改成异步 start/stop，前台随时能接新消息；IM 回复不超过 100 词，GitHub 和邮件给结构化长文 全双工
计算、状态、环境分离 Agent Loop 无状态放云端，会话存数据库；执行环境留在用户机器上，端侧只装轻量 daemon 存算分离，与 Anthropic 的“脑手分离”同路
Watchdog 主系统之外、定时唤醒的独立会话，检查 Worker 有没有实质进展、有没有跑偏；维护者可以用自然语言让它在线改提示词和触发规则 Control Loop

三、实验里最该看的一条

实验用约 300 条混合消息驱动，其中约 20 条是真正的工作请求。编码工作用一个只耗时间的假工具代替，所以测的是调度，不是干活能力。每种方案跑 5 次。

方案 结果
Super-agent p50 12.4 分钟，p95 15.7 分钟
单会话加 subagent 工具，中性提示 5 次里一次都没委派，主会话自己干，不断被新消息打断，p95 29.5 分钟
单会话加 subagent 工具，提示“优先委派” 5 次里 4 次委派；剩下 1 次模型觉得活“很小”自己做了，形成长尾
去掉直通的 Super-agent 完成时间几乎不变，但 Router 的决定数多了约 30%，读缓存 token 从 2323 万涨到 3177 万（约 +37%）

Router 单独压测：事件到达速率从每分钟约 1 条升到约 40 条，平均 batch 从 1.0 升到 2.8，单次请求从 2.5 秒升到 3.9 秒，每个决定分摊的推理时间反而从 6.4 秒降到 1.6 秒。

最有分量的是第二、三行：分不分工，只要还交给模型临场判断，它就会退回去自己干。 双层架构把这件事从提示词挪到了结构里。

作者自己也说明了这是合成负载、简化环境，只作初步参考。文章最后列了四个开放问题：双层架构怎么扩展、脱离会话以后人怎么协作、上下文边界与 A2A、安全与隐私（云端一旦被入侵或注入，连着的所有端侧设备都有风险）。

四、某科学的仙人仉：灵魂不在实现

这条回答有 5000 多赞，比官方回答还高。作者从春天起在做一套 harness，快完工时撞上了这篇。他认为高赞回答都在拆事件驱动、全双工、存算分离，这些信息增量很小，真正的变化在思想层面。我把他的意思归纳成六点：

  1. 从“面向过程”到“面向对象”。 大厂招人不只是为了省 leader 的时间，更是为了让 leader 的上下文不被脏细节填满。LLM 做不了大项目，根因是它亲自经历每一个实现过程，认知负荷被细节占满。
  2. 主 agent 永远不碰具体工作。 任何具体工作都开一个 subagent，只给它写验收标准；做完留下报告和产物，释放线程，留一份短文档。主 agent 只面向需求和用户，管项目状态。
  3. 一切皆 agent。 每个具体过程一个 subagent，每个复杂需求一个 leader agent。人的工作是写好需求文档和验收标准，并教 leader 怎么写。子任务太大时，subagent 可以升格成“部门 leader”继续往下派，形成自组织的公司结构。
  4. 必须在架构上强制，不能靠提示词。 他 7 月用 GPT 5.6 sol 做的实验，结论和原文 7.1 几乎一样：中性提示下不委派，强调委派也有长尾。subagent 要做一等公民，不能只是一个可选工具。他也补充说 6.1 sol 的指令遵循提高了，小样本下优化提示词已经能做得不错，但长期重型任务还不够。
  5. 上下级严格强于平级。 平级 multi-agent 多数只是把一个任务采样 N 次再汇总，增加的是吞吐和多样性；上下级 subagent 改变的是上下文拓扑：长期的高层上下文，派出临时的局部上下文，产出产物，再压缩回流。人的组织结构本身就是一种上下文拓扑。
  6. 真正难的是状态管理。 只靠提示词能做一部分，要撑住长期重型任务，需要独立的状态管理系统和脚本。他打算整理后开源成插件，再写一篇讲状态管理。他也提到，评论区很多人做的只是普通的 subagent 或平级 multiagent，和这里说的不是一回事。

五、其他回答：赞同、补充与反对

崔添翼（DeepSeek 产品部，官方回答）：承认没有新理论，这套架构在前沿团队里基本是共识，好几个团队几个月前就试过。做双层的动机是长程记忆一直没有公认的方案，所以“跨任务的连续性”和“吞吐量”成了一对根本取舍。原型只在公司内小规模、受信任的环境里跑通。

酱紫君（最有力的反对）：

  • 常驻 Router 在他的实践里做不到：用户打断越多，模型注意力越散，指令遵从越差，最后还是要人手动开新会话“GC”。
  • Router 用轻量模型是错的。在插队频繁的个人场景里，排优先级恰恰最需要旗舰模型。
  • 链式召回有“二跳现象”：有的模型第二跳就停，靠幻觉做决定；有的过度跳转，把上下文刷爆。
  • 他的替代做法叫 Inline or Never：每个概念或决策的全部解释都在一个 markdown 文件里，Agent 只读这个文件，不再搜索；文档只追加，由最强的模型定期消歧和压缩。
  • 他还主张模型按岗位分化：一个模型负责传话、整理卷宗，一个负责挑刺、列计划，干活交给几个 Flash 级模型随机轮换。

Kitt在进化：观察到很多人已经把 Personal Agent 当监工，不直接跟 Claude Code 或 Codex 说话，下面再分规划、拆解、执行三层。他认为 Super-agent 可能真会成为新范式。

程墨Morgan 打了个比方：Claude Code 的 subagent 像 tech lead 带实习生，上下文全由 lead 喂；Super-agent 的 Router 像项目经理，Worker 像会自己顺着线头找上下文的老员工。

文章评论区：有人建议加一个 workspace：验收时发现不对、简单反馈又解决不了，人要能进到这个任务的全部上下文里手动修，作为降级路径。也有人问，自主性提高以后，成本和幻觉怎么平衡。

六、对照：Enchanted 已经有什么

下表按 Enchanted 现在的设计对照。“有”指设计里有，不代表每一项都已经在新的终端运行时上重新取得证据。

Super-agent Enchanted / a2a 状态
Router 不干具体活 构思主控对用户，执行主控派发；worker 在受管任务里干活。但现在有一批建造票是主控在自己的会话里直接写的 部分
Worker 隔离上下文、只回报结论 受管任务加任务卡加独立 worktree；每次交付新开一个只读审查会话 有，而且更强
Worker 交回的结果怎么算数 原文基本没谈。Enchanted 有一串门禁检查：身份与版本、路径边界、验收文件不能被改、红态、独立审查、提交尾注，全过才集成 Enchanted 独有
两级过滤 Fast / Slow Path “提示词管判断，脚本管事实” 同一个思想
Thread 订阅直通 用户可以直接在 worker 窗格里输入，记为人工介入；问题上报直接推给执行主控 部分
ID 加摘要、链式召回 任务 ID、attempt、启动记录号、A2A-* 提交尾注已经构成一张引用图；主控靠项目地图和 ticket 恢复状态，不靠对话历史 有图，缺召回工具
异步、全双工 派发写进窗格，完成后唤醒主控；终端用结构化信号报告状态 有
计算与状态分离 编排后台常驻，界面关掉 agent 也不停；后台重启后接回原来的 attempt。本地优先，不上云 本地版
Watchdog monitor 只读观察、报警；上报的问题 15 分钟没人处理就进入“等你决定” 有，权限更窄
外部事件（IM、GitHub、CI）驱动 还没有接外部信道 没有
投机执行、静默修复 和“不自动 push、重大决定停下来问人”冲突 不照搬
安全与隐私（原文的开放问题） 权限只在工作台内、不写全局配置、门禁兜底、验收文件受保护 走在前面
A2A（原文的开放问题） 就是内核的名字 只在一个实例内

七、我们的看法

1. 方向被外部证据支持了，Enchanted 还多走了一步

Enchanted 的第一个目标是：让协作不依赖模型持续记住操作手册。原文 7.1 和仙人仉的实验说的是同一件事：靠提示词让模型自觉分工，它会退回去自己干。Enchanted 从一开始就把认领、交付、验收、集成放进门禁，这是同一个结论更早、更硬的版本。

更重要的是，原文和几乎所有评论都把注意力放在“怎么分派”上，没有人认真回答“Worker 交回来的东西凭什么算数”。仙人仉也只提了一句“只写验收标准”。Enchanted 的任务卡、验收文件保护、红态检查和独立审查会话，补的正是这一块。所以我想这样概括两者的区别：Super-agent 管分派，Enchanted 管分派之后的验收。

2. 最大的风险，是主控自己在干活

Enchanted 现在有一批建造票是主控直接在会话里写的，因为新的终端运行时还没接好，没法经工作台派发。这和原文实验里“主会话决定自己做”的那条长尾是同一种形态，也就是仙人仉说的“退回面向过程”。理由是成立的，但这样会让主控的上下文被细节填满，而且这种安排没有明确的结束时间。

有两件事可以做，都符合“脚本管事实”：给这个例外写明结束条件，比如受管窗格换到新运行时、旧的基线测试恢复之后，就改回派发；再让门禁把“主控会话里产生、没有受管任务尾注的提交”记成一条可查的事实，在复盘里显示出来。不拦截，只让它被看见。

3. Router 用什么模型，我们同意酱紫君

原文说 Router 用轻量模型就够，是因为他们的 Router 主要判断“这条消息归谁”。Enchanted 的执行主控要判断范围、读验收结果、决定什么时候停下来问人；构思主控要把想法写成 ticket。这些都是最吃判断力的环节，两个主控应该继续用旗舰模型。轻量模型更适合放在问题上报的初筛、复盘初稿这种位置。

4. 常驻 Router 会变迟钝，Enchanted 的设计已经解决了一半

酱紫君说长期会话要手动“GC”。Enchanted 里有现成的出口：主控从项目地图、ticket 和收件箱恢复状态，不靠对话历史；主控身份绑定终端，终端关了身份就结束。所以主控随时可以换一个干净的会话接班。下一步可以把“主控换班”当成例行操作，而不是出了问题才做的补救。

他的 Inline or Never 和只追加文档，几乎就是 Enchanted 的 .project-map、追加式收件箱和术语表。这一点 Enchanted 已经领先了。

5. 链式召回可以做，但要配上门禁的 ID

Enchanted 已经有的任务 ID、attempt、启动记录和提交尾注就是一张引用图，缺的是一个给主控用的只读命令：给一个 ID，返回摘要和下一跳的 ID。这比让主控自己翻日志更省上下文。为了避开二跳问题，返回内容里最好直接带上结论（通过、拒绝、原因），让模型不必跳到底才知道结果。

6. 仙人仉的“递归升格”，现在先别做

让 worker 自己升格成部门 leader 继续往下派，每一层都要有门禁、attempt 绑定和尾注，追溯的复杂度会翻倍。在 Enchanted 里更稳的做法是：worker 发现活太大，就走问题上报，请执行主控拆票；层级保持一层，所有派发都经过同一个门禁入口。等单层稳定以后再考虑。

7. 不该照搬的

  • 云端 Agent Loop 加端侧 daemon。 Enchanted 是本地优先；原文自己也承认，这一层的安全问题还没解决。
  • 在群聊里静默复现、自动提 PR。 这和“不自动 push、重大决定停下来问人”冲突。将来接 GitHub 事件，也应该是事件生成受管任务、过门禁、等人批准。
  • 能在线改提示词和触发规则的 Watchdog。 Enchanted 的 monitor 只读，这是对的；改规则应该回到主控和人。

8. 可能值得排进路线图的

  • 外部事件进来变成受管任务，比如 GitHub PR 评论、CI 失败。四个特征里的“主动”，是 Enchanted 目前完全没有的一项。
  • 评论区说的 workspace 降级。 验收不通过时，一键打开这个任务的 worktree、审查报告和原生会话。Enchanted 的“项目 → 任务 → agent 会话”结构和深度链接已经很接近了。
  • 做一次自己的 7.1 式对照实验。 同一批 ticket，主控亲自写和经门禁派发各做一遍，比较完成时间、返工次数和主控的上下文用量。我们一直要求收益主张必须有独立对照，这正好可以是第一次。