只看结果的评测会把「蒙对」显示成绿灯、把「有价值的失败」错杀——这张过程×结果四象限把两者分开。「危险通过」标记机制、依赖式部分得分、扰动测试抓蒙对、过程只卡「必须/绝不能」的平衡点，全是可直接落地的方法。
先修：a05（Agent Eval 概念），建议先读 a29。评测看板一片绿但心里不踏实的团队——用四象限重扫你的「成功」case。与 a29（工具调用）连读，构成能力维度评测的核心两篇。
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
「蒙对」（结果对+过程错）：在只看结果的评测里显示为成功，换个输入就崩。只测结果的评测会把满屏定时炸弹显示成满屏绿灯。
过程和方向都对，问题往往在外部（工具抖动、依赖出错）。当成 Agent 的错去改 prompt，很可能把本来对的东西改坏——先定位根因在不在 Agent。
① 过程护栏把「结果 pass 过程 fail」标为危险通过；② 扰动测试：微调输入（可退改不可退、换请求人）再跑，真会的稳、蒙对的露馅。
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
上一讲测的是 Agent 的"手"——工具调用。这一讲，我们测它的"脑子"和"成果"：规划与推理（它想得对不对）和任务完成度（它到底办成没办成）。
为什么把这两个放一讲？因为它们是一枚硬币的两面，由一条贯穿全专栏的主线串起来——过程正确性 vs 结果正确性。这一讲的核心，一句话：
光看结果，会放过"蒙对"的定时炸弹；光看过程，会错杀"聪明的捷径"。两个都要，还得懂怎么权衡。
任务完成度评的是 outcome——任务最终有没有达成目标。看起来简单，但有两个坑要处理好。
坑一：别把"成功"简单地当成非 0 即 1。很多任务是多目标的。退款任务其实有两个子目标：① 退款成功；② 发确认邮件。如果 Agent 退成了、却漏了邮件，这既不是完全成功、也不是彻底失败——它是部分成功。硬判成"失败"会丢失信息，硬判成"成功"又掩盖了问题。对多目标任务，用部分得分（partial credit）：给每个子目标一个权重，按达成情况加权。
设权重时还有个容易忽略的点——子目标之间常有依赖。有些子目标是"前提性"的，前提没达成，后面的就无从谈起。"发确认邮件"依赖"退款成功"：如果退款根本没成，那"没发邮件"就不该再单独扣分（因为压根不该发）。所以部分得分不是把子目标简单并列加权，还要考虑"谁依赖谁"——前提失败时，被它依赖的后续目标应从计分里剔除，而不是判成"未达成"，否则你会为同一个根因重复扣分、把分数压得虚低。
坑二：部分得分别滥用到"危险失败"上。有些失败是"一票否决"的——比如错误地给一个不该退的订单退了款。这种绝不能因为"其他子目标都达成"就给个高分蒙混过关。关键项（安全、动钱）要么满分、要么直接判失败，不进部分得分的加权池。
什么时候用二元、什么时候用分档？单目标、判定清晰的任务，pass/fail 最省事也最不易扯皮；多目标、有中间程度的任务，才上部分得分。别为了"看起来精细"给本该二元的任务硬套分档——那只会引入主观和噪声。
过程侧评的是 Agent 想得对不对、走得合不合理。分两块看。
规划质量，三个角度看：
过程正确性，关键是区分两种"看起来一样"的情况：
规划本身，可以在执行前就单独评。对于先规划、再执行（plan-then-execute 型）的 Agent，你能把它产出的"计划"单拎出来评，不必等它执行完：拿计划对照任务的需求清单逐条核——覆盖了所有必须步骤吗（完整性）？每步都可执行吗（可行性）？有没有明显多余的步骤（过度规划）？这种"计划体检"能在 Agent 真正动手、烧掉大量 token 之前，就提前暴露"方向错了"，省时省钱。
多步推理链怎么测？除了看计划，还要看推理链条站不站得住。做法是让 LLM/Agent 裁判逐步核查：每一步推理，是不是从"当前已知信息"合理推出的？有没有跳步（结论对，但中间某步其实没依据、是蒙的）？有没有自相矛盾？记住一句：推理链每步都对，最终不一定对；但中间有一步明显没依据，哪怕最终蒙对了，也该标为过程有问题——这正是区分"蒙对"和"真会"的显微镜。
怎么测过程？过程是轨迹级的东西，手段有三：① 关键步骤断言（序列检查——"退款前必须查状态"）；② LLM 裁判审轨迹（判规划合不合理、有没有走弯路）；③ 复杂轨迹上 Agent 裁判主动核查。
一个现实：过程评测比结果评测更"贵"。结果（outcome）通常客观、能用代码断言；而"规划合不合理、推理有没有跳步、是不是走弯路"这些过程判断，大量是主观的，得靠 LLM 裁判甚至 Agent 裁判。所以过程评测天然更慢、更贵、也更需要校准。取法还是级联：能用序列断言硬卡的过程约束先用代码卡住，剩下真正主观的才上裁判。
把结果侧和过程侧交叉，就得到一张特别有用的四象限——它能让你一眼看清"这次到底是什么性质的成功/失败"：
| 过程对 | 过程错 | |
|---|---|---|
| 结果对 | ✅ 理想：又对又稳，可复制 | ⚠️ 蒙对：定时炸弹，换个输入就崩 |
| 结果错 | 🔧 有价值的失败：方向对，差临门一脚 | ❌ 明确失败：方向和执行都错 |
四个格子，每个的含义和处理都不同：
这张图最大的价值，是让你分清"蒙对"和"有价值的失败"——而只看结果的评测，恰恰把这两者完全颠倒了（把蒙对当成功、把有价值的失败当失败）。这就是为什么过程和结果都得测。
用退款的四条轨迹把四个格子填实：理想——核了身份、查了状态（可退）、退款成功、发了确认邮件；蒙对——没核身份、没查状态，直接退款，碰巧这单是本人、且可退，退成了；有价值的失败——核了身份、查了状态、判断可退、调了 refund，偏偏退款接口临时超时失败了，方向全对，只差工具没给力；明确失败——没核身份，就给一个已发货、不可退的订单退了款，既违规、结果也错。"蒙对"和"有价值的失败"，在只看结果的评测里，一个被记为成功、一个被记为失败——恰好和它们的真实价值相反。
既然两个都要测，怎么合成？两条原则：
原则一：别让简单相加淹没关键信息。如果你把过程分和结果分一加了事，"蒙对"（结果满分、过程零分）可能算出个"及格"，就被放过了。所以——"蒙对"必须能被单独标出来：结果 pass 但过程 fail 的 case，不该显示为"通过"，而该显示为"危险通过 / 不可信的通过"，单独拎出来盯。
原则二：权重看场景的风险。高风险场景（动钱、不可逆、医疗）：过程权重要高，甚至"过程不对直接判不可信"——因为你不容许蒙对，一次靠运气的成功可能就是一次事故的前奏。快速能力探测阶段：可以先粗看结果，过程评测后置。多数生产场景：两个都要，结果为主、过程为护栏。
给退款例子落一下：一次退款，outcome 对了（钱退对了），但过程评分器发现它没核身份。即使结果满分，这个 case 也该被标成"危险通过"——因为它这次没出事纯属这单的请求人恰好是本人，换个冒名请求就是事故。你要的不是"这次成了"，而是"下次也不会出事"。
怎么系统地抓"蒙对"？最有效的一招是扰动测试。把一个"成功"的 case 稍微改一改（换个订单号、把"可退"改成"不可退"、把请求人换成非本人），再各跑几次：真会的 Agent 依然稳，蒙对的 Agent 一扰动就露馅（比如它对"不可退订单"照样退了，说明它之前的"成功"根本没依赖状态检查）。蒙对的本质就是"在这个特定输入上运气好"，而扰动和多跑，就是把运气挤出去、让真实能力现形。
误区一：只测结果（最省事，最危险）。省是真省，但它系统性地放过所有"蒙对"，还把"有价值的失败"错杀。你的看板一片绿，生产却在悄悄埋雷。
误区二：过度苛求过程（把聪明的捷径判死）。另一个极端：你规定了一套"标准解法"，Agent 但凡没照着走就扣分。可 Agent 有时会找到更优的捷径——更少的步骤、更聪明的路径。你按"标准解法"扣它的分，等于在惩罚它变聪明。
举个例子：你的"标准解法"是"查订单 → 查物流 → 查退款政策 → 退款"四步；但某个更聪明的 Agent 发现，订单接口的返回里其实已经带了物流和政策信息，于是它一次 getorder 就拿全了、直接退款。它更快、更省、结果也对——可你的过程评分器因为"它没调 checklogistics 和 check_policy"给它扣了分。这就是在惩罚它变聪明。真正该卡的，是"退款前是否掌握了物流和政策信息"（目的），而不是"是否调了那两个特定工具"（手段）。
平衡点：结果为准绳，过程为护栏。过程评测只卡"必须做的"和"绝不能做的"（必须核身份、绝不能跳过状态检查），而不规定"必须怎么走"。这样既抓住了蒙对，又给 Agent 留出了找更优解的自由。
把这一讲整合进退款评测，大概是这样分层的：结果侧·完成度——退款正确权重 0.7、确认邮件权重 0.3（多目标部分得分）；过程侧·护栏（只卡"必须/绝不能"）——必须先核身份、必须先查订单状态再退款（缺失 = 危险通过）、不得对不可退订单退款（违反 = 一票否决·安全）；判定——outcome 分 × 过程护栏全过？过程护栏有缺失 → 标记"危险通过"，单独盯，不计入"干净通过率"。
注意它没有规定"必须用哪几步、什么顺序"，只卡了几条硬护栏——结果打分，过程设栏。这样一个"蒙对"的退款，outcome 再漂亮，也会被那几条护栏拦下来标红；而一个走了聪明捷径的退款，只要护栏都过、结果也对，就照样满分——既抓住了雷，又没扼杀聪明。