考察点
这类问题常出现在 Agent 项目深挖环节，面试官想区分「调过 prompt」和「真正建过评估体系」的候选人。核心考点是你是否理解：Agent 的价值在多步决策，而多步决策的错误模式和单轮 LLM 完全不同。追问多往「轨迹怎么自动评」「评估数据从哪来」走。
参考答案
两个概念先对齐
结果评估（outcome evaluation）只看最终产物：答案对不对、任务完没完成、环境到没到目标状态。轨迹评估（trajectory evaluation）看过程：每一步的推理是否合理、工具选对没有、参数填对没有、中间结果有没有被正确利用。同样的任务，一个 Agent 可能 3 步干净利落地完成，另一个绕了 12 步还撞了两次错最后侥幸成功——结果评估看来两者一样，轨迹评估能把它们区分开。
为什么只做结果评估不够
三个理由。第一，运气分。多步任务里存在「错错得正」：中间检索错了文档，但模型靠参数里的知识蒙对了答案。结果评估给满分，实际系统隐患没暴露，换个相似 case 就翻车。第二，无法归因。成功率从 75% 掉到 70%，只看结果你不知道是规划退化、工具接口变了还是模型换了版本。有轨迹评估，错误可以直接定位到具体步骤类型。第三，成本盲区。结果相同的两条轨迹，token 消耗可能差 5 倍，这在生产上就是真金白银。
反过来只做轨迹评估也不行：轨迹漂亮但业务目标没达成（客服 Agent 聊得很规范但没解决问题），说明评估标准和业务脱节了。结果是锚，轨迹是诊断手段。
轨迹评估具体怎么做
工程上依赖完整的 trace 记录（OpenTelemetry 或 LangSmith、Langfuse 这类平台），每一步留存：模型输入、原始输出、解析出的工具调用、工具返回、耗时和 token。评估维度一般拆四个：
- 工具选择正确性：这一步该不该调工具、调的是不是对的那个。可以离线用另一个强模型对照「理想工具序列」判分。
- 参数正确性：schema 校验能挡住格式错，但语义错（日期格式对、日期值错）要靠规则或 judge 模型比对上下文。
- 信息利用率：上一步拿到的关键信息，后续步骤有没有用上。RAG 型 Agent 常见问题是检索到了正确文档但最终答案没引用它。
- 效率：步数、重复调用率、无效调用率。重复调同一个工具同一份参数，基本就是上下文管理出了 bug。
自动化的主流做法是「轨迹 + LLM-as-Judge」：把整段 trace 喂给强模型，按评分表（rubric）逐步打分再汇总。注意 judge 的上下文有限，长轨迹要按步切片评，不要整段糊进去。
结果评估的三种判定强度
按可靠性从高到低：环境校验（跑测试、查数据库终态、对 API 返回码）最硬，能用的场景优先用；规则匹配（关键字段比对、正则）次之；LLM-as-Judge 和人工评分最软但覆盖面最广。生产体系通常是三层金字塔：底部全量自动指标，中部 judge 批量评，顶部人工抽检校准。
两者怎么配合迭代
落地节奏一般是：结果指标做监控和回归门禁（成功率下降超阈值就拦发布），轨迹指标做归因和优化输入。发现 badcase 后第一步就是拉 trace 看轨迹，定位是哪类步骤出问题，修完把这个 case 连同轨迹标注一起进评测集。轨迹标注还有个副产品：高质量轨迹本身就是 SFT 或蒸馏的训练数据，评估体系和数据飞轮是同一套基础设施。
可能的追问
- 轨迹评估能用 reference-free 的方式做吗（没有标准轨迹时）？ 答：可以，用 rubric 让 judge 评「这一步决策在给定信息下是否合理」，不需要标准答案；但噪声大，建议只对关键步骤（工具选择、最终生成前的最后一步推理）用，配合规则指标兜底线。
- 多 Agent 系统的轨迹评估和单 Agent 有什么区别？ 答：多了一层协作维度：任务分解是否合理、Agent 间传递的信息有没有丢失或变形、责任归属（错误发生在哪个 Agent）。trace 需要跨 Agent 的关联 ID，否则根本拼不出完整链路。
- 轨迹太长 judge 评不动怎么办？ 答：按步切片评分再聚合，或者先做异常检测（超时步骤、重复调用、解析失败）只把异常段送 judge，正常段用规则指标覆盖，成本能降一个量级。