A
Member
最近把内部 Agent 的评测从“凭感觉”改成可复现的流程，踩了不少坑，分享几点落地经验，供同行参考。
一、别先选框架，先定任务集。先从真实业务里抽 50~100 条任务，覆盖高频、长尾和容易出错的场景；每条任务都要写清输入、预期终态和判定标准，并按成功、部分成功、失败三档分级。部分成功尤其要写清楚：是完成了主目标但漏了次要步骤，还是只走对了一半流程，否则评分时很容易各说各话。
二、评分标准要分层。建议分四层：任务完成度看最终结果是否达标；工具调用正确率看参数、顺序和调用次数是否合理；成本与耗时单独统计 token、调用次数和端到端耗时；幻觉与越权行为单列否决项，一旦出现编造结果、越权操作，或删除、修改不应动的数据，直接判失败，不再看其他分数。
三、跑评测要固定条件。固定模型版本、温度和工具环境，同一任务跑多次看波动，只跑一次的分数很容易被偶然性误导。同时记录每次运行的日志、工具轨迹和中间结果，方便复现和定位问题。
四、把结果做成回归基线。每次改提示词或换模型，都跑同一套任务集，对比基线再下结论。分数变化时先看任务集：是任务本身变难、数据变了，还是模型真的退化，避免把任务集偏差当成模型问题。
你们自建评测时，最难统一的是评分标准还是任务集的代表性？
一、别先选框架，先定任务集。先从真实业务里抽 50~100 条任务，覆盖高频、长尾和容易出错的场景；每条任务都要写清输入、预期终态和判定标准，并按成功、部分成功、失败三档分级。部分成功尤其要写清楚：是完成了主目标但漏了次要步骤，还是只走对了一半流程，否则评分时很容易各说各话。
二、评分标准要分层。建议分四层：任务完成度看最终结果是否达标；工具调用正确率看参数、顺序和调用次数是否合理；成本与耗时单独统计 token、调用次数和端到端耗时；幻觉与越权行为单列否决项，一旦出现编造结果、越权操作，或删除、修改不应动的数据，直接判失败，不再看其他分数。
三、跑评测要固定条件。固定模型版本、温度和工具环境，同一任务跑多次看波动，只跑一次的分数很容易被偶然性误导。同时记录每次运行的日志、工具轨迹和中间结果，方便复现和定位问题。
四、把结果做成回归基线。每次改提示词或换模型，都跑同一套任务集，对比基线再下结论。分数变化时先看任务集：是任务本身变难、数据变了，还是模型真的退化，避免把任务集偏差当成模型问题。
你们自建评测时，最难统一的是评分标准还是任务集的代表性？