Agent 评估体系
最容易踩的四个坑

01 / WRONG TARGET

第一个坑：把运行态问题塞进静态评估

设计评分体系时，最自然的起点是问“什么是一个好的 Agent”。我最初的版本里有一项叫“流程标准化质量”，直觉判断标准是：同样输入是否同样输出，新人能否复现老手水平。

问题是，这两个属性是运行态属性——你需要实际跑几轮才能判断它们，光看 Agent 的设计文件根本评不出来。静态文件里能看到的，是流程写了什么步骤、每一步有什么输入输出、异常有没有收口。至于它跑起来是不是真的稳定，那是运行时的事。

把运行态属性硬塞进静态评估的后果是：评分结果完全取决于评分者怎么“脑补”这个 Agent 跑起来会怎样。同一个人评两次，分数可能差十几分。一个不能稳定观测的指标，设计再精细也是噪音。

我后来把这一项拆成两个真正能静态评的维度：width——覆盖了多少真实业务场景，和operationalization depth——每个已覆盖场景是否被写成可执行 procedure，而不是原则口号。这两个维度都是静态可验证的，而且和业务价值直接相关：场景覆盖广、流程能执行，就比“看起来标准化”有用得多。

不能静态稳定观测的属性，不要强行设计静态指标。评不出来就是评不出来，换一层去评。

02 / UNTESTED ASSUMPTION

第二个坑：默认“能打分”等于“能预测价值”

评分体系搭完之后，所有人都默认一件事：分数高的 Agent，上线后质量就好。这个假设看起来不需要论证——分数就是质量嘛。但它可能从一开始就不成立。

静态文件中的结构、指令、反模式，真的能稳定预测上线后的执行质量和故障风险吗？我审视了自己的框架：19 个指标，每个都有清晰定义，MECE 看起来也成立。但如果拿一个静态评分 85 分的 Agent 和一个 60 分的 Agent，对比它们上线后的实际运行质量——我能证明前者真的比后者跑得好吗？

诚实地说，我没做这个回测。而在企业环境里，静态评分一旦被用来做准入或下架决策，它就在实质上充当“预测器”。如果预测能力从未被验证，那再精细的指标也只是“看起来专业”的代理变量。

另一个相关的问题是“隔离幻觉”。评审多 Agent 系统时，一个常见做法是把评估拆给多个独立 reviewer，避免锚定偏差。但切分 reviewer 只消除了顺序偏差——如果多个指标都在读同一份 Agent 定义文件、同一份上下文说明，它们共享的证据源并没有被切断。你以为隔离了，实际上只是换了几个角度看同一组数据。

我后来的做法是，在评分正式用于决策之前，必须做一次带真实运行标签的回测：拿一批已经上线、运行质量已知的 Agent，用静态框架打分，看分数和运行结果是否相关。如果不相关，说明框架评的是“文档写得好不好”，不是“上线后会不会出问题”——这是两件事。

先验证你的指标和真实结果是否相关。如果不相关，指标越精细，误导越精确。

03 / FAKE MECE

第三个坑：指标看起来 MECE，实则在重复扣分

MECE——互不重叠、完全穷尽——是指标体系的基本要求。但“写一句互不重叠”不等于 MECE 真的成立。我在框架里犯的最隐蔽的错误，是同一类缺陷被多个指标同时命中。

举一个具体的例子。一个 Agent 如果“业务目标不清晰”，在我的框架里会同时被这几项扣分：目标不清（扣）、场景边界不清（扣）、入口路由不清（扣），然后可能再被“反模式”额外扣一次。表面上看，每项都在评不同的维度；实际上，“目标不清”这一个根因，触发了四条指标同时降分。最终这个 Agent 的分数被异常放大了——不是因为它有四个问题，而是因为一个问题被记了四次。

真正的 MECE 不是列一堆看起来不重叠的指标名，而是每一类缺陷必须有且只有一个 owner metric。先列 defect taxonomy——可能出现的所有缺陷类型——再给每类分配唯一负责的指标。而不是先拍 20 个指标名，然后假装它们不重叠。

判断方法也很简单：如果同一个问题的修复动作相同——比如“把业务目标写清楚”——却会命中多个指标，说明体系大概率不够 MECE。因为修复同一个缺陷只需要一个动作，它就应该只对应一个扣分点。

还有一个容易漏的角落：antipattern这类“兜底”指标。如果它收录的问题已经被其他指标覆盖了，就会变成重复扣分的来源。要么把它做成 hard gate（命中即不通过，不额外扣分），要么只收录其他指标确实没有覆盖的问题。

MECE 不是写一句“互不重叠”就成立。判断标准是：同一个缺陷，是否只触发一个指标。

04 / WRONG DIRECTION

第四个坑：把交互摩擦当成使用深度

评估 Agent 的使用情况时，最容易拿到的数据是会话时长和交互轮次。直觉上，用户和 Agent 聊得越久、来回越多，说明使用越深入。我最初也把这两个量塞进了“使用深度”指标。

但在审视真实数据时，我发现一个反模式：会话时长和交互轮次很多时候越高，反而说明 friction 越大。用户反复追问、反复纠错、反复让 Agent 重试——这些都会拉长会话、增加轮次，但它们说明的不是“使用深入”，而是“体验糟糕”。一个真正好用的 Agent，可能三轮以内就完成了任务；一个难用的 Agent，可能需要十轮才磕磕绊绊做到同样的结果。

这就是指标设计里最危险的陷阱：伪第一性。公式很漂亮，维度看起来也合理，但变量和业务含义不是单调关系。“会话时长”这个数字，在有的情况下代表深度，在有的情况下代表摩擦。把它统一塞进“使用深度”桶里，总分会奖励低效系统。

我后来把“使用深度”和“交互摩擦”彻底分开。深度看的是：用户是否完成了任务、是否在后续工作流中再次回来使用。摩擦看的是：用户需要多少轮纠正才能得到满意结果、中途放弃率有多高。两个指标方向相反——深度越高越好，摩擦越低越好——不能混在同一个分母里。

更一般的原则是：先问每个指标对北极星是不是单调同向。如果方向不确定——比如会话时长，高可能是深度也可能是摩擦——不要硬塞进一个桶。宁可拆成两个指标，也不要假装它是单调的。

把交互摩擦当成使用深度，等于奖励一个让用户反复纠错的系统。

05 / WHAT WORKS

什么管用：先验证再信任

四个坑讲完，可以总结一下我从中真正学到的东西。不是某个具体的方法论，而是一条原则：评估体系本身也需要被评估。

这套体系后来扩展到了公司级能力资产的全景追踪——从 Agent 级的可观测性，到资产级别的覆盖广度、使用深度和实际效果。但核心方法论没有变：先定义评估对象的本质，再验证指标和真实结果的关系。

如果你也在做类似的工作，最后一句建议是：不要急着搭框架。先问自己一个可能让整个框架坍塌的问题——“我评的这个东西，和我真正想知道的结果，到底是不是同一件事？”

评估体系最大的陷阱，不是指标不够多，而是默认“能打分”等于“能预测价值”。