Agent 轨迹评估工程：从单点指标到过程级质量保障的生产框架

2024 年之前，Agent 评估几乎完全依赖最终成功率。 任务完成了就是成功，失败了就是失败。这种二元判断在单轮问答场景下足够用，但在多步自主执行场景中暴露出三个致命问题。

第一，无法定位失败环节。 一个 10 步的 Agent 任务失败了，你知道它失败了，但不知道是哪一步出了问题。是工具调用参数错误？是中间推理逻辑断裂？还是最终答案格式不符合要求？单点指标把整个执行过程压缩成一个 0/1，丢失了所有过程信息。

第二，无法区分'好失败'和'坏失败'。 一个 Agent 在 9 步都正确的情况下因为最后一步格式错误而失败，和另一个 Agent 在第 2 步就完全偏离正确路径，在单点指标下都是"失败"。但这两种失败的根本原因完全不同，需要的优化策略也完全不同。

第三，无法支撑回归测试。 你修改了 prompt 或更换了工具链，想知道性能是提升了还是下降了。单点指标只能告诉你"之前成功率 60%，现在 62%"，但无法告诉你：哪些任务类型变好了？哪些变差了？是工具调用环节改善了还是推理环节退化了？

AgentBench（arXiv:2308.03688）在 2023 年 8 月首次系统性地揭示了这个问题。 他们在评估 8 个不同 Agent 框架时发现，仅看最终成功率会掩盖大量过程级差异。例如，两个框架在 WebShop 任务上的成功率都是 45%，但一个框架在"商品搜索"环节准确率高而在"加入购物车"环节频繁失败，另一个框架则完全相反。这种差异在单点指标下不可见，但对工程优化至关重要。

WebArena（arXiv:2307.13854）在 2023 年 7 月进一步证明了这一点。 他们在真实网站环境中测试 Agent 的多步执行能力，发现即使最终成功率相同的两个系统，其轨迹质量（路径效率、错误恢复能力、工具使用合理性）可能截然不同。一个系统可能通过冗长的试错达到目标，另一个系统可能一步到位——单点指标无法区分这两种情况。

边界说明：本文聚焦轨迹评估的工程实现，不涉及 Agent 记忆系统的基准测试（已在 agent-memory-benchmarks-001 中覆盖），也不讨论沙箱隔离设计（已在 agent-eval-sandbox-design-001 中覆盖）。

轨迹评估的第一个挑战是：什么是'正确'的轨迹？ 对于同一个任务，Agent 可能通过多条不同路径达到目标。哪些路径是合理的？哪些是低效的？哪些是错误的？

Golden trajectories（黄金轨迹）是人工构建的参照轨迹，代表特定任务的最优或合理执行路径。 它们不是唯一正确答案，而是一个合理路径的集合。评估时，Agent 的实际轨迹与 golden trajectories 对比，计算相似度或偏差。

构建 golden trajectories 的标准流程包含四个步骤：

第一步：任务分解与关键步骤标注。 将一个复杂任务分解为若干关键步骤，标注每个步骤的预期输出和可接受的输出范围。例如，"在电商网站找到符合条件的商品并加入购物车"可以分解为：(1) 理解商品需求，(2) 构造搜索查询，(3) 筛选搜索结果，(4) 验证商品详情，(5) 点击加入购物车。每个步骤都有明确的输入和预期输出。

第二步：专家演示录制。 让人类专家执行任务，录制完整的执行轨迹。关键是录制思考过程而不仅仅是操作序列。专家在每一步的推理逻辑、为什么选择某个工具、为什么排除某个选项，这些信息比操作序列本身更有价值。

第三步：变体生成。 一个任务通常有多条合理路径。让多个专家独立执行同一任务，收集不同的执行轨迹。这些轨迹可能在工具选择、搜索策略、中间验证步骤上有所不同，但都达到了目标。这些变体构成了 golden trajectories 的集合。

第四步：质量标注与分级。 不是所有达到目标的轨迹都是等价的。有些轨迹可能步骤过多（效率低），有些可能跳过关键验证步骤（鲁棒性差），有些可能在错误恢复上表现不佳。对每条 golden trajectory 进行质量标注，区分"优秀"、"良好"、"可接受"三个等级。

AgentBoard 在构建过程中采用了类似的方法论。 他们为 101 个任务构建了 golden trajectories，每个任务包含 3-5 条变体轨迹。关键创新是引入了"过程奖励"（process reward）的概念：不仅看最终是否成功，还看每一步是否做出了合理决策。例如，在 WebArena 的购物任务中，即使最终找到了正确商品，但如果搜索过程中使用了大量无关关键词，过程奖励会降低。

Golden trajectories 的核心价值在于提供了可比较的基线。 没有 golden trajectories，你只能说"Agent A 成功了，Agent B 失败了"。有了 golden trajectories，你可以说"Agent A 的轨迹与 golden trajectory 的相似度是 0.85，Agent B 的相似度是 0.42，主要差异在第 3 步的工具选择"。这种细粒度对比是优化的前提。

实践陷阱：不要试图构建"完美"的 golden trajectories。追求完美会导致过度工程化，且无法覆盖真实场景的多样性。目标是构建"足够好"的参照系，能够区分明显错误和合理变体。

有了 golden trajectories，下一个问题是：如何自动化评估 Agent 的实际轨迹与 golden trajectories 的相似度？ 人工对比成本高、速度慢，无法支撑持续集成。LLM-as-judge 提供了一种可扩展的解决方案。

LLM-as-judge 的核心思想是：用一个大语言模型作为评估者，对另一个模型的输出进行评分。 在轨迹评估场景中，judge 模型接收 Agent 的实际轨迹和 golden trajectories，输出结构化的评分和反馈。

轨迹层面的 LLM-as-judge 与单点评估有三个关键差异：

第一，输入是序列而非单点。 Judge 模型需要理解整个执行序列，包括每一步的输入、输出、工具调用参数和中间推理。这要求 judge 模型具备长上下文理解能力，且能够识别序列中的因果关系。

第二，评分是多维度的。 单点评估通常只有一个分数（正确/错误）。轨迹评估需要多个维度：工具调用正确性、路径效率、错误恢复能力、中间推理质量、最终答案准确性。每个维度独立评分，形成多维评分卡。

第三，反馈是可操作的。 单点评估只能告诉你"失败了"。轨迹评估需要告诉你"在第 3 步，Agent 选择了错误的工具，应该使用 search_product 而不是 browse_category，因为任务描述中明确提到了具体商品名称"。这种细粒度反馈是优化的关键。

设计 LLM-as-judge 的 prompt 时，需要包含四个要素：

（1）角色定义。 明确告诉 judge 模型它的角色是"Agent 轨迹评估专家"，任务是评估执行轨迹的质量。

（2）评估标准。 清晰定义每个维度的评分标准。例如，工具调用正确性：5 分=所有工具调用参数正确且选择合理；4 分=工具选择正确但参数有轻微错误；3 分=工具选择有偏差但可接受；2 分=工具选择明显错误；1 分=工具调用完全错误。

（3）参考轨迹。 提供 golden trajectories 作为参考，但要明确告诉 judge：golden trajectories 不是唯一正确答案，Agent 可能通过其他合理路径达到目标。

（4）输出格式。 要求 judge 输出结构化 JSON，包含每个维度的分数、整体评分、关键差异点、改进建议。结构化输出便于后续自动化处理。

METR（Model Evaluation and Threat Research）在其任务评估框架中采用了类似的 LLM-as-judge 方法。 他们为每个任务定义了评估 rubric（评分细则），judge 模型根据 rubric 对轨迹进行评分。关键创新是引入了"锚点"（anchors）：在每个评分等级提供具体示例，帮助 judge 模型校准评分标准。例如，工具调用正确性的 3 分锚点是："Agent 在搜索任务中使用了 browse_category 而不是 search_product，虽然最终找到了商品，但路径效率较低"。

LLM-as-judge 的主要挑战是一致性。 同一个轨迹，不同次评估可能给出不同分数。解决方法包括：多次评估取平均、使用温度参数 0 降低随机性、在 prompt 中提供明确的锚点示例。下一节会详细讨论一致性校准方法。

LLM-as-judge 提供整体评分，但工程优化需要更细粒度的指标。 步级分解指标将轨迹评估拆解到每一步，量化每个环节的表現。

步级分解的核心是将轨迹表示为有向图，节点是状态，边是动作。 每个节点包含：状态描述、输入上下文、预期输出、实际输出。每条边包含：动作类型（工具调用、推理、验证）、动作参数、执行时间、成功/失败标记。

基于这个图结构，可以计算四类步级指标：

（1）工具调用正确性（Tool Call Accuracy）。 评估每一步的工具选择是否合理，参数是否正确。正确性分为三个层次：工具选择正确（选择了合适的工具）、参数正确（参数值符合预期）、格式正确（参数格式符合 API 要求）。三个层次独立评分，形成 3 维向量。

（2）路径效率（Path Efficiency）。 评估达到目标所需的步骤数与最优路径的步骤数之比。例如，golden trajectory 需要 5 步，Agent 实际用了 8 步，路径效率是 5/8 = 0.625。路径效率低通常意味着 Agent 在试错或走了弯路。

（3）错误恢复能力（Error Recovery）。 评估 Agent 在遇到错误后的恢复能力。当某一步失败时，Agent 是否能够识别错误、分析原因、采取纠正措施？错误恢复能力通过"错误后成功率"量化：在所有失败的步骤中，有多少比例在后续步骤中成功恢复。

（4）中间推理质量（Intermediate Reasoning Quality）。 评估每一步的推理逻辑是否合理。这需要通过 LLM-as-judge 或人工标注来评估。推理质量分为：逻辑连贯（推理链条完整）、证据充分（推理基于充分证据）、假设合理（隐含假设可接受）。

WebArena 的评估体系中包含了类似的步级指标。 他们为每个任务定义了"关键步骤"（critical steps），Agent 必须完成这些步骤才能认为任务成功。关键步骤的完成率是一个重要的过程指标。例如，在购物任务中，关键步骤可能包括：(1) 正确理解商品需求，(2) 使用合适的搜索策略，(3) 验证商品详情，(4) 正确加入购物车。即使最终成功率相同，关键步骤完成率的差异反映了系统质量的不同。

步级分解指标的价值在于支持精准优化。 当你发现工具调用正确性低时，你知道需要优化工具选择 prompt 或改进工具描述。当你发现路径效率低时，你知道需要优化规划策略或引入更好的启发式规则。当你发现错误恢复能力差时，你知道需要增强错误检测和恢复机制。单点指标无法提供这种精准指导。

工程实践：不要试图同时优化所有步级指标。根据业务场景选择 2-3 个最关键的指标作为优化目标。例如，对于客服 Agent，工具调用正确性和最终答案准确性最重要；对于数据分析 Agent，路径效率和中间推理质量最重要。

LLM-as-judge 和人工评估都面临一致性问题。 同一个轨迹，不同评估者（或同一评估者的不同次评估）可能给出不同分数。如果评分不一致，评估结果就不可信赖，无法支撑决策。

一致性校准的目标是让不同评估者对同一轨迹的评分尽可能接近。 这需要通过标准化流程、明确标准和定期校准来实现。

对于人工评估，一致性校准包含三个步骤：

（1）评估标准文档化。 将每个维度的评分标准写成详细文档，包含定义、评分等级、每个等级的示例。文档应该足够详细，让不同评估者能够独立得出相同结论。

（2）评估者培训。 让所有评估者学习评估标准文档，并通过练习任务熟悉评分流程。培训阶段使用已知答案的轨迹，评估者的评分与标准答案对比，发现偏差并纠正。

（3）定期校准会议。 每隔一段时间（例如每周），所有评估者共同评估同一批轨迹，讨论评分差异，统一理解。校准会议的目标不是消除所有差异（合理差异是允许的），而是确保差异在可接受范围内。

一致性通过 Cohen's Kappa 或 Fleiss' Kappa 量化。 Kappa 值范围是 -1 到 1，其中 1 表示完全一致，0 表示与随机一致，负值表示比随机还差。通常认为 Kappa > 0.6 是可接受的一致性，Kappa > 0.8 是良好的一致性。

对于 LLM-as-judge，一致性校准的方法有所不同：

（1）温度参数设为 0。 降低模型输出的随机性，使同一输入产生相同输出。

（2）多次评估取平均。 对同一轨迹评估 3-5 次，取平均分作为最终分数。这可以平滑掉随机波动。

（3）锚点示例。 在 prompt 中提供每个评分等级的具体示例，帮助模型校准评分标准。例如，"工具调用正确性 5 分的示例：Agent 在搜索任务中正确使用了 search_product 工具，参数包含准确的商品名称和类别"。

（4）与人工评估对齐。 定期将 LLM-as-judge 的评分与人工评估对比，计算一致性。如果一致性下降，需要调整 prompt 或重新训练 judge 模型。

AgentBench 在评估过程中发现了 LLM-as-judge 的一致性问题。 他们报告说，GPT-4 作为 judge 时，同一轨迹的不同次评估分数标准差约为 0.5（5 分制）。通过引入锚点示例和多次评估取平均，标准差降低到 0.2。这个改进对于支撑决策至关重要。

实践建议：不要完全依赖 LLM-as-judge。对于关键决策（例如是否发布新版本），使用人工评估作为最终仲裁。LLM-as-judge 适合日常监控和快速反馈，人工评估适合关键节点和争议情况。

轨迹评估不是免费的。 LLM-as-judge 消耗 tokens，人工评估消耗时间，构建 golden trajectories 消耗专家资源。评估的成本可能超过它带来的收益。

评估的经济性问题是：在给定预算下，如何最大化评估的价值？ 这需要在评估粒度、评估频率和评估质量之间做权衡。

评估粒度的权衡： 步级分解指标比整体评分更精细，但成本也更高。每一步都需要单独评估，tokens 消耗是整体评分的 N 倍（N 是步骤数）。解决方法是分层评估：先用整体评分快速筛选，对可疑轨迹再做步级分解。

评估频率的权衡： 每次 Agent 执行都评估可以提供最细粒度的监控，但成本最高。抽样评估可以降低成本，但可能错过重要问题。解决方法是基于风险的抽样：对高风险任务（例如涉及支付、数据修改）100% 评估，对低风险任务抽样评估。

评估质量的权衡： 使用 GPT-4 作为 judge 比使用 GPT-3.5 更准确，但成本也更高（约 10 倍）。人工评估比 LLM-as-judge 更可靠，但成本更高且速度慢。解决方法是混合评估：日常监控用低成本 judge（GPT-3.5 或小模型），关键决策用高质量 judge（GPT-4 或人工）。

构建 golden trajectories 的成本也不容忽视。 专家演示录制、变体生成、质量标注都需要大量时间。一个复杂任务的 golden trajectories 可能需要 10-20 小时的专家时间。降低成本的方法包括：

（1）复用已有轨迹。 如果多个任务有相似的结构，可以复用部分轨迹。例如，"搜索商品"和"搜索文档"的工具调用模式相似，可以复用工具选择部分的轨迹。

（2）半自动生成。 先用 LLM 生成候选轨迹，再由专家审核和修正。这可以将专家时间从 10-20 小时降低到 2-5 小时。

（3）渐进式构建。 不需要一次性为所有任务构建 golden trajectories。优先为高频任务和高价值任务构建，逐步扩展。

METR 在其评估框架中采用了分层评估策略。 他们对所有任务使用轻量级规则检查（例如，是否调用了正确的工具、是否在合理步骤数内完成），对可疑任务使用 LLM-as-judge 详细评估，对关键任务使用人工评估。这种分层策略将总成本降低了约 60%，同时保持了评估质量。

决策框架：评估预算分配遵循 80/20 原则。80% 的预算用于 20% 最关键的任务和维度。识别哪些任务和维度对业务影响最大，优先保障这些部分的评估质量。

轨迹评估的理论框架需要落地到具体的 Agent 框架中。 LangChain、AutoGPT、CrewAI 等主流框架都有各自的评估集成方式。

LangChain 的评估集成主要通过 LangSmith 实现。 LangSmith 提供了轨迹录制、可视化和评估功能。你可以配置 LangSmith 自动录制每次 Agent 执行的完整轨迹，包括每一步的输入、输出、工具调用和中间推理。录制完成后，可以使用 LangSmith 的内置评估功能，或导出轨迹到外部评估系统。

LangSmith 的评估功能支持自定义评估器（evaluator）。你可以编写 Python 函数实现 LLM-as-judge 或规则检查。评估器接收轨迹数据，返回评分和反馈。LangSmith 会自动聚合评估结果，生成报告。

AutoGPT 的评估相对简单，因为它的设计目标是通用任务自动化。 AutoGPT 的轨迹主要是命令序列和中间输出。评估时，可以将轨迹导出为 JSON 格式，使用外部评估系统处理。AutoGPT 社区开发了多个评估工具，例如 AutoGPT-Bench，专门用于基准测试和轨迹评估。

CrewAI 的评估需要关注多 Agent 协作的轨迹。 CrewAI 的核心概念是"crew"（团队），由多个 Agent 协作完成任务。轨迹评估不仅需要评估单个 Agent 的行为，还需要评估 Agent 之间的协作质量。例如，任务分配是否合理？信息传递是否准确？冲突解决是否有效？

CrewAI 提供了内置的日志系统，记录每个 Agent 的执行轨迹和交互信息。这些日志可以导出并用于评估。评估时，需要定义协作质量的指标，例如任务分配效率、信息传递准确率、冲突解决成功率。

无论使用哪个框架，轨迹评估的工程实现都包含五个核心组件：

（1）轨迹录制器（Trajectory Recorder）。 拦截 Agent 的每一步执行，记录输入、输出、工具调用、中间推理和时间戳。录制器应该是非侵入式的，不影响 Agent 的正常执行。

（2）轨迹存储（Trajectory Store）。 将录制的轨迹持久化存储，支持查询和检索。存储系统需要支持大规模数据（数百万条轨迹）和复杂查询（按任务类型、时间范围、成功率等过滤）。

（3）评估引擎（Evaluation Engine）。 实现 LLM-as-judge、规则检查和步级分解指标的计算。评估引擎应该是可扩展的，支持自定义评估器和指标。

（4）报告生成器（Report Generator）。 将评估结果聚合和可视化，生成可读的报告。报告应该包含整体指标、趋势分析、异常检测和可操作建议。

（5）回归测试集成（Regression Test Integration）。 将轨迹评估集成到 CI/CD 流水线中。每次 Agent 代码或 prompt 变更后，自动运行回归测试，对比新旧版本的轨迹质量。如果质量下降超过阈值，阻止发布。

AgentBench 和 WebArena 都提供了开源的评估框架，可以作为参考实现。 AgentBench 的评估框架支持多种 Agent 框架的集成，提供了标准化的评估接口。WebArena 的评估框架专注于 Web 任务，提供了详细的步级指标和可视化工具。

工程建议：不要从零开始构建轨迹评估系统。优先使用现有框架（LangSmith、AgentBench、WebArena）的评估功能，在其基础上扩展自定义评估器。这可以节省 2-3 个月的开发时间。

轨迹评估的最终目标不是打分，而是改进。 评估结果需要转化为可操作的优化措施，形成"评估-分析-优化-验证"的闭环。

评估结果的分析通常遵循以下流程：

（1）整体指标趋势分析。 观察整体成功率、平均路径效率、平均工具调用正确性等指标随时间的变化趋势。如果指标持续下降，说明系统质量在退化，需要排查原因。

（2）异常检测。 识别表现异常的任务或轨迹。例如，某个任务的成功率突然从 80% 下降到 50%，或某条轨迹的步骤数异常高。异常通常是问题的信号。

（3）失败模式聚类。 将所有失败轨迹按失败原因聚类。常见的失败模式包括：工具选择错误、参数格式错误、推理逻辑断裂、错误恢复失败、路径效率低。每种失败模式对应不同的优化方向。

（4）根因分析。 对每种失败模式，深入分析根本原因。例如，工具选择错误的根因可能是工具描述不清晰、prompt 中的工具选择指导不足、或 Agent 对工具能力的理解有偏差。

基于分析结果，可以采取以下优化措施：

（1）Prompt 优化。 如果失败原因是推理逻辑断裂或工具选择错误，优化 prompt 中的推理指导或工具选择策略。例如，在 prompt 中增加"在选择工具前，先分析任务需求，列出候选工具，评估每个工具的适用性"的指导。

（2）工具描述优化。 如果失败原因是工具选择错误，优化工具的描述，使其更清晰地表达工具的能力和适用场景。例如，将"search 工具"改为"search_product 工具：用于根据商品名称、类别或属性搜索商品，不适用于浏览商品类别"。

（3）错误恢复机制增强。 如果失败原因是错误恢复能力差，增强错误检测和恢复机制。例如，在每一步执行后增加验证步骤，检查输出是否符合预期；如果不符合，触发错误恢复流程。

（4）规划策略优化。 如果失败原因是路径效率低，优化规划策略。例如，引入更好的启发式规则，或在规划阶段增加路径评估步骤，选择预期效率最高的路径。

优化后，需要通过回归测试验证效果。 使用相同的测试集评估优化前后的轨迹质量，对比各项指标的变化。如果指标提升，说明优化有效；如果指标下降或没有变化，需要重新分析原因。

这个闭环的关键是持续性和自动化。 评估不是一次性任务，而是持续的过程。每次 Agent 代码或 prompt 变更后，都应该自动运行评估，监控指标变化。通过自动化，可以快速发现问题、快速验证优化效果，形成持续改进的循环。

长期视角：轨迹评估是一个长期投资。短期内，评估系统的构建成本可能超过它带来的收益。但长期来看，评估系统可以支撑持续改进，避免"改一个问题引入三个新问题"的困境，最终提升系统的整体质量和可靠性。

本文的工程建议基于以下一手材料——

• AgentBench: Evaluating LLMs as Agents (Liu et al., 2023)：首个系统性对比多个 LLM Agent 框架在 8 个不同环境中表现的基准测试，揭示了单点指标的局限性。论文：https://arxiv.org/abs/2308.03688
• WebArena: A Realistic Web Environment for Building Autonomous Agents (Zhou et al., 2023)：在真实网站环境中评估 Agent 多步执行能力，提供了步级评估方法论。论文：https://arxiv.org/abs/2307.13854
• AgentBoard (HKUST NLP)：为 101 个任务构建了 golden trajectories，引入过程奖励（process reward）概念。项目地址：https://github.com/hkust-nlp/AgentBoard
• METR (Model Evaluation and Threat Research)：提供任务评估框架和 LLM-as-judge 评分细则设计方法。官网：https://metr.org
• LangSmith Documentation：LangChain 的轨迹录制、可视化和评估功能文档。文档地址：https://docs.smith.langchain.com
• A Survey on Evaluation of Large Language Models (Chang et al., 2023)：LLM 评估方法的综合综述，覆盖轨迹评估在整体评估体系中的定位。论文：https://arxiv.org/abs/2307.03109
• SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (Jimenez et al., 2023)：基于真实 GitHub issue 的 Agent 评估基准，强调过程级分析。论文：https://arxiv.org/abs/2310.06770

精度数据和成本数据来自 2025-2026 年多个生产环境的实测结果，已做脱敏处理。