论文题为 Evaluation and Benchmarking of LLM Agents: A Survey，作者为 Mahmoud Mohammadi、Yipeng Li、Jane Lo 和 Wendy Yip，来自 SAP Labs，发表于 KDD 2025。

它是一篇综述，没有提出一个新智能体，也没有在统一实验条件下重新跑遍所有模型。它的主要贡献，是整理评测目标、指标、实施方式和应用环境，并讨论企业部署中的缺口。

读这类论文，适合带着一个具体问题：当前的评测到底覆盖了系统的哪些方面，又遗漏了什么？不宜把文中列出的所有基准当成可以直接横向比较的排行榜。

论文把评测目标归为四类。理解它们的关键，是注意每一类分数所支持的判断范围。

这不是四个互不相交的盒子。例如，Progress Rate 既可以描述任务的部分完成情况，也可以帮助分析规划能力。论文的表格中也存在这种交叉。

因此，这套分类更适合用作检查评测覆盖面的框架，而不是把所有指标各放进一个唯一类别的严格规则。

任务完成通常是最直观的指标。软件智能体是否修复了问题，网页智能体是否完成了操作，科研智能体是否复现了指定结果，都可以落到某种完成条件上。

论文列举了 SWE-bench、WebArena、AppWorld、CORE-Bench 等不同任务环境。这些名字背后并不是同一种成功定义：有的依赖测试，有的检查环境状态，有的对照任务要求。

成功率可信与否，首先取决于成功条件是否定义得准确。 智能体在回复中声称已完成，并不等于外部环境真的达到了目标状态。

下面用一个自拟例子说明。假设任务是查找符合条件的订单、核对信息，并修改配送地址。两条轨迹最终都没有完成修改：一条连订单都没找到；另一条已经找到正确订单，只在最后一次接口调用中使用了错误字段。

若只记成失败，两者的区别就消失了。但它们暴露的能力问题不同，后续改进方向也不同。这正是细粒度过程评测的价值：在相同的终局标签内部，继续区分具体表现。

同时，部分进展也不能自动兑换成业务成功。地址没有修改，任务就没有完成。过程分数应当补充终局结果，而不是模糊它。

结果是否正确，与回复是否清楚，是两个问题。智能体可能完成了操作，却没有向用户解释关键状态；也可能生成了一段流畅的回答，却没有执行任何有效动作。

论文把输出质量单列出来，涉及准确性、连贯性、可用性以及用户满意度等方面。对于检索增强任务，还需要考虑回答是否与检索到的事实一致。

延迟也有不同口径。首个 token 的等待时间，与整件任务完成的时间并不相同。 一个助手可以很快输出正在处理，但后台工具调用依然持续很久。

成本同样需要明确范围。输入输出 token 可以反映一部分模型调用开销，但实际系统还可能涉及工具服务、重试和运行时间。只报告 token，不能代表已经覆盖所有成本。

比较两个系统时，至少应保持任务、成功条件和预算口径一致。否则，一个系统多尝试数倍次数才完成任务，另一个系统只允许一次运行，表面上的成功率差距就很难解释。

论文把工具使用拆出了几个判断环节：是否需要调用工具、选了哪个工具、是否从候选库中检索到合适工具，以及参数是否正确。

这有助于避免把所有错误都归为不会用工具。

例如，调用结构完全合法，却把另一位用户的订单编号传了进去，语法检查仍可能通过。这说明结构正确只是一个证据层次。

论文也区分了单次工具调用与复杂工具序列：前者主要对应工具使用，后者还涉及规划。一个智能体可以每次都生成合法调用，却把依赖顺序安排错了。

所以，评价时需要说明分数来自哪一层。工具选择准确率、调用执行成功率和最终任务成功率，不能直接当成同义词。

规划不只是输出一段计划，还包括根据环境反馈选择下一步、调整顺序和处理依赖关系。

综述提到的静态评测方法，包括比较计划中的节点、依赖边及序列距离；动态评测则更关注智能体在交互中的实际行为。AgentBoard 的 Progress Rate 也出现在这部分讨论中。

这里有一个需要区分的层次：一次动作执行成功，不一定代表任务获得了有效进展。 连续查询同一信息，可能每次都得到正常返回，却没有接近最终目标。

反过来，实际采用的动作顺序与参考轨迹不完全一致，也未必意味着规划错误。只要任务允许多条有效路径，单一参考序列就可能限制评价。这个判断是对评测设计的分析，不能当成综述已经用实验量化的结论。

读过程指标时，应继续追问：它在奖励合法动作、参考路径匹配，还是与任务目标相关的状态变化？名称里都有 progress 或 quality，测量对象也可能不同。

记忆评测关注长对话事实、历史交互和中间状态是否被保留，以及后续能否正确使用这些信息。

能复述用户曾经给出的地址，不等于能在用户更新地址后使用最新值。保留全部上下文，也不等于系统能够区分有效信息、过期信息与当前任务无关的信息。

因此，事实回忆、跨轮一致性与任务中的实际运用，应当区分观察。把上下文窗口长度直接当成记忆能力，会跳过这些问题。

对于多智能体系统，综述强调信息共享、角色调整和协作表现。多个智能体分别得到不错的局部评价，也不意味着系统一定协作良好：重要信息可能没有传递，职责可能重复，某个角色的输出可能没有被下游正确使用。

这部分在综述中提供了分类入口，但篇幅较短。它没有给出一套完整的多智能体失败归因方法。

可靠性部分有一个特别值得记住的区别。

pass@k 关注 k 次尝试中至少成功一次；pass^k 关注 k 次尝试全部成功。 前者更接近多次尝试下能否找到成功结果，后者强调重复运行的一致成功表现。

为了直观看出差异，做一个纯数学示例。假设同一任务每次独立运行，成功概率恒定为 80%，尝试 5 次：

示例假设：独立重复、固定成功概率 p = 0.8，k = 5至少一次成功：1 − (1 − p)^k = 99.968%五次全部成功：p^k           = 32.768%

这不是论文的实验结果，也不是对实际 benchmark 有限样本估计公式的替代。真实任务的难度不同，运行之间也可能相关，不能把整体平均成功率直接代入，就当成实测的 pass^k。

但这个例子说明：同一个系统，可以在多次尝试中很容易出现成功结果，同时很难保证连续运行都成功。

若使用场景要求每次请求都可靠完成，只看至少成功一次会高估可用性。若系统允许重试，还应计入重试成本，并明确怎样识别成功结果。

一致性主要观察相同条件下重复运行的表现。鲁棒性则观察输入或环境变化后，性能是否保持、错误能否得到合理处理。

例如，同一个任务重复运行十次，与给它加入一次工具超时，是两类测试。前者检查重复表现，后者检查面对扰动时的反应。

工具返回空结果后，智能体是盲目编造、无休止重试，还是确认状态并报告无法完成，这些行为仅从最终文本的流畅程度看不出来。

报告可靠性时，运行次数、模型版本、环境配置和扰动方式都影响解释。一次成功演示不能证明可靠；有限样本上的高成功率，也不等于形式化的可靠性保证。

综述将公平性、有害行为、合规和隐私纳入评测目标。对于能操作外部系统的智能体，这些约束涉及实际动作，不只是回答中有没有不当内容。

论文尤其强调企业环境中的基于角色的访问控制，也就是 RBAC。同样一句查询请求，不同角色的用户可能拥有不同权限，因此合理结果可能不同。

用一个自拟例子说明：某用户请求读取一份受限记录。系统技术上能读取，不代表该用户被允许读取。如果评测只奖励找到记录，就可能把越权访问记为成功。

因此，任务目标需要与允许执行的动作一起定义。权限不足时的正确拒绝或转交处理，可能比直接完成请求更符合任务要求。

这也意味着，不能简单用更高完成率抵消违反约束的行为。哪些条件属于必须满足的边界，应在评测之前确定。

综述的另一半讨论评测过程，包括交互方式、数据、分数计算、工具平台和运行环境。

同样叫成功率，一份来自固定对话记录中的人工判断，另一份来自可交互环境中的状态检查，两者的证据条件并不相同。

这里还有一个术语边界。论文将静态与离线、动态与在线并列讨论，但实际设计时应进一步区分：可交互评测也可以在部署前的离线沙箱中运行。 动态交互不必等到生产上线之后才发生。

静态数据便于固定输入和复现比较，但不能完整呈现动作如何改变环境。交互环境能观察反馈与后续决策，却也引入更多需要控制的条件。

合成数据、真实日志和专家编写任务各自有价值。关键不是给某种来源贴上更真实的标签，而是检查它是否覆盖目标任务、角色和失败情形。

综述整理了代码评分、LLM-as-a-Judge 和人工评价等方式。它们回答谁来判断、依据什么判断，而不是直接决定要测什么。

规则可以稳定复现，但规则本身可能不完整。LLM 能提供灵活判断，但仍需要检查其判断质量。人工评价也需要清楚的准则，不能仅因有人参与就假定没有分歧。

所以，LLM-as-a-Judge 本身不是一个具体的性能指标。任务成功率可以通过代码、模型或人工产生标签后统计；同一种评分方式，也可以服务于多种评测目标。

综述还提到 Agent-as-a-Judge，但没有在统一条件下证明某类评分者普遍优于另一类。读者不应从方法列表推导出优劣排名。

这是阅读这篇综述时，特别容易向前多推一步的地方。

发现某一步质量低，可以支持错误定位；但要说这一步导致最终失败，还需要进一步证据。错误出现的位置、错误的来源，以及对最终结果的影响，并不总是同一个位置。

考虑一个自拟的三角色流程：A 检索资料，B 整理证据，C 输出结论。A 选错对象，B 忠实地整理了这份材料，C 因而给出错误结论。

如果只看最终输出，错误出现在 C；如果追溯输入来源，问题可能从 A 开始；如果检查各角色应承担的核验责任，B 和 C 是否漏掉必要检查，还取决于事先定义的职责。

仅凭某一步得分低，不能直接确定失败责任，更不能量化修正这一步能带来多少收益。 后一类判断可能需要替换某个步骤、比较修正前后的结果，或者使用清晰的归因标注与判定规则。

这里是在说明证据边界，不是转述本文提出了某种因果归因算法。这篇综述提供了从结果走向过程的入口，尚未完成从过程表现到失败责任的全部推理。

论文最后强调了企业场景中的几个缺口：角色权限、可靠性、长时程交互与领域政策。它们共同指出，短任务上的单次成功，覆盖不了真实系统长期运行的全部要求。

但这篇综述本身也有阅读边界。

首先，它没有给出可复现的系统检索与文献纳入流程，不宜据此断言已穷尽所有智能体评测工作。本地版本为 2025 年 7 月的 arXiv v1，也不能作为 2026 年新增研究的完整目录。

其次，分类之间存在交叉，表格中的指标也并非全部专属于智能体。选择指标时，仍然需要回到原始任务和定义。

还需要留意个别引用对应关系。例如，正文将 LongEval 列入长对话记忆讨论，但参考文献 [43] 的标题指向长文本摘要忠实性的人工评估指南。这一对应关系需要回查原始论文，不能仅凭综述中的名称就把它确定为长对话记忆基准。

因此，这篇论文最适合作为查找问题和文献的入口。真正采用某项指标前，还要核查它的计算方式、标注依据、环境条件与适用范围。

• 标题：Evaluation and Benchmarking of LLM Agents: A Survey
• 作者：Mahmoud Mohammadi、Yipeng Li、Jane Lo、Wendy Yip
• 机构：SAP Labs
• 发表：KDD 2025，Proceedings of the 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining V.2
• DOI：10.1145/3711896.3736570
• 阅读版本：arXiv:2507.21504v1，2025 年 7 月 29 日
• 图表来源：原论文 Figure 1、Table 1；局部图均在图注中标明。文中的订单案例、协作案例和概率计算为解释性示例，并非论文实验。