业务问答 Agent 收到追问“那同比呢”，恢复了错误区域，检索到一份过期口径，又调用了参数合法但日期错误的工具。最终答案可能只表现为一个数字错了，修复位置却有三处。
第 7 章已经定义了任务结果、执行路径、单次决策和运行事实等评价对象。本章直接把这套方法用于多轮对话、RAG、工具调用和 Agent 轨迹：先确认失败属于哪一层，再为该层准备足够证据。结果判断用于确认用户损失，局部检查用于定位修复点。
多轮对话：质量存在于消息之间
用户先说“本月只看华中区”，下一轮问“那同比呢”。第二句话单独看几乎没有信息。系统需要从历史中恢复区域、时间和指标，再判断当前应该回答还是澄清。
多轮评估至少要同时观察当前响应和会话进展。当前响应需要遵守已经确认的约束，正确理解指代与省略；会话层面则要看目标最后是否完成，系统有没有遗忘信息、前后矛盾或原地打转。信息不足时主动澄清可能是正确动作，因此不能把“每轮直接回答”当成统一标准。
一个可重放样本应保存初始目标、截至当前轮的消息历史、持续有效的约束，以及期望的下一步或最终结果。线上出现“忘记华中区”的失败后，可以截取失败前的历史，构造 N+1 测试：让修改后的系统面对相同历史，比较下一次响应。尚无足够真实会话时，也可以模拟用户完成多轮交互，不过模拟数据只能补覆盖，真实用户的省略、改口和异常路径仍要从线上获得。
在 Langfuse 中，Session 可以关联多轮 Trace，消息历史也可以存入 Dataset Item 运行 Experiment。Score 可以描述上下文保持或任务完成。Session 是一种具体承载方式；迁移到其他平台时，需要保住会话 ID、消息顺序、状态快照和评分语义。
RAG：沿证据链判断哪里断了
RAG 的回答错误，可能是资料没找回来，也可能是模型没有使用已经找回的资料。评估时应沿数据流拆开。
检索环节先看所需证据是否被找回，以及返回内容中有多少真正相关。Context Recall 和 Context Precision 常用于描述这两个方向。Top K、过滤条件、查询改写、排序分和文档版本也要保存，因为范围错误往往发生在过滤与路由，而不是向量检索本身。
接着看回答是否忠于提供的上下文。Faithfulness 判断答案中的事实能否由当前证据支持。它与现实世界的事实正确性并不相同：回答可能碰巧正确，却没有使用给定证据；也可能忠实复述了一份过期文档。前者属于证据使用，后者要回到知识源治理。
最后再看答案是否解决了用户问题。Answer Relevancy、完整性和引用准确性都可以按业务选择。用户问“华中区本月消耗同比下降原因”，系统却检索全国环比数据，语言再流畅也不该先归咎于生成 Prompt。Trace 中的过滤条件和检索结果已经指出修复位置。
离线 Dataset 可以保存问题、参考证据或证据判定规则，以及必要的参考答案。没有唯一答案时，仍可判断证据支持和相关性；Context Recall 若缺少参考文档，解释会弱很多。在 Langfuse 里，检索、重排和生成可以记录为同一 Trace 下的 Observation，再接收规则、人工、Ragas 或 Judge 产生的 Score。指标来自评估方法，平台负责把过程和结果放在一起。
工具调用：检查一次动作是否合适
工具评价关注一个具体决策。在当时的用户输入、上下文和候选工具下，Agent 是否应该调用工具，是否选对工具，结构化参数是否符合业务语义。Schema 校验通过，只能证明格式合法。日期少一天、区域传成全国，接口仍可能返回成功。
调用后的处理也属于这次决策。空结果、超时和权限错误出现时，系统是否识别状态，是否应该重试或询问用户；拿到结果后，最终回答有没有改错单位、漏掉限制条件。采集时需要保留调用前可见的上下文、工具描述、工具名、参数、返回值或错误，以及结果怎样进入后续步骤。
确定性部分优先用代码断言，比如工具名、必填参数、枚举范围和调用次数。“现在是否需要查实时数据”更依赖语境，可以交给人工或校准过的 Judge。Dataset 里可以保存期望工具、关键参数和允许范围，不必要求所有参数逐字相同。
例如“看昨天武汉项目的消耗”，参考动作可以要求调用 query_spend，城市为武汉，日期是昨天对应的闭区间；若结果为空，应明确提示无数据。把工具选择、日期归一化和空结果处理分开检查，失败后才知道应该修意图识别、参数组装还是结果解释。
Langfuse 可以把工具步骤记录为 Observation，并将规则或 Judge 的结果写成关联 Score。到了 v4，在线 Evaluator 以该 Observation 自身字段为输入，不会自动读取整条 Trace 或 Session。若判断需要更广的上下文，应在埋点时把必要证据汇总到目标 Observation，或放到 Experiment、外部评估流水线中处理。旧 Trace 级 Evaluator 的示例要结合兼容矩阵阅读。
Agent 轨迹：判断整条路是否可接受
单次工具调用正确，整条路径仍可能很差。Agent 也许连续检索三次，重复调用相同接口，最后偶然得到正确答案。轨迹评价观察动作怎样组合，以及系统何时停止。
评价前先定义可接受路径。某些任务有严格顺序，比如鉴权后才能查询；另一些任务允许不同工具达到相同结果。此时不应要求轨迹逐项匹配唯一答案。更实用的参考包括必要步骤、禁止动作、先后约束和预算。
轨迹评价需要回答几类具体问题：关键步骤是否存在，失败后有没有根据新信息调整，是否出现循环，步骤数和外部调用成本能否接受，过程中有没有越权。任务最终是否完成仍要保留，因为一条路径再漂亮，没有交付结果也不能算成功。
以“分析华中区消耗下降原因”为例，系统可能先确认比较口径，再查询消耗和同比数据，最后解释差异。若它从全国销售额开始，多次换词搜索后才碰到正确接口，结果可以正确，路径效率和工具选择仍应扣分。反过来，实际路径与参考不同，只要证据完整、约束满足且成本合理，就不该因为顺序不同被判失败。
实践中可以先人工阅读一批真实 Trace，归纳常见成功路径和高风险失败，再把必要工具、允许替代路径、禁止动作与预算写入 Dataset。确定约束由规则检查，路径合理性和重试依据可由人工或 Judge 评价。低轨迹分只是入口，根因仍要下钻到具体 Observation。
Langfuse 通过嵌套 Observation 和工具调用记录采集轨迹，Agent Graph 负责把已有事件可视化。它不会代替埋点生成缺失的步骤。可迁移资产是原始事件、父子关系、工具语义、路径约束和评分理由，而不是某张产品界面上的图。
怎样组合这些评价
复杂 Agent 不需要为每次运行启用所有评估。先从业务风险反推证据：多轮产品容易丢上下文，就保留会话目标和 N+1 测试；RAG 的主要风险是证据错误，就重点检查检索与忠实度；能执行外部动作的 Agent，应把权限、参数和禁止步骤设为硬约束。轨迹评价适合解释整体效率和收敛问题。
同一 Score 名称也不要跨对象混用。“正确性”挂在检索步骤、最终回答和 Session 上时，实际含义不同。名称、评价对象和量表应一起版本化。线上评价用于发现新失败，离线 Experiment 则让不同版本在同一组复杂场景上接受比较。
这一套分层方法不依赖 Langfuse。只要平台或自建系统能保存会话顺序、检索证据、工具事件和轨迹关系，并把评价结果关联回正确对象，就能完成同样工作。工具真正影响的是采集和分析效率，评价逻辑仍来自产品任务。
参考资料
系列目录：AI 应用可观测性与评估