一、关于本报告

本报告的分析对象是 DeepSeek Harness 团队于 2026 年 10 月 31 日发布的《Super-agent 设计探索：迈向更自主的 Agent 系统》，以及该文公开的两组实验数据。文中凡称「原文」，均指该篇；凡称「复算」，均指本报告依据原文公开数据所做的重新计算，公式在正文中给出，读者可以自行核对。

本报告不评价该团队的产品，也不评价其模型能力。原文是一份架构说明，其中同时包含设计主张、工程简化与初步实验三类内容。本报告将这三类内容分开处理：设计主张按逻辑检验，工程简化按其自陈的边界处理，实验数据按可复算的口径重算。

1.1 证据分级

报告中的每一条判断标注来源等级，以便读者判断其可靠程度。

  • E1：原文明确陈述，可逐字核对。
  • E2：由原文公开数据直接复算，公式见正文。
  • E3：本院推算，依赖正文标明的假设。
  • E4：外部公开文献，注明出处，检索日期为 2026 年 10 月 31 日。

复算遵循两条纪律。其一，不引入原文未披露的数据来补全结论；材料不足时，写入文末的待核实清单，不在正文中给出替代读数。其二，自行推算的数字不与来源数字混排在同一结论中，凡属推算，均单独标注。

1.2 与既有讨论的关系

这份架构说明发布当日即形成了密集的转述层。IT之家、驱动中国、观点网、读懂AI时代、同花顺等媒体在数小时内发出要点摘编，标题高度接近，内容集中于「Router 与 Worker 双层架构」「四个特征」「五个模块」三组标签。这一层信息重复度很高，不构成独立分析。

在此之上，已经出现一类技术评论。比较有代表性的一种意见认为，并发不等于协作，调度也不等于编排；原文把复杂工程所需的分支、并行、结果合并、动态重规划与交叉验收下沉到 Worker 内部，原有的困难并未被解决，只是被移到了下一层。这一判断成立，本报告不再重复，但在第五章给出一个更具体的机制解释：问题的根源在于 Router 同时承担了路由与全局记忆两项扩展性冲突的职责。

操作系统类比在 2025 年至 2026 年已经是成熟话题。把上下文窗口视为内存、把检索增强视为换页、把上下文溢出视为颠簸，这一组对应关系在 LLMOS、AgentOS、vMem 等一批工作中被反复讨论，并有若干开源实现按此建模。原文与这些工作共享同一套隐喻。本报告因此不把这个类比当作新颖见解，而是反过来把它当作检验工具使用，在第六章指出这一类比在四处失效，并给出失效所要求的原语。

「验证带宽是真正的约束」这一判断，同样已经在经济学文献中被系统提出。Catalini、Hui 与 Wu 在《Some Simple Economics of AGI》中把验证带宽建模为与自动化成本赛跑的第二条曲线，并给出「可测性缺口」这一概念：当执行成本指数下降而验证成本受生理与组织边界约束时，两者的差额会持续扩大。本报告第八节以此为前提，增量不在于提出这一约束，而在于按验收延迟把应用场景切成三类，并说明原文架构只在其中一类成立。

「投机的副作用需要分阶段提交」在 2026 年的系统文献中亦有讨论，涉及暂存副作用、可逆沙箱与事务化工具调用等方向。本报告第六节把这一结论接到原文的投机执行设计上，指出其缺少提交边界，并给出与即时通讯、代码评审两类信道相对应的原语。

此外，「把试过且失败的路径作为一等记忆对象」已经成为一条独立的研究方向。本报告第五章讨论长程记忆时引用这一方向，但不将其作为自己的主张。

1.3 本报告自认的增量

为避免将既有讨论误报为原创，此处集中列出本报告认为属于自己的五处工作。每一处都在正文中有对应的公式、表格或判据，可以单独检验。

第一，用原文 7.2 节公开的批处理数据复算 Router 的利用率，得出在每分钟约 40 条 Trigger 时利用率约为 0.93，从而否定原文「仍未触及单 Router 的吞吐瓶颈」的判断（第三节）。

第二，指出 7.1 节的因变量与全文主张的因变量不一致，并指出该实验缺失一个关键对照——强制委派。缺少这一对照，就无法把架构效应与提示词效应分开（第四节）。

第三，把 Router 的路由职责与记忆职责的耦合识别为长程记忆瓶颈的结构性来源，并提出以日志序号而非会话作为序列点（第五节）。

第四，提出原文五个模块共同缺失的第六个模块——结清，并给出状态机、回收器与预算三项要件（第七节）。

第五，按验收延迟把应用场景分为三类，说明原文架构只在第一类成立，并给出第二类场景（制造业寻源）的改造方向（第八节）。

以上五处，第一、第二两处是对已发表数据的重算，可被读者逐一复现；第三、第四、第五三处是设计判断，属于可争论的范围。本报告在结论部分区分这两类判断，不把设计判断表述为已被验证的事实。

二、原文主张的结构化重述

要检验一份架构说明，先要把它的命题写清楚。原文的论证链条可以拆成七条命题。

  • P1：单任务的上限取决于模型能力，多任务的上限取决于人的注意力；随着执行侧对人的依赖下降，限制进一步提效的瓶颈正在转向人的注意力。
  • P2：会话应当是系统的实现细节，不应成为用户的认知负担。
  • P3：双层架构可以同时获得跨信道的连续性与多任务的吞吐量。
  • P4：事件驱动可以把 Agent 从被动执行变为主动响应。
  • P5：计算、状态与环境的分离可以获得跨设备的持久在线。
  • P6：外部 Watchdog 可以在长期运行中实现异常自愈。
  • P7：以上命题在真实负载下成立。

这个拆法并非苛求。原文自己在第 7 节开头写明「由于实验基于合成负载与简化环境，部分设置还可以更加严谨，以下结果仅作为初步参考」。这句话划定了证据的范围，本报告只是把范围换算成命题，看哪几条落在范围内。

2.1 四个特征与五个模块的对应关系

原文提出四个基础特征：连续、高效、主动、持久。五个模块分别支撑这些特征。把对应关系列成表，可以看出覆盖是不均匀的。

模块 核心机制 对应特征 原文给出的证据 实验覆盖程度
双层架构 常驻 Router 加隔离 Worker 连续、高效 7.1 完成时间对比、7.2 批处理压测 部分覆盖
事件驱动 Trigger、Thread、订阅直通、链式召回、投机执行 主动 7.1 中「去掉直通」的 token 对比 仅覆盖直通一项
面向人的交互 异步 ReAct Loop、多信道输出规范 连续、高效 无实验，原文称「已经在 DeepSeek Harness 中实现，但尚未默认开启」 未覆盖
计算与状态、环境分离 云端无状态 Loop 加端侧 daemon 持久 无实验 未覆盖
Watchdog 外部定时驱动的独立会话 持久 无实验 未覆盖

这张表的读法需要谨慎。未覆盖不等于不成立。第五、第六两节所描述的能力，在工程上完全可能已经成立，只是没有以实验形式公开。本报告要指出的是另一件事：这份说明的说服力分布不均。读者最容易记住的是 7.1 节的 p50 与 p95，而这两个数字只支撑「双层架构在合成负载下缩短了任务完成时间」，并不支撑「持续在线」「异常自愈」「跨设备接管」这三项更容易打动人的能力。

对一份工程说明而言，这种不均匀是正常的。但它带来一个传播后果：媒体转述时，四个特征与五个模块被并列成同等确定的结论，而实际上它们的证据强度相差一个量级。本报告在后续章节中按证据强度分别处理。

2.2 原文做得比多数同类文本更好的两处

批评之前应当先承认两处优点，因为它们决定了本报告能够做复算。

第一处是对实验边界的主动披露。原文写明编码工作由一个只消耗时间的工具代替，因此实验衡量的是调度与协作能力，而非单个任务的执行能力；写明消息间隔与工作时长按四分之一缩放，模型调用耗时为真实值；写明每种方案重复运行五次。这些披露使得读者可以判断哪些结论可以外推、哪些不可以。多数同类文本只给出结论，不给出边界。

第二处是对简化组合的明示。原文在 8.1 节直接写出自己所依赖的简化：「单常驻 Router Session + 订阅直通 + Worker 间不直接通信」，并说明这是「以较小的工程代价覆盖了我们目前的大多数日常任务」。这句话实际上承认了这套架构是为特定规模设计的，而不是普适方案。后文所有关于扩展性的讨论，都建立在这个自陈之上。

本报告第三节的复算之所以可能，正是因为原文给出了到达速率、批大小与单次请求耗时三个数。这个数据披露的完整度，在同类工程文章中属于少数。

2.3 一条需要拆开的主张

P1 是整篇的起点：单任务的上限取决于模型能力，多任务的上限取决于人的注意力。这句话读起来像一条定律，实际上是一个关于当前设计的状态描述。它成立的前提是：人必须同时承担「跟踪任务状态」与「承担任务后果」两件事。

这两件事的扩展性完全不同。跟踪状态是可以外包的——只要有可靠的记录、检索与提醒，一个人跟踪的任务数可以从几个增加到几十个。承担后果则不能外包：验收一个产出，意味着验收者要为这个产出的正确性负责，而责任的容量受专业判断力与组织授权约束，不受界面设计约束。

原文用来支撑这一判断的是一个经验观察：一个人通常只能同时跟进三到五个活跃会话。这个数字没有给出样本、测量方法与人群，本报告只能按经验值处理。它在机制上可能对应三种不同的限制：工作记忆的容量、中断恢复的成本、以及同时为多少件事承担后果的容量。前两种可以靠架构与交互降低，第三种不能。原文把三者合称「注意力」，于是只要证明跟踪成本下降，就好像证明了注意力瓶颈被缓解。

原文的双层架构，实质上做的正是把「跟踪」从人身上剥离出去：Router 维护全局记忆，Worker 各自持有局部上下文，人只需要面对一个统一的对话入口。这一步是有效的，也是这套设计最有价值的部分。但它并没有触及第二件事。原文把这两件事合称「人的注意力」，于是在论证上获得了一个便利：只要证明跟踪成本下降，就好像证明了注意力瓶颈被缓解。

本报告认为，这个合并掩盖了真正的问题。把两件事分开之后，会得到一个不同的结论：Super-agent 缓解的是跟踪瓶颈，不是验收瓶颈。而随着跟踪瓶颈被缓解，验收瓶颈会以更快的速度暴露出来——因为单位时间内产生的待验收产出增加了。第八节将沿着这条线展开。

这个区分也解释了原文 8.2 节的犹疑。原文在那里写道，脱离会话之后「如何向用户呈现任务并提供自然的交互与项目管理形式，便成为了新的问题」，并认为以聊天窗口为中心的交互「在一定程度上是路径依赖的结果」。这个判断是对的，但原文把它归为产品设计问题。本报告认为它首先是计量问题：当系统把任务状态从人脑中移出之后，人剩下的唯一工作就是验收，而验收的单位、成本与责任归属，原文没有给出定义。

三、复算一：Router 的吞吐余量被高估

原文 7.2 节给出了 Router 层压力测试的一组读数，这是全文唯一可以完整复算的压测序列。本节的结论只有一句：按这组读数计算，单个 Router 会话在测得的最高到达速率下已经接近满负荷运行，原文「仍未触及单 Router 的吞吐瓶颈」的判断不成立。

3.1 原文公开的读数

原文的压测方式为：Router 调用真实模型，Worker 使用模拟模型，将需要判定的 Trigger 到达速率从每分钟约 1 条逐步提升到约 40 条，观察三个量。

到达速率（条/分钟） 平均批大小 单次请求耗时（秒） 单个决定分摊的推理时间（秒）
约 1 1.0 2.5 6.4
约 40 2.8 3.9 1.6

原文据此写道：单次请求耗时仅从 2.5 秒增至 3.9 秒，增长慢于批大小，从而使单个决定分摊的推理时间从 6.4 秒降至 1.6 秒；这说明外部事件突发拥堵时，Router 能够通过自动合并积压事件提高有效吞吐，因此「在我们目前的团队规模下，无需过早对 Router 层做水平切分」。

这段推理的每一步都依赖一个未写出的前提：单次请求耗时是纯服务时间，且批大小是系统主动选择的结果。把这两个前提写出来之后，会看到另外两种读法。

3.2 用排队论复算利用率

设到达速率为 λ（条/秒），平均批大小为 b，单次请求耗时为 S（秒）。在批量服务的排队系统中，服务器处于忙碌状态的时间比例为

  • 利用率 ρ =（批到达率）×（批服务时间）= (λ / b) × S。

代入原文的两组读数。

低速端：λ = 1/60 ≈ 0.0167 条/秒，b = 1.0，S = 2.5 秒，得 ρ ≈ 0.042。

高速端：λ = 40/60 ≈ 0.667 条/秒，b = 2.8，S = 3.9 秒，得 ρ ≈ 0.929。

也就是说，在整个压测区间内，Router 的利用率从约 4% 上升到约 93%。这不是原文所说的「仍未触及」瓶颈，而是已经贴着瓶颈运行。在利用率 0.93 的排队系统里，等待时间对到达速率的微小波动极为敏感；平均等待时间与服务时间之比，随利用率趋近 1 而迅速发散。

这一计算依赖三个假设，此处逐一说明。第一，假定原文所称「单次请求耗时」是服务时间而非含排队的响应时间。第二，假定表中的批大小是该速率下的平均值，而非某一时刻的瞬时值。第三，忽略批与批之间的到达相关性与服务时间方差。在这三个假设下，ρ ≈ 0.93 是一个中心估计；即便把批大小取值上浮到 3.0、把服务时间下调到 3.5 秒，ρ 仍约为 0.78，结论方向不变。

3.3 批大小是怎么来的

还有一个更值得注意的问题：批大小 2.8 这个数，几乎正好等于「一次服务期间新到达的 Trigger 数量」。

按定义，若批处理就是「服务期间到达的事件合并进下一次调用」，则 b ≈ λ × S。代入高速端：0.667 × 3.9 ≈ 2.60。原文实测的批大小是 2.8，两者相差约 8%，在测量误差范围内。低速端则相反：0.0167 × 2.5 ≈ 0.04，远小于 1，系统退化为逐条处理，与表中 b = 1.0 一致。

这个吻合说明一件事：原文描述的「批处理机制」，在这组数据里与普通排队系统的自然积压无法区分。路由器并没有一个额外的调度策略在主动攒批；它只是在一个请求处理期间，把新到的事件收进队列，然后在下一轮一并处理。这是任何单线程服务端在网络负载下都会出现的现象，不需要专门设计。

这个区分的意义在于指标的解释。若批处理是主动策略，则「单个决定分摊时间下降」可以解读为效率提升；若批处理只是积压的自然结果，则这个指标就是一个排队统计量，它下降的原因是把固定的服务成本摊到了一段不断变长的等待上，而不是系统变快了。原文选择了前一种解释，但没有给出能区分两种解释的证据。

3.4 服务时间的规模弹性，以及它为何可能不会持续

把表中的两个点按幂律拟合，得到

  • S = 2.5 × b^0.432。

两个点拟合一条幂律，本身证据很弱，这里只用它做量级判断。由此得到系统的容量（每秒可判定的条数）

  • C = b / S = 0.4 × b^0.568（条/秒），即每分钟约 24 × b^0.568 条。

代入不同的批大小：

批大小 服务时间（秒） 容量（条/分钟）
1.0 2.5 24
2.8 3.9 43
8.3 6.2 80
17 8.5 120
30 10.9 166

按这条曲线，以每分钟 40 条为基准，把容量翻倍到每分钟 80 条需要批大小约 8.3；提高到每分钟 120 条需要批大小约 17。若每条 Trigger 在 Router 上下文中约占 500 至 2000 个 token，批大小 17 对应 8500 至 34000 个 token，远低于当前主流模型的上下文长度。

由此得到两个判断。

第一个判断：原文所称的上限「取决于上下文长度」，在当前量级上并不紧。上下文长度要到批大小上百时才会成为约束，而那时系统的容量已经到每分钟数百条，超出了单个团队的事件规模。真正先成为约束的是另一个上限——原文同一句话的后半段「模型在一轮中能准确处理多少条 Trigger」。这条曲线没有被测。

第二个判断：服务时间对批大小的弹性 0.432，本身就值得怀疑。若批处理带来的收益来自原文所称的 Prefill 并行，那么在固定一批请求、只增加输入 token 的情况下，Prefill 的计算量大致随 token 数线性增长，服务时间应当接近 S ∝ b，弹性接近 1，此时容量 C = b/S 将是一个常数，批处理完全不带来吞吐提升。实测弹性只有 0.432，说明服务时间里有一大块与批大小无关的固定开销——上下文组装、工具调用、状态读写，以及状态读写。收益更可能来自这部分固定开销的摊薄，而不是 Prefill 并行。

这两种机制对工程的含义不同。若收益来自固定开销摊薄，那么它随系统实现而变化，换一套上下文组装方式就可能消失；若来自 Prefill 并行，则它是模型推理层的稳定性质。原文把收益归因于 Prefill，但没有排除固定开销这一解释。

3.5 三个指标里缺了最重要的一个

原文 7.2 节报告了三个量：平均批大小、单次请求耗时、单个决定分摊的推理时间。这三个量描述的都是服务器一侧。

对「主动」这一特征而言，真正决定体验的量是「事件到决定」的时延，即一条 Trigger 从进入系统到 Router 做出分派决定所经过的时间。这个量等于排队等待加服务时间。在利用率 0.93 的系统里，排队等待通常显著大于服务时间，且方差很大。

原文没有报告这个量。因此在原文的数据范围内，无法判断在每分钟 40 条的负载下，「主动响应」还剩下多少。这是一个可以补测的缺口，只需在压测中记录每条 Trigger 的进入时间与判定时间，取分位数即可。

3.6 本节结论的边界

本节没有说这套架构不能用。恰恰相反，按复算，这套架构在每分钟 40 条以下的负载下是稳定的，而 40 条/分钟的团队消息量已经不算小。本节的结论只有两条。

第一，原文对余量的描述与实际数据不符。利用率 0.93 意味着余量在百分之十的量级，而不是原文所说的「仍未触及」瓶颈。这对工程决策有直接影响：如果读者按「还有大量余量」来做容量规划，会在负载略微上升时遇到排队时间的非线性上升。

第二，原文把这一现象作为 Router 层的吞吐机制来解释，而数据形态更支持「自然积压」。这不影响系统的可用性，但影响可迁移性——如果一个团队照着这段描述去实现一个「主动攒批」的调度器，可能会发现收益远小于预期，因为原文测到的收益本来就不来自调度器。

四、复算二：实验测的变量与主张的变量不一致

第三节处理的是数据怎么读。本节处理一个更靠前的问题：这组实验是否在检验它想要检验的东西。

4.1 主张与测量的错位

原文的出发点是 P1：多任务的上限取决于人的注意力。由此推出的架构目标，应当是提高单位时间内人所能推进的任务数。这是一个人力吞吐量指标。

原文 7.1 节测量的却是「任务完成时间」：从工作请求到结果消息的耗时，取 p50 与 p95。这是一个单任务延迟指标。原文同时给出了四种方案的累计完成曲线，其中包含吞吐信息；但正文用来排序的统计量是 p50 与 p95，并且没有给出人力吞吐指标，也没有做强制委派对照。本节批评的是统计量与对照设计，不是否认曲线存在。

两者不是单调关系。一个系统完全可以在降低单任务延迟的同时降低人力吞吐量——如果它产生了更多需要人验收的小产出，人的切换成本会上升。反过来，一个系统也可以提高单任务延迟而提高人力吞吐量——把多个任务攒到一起集中验收，延迟上升，单位时间的验收数增加。因此，用单任务延迟的排序来支撑关于注意力瓶颈的结论，属于构念效度问题：测量的变量不是主张所关于的变量。

这不是吹毛求疵。原文 4.1 节自己提出了全双工交互，其目的正是「无需等待上一个命令或任务完成即可随时接受新指令」，这是一个吞吐量主张。如果实验只测延迟，那么异步 ReAct Loop 这一整个模块在实验上是空的。

4.2 缺失的那个对照

7.1 节对比了四种方案：完整 Super-agent、去掉直通的 Super-agent、中性提示下的单会话加子代理工具、优先委派提示下的单会话加子代理工具。

这四种方案漏掉了一种：强制委派的单会话。

所谓强制委派，是指由 harness 无条件地把每个工作请求交给一个新的子代理，不交给模型判断。这个方案与「优先委派提示」只差一个实现细节——把「建议委派」的提示词换成「必须委派」的代码，其余完全相同。

为什么这个对照关键？因为原文自己的数据已经暗示了它的重要性。在中性提示下，模型五次运行一次都没有调用子代理；改为优先委派提示后，五次里有四次调用，但仍有一次判断工作「很小」而选择自己执行，形成了原文所称的紫色长尾。这段描述说明，委派提示显著改变了委派率；在明确提示下仍然出现的那一次长尾，可以归因于模型对自身工作量的误判。至于单会话结构本身是否失分，需要强制委派对照才能判断。

若加入强制委派对照，可能出现两种结果。

第一种，强制委派与双层架构基本相当。这意味着双层架构的主要价值不在于「两层」，而在于「取消了模型的委派裁量权」。这是一个很有价值的结论，而且实现成本极低——几行 harness 代码即可，不需要 Router、不需要订阅、不需要链式召回。对绝大多数团队来说，这是一个远比整套架构更划算的选择。

第二种，强制委派仍明显落后。这才能说明双层架构带来了结构性的收益，例如 Worker 不直接对外回复所带来的输出收敛，或者订阅直通所带来的 Router 负载下降。

原文没有做这个对照，因此无法区分这两种情况。它给出的 p50 与 p95 差异，同时兼容「架构更优」与「强制比建议更有效」两种解释。

4.3 五次的样本量能支撑什么

7.1 节每种方案重复运行五次。在这个样本量下，报告 p95 需要谨慎：五个观测的第九十五百分位无法可靠估计，按次序统计量计算，它落在最大两个观测之间，接近最大值。因此「p95 为 15.7 分钟」与「p95 为 29.5 分钟」这两个数，更准确的读法是「五次中最慢的一次分别为 15.7 分钟与 29.5 分钟」。

同样，「中性提示下五次均未调用子代理」这一观察，在统计上只能把调用率的上界压到约 45%（零次成功的精确二项上界：1 − 0.05^(1/5) ≈ 0.45）。它不能支撑「模型不会主动委派」这一较强的判断。

这些不是对原文的否定。原文自己写明结果「仅作为初步参考」。本报告要提示的是转述层的风险：当这些数字被媒体摘编成「p95 缩短一半」时，读者接收到的确定性远高于数据本身能提供的。

4.4 成本的量级

原文给出了一个很有价值但容易被忽略的数字：完整 Super-agent 单次实验的读缓存 token 为 2323 万，去掉直通后增至 3177 万，增幅约 37%。单次实验包含约 300 条消息，其中约 20 条是工作请求。

把它换算成单位成本：

  • 每个工作请求对应的读缓存 token ≈ 2323 万 ÷ 20 ≈ 116 万。
  • 直通机制节省的 token ≈ 3177 万 − 2323 万 = 854 万，占完整版的 37%。

原文没有给出计价，本报告也不引入外部价格，只给出比值：若读缓存按输入价格的十分之一计价，则每个工作请求的等效全价输入 token 约为 11.6 万。这个量级意味着，这套架构的成本中心不在「执行任务」，而在「反复读取上下文」。任务越复杂、会话越长，单位成本上升得越快。

还有一个负载结构的问题。300 条消息里只有 20 条是工作请求，占 6.7%。Router 需要读取全部消息才能判断哪条需要行动，因此它的绝大部分算力花在了处理非工作消息上。这是一个设计上的必然，不是缺陷——主动性的代价就是必须读完全部输入。但它意味着，原文报告的成本数字高度依赖于这个 6.7% 的比例。在一个工作消息占比更高的团队里，单位成本会下降；在一个闲聊占比更高的群里，单位成本会上升。原文没有说明这个比例的现实依据。

4.5 如果要补做，最小的实验设计

本报告不主张推翻原文的结论，只主张这些结论需要一次成本不高的补充实验。最小设计如下。

采用 2×2 因子设计。两个因子分别是：是否强制委派（代码强制 / 模型裁量）、是否为双层架构（单会话 / Router 加 Worker）。四种组合各运行不少于二十次，负载沿用原文的合成消息流，以便对照。

因变量取两个。一个是单任务完成时间，用于与原文对齐；另一个是人力吞吐量代理指标，例如「在固定的人力预算内（比如每十分钟检查一次、每次最多处理五个待验收项）完成的工作请求数」。后一个指标才是 P1 所关于的量。

同时记录「事件到决定」的时延与「待验收队列长度」两条曲线。前者补上第三节指出的缺口，后者直接对应第八节要讨论的验收瓶颈。

这个设计的成本远低于重做整套系统，但它能把原文目前混在一起的三个效应——架构效应、强制效应、测量效应——分开。对准备采用这套架构的团队来说，这个区分决定了他们要付多少实现成本。

五、结构诊断：路由与全局记忆被放在同一个会话里

第三节说明 Router 的余量比原文描述的更小。本节要指出一个更基础的问题：Router 之所以这么快就接近满负荷，部分原因在于它同时承担了两项扩展性相互冲突的职责。

5.1 Router 的三重身份

原文 2.1 节对 Router 的描述可以拆成三句。

第一句：「所有跨任务的信息与决策都在 Router 层中汇总，由它充当全局的序点（Sequence Point）、协调点和记忆。」这句话把三件事交给同一个组件：全局顺序、跨任务协调、长期记忆。

第二句：「Router 层在设计上不直接执行具体任务，只负责人类交互与任务分派，甚至可以不配备 Bash 工具。」这句话把 Router 定位为轻量的分派者，并建议使用「较轻量的模型」。

第三句：「从我们的实践来看，Router 层的任务常常没有想象中复杂，使用较轻量的模型往往就能兼顾速度与效果。」

三句话合起来，得到一个不太稳的结构：系统里信息最全的组件，按原文建议用的是较轻量的模型；系统里唯一掌握全局事实的组件，是一个可能被重启、被替换、被上下文长度限制的会话。

原文并非没有意识到风险。它紧接着写道：「为了避免这一全局节点成为系统的性能瓶颈，Router 层在设计上不直接执行具体任务。」也就是说，它看到了吞吐瓶颈，并用「不执行具体任务」来规避。但它没有处理另一种瓶颈：记忆的体量。

5.2 两项职责的扩展性冲突

路由与记忆对上下文的要求方向相反。

路由希望上下文短。路由决策的输入是「这条事件该交给谁」，所需信息是当前任务表、订阅关系、以及少量近期状态。上下文越长，单次决策的成本越高、延迟越大、注意力越分散。在第三节的复算中，单次请求耗时随批大小上升，而批大小上升又来自队列积压——这已经显示出成本对上下文规模敏感。

记忆希望上下文长。全局记忆要回答的是「三个月前那个任务为什么改了方案」，所需信息是完整的历史与决策理由。上下文越短，召回越不可靠。

把两者放进同一个会话，会得到一个必然结果：每一次路由决策都要为整个记忆付费。原文的总量数据与这一诊断相容——每个工作请求约 116 万读缓存 token，而真正的「工作」在实验里只是一个消耗时间的空工具。但原文没有给出 Router 与 Worker 的分项，因此这组总量只能作为旁证，不能单独证明。

这个耦合还带来三个次要后果，都会在长期运行中显现。

其一是可用性。原文 5.1 节把会话状态存入数据库、由持久化存储保障连续性，这一步是成立的。问题在于全局记忆仍然以单个上下文窗口为载体，没有外化为可查询的视图；因此重启后的会话能在多大程度上恢复「同一个」全局记忆，取决于上下文能否重建，而原文没有描述这条重建路径。

其二是可替换性。想更换 Router 使用的模型，就必须同时迁移记忆。这使得模型升级与架构升级被绑在一起，团队很难做小步替换。

其三是可评估性。想比较两个 Router 策略的优劣，必须让它们各自维护一份记忆，否则比较不成立；而一旦各自维护，两份记忆又会分叉。评估成本因此远高于一个无状态组件。

5.3 把序列点从会话移到日志序号

原文使用的是「序点（Sequence Point）」这一表述，本报告以下改称「序列点」。这个词来自数据库与日志系统，含义是「全局顺序上的一个位置」。在这个语境里，序列点的作用是为跨任务的事件提供一个统一的时间轴，使「先发生」「后发生」「并发」有确定的判定。

在日志系统里，序列点是一个单调递增的编号，通常称为日志序号。它是一个数值，不是一个进程。进程可以崩溃、重启、替换、水平扩展，而日志序号不变；任何组件只要记住自己处理到哪个序号，就能在重启后从正确的位置继续。

原文把序列点放在一个常驻会话里，等于把一个数值的职责交给了一个进程。这带来两个不必要的约束：全局顺序的可用性依赖该进程存活；全局记忆的完整性依赖该进程的上下文长度。

一个更稳的结构是把两者分开。

事件日志作为唯一权威，以只追加的方式记录所有 Trigger、分派决定、Worker 状态变更与对外动作，每条记录带一个单调递增的序号。Router 会话只持有两样东西：当前处理到的序号，以及一个容量受限的工作集（working set，这一概念来自操作系统对程序局部性的研究）。全局记忆不属于 Router，而是从日志派生出来的物化视图——任务表、决策表、线程表、否决表——可以随时重建，也可以被任何组件查询。

在这个结构下，原文的链式召回会变成另一种东西。原文的链式召回是「每次召回的对象均内联下一跳关联对象的 ID，支持沿引用关系逐跳展开上下文」；它依赖 Router 的上下文持有这些 ID，并且依赖 Router 知道该往哪个方向跳。改为日志查询之后，召回变成一次带条件的检索：给定一个时间点或一个任务标识，取出该任务的全部事件与该任务被否决的方案。前者依赖模型的记忆，后者依赖索引。

这个改法与原文 5.2 节并不冲突，反而更接近原文自己引用的方案。原文在 5.2 节写道，它的思路「与 Anthropic 提出的「脑手分离」（Decoupling the brain from the hands）一致，同样让 harness 保持无状态，把会话日志存放在 harness 之外」。Anthropic 那套设计的核心正是：会话是一份存放在模型上下文之外的、只追加的持久日志，harness 崩溃后凭会话标识重新读取日志并从最后一个事件恢复。原文接受了这一点，但只把它用在 Worker 侧；Router 侧仍然把全局记忆放在会话里。

因此这里的问题不是「原文没想到无状态」，而是「无状态只做了一半」。Worker 的 harness 无状态，Router 的记忆有状态；系统的全局连续性因此仍然系于一个进程。原文 8.1 节承认「长程记忆便成为制约可扩展性的主要瓶颈」，按本节的读法，这个瓶颈的来源不是记忆存得不够多，而是记忆放错了位置。

5.4 一个可以立刻检验的推论

若上述诊断成立，应当能观察到一个具体现象：系统在长期运行后，Router 的单位决策成本随运行时长上升，且上升幅度与任务总量相关，而与当前负载无关。

原文的压测是短时的，无法显示这一点。但原文 7.1 节的成本数据已经给出一丝线索：单次实验 300 条消息就消耗 2323 万读缓存 token。把时间尺度拉长到数周，这个数字会如何变化，原文没有报告。这是一个可以在现有系统上直接测量的量：把 Router 每轮调用的输入 token 数与当时的日志长度做回归，若斜率显著为正，诊断成立。

5.5 隐藏会话带来的第二个问题：没有去重键

原文有一个很漂亮的判断：「Session 应当是系统的实现细节，而不应是用户的认知负担。」这个判断在交互层面成立。但会话除了是认知单位，还是去重单位。

在传统的单会话设计中，用户重复发送同一个请求，系统至少能看出「这是同一个会话里的第二次输入」，从而做上下文内的判重。会话被隐藏之后，同一个意图可以从不同信道到达：先在即时通讯里说一遍，再在邮件里补一句，再在代码平台上开一个议题。这三条事件在底层是三个不同的 Trigger，来自三个不同的 Thread，没有任何共同的标识。

原文的订阅与直通机制解决的是「同一 Thread 内的后续事件」的路由问题，不解决「不同 Thread 表达同一意图」的合并问题。后者需要在全局层面做语义判重，而全局层面恰好只有 Router，Router 又恰好被设定为轻量模型。

于是形成一个两难：要么 Router 用强模型做语义判重，成本与延迟上升；要么用轻量模型，判重准确率不足，出现重复任务。重复任务的代价不是多花一点算力，而是两个 Worker 在同一个外部目标上并行推进，产生冲突的对外动作。

这个两难是本报告认为最值得在下一版设计中处理的具体问题。它有一个低成本的解法：在事件进入时先做一次结构化抽取（谁、要什么、对象是什么），用抽取出的三元组做精确匹配，只把无法匹配的交给语义判重。这样把大部分判重工作从模型移到代码，与原文自己在事件过滤中采用的「程序快路径加模型慢路径」是同一个思路，只是原文把它用在了过滤上，没有用在判重上。

六、类比检验：操作系统隐喻在哪里失效

原文第 9 节写道：「我们并没有提出全新的理论，而是将计算机系统中经典的工程思想应用到了 Agent 系统的构建中。」这句话是准确的，也是一种诚实的自我定位。本节的任务是把这句话推到底：既然整套设计建立在类比之上，那么类比的失效处，就是设计的风险处。

6.1 这个类比已经不是新见解

需要先说清楚一件事，以免读者误以为本文提出了新框架。把 Agent 系统类比为操作系统，在 2025 年至 2026 年已经是成熟话题。围绕「上下文窗口即内存、检索增强即换页、上下文溢出即颠簸」这一组对应，出现了 LLMOS、AgentOS、vMem 等一批命名与实现，也有若干开源项目直接按页表、工作集、缺页处理的语义来管理上下文。国内亦有作者给出过一组对应：大模型是新 CPU、上下文窗口是新内存、数据库是新磁盘、Agent 是应用程序。

因此本报告不把这个类比作为贡献，而是把它作为检验工具：如果类比成立，它应当能预测原文没有讨论的失败模式；如果类比在某个点上失效，那个点就是这套架构的真实边界。

6.2 对应关系

先把对应关系列全，再逐条检验。

操作系统概念 Super-agent 中的对应物 对应强度
进程 Worker Session 强
进程控制块 Worker 的上下文与工具配置 强
调度器 Router 中
中断 Trigger 强
中断亲和性 Thread 订阅直通 强
缓存 上下文窗口内联的信息 强
换出 Spill 到窗口之外 强
多级页表遍历 链式召回 中
硬件看门狗 Watchdog 会话 强
用户态与内核态 Worker 与 Router 的权限分层 反向（Router 权限更少）
进程号 无对应物 缺失
事务与提交 无对应物 缺失

前九行的对应是成立的；第十行方向相反，Router 的权限少于 Worker，与内核态高于用户态的常规相反；最后两行在原文中没有对应物。这三处正是本报告认为最需要补的地方。

6.3 失效之一：外部世界不可回滚

原文 3.4 节借用投机执行，写道「结果有价值就交付，没有价值就丢弃」。

在处理器里，这句话成立，因为投机执行的结果写在寄存器或重排序缓冲里，丢弃的代价是几个时钟周期。在 Agent 系统里，这句话只在沙箱内成立。一旦投机的产物越过了沙箱边界——发出一条群消息、提交一个合并请求、发出一封邮件、调用一次外部接口——它就不再是可丢弃的。原文举的例子恰恰是越界的：Agent 在群里讨论尚未结束时，已经在后台提交了修复用的合并请求。这个动作发生在外部世界，无法因为「结果没有价值」而撤销。

这一点在 2026 年的系统研究中已有回应。围绕 Agent 的事务化执行，出现了「暂存副作用」「提交门」「可逆沙箱」等一组设计：把对外动作先写入一个暂存区，只有在通过校验之后才真正释放。数据库领域的乐观并发控制早就给出了同样的结构——先执行，再在提交阶段校验，校验失败则回滚；而回滚之所以可能，是因为所有写入都还没有落盘。

对本架构而言，这意味着投机执行需要补一个原文没有写的阶段。Worker 可以自由地在沙箱内尝试，但它的产物在越过沙箱之前必须停在一个可审阅、可丢弃的形态：一封草稿邮件、一个未提交的分支、一条待发送的消息。提交这一步应当由策略门执行，而不是由 Worker 自己执行。

6.4 失效之二：副作用不是幂等的

操作系统的系统调用失败后可以重试，因为内核保证大多数调用的语义。Agent 的对外动作不满足这一点：发送一条消息不是幂等操作，提交一个合并请求不是幂等操作，给客户打一个电话更不是。

原文 5.2 节描述了一个必然会遇到重试的场景：端侧 daemon 与云端 Loop 之间的连接可能中断，设备可能间歇在线，「在用户的某台个人设备重新上线后，再由云端 Agent 自动触发并完成需要在该设备上执行的任务」。在这个场景里，同一条命令可能被执行两次，因为云端无法确定第一次是否已经生效。

解决这个问题需要幂等键，而且幂等键必须由发起方生成、随任务一起下发，不能由执行方生成。原文没有讨论这一点。这不是一个可以留到实现阶段再补的细节：幂等键的位置决定了任务标识的设计，而任务标识又决定了日志结构。

6.5 失效之三：人不是中断控制器

中断可以抢占任意一条指令，上下文切换的代价是微秒级。人不行。人的响应延迟以分钟到小时计，且不可预测；人的「上下文切换」代价以十分钟计。关于中断成本的经典研究给出的量级是：一次被打断的工作，平均需要二十余分钟才能回到原来的任务状态。

因此，原文 4.1 节的「全双工交互」在系统层面成立，在人的层面只是「不阻塞」，不是「实时」。这个区别对设计有实际影响：如果系统假设人可以像中断控制器一样随时响应，它就会倾向于频繁地发起确认请求；而每一次确认请求都是一次对人的中断，其成本远高于系统侧的等待。

原文在 4.2 节给出了一个很好的经验规则：单次回复不超过一百词，只在需要决策或验收时通知。这条规则的方向是对的。但它是一条提示词层面的约束，不是结构层面的保证。要让它稳定成立，需要把「什么情况下可以打扰人」变成策略门的一个判定条件，而不是模型的自律。

6.6 失效之四：换出的代价函数不同

在操作系统里，换出页面的代价是慢：一次缺页要访问磁盘。在 Agent 系统里，遗忘的代价可能是不可恢复的：某些信息一旦离开上下文，就再也取不回来。

原文的 Inline & Spill 设计假定「将超出窗口预算或低频使用的完整信息留在上下文窗口之外，仅在窗口内保留引用或摘要，供模型按需读取」。这个假定对可重新读取的对象成立——文件、代码、评论历史都可以再读一次。但它对只在对话中出现过一次的信息不成立：用户口头说的一句约束、讨论中临时决定的一个取舍、被否决的一个方案。

这类信息的特点是：没有对应的可读对象。它们只存在于当时的上下文里。一旦 Spill 掉，引用指向的是空。

这就引出本报告认为原文最应当补充的一类记忆：否决记忆。一个团队真正稀缺的知识，往往不是「做过什么」，而是「试过什么并且为什么不行」。前者通常会留下产物——代码、文档、合并请求；后者通常什么也不留。而链式召回依赖 ID 图，ID 图只能索引有产物的对象。否决没有产物，因此无法被索引。

已有研究把这一类对象称为负面知识或失败记忆，并指出它的检索语义与正向记忆不同：正向记忆可以按语义相似度召回，否决记忆必须按条件精确匹配，因为「一个相似的失败」很可能是完全不同的失败。这个判断与本报告在 5.3 节的诊断相互印证——记忆的关键不在于容量，而在于索引方式是否与对象类型匹配。

6.7 类比成立的推论：缓存一致性会出问题

前几节讲失效，本节讲一个类比反过来给出的有效预测。

在操作系统里，多个处理器各自缓存同一块内存时，需要缓存一致性协议；否则一个处理器改了数据，另一个处理器仍在用旧值。原文的设计里，Worker 之间不直接通信，各自持有隔离的上下文，只通过订阅同一个 Thread 获取相同的事件。这在「同一 Thread」内保证了一致性。

但全局决策不在 Thread 里。Router 可能在中途调整了任务边界、更改了优先级、或者否决了某个方案。这些变更发生在 Router 会话中，不会自动传播到已经在运行的 Worker。Worker 手里拿着的是分派时刻的旧假设，而它仍然在对外执行动作。

按类比的推论，这套系统在生产环境中的第一次严重事故，大概率不是进程崩溃，而是两个 Worker 基于互相矛盾的全局假设同时推进，并且都在对外产生副作用。这个推论可以用一个很轻的机制防范：给全局决策加一个版本号，Worker 在执行任何对外动作之前校验自己的版本号是否仍然有效；不一致则暂停并回报 Router。

这个机制的成本很低，但原文没有提到。本报告把它列为第六节的主要建议。

6.8 小结

操作系统类比在进程、中断、缓存、看门狗四组关系上成立，能带来有用的设计直觉；在事务与进程号两处缺失，而这两处恰好对应着本报告认为这套架构最薄弱的两块：对外动作的提交边界，以及跨信道的任务去重。

一个更一般的观察是：操作系统之所以能把这些机制做得可靠，是因为它控制了硬件；Agent 系统不控制外部世界。凡涉及外部世界的动作，类比都会变弱；凡只涉及系统内部资源的动作，类比都很强。原文的设计在系统内部做得很完整，在边界上留白较多，这与原文自陈的「工程和场景简化」是一致的。

七、缺失的第六模块：结清与回收

原文用五个模块支撑四个特征。本报告认为这套结构缺一个模块，而且缺得很整齐：五个模块全部关于「如何开始」与「如何持续」，没有一个关于「如何结束」。

7.1 五个模块的共同偏向

逐个看这五个模块的功能。

双层架构解决的是任务如何被分派与执行。事件驱动解决的是任务如何被触发与路由。面向人的交互解决的是结果如何被呈现。计算、状态与环境的分离解决的是系统如何在设备离线时继续存在。Watchdog 解决的是系统如何在异常后恢复。

五项都在回答「怎么让事情跑起来并且不停」。没有一项在回答「一件事情的终态是什么，到达终态之后占用怎么释放」。

一份完整的任务生命周期至少需要四个阶段：受理、执行、验收、结清。原文把前三个阶段都覆盖了，第四阶段没有。原文 8.2 节讨论「脱离 Session 之后如何与 Agent 协作」时，谈的是任务发起与结果验收阶段的人的参与，仍然没有触及终态。

这个缺失在短期演示里不会暴露。系统跑三天，任务不多，残留看不出来。但原文的目标形态恰恰是「始终在线」「长期运行」，而残留问题只在长期运行中显现。

7.2 五类残留

按本报告的分析，这套架构在长期运行中会产生五类残留。

僵尸任务。任务是「进行中」状态，但没有任何实质进展。原文的 Watchdog 会判断「各个 Worker 是否有实质进展、方向是否偏离整体目标」，这一步是对的。但原文对 Watchdog 的处置只有一种：介入修复。若修复失败，任务是继续挂着，还是被放弃，原文没有说明。一个既不前进也不终止的任务，会持续占用上下文、占用订阅、占用预算，并在全局记忆里保持「进行中」，从而污染 Router 的判断。

孤儿订阅。原文描述了 Worker 可以主动取消订阅，但没有描述 Worker 终止时的自动撤销与引用计数。后续事件继续直通到一个已经不存在或已经结束的会话。轻则浪费算力，重则产生错误回复。订阅是多对多的，撤销需要精确的引用计数，而原文没有描述订阅的生命周期管理。

投机残骸。被丢弃的投机结果仍然占用存储索引。原文说「没有价值就丢弃」，但丢弃的是「采用」，不是「删除」。那些被判定为无价值的尝试，如果不进入一个明确的归档或删除流程，就会在存储与检索索引里持续累积。

悬空引用。链式召回依赖对象之间的 ID 图。任何一次清理都会在图上留下悬空 ID，而召回路径一旦经过悬空 ID 就断裂。原文没有描述引用完整性如何维护。

提交槽位未结。这一条是本报告第六节建议引入提交门之后新增的：若对外动作先进入暂存区再提交，那么暂存区本身也需要结清机制。一个已经准备好但既未提交也未取消的动作，会在暂存区里永久停留，并在某次重试中被误提交。这是补一个机制所引入的新问题，必须与结清模块一起设计。

五类残留的共同点是多数不触发告警，主要产生成本与不确定性；其中孤儿订阅与悬空引用还可能直接导致错误回复与召回断裂。因此它们很少被告警捕获，通常只表现为单位成本缓慢上升。

7.3 结清的定义与状态机

本报告把「结清」定义为一个可判定的状态，包含三个条件：任务进入终态；该任务占用的四类资源全部释放；终态及其原因写入日志。

四类资源分别是对外动作槽位、订阅关系、上下文存储与预算余额。

对应的状态机如下。

当前状态 可迁移至 迁移条件 必须记录
受理 分派、已合并、已放弃 路由判定、判重命中或人工撤销 受理来源、判定依据
分派 执行、已合并、已放弃 Worker 接收、判重命中或拒绝 分派目标、版本号
执行 待验收、已放弃、已过期 产出完成、预算耗尽、静默超时 产出标识、消耗
待验收 已结清、已合并、已放弃、已过期 人验收、世界回执、人工撤销、超时 验收方式、验收者
已结清 终态 — 结果回执
已放弃 终态 — 放弃原因、否决理由
已合并 终态 — 合并到哪个任务
已过期 终态 — 过期阈值

状态机本身不复杂，但它强制执行两件在原文中被省略的事：任何任务都必须有终态；任何终态都必须有原因。第二件事直接产生本报告在第六章提到的否决记忆——放弃原因是唯一能自然积累下来的负面知识。

状态机中「已合并」一行值得单独说明。在去重失效的场景下，同一意图会产生多个任务。这时正确的处理不是让它们并行了事，也不是简单取消其中一个，而是把后来的任务合并到先到的任务上，并把两条事件的来源都记在合并记录里。合并是结清的一个子类，它同时解决了一部分去重问题。

7.4 回收器：为什么必须是确定性的

结清需要有人执行。原文的 Watchdog 是现成的候选，但它不适合独立承担这件事，原因有两个。

第一，Watchdog 与主系统共享同源失效。原文用模型判断 Worker 是否有实质进展，这个判断本身依赖于同一个模型家族。若模型对「进展」的理解有系统性偏差，Watchdog 会与 Worker 犯同一类错误。这是验证器与被验证器同源时的固有风险，统计学上称为相关误差：两个同源判断的一致性很高，但联合准确率并不会因为多加一个判断者而显著提高。

第二，语义判断不可靠时需要一个确定性兜底。判断一个任务是否「真的做完了」是语义问题，任何模型都会出错。但判断一个任务是否「超过了预算」是算术问题，不会出错。

因此本报告建议，回收器以确定性规则为主、语义判断为辅。主规则是四条：超过预算则结清；超过静默期则结清；订阅对应的 Thread 已关闭则结清；对外动作槽位超时未提交则取消。这四条都不需要模型。语义判断只在任务看起来「还在动但方向可疑」时作为补充，且其输出只能触发「上交给人」，不能直接改变任务状态。

这个分层与原文自己的「程序快路径加模型慢路径」是同一个思路。原文把它用在了事件过滤上，本报告认为它同样适用于任务回收，而且更必要——因为回收的错误代价高于过滤的错误代价。

7.5 预算应当是一等公民

原文的讨论中，预算是隐含的：Worker 会消耗 token，Router 会消耗 token，但没有任何地方说一个任务最多能消耗多少。

缺少预算定义会带来一个结构性后果：系统没有内在的停止条件。任务的终止只能来自「做完了」或「人叫停」，而两者都不可靠。前者依赖模型的自评，后者依赖人的在场。

把预算提升为一等公民，意味着在任务受理时就分配四项上限：token 预算、工具调用预算、墙钟预算、对外动作预算。任何一项耗尽，任务进入「已过期」并以「预算耗尽」为原因结清。

这带来两个好处。其一，成本可预测：一个任务的最坏成本在受理时就已经确定，这使得这套架构可以被采购、被审计、被按项目核算。其二，僵尸任务自动消失：僵尸的定义就是「持续消耗但不产出」，而预算耗尽是一个确定性的终止条件。

本报告认为，第二点是这套架构从「团队内部工具」走向「企业级系统」的关键一步。企业内部可以容忍不确定的成本，采购流程不能。

7.6 这个缺口为什么在账上看不见

结清缺口的隐蔽性来自成本的分摊方式。

一个僵尸任务不会产生一笔可以指认的支出。它每轮只消耗一点上下文，分布在许多次调用里；它不报错，不触发告警，也不出现在任何一个任务的成功率统计里。它唯一的表现是：单位产出的成本缓慢上升。

而这个表现与架构开销无法区分。原文报告的成本变化是「去掉直通后 token 增加 37%」，这是一个可归因的变化。僵尸任务造成的成本上升没有这样的对照，它会被归入「这套架构本来就贵」的范畴。

因此，结清缺口会以「效率莫名下降」的形式出现，而不是以「故障」的形式出现。这也是本报告主张把「僵尸任务占比」列为常规指标的原因——它是唯一能把这类成本从总账里分出来的量。

八、验收制度：三类场景，三种架构

至此，前四节处理的是这套架构在内部是否自洽。本节处理一个外部问题：它在什么样的场景里成立。本报告认为，答案取决于一件原文没有讨论的事——验收延迟。

8.1 一个已经成立的结论

先说明本节的起点不是新的。

把验证视为约束条件，在 2026 年的经济学文献中已经有系统论述。Catalini、Hui 与 Wu 在《Some Simple Economics of AGI》中提出，当执行成本指数下降时，真正的约束转移到验证一侧：人验证、审计并为结果承担责任的能力，受生理与组织边界限制，无法同步扩张。三位作者把这一不对称称为「可测性缺口」，并推断 rents 会向可验证的地面真值、来源证明与责任承保迁移。

这一结论与本报告的问题直接相关，但它是一个宏观经济学判断，不直接回答架构问题。本节的增量在于把它落到工程层面：按验收的性质把场景分类，并说明每一类对架构的要求。

业界的零散观察也指向同一方向。围绕人在回路的产品设计，已经出现一类经验判断：当审核请求连续出现数百次且绝大多数为正常时，审核者会退化为盖章，此时增加审核关口的系统反而更容易放过危险动作。这一观察本报告未取得可核对的原始研究，列入文末待核实清单，此处只作为方向性提示，不作为论据。

8.2 两个维度与三类场景

本报告用两个维度切分场景。

第一个维度是可读性：产出本身能否被人直接检视。第二个维度是可判定性：检视能否确定产出的正确性。

两个维度交叉，得到三类有实际意义的场景。第四象限（既不可读又可判定）不存在，可以忽略。

场景类别 产出的形态 人能否读 读能否判定对错 典型例子 验收延迟
第一类 变更与文本 能 能 代码改动、文案、报表 秒到分钟
第二类 决策与名单 能 不能 寻源名单、投放名单、候选人名单 天到月
第三类 复杂产物 不能 不能 超人类策略、大规模组合优化 无法验收

三类的差别不在难度，而在验收的性质。第一类的验收是审阅，第二类的验收是归因，第三类的验收在人类能力之外，只能靠事先约束与过程监督。

8.3 原文的架构只覆盖第一类

原文的整个设计，从 Router 汇总 Worker 结果、到「只在需要决策或验收时发送通知」、到「单次回复不超过 100 词」，都建立在同一个前提上：人能读懂产出，并据此判断对错。

这个前提在第一类成立。它也解释了为什么原文选择研发协作作为主场景——代码改动恰好是第一类里最成熟的一种。

第一类有一个其他类别不具备的性质：产出是自证的。一份代码改动，在同一个介质里就包含了判断所需的信息：改了什么、为什么改、测试是否通过、有没有影响其他模块。审阅者不需要去外部世界取证，就能做出相当可靠的判断。

这个性质不是 Agent 带来的，是软件工程五十年的积累带来的。版本控制让变更可比对，测试让行为可验证，持续集成让结果可复现，代码评审让责任可追溯。这四样东西构成了一套现成的验收基础设施。Coding agent 之所以率先落地，很大程度上是因为它落在这套基础设施上，而不是因为它的产出天生更容易验收。

这个判断有一个可以直接检验的推论：把同一套架构搬到没有这套基础设施的领域，收益会明显下降。不是因为架构变差了，而是因为验收成本从系统侧转移回了人侧，而人侧没有扩容。

8.4 第二类：制造业寻源的验收即归因

制造业的寻源场景属于第二类。

一次寻源的产出通常是一张企业名单，附带联系方式、主营产品、规模与所在地。这张名单是可读的：每一行都能看懂。但它不可判定：没有任何一种阅读方式能告诉你，这家企业会不会回复、会不会报价、能不能做这个规格、交期是否可信。

判断只能来自外部世界。发出去的消息有没有回，回了之后有没有报价，报价之后有没有样品，样品之后有没有订单。这条链条的周期以周计，长的时候以季度计。

这带来一个直接后果：抽查不是验收。假设一百家里有五家实际不合格，随机抽十家检查，至少发现一家的概率约为 41.6%；若不合格率为 10%，概率约为 67%。也就是说，一个看起来勤勉的抽查流程，在这两档不合格率下，漏检概率都在三成以上。抽查提供的是心理安慰，不是质量控制。

第二类真正需要的是归因能力：当一条线索最终没有成交时，系统能否回答「这条线索是怎么来的」。是哪个查询词召回的，命中了哪条筛选条件，当时的置信度是多少，谁在什么时候把它发出去的，对方的反馈是什么。

要做到这一点，架构上有三处与原文不同。

其一，Worker 的产出必须是结构化对象，不是散文摘要。每一个候选企业需要携带：企业标识、来源、召回理由、证据链接、置信度、以及这条记录的产生时间。原文的 Router 把 Worker 的结果压缩成一段话交给用户，压缩的方向与归因的要求相反——摘要丢掉的恰恰是归因所需的字段。

其二，Router 的对外输出应当是待办清单，不是汇报。人在这里的角色不是读者，是执行者：这批线索要发给谁、用什么话术、什么时候跟进。

其三，系统需要一个结果回传接口。世界的结果必须能被写回同一张表，并与产生它的那次检索建立连接。原文的五个模块里没有任何一个负责这件事，因为它假定验收发生在系统内部。

这三处差异可以归结为一句话：第一类的验收层是审阅层，第二类的验收层是结清层。审阅层回答「这个产出看起来对不对」，结清层回答「这个产出后来怎么样了」。

8.5 结清层的三个字段

若要在第二类场景中落地这套架构，本报告建议结清层至少记录三个字段。

产出标识：这条产出属于哪一次任务、哪一个查询、哪一版筛选条件。它使得任何一条后续结果都能被追溯回产生它的动作。

对外动作：这条产出被以什么形式、在什么时间、发给了谁。它把「系统内部的动作」与「外部世界的动作」连起来，也是责任归属的依据。

结果回执：对方如何回应，包括无回应。无回应也是回执，而且是最重要的一种——它区分了「没有发出去」与「发出去了但没回音」这两种完全不同的失败。

三个字段齐备之后，验收的定义发生变化：从「人点了通过」变成「世界给了回执」。这个变化的实质是把验收从主观判断转成客观记录，从而使验收可以规模化——因为记录不需要人的注意力。

人在第二类里的角色随之改变：从逐条审阅者，变成抽样审计者与例外处理者。这与第一类里人的角色不同，而与质量控制部门的角色相同。

8.6 第三类：不可验证与事先约束

第三类场景在制造业的日常经营中不常见，但在一些高价值决策中会出现，例如大规模产能排布、跨区域的供应链重构、长周期的投资组合。这类产出的正确性超出人的判断能力，验收在原则上不可能完成。

对这一类，本报告只给一个方向性判断：可行的路径不是提高验收能力，而是把控制点从事后移到事前。具体而言，是把人的作用从「判断产出对不对」改为「设定约束并监督是否越界」——预算上限、风险敞口、不可触碰的清单、必须留痕的环节。

这与本报告第六节提出的提交门是同一个机制。差别只在于，第一类与第二类的提交门主要防的是模型的失误，第三类的提交门防的是人的判断力不足。

8.7 本节对原文的总体判断

原文第 9 节写道，随着模型执行单个任务越来越少需要人工干预，「限制生产力进一步提升的瓶颈正在转向人的注意力」，系统使「人类得以从具体的执行细节进一步上移到更高层的决策与验收」。

这个判断在第一类成立，而且原文给出的架构在第一类里是有效的。但它把「验收」当成了一个统一的动作，而验收在不同场景里的性质差别极大。原文没有区分这一点，因为它选择了验收条件最好的那个场景。

这不是原文的缺陷。一份面向自身研发场景的架构说明，没有义务覆盖其他场景。但对准备采纳这套架构的团队来说，这个区分是决定性的：如果他们的业务落在第二类，那么照搬这套架构会得到一个运转良好但无法评估的系统——任务完成得很快，界面很清爽，但没人能回答这些产出到底有没有用。

本院在制造业寻源场景中接触到的高价值 Agent 应用，多数落在第二类。这是本报告认为最需要被说清楚的一件事。

九、度量：把「注意力」变成一个可以计算的量

原文用「人的注意力」作为整套架构的出发点，但只给出了「一个人通常只能同时跟进 3 到 5 个活跃 Session」这一经验观察，没有给出可操作的量化指标。这不影响架构设计的价值，却使得这套架构无法被评估，也无法被改进。

9.1 原文报告的四个指标

原文在实验部分报告了四个量：任务完成时间的 p50 与 p95、Router 需要做出的决定数、读缓存 token 总量、批大小与单次请求耗时。

这四个量都是系统侧指标。它们能回答「系统跑得多快、花多少算力」，不能回答「人因此多做了多少事、少犯多少错」。

对一个以人为出发点设计的系统而言，这个指标集是不完整的。更麻烦的是，只有系统侧指标时，任何优化都会自然地向系统侧倾斜：延迟更低、token 更少，看起来就是进步，哪怕它让人更累。

9.2 建议补充的八个指标

下表的八个指标多数可以从现有事件日志中计算，前提是日志字段在架构设计阶段就定好；其中 M1 依赖人工抽检，M4 需要记录人在系统上投入的时间，这两项需要单独的数据来源。

编号 指标 定义 计算方式 用途
M1 路由准确率 事件被分派到正确 Worker 的比例 人工抽检 1%，按「错分或不必要分派」计错 判断 Router 是否可靠
M2 直通命中率 经订阅直通的事件占全部事件的比例 直通事件数 ÷ 事件总数 衡量 Router 负载结构
M3 每验收产出 token 单位被验收产出的 token 消耗 区间内 token 总量 ÷ 被验收产出数 成本效率的主指标
M4 人类分钟每验收产出 单位产出所需的人力时间 区间内人在该系统上的总时间 ÷ 被验收产出数 直接对应注意力主张
M5 投机命中率与浪费率 投机结果被采用的比例与被丢弃部分的成本 采用数 ÷ 投机数；丢弃部分 token ÷ 总 token 判断投机是否划算
M6 僵尸任务占比 超过静默期仍处进行中的任务比例 僵尸任务数 ÷ 任务总数 衡量结清缺口
M7 重复任务率 同一意图被受理多次的比例 重复受理数 ÷ 任务总数 衡量去重能力
M8 返工率 验收后被打回重做的比例 打回次数 ÷ 验收次数 衡量产出质量

M3 与 M4 是本报告认为最重要的两个。M3 把成本归到「被验收的产出」而不是「任务」，这一点与原文按任务统计的区别很大：一个任务跑完但没人验收，不应计入产出。M4 直接测量了 P1 所关于的量，若这个指标没有改善，那么整套架构关于注意力的主张就没有被验证。

M6 与 M7 对应本报告第七、第五两节指出的两个缺口。它们的作用不是提高性能，而是让缺口显形。一个不测量僵尸占比的系统，会以为自己一切正常。

9.3 先定日志字段，再定架构

这八个指标都依赖同一组字段：事件标识、线程标识、任务标识、状态迁移、消耗、执行者、验收方式、外部回执。

这组字段应当在架构确定之前定好，因为字段决定了系统的能力边界。举例而言，若日志只记录「任务完成」，不记录「任务被验收」，那么 M3 与 M4 永远算不出来；若日志不记录「由谁验收」，责任归属就无法落实。

原文在 3.3 节把上下文窗口当作缓存来管理，这个思路很好。同样的思路可以推广到日志：日志不是调试副产品，而是系统的一等资产。本报告在 5.3 节建议以日志序号作为序列点，理由也在这里——一旦日志成为权威，所有指标都是日志上的查询。

9.4 单项指标会被博弈

任何单一指标都会被优化到失真，这套系统也不例外。

若只考核 M3，系统会倾向于挑选容易验收的任务，把难的推给人。若只考核 M1，Router 会倾向于只处理格式最规范的事件，把其余一律判为无需行动，以减少错分与漏派。若只考核 M6，回收器会过早终止任务，把本可完成的任务提前终止。若只考核 M8，系统会倾向于产出最保守的方案。

因此建议以配对方式考核：M3 与 M8 配对，防止为省成本牺牲质量；M1 与 M2 配对，防止 Router 退化为转发器；M6 与 M5 配对，防止过早结清。

这类配对并不新鲜，是绩效度量的常规做法。之所以要在这里写明，是因为 Agent 系统的特殊之处：它的执行速度远快于人的检查速度，一旦指标被博弈，偏差会在很短时间内累积到很大。

十、安全与责任：两个原文点到为止的问题

原文 8.4 节用很短的篇幅讨论了安全与隐私，并明确承认「如果没有办法很好的解决安全与隐私问题，那么 Super-agent 只有在一个很小且可信的范围才能工作」。这个自我判断是准确的。本节沿着它的两条线索往下走。

10.1 BYOM 的能力模型问题

原文 5.2 节的设计是：Agent Loop 在云端运行，执行环境留在本地，端侧只部署一个「不保存会话状态的轻量 daemon，它只负责执行命令与返回结果」。

这个 daemon 的权限，实际上是「在这台机器上执行任意命令」。原文也意识到了风险：「一旦云端的 Agent Loop 遭遇服务端入侵或提示词注入而被攻破，其连接的全部端侧设备都面临被控制的潜在风险。」

要处理这个风险，靠加密或认证是不够的，需要改变 daemon 的能力模型。安全工程里有一套成熟的原则可以借用：最小权限、完全中介、默认拒绝、权限分离。四条的共同含义是：不要给一个通用执行器，要给一组被明确声明、可核查、可撤销的能力。

具体到端侧 daemon，本报告建议三项约束。

第一，命令白名单，而不是 shell。daemon 不解释任意字符串，只接受预先声明的动作类型，每个动作类型有固定的参数结构与固定的输出结构。这样即使云端被注入，攻击者能做的也只是在已有的动作集合里选择，而不是执行任意命令。

第二，路径与目标的范围约束。每个任务在受理时声明它能触及的路径前缀、仓库、服务与收件人集合。daemon 在执行时校验，越界即拒绝并记录。

第三，短时凭据，且凭据不进上下文。原文已经提到「让 Agent 能够在完全不接触凭据本身的情况下使用凭据」，方向是对的。需要补充的是执行位置：凭据不应出现在模型的上下文里，也不应出现在 daemon 的通用 shell 里，而应只出现在 daemon 与目标服务之间的那一次调用中。安全领域关于信息隔离的经典讨论指出，只要一段信息能被读入一个可编程的实体，它就有办法通过某种输出通道泄露出去。因此「不接触」必须由接口形状保证，不能由提示词保证。

10.2 完全中介：安全边界应当放在哪里

原文的事件驱动设计让 Agent 能够被更广泛的环境驱动，这本身扩大了攻击面。原文 3.1 节的两级过滤——程序层策略加语义层策略——是很好的降噪设计，但它不是安全边界。

原因在于语义层策略本身是一个语言模型，它的输入是不可信的文本。任何能向群里发消息的人，都可以构造一条能通过语义过滤的消息。过滤降低的是噪音量，不是攻击成功率。

同理，原文描述的「持续关注公共群聊，在无人 @ 的情况下主动识别缺陷并提交修复 Pull Request」这一行为，在内部可信群里是合理的，在对外开放的群里则是把「任何人发一句话」变成了「触发一个拥有完整工具权限的 Worker」。

安全边界的正确位置在对外动作之前，而不是在事件进入之时。这就是本报告第六节提出的提交门：任何越过沙箱边界的动作，必须在策略门处校验，校验的依据是动作类型、目标范围、预算与频率，而不是这句话看起来像不像一个请求。

这个设计与安全工程中的端到端原则一致：一项功能若其正确性只能依靠端点掌握的信息来判断，把它放在中间层实现就既冗余又不可靠。判断「这个动作该不该做」所需的信息在策略端，不在事件端，因此检查必须放在策略端。

10.3 可归属主体

原文没有讨论责任归属。这不是疏忽，而是场景使然：在团队内部，责任归属由组织关系自然解决。

一旦这套系统进入企业采购或对外服务，责任归属就变成一个前置条件。企业无法采购一个「出了事找不到人」的系统。这不仅是法律问题，也是流程问题：任何一次对外动作，都需要一个可以被追问的主体。

因此本报告建议，把「可归属主体」作为架构的一等约束：每一个越过沙箱边界的动作，都必须在日志中绑定一个责任主体，这个主体可以是一个自然人，也可以是一个注册的服务身份，但不能是「Agent」这个笼统的称呼。

与之配套的是日志的不可篡改。只追加、带哈希链的日志是常见做法，成本不高。它的价值不在于技术，而在于事后：当需要判断某个动作是谁在什么依据下做出的时候，一份可以被修改的日志等于没有日志。

十一、结论

本报告的结论分为两组。第一组基于原文公开数据的复算，可以被读者独立验证；第二组是设计判断，属于可以争论的范围。

11.1 基于复算的结论

第一，Router 的吞吐余量被高估。按原文 7.2 节的批大小与单次请求耗时计算，单个 Router 会话在每分钟约 40 条 Trigger 时利用率约为 0.93，已接近满负荷。原文「仍未触及单 Router 的吞吐瓶颈」的判断与自身数据不符。且批大小 2.8 与「服务期间的自然到达量」 2.60 几乎相等，说明测到的批处理与排队积压无法区分。

第二，7.1 节的实验没有检验它的主张。实验测量的是单任务完成时间，主张的是人力吞吐量；二者不构成单调关系。实验缺少「强制委派」这一关键对照，因此无法把架构效应与提示词效应分开。以五个样本报告 p95，实际上报告的是最大值。

第三，成本的中心在上下文读取，不在任务执行。每个工作请求对应约 116 万读缓存 token，若读缓存按输入价格十分之一计价，等效全价输入约 11.6 万 token。这个数字高度依赖工作请求在总消息中占 6.7% 这一负载结构。

11.2 基于设计判断的结论

第四，Router 同时承担路由与全局记忆，是长程记忆瓶颈的结构性来源。路由要短上下文，记忆要长上下文，两者耦合使每一次分派都要为整个记忆付费。建议以只追加日志的序号作为序列点，会话只持有工作集，全局记忆改为从日志派生的物化视图。

第五，五个模块覆盖了任务的受理、执行与验收，缺结清。长期运行会产生僵尸任务、孤儿订阅、投机残骸、悬空引用与未结的提交槽位五类残留。结清需要状态机、确定性回收器与一等公民的预算三项要件。

第六，投机执行缺少提交边界。「没有价值就丢弃」只在沙箱内成立，而原文举的例子已经越过沙箱。对外动作应当先进入暂存区，再经策略门提交。

第七，操作系统类比在进程、中断、缓存、看门狗四处成立，在事务与进程号两处缺失，而这两处恰好对应最薄弱的两块：对外动作的提交边界与跨信道的任务去重。

第八，验收按性质分为三类，原文架构只覆盖第一类。第一类的验收是审阅，第二类的验收是归因，第三类的验收只能靠事先约束。制造业寻源属于第二类，需要的是结清层而不是审阅层。

11.3 对准备采纳这套架构的团队的建议

若要落实成一条可操作的建议，本报告认为顺序应当是：先做强制委派的对照实验，再决定是否引入双层架构。

原因很直接。强制委派只需要几行 harness 代码，它检验的是「取消模型裁量权」能带来多少收益。若它能达到双层架构的大部分效果，那么团队可以用极低的成本获得主要收益；若它明显落后，才说明双层结构本身有价值，此时再投入 Router、订阅、链式召回与 Watchdog 是合算的。

原文实际上已经提供了支持这个建议的证据：在中性提示下模型五次全不委派，在明确提示下四次委派且效果改善。这说明提示偏好会显著改变委派率；至于把委派改成强制是否同样有效，仍需那个对照实验来回答。这一点在原文的叙述中被架构层面的讨论盖过了。

第二件事是先把日志字段定下来。八个指标里多数依赖同一组字段，而这些字段一旦在系统上线后再补，历史数据就补不回来。

第三件事是给任务加预算。这是把系统从内部工具变成可采购系统的最低门槛，也是清除僵尸任务的唯一确定性手段。

11.4 关于这份架构说明本身

本报告通篇在做复算与追问，这里应当给出一个整体判断。

这份架构说明的价值，不在于它提出了多少新概念——它自己也承认没有提出新理论。它的价值在于把一个正在被大量团队模糊感受到的问题写清楚了：当 Agent 从「一次对话」变成「持续在场」时，系统的形态会发生什么变化。它给出的五个模块，是这个变化的一个自洽答案，而且是一个可以照着实现的答案。

它的不足集中在两处。一是证据的覆盖范围小于结论的覆盖范围：五个模块里，双层架构只被部分触及，事件驱动只触及订阅直通一项，而叙述的语气是整体性的。二是它把「验收」当作一个不需要定义的动作，因此没有看到不同场景对验收的不同要求。

这两处不足都不是能力问题，而是体裁问题。一份团队内部的架构说明，本来就不必承担外部有效性检验。但当它被当作行业范式传播时，这两处会被继承下来。本报告的工作，就是在这份说明被继承之前，把可以核对的部分核对一遍。

十二、待核实清单

以下各项在本报告写作时无法闭合，列出以备后续核对。本报告未在正文中以推算值替代这些缺口。

  • 原文 7.2 节未定义「单次请求耗时」与「单个决定分摊的推理时间」两个指标的口径。二者在批大小为 1 时不相等（2.5 秒对 6.4 秒），无法用同一服务时间解释。本报告的利用率复算假定前者为服务时间，若该假定不成立，第三节的数值需重算。
  • 原文未披露 Router 与 Worker 各自使用的模型型号、参数量与上下文长度，因此第三节关于「上下文长度不是当前约束」的判断只能按主流模型的常规上下文规模估算。
  • 原文未给出 token 计价，本报告只使用 token 量与比值，未折算金额。
  • 原文称「一个人通常只能同时跟进 3 到 5 个活跃 Session」，未说明样本、测量方法与人群。本报告在 2.3 节将其作为未标注来源的经验值处理，并指出其可能对应三种不同机制（工作记忆容量、中断恢复成本、社会协调容量），三者的架构含义不同。
  • 原文实验的 300 条消息中工作请求占 6.7%，未说明该比例的现实依据。第四节关于成本结构的判断依赖这个比例。
  • 本报告未取得原型仓库 dsh-superagent-prototype 的代码，第六节关于提交门的建议是设计推论，不是对实现的描述。
  • 第六、七节提到的 LLMOS、AgentOS、vMem、暂存副作用、负面知识等方向，系 2026 年 10 月 31 日公开检索所得，本报告未逐篇核对原文，正文只作方向性引用。
  • 第八节引用的「连续数百次正常审核后审核者退化为盖章」这一业界观察，本报告未取得可核对的原始研究，正文已标注为方向性提示，不作为论据。
  • Catalini、Hui 与 Wu 将工作划分为四类，本报告未逐条比对其分类与本节三类验收场景的对应关系，二者的关系有待专门讨论。

十三、参考文献与方法说明

13.1 一级材料

  • DeepSeek Harness 团队：《Super-agent 设计探索：迈向更自主的 Agent 系统》，2026 年 10 月 31 日。本报告全部 E1、E2 级材料出自此文。
  • 同期媒体转述：IT之家、驱动中国、观点网、读懂AI时代、同花顺等，2026 年 10 月 31 日。用于判断公共讨论的分布，不作为技术论据。

13.2 二级文献

  • Anthropic：《Scaling Managed Agents: Decoupling the brain from the hands》，2026 年 4 月。用于 5.3 节关于无状态 harness 与外部会话日志的讨论。
  • Catalini, C., Hui, X., Wu, J.：《Some Simple Economics of AGI》，arXiv:2602.20946，2026 年 2 月。用于 8.1 节关于验证带宽与可测性缺口的讨论。
  • Kung, H. T., Robinson, J. T.：《On Optimistic Methods for Concurrency Control》，1981 年。用于 6.3 节关于提交阶段校验的类比。
  • Saltzer, J. H., Schroeder, M. D.：《The Protection of Information in Computer Systems》，1975 年。用于 10.1 节最小权限、完全中介、默认拒绝、权限分离四项原则。
  • Saltzer, J. H., Reed, D. P., Clark, D. D.：《End-to-End Arguments in System Design》，1984 年。用于 10.2 节关于检查位置与信息分布的论证。
  • Lampson, B. W.：《A Note on the Confinement Problem》，1973 年。用于 10.1 节关于信息隔离必须由接口保证的判断。
  • Denning, P. J.：《The Working Set Model for Program Behavior》，1968 年。用于第五节与第六节关于缓存与工作集的类比。
  • Cowan, N.：《The Magical Number 4 in Short-Term Memory: A Reconsideration of Mental Storage Capacity》，2001 年。用于 2.3 节关于跟踪容量上限的讨论。
  • Mark, G., Gudith, D., Klocke, U.：《The Cost of Interrupted Work: More Speed and Stress》，2008 年。用于 6.5 节关于中断恢复成本的量级判断。

13.3 方法说明

本报告的全部计算均可由正文公式复现。第三节的利用率公式为 ρ = (λ / b) × S；服务时间弹性由两点幂律拟合得到，拟合式为 S = 2.5 × b^0.432；容量曲线为 C = b / S。第四节的单位成本由 2323 万 token 除以 20 个工作请求得到。第八节的抽查检出概率按超几何分布计算，公式为 1 − C(N−D, n) / C(N, n)，其中 N 为名单规模，D 为不合格数，n 为抽查数。

本报告承认一项方法局限：复算依赖原文公开的三个读数，样本点为两个，无法做稳健性检验。第三节因此给出的是量级判断，不是精确估计。若原文后续公布完整的压测序列，本报告的结论应当据其修正。

13.4 关于本报告的立场

本报告由天下工厂产业研究院撰写。本院运营制造业企业数据库，并在寻源场景中使用 Agent 系统，因此第八节关于第二类验收的讨论包含本院的实践经验。这一背景可能带来立场偏向，读者在阅读第八节时应当考虑这一点。前七节的分析不依赖本院的业务数据，仅使用原文公开材料与公开文献，可以独立核对。