评估

为什么不能只看最终回答像不像？

智能体会调用工具、走多步、把环境改掉。最后一句说得通，可能中间用错了工具、用了没返回的数字，或者只是碰巧答对。评估要能在改提示和改循环时重复跑，而不是上线前看几个演示。

先写成功是什么样：答案对、工具用对、步数和费用在预算内、不执行不该执行的动作。说不清成功，指标没有意义。

工具调用和通用助手各看什么？

两类基准面试要分开，不要混成「准确率」。

工具调用看的是函数名和参数是否匹配，参数顺序可以不同，等价表达式可以算对，函数名错或参数值错算失败。BFCL 是这一类的代表，里面还有单函数、多函数、并行调用这些子集。报结果时要说清测的是哪一类，而不是一个总分。

通用助手看的是开放任务能不能做完，答案往往要精确匹配，并按难度分级。GAIA 是这一类的代表。要同时报总体和分级，因为模型经常在简单档很高、难档掉下去。

轨迹比最终对错多出来的信息是：哪一步选错工具、哪一步忽略了观察、失败是规划错还是参数错。

没有标准答案时怎么评？

生成类任务可以用三种办法，都要说明局限。

• LLM 评审：另一次调用按维度打分。便宜，但评审模型和被评模型会共享偏见。
• 胜率：同一题比较两个系统，看谁更常赢。适合对比改动前后，不适合当成绝对质量。
• 人工看：抽轨迹，不只看分数。用来校准自动评审，不适合每改一次都全量看。

自动分和人看冲突时，以人看的失败类型为准，再改自动规则。

评估怎么嵌进开发？

先跑很少的样本确认脚本和解析是对的，再加大。每次只改一个变量：提示、工具描述或模型。把类别准确率、失败样本和轨迹留下来，才能知道这次改动修好了哪一类、伤了哪一类。

完整跑官方榜、提交排行榜，是项目流程，面试答到「本地先有可重复的小集」就够。