验收瓶颈：Super-agent 架构换代的产业含义与投资判据

一、本报告的问题

1.1 一份内部工程说明，为什么会被当成行业范式

2026 年 10 月 31 日，DeepSeek Harness 团队发布了一篇架构说明，标题是《Super-agent 设计探索：迈向更自主的 Agent 系统》。发布后数小时内，中文技术媒体的标题高度接近：「双层架构」四个基础特征与五个模块。

传播层面发生的事情很清楚：一套原本属于团队内部工程路线图的东西，在二十四小时内被读成了整个行业的技术风向。

这个读法并不是空穴来风。这篇说明确实把一个正在被大量团队模糊感受到的变化写清楚了——Agent 正在从「一次对话」变成「持续在场」。过去用户打开一个窗口，问一句，等一个答案，关掉；现在系统持续观察消息流、邮件、代码评审与运行结果，在没有人下达指令的时候自行推进。这个变化是真实的，而且不只发生在软件开发场景。

问题出在下一步。当一份内部说明被当作范式传播时，它的边界会被一并省略。原文自己写了两句话，恰好是边界。

第一句在实验部分的开头：「由于实验基于合成负载与简化环境，部分设置还可以更加严谨，以下结果仅作为初步参考。」第二句在结语：「我们并没有提出全新的理论，而是将计算机系统中经典的工程思想应用到了 Agent 系统的构建中。」

这两句话把这份材料的性质说得相当准确。它是一份可实现的工程路线图，不是一份经过外部检验的技术结论。把它作为判断依据之前，需要补一道工序：先确认哪些部分能够被核对，再判断这些部分能够推广到多远。

本报告做的就是这道工序的下半段。

技术层面的核对已经由本院在《Super-agent 架构的独立复算》一文中完成。那篇报告逐条比对原文数据，给出了三条可由读者独立复算的结论，另附若干设计判断。本报告不再重复推导过程，只把那些结论往前推一步，翻译成产业与投资能够使用的判断。读者不需要先读技术复算，也能读完本篇；需要核对公式与原始数据时，再回到那一篇。

1.2 三个问题

对一份架构说明，工程师关心的是能不能照着实现。分析师与投资人关心的是另外三个问题。

第一个是余量。这套架构现在离它的容量上限还有多远？余量决定竞争节奏——余量充足，说明这一代架构还能用两三年，竞争焦点在功能；余量见底，说明基础设施层很快要换一遍，竞争焦点在成本与调度。这个判断直接影响投入的时间窗口。

第二个是护城河。它相对简单方案的优势，能不能被更便宜的方式复制？如果能，那么架构本身不构成壁垒，价值会流向别处；如果不能，那么先做出这套架构的团队会获得一段真实的结构性优势。这个判断决定该投架构，还是投架构之上或之下的东西。

第三个是边界。它在哪些场景成立，在哪些场景不成立？这个判断决定垂直赛道怎么选。同一套技术在软件工程里可能是即插即用，在制造业寻源里可能根本跑不起来，原因往往不在模型能力，而在别的地方。

三个问题分别对应本报告的第三、第四、第七章这三章。其余各章是支撑：第二章把技术主张翻译成商业命题，第五、第六章处理原架构的两处结构性缺口，第八、第九章讨论度量与责任这两个采购前置条件，第十章给出价值迁移的判断，第十一章给出一份可以直接拿去用的尽调清单，第十二章把结论落回制造业，第十三、第十四章交代待核实项与方法来源。

1.3 证据分级与判断纪律

本报告沿用技术复算的证据分级，在关键推算与关键判断处标注来源等级，读者可以据此决定信到什么程度。

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

判断纪律有两条。第一，原文没有披露的数据，不用推算值去补全结论；材料不足的地方进入第十三章的待核实清单，正文不给替代读数。第二，本报告算出的数字与原文数字不混在同一句结论里，凡是推算值都单独标注。

还有一条只对本报告生效的约束：本报告不给出任何市场规模数字。原因在方法论上——Agent 架构这一层的市场边界目前无法划定，谁算在里、谁算在外，不同口径能差出一个数量级。用构造出来的总量去支撑投资判断，是把不确定性藏进了一个看起来很确定的数里。本报告因此只讨论结构：价值从哪里产生，向哪里迁移，被谁捕获。

1.4 结论先行

把后面各章的判断压缩成五条。

第一，这套架构的工程余量只剩百分之七，与原文「仍未触及单 Router 的吞吐瓶颈」的判断不在同一个量级。按原文自己公开的到达速率、批大小与单次请求耗时复算，Router 在每分钟约 40 条 Trigger 时的利用率约为 0.93。原文的判断是「仍未触及单 Router 的吞吐瓶颈」，数据支持的是已经贴着瓶颈运行。这意味着「持续在场」这一代系统的扩容问题，会比原文预期的时间更早到来。

第二，它的核心优势目前没有被证明来自架构。原文实验缺一个关键对照：强制委派的单会话。没有这个对照，就无法区分「双层结构带来了收益」与「取消了模型自行决定分不分工的裁量权带来了收益」。后者的实现成本是几行代码。这道对照不做，架构的溢价就说不清楚。

第三，原架构缺一个模块，而且缺得很整齐。五个模块全部在回答「怎么开始」与「怎么持续」，没有一个在回答「怎么结束」。长期运行会产生五类残留，它们不产生错误，只产生成本，因此不会被告警捕获，会以「效率莫名下降」的形式出现。

第四，这套架构只在三类场景中的一类完全成立。按验收延迟划分，软件工程属于「可读可判定」，原文架构成立；制造业寻源属于「可读不可判定」，需要的是结清层而不是审阅层；第三类不可读的场景，当前架构无法承担。这条判据比模型能力更能预测一个垂直 Agent 能不能落地。

第五，价值会从「谁能生成」转向「谁掌握验收所需的事实」。生成能力的成本仍在快速下降，验收能力受人的判断力与组织授权约束，两条曲线的差距在扩大。谁手里有验收所需的那部分事实——回执、结果、后续行为——谁就占据了这条链上最难被替代的位置。

二、把架构主张翻译成商业命题

2.1 原文的七个命题

要判断一份架构说明的商业含义，先要把它的主张写成可以判定真假的句子。原文的论证可以拆成七条。

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

这个拆法并不过分。原文自己在实验部分开头就把 P7 的范围限定了——「以下结果仅作为初步参考」。本报告要做的，是把这个限定逐条落到命题上，看哪几条落在范围内、哪几条落在范围外。

2.2 从技术命题到商业命题：三道坎

一个技术主张要变成可以支撑估值的商业命题，需要跨过三道坎。这三道坎不属于技术，但决定技术能不能变成生意。

可复现。 同样的输入，能不能稳定得到同样的输出？这一条决定了产品能不能交付。演示环境里成功一次，与一千家客户各自环境里成功一千次，是两件事。原文自己也承认实验环境经过了简化：编码工作用一个只消耗时间的工具代替，消息间隔与工作时长按四分之一缩放。这两项简化对衡量调度能力是合理的，对衡量可靠性则不够。

可结算。 一次服务的成本，能不能归到具体的一次产出上？这一条决定了产品能不能定价。Agent 系统的成本结构与上一代软件不同：它不是一个固定的许可证，而是随任务长度、上下文规模、重试次数变化的连续量。如果没有把成本归到产出的机制，定价只能靠估算，估算就会被客户质疑，质疑就会拖长采购周期。

可归属。 一个越出沙箱的动作，能不能找到承担责任的主体？这一条决定了产品能不能进入企业。企业内部工具可以没有责任主体，因为组织关系天然解决了这个问题；一旦对外提供服务，任何一次发出消息、提交代码、发送报价的动作，都需要一个可以被追问的主体。

三道坎里，第一道是工程问题，第二道是度量问题，第三道是治理问题。原文的五个模块主要解决第一道的前半段，对后两道基本没有涉及。这不是缺陷——一份团队内部的架构说明，本来不需要承担外部商业化的全部条件。但读者如果拿它当范式，就会把这三道坎的缺口一起继承下来。

2.3 五个模块的证据强度并不相同

原文提出四个基础特征，用五个模块支撑。把每个模块对应的证据摆在一起，覆盖程度的差异相当明显。

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

未覆盖不等于不成立。第五、第六两节描述的能力，在工程上完全可能已经跑通，只是没有以实验形式公开。本报告要指出的是另一件事：这份说明的说服力分布不均。

读者最容易记住的是 7.1 节的 p50 与 p95——12.4 分钟与 15.7 分钟。这两个数字支撑的结论只有一句：双层架构在合成负载下缩短了任务完成时间。它们不支撑「持续在线」「异常自愈」跨设备切换这三项更容易打动人的能力。当媒体把这四个特征与五个模块并排列出时，读者接收到的信息是五项同等确定，实际上证据强度相差一个数量级。

对投资判断而言，这个区别很实际。如果一个团队宣称自己做了「Super-agent 架构」，需要追问的是：它做了哪几个模块，哪几个有对照数据。多数团队目前能拿出的，是双层架构的一部分加事件过滤的一部分，其余是设计文档。

2.4 一个被合并的概念

P1 是整篇的起点。这句话读起来像一条定律，实际上是一个关于当前设计的状态描述。

它成立的前提是：人必须同时承担两件事——跟踪任务状态，承担任务后果。

这两件事的扩展性完全不同。

跟踪状态可以外包。只要有可靠的记录、检索与提醒，一个人跟踪的任务数可以从五个上升到五十个。CRM 系统做的就是这件事，项目管理软件做的也是这件事。它们的价值恰恰在于把「记着」从人脑里搬出去。

承担后果不能外包。验收一个产出，意味着验收者要为这个产出的正确性负责。责任的容量受专业判断力与组织授权约束，不受界面设计约束。一个采购经理可以同时盯着二十张报价单的进度，但真正需要他签字确认「这家供应商可以下单」的，一天可能只有五家——不是因为他记不住，而是因为每一次签字都要消耗他的专业判断与职业风险。

原文用来支撑 P1 的经验观察是「一个人通常只能同时跟进 3 到 5 个活跃 Session」。这个数字没有给出样本、测量方法与人群，只能当作经验值。它的机制可能对应三种不同的限制：工作记忆容量、中断恢复成本、承担后果的容量。前两种可以通过架构与交互降低，第三种不能。

原文把三者合称「人的注意力」，于是在论证上获得了一个便利：只要证明跟踪成本下降，就好像证明了注意力瓶颈被缓解。

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

这个推论在后面几章反复出现。第六章的结清缺口、第七章的验收三分法、第八章的 M3 与 M4 指标，都是这条线的延伸。

2.5 商业命题的翻译结果

把七条技术命题按三道坎过一遍，可以得到一张对照表。

原文命题	商业含义	当前状态
P1 注意力是瓶颈	卖点是「一个人能推进更多任务」	只对跟踪部分成立，验收部分未解决
P2 Session 是实现细节	产品形态可以从聊天窗口解放出来	方向成立，替代形态未定
P3 双层架构兼顾连续与吞吐	可以在同一系统里同时卖连续性与效率	有实验支持，缺关键对照
P4 事件驱动带来主动性	可以从「工具」变成「同事」	只有直通一项有数据
P5 存算分离带来持久在线	可以跨设备、跨场景持续服务	无实验，工程上可信
P6 Watchdog 带来自愈	可以降低运维人力	无实验，工程上可信
P7 在真实负载下成立	可以直接交付企业	原文自陈为初步参考

这张表最重要的读法是最后一列。七条命题里有实验支撑的只有一条半，其余是设计判断或工程常识。这不影响这套架构的价值——一份路线图的价值本来就在于指出方向——但它决定了当前阶段能做哪种投资判断。

能做的是方向判断：持续在场这个方向是对的，会有人做成。不能做的是节奏判断：不能根据这篇说明推断「明年就能大规模铺开」，因为铺开所需要的可复现、可结算、可归属三项条件，原文一个都没有处理。

这三个条件，恰好也是本报告后面几章反复回到的坐标。

三、复算一：余量只剩百分之七

3.1 三个数字就够了

原文 7.2 节为了说明 Router 层的批处理机制，公开了三个量：需要决定的 Trigger 到达速率、平均 batch 大小、单次请求耗时。这三个量足以算出一个排队系统最关键的指标——利用率。

原文给出的取值是：到达速率从每分钟约 1 条提升到约 40 条；平均 batch 大小从 1.0 升至 2.8；单次请求耗时从 2.5 秒增至 3.9 秒。除此之外，原文还给出了「单个决定分摊的推理时间」，从 6.4 秒降至 1.6 秒。

需要先说明口径。原文没有定义这两个量。若按字面理解，「单个决定分摊的推理时间」等于单次请求耗时除以批大小，那么在批大小为 1 时两者应当相等；原文给出的却是 2.5 秒与 6.4 秒，并不相等。因此本报告只用「单次请求耗时」做利用率复算，「单个决定分摊的推理时间」只作方向性引用。

3.2 利用率怎么算

对一个批量服务的系统，利用率的基本公式是：

ρ = (λ / b) × S

其中 λ 是每秒到达的 Trigger 数，b 是平均批大小，S 是单次服务耗时（秒）。直观读法是：系统每秒需要处理 λ/b 个批次，每个批次占用服务器 S 秒，两者相乘就是服务器被占用的比例。

代入原文数据。到达速率为每分钟 40 条，即 λ = 40/60 ≈ 0.667 条每秒；b = 2.8；S = 3.9 秒。

ρ = (0.667 / 2.8) × 3.9 ≈ 0.93

到达速率为每分钟 1 条时，λ = 1/60 ≈ 0.0167；b = 1.0；S = 2.5 秒。

ρ = (0.0167 / 1.0) × 2.5 ≈ 0.042

也就是说，在整个压测区间内，Router 的利用率从约 4% 上升到约 93%。

这与原文的判断不一致。原文的原话是「即使去掉直通使 Router 的峰值负载增加，仍未触及单 Router 的吞吐瓶颈」，紧接着的一句是「因此在我们目前的团队规模下，无需过早对 Router 层做水平切分而牺牲全局上下文的连续性」。

触及瓶颈在工程上有相对明确的含义：利用率接近 1，排队时间随负载非线性上升。0.93 已经落在这个区间。余量是百分之七，与原文「仍未触及单 Router 的吞吐瓶颈」的判断不符。

需要公平地说明一点：这次压测的上限是每分钟 40 条 Trigger，原文并没有声称 40 条是系统的极限。原文说的是，在这个区间内批处理机制有效。这个说法本身没错。问题在于从这个区间内有效，推到未触及瓶颈，中间缺了一步——而在 40 条这个点上，利用率已经到了 0.93，继续往上加，批处理带来的收益会被排队延迟吃掉。

3.3 批大小 2.8 是怎么来的

还有一个更值得注意的地方。

按定义，如果一个系统在一次服务期间新到达的 Trigger 会被合并进下一次调用，那么批大小的自然值就等于一次服务期间新到达的 Trigger 数量，也就是 λ × S。

代入 40 条每分钟的情形：λ × S = 0.667 × 3.9 ≈ 2.60。

而原文测得的平均批大小是 2.8。

两者几乎相等。

这个巧合的含义是：原文观测到的「批处理」，与一个普通的排队系统在负载下自然形成的积压，在数据上无法区分。原文没有给出能区分「攒批窗口」与「排队积压」的读数，例如延迟调度的次数、批的形成时刻分布。从现有数据看，最省力的解释是：前一次调用还没返回的这段时间里，新来的 Trigger 排在了队里，下一次调用把它们一起带上。

这个区分对指标的解释很重要。

如果批处理是主动策略，那么收益可以归因于设计，其他团队照做也能拿到。如果批处理只是自然积压，那么收益不需要设计，任何单线程服务端在负载上来时都会出现同样的曲线。前者是可复制的工程经验，后者是排队论的必然结果。

对投资判断而言，这个区别决定了一件事：原文 7.2 节展示的「单个决定分摊的推理时间从 6.4 秒降至 1.6 秒」，不能被读成「这套架构有特殊的吞吐优化」。它更准确的读法是「负载上来之后，固定开销被摊薄了」。

这不影响系统的可用性。它影响的是可迁移性——一个团队如果照着这段描述去实现一个「主动攒批」的调度器，可能会发现收益远小于预期，因为原文测到的收益本来就不来自调度器。

3.4 对产业竞争节奏的含义

把上面两条合起来，可以得到一个对时间窗口的判断。

第一，这一代「持续在场」架构的工程余量只剩百分之七，与公开叙述所暗示的余裕不在同一个量级。原文的叙述给人的印象是：单 Router 还有很大空间，扩容问题可以往后放。复算的结果是：在原文自己的压测上限处，余量只剩百分之七。这意味着当团队规模扩大、事件密度上升时，水平切分的问题会在比预期更早的时间点变得紧迫。

第二，水平切分会直接损伤这套架构最值钱的部分。原文自己写得很清楚：切分粒度越细，Router 层的并发吞吐量就越高，但分片之间的记忆与上下文连续性就会越低；「在全局记忆问题被解决之前，这一权衡始终存在」。换句话说，这套架构目前处在一个两难里——不切分，吞吐到顶；切分，连续性打折。而连续性正是它区别于普通 Agent Team 的卖点。

第三，这个两难会重塑竞争焦点。2025 年到 2026 年上半年，Agent 产品的竞争焦点是能力：能不能完成任务，能不能调用工具，能不能多步推理。当能力逐渐拉平、架构趋同之后，焦点会转向调度效率与单位成本。谁能用更少的 token、更短的队列、更稳的延迟完成同样的任务，谁就能在同样的价格下活下来。

这个判断有一个可检验的推论：如果这套架构的余量真的只剩百分之七，那么在接下来的一段时间里，公开讨论的重心应该从「架构有几个模块」转向「单位产出的成本是多少」。观察这个转向什么时候发生，比观察又出了几个新概念更有信息量。

3.5 三个可以持续观察的先行指标

对不直接接触系统的观察者，下面三个指标可以从公开材料中间接推断，成本很低。

其一，单次请求耗时随到达率上升的斜率。 如果耗时增长慢于批大小增长，说明批处理还有效，余量还在；如果两者同速甚至更快，说明固定开销已经摊不动，接近上限。原文的数据是：批大小增长到 2.8 倍，耗时增长到 1.56 倍。这个比值衡量的是摊薄效率，不改变 3.2 节量出的余量；它说明的是继续加负载时耗时如何增长，而这个变化会先于故障出现。

其二，批大小与自然到达量的比值。 也就是 b 除以 λS。这个比值接近 1，说明所谓的批处理就是排队；明显大于 1，说明系统真的在做攒批。这个指标不需要内部数据，只要有到达率、批大小与服务耗时三个公开数字就能算。

其三，单位产出的 token 消耗。 原文报告 Super-agent 单次实验的读缓存 token 为 2323 万，实验包含约 20 条工作请求，按此折算每个工作请求约 116 万读缓存 token（E2，本报告推算）。这个量级说明，这套架构的成本中心不在「执行任务」，而在「反复读取上下文」。当模型单价下降时，这个成本会跟着下降；当上下文规模上升时，它会以更快的速度上升。两个方向的力谁更大，决定这套架构的经济性。

四、复算二：实验测的不是它想证明的东西

4.1 主张与测量之间的距离

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

原文 7.1 节测量的却是「任务完成时间」：从工作请求到结果消息的耗时，取 p50 与 p95。这是单任务延迟指标。

两者不是单调关系。

一个系统完全可以在降低单任务延迟的同时降低人力吞吐量。原因很直接：如果它产生了更多需要人验收的小产出，人的切换成本会上升，单位时间内真正结掉的事情反而变少。反过来，一个系统也可以提高单任务延迟而提高人力吞吐量——把多个任务攒到一起集中验收，延迟上升，单位时间完成的任务数增加。

因此，用单任务延迟的排序去支撑关于注意力瓶颈的结论，属于构念效度问题：测量的变量不是主张所关于的变量。

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

同一个错位还出现在实验的另一个简化上。原文 7.1 节把编码工作替换成一个只消耗时间的工具，这个简化本身是合理的，它让实验专注衡量调度与协作能力。但它同时意味着，实验中不存在「产出质量」这个维度。而在真实验里，产出质量正是验收成本的主要来源——一份写得不好但很快的方案，会让验收者花更多时间。

4.2 缺的那个对照

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

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

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

为什么这个对照关键？因为原文自己的数据已经暗示了它的重要性。

在中性提示下，模型五次运行一次都没有调用子代理，所有工作都在主会话中进行，不断被新消息打断，p95 达到 29.5 分钟。改为优先委派提示后，五次里有四次进行了委派，完成时间有所缩短，但仍慢于 Super-agent；剩下一次，模型判断工作「很小」而选择自己执行，形成了原文所说的紫色长尾。

这段描述说明，紫色长尾这一次可以归因于模型对自身工作量的误判：它判断「很小」就自己做，判断错了就堵住整条流水线。但四次委派之后仍慢于 Super-agent，说明失分不只在误判。是否还有结构因素，需要强制委派对照才能判断。

如果问题出在判断，那么解法可以是「不让它判断」。

4.3 两种可能的结果，两种不同的估值含义

若加入强制委派对照，可能出现两种结果，各自的商业含义完全不同。

第一种，强制委派与双层架构基本相当。

这意味着双层架构的主要价值不在于「两层」，而在于「取消了模型的委派裁量权」。收益的来源是：把「要不要分工」这个决定从概率判断变成确定性规则。

这个结论如果成立，影响很大。它的实现成本是几行 harness 代码，不需要 Router，不需要订阅直通，不需要链式召回，不需要 Watchdog。对绝大多数团队来说，这是一个远比整套架构更划算的选择。

对投资的含义是：架构层的溢价被大幅压缩，价值向下游的场景与数据转移。一个只有几行代码的差异化，撑不起一层基础设施的估值。

第二种，强制委派仍明显落后。

这才能说明双层结构本身带来了收益。可能的机制有几个：Worker 不直接对外回复所带来的输出收敛；订阅直通带来的 Router 负载下降；上下文隔离带来的单任务质量提升。原文在 7.1 节给出了其中一项的证据——去掉直通后，完成时间基本不变，但 Router 的决定数增加约 30%，总读缓存 token 从 2323 万增加到 3177 万，增幅约 37%。这是订阅直通有效的一个干净证据。

在这个结果下，架构层的价值成立，先做出这套系统的团队有结构性优势，围绕 Router、订阅、召回做工程优化的公司有投入价值。

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

4.4 护城河可能只有几行代码深

这是本报告认为对投资判断最有用的一条。

在技术评估里，一个常见的错误是把「有效」等同于「这个方案有效」。原文的实验确实证明了完整 Super-agent 比单会话快。但它没有证明快的原因是什么。

从数据形态看，最省力的解释是提示词效应：中性提示下模型不委派，优先委派提示下模型四次委派，性能随之改善。这条链条上，起作用的变量是「模型是否被允许自己决定分工」，而不是「系统有几层」。

如果这个解释成立，那么这套架构真正的创新点，其实是「把一件需要模型判断的事，改成了不需要判断的规则」。这确实是一个好设计——把不确定的判断换成确定的机制，是系统工程里的经典手法。但它的护城河深度，与它被描述出来的复杂度不匹配。

对投资人，这条判断可以变成一个具体问题：这家公司的技术优势，有多少是「我们想到了这个结构」，有多少是「我们把这个结构调到了能跑」？前者可以被复制，后者需要时间与数据。两者在估值上应该分开算。

4.5 一条可用的判据

由此可以得到一条判据：看一家 Agent 公司有没有做过对照实验。

具体问三个问题。第一，你们有没有测过「强制委派」或等价的简化方案？第二，如果有，结果差多少？第三，如果没有，你们怎么知道收益来自架构而不是提示词？

前两个问题有明确答案的公司，说明它的技术判断建立在自己做过的实验上。第三个问题答不上来的公司，很可能是在用一个未经验证的结构解释一个可以从别处解释的现象。

这条判据比看架构图有用得多。架构图画得越漂亮，越需要证据支撑；一份只有五个模块图、没有对照实验的技术材料，和一个只有两页纸但有干净消融实验的技术材料，后者更值得相信。

五、结构缺陷一：路由与记忆绑在一起

5.1 两项职责的扩展方向相反

原文把 Router 层定义为常驻的全局路由层，并且明确写了它的三重身份：全局的序点、协调点和记忆。

原文也意识到了这个节点的风险，紧接着写了一句话：「为了避免这一全局节点成为系统的性能瓶颈，Router 层在设计上不直接执行具体任务，只负责人类交互与任务分派，甚至可以不配备 Bash 工具。」

这个处理是对的：把重活挪走，让中心节点只做轻量判断。但它只处理了一半。Router 承受的负载不只是「执行任务」这一种，它还承担着「记住一切」这一种。

问题在于，这两项职责对上下文的要求方向相反。

路由希望上下文短。 一次路由决策的输入，本质上只需要三样东西：这条事件是什么、它该归谁、当前系统里有哪些任务在跑。信息越精简，判断越快越准。原文自己的成本数据也印证了这一点：单次实验的读缓存 token 是 2323 万，分摊到 20 条工作请求上是每条约 116 万。这个量级说明，成本的主要部分不是「思考」，是「反复读」。

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

把两者放进同一个会话，会得到一个必然结果：每一次路由决策都要为整个记忆付费。

这并不是说这个设计是错的。在团队规模小、任务历史短的时候，一个常驻会话同时做两件事，工程上最简单，也确实够用。问题出在扩展性上——当记忆增长到一定规模，路由的成本会随记忆线性上升，而路由本身的复杂度并没有变。

5.2 三个次级后果

这个耦合还带来三个后果，都会在长期运行中显现，而且都会影响估值。

其一是可用性。 全局记忆的持久性绑定在单个会话的存活上。会话状态已按 5.1 节的做法存入数据库，重启后上下文可以恢复；不确定的是全局记忆能否从这些持久化状态里重建出来，这条重建路径原文没有描述。Watchdog 可以重启会话，但重启后的会话是否还是「同一个」全局记忆，原文未作说明。对企业客户来说，这是一个会写进 SLA 的问题：如果核心记忆的边界取决于一个进程的存活，这套系统在关键流程上的可用性就无法承诺。

其二是可替换性。 想更换 Router 使用的模型，就必须同时迁移记忆。这使得模型升级与架构升级被绑在一起，团队很难做小步替换。这个后果在当前阶段还看不出来，因为模型一年换几代，架构本来就跟着换。但当系统进入稳定运行期，模型升级会变成一件高频的事——每一代新模型在价格与能力上都有变化，不换就落后。届时「换模型要迁记忆」会成为一个真实的运营成本。

其三是可评估性。 想比较两个 Router 策略的优劣，必须让它们各自维护一份记忆，否则比较不成立；而一旦各自维护，两份记忆又会分叉。评估成本因此远高于一个无状态组件。这一条对做产品迭代的团队伤害最大：它意味着每一次 A/B 测试都要复制一整套历史，测试周期被拉长。

5.3 序列点应当是日志序号

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

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

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

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

事件日志是唯一权威。 所有进入系统的事件、所有作出的决定、所有对外动作，按序写入只追加的日志。日志不可修改，只能追加，因此它天然是完整的、可回放的、可审计的。

会话只是工作集。 每个会话记住自己处理到哪个序号，加载它需要的那一段上下文。会话可以被销毁、重建、迁移到别的机器，连续性由日志保证。

记忆是日志上的物化视图。 全局记忆不是一个需要被保护的实体，而是从日志中按需计算出来的结果。需要「三个月前那个任务为什么改了方案」时，从日志里查，而不是从一个会话的上下文里翻。查询结果可以缓存，缓存失效就重算，重算不改变事实。

这个结构在数据库领域已经被验证了几十年，它不是新发明。用在这里的价值是：它把「记忆」从一种需要小心翼翼保护的状态，变成了一个可以随时重建的派生结果。这一变化直接解决了前面三个后果——可用性由日志保证，可替换性由接口保证，可评估性由重放保证。

原文 5.2 节引用了 Anthropic 提出的「脑手分离」，并说明这套思路「同样让 harness 保持无状态，把会话日志存放在 harness 之外」。这句话说明原文对无状态的价值是有认识的。问题在于，它把这个认识用在了 Worker 侧，Router 侧仍然把全局记忆放在会话里。

因此这里的问题不是「原文没想到无状态」，而是无状态只做了一半。半截无状态的系统，在扩展性上并不比完全有状态的系统好多少——因为瓶颈会集中到那唯一一个没有解耦的节点上。

5.4 一种新形态的供应商锁定

对投资人来说，这个结构缺陷有一个直接的商业后果：它会制造一种新形态的锁定。

过去十年，企业软件的锁定主要发生在数据层：数据存在供应商的库里，迁移成本高，所以客户不走。SaaS 时代这个问题被部分解决，因为多数 SaaS 提供数据导出。

Agent 系统带来的是另一层：记忆锁定。

如果一家公司的 Agent 在两年里积累了完整的任务历史、决策理由、否决记录与业务上下文，而这些内容存在一个只有该供应商能解释的会话结构里，那么客户换供应商的代价不是「导出一份数据」，而是「失去全部的机构记忆」。

这个锁定的强度比数据锁定更高，因为它不可迁移。一份客户名单可以导出成 CSV 换一家 CRM 继续用；一段由十万次交互形成的、绑定在特定会话结构上的上下文，导出之后没有别家能用。

对采购方，这意味着合同里需要增加一条过去不常见的内容：记忆的可导出性与可解释性。不是导出聊天记录，而是导出结构化的任务历史——每个任务的目标、约束、决策、否决理由与结果回执。

对投资人，这意味着一个判断维度：这家公司的客户，是因为产品好用而留下，还是因为记忆搬不走而留下。前者是健康留存，后者是脆性留存——一旦出现一个能导入历史记忆的竞争者，留存会快速崩塌。

5.5 一个反直觉的判断

有一种常见的推论是：既然 Router 是瓶颈，那么做「更好的 Router」就是一个好生意。

本报告认为这个推论需要打一个折扣。原因在于，Router 的问题不在于它不够好，而在于它承担了本不该由它承担的职责。优化一个职责错配的组件，收益有上限；把职责重新划分，收益是结构性的。

真正稀缺的能力，是把「事件日志 + 物化视图」这套结构落到 Agent 场景里，并且定义清楚哪些东西必须进日志、哪些可以派生。这件事不显眼，却是所有后续能力——审计、结算、归因、迁移——的地基。

六、结构缺陷二：没有结清

6.1 五个模块都在回答「怎么开始」

原文用五个模块支撑四个特征。这五个模块分别是：双层架构、事件驱动、面向人的交互、计算与状态环境的分离、Watchdog。

把它们要解决的问题列出来，会发现一个很整齐的模式。

双层架构解决的是如何在连续性与吞吐量之间取得平衡——这是「怎么开始一项任务，并且同时开始很多项」。事件驱动解决的是如何不等指令就行动——这是「怎么主动开始」。面向人的交互解决的是如何不阻塞、如何匹配信道——这是「怎么让开始的过程顺畅」。存算分离解决的是如何不因设备离线而停止——这是「怎么让已经开始的事情继续」。Watchdog 解决的是异常后如何恢复——这是「怎么让继续的事情不断掉」。

五项都在回答「怎么让事情跑起来并且不停」。

没有一项在回答：一件事情的终态是什么，到达终态之后占用的资源怎么释放，终态及其原因怎么被记录。

这个缺失不是偶然的疏忽。它对应着原文的一个隐含假设：任务会自己结束，结束之后就没有然后了。这个假设在短周期、人工盯着的场景里成立；在长期运行、无人值守的场景里不成立。

6.2 五类残留

长期运行会留下五类东西，原文都没有处理。

僵尸任务。 一个任务失去了推进的动力，但仍然占着上下文、订阅与预算。它不会报错，因为它没有失败；它只是不再前进。在人工盯着的系统里，这种任务会被人发现并手动关掉；在无人值守的系统里，它会长期驻留。

孤儿订阅。 Worker 已经结束，但它对某个 Thread 的订阅还挂着。后续事件继续直通给一个不存在的会话，要么被丢弃，要么被一个重建的会话错误处理。

投机残骸。 原文 3.4 节引入了投机执行：Agent 在不确定结果是否会被采用时提前尝试，「结果有价值就交付，没有价值就丢弃」。丢弃的是结果，不是过程。那些被判定为无价值的尝试，如果不进入明确的归档或删除流程，就会在存储与检索索引里持续累积。

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

未结的提交槽位。 这一条在原架构里还不存在，但如果按照第九章建议的方式引入提交门（对外动作先进暂存区再提交），暂存区本身也需要结清机制。一个已经准备好但既未提交也未取消的动作，会在暂存区里永久停留，并在某次重试中被误提交。补一个机制会引入一个新问题，两者必须一起设计。

五类残留有一个共同点：多数不产生错误，主要产生成本与不确定性；其中孤儿订阅与悬空引用还会直接造成错误回复与召回断裂。

6.3 成本以「效率莫名下降」的形式出现

这一点是本报告认为最值得投资人注意的地方。

一个会产生错误的缺陷，会被监控捕获，会进故障单，会被修复。一个只产生成本的缺陷，不会。它表现为单位产出的成本缓慢上升，而这种上升与「这套架构本来就贵」无法区分。

原文报告的成本变化是：去掉直通后，Router 的决定数增加约 30%，总读缓存 token 从 2323 万增加到 3177 万，增幅约 37%。这是一个可归因的变化，因为有对照。僵尸任务造成的成本上升没有这样的对照，它会被归入「这套架构的运营成本」这个类别里，没有人会去查。

于是结清缺口会以「效率莫名下降」的形式出现，而不是以「故障」的形式出现。团队会以为是模型变慢了，以为是上下文变长了，以为是供应商涨价了，唯独不会想到是三个月前那个没有结束的任务还在占资源。

这个特征对投资判断有直接含义：一家 Agent 公司如果只有功能指标、没有成本归因能力，那么它的毛利率会在一个较长的时间里缓慢恶化，而管理层在恶化到明显之前看不到原因。等到看见的时候，通常已经积累了大量的结构性浪费。

6.4 结清的定义与状态机

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

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

对应的状态机如下。

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

状态机本身不复杂，但它强制执行两件在原架构中被省略的事：任何任务都必须有终态；任何终态都必须有原因。

第二件事的价值被低估了。一个任务被放弃的理由，是组织里最稀缺的知识之一。多数团队真正缺的不是「做过什么」，而是「试过什么并且为什么不行」。前者可以按语义相似度召回，后者必须按条件精确匹配——因为一个相似的失败，只有在条件相同时才会重演。

把「放弃理由」变成状态机的必填项，等于把否决记忆的采集变成流程的副产品，而不是额外的工作。这一点在后面的第十二章还会展开。

6.5 结清层是采购的前提

对企业采购而言，结清层的意义不止于省钱。

企业买一套系统，买的不是「能干活」，而是「能算账」。一件工作花了多少、谁批准的、结果如何、为什么停止——这四个问题答不上来，财务就无法把它放进任何一个预算科目。

这也是为什么大量 AI 工具停在「部门自采」这一层，进不了企业级采购。不是能力不够，是账算不清。一个按席位收费的工具，可以进「软件订阅」科目；一个按任务执行、成本随上下文浮动的系统，必须进「生产性支出」科目；而生产性支出要求可归集、可审计、可比较。

结清层就是这三个要求的交集。它让每一次任务执行变成一个可以入账的对象：有开始、有结束、有消耗、有结果、有责任人。

从这个角度看，结清不是一个工程优化项，是一个商业化前置项。谁先把它做出来，谁就能拿到企业预算；谁没做，就只能停在「团队内部工具」的位置上，靠个人付费或者部门经费维持。

原文自己也提到了这个方向。它在 8.1 节末尾写道，当运行周期拉长到跨月甚至更长的时间跨度时，长程记忆便成为制约可扩展性的主要瓶颈。这句话是对的，但它只看到了记忆的「存」，没有看到记忆的「结」。长期运行之后真正会压垮系统的，往往不是记不住，而是记住了太多不需要再记的东西。

七、验收三分法：垂直 Agent 的分水岭

7.1 一个更容易解释的现象

同一套 Agent 架构，在软件开发场景里跑得很好，换到制造业寻源就几乎不能用。这个现象在行业里被反复观察到，但解释往往是错的。

常见的解释有两类。一类说是模型能力不够，等行业模型变强就好了。一类说是数据不够，等数据积累到位就好了。

这两类解释都回避了一个更基础的问题：输出之后发生了什么事。

软件开发的产出是代码，代码之后紧接着有编译、有测试、有代码评审、有回滚。一个 Agent 提交了一个错误的改动，几分钟内就会被 CI 拦住，或者被评审打回。错误的代价是几分钟。

制造业寻源的产出是一份工厂名单。名单之后什么都没有。名单对不对，要等到把询盘发出去、等对方回不回、报价合不合适、能不能验厂，才知道。这个循环以周甚至月计。

两者用的可能是同一个模型、同一套架构，结果完全不同。差别不在生成侧，在验收侧。

因此本报告提出一个判据：决定一个垂直 Agent 能不能成立的，首先不是模型能力，是验收延迟。

7.2 验收的三项成本

把「验收」拆开，它包含三项成本。

其一，可读性成本。 产出能不能被人以合理的速度读完？一份两百行的代码改动可以读，一份十万行的日志不能读，一张三千家企业的名单可以读完，但读完也判断不了对错。

其二，判定依据成本。 读完以后，凭什么说它对不对？有的场景有客观依据——测试通过就是通过，编译失败就是失败；有的场景没有，只有「我觉得这家的报价偏高」这类判断，而这类判断依赖经验，不稳定，也无法标准化。

其三，反馈延迟成本。 就算当下判断不了，多久之后能知道答案？几秒、几天、几个月，对应完全不同的系统设计。

三项成本合起来决定了一件事：一个产出从生成到被确认为有效，需要多长时间、消耗多少人的注意力。这个时长，本报告称为验收延迟。

7.3 第一类：可读可判定

特征是：产出人类可读；对错有客观依据；验收延迟在分钟到小时级。

软件工程是这一类最典型的场景，也是这一类里被大规模验证得最充分的场景。

原文的实验全部落在这里。CI 消息、代码评审、Pull Request——这些不只是开发工具，它们本身就是一套高度成熟的验收基础设施。版本控制让每次改动可对比，diff 让人只看变化的部分，测试让对错有客观依据，评审让判断有第二双眼睛，回滚让错误的代价可控。

这套基础设施积累了五十年。

Agent 在软件工程里的成功，有一部分是从这套基础设施里借来的。它提交了一个改动，diff 会自动生成，测试会自动运行，评审会自动触发。它不需要自己解决「怎么让人快速判断这个产出对不对」，因为这个问题在它出现之前已经被解决了。

这一点对判断行业格局很重要。软件工程 Agent 的领先，不等于通用 Agent 能力的领先；它可能只是第一个找到了一片验收基础设施已经就位的场地的玩家。换一片没有这套基础设施的场地，同样的能力会立刻打折。

第一类场景还有两个特征值得注意。一是产出可以被切分——一个大改动可以拆成十个小的 Pull Request，每个都能独立验收。二是错误可以被隔离——改错了回滚就行，不影响生产环境。这两个特征让第一类场景对 Agent 的容错度很高，也让 Agent 的失败不会变成事故。

7.4 第二类：可读不可判定

特征是：产出人类可读；但对错在当下无法判定，只能等外部世界给回执；验收延迟在天到月级。

制造业寻源是这一类最典型的场景。

一份工厂名单，人是读得完的。三千家企业的名称、地区、注册资本、主营产品、联系方式，一下午能看完。看完之后呢？看完之后什么也确定不了。

名单里写着「这家做汽车零部件，注册资本 5000 万，位于常州」，这些信息都对。但采购真正要知道的是另外三件事：它会不会回复我的询盘，它的报价有没有竞争力，它能不能通过验厂。这三件事没有一件能从名单里看出来。

要知道，只有一个办法：发出去，等回音。

于是验收动作被拆成了两段。第一段是「看起来对不对」，可以在几分钟内完成；第二段是「后来怎么样了」，要等到几周之后。第一段由审阅完成，第二段只能由回执完成。

很多 Agent 产品停在第一段。它们把名单生成得很漂亮，把匹配理由写得很充分，然后交给用户。用户看着觉得有道理，用了一次，发现发出去的询盘石沉大海，第二次就不用了。

这不是产品做得不好，是它只完成了验收的一半。而缺的那一半，恰恰是用户真正在意的部分。

第二类场景需要的架构组件，与第一类不同。

第一类需要的是审阅层：把产出组织得便于快速判断，提供 diff、提供对照、提供证据链。

第二类需要的是结清层：记录每一条产出以什么形式、在什么时间、发给了谁；记录对方如何回应，包括无回应；把「没有发出去」与「发出去了但没回音」区分开。

这两种失败看起来一样，实际上完全不同。前者是系统故障，要修投递；后者是线索质量问题，要修召回。不区分，就永远不知道该改哪里。

7.5 第三类：不可读

特征是：产出超出了人的有效阅读能力；或者判定依据本身不存在。

这一类包括大规模数据清洗、长文档的一致性检查、跨库的实体对齐。这些任务 Agent 做得比人快得多，但做完之后没有人能确认它做对了。

一个典型的例子是给一千万条企业记录做标准化。Agent 跑完了，报告说处理了 998 万条，剩下 2 万条需要人工确认。这 2 万条人看不过来；而那 998 万条里有多少是错的，没有人知道。

第三类场景的风险不在效率，在不可验证性。系统越高效，产出越多，人越无法检查，出错的可能性越大而发现的可能性越小。

这一类不适合让 Agent 全自动执行，适合的做法是抽样加统计保证。具体来说，设定一个可接受的不合格率，随机抽取固定数量的样本人工核对，用超几何分布算出「在抽到的样本全部合格时，整批不合格率低于某个阈值的置信度」。

举个具体的算法。一批 N 条记录，真实不合格 D 条，抽 n 条，一条不合格都没抽到的概率是 C(N−D, n) / C(N, n)。反过来，如果抽了 n 条全部合格，那么整批不合格率高于某个水平的概率可以被算出。要在 95% 置信度下排除「不合格率高于 1%」，在总量远大于样本时，样本量约需 300 条，与批量大小关系不大。这个性质让第三类场景的验收成本可以被控制在一个固定值上，而不是随产出规模线性增长。

这一段是本报告认为第三类场景较为可行的工程路径。它不追求逐条正确，追求的是「错误的密度被限制在一个已知的水平上」。对企业客户而言，这个承诺比「AI 准确率 99%」更可信，因为它可以被独立复核。

7.6 一张判据表

把三类放在一起。

类别	产出可读性	判定依据	验收延迟	需要的架构组件	典型场景
第一类	可读	客观存在	分钟到小时	审阅层	软件工程、报表生成、格式转换
第二类	可读	需要外部回执	天到月	结清层	制造业寻源、销售线索、招聘、投资标的
第三类	不可读	不存在或不完整	无法确定	抽样与统计保证	大规模数据清洗、跨库对齐

这张表可以直接用来判断一个垂直 Agent 项目的可行性。做法是问三个问题：产出人能不能读完？读完凭什么判断对错？判断不了的话，多久能知道答案？

三个答案落在第一类，架构问题基本已经被软件工程解决了，团队要做的是工程实现与场景适配。 落在第二类，团队必须自己建结清层，否则产品只能停在「看起来有用」。 落在第三类，团队要放弃「逐条正确」的叙事，改用统计承诺，并且把抽样流程做进产品。

这条判据比「我们的模型更强」有解释力得多。它解释了为什么同样是大模型，有的场景已经能收费，有的场景还在做 demo；也解释了为什么一些看起来技术含量不高的产品反而先赚到钱——它们落在第一类，验收便宜。

八、度量缺席：企业采购的预算科目问题

8.1 原文报告的四个指标，全是系统侧

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

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

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

这不是原文一家的疏忽。整个 Agent 行业目前报的都是这类指标：响应速度、工具调用成功率、任务完成率。这些指标对工程师有用，对采购方没有用。采购方要回答的问题是「买这个能省几个人」和「买这个一年花多少钱」，两个问题都需要人侧指标。

8.2 建议补充的八个指标

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

编号	指标	定义	计算方式	用途
M1	路由准确率	事件被分派到正确 Worker 的比例	人工抽检 1%，按「错分或不必要分派」计错	判断 Router 是否可靠
M2	直通命中率	经订阅直通的事件占全部事件的比例	直通事件数 ÷ 事件总数	衡量 Router 负载结构
M3	每验收产出 token	单位被验收产出的 token 消耗	区间内 token 总量 ÷ 被验收产出数	成本效率的主指标
M4	人类分钟每验收产出	单位被验收产出消耗的人的时间	区间内人工投入分钟 ÷ 被验收产出数	直接对应人力预算
M5	一次通过率	首次提交即通过验收的产出占比	一次通过数 ÷ 提交总数	衡量产出质量
M6	结清率	到达终态、释放资源且写入原因的任务占比	已结清任务数 ÷ 任务总数	衡量结清缺口
M7	重复受理率	同一意图被多次受理的比例	重复受理数 ÷ 任务总数	衡量去重能力
M8	返工率	验收后被推翻重做的产出占比	推翻重做数 ÷ 验收产出数	衡量隐性成本

需要说明编号口径：本篇的 M5 与 M6 分别是「一次通过率」与「结清率」；本院前一篇《Super-agent 架构的独立复算》中同样编号的两个指标分别是「投机命中率与浪费率」与「僵尸任务占比」。两篇的 M1 至 M4、M8 含义一致。

M3 与 M4 是这张表里最重要的两个。M3 把成本归到被验收的产出上，分母不是「任务」，这一点很关键：原文报的是单次实验的 token 总量，连任务粒度都没有；而大量任务没有产出，也没有验收。M4 直接对应 P1 所说的注意力：如果这个指标没有改善，那么无论架构怎么设计，关于注意力的叙事都没有被验证。

M6 与 M7 对应两个隐性缺口。多数系统不是做得不够，是做了太多不该做的、留了太多没结的。一个能说清楚自己僵尸任务占比的系统，才有资格谈长期运行。

8.3 M3 与 M4 决定能不能进预算

对采购方而言，M3 与 M4 的意义不是「更精确」，而是「能不能算账」。

企业的预算科目是分层的。软件订阅按席位计，市场费用按项目计，生产性支出按单位产出计。一个 Agent 系统如果只能报「每月多少 token」，采购方无法把它放进任何一个已有科目，只能新开一个「AI 实验费」，而这个科目的额度通常很小，且每年要重新申请。

一旦能报出「每获得一条有效线索消耗多少」或「每完成一份可提交的报价单消耗多少人工分钟」，性质就变了。它可以被放进获客成本、可以被放进人效指标、可以与其他方案横向比较。这时候采购讨论的对象从「要不要试」变成了「划不划算」，后者是一个可以签字的问题。

这也是本报告认为 M3 与 M4 应该被当作产品能力而不是运营报表的原因。能把这两个数报出来的公司，卖的不是工具，是产能。

8.4 指标会被博弈，所以要配对

任何单一指标都会被优化到失真。

若只考核 M3，系统会倾向于挑选容易验收的任务，把难的推给人。若只考核 M1，Router 会倾向于把所有事件都交给人处理，因为这样不会错分。若只考核 M6，回收器会过早终止任务，把本可完成的任务提前终止。若只考核 M8，系统会倾向于产出最保守的方案。

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

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

对投资人，这条判断可以变成一个尽调问题：你们考核哪几个指标，怎么防止它被优化到失真？答得出配对逻辑的团队，通常对自己的系统有真实的观察；答不出的，多半还没有跑到需要担心的规模。

九、安全、责任与采购门槛

9.1 原文自己划定的范围

原文 8.4 节用很短的篇幅讨论了安全与隐私，并明确承认：「如果没有办法很好的解决安全与隐私问题，那么 Super-agent 只有在一个很小且可信的范围才能工作。」

这句话是准确的，而且比它看起来更严重。它说的不是「安全性有待加强」，而是「适用边界由安全性决定」。一个系统只能在小范围可信环境里工作，意味着它不能作为对外服务交付。

原文举了两个具体的风险。第一，云端 Agent Loop 持续接入外部事件、端侧设备存有私有代码与本地凭据，这个跨设备连接一旦被攻破，所有端侧设备都面临被控制的风险。第二，即使云端未被攻破，只要端侧凭据进入模型上下文，正常执行过程中也存在泄露风险。

这两条都不是可以通过「加强提示词」解决的问题。它们是结构问题：系统需要在接触大量不可信输入的同时，持有大量高权限能力。这两个条件同时成立，风险就不是概率问题，是时间问题。

9.2 检查被放在了错误的位置

原文的事件过滤设计本身是合理的：程序层做快速准入，语义层做判断。但它解决的是噪音问题，不是安全问题。

过滤降低的是噪音量，不是攻击成功率。

原文举的一个例子很能说明问题：Agent 持续关注公共群聊，在无人 @ 的情况下主动识别缺陷并提交修复 Pull Request。这个行为在内部可信群里是合理的，效率很高。但同样的行为放在对外开放的群里，等于把「任何人发一句话」变成了「触发一个拥有完整工具权限的 Worker」。

过滤机制在这里帮不上忙。因为攻击者发的消息，从内容上看就是一个正常的缺陷报告——它甚至会写得很规范，因为它就是要通过过滤。

安全边界的正确位置在对外动作之前，而不是在事件进入之时。这是安全工程里的端到端原则：一项检查如果放在信息不足的位置，它要么冗余，要么错误。判断「这个动作该不该做」所需的信息在策略端——动作类型、目标范围、当前预算、历史频率——不在事件端。事件端只知道一句话长什么样。

由此引出本报告建议的一个原语：提交门。

具体做法是，把越过沙箱边界的动作分成两个阶段。第一阶段是暂存：Agent 生成动作，写入暂存区，不执行。第二阶段是提交：暂存区里的动作经过策略门校验后才真正执行。策略门校验的依据是动作的类型、目标范围、预算与频率，不校验这句话看起来像不像一个请求。

这个设计的好处是它把「判断」从概率问题变成了规则问题。规则可以被审计，可以被测试，可以在事故后复现。而「模型判断这条消息可不可信」做不到这三点。

同时，提交门带来一个新的工程问题，前面第六章已经提到：暂存区本身需要结清机制。一个已经准备好、既未提交也未取消的动作，会在暂存区里永久停留，并在某次重试中被误提交。补一个机制会引入一个新问题，这也是为什么结清模块必须与提交门一起设计。

9.3 可归属主体

原文没有讨论责任归属。这不是疏忽，而是场景使然：在团队内部，责任归属由组织关系自然解决。代码是谁提交的，找谁；群里的回复是谁发的，找谁。组织关系本身就是责任链。

一旦这套系统进入企业采购或对外服务，责任归属就变成一个前置条件。

企业无法采购一个「出了事找不到人」的系统。这不仅是法律问题，也是流程问题：任何一次对外动作，都需要一个可以被追问的主体。

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

这条约束看起来只是加一个字段，实际上会改变系统设计。它要求每一次动作都能追溯到发起它的任务、批准它的策略、以及为该策略负责的人。这反过来要求日志必须是完整的、只追加的、不可篡改的——也就是第五章建议的那套结构。

到这里可以看到，前面几章的建议互相咬合：日志序号解决了记忆的可重建，结清解决了成本的可归集，提交门解决了动作的可拦截，可归属主体解决了责任的可追溯。四件事共用同一套基础设施。

9.4 企业采购的三个前置条件

把这一章与前面几章合起来，可以总结出企业采购的三个前置条件。第二章提出的三道坎里，可结算与可归属在这里落成两个具体条件；第三个条件只在采购阶段才出现。

可结算。 每一次执行都能归到一次产出上，有消耗、有结果、有单价。这一条由结清层与 M3、M4 两个指标共同支撑。

可归属。 每一个对外动作都能找到一个责任主体，有授权、有记录、有边界。这一条由提交门与可归属主体约束共同支撑。

可退出。 客户离开时，能够带走完整的任务历史与决策理由，且这些内容在新系统里仍然可读。这一条由日志结构支撑。

三个条件里，第三条最容易被忽略，但它往往决定了客户敢不敢深度使用。一个客户如果知道自己用得越深、越走不掉，他会在某个点上主动停止加深——这个点通常出现在系统开始承载关键流程的时候。这是一种自我限制的增长天花板，从外部看不出来，只有问客户才问得到。

十、价值池往哪里迁移

10.1 三层结构

讨论 Agent 产业的价值分布，可以先把链条拆成三层。

模型层。 提供推理能力。这一层的特点是能力趋同速度快、价格下降快、规模效应强。过去两年，同一档能力的模型价格下降了一个数量级以上。这一层的竞争格局已经比较清楚：少数几家占据大部分份额，其余靠垂直或成本生存。

调度层。 也就是原文所说的 harness 与架构。它负责把模型能力组织成可持续运行的系统：路由、上下文管理、事件处理、状态恢复。这一层的进入门槛不高，但做好不容易——需要处理大量边界情况，需要对成本敏感，需要在长尾场景里打磨。

场景层。 具体行业的任务定义、数据、验收标准与交付方式。这一层高度分散，每一垂直都要重新做一遍，但一旦做成，替换成本很高。

原文的贡献主要在第二层。它把调度层的一个形态讲清楚了，并且给出了可实现的路径。这也意味着，围绕第二层的竞争会很快变得拥挤。

10.2 四个可能的价值捕获点

在一个快速趋同的链条上，价值会向难以复制的地方集中。本报告认为有四个可能的位置。

第一个是推理成本优势。 谁能在同等质量下把单位推理成本压得更低，谁就在所有场景里多一段毛利。这是一个纯粹的规模与工程优势，与场景无关，赢家通吃。这一层的机会属于有自研能力或有特殊硬件条件的玩家，不属于应用层。

第二个是调度工程质量。 同样的架构，一个团队能做到稳定运行、成本可控、故障可恢复，另一个团队做不到。这个差距真实存在，但它的护城河深度有限——它依赖经验积累，而经验会随着人才流动扩散。这一层能支撑一家好公司，撑不起一个高估值。

第三个是验收事实。 这是本报告认为最有价值的位置。

第二类场景的验收依赖外部回执：客户回没回、报价合不合适、验厂过没过、订单成没成。这些事实不在模型里，不在公开数据里，只在真实业务流里。谁能在合法的前提下积累这类事实，谁就掌握了判断「哪条线索值得发出去」的依据。

这类事实的特点是：越用越多，越多越准，越准越难被替代。它是少数几类会随时间自我强化的资产之一。

第四个是责任承接。 当 Agent 开始代替人做对外动作，就需要有人为这些动作承担责任。责任承接可以表现为合规资质、保险产品、审计服务，或者一个明确的服务身份。这一层目前几乎是空白，但随着 Agent 承担的动作变重，它会从「可选项」变成「必需项」。

四个位置里，第一个需要资本，第二个需要时间，第三个需要场景与耐心，第四个需要资质与信任。对多数创业者，第三个是较为现实的入口；对投资人，第三个是具备复利效应的位置。

10.3 三个观察窗口

判断这个迁移有没有真的发生，可以看三个窗口。

窗口一：公开讨论的关键词。 如果讨论从「架构有几个模块」转向「单位产出多少钱」，说明调度层的竞争已经进入成本阶段，价值开始向下游转移。这个转向通常发生在能力差距缩小之后，滞后于技术成熟大约一到两个季度。

窗口二：报价方式的变化。 如果市场上开始出现「按有效线索计费」「按验收通过的产出计费」这类报价，说明 M3、M4 这类指标已经进入商业实践。这是第二类场景真正开始商业化的标志，也是结清层落地的标志。目前主流的报价方式仍是按席位或按调用量，说明行业还停在第一层。

窗口三：记忆迁移工具的出现。 如果出现能够导入、导出、转换 Agent 任务历史的工具或标准，说明客户已经开始用脚投票，供应商锁定正在被打破。这个窗口出现得越早，说明市场竞争越充分；出现得越晚，说明现有玩家的锁定越强，但也说明这个市场的天花板受限于客户的信任。

三个窗口都不需要内部数据，从公开信息和产品页面就能观察到。

10.4 四类不值得投入的方向

反过来，也可以列出四类本报告认为不值得投入的方向。

只做 Router 优化的。 Router 的第一层问题是性能，第三章已经量化；第二层问题是职责错配，第五章已经论证。只在一个职责错配的组件上做优化，收益有上限，而且随时可能被一次结构重设计归零。

只做提示词编排的。 第四章的复算显示，原文实验中最有效的变量可能是「取消了模型的裁量权」，而这一点的实现成本极低。任何仅靠提示词与工作流编排形成的差异，都会被快速复制，且会被下一代模型的内置能力吞掉。

声称通用但场景落在第三类的。 一个声称「什么都能做」的产品，通常意味着它没有选定验收方式。如果它的实际场景落在不可读的那一类，那么它的准确率无法被验证，客户用一次就不会再用。这类产品的增长曲线通常很好看，留存曲线很难看。

靠记忆锁定留存的。 前面第五章分析过，记忆锁定带来的留存是脆性留存。它会让短期数据好看，掩盖产品力不足，并在竞争者提供迁移工具时集中崩塌。对投资人，这是一个需要主动识别并打折的指标。

10.5 一个总体判断

把这一章压缩成一句话：这一轮 Agent 架构的换代，真正的稀缺资源不是生成能力，是验收所需的事实与承担责任的资格。

生成能力的成本还在快速下降，任何人都能买到；验收能力受人的判断力与组织授权约束，不会因为模型变强而同步扩张；而承担责任的资格，需要时间、资质与信任，是这条链上最难加速的部分。

这个判断有一个不太直觉的推论：在这个行业里，能说清楚「怎么知道它做对了」的团队，比跑得最快的团队更可能留下来。

原文的实验之所以有说服力，恰恰是因为它给了一个可以被检验的量——任务完成时间。哪怕这个量测的不是它想证明的东西，它至少是明确的、可复现的、可以被别人质疑的。相比之下，行业里大量关于 Agent 能力的叙述，连一个可以被证伪的量都没有。

这也是本报告愿意花大量篇幅做复算的原因。复算的用途在于示范一种可以被继承的判断方式：把主张拆成命题，把命题对到数据，把数据算出结论，再检查结论与主张是不是同一件事。

这套方法不新，但在这个概念密度远高于证据密度的阶段，它比任何预测都有用。

十一、给投资人的十二个问题

前面各章的判断可以压缩成一份问答清单。下面十二个问题按技术、商业、治理三组排列，每个问题后面给出「什么答案算过关」与「什么答案需要警惕」。

11.1 技术组

编号	问题	过关的回答	需要警惕的回答
Q1	你有没有测过强制委派或等价的极简方案？	有，结果差 X%，因此我们选择了 Y	没有，但我们的架构明显更复杂更完整
Q2	你们报的性能提升，因变量是什么？	人力吞吐量，定义为每单位人工时间完成的验收产出	任务完成时间、响应延迟
Q3	单位被验收产出的 token 消耗是多少？	有数，且能拆出上下文成本与执行成本	只报总调用量或月度账单
Q4	事件日志能不能重放出一个任务的完整历史？	能，日志只追加，可按序号重放	能看聊天记录，但决策过程没有结构化保存
Q5	任务进入终态后，占用的资源怎么释放？	有状态机、有回收器、有预算上限	任务完成就结束，异常情况人工处理
Q6	记忆存在哪里，能不能迁移？	日志是权威，记忆是可重建的物化视图	记忆在会话上下文里，导出只有文本

Q1 与 Q2 是第四章的直接推论。Q1 检验的是团队有没有做过消融，Q2 检验的是它有没有意识到延迟与吞吐不是一回事。

Q3 检验的是成本能不能归到产出。Q4 与 Q6 检验的是记忆结构，这一组问题在尽调中最容易被跳过，因为它们听起来像工程细节，实际上是估值的核心——记忆能不能迁移，决定了客户留存是健康还是脆性。

Q5 检验的是第六章所说的结清缺口。一个没有回收器的系统，跑三个月和跑三年是两种东西。

11.2 商业组

编号	问题	过关的回答	需要警惕的回答
Q7	你的场景属于哪一类验收？	明确说是第一类或第二类，并说明理由	说「所有场景都能做」
Q8	客户用完之后，怎么知道它做对了？	有回执数据，能说清发出、回应、结果的分布	客户反馈很好，NPS 很高
Q9	定价单位是什么？	按验收产出、按有效线索、按完成的流程	按席位、按 token、按调用次数
Q10	客户为什么留下？	因为产出有效，切换成本在数据与流程上	因为历史记录搬不走

Q7 是第七章的直接应用。这个问题最能区分「有场景」和「有叙事」——有场景的团队会立刻说出自己的验收延迟有多长，没场景的团队会说技术可以适配。

Q8 检验的是结清层有没有真的落地。NPS 是主观评价，回执分布是客观事实，后者才能支撑产品迭代。

Q9 与 Q10 合起来看，能判断这家公司是在卖产能还是在卖工具。卖产能的公司有单位经济模型，卖工具的公司只有订阅收入。

11.3 治理组

编号	问题	过关的回答	需要警惕的回答
Q11	越过沙箱的动作，在哪里被拦截？	在策略门，按动作类型与范围校验	在提示词里约束，在事件入口过滤
Q12	出了事，谁是责任主体？	每个对外动作绑定自然人或服务身份	系统自动执行，由客户自行判断

Q11 检验的是第九章的端到端原则。把检查放在事件入口是常见的错误，它看起来像在做安全，实际上只是在做降噪。

Q12 目前很少有公司能给出完整答案。但只要这家公司打算服务企业客户，这个问题迟早会被采购方问到。提前想清楚的团队，会在企业市场上获得一段真实的时间优势。

11.4 这份清单的用法

十二个问题不需要全部问到。实际尽调里，Q1、Q3、Q7、Q9 四个问题能在半小时内把多数项目分出层次。剩下八个可以在技术尽调阶段补。

值得强调的是，这份清单的目的不是筛掉项目，是给项目定价。一个团队如果在 Q1 上没有做过对照，不代表它做不出好产品，只代表它的技术优势还没有被证明，估值里不应该包含这一部分溢价。

十二、制造业落点：从「找到」到「验过」

12.1 制造业寻源为什么是第二类

制造业寻源的任务结构，与第七章的第二类完全对应。

产出是一份工厂名单，人读得完。可读性成本不高。判定依据在名单之外——这家会不会回复、报价有没有竞争力、能不能通过验厂。反馈延迟以周计。

这意味着寻源类 Agent 的核心能力，不在召回，在结清。

召回已经不稀缺了。天下工厂的工厂档案覆盖 480 万家中国制造企业，细分行业类目 1,965 个，产业带 1,000 个以上，其中具备外贸业务的工厂 180 万家，带老板或决策人直连联系方式的工厂超过 300 万家。这些数字说明，在这个库里「找得到」已经不再是瓶颈。

真正稀缺的是「找得准」，更准确地说，是「经回执验证过的准」。

一家采购商要的不是三千家符合条件的工厂，是二十家会回他消息、报价在预算内、能通过验厂的工厂。从三千到二十，中间隔着的不是更聪明的检索，是回执。

12.2 数据说明了什么

把我们的覆盖数据按第七章的三类拆开看，会得到一个有意思的结论。

可读性这一层，供给已经充足。企业名称、地区、注册资本、成立年限、主营产品、经营范围、联系方式——这些字段构成了名单的主体，也是多数寻源产品交付的全部内容。

判定依据这一层，供给是断裂的。判断一家工厂值不值得联系，需要的信息包括：它最近有没有接同类订单、它的产能是否饱和、它的报价习惯、它对哪类客户有响应偏好。这些信息不在工商数据里，也不在企业官网上，只在真实的询盘往来里。

反馈延迟这一层，目前基本没有产品化。询盘发出去之后发生了什么，多数系统不记录。发了多少、回了多少、为什么没回、回了之后谈到哪一步——这些数据散落在销售人员的微信、邮箱与记忆里。

三段供给的失衡，决定了这个行业的产品重心应该往哪里挪。

12.3 三条可操作的建议

基于上面的判断，本报告给出三条建议，面向做制造业寻源产品的团队。

第一，把回执做成一等数据。

具体做法是：每一次对外触达都记录三个字段——触达方式（电话、微信、邮件、平台站内信）、触达时间、对方回应（包括无回应）。无回应也要记录，而且是最重要的一种记录，因为它区分了「没有发出去」与「发出去了但没回音」这两种完全不同的失败。

三个字段齐备之后，验收的定义会发生变化：从「人点了通过」变成「世界给了回执」。这个变化看起来只是加了几列数据，实际上把产品从第一类拉到了第二类，也让产品第一次具备了积累复利的能力。

第二，把「验过」而不是「匹配」作为交付口径。

多数寻源产品的报告开头是类似「为您找到 N 家符合条件的工厂」这样的表述。这个口径的问题在于，N 越大，客户越不知道该从哪家开始，而且 N 与成交之间没有关系。

更可交付的口径例如：「本批 200 家中，已触达 86 家，收到回应 31 家，其中 12 家进入报价阶段，3 家完成验厂。」这组数字里每一个都可以被客户复核，也都指向下一步动作。

这个口径的转换会带来一个副作用：它逼迫产品去处理触达，而不只是处理检索。这正是第二类场景应有的形态。

第三，建立否决记忆。

一个团队真正稀缺的知识，往往不是「做过什么」，而是「试过什么并且为什么不行」。在寻源场景里，这表现为：某类企业在某个地区不回复询盘，某个规模的工厂不接受小批量订单，某个行业在某个季节产能排满。

这类知识的检索语义与正向记忆不同。正向记忆可以按相似度召回，否决记忆必须按条件精确匹配——因为一个相似的失败，只有在条件相同时才会重演。因此它不能被塞进一个语义检索里，需要有结构化的条件字段。

这件事的价值会随时间上升。一家做了三年寻源的公司，如果完整记录了每一次失败的条件，它就拥有了一份别人无法通过采购数据获得的东西。这份东西不能被模型能力替代，也不能被资本快速买到。

12.4 一个更大的判断

制造业是检验 Agent 成色的好场地，因为它同时具备三个特征：任务足够复杂、验收足够贵、客户足够务实。

任务复杂，意味着模型能力有用武之地；验收昂贵，意味着结清层有真实价值；客户务实，意味着概念叙事拿不到订单。

这三个特征合起来，会逼出一批真正能算账的产品。它们不会讲「自主智能体」，只会讲「这批线索里有多少条被验证过」。它们的技术含量可能不如通用 Agent 公司，但它们解决的问题是真的。

对本报告开头提出的第三个问题——这套架构在哪些场景成立——制造业给出的答案是：它可以在制造业成立，但前提是换上结清层；原文那一套只在第一类成立。软件工程靠审阅层，制造业靠结清层。两种形态都属于「持续在场」这个大方向，但需要的工程能力完全不同。

把这两种形态混为一谈，是当前行业里最常见的一个判断错误。

十三、待核实清单

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

• 原文 7.2 节未定义「单次请求耗时」与「单个决定分摊的推理时间」两个指标的口径。二者在批大小为 1 时不相等（2.5 秒对 6.4 秒），无法用同一服务时间解释。本报告的利用率复算按「单次请求耗时」为一次 LLM 调用耗时处理，若口径不同，结果会变。
• 原文未披露 Router 与 Worker 各自使用的模型型号、参数量与上下文长度，因此第三章关于单位成本的判断只能停留在量级层面，不能折算为金额。
• 原文未给出 token 计价，本报告只使用 token 量与比值，未折算金额。
• 原文称「一个人通常只能同时跟进 3 到 5 个活跃 Session」，未标注来源，也未说明测量方法。本报告将其作为未标注来源的经验值处理，并指出其可能对应三种不同机制（工作记忆容量、中断恢复成本、承担后果的容量），三者的架构含义不同。
• 原文实验的 300 条消息中工作请求占 6.7%，未说明该比例的现实依据。第三章与第五章关于单位成本的折算依赖这个比例。
• 本报告未取得原型仓库 dsh-superagent-prototype 的代码，第六章关于结清层、第九章关于提交门的建议是设计推论，不是对实现的描述。
• Catalini、Hui 与 Wu 将工作划分为四类，本报告未逐条比对其分类与本报告三类验收场景的对应关系，二者的关系有待专门讨论。

十四、方法与文献

14.1 本报告做了什么

本报告的工作可以概括为三步。

第一步是拆解。把原文的论证拆成七条可以判定真假的命题，并在关键处标注证据等级。这一步的目的是让后续讨论有共同的对象——不拆开，批评与辩护都会落空。

第二步是复算。对原文公开的数据重新计算，得出利用率、批大小与自然到达量的关系，并检查实验的因变量与主张是否一致。复算的价值在于它可以被读者独立验证，不依赖叙述者的信用。

第三步是外推。把技术结论翻译成产业与投资判断，并对每一条外推标注它所依赖的假设。凡是假设没有依据的地方，进入待核实清单，不在正文给出结论。

三步之外，本报告没有做预测。原因很简单：这个行业的变化速度快于任何预测模型的更新速度，给出三年后的数字，价值不如给出一个可以在当下使用的判据。

14.2 一级材料

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

14.3 二级文献

• Anthropic：《Scaling Managed Agents: Decoupling the brain from the hands》，2026 年 4 月。原文 5.2 节引用，本报告第五章讨论无状态时参照。
• Catalini, C., Hui, X., Wu, K.：《Some Simple Economics of AGI》，arXiv:2602.20946。验证带宽与可测性缺口的讨论来源。
• Saltzer, J. H., Reed, D. P., Clark, D. D.：《End-to-End Arguments in System Design》，1984。第九章检查位置的论证依据。
• Saltzer, J. H., Schroeder, M. D.：《The Protection of Information in Computer Systems》，1975。最小权限与完全中介原则。
• Kung, H. T., Robinson, J. T.：《On Optimistic Methods for Concurrency Control》，1981。第五章序列点与提交边界的类比来源。
• Denning, P. J.：《The Working Set Model for Program Behavior》，1968。第五章工作集概念的来源。

以上二级文献的检索日期均为 2026 年 10 月 31 日。本报告只引用其结论，不复述推导。

14.4 与本院前一篇的分工

本院于同月发布了《Super-agent 架构的独立复算》，那篇报告处理的是「原文说了什么、数据支持什么」，本报告处理的是「这些结论对产业意味着什么」。

两篇的结论一致，但读者对象不同。前一篇面向工程师与研究者，给出公式、数据与可复现的推导；本篇面向分析师与投资人，给出判据、结构与可执行的问题清单。

需要核对原始数据时，请回到前一篇。需要做判断时，本篇可以直接使用。

14.5 一句说明

本报告对原文的批评，不构成对 DeepSeek Harness 团队工作的否定。恰恰相反，正是因为它公开了到达速率、批大小、请求耗时这三个数，本报告的复算才成为可能。在当前的技术传播环境里，愿意交出可被检验数据的团队是少数。

批评的用处，是把一份可以被继承的材料整理成可以安全继承的样子。这份架构说明会被大量团队照着实现，本报告的工作，是在它被继承之前，把可以核对的部分核对一遍，把不能推广的部分标出来。

这是产业研究应该做的事。