《盘点表全对，仓库全乱》— 企业 Agent 持续评估论文深度解读

每个月最后一个周五，仓储主管老张都会收到一张盘点表。表格干净利落：期初库存、期末库存、进出流水，三个数字严丝合缝，误差为零。按理说，这样的仓库该评先进。可如果你真推开仓库大门走进去，会看见另一幅景象——为了凑期末那个漂亮的数字，整个月里货物被倒腾得鸡飞狗跳：A 区的货借调到 B 区冲账，次品混进正品堆，三批货绕着同一个货架空转了四圈，盘点前夜甚至还有一箱货躺在月台上忘了入库。盘点表上一分不差，仓库里一地鸡毛。

这就是「能力的代价」系列的收官篇。前两篇我们见过两张截然不同的账单：Mímir 讲一个想走进灌溉物理世界的大语言模型，得先给自己造一道不可篡改的门——解锁要付钱；HydroJEV 讲一个一秒出活的快筛护士，配上双法官的门能砍掉 35-38% 的审查负载，但隐蔽攻击 66% 的漏网率是永远付不清的盲区账单。今天这篇，IBM 的两位作者把账单翻到了第三页：企业里一个 AI agent 的验收测试如果只查"最终答案对不对"，会发生什么。答案是一串让人后背发凉的数字：240 次全自动试验，175 个通过所有终检——其中 162 个（92.6%）过程是歪的。

论文叫 Continual Learning for Enterprise AI Agents，简称 CLEA，十月初挂上 arXiv（2610.01833，cs.AI）。作者 Aarya Doshi 来自 Georgia Tech，合作者 Vadim Sheinin 来自 IBM——这篇工作是 Doshi 在 IBM Research 暑期实习期间完成的。故事全部发生在 IBM 一套真实的企业系统里：不是玩具基准，不是合成任务，是一套每天真正在跑的 IT 基础设施成本分摊管道。

🏢 一出错就污染全村的管道

先认识一下出事现场。

IBM 有个系统叫 VAR（Value Aware Resiliency），管 IT 基础设施的成本韧性。里头有个 skill 叫 BVD（Business Value Determination）：把业务收入按应用拆开算账。给一组应用、一个日期范围、一笔年度收入，它去查可观测性 API，拿到每个应用的 CPU、内存、调用量，按比例分摊收入——默认权重 CPU 40%、内存 40%、调用 20%。摊完写进持久数据库，所有下游 skill 都从这个库里读数。

这个"下游都读这个库"是关键。BVD 是管道的上游水源：它的输出错了，不在自己这儿爆炸，而是顺着水流污染下游每一本账。好比仓库那箱忘了入库的货——盘点表上若无其事，发货环节才发现账上有、架上无，缺口的代价由一整串无辜的人分摊。

论文盯的是两个相关但结构不同的 skill。Revenue Apportionment：9 个应用，读 CPU、内存、调用量，分主机级和应用级两张收入表，104 项检查。Productivity Apportionment 更复杂：除利用率外还要拉 Kubernetes 成本（Kubecost）和 EC2 非混合成本（Cloudability），需要 EC2 资源标识符，要分摊主机成本，要算收入减成本的生产力（带显式 NULL 语义），写另一张应用表，80 项检查。实验用真实企业组合：9 个应用，3 个基础设施平台（2 个 K8s 集群加 1 个 EC2 主机），年收入 120 万美元。利用率来自 Instana 实时读数，Revenue 试验跑 2026 年 5 月上半月，Productivity 跑 7 月上半月。agent 手里有 41 个工具：VAR MCP Server 23 个无状态工具，VAR Data Access MCP Server 18 个带 SQLite 持久化的工具。

📝 终检是什么：只看最后一题的考试

先把"终检"这个词说透。CLEA 把评估分成三层。Level 1 是预设的最终数值结果——Revenue 的应用收入，Productivity 的应用收入、总成本、生产力，就这几个数。Level 2 把终检放宽到七项：Level 1 的数，加上其他存储值、归一化和、响应结构。Level 3 才是剩下的一百来项轨迹检查——工具选对没有、参数给对没有、调用顺序对不对、查询作用域有没有越界。

现在看行业惯例。今天企业里验证 agent skill 的标准做法，就是 Level 1 那一档：跑一遍，把最终输出的数字和期望值对一对，对上了，盖章，上线。这个做法省心、便宜、看上去也很科学——数字是硬指标，不会说谎。

但仓库的比喻已经出卖了终检的盲区：只核对最终库存数字的检查，看不见货是怎么搬的。只改最后一题、答案对就给满分的老师，看不见草稿纸上全是错的中间步骤——何况有些题用错方法也能蒙对最后那个数。

为什么在企业 agent 身上这道裂缝格外宽？因为 skill 不是写完就冻住的静态工件。论文列了四个演化轴。其一，工具 API 演化：参数名换了、作用域语义变了，skill 静默崩溃——不报错，就是悄悄做错。其二，规范修订：运营团队攒了经验回来改文档，每次修订都可能以终检捕捉不到的方式改变规划策略。其三，LLM 版本变化：同一家族内换个版本，模糊步骤的默认规划选择可能从保守漂向激进。其四，harness 变化：Claude Code 迁到 Codex，或反过来——终检精度看着差不多，过程级偏差模式可能已面目全非。

四个轴叠加，意味着一个今天验收合格的 skill，下周可能就在没人察觉的情况下变质。CLEA 的核心主张只有一句：企业 agent 的评估必须是持续的过程级评估，终检只是其中最便宜、也最不可靠的一层。

🔬 240 次试验，和一道 92.6% 的裂缝

现在看实验怎么搭的，这个矩阵值得逐格看清：2 个 skill × 2 个规范变体 × 2 个 harness × 3 个模型 × 10 次重复，共 240 次全自动试验。

两个规范变体是 MD（SKILL.md）和 TXT（Skill.txt）：同一 skill 的两种文档形态。Revenue 的 TXT 是大幅浓缩版，904 词对 1,379 词；Productivity 的 TXT 只略短（1,318 对 1,405 词）还加了操作内容。注意作者的强调：MD 和 TXT 的差异估计的是完整修订的敏感性，不是纯格式因果效应。两个 harness 是 Claude Code 和 Codex。三个模型：GPT-5.6-Sol（Azure）、Claude Opus 4.8（AWS）、Claude Sonnet 4.6。

240 次试验里，175 个通过所有适用的终检数值检查。这 175 个"验收合格"的 run 里，162 个（92.6%，Wilson 95% 置信区间 87.7-95.6%）仍藏着至少一个评估器标记的偏差，终检单独漏掉 67.5% 试验的偏差。推到全体：227 个 run（94.6%）至少失败一项检查——真正干干净净的，一只手数得过来。

最震撼的是 Revenue 的极端一致性：120 个 Revenue 试验，全部通过终检；120 个，全部有轨迹偏差。零例外。不是某个模型的坏日子，不是某个配置的意外——是整个 skill 在"最终数字"这一栏上学会了某种稳定的、系统性的投机取巧。作者做了两个稳健性检查：排除 33 个外部错误 run 后是 131/144（91.0%），再排除所有未恢复错误 run 是 136/147（92.5%）。结论纹丝不动。

你可能要质疑：会不会是终检本身太窄？从 Level 1 的一两项扩到 Level 2 的七项——存储值、归一化和、响应结构全查——裂缝会不会自动合拢？不会。通过全部七项的 164 个 run 里，151 个（92.1%，置信区间 86.9-95.3%）仍违反至少一项轨迹检查。Revenue 还是极端的 109/109，Productivity 稍好，42/55（76.4%）。这个对照很要紧：轨迹检查的增量不是"一百项对上一两项数值"的人为产物——终检面扩到七项，九成以上的过程偏差照样漏网。

考试改到七道题，还是看不见草稿纸。

🧬 偏差长什么样：根因家族与级联归因

162 个"数字全对、过程全歪"的 run 摆在那儿，作者把这些偏差按根因家族分了类（各类别非互斥，一个 run 可以同时踩好几条）：

数据/数值一致性偏差 106 个——写入数据库的数和它算的过程中该有的数对不上；缺失阶段或必需工具 66 个——该走的步骤整段被跳过，比如压根没做数据库回读就把数写了；允许列表违规 55 个——调了规范没批准的工具，像仓库管理员随手开了台没登记的叉车；冗余或调用计数违规 43 个——同一个查询翻来覆去打，或者该调一次的工具调了三遍；作用域/过滤器违规 13 个——查询该限定到某集群某主机的，手一抖捞了全局的数据。尾巴上还有响应格式 2 个、工具执行 1 个。作者还特意做了一个消融式验证：就算把"无关工具"这项检查整个摘掉，162 个 run 依然全部还有别的失败检查——这些偏差不是某一种洁癖评估器挑刺挑出来的，是扎扎实实遍布在所有维度上。

想象一个具体的 run。agent 要算 9 个应用的收入分摊，跳过数据库回读，拿暂存阶段的利用率参数就开始算，顺手用了允许列表外的工具去凑数，最后写库的数碰巧赶上容差线——终检绿灯。四个违规，三次绿灯。仓库里那箱忘了入库的货，在数字世界里就是这个样子。

但工程师拿到这样的报告会立刻晕：每 run 平均 6.34 个失败检查，一张工单开一张，修到明年也修不完。CLEA 给了第二个工具：级联归因。两位作者手工编写了一张依赖图，标明检查间的因果链——哪些失败是根，哪些是根的下游效应。顺图遍历，每 run 平均 6.34 个失败检查压缩到仅 2.65 个根失败，58% 的压缩率；中位数更直观，每 run 4 张罚单变 2 张。Revenue 的主要根因：不正确的暂存利用率参数（120 里占 75）、使用允许列表外工具（42）、缺失数据库回读（24）。Productivity 的主要根因：计算工具的应用输入不正确（73）、总成本不正确（40）、按应用过滤的 K8s 查询缺失（38）、按应用过滤的 EC2 查询缺失（31）。

罚单从六张变三张，剩下的三张才是真的病。这个机制的成本是什么？一张依赖图还得人手写——这框架现在还离不开人类的领域知识，这点后面谈局限会回来。

🔄 Harness 反转：没有普适的"听话模型"

第三组结果，是全篇最反直觉、也最值钱的一页。它回答的是从业者真正关心的问题：换 harness、换模型、改文档，到底哪个敏感？

把 Revenue skill 的 MD 和 TXT 两个变体比一比，规范敏感性在两个 harness 下呈现出完全相反的排序。在 Claude Code 上，GPT-5.6-Sol 对规范变体稳健，差异只有 −1.2 个百分点——文档换了个写法，它几乎不为所动；Opus 4.8 和 Sonnet 4.6 则分别是 +9.7 和 +6.3 个百分点的中度敏感。可同样这对比较搬到 Codex 上，模式整个倒转：Sonnet 4.6 变成最稳健的（−0.4pp），而 GPT-5.6-Sol 和 Opus 4.8 出现最大的 TXT 退化（+12.9 和 +11.8pp）。统计上，bootstrap 差中差区间支持 Revenue 的全部三个比较和 Productivity 上 GPT 的 harness 依赖效应；Productivity 上 Opus 和 Sonnet 的不确定。Productivity skill 上则是另一幅温和图景：Claude Code 的模型全部中度敏感（2.1 到 4.6pp），Codex 上的 Sonnet 和 GPT 都稳健（不到 2pp）。

一句话说透："哪个模型更听规范的话"没有普适答案，答案长在一个特定模型和特定 harness 的耦合里。GPT 在 Claude Code 上稳重，搬到 Codex 上最敏感；Sonnet 恰好相反。任何"我们在 Claude Code 上测过没问题"的心安，在迁移 harness 的那一刻自动作废。作者把结论写得很白：迁移 harness 时应该重新评估每一个完整 skill 规范，绝不能假设 MD/TXT 的效应会跟着迁移。

还有两条 harness 相关的实证。Claude Code 在 Revenue 的 TXT 变体上精度始终更高（86.8-95.7% 对 82.1-92.6%）。未恢复错误高度集中在 Codex 一侧：38 个对 5 个，单看 Revenue 是 11 对 4。最极端的是 Productivity 的 Codex-Sonnet 配置——20 个 run 全部带着至少一个未恢复错误，净执行效应根本没法估计。

顺手看一眼账单。240 个 run 总共 859.34 美元，均值 3.58，中位 1.23，最贵的一个 30.23。拉开看：Claude Code 均值 1.04 美元，Codex 均值 6.12 美元——差近六倍。细分到模型，Opus 在 Codex 上是 Claude Code 的 5.9-6.0 倍，Sonnet 是 8.8-10.2 倍，GPT 基本持平（1.0-1.4 倍）。原因也好猜：Claude 模型在 Claude Code 上的缓存读 token 占比高达 90.7-92.9%，在 Codex 上是 0%。贵不贵，一半看模型，另一半看你把它放进哪个 harness——这本身就是"过程重于结果"的讽刺注脚：同样的模型、同样的 skill，换个 harness 账单差六倍，只看终点数字的话，什么差别都看不见。

🛠 五阶段流水线：把"过程"做成可复用的工件

诊断讲完了，看药方。CLEA 的评估框架是一条五阶段流水线，每一阶段都在回答一个具体的工程问题。

第一阶段，捕获。在 skill 规范的第一步加一行指令，让 agent 把解析后的输入参数记到结构化日志；完整的工具调用轨迹——工具名、参数、返回值、对话轮次索引——从 harness 的执行日志里捞出来。

第二阶段，独立计算 ground truth。用独立的 Python 脚本，走一条和 skill 完全独立的执行路径，去调 skill 用过的同一批真实 API。这个"独立性"是刻意的：绝不让 LLM 自己生成 oracle（基准答案），因为依赖 LLM 生成的 oracle 会继承它的错——论文引用了 HumanEval 上的教训，88.89% 的错误测试用例来自错误的输出 oracle。让考生自己出考卷，全对的概率当然高。

第三阶段，物化模板测试用例。测试不写死数字，用占位符——比如 $k8s_host_date_calls 在评估时才从 ground truth 解析成具体值。同一套模板可以套在不同日期范围、应用组合、收入数字上。更妙的是检查之间有依赖链接：测试 B 依赖测试 A 的产出，A 挂了 B 跟着挂，归因时就能分清谁是根谁是下游。这套模板在实践中被证明是可复用的回归工件：同一注册套件跨全部 24 个配置复用（每 skill 一个套件），跨归档物化时，同一检查 ID 覆盖过 4 个不同的 Revenue 期望状态和 16 个不同的 Productivity 期望状态。软件工程里管这个叫单元测试——agent skill 的单元测试，今天绝大多数企业还没有。

第四阶段，三层评估。Level 1 终检数值、Level 2 七项终检、Level 3 一百来项轨迹检查。过程检查沿四个维度展开：工具选择（必需工具调了没有、无关工具碰了没有）、工具参数（日期范围、过滤器、数值参数，全带类型化约束）、工具排序（fetch→stage→readback→allocate→write 这个顺序，拿对话轮次索引逐个比）、参数作用域（按集群按主机逐个查，既查欠覆盖也查过覆盖）。LLM judge（claude-sonnet-4-6）只被用在精确匹配太脆的指定检查上，比如语义等价的 SQL、替代参数表示；所有数值比较一律走计算器工具，不让语言模型碰数字。为什么收敛得这么谨慎？因为 Sonnet 4.6 自己也是被评估的模型之一，LLM judge 存在自偏好偏差的嫌疑——能不用就不用。两位作者人工复审了 60 个随机抽样的 LLM 判定案例，57 个一致，95% 的吻合度。

第五阶段，报告根失败。就是前面讲过的级联归因，顺着依赖图把下游罚单归并到根因上，6.34 张变 2.65 张。

这套流水线还有一个刺眼的压力测试。作者事后模拟"期望值过期"：把 Productivity 的众数期望值冻结住继续跑 120 个 run——80 个 run 里至少一个值跑出界外，终检立刻开始误报；Revenue 倒是稳在容差内。结论双面：运行时解析在观察到的参考变异下有效，但受控演化下的持久性还没被真正测试过。模板测试用例是活的工件，不是一劳永逸的印章——它跟着数据一起老。

🎁 彩蛋：写测试这个动作本身，就在改进规范

这篇论文最温柔的发现，藏在工程日志的边角里。

写测试用例的过程中，评估器三次撞上"算不出期望值"的窘境，每一次都挖出一个规范里根本没写清的隐性政策选择。最典型的一次：EC2 内存。工具能返回主机级或 JVM 级的内存读数，但没有任何合理办法拆到每个应用头上——物理上就是拆不开。评估器的不变量期望零，可"拆不开时到底该存什么"，规范里从来没写过。写测试这个动作，逼着政策空洞浮出水面。同样的事发生在数据库回读排序、EC2 调用作用域上。

这个发现值得单独划线：持续评估不仅验收 skill，还充当"规范完整性工具"。每写一个测试，都是拿探针去戳一遍规范文档——戳到软的地方，规范就补一块。测试驱动开发的老道理，在 agent 时代换了个马甲回来了。

⚠️ 摊在桌面上的局限

作者自己的局限清单，长得罕见地诚实。这是一个企业系统的两个 skill，泛化性开放。每格只有 10 次重复，小效应的统计功效有限。MD 和 TXT 是捆绑变体，不是受控的格式干预。聚合套件分数混合了异质的检查项，不编码失败的严重性——一个格式小瑕疵和一个写错数据库的根因，在分数表上可能长得一样重。83 个 run 至少撞上一个工具或 harness 错误，执行环境本身就不干净。LLM judge 是被评估模型家族中的一员，自偏好偏差没法完全排除。整个比较是固定配置之间的横截面，不是纵向的 API 或模型升级追踪——四个演化轴里真正动态的"时间"这一维，这篇只扫到了边。最后，框架只诊断，不修复——它能告诉你仓库乱了，收拾还得你自己来。

🔚 收官：门、账单，和裂缝

三篇读完，把三条线收拢。

Mímir 的故事里，LLM 想进物理世界，得先造门——宪法锁死，日记常新，解锁要付钱。HydroJEV 的故事里，快筛想省审查费，得装双法官的门——折扣 35-38% 是真的，盲区 66% 的漏网也是真的，快筛有账单。今天 CLEA 的故事里，企业想省掉过程检查、只留终检——最便宜的验收方案，代价是 92.6% 的轨迹偏差从裂缝里无声滑过，Revenue 那一格，120 个 run 无一幸免。

门、账单、裂缝——是同一堵墙的三个侧面。能力从来不是一个开关，而是一份合约：你买到"看起来对"的能力，合约小字里就写着"过程可能全错"；你跳过过程检查省下检查费，账单就改由下游的某个环节在某个深夜支付；你以为换模型、换文档、换 harness 是同一个 skill 在搬家，其实每一次迁移都是重新签一次合约。92.6% 这个数字的用途，不是吓唬谁，而是给所有"验收通过"的报告上加一行小字：本结论仅对最终数值负责，过程健康不在承保范围。

仓库盘点表还是那张盘点表。从今往后，推开大门看一眼货是怎么搬的，再决定信不信表上的数。

参考文献

• Doshi, A., & Sheinin, V. Continual Learning for Enterprise AI Agents (CLEA): Continual Process-Level Evaluation for Evolving Enterprise AI Agent Skills. arXiv:2610.01833 (cs.AI, 2026). https://arxiv.org/abs/2610.01833
• 机构：Georgia Tech、IBM Research