Super-agent 的系统设计与证据链

《Super-agent 设计探索》是一篇质量不错的系统设计技术文章。它的价值在于把多任务 Agent 的工程经验组织成设计机制，并用消融实验和压力测试检查其中一部分判断；它尚未提供足以支持通用优越性的证据。

研究截止于 2026 年 11 月 2 日。本文分析 DeepSeek Harness 团队的《Super-agent 设计探索：迈向更自主的 Agent 系统》，并静态核对公开原型 v0.1.0、提交 6337fc8。文中的性能数字均为原作者报告，本文未重跑其调度实验，也未测量真实开发质量。

官方发布入口见知乎与微信公众号。本次未能直接取得这两个入口的正文，全文依据注明原作者的 ChainCatcher 转载与另一份全文转载核对；结果表另对照带“知乎 @DeepSeek”水印的原图。代码证据来自官方版本化仓库。下文将作者主张、代码事实、报告结果与本文判断分别说明。

一、它研究的是任务管理，而不只是增加几个 Agent

设想一个开发助手同时修复登录问题、开发导出功能、升级依赖。每项工作都可以交给独立子会话。主会话只维护全局进展，必要时转交追问，执行者分别调查代码和提交结果。这种用法本身已经接近 Super-agent 的双层架构。

原文第 2.1 节也承认：如果主会话不亲自执行，只负责交互与协调，不同工作由成员独立推进，这样的 Agent Team 也可以归入它所说的双层架构。因此，不能把“主 Agent 管理子会话”和“Super-agent”当作天然互斥的两种路线。

它进一步讨论的是：工作持续数小时乃至更久，群聊、评审与 CI 事件不断到达时，如何稳定地维护这种分工。Router 负责跨任务协调，Worker 保留单项工作的详细上下文；已知归属的后续事件可以直达执行者。开发、个人助理可以共享这层组织方式，但连接器、授权、任务语义和验收仍需逐场景设计。原文第 2、3 节

系统设计的贡献，不必是发明全新组件，也可以是找出一个有用的职责边界，并说明它在什么负载下成立。 但这种贡献需要与“已经有人用提示词实现了同样分工”相容，不能把现成做法包装成另一类系统才具备的能力。

二、从架构描述到可检验的假设

一张架构图只能表达组件关系。研究意味来自下一步：为什么要这样拆分，替代方案是什么，拆分之后预计改变哪个指标。

图 1｜本文绘制的分析框架。机制存在、实现可用与效果被验证，是不同层次的证据。图示不是原文实验结果。

Super-agent 的设计可以整理为以下假设。表中的“预期”是本文对机制的分析，不表示每项都已被作者实验证实。

工程问题	设计机制	可检验的预期	本文看到的证据
主会话偶尔亲自执行，持续被新消息打断	固定协调与执行职责	委派更稳定，任务耗时长尾缩短	有端到端比较，但对照和因果分离不充分
已知任务的后续事件仍重复路由	订阅与直通	Router 决定次数、推理开销下降	有单机制消融
事件突发，单 Router 出现积压	批量处理积压事件	请求耗时增长慢于批次大小	有 Router 压力测试
历史全量注入太贵，只给摘要又频繁补读	Inline & Spill、关联对象引用	降低读取成本，同时维持必要信息	有设计和代码，未见针对性效果实验
等待完整指令后才开始调查	投机执行	减少人的等待，增加后台算力消耗	有团队实践描述，未见量化收益与误触发率
进程仍存活，但 Agent 陷入无效循环	外部 Watchdog	缩短异常发现与恢复时间	有设计描述，未见故障注入评估

这张表也给出了阅读顺序：先找设计理由，再找预测，最后检查结果是否测到了预测。全文设计覆盖很广，实验验证只覆盖核心调度与路由的一部分。

三、“算法化”主要发生在职责与信息路径上

3.1 把确定关系交给程序，把不确定语义交给模型

事件接入后，系统先按来源、身份、接收范围等条件做程序检查，再让模型理解候选事件的意图。路由也采用类似分工：消息与某项工作的关系已经确定时，程序直接投递；需要开始新任务或跨任务协调时，再使用 Router。

可以将订阅路由抽象为下面的过程。这是本文为说明机制写的伪代码，不是原文新增的算法定义；公开代码还处理消息归属、停止、恢复与策略检查等细节。

接收并去重事件
查找其讨论串订阅的任务
向符合条件的任务投递上下文
已有执行者负责的人类后续消息：交给执行者处理
其余事件：按策略进入评估
执行者发现超出任务范围：交回路由层

这里的价值是减少重复语义判断，不是消除语义判断。订阅本身不能证明后续内容都属于原任务，也不能给外部评论增加授权。公开原型保留了 Worker 交回消息的路径。事件接入代码、Worker 接口

3.2 让上下文成为有预算的信息结构

Inline & Spill 把近期很可能需要的信息直接放进窗口，把长内容的剩余部分保存在窗口之外，并提供补读入口。链式召回则沿消息、讨论串、任务和会话之间的引用逐步读取历史。

这比笼统地说“使用长期记忆”更具体。公开实现中，主动评估的触发消息有长度上限，讨论窗口选取开头及消息附近内容，其他历史提供预览，截图和全文可以按需读取。关联任务卡片也限制展示数量。上下文组装代码

但它仍然是上下文组织策略，尚未通过本文所见实验确定最优窗口、截断长度或召回路径。要证明效果，需要同时测量读取成本与证据遗漏，不能只展示窗口变小了。

3.3 状态机把任务与会话分开

公开原型区分事件、讨论串、授权、任务和某次执行。任务可以跨重试持续存在，后续消息可以找回原负责人。SQLite 和持久化副作用队列保存待启动、待投递、待回复等操作；模型的会话历史不必独自承担所有任务管理状态。

这是一项工程贡献，不等于已证明长期可靠。公开目录和命令包装也不构成安全沙箱，外部动作的副作用不能仅凭本地队列就宣称严格只发生一次。领域模型、持久化队列

这些机制采用了协调者与执行者、快慢路径、发布订阅、缓存、批处理和外部控制回路等经典思想。文章的算法性主要体现在对象、路径和规则的具体化，没有提出新的学习算法、优化求解器或复杂度突破。简单机制仍可能产生好的系统研究，前提是证据能说明组合后的收益。

四、端到端比较：测到了分工不稳定，但没有排除更强基线

原文第 7.1 节用群聊和 GitHub CI 消息流驱动四种方案。每轮约 300 条消息，约 20 条为工作请求，其余包括闲聊、跟进、叫停和 CI 信息；每种方案重复五次。编码由只消耗时间的工具模拟，因此测试的是调度与协作，不是真实编码能力。

图注说明消息间隔与工作时长按四分之一缩放，模型调用耗时保持真实值。完成时间从工作请求发出算到结果消息返回；缩放改变了到达与执行时间相对于模型推理时间的比例，数字不应直接解释为真实开发任务的交付时间。

方案	P50 完成时间（分钟）	P95 完成时间（分钟）	每轮全部会话读缓存 token（万）
Super-agent	12.4	15.7	2323
Super-agent，去掉直通	12.6	15.5	3177
单主会话 + Subagent，中性提示	20.4	29.5	605
单主会话 + Subagent，优先委派提示	13.8	29.0	1082

P50 是中位数，P95 是第 95 百分位数，不是置信区间，也不是最慢任务。数值为作者的汇总报告；本文未取得逐轮日志，不能重算分位数或确定跨轮聚合细节。原始结果图

图 2｜依据原作者报告值重绘。圆点与方点分别表示 P50、P95，连接线不表示误差或置信区间。下半图独立展示缓存读取量；它不是总 token 或总费用。可下载数据及来源说明。

4.1 对照组不是没有 Subagent，而是没有稳定委派

中性提示允许模型在适当时使用 Subagent。作者报告五次运行都没有调用，工作集中在主会话中，并被新消息反复打断。

优先委派提示更明确地解释了中断问题，要求尽量把每项工作交给独立 Subagent，但仍允许主会话做小事。五次运行中四次进行了委派，另一次模型认为工作很小而自行执行，形成长尾。

这个发现支持一个有限且有用的判断：在该负载下，把协调与执行分工固定下来，比让模型临场决定是否委派表现更稳定。它并不支持“模型不会管理子 Agent”，更没有证明所有模型和宿主都会出现同样问题。实验正文

4.2 缺少的是“严格只协调”的强对照

更接近既有实践的基线应当是：主会话不配备执行能力，只做交互和协调，所有实质工作交给独立持久子会话；其事件输入、模型、工具、预算与 Super-agent 尽量一致。

原实验的优先委派组没有固定这一约束。因此，端到端差距可能混合了委派纪律、执行消息隔离及其他宿主机制的影响。它还没有独立回答：只要固定职责是否就足够，额外的任务管理机制又贡献了多少。

这不是认定作者故意选择弱对照。基线不足是一项方法限制，不能据此推断动机。尤其是作者第 2.1 节已将严格协调型 Agent Team 纳入双层架构，正确比较对象应该落到具体机制，不能只比较名称。

五、直通消融与批处理：更清楚的工程证据

5.1 直通节省协调开销，没有显示速度收益

完整方案与去掉直通的方案，P50、P95 几乎相同，不能将这项机制描述成已测出加速。但移除直通后，Router 决定数约增加 30%，读缓存 token 从每轮 2323 万变成 3177 万。

以完整方案为分母，移除直通增加约 36.8%；以无直通方案为分母，保留直通减少约 26.9%。两个百分比来自相同差值、不同分母，不应互换。

这比整套架构的端到端比较更接近单机制检验：预期是减少重复路由，观测指标也确实是判断次数和缓存读取量。它说明“无须反复推理的归属关系可以用程序缓存”。已经具备相同直通能力的其他 Agent 系统也能采用这一优化。

5.2 单 Router 的可行性需要压力测试

第 7.2 节让 Router 使用真实模型、Worker 使用 Mock 模型，将需要决定的事件从约每分钟 1 条提高到 40 条。平均批次大小从 1.0 增到 2.8，单次请求耗时从 2.5 秒增到 3.9 秒。合并更多输入的耗时增长慢于批次大小，说明批处理在测试负载中有助于消化积压。

作者还报告单个决定分摊的推理时间从 6.4 秒降到 1.6 秒。本文保留其独立指标口径，不将它强行等同于前述平均耗时除以平均批次大小；没有原始日志与完整计算定义，不能还原各项平均值之间的关系。

这支持“当前团队负载下不必过早拆分 Router”，而不是证明一个 Router 可以无限扩展。批处理还需要报告判断正确率、事件等待时间和饱和点：吞吐增加时，如果漏接和错误关联同步上升，就不能只看处理速度。原文第 7.2 节

六、技术文章的研究价值与证据缺口

系统研究不要求每个组件都是新发明。明确真实负载、职责边界、取舍与失败方式，再给出实现和实验，也可以构成有价值的贡献。Super-agent 做到了其中一部分，尤其是把宽泛的多 Agent 讨论落到了分工稳定性、重复路由开销和 Router 吞吐。

不过，文章开篇强调人的注意力是瓶颈，实验却没有直接测量人工介入次数、纠正耗时、重复通知或跨会话搬运信息的成本。完成时间更短，并不能自动证明更少打扰人。核心产品主张与现有指标之间仍有距离。

其他限制同样影响结论强度：五次运行的统计证据较薄；未提供足够信息重建完整实验配置与聚合过程；缓存读取量不是完整成本；模拟工作不覆盖真实代码冲突和返工。本文在所核对的公开原型中未找到与第 7 节对应的完整负载生成、运行和原始结果脚本，因此不能把“代码开源”直接写成“实验可复现”。

评价维度	本文判断	依据或限制
问题与权衡的表达	较好	连续交互、并行执行与协调成本之间的关系明确
机制的具体程度	较好	对象、订阅、补读入口、状态转换有可检查实现
算法与理论原创性	有限	主要迁移、组合经典系统思想
实验设计意识	明确存在	包含端到端比较、单机制消融和压力测试
因果解释与统计充分性	初步	强基线、控制变量、重复次数和原始数据仍不足
跨模型、真实工作流泛化	尚未建立	模拟负载无法代替真实开发评估
写作与工程学习价值	较高	可学习怎样把机制对应到预测和指标

因此，更合适的定位是“有初步研究方法的系统设计技术文章”，而非已经充分验证的通用架构论文。这是对当前材料的评价，不是对其是否能够发表或通过某个会议审稿的预测。

作者归属也需要准确：文章文末将系统实现与写作归于 Yujia Qiao，并列出团队审阅与讨论者；仓库 README 说明大量工程工作由 Coding Agent 完成。这不足以证明研究设计、论证和整篇文章都是 Agent 独立产出。官方 README

七、把相同方法用于自己的 Agent 系统

最值得复制的是研究步骤：从具体故障出发，提出能够被推翻的解释，选择最小机制，用实验排除替代解释。下面是一份针对本文证据缺口的后续实验建议，尚未执行。

7.1 先固定职责，再逐项增加机制

第一轮可以只比较三组：自由委派、优先委派、严格协调者。严格协调者不具备实质执行工具，所有工作交给相同能力的独立会话。这样可以先回答：结构性约束是否比提示词建议更可靠。

第二轮在严格协调者上，分别启用与禁用订阅直通、事件批处理，构成受控的组合实验。保持消息流、任务持续时间、模型版本、工具、并发上限、预算与失败重试设置一致，分别观察每个机制的贡献及其交互。若测试持久化恢复，应单独注入故障并检查副作用，不能由无故障调度实验推断恢复能力。

7.2 把工作量与风险分别测量

指标组	具体指标	回答的问题
完成表现	P50/P95 延迟、未完成率、吞吐、排队时长	做得是否及时
路由正确性	漏接、重复任务、错误关联、范围外执行	是否把事交对、做对
人的注意力	人工纠正次数、主动干预时间、无效通知数	是否确实减轻管理负担
完整成本	新输入、缓存读取、输出 token、机器与工具成本	为收益付出多少
恢复能力	丢失输入、重复外部动作、恢复时间	中断之后是否还能可信地继续

先用一小批事件检查负载生成、日志和评分是否正确，再预先确定正式运行次数与停止条件。保留每轮结果和失败原因，对相同负载做配对比较；成功委派与未委派的运行分别展示，避免平均值掩盖故障机制。最后再加入真实仓库任务，检查模拟结果能否保留。

7.3 技术文章应当留下可重建的路径

一篇可复核的系统设计文章至少应交代：真实问题、系统边界、替代方案、机制为何可能有效、可观测预测、实验控制条件、原始数据与计算方法、失败案例，以及结论不能扩展到哪里。

Super-agent 的启发在于，它让“主会话管进度、子会话做工作”从使用习惯变成了可以讨论、实现和测量的设计对象。进一步的研究价值，需要在更强的基线、真实任务和人的注意力指标上继续建立。对已经稳定采用相同分工的系统，是否值得迁移，应由新增机制的独立收益决定。

来源与复核材料

1. DeepSeek Harness 团队：《Super-agent 设计探索：迈向更自主的 Agent 系统》，2026-10-31。知乎发布入口、公众号发布入口。本次直接读取受限，正文通过注明原作者的转载交叉核对。
2. ChainCatcher 全文转载、月球基地全文转载。用作正文与图表核验，不将转载域名视为官方站点。
3. 官方原型 v0.1.0 固定提交、实现架构文档。代码检查不是运行实验。
4. 原始结果表、本文转录的数据与口径、本文图表生成源码。图表为本文确定性重绘，未重新发布原作者截图。
5. 相关背景：DeepSeek Harness 插件化架构与工程评估、分布式 Agent 个人助理：互通协议、委派管理与产品边界。两篇文章的研究时间与范围分别独立，不作为本次实验的替代证据。