别把 Sub-Agent 和主线程指标混在一起算，实测数据偏差最高达 135 倍

最近在处理一组包含 4890 条线程的真实负载日志时，我差点掉进一个巨大的统计陷阱。起初我的目标很简单：通过汇总 7 个模型版本在 5 个行为指标上的表现，产出一张对比表。但当我尝试将数据通过“角色 × 模型”进行交叉分析时，发现之前所有基于全局均值的结论全部失效了。

最让我震惊的是，同一个模型在不同角色下的表现完全是两回事。在主线程（Main Thread）和子代理（Sub-Agent）之间，指标的差距大得离谱。以样本中的 A 模型和 D 模型为例，A 模型在主线程的中位数是 47.8 万 tokens，而子代理仅为 6212，差距 77 倍；D 模型的情况更极端，主线程中位数 18.5 万，子代理 1371，差距直接拉到了 135 倍。相比之下，B 模型的两端数据仅差 1.2 倍。

这种量级的差异意味着，如果你把主线程和子代理的数据混在一起计算平均值，你得到的根本不是模型的性能画像，而是一个被随机干扰的“数字怪物”。

除了 Token 数量的剧烈波动，更深层的坑在于行为指标的“结构性失真”。我重点观察了两个指标：同文件重编辑率和错误恢复序列。在主线程层级，这些指标能有效区分模型能力，数值分布在 0.40 到 0.53 之间，错误恢复次数在 1 到 2 次。然而，一旦切换到子代理层，你会发现 7 个模型中有 6 个的数值恰好为 0。

这是因为子代理的运行逻辑本质上是“触发即销毁”（fire-and-forget）。它们被指派去完成一个单一的原子任务，跑完即销毁，不存在回头修改同一个文件的行为，也遇不到需要通过多次迭代来“恢复”失败的场景。这意味着在子代理这个分层里，模型之间的性能信号几乎不存在，所有的有效信号其实全部挤在仅占 7% 的主线程数据里。

而最致命的干扰项来自于“角色混合比例”的失衡。在我的 4890 行数据集中，有 4533 行（占比 92.7%）是由子代理产生的。但由于编排策略的不同，每个模型承接的主线程占比从 1.5% 到 71.4% 不等，跨度高达 48 倍。

这背后的逻辑很残酷：在实际部署中，我们倾向于把便宜的模型指派去执行机械的 Fan-out（扇出）任务，而将昂贵的模型留在主线程由人工驱动。当你把所有行合在一起算均值时，你其实是在比较一个“主要由子代理构成、但子代理占比因模型而完全不同”的混合体。这种合成出来的差异，在主线程和子代理任何一个独立分层里其实都不存在。

对于目前在构建 Agent 观察管道（Observation Pipeline）的工程师来说，这个教训非常深刻：不要迷信全局均值。如果你想真实评估模型在 Agent 架构中的表现，必须采取“按角色分层”的观察方式。将主线程和 Sub-Agent 彻底拆开分析，否则你看到的所谓“模型差异”，可能仅仅是编排策略导致的统计偏差。