一张 3 层 × 4 维的网格把 Agent 评测彻底结构化，附两个直接能用的玩法：按「风险 × 概率」圈出重兵格子、用三个问题给现有评测做十分钟体检。与 a15 互补：a15 告诉你每个维度怎么打分，这篇告诉你先测哪个格子。
先修：无硬先修，建议先读 a05。需要从零搭建或盘点评测体系的人：先读这篇拿到地图，再用 a15 的评分器模板填格子。属于「结构工具」，按需查阅。
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
端到端（任务成了吗）→ 轨迹级（过程走得好不好）→ 组件级（具体哪一环坏了）。端到端告诉你病了，组件级才能挖到根因。
① 12 个格子里哪些根本没测？② 空白格子里有没有正对着最大风险的？③ 哪个格子用力过猛？——分别暴露欠债、偿还顺序、精力错配。
把最怕的失败模式贴到网格上，按「风险 × 概率」圈重兵区：财务类守端到端×任务完成 + 安全；RAG 客服守组件级检索事实性 + 注入安全；编码类守任务完成 + 工具调用/规划。
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
走到这里，你手里已经攒了不少东西：范式跃迁的四个转变（第 1 讲）、"模型 + harness"的系统观（第 2 讲）、循环及其评测项（第 3 讲）、一套通用语（第 4 讲）。但你可能也有点感觉——这些视角还散着，像一桌摊开的拼图，缺一张能把它们拼起来的总图。
这一讲就是那张总图。我们用两个维度，把"Agent 评测"这件事彻底结构化：
三层乘四维，就是一张完整的评测全景图。更妙的是，你会发现：这张图，其实就是这门专栏接下来所有内容的骨架。
第一个维度，是"看的粒度"。同一次 Agent 运行，你可以站在三个不同的距离去看它。
第一层，端到端（end-to-end）：整件事成了吗？这是最粗、也最贴近业务的视角。它只问一个问题：这个任务，最终在真实世界里达成了没有？退款例子里，就是"钱退了、邮件发了，且都正确"。它对应的是 outcome——世界的最终状态。端到端是你最该先建立的一层，因为它直接对应用户和老板关心的东西。但它有个短板：它只告诉你"成没成"，不告诉你"为什么"。
第二层，轨迹级（trajectory）：这条路走得好不好？放大一格，看 Agent 走过的整条轨迹：它的规划合不合理、工具调用的顺序对不对、有没有在原地打转、出错后有没有恰当恢复。它回答的是"过程质量"。轨迹级，正是用来抓"结果对、过程错"的层次。
第三层，组件级（component）：到底是哪一环坏的？再放大到最细，盯住轨迹里的单个环节：某一次工具调用的参数对不对、某一步检索召回得准不准、某一次 LLM 裁判打分靠不靠谱、某个子 Agent 交接得干不干净。它回答的是"具体哪一颗螺丝松了"。组件级是定位和调试的层次。端到端告诉你"病了"，轨迹级告诉你"大概在消化系统"，组件级才能指到"就是这一段肠子"。
三层是"下钻"关系。实际排查问题时，你几乎总是从端到端往下钻：先看整体成功率（端到端）→ 失败的 case 调出轨迹看过程（轨迹级）→ 锁定可疑环节做细查（组件级）。这条下钻链，也解释了为什么"可观测性 / Tracing"那么重要——没有完整轨迹，你根本下钻不下去。
假设线上监控报出来：退款 Agent 这周的成功率，从 92% 掉到了 78%。你要查这是怎么回事。
站在端到端看，你只看到一个事实：成功率掉了 14 个点，一批退款任务的 outcome 没达成（钱没退成）。这一层告诉你"出事了、有多严重"，但到此为止——它指不出原因。于是你往下钻。
站在轨迹级看，你把这周失败的几十条 trial 的轨迹调出来，对比成功的轨迹，找规律。很快发现：失败的轨迹几乎都卡在同一个形状——调用 refund 工具那一步拿到了报错，然后 Agent 反复重试了好几轮，最后超出步数上限、放弃。这一层告诉你"卡在退款这一步、而且重试逻辑也有问题"，范围一下子缩小了。但具体是退款工具怎么了，还得再钻。
站在组件级看，你单独盯住那一次 refund 调用，检查它的入参和返回。这才发现真相：上游某次发布改了订单状态的字段名，refund 工具拿到的 order_id 关联不上新状态，返回了参数错误。根因找到了——根本不是模型变笨了，是一个上游字段改名。
你看，端到端告诉你"病了、多重"，轨迹级告诉你"病在退款环节、还带重试问题"，组件级才挖到"上游字段改名"这个根因。三层缺一层，你的排查就会卡在某个粒度上下不去。
第二个维度，是"衡量的角度"。不管在哪一层看，你关心的无非这四类东西。
维度一，任务完成（task completion）。最根本的一维：它到底把事办成了吗？包括结果是否正确、多目标任务完成了几成、该达成的 outcome 达成了没有。这是所有评测的"主菜"。
维度二，工具调用（tool use）。Agent 区别于单轮模型的核心能力之一：工具选得对不对、参数传得准不准、调用顺序合不合理、有没有冗余调用或该调没调。
维度三，规划推理（planning & reasoning）。多步任务里的"脑子"：规划是否合理、推理链条是否站得住、有没有走弯路、会不会"蒙对"。它决定了 Agent 在复杂任务上的上限。
维度四，安全与成本（safety & cost）。容易被忽略、却最影响"敢不敢上线"的一维。安全：会不会越权、会不会被提示注入带跑偏、该停下问人的地方有没有停。成本：一次任务烧多少 token、多少时间、稳不稳定、会不会陷入死循环把预算烧爆。
这四维之间不是孤立的——一个糟糕的规划（维度三）会导致一堆冗余的工具调用（维度二），进而推高成本（维度四），最后任务也没完成（维度一）。但分开来看，能让你精确地说出"它差在哪一维"，而不是笼统地说"它不太行"。
| 维度 | 合格长什么样 | 出问题长什么样 |
|---|---|---|
| 任务完成 | 该退的退了、该拒的拒了、邮件如实 | 谎称"已退款"其实没退（output≠outcome） |
| 工具调用 | 选对 refund、参数对、退款前先查状态 | 调错工具、订单号传错、没查状态直接退 |
| 规划推理 | 多步有条理、该澄清就澄清 | 绕一堆无谓步骤，或"蒙对"了但过程站不住 |
| 安全与成本 | 高风险退款走审批、单均成本可控 | 被订单备注里的注入指令带着越权退款、或陷死循环烧爆预算 |
现在把两个维度叉乘起来，得到一张 3 × 4 的网格。每个格子，都是一类具体的评测问题：
| 任务完成 | 工具调用 | 规划推理 | 安全与成本 | |
|---|---|---|---|---|
| 端到端 | outcome 是否达成（最核心） | —（工具多在过程中看） | 整体策略对不对 | 全程总成本/延迟、是否发生越权 |
| 轨迹级 | 多目标完成度、部分得分 | 调用序列是否合理、有无冗余/漏调 | 规划质量、有没有走弯路或蒙对 | 中途该不该停的地方停了吗、有无死循环 |
| 组件级 | 某子任务/子 Agent 是否完成 | 单次调用参数对不对 | 单步推理/检索这一步准不准 | 单个高风险动作前有没有过审批 |
这张网格，就是评测的全景图。它的价值在于：任何一个 Agent 评测问题，你都能在图里找到它的位置。当有人说"我要测一下我的 Agent"，你可以反问一句——你说的是哪个格子？一旦定位到格子，方法和指标就清晰了。
要提醒一句：不是每个格子都要测、都同等重要。有些格子（比如端到端 × 工具调用）天然意义不大，工具更多在轨迹/组件层看。
光有图不够，关键是会用。最实用的用法，是用它来排优先级——因为你不可能、也不需要把 12 个格子都测满。方法很简单，三步：
第一步，把你 Agent 已知或最怕的失败模式，往图上贴。想想你的 Agent 最容易死在哪种失败上？把它定位到具体格子。
第二步，按"风险 × 概率"决定哪些格子要重兵把守。哪个格子一旦出问题后果最严重、又最常发生，就先测哪个、测得最密。
第三步，其余格子用轻量手段兜底，别平均用力。
不同形态的 Agent，重心会很不一样，给你三个对照：
同样一张图，三种 Agent 圈出的"重兵区"完全不同。先有全景图，再按自己的业务圈重点——这就是从"东一榔头西一棒子地测"到"系统化评测"的关键一步。
这张图还有个立刻能用的用法：拿它给你现在的评测照一次 X 光。把这 12 个格子（3 层 × 4 维）一个个过一遍，问三个问题：
第一问暴露"评测欠债"，第二问告诉你先还哪笔债，第三问帮你把过剩的精力挪到刀刃上。一张图、三个问题，十分钟就能让你看清自己评测的全貌和窟窿——这比闷头再多写几个用例有用得多。