LiteTrajEval：用一次评判、固定预算给生产轨迹定位失败

轻量、量表引导的轨迹评测：给生产环境里的 AI Agent 用

Linh-An Phan、MingXue Wang、Guangyu Wu（华为爱尔兰研究中心）、Feng Pan、Zhaoyu Pang、Yanbin Zhang（华为深圳研发中心）。许可证：CC BY 4.0。arXiv:2610.03315v1，2026 年 10 月 2 日。

轨迹评测对提高基于大语言模型（LLM，按提示生成文字并调用工具的模型）的智能体可靠性很重要，但生产环境里反复跑很贵。现代智能体会生成很长的轨迹（trajectory，一次任务里按时间排好的推理、工具调用、观察和重试记录）。轨迹里有工具调用、观察、重试和外部输出，并不是每一段原始 token（模型按块计费的文本单位）对诊断都同样有用。本文提出 LiteTrajEval，一种预算有界的轻量轨迹评测架构。它先离线抽出紧凑的、分领域的规则画像，再在线预处理每条轨迹，标出启发式失败信号，在固定的全局预算内把轨迹序列化，然后只调用一次由量表（rubric，事先写好的评分条目）引导的 LLM 评判器，产出结构化诊断报告。在公开的 Magentic-One 风格轨迹和 τ-bench 风格轨迹上，相对 AgentRx，LiteTrajEval 与人工标注的失败定位对齐，在 Magentic-One 上大约提高 20–35 个百分点，在 τ-retail 上最多提高 23 个百分点，同时成本大约降到 1/6，评测时间缩短到 1/8 以下。该方案已部署在作者的企业智能体平台上。

I 引言

基于 LLM 的智能体越来越多地做复杂流程：规划、用工具、检索、执行代码、更新状态、多步决策。对这类系统，最终答案只是可靠性的一部分。答对了，仍可能藏着不安全的工具使用、违反策略、不必要的重试，或中间推理没有落到证据上。答错了，原因可能是早先读错观察、一次工具调用失败、缺证据，或前一个错误之后没有恢复好。因此执行轨迹成为理解智能体行为、提高可靠性的中心产物。

和传统软件日志不同，智能体轨迹里的报错信息常常不是真正根因。智能体可能靠重试或换一条工具路径恢复；早期推理错误可能要到后面的工具失败才露出来。只靠规则做诊断不够。在生产智能体系统里，轨迹持续堆积，评测要在提示版本、模型升级和回归套件（regression suite，用来确认以前能过的题现在还过）上反复跑。一次性的基准分析碰不到的成本和延迟，在这里变成硬约束。

近期工作已从只评最终答案，转到过程级和轨迹级评测。τ-bench [1]（评测智能体在真实领域里与用户、工具多轮交互时是否遵守策略）表明，智能体可能不遵守领域策略，也不能在多轮交互中正确更新外部状态。AgentBoard [2] 和 T-Eval [3] 用进度、落地和步骤级技能信号来评，而不是只看一个成功指标。更直接地，TRACE [6]、AgentRewardBench [7]、Agent-as-a-Judge [8]（用智能体评智能体）、AgentDiagnose [9] 和 AgentRx [11] 表明，分析完整解题过程能露出最终答案打分看不见的失败模式。但这些方法把轨迹质量单独处理，没有计入反复做生产评测时的成本和延迟。

实际中，评测要跨提示版本、工具实现、模型升级和失败分析批次来跑，成本和 token 用量需要可预期。长时间运行的智能体可能产生很多推理步、工具调用、观察、重试、日志、堆栈和很大的外部输出。把整段原始轨迹喂给评判器既浪费，也会受长上下文里注意力变差的影响 [10]；切得太狠又会打断诊断需要的因果链。重复的工具循环、重复观察和冗长日志可能吃掉大部分 token 预算，诊断信号却很少。核心问题因此是：一次调用、预算固定的评测器，能不能留下足够的执行过程，来可靠地定位失败。

表 I：轨迹评测方法里的 LLM 调用模式。

多次调用的方法先评单个步骤，再判断整条轨迹的质量；LiteTrajEval 每条轨迹只调用一次评判器。

不少近期系统用多调用的 LLM 流水线：先评单个步骤或片段，再汇总成轨迹级判断，见表 I。这可以有效，但成本和延迟上升，很难挂到生产回归流程上——那里可能要评成千上万条轨迹。

本文提出 LiteTrajEval，一种预算有界的轻量轨迹评测架构。它把可复用的离线领域画像，和在线的逐条轨迹诊断分开。评测时，LiteTrajEval 把异构轨迹归一化，用启发式规则标出面向失败的信号，删掉或压紧低价值的重复内容，保留全局执行骨架，并在固定全局预算下把轨迹序列化。一次由量表引导的 LLM 评判，产出结构化诊断报告：候选失败步骤、根因说明、失败类别、关键观察和量表分数。

本文有两项主要贡献：

固定预算、单次调用的生产轨迹评测架构。提出 LiteTrajEval，一条离线–在线流水线：保留轨迹的整体视图，限制每条轨迹送进评判器的输入，用一次量表引导的 LLM 调用产出结构化诊断。它表明：确定性预处理、按状态压缩，以及按预算序列化，可以让单次调用的轨迹评测成立，而不必做多阶段诊断流水线。

相对强失败诊断基线的实证比较。在 Magentic-One 风格轨迹和 τ-retail 轨迹上，相对 AgentRx，LiteTrajEval 与人工标注的组级失败定位对齐，在 Magentic-One 上大约提高 20–35 个百分点，在 τ-retail 上最多提高 23 个百分点；同一评判模型下总评测成本大约降到 1/6，改用 DeepSeek-v4-flash 时大约降到 1/22，完整评测时间缩短到 1/8 以下。

LiteTrajEval 不打算取代针对具体任务的成功指标、基于约束的检查或人工复核。它处在“只评最终答案”和“重型多调用根因分析”之间，是可部署的中间层，并已接入作者生产智能体平台的评测支架（harness，包在模型外面、负责跑任务、收轨迹、打分的程序）。

图 1：LiteTrajEval 流水线总览。虚线是离线步骤，从积累的轨迹输出生成分领域规则画像。在线路径处理异构的智能体执行日志，在固定预算下序列化轨迹，再用量表引导的 LLM 评判器评测。

II 系统设计

LiteTrajEval 是生产智能体工作流上的一层轻量轨迹评测。它把离线规则画像（每个领域跑一次）和在线逐条评测分开。离线路径从积累的轨迹生成分领域规则画像；在线路径应用这些规则，在固定预算下序列化每条轨迹，并调用一次量表引导的 LLM 评判器。这样 LLM 只用于语义上的规则发现，不会给在线预处理增加 LLM 调用。

II-A 离线规则生成

规则生成看的是步骤输出，不是完整轨迹。LiteTrajEval 用积累的轨迹数据，离线产出紧凑的、分领域的规则画像，再在在线预处理时确定性地应用这些规则。离线过程有四步：

输出抽取：从每条收集到的轨迹步骤里抽出 output 字段。状态规则要发现的是可疑输出模式，而不是对整条轨迹做推理。

文本规范化：把常见的易变记号归一，例如 URL、UUID、时间戳、文件路径、十六进制串、请求标识和长数字，使反复出现的运行模式更容易被发现。

代表样本选择：用归一化后的 token 集合上的 Jaccard 相似度（两个集合交集大小除以并集大小）做近重复检测。若某条输出超过阈值（例如 0.7），就归入该代表，只更新其支持计数。

规则合成：把代表组按 token 预算切块，连同当前规则画像一起交给 LLM，由它提出或修订结构化规则。每个领域这次离线过程通常只需要少数几次 LLM 调用；除非步骤输出的分布变了，规则保持稳定，开发者也可以审阅或更新。

每条生成的规则包含：规则标识、优先级、作用范围、匹配模式、可选的排除模式、赋予的状态，以及候选分类标签。规则只赋予 warning 或 error；没有规则命中的输出默认为 ok。因此离线的 LLM 调用提供分领域的语义规则发现，在线路径仍是确定且高效的。

II-B 轨迹预处理

拿到一条新轨迹后，LiteTrajEval 先把异构执行日志转成最小的归一化模式。不同智能体运行时暴露推理步骤、工具调用、观察、重试、错误和最终回复的方式不一样。归一化模式只保留评测需要的信息：原始任务、最终输出，以及按顺序排列的步骤。每一步包含 step_id、type、status、input 和 output。status 由集中的规则画像推断。规则从步骤输出检测 warning 和 error；未命中的步骤默认为 ok。这样在线推断保持简单，同时保留分领域的失败信号。

状态推断之后，LiteTrajEval 抽出轻量的、面向失败的提示。它把 warning 和 error 步骤选为锚点，按邻近步骤顺序、相同的工具或动作类型、重复的输入，或相似的输入／输出指纹，扩展成小的局部区域，并附上命中规则给出的候选分类标签。这些提示是弱引导，不是最终决定：它们帮助评判器在长轨迹里注意可疑区域，也让跨轨迹汇总更容易。

预处理的输出是一条归一化轨迹，加上一份紧凑的引导产物，里面有候选失败区域、命中的规则标识和候选分类标签。这一阶段为按预算序列化和单次调用评判提供稳定结构。

II-C 证据感知的预算序列化

预处理之后，轨迹仍可能长到不能直接送给 LLM 评判器。原始输出里可以有冗长的网页观察、大块 JSON、堆栈、重复的工具回复，或重复的编排消息。LiteTrajEval 把轨迹序列化写成一个约束优化问题。目标是在固定的全局字符预算 \(B\) 下，得到有界表示，同时保留任务定义、步骤顺序和与失败相关的证据。在线序列化器完全确定。

给定归一化轨迹 \(T\)，最终渲染前做三步确定性精炼。

局部工具结果压缩。先降低工具结果在局部的啰嗦程度。轨迹里很多工具调用的输出是结构化或半结构化的，例如 JSON、表格、日志、堆栈、命令行输出和搜索结果。LiteTrajEval 不把这些输出当纯文本，可以复用已有的、基于规则或感知格式的压缩方法，得到更短但仍可读的表示。例如类 JSON 的输出可以渲染成更省 token 的格式，如 TOON [12]（Token-Oriented Object Notation，面向 token 的对象记号，用来比 JSON 更短地写下结构化数据）。

跨步骤去冗余。序列化器再去掉步骤之间的重复信息。按时间扫描轨迹，把每一步压缩后的输出和前面的步骤比较。若某段输出与前面完全相同，或含有几乎逐字重复的文本（例如抄来的代码、重复的数据记录），就把这段换成紧凑的引用标记。因为步骤骨架（input、type、status）还在，去重保留了执行图，去掉的是重复证据。

按档分配和步内选择。去冗余之后，剩下的每一步 \(i\) 有压缩后输出长度 \(\ell_i\)。LiteTrajEval 按该步推断出的状态档，给出最低保留下限。状态档 \(\tau_i\in\{0:\texttt{ok},1:\texttt{warning},2:\texttt{error}\}\)：

\[ m_i=\min(\ell_i, M_{\tau_i}),\qquad M_0<M_1<M_2. \tag{1} \]

这里 \(M_{\tau_i}\) 是配置好的最低保留预算。序列化器再为每一步分配最终输出预算 \(c_i\)，约束为：

\[ m_i\le c_i\le \ell_i,\qquad \sum_i c_i\le B_{\text{out}}, \tag{2} \]

其中 \(B_{\text{out}}\) 是为任务和最终答案留出空间之后，剩下的全局预算。分配由算法 1 的瀑布式削减求解。先把每一步初始化成完整压缩长度，并带上按档的保留下限；然后按优先级从低到高处理各档，反复把当前档里仍最长的输出，缩到下一长度水平或下限（第 3–10 行）。只有全局预算仍然被违反时，才做最后的硬截断。

对分到的预算 \(c_i\)，步内缩短被写成证据选择问题。按最大边际相关（MMR [13]，在“和当前问题相关”与“和已选内容不重复”之间折中）原则，LiteTrajEval 用任务和该步输入构造选择锚点 \(a_i\)，迭代选择证据单元 \(u\)，提高与锚点的相关，同时惩罚与已选集合 \(S_i\) 的重复：

\[ u^{*}=\arg\max_{u\in U_i\setminus S_i}\left[\lambda\cdot\mathrm{sim}(u,a_i)-(1-\lambda)\cdot\max_{v\in S_i}\mathrm{sim}(u,v)\right] \tag{3} \]

算法 1：按档的瀑布式预算分配

输入：归一化步骤 S，全局预算 B
输出：序列化轨迹 T
1: 构造 r_i=(h_i, o~_i, τ_i, a_i)；对所有 i，令 ℓ_i=|o~_i|，c_i=ℓ_i，m_i=min(ℓ_i, M_{τ_i})。
2: 令 R(c)=Render({h_i, Select(o~_i, c_i, a_i)}_i)，T ← R(c)。
3: for t ∈ {0,1,2} do
4:   while |T|>B 且存在 i 使得 τ_i=t 且 c_i>m_i do
5:     C ← {i : τ_i=t 且 c_i>m_i}
6:     L ← max_{i∈C} c_i，G ← {i∈C : c_i=L}
7:     L' ← max({c_i : i∈C, c_i<L} ∪ {0})
8:     对每个 i∈G，把 c_i 均匀减向 max(m_i, L')。
9:     T ← R(c)
10:  end while
11: end for
12: 若 |T|≤B 则返回 T，否则返回 HardTruncate(T, B)

II-D 量表引导的 LLM 评判

最后一阶段调用一次由量表引导的 LLM 评判器（LLM-as-a-Judge，用另一个语言模型按量表打分，而不是再写一套规则引擎）。LiteTrajEval 不分别为打分、失败定位、分类和根因分析各调用一次，而是收成一份结构化报告：所有输出都以同一份序列化轨迹为条件，一次调用既够用，也更省。

评判器同时看最终输出质量和轨迹质量。量表覆盖：目标推进与完成、证据落地与核验、执行与工具处理、恢复与自适应控制。输出是一份结构化 JSON 报告，含量表分数、候选失败步骤、失败类别、根因分析和关键观察。对单条轨迹，失败步骤和根因分析帮助开发者查看相关执行区域。对许多轨迹，失败类别和量表分数可以汇总，用来找出反复出现的失败模式、比较智能体版本，并支持回归测试。

III 评测

评测沿三个实际问题展开。第一，轻量评测器能否发现一条失败轨迹里有问题？第二，一旦发现失败，预测的失败区域是否与人工标注对齐，和更重的诊断基线比如何？第三，在固定轨迹预算下，LiteTrajEval 能否让 token 用量、运行时间和评测成本可预期？

表 II：失败检出率，以及在已检出样本上的组级对齐。

Magentic-One 为 44 个样本、78 个失败组；τ-retail 为 29 个样本、31 个失败组。

表 III：轨迹长度、每样本评测器 token 用量、总评测成本和运行时间。

成本是按 2026 年 6 月官方 API 价格，对全部样本估计的总费用。

III-A 数据集、基线与指标

评测用 AgentRx 基准派生的两套公开失败轨迹：Magentic-One 风格轨迹（44 个样本，78 个归一化失败组）和 τ-retail 轨迹（29 个样本，31 个归一化失败组）。后者是智能体、用户和外部工具之间受策略约束的交互。

基线是 AgentRx [11]。选它是因为它同样做失败定位，并提供人工失败标注。AgentRx 以尽量省成本的配置运行；即便如此，每个样本仍要多次 LLM 调用。LiteTrajEval 在预处理和按预算序列化之后，只调用一次评判器。另外包含一个“无 LLM，仅状态”变体，只用基于规则的步骤状态信号。

报告两个指标。检出率（Detection Rate）是失败样本中，评测器至少报告一个候选失败步骤的比例，对 LiteTrajEval 即 failure_steps 字段非空。因为全部样本都是失败轨迹，这个指标度量的是失败召回。

对齐｜检出 @k（Align.|Det.@k）度量已检出样本上、与人工标注的组级一致。因为一个因果失败可能跨相邻步骤，把人工标注归一成失败组 \(G=\{g_1,\ldots,g_m\}\)。预测步骤 \(p\) 在容差 \(k\) 下匹配 \(G\)，当 \(\min_{g\in G}|p-g|\le k\)。报告 \(k=1\) 和 \(k=3\)：

\[ \text{Align.|Det.@k}=\frac{N_{\text{容差 }k\text{ 下匹配到的失败组}}}{N_{\text{已检出样本中的失败组}}} \tag{4} \]

用对齐而不是准确率，是因为人工标注是参考区域，不是唯一标准答案；落在容差窗外的预测，仍可能指出有用的相关症状或后果。同时报告评测器 token 用量、估计成本和运行时间：AgentRx 把流水线里全部 LLM 调用加总；LiteTrajEval 对应固定 50,000 字符轨迹预算下的那一次评判调用。

图 2：一个 τ-retail 失败案例上的定性比较。AgentRx 定位到一处与人工标注不符的、无关的策略违反；LiteTrajEval 指出订单级取消错误及其下游影响。原文 HTML 只有该图的说明，没有可单独保存的图像文件。

III-B RQ1：轻量评判器能否发现并定位失败轨迹？

表 II 表明，只靠基于规则的状态信号——这已经是离线规则生成阶段所能达到的最高检出——不足以可靠地评轨迹。图 2 就是这样一个例子：失败并不表现为局部 error 状态，而要结合用户约束、工具语义和下游取消结果来推理。这和智能体执行一致：局部报错不总是根因，因为智能体可能靠重试或换路径恢复，早期推理错误可能要到后面才变成可见的失败。无 LLM、仅状态的变体，检出的失败轨迹明显少于任何带 LLM 的配置（Magentic-One 上 56.8%，τ-retail 上 31.0%），于是许多失败轨迹不会被送去诊断。它在已检出样本上的对齐并非可忽略，尤其是 @1，但检出覆盖低才是主要限制。

带 LLM 的 LiteTrajEval 在两个数据集上都明显提高检出覆盖，并且在已检出样本上的组级对齐也强于纯规则变体。这个差距说明，评判器用到的信息不只是规则推断的步骤状态，还包括模型推理、恢复行为、失败传播，以及后面看得见的错误是不是更早错误的症状。和 AgentRx 比，检出情况因评判模型而不同。GPT-5-mini、Gemini-3-flash 和 DeepSeek-v4-flash 在两个数据集上的检出率与 AgentRx 相当或更高。DeepSeek-v3.2 在不开启推理模式时，τ-retail 上的检出率更低（72.4%，AgentRx 为 86.2%），说明在受策略约束、交互很重的轨迹上，检出覆盖受益于具备推理能力的评判器。

尽管检出有高有低，一旦失败被检出，LiteTrajEval 与人工标注的条件对齐始终、并且明显更好。所有报告的评判模型上，对齐｜检出 @3 都比 AgentRx 大约高出 20–35 个百分点，两个数据集都是如此。也就是说，失败轨迹一旦被找出来，LiteTrajEval 更常指向与人工参考标注一致的失败区域，同时保持轻量的、单次调用的在线评测路径。

τ-retail 上较低的检出覆盖，也和该数据集里一部分失败的性质有关。若干未检出案例涉及用户侧行为，例如用户信息不正确或缺少确认，而不是明显的工具执行错误或智能体推理错误。当前评判提示主要关注工具执行、模型推理和智能体反应，这类交互状态上的失败更难识别，是以后细化提示的自然方向。

III-C RQ2：LiteTrajEval 能否把评测保持在轻量范围？

表 III 报告原始轨迹长度、每样本评测器 token 用量和总评测成本。对 AgentRx，先把一个样本所需的全部 LLM 调用的 token 加总，再在样本上计算最小、最大和平均。对 LiteTrajEval，每个样本一次在线评判调用，报告的 token 就是这一次调用。成本列是跑完整评测集的估计总费用，包括全部 44 个 Magentic-One 样本和 29 个 τ-retail 样本。

成本比较看出轻量设计的效果。同一 GPT-5-mini 评判模型下，LiteTrajEval 把总评测成本从 2.4628 美元降到 0.4155 美元，大约是 1/6。改用 DeepSeek-v4-flash 时，总成本进一步降到 0.1087 美元，大约是 AgentRx 配 GPT-5-mini 的 1/22.7。这个成本下降没有以定位质量为代价：DeepSeek-v4-flash 在两个数据集上、已检出样本的组级对齐仍然强（@3 为 73.1% 和 77.8%），明显高于 AgentRx（45.4% 和 59.2%），尽管它在 τ-retail 上的检出率略低于 AgentRx。在全部配置里，GPT-5-mini 在 τ-retail 上给出检出和对齐的最强组合。

LiteTrajEval 也更快、更稳：总评测时间从 15,990 秒降到 1,840 秒（8.7 倍），每样本运行时间收在 12–63 秒，AgentRx 则是 48–914 秒，见表 III。这种稳定来自固定预算、单次调用的设计。

IV 生产部署中的经验

LiteTrajEval 已接入作者企业智能体平台的评测支架。第一期试点针对一个内部 SRE（Site Reliability Engineering，站点可靠性工程）智能体，它在大规模云平台上对事故做自动根因分析（RCA，root-cause analysis），每天执行数百条 ReAct 风格轨迹（ReAct，推理和行动交替的循环），每条有几十步。轻量设计使这个量级的评测可以做：全天流量可以评，提示或配置改了之后也可以再评，并且落在日常成本和延迟预算内。工具输出高度偏斜：少数诊断调用（例如查日志）返回非常大的载荷，其他步骤很短。实践中，压缩输出最大的那些步骤，就占了序列化轨迹长度下降的大部分，印证了序列化策略的设计。这种压缩仍是结构上的，不是语义上的；因此，只对这些离群步骤做基于 LLM 的摘要、同时不为每一步增加一次 LLM 调用，是自然的延伸。

评判方面，小型开源权重、自托管模型（例如 DeepSeek-v4-flash、Qwen3.5-35B）就足以落在生产延迟和成本预算内，不需要前沿模型。初步人工查看中，找出来的失败步骤说得通，并且在不同评判模型之间大体稳定。生产流量没有步骤级的真值标签，因此这里只作为定性观察；轻量的人在环标注，以及跨评判模型的校准评估，仍在进行。

最后，评判器与预处理、序列化是松耦合的。正在做的技能自动优化和智能体记忆实验，复用同一条流水线，只换量表和输出模式。这说明轻量轨迹评测可以成为更广的智能体改进流程的可复用构件，而不只用于失败诊断。

V 结论

本文给出 LiteTrajEval，一种对生产 LLM 智能体做预算有界轨迹评测的轻量架构。它把离线规则画像、确定性轨迹预处理、固定预算序列化和一次量表引导的 LLM 评判调用组合在一起。在公开的 Magentic-One 风格轨迹和 τ-retail 轨迹上，相对强的多调用诊断基线，LiteTrajEval 提高了与人工标注的失败定位对齐，并降低了评测成本和运行时间。通过保留全局执行骨架、去掉低价值的重复内容，LiteTrajEval 使反复的智能体调试、回归测试和离线失败分析，可以落在可预期的评测预算里。

参考文献

• [1] S. Yao, N. Shinn, P. Razavi, and K. R. Narasimhan, “τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains,” in Proc. International Conference on Learning Representations (ICLR), 2025.
• [2] C. Ma et al., “AgentBoard: An Analytical Evaluation Board of Multi-turn LLM Agents,” in Advances in Neural Information Processing Systems 37 (NeurIPS 2024), Datasets and Benchmarks Track, 2024.
• [3] Z. Chen et al., “T-Eval: Evaluating the Tool Utilization Capability of Large Language Models Step by Step,” in Proc. 62nd Annual Meeting of the Association for Computational Linguistics (ACL), Volume 1: Long Papers, Bangkok, Thailand, 2024, pp. 9510–9529.
• [4] N. Madvil et al., “Holistic Evaluation and Failure Diagnosis of AI Agents,” arXiv preprint arXiv:2605.14865, 2026.
• [5] D. Guo, J. Wu, and S. M. Yiu, “AgentEval: DAG-Structured Step-Level Evaluation for Agentic Workflows with Error Propagation Tracking,” arXiv preprint arXiv:2604.23581, 2026.
• [6] W. Kim et al., “Beyond the Final Answer: Evaluating the Reasoning Trajectories of Tool-Augmented Agents,” arXiv preprint:2510.02837.
• [7] X. H. Lù et al., “AgentRewardBench: Evaluating Automatic Evaluations of Web Agent Trajectories,” arXiv preprint arXiv:2504.08942.
• [8] M. Zhuge et al., “Agent-as-a-Judge: Evaluate Agents with Agents,” in Proc. 42nd International Conference on Machine Learning (ICML), PMLR, vol. 267, 2025, pp. 80569–80611.
• [9] T. Ou, W. Guo, A. Gandhi, G. Neubig, and X. Yue, “AgentDiagnose: An Open Toolkit for Diagnosing LLM Agent Trajectories,” in Proc. 2025 Conference on Empirical Methods in Natural Language Processing: System Demonstrations, Suzhou, China, 2025, pp. 207–215.
• [10] N. F. Liu et al., “Lost in the Middle: How Language Models Use Long Contexts,” arXiv preprint:2307.03172, 2023.
• [11] S. Barke, A. Goyal, A. Khare, A. Singh, S. Nath, and C. Bansal, “AgentRx: Diagnosing AI Agent Failures from Execution Trajectories,” arXiv preprint:2602.02475, 2026.
• [12] I. Matveev, “Token-Oriented Object Notation vs JSON: A Benchmark of Plain and Constrained Decoding Generation,” arXiv preprint:2603.03306, 2026.
• [13] J. Carbonell and J. Goldstein, “The Use of MMR, Diversity-Based Reranking for Reordering Documents and Producing Summaries,” in Proceedings of the 21st Annual International ACM SIGIR Conference on Research and Development in Information Retrieval, 1998.

出处：Linh-An Phan, MingXue Wang, Guangyu Wu, Feng Pan, Zhaoyu Pang, Yanbin Zhang，Lightweight, Rubric-Guided Trajectory Evaluation for Production AI Agents，2026-10-02，https://arxiv.org/abs/2610.03315，CC BY 4.0。