agent eval应该有不同颗粒度的，你讲讲这个

回复 joye： 对，eval 不是一个东西，是一摞不同倍数的放大镜。从细到粗大概四层，越往下越贵、越接近真实价值，但越难定位问题。 最细一层是零件级。就是看单独一步做得对不对，不关心整件事成不成。还是修 bug 那个例子：给它一个函数加一段报错，只看它第一步干嘛——是先去读文件，还是直接拍脑袋改？再比如工具调用，它决定调搜索还是调读文件，参数里的路径写对没有，JSON 有没有拼错。这一层最好写，因为大多数能直接用代码断言，不通过就是不过。好处是便宜、快、可复现，跑一百个用例几秒钟几厘钱；坏处是它跟"用户爽不爽"离得远，零件全对不代表活干得成。 往上一层是轨迹级，看整条路线。同样的结果，一个 agent 三步搞定，另一个绕了二十步、同一个文件读八遍、中间还声称跑了测试其实没跑——端到端那层这俩都是"通过"，只有轨迹层能把它们分开。看的指标也具体：总步数、有没有重复动作、有没有"改完自己再验一遍"这个环节、读文件跟写结论的比例。你换规划器、加工具、改 prompt 的时候，主要看这层，因为端到端太粗，失败了也不知道是哪儿坏的。 再往上是任务级，也就是端到端。一句话：活干完没有。修 bug 就是测试真绿了没有，文件是不是真改了，而且 diff 只动该动的地方、没顺手把别的功能删了。这是最接近用户感受的一层，也是发版前必跑的一层。它的问题是噪声大：同一个任务 agent 每次走的路不一样，跑一遍过了不算数，得跑三遍看稳不稳，所以贵、慢，失败了你只知道"不行"，不知道为什么不行为什么。 最粗的一层是会话级或长任务级。前面几层都是一个任务跑完就结束，这层看的是长跑：一个要改三个文件、跨十几分钟的活，中途插进来一条无关消息，看它目标还在不在；或者今天跟它说过的事，明天还在不在。这层的坑最多，也最容易被忽略，因为前面几层全绿的项目，一到长任务照样散架。 还有一个跟颗粒度配套的东西：判分手段也在变。细的那两层能写死断言，让代码判；粗的那两层往往只能靠 LLM 当裁判或者人工看，而裁判本身又有噪声，所以端到端用例一般都不会多。 实际怎么用：金字塔。底层堆大量便宜的单步用例，随时跑，改一行 prompt 就能马上知道有没有踩坏东西；中间放一小撮轨迹用例，架构动了才跑；塔尖放极少几条端到端，发版前跑。反过来只有塔尖没有底座，你就只能看着一个红叉干瞪眼。