LLM Agent 的评测与基准：一篇综述（中文全译）

LLM Agent 的评测与基准：一篇综述（中文全译）

翻译说明：本文是 arXiv 论文 Evaluation and Benchmarking of LLM Agents: A Survey（arXiv:2507.21504，2025-07-29 提交）的中文全译，由智测团队翻译。原作者：Mahmoud Mohammadi、Yipeng Li、Jane Lo、Wendy Yip（SAP Labs，美国）。该文发表于第 31 届 ACM SIGKDD 会议（KDD '25，2025 年 8 月，多伦多）。原文以 CC BY 4.0 许可发布，允许翻译与再分发，须署名。译文保留原文全部章节与论点，参考文献列表与文内引注编号从略，基准与工具名称保留英文原名。原文配图 1（评测分类树）随文保留，版权归原作者。

摘要

基于大语言模型（LLM）的 Agent 的兴起为 AI 应用打开了新的疆界，但如何评测这些 Agent 仍是一个复杂且不成熟的领域。本综述对这个新兴的 LLM Agent 评测领域做了深入梳理，提出一个二维分类体系，沿两条轴组织已有工作：（1）评测目标——评什么，例如 Agent 行为、能力、可靠性与安全性；（2）评测过程——怎么评，包括交互模式、数据集与基准、指标计算方法和工具。在分类体系之外，我们重点指出企业场景特有的挑战，例如基于角色的数据访问、可靠性保证的需要、动态且长时程的交互，以及合规要求——这些在现有研究中常被忽视。我们还指出了未来的研究方向，包括整体性、更真实和可扩展的评测。这项工作希望为碎片化的 Agent 评测图景带来清晰性，并提供一个系统化评估的框架，帮助研究者和实践者为真实部署评测 LLM Agent。

关键词：LLM Agent；Agent 评测；评测分类体系；Agent 行为；基准；安全；企业 AI

1. 引言

基于 LLM 的 Agent 是使用大语言模型进行推理、规划和行动的自主或半自主系统，代表着人工智能中快速增长的前沿方向。从客服机器人、编程副驾到数字助理，LLM Agent 正在重新定义我们构建智能系统的方式。

随着这些 Agent 从研究原型走向真实应用，如何严格地评测它们，变得既紧迫又复杂。评测 LLM Agent 比单独评测 LLM 更复杂。LLM 主要按文本生成或问答来评估，而 LLM Agent 运行在动态、交互的环境中：它们推理并制定计划、执行工具、利用记忆，甚至与人类或其他 Agent 协作。这种复杂行为和对真实世界效果的依赖，使标准的 LLM 评测方法不再够用。打个比方：LLM 评测评的是一台发动机的性能，Agent 评测则要全面评估一辆车在各种路况下的表现。

LLM Agent 评测也不同于传统软件评测。软件测试关注确定性和静态行为，LLM Agent 本质上是概率性的、行为是动态的，因此需要新的性能评估方法。LLM Agent 评测处在自然语言处理（NLP）、人机交互（HCI）和软件工程的交叉点上，需要额外的视角。

尽管这个方向的兴趣不断上升，已有综述要么狭窄地只谈 LLM 评测，要么只覆盖某几种 Agent 能力，缺乏整体视角。此外，企业应用给 Agent 带来了额外要求：对数据和系统的安全访问、为审计与合规所需的高可靠度、更复杂的交互模式——这些在现有文献中很少被处理。本综述希望成为 Agent 评测领域实践者和研究者的有用参考。我们的贡献有两点：

• 我们提出一个 LLM Agent 评测的分类体系，按评测目标（评什么：行为、能力、可靠性、安全性）和评测过程（怎么评：交互模式、数据集与基准、指标计算方法、评测工具、评测环境）组织已有工作。
• 我们指出企业场景特有的挑战，包括基于角色的访问控制、可靠性保证、长时程交互和合规要求。

后文结构如下：第 2 节描述本综述使用的分类体系；第 3 节展开第一个维度「评测目标」，聚焦被评测的 Agent 侧面；第 4 节展开第二个维度「评测过程」，聚焦评测方法；第 5 节讨论企业环境中评估 LLM Agent 的挑战；第 6 节给出开放问题与未来研究方向。

2. LLM Agent 评测的分类体系

我们提出一个二维分类体系来组织 LLM Agent 评测的不同侧面，两条轴分别是评测目标（评什么）和评测过程（怎么评）。该体系以层级树的形式呈现在图 1 中。

评测目标维度关心评测的对象。第一个类别「Agent 行为」聚焦结果导向的侧面，例如任务完成度和输出质量，刻画 Agent 在多大程度上满足最终用户的期望。接着，「Agent 能力」强调过程导向的胜任力，包括工具使用、规划与推理、记忆与上下文保持、多 Agent 协作。这些能力揭示了 Agent 如何达成目标、在多大程度上符合设计规格。「可靠性」评估 Agent 对相同输入是否表现一致，以及在输入变化或系统出错时是否稳健。最后，「安全与对齐」评估 Agent 的可信与安全，包括公平性、合规性，以及对有害或不道德行为的防范。

评测过程维度描述 Agent 如何被评估。「交互模式」区分静态评测（Agent 对固定输入作出响应）与交互式评估（Agent 与用户互动）。「评测数据」讨论合成数据集与真实数据集，以及面向软件工程、医疗、金融等特定领域的基准。「指标计算方法」涵盖定量度量（如任务成功率、事实准确性）和基于人类或 LLM 判断的定性评估。「评测工具」指支撑性基础设施，例如埋点框架（LangSmith、Arize AI 等）和公共排行榜（如 Holistic Evaluation of Agents），它们让评估可以规模化、可复现。最后，「评测环境」定义评测发生的场所，从受控模拟到开放世界设定（如网页浏览器或 API）。

这个分类体系既是概念框架也是实践指南，支持在广泛的目标、方法和部署条件下对 LLM Agent 做系统化比较与分析。后续各节将详细展开每个维度，指出关键评测实践和代表性研究。

随着 LLM Agent 被部署到日益多样和复杂的场景，单轮与多轮交互、多语言、多模态等因素都变得更加重要。分类体系在这些变化下依然适用，但通常需要定制化的指标与评测策略。我们会在相关小节讨论这些具体适配。

3. 评测目标

3.1 Agent 行为

Agent 行为指用户感知到的 Agent 整体表现——把 Agent 当作黑盒来看。它是评测中最高层的视角，也最直接地反映用户体验。这个类别涵盖任务完成度、输出质量、延迟和成本。

#### 3.1.1 任务完成度

任务完成度是 Agent 评测的基础目标，评估 Agent 是否成功达成给定任务的预设目标，即是否到达期望状态、是否满足为任务成功定义的具体标准。它有时被批评对失败缺乏细粒度洞察——尤其当多数模型成功率都很低时——但任务完成度仍然是衡量 Agent 整体表现的主要且必要的指标。

任务完成度通常用成功率（Success Rate，SR，也称 Task Success Rate 或 Overall Success Rate）来量化。相关指标还有任务目标完成度（TGC）和通过率（Pass Rate）。一些评测使用二元指标，例如对目标达成返回 0 或 1 的奖励函数。pass@k 和 pass^k 这类指标把成功扩展到多次尝试上。

这一目标被广泛用于各类 LLM Agent 评测领域和基准，包括编程与软件工程任务：解决 GitHub issue（SWE-bench）、科学数据分析编程（ScienceAgentBench）、复现研究（CORE-Bench、PaperBench）、应用内交互式编程（AppWorld）。它也大量用于与网页环境交互的 Agent：通用网页导航（BrowserGym、WebArena、WebCanvas）、多模态网页任务（VisualWebArena、MMInA），以及真实耗时的网页任务（ASSISTANTBENCH）。

#### 3.1.2 输出质量

输出质量指 LLM Agent 回复的特性，是一个伞形术语，涵盖准确性、相关性、清晰度、连贯性，以及对 Agent 规格或任务要求的遵循程度。Agent 可能完成了任务，但如果交互缺少上述品质，用户体验仍然糟糕。输出质量对评估对话 Agent 尤其重要，因为用户目标往往跨多轮达成。这个类别的许多指标与 LLM 评测重叠：例如流畅度（fluency）衡量输出符合自然语言习惯的程度，逻辑连贯性衡量论证的严谨程度。由于 LLM Agent 可能借助工具检索依据信息、给出上下文相关的文本回答，检索增强生成（RAG）系统的标准指标同样适用，例如回答相关性（Response Relevance）和事实正确性（Factual Correctness）。

#### 3.1.3 延迟与成本

延迟是 Agent 行为的关键侧面，在用户与 Agent 同步交互的场景中尤其如此。等待过长会显著损害用户体验、侵蚀对系统的信任。常用指标是首 token 时间（TTFT），衡量流式模式下用户看到第一个 token 前的延迟。对异步运行的 Agent，端到端请求延迟（收到完整响应的时间）往往更相关。

成本虽然不被最终用户直接观察，却决定了 Agent 能否规模化部署。我们把成本作为 Agent 货币效率的度量，通常按输入输出 token 数估算——这与多数 LLM 部署的按量计价直接相关。

3.2 Agent 能力

除外部行为之外，评测常常针对支撑表现的特定能力：工具使用、规划与推理、记忆与上下文保持、多 Agent 协作。评估这些能力有助于在更细的粒度上确定 Agent 的强项与弱项。

#### 3.2.1 工具使用

工具使用是 LLM Agent 的核心能力，使其能够检索依据信息、执行动作、与外部环境交互。在本综述中，工具使用指单个工具的调用，与函数调用（function calling）同义；为复杂任务确定工具序列的更复杂情形在 3.2.2 讨论。近年 ChatGPT-3.5 及之后的模型原生支持函数调用：模型可以自主决定是否调用函数、从候选集中选出合适的函数、生成所需参数。因此 LLM Agent 可以直接建立在底层模型的函数能力之上，许多最初为 LLM 开发的工具使用评测技术也得以沿用。

工具使用的评测要回答几个关键问题。第一，Agent 能否正确判断给定任务是否需要调用工具？如果能，它能否从定义的候选集中选出合适的工具？选定工具后，Agent 必须识别该工具需要的正确参数，并为每个参数生成合适的值以保证正确执行。当候选工具集很大时，Agent 还可能需要根据任务的自然语言描述从工具库中检索出正确的工具。

针对这些能力已有若干指标。调用准确率（Invocation Accuracy）评估 Agent 关于「是否要调工具」的决定是否正确。工具选择准确率（Tool Selection Accuracy）衡量是否从选项中选出了正确的工具。检索准确率（Retrieval Accuracy）关注系统能否从更大的工具集中检索出正确工具，常用 rank accuracy k 衡量。对基于排序的评估，平均倒数排名（MRR）量化正确工具在排序列表中的位置，归一化折损累计增益（NDCG）反映系统对全部相关工具的排序质量。

参数相关的评估涉及两个方面。参数名 F1 分数衡量 Agent 正确识别函数所需参数名并正确赋值的程度。一些评测依赖抽象语法树（AST）的正确性来检查工具调用在语法上是否有效，但这种方法可能漏掉语义错误，例如不正确或幻觉出的参数值——对受枚举类型约束的参数尤其如此。为弥补这一局限，Gorilla 等工作提出了基于执行的评估：真正运行工具调用并评估其结果，对工具使用能力给出更全面、更有依据的评估。

#### 3.2.2 规划与推理

规划与推理是 LLM Agent 的关键能力，对需要多步骤或在不确定下决策的复杂任务尤其重要。规划指按恰当顺序选出正确的工具集合；推理使 Agent 能够做出上下文感知的决策——或在事前，或在任务执行中动态进行。T-Eval 把规划评估表述为将预测的工具集合与参考集合比较。由于工具顺序和依赖关系也很重要，一些基准采用基于图的表示，引入 Node F1（工具选择）以及 Edge F1 或归一化编辑距离（评估工具调用序列与结构准确性）等指标。

在动态环境中，Agent 常常需要交替进行规划与执行，根据演变中的上下文调整动作。ReAct 范式展示了这种模式：Agent 在推理步骤和工具使用之间交替。评估这种自适应推理不能只比较静态计划，需要反映实时决策的指标。T-Eval 为此引入推理指标，评估 Agent 预测的下一个工具调用在每一步与期望调用的吻合程度，捕捉 Agent 在工具输出未知的情况下做出明智决策的能力。类似地，AgentBoard 提出进度率（Progress Rate），把 Agent 的实际轨迹与期望轨迹比较，细粒度地衡量 Agent 向目标推进的有效程度。

当要求 Agent 以生成完整多步程序的形式做规划时，代码生成的评测方法就变得相关。ScienceAgentBench 等基准用程序相似度指标将生成的计划与标注参考比较。此外，步骤成功率（Step Success Rate）被提出用来衡量生成计划中成功执行的步骤占比，从执行角度给出规划质量的整体视图。

#### 3.2.3 记忆与上下文保持

对长时间运行的 Agent，一项关键能力是在许多次交互中保留信息，并把先前的上下文应用到当前请求。Guan 等人按记忆跨度（信息保存多久）和记忆形式（信息如何表示）对多轮对话中的记忆评测做了分类。例如 LongEval 和 SocialBench 测试 Agent 在长对话（40 轮以上）中的上下文保持：给 Agent 一段跨越几十轮交流的对话，之后再提问需要回忆对话早期细节的问题。Maharana 等人展示了跨数百轮（600+ 轮）对话的评估；Li 等人引入记忆增强评测技术，追踪 Agent 在长时程任务中保持一致性的程度。这类评测常用合成或记录的对话作为数据集，指标包括事实召回准确率和一致性分数（轮次之间没有矛盾）。记忆评测还可能考虑工具型 Agent 的工作记忆（Agent 是否跟踪中间结果）和遗忘策略（是否恰当地遗忘无关细节以避免混淆）。

#### 3.2.4 多 Agent 协作

评估 LLM 系统中的多 Agent 协作，需要不同于传统强化学习驱动协调的方法。传统 Agent 依赖预定义的奖励结构，LLM Agent 则通过自然语言、策略性推理和去中心化的问题求解来协调。这些能力在真实应用中至关重要，例如金融决策和结构化数据分析——自主 Agent 必须高效地交换信息、协商并同步决策过程。Autonomous Agents for Collaborative Tasks 评估协作效率，即多个 Agent 动态分担职责、分配任务的好坏。

3.3 可靠性

可靠性是一个关键目标，尤其当 LLM Agent 被考虑用于企业和安全攸关的应用时。它涵盖一致性、对变化的稳健性，以及输出的可信程度。与任务表现（可能衡量的是最好情况下的能力）不同，可靠性评估探查的是最坏情况和平均情况。

#### 3.3.1 一致性

一致性指同一任务重复多次时输出的稳定性。LLM 本质上是非确定性的，基于 LLM 的 Agent 行为也因此有波动。要在企业或其他高风险场景中被信任，Agent 必须在同一任务的重复运行中表现一致。常用指标是 pass@k：Agent 在 k 次尝试中至少成功一次的概率。但更严格的一致性度量是 Agent 在全部 k 次尝试中都成功——τ-bench 将其形式化为 pass^k 指标，更好地刻画任务攸关部署的一致性要求。

#### 3.3.2 稳健性

稳健性指面对输入变化或环境改变时 Agent 输出的稳定性。要保持有效和可信，LLM Agent 必须在一系列有挑战的条件下持续给出高表现。稳健性评估通常用扰动输入对 Agent 做压力测试——改写的指令、无关或误导性上下文、错别字和方言等语言变体——看它能否仍然成功完成任务。例如可以对标准提示词做系统性变换，测量任务成功率或输出质量的下降幅度。HELM 基准明确纳入这类测试，追踪模型表现在输入变化下的退化。

稳健性还涵盖适应性恢复——Agent 从环境动态变化中恢复的能力。例如 WebLinX 考察网页结构在执行过程中改变时 Agent 的行为。在这类设定下，有效的 Agent 必须调整策略，而不是卡住或失败。

对工具型 Agent，稳健性还体现在错误处理能力上。ToolEmu 的评估表明，Agent 必须能得体地应对工具失败或意外输出。稳健性测试可以故意注入失败——API 报错、空响应——观察 Agent 是恢复（重试、换工具、向用户解释问题）还是崩溃。一个关键指标是被恰当处理的注入失败的比例，反映 Agent 在不确定或不完美条件下的可靠程度。

3.4 安全与对齐

安全涵盖 Agent 对伦理准则的遵循、对有害行为的避免，以及对法律或政策约束的合规。随着 LLM Agent 越来越强大和自主，意外不良后果（生成虚假信息、仇恨言论或不安全指令）的风险在增长，安全评测因此不可或缺。在金融服务、网络安全和自主决策等领域，Agent 的漏洞可能导致严重后果，这类评测尤其关键。

#### 3.4.1 公平性

AI Agent 缺乏公平与透明会导致有偏的结果、用户信任下降和意料之外的社会后果。例如在金融应用中，贷款审批或投资策略里的偏向性决策会强化系统性不平等（FinCon、AutoGuide）。多 Agent 交互中也会出现伦理问题：决策框架必须确保符合标准与社会规范（MATSA）。

可解释性对增强用户信任至关重要，尤其在 AI Agent 提供推荐或自动协助的交互式系统中。准则驱动的决策（AutoGuide）和结构化透明机制（MATSA、FinCon）等方法为用户提供清晰的推理路径。R-Judge 分析 Agent 在自主决策时如何感知风险，强调 AI 交互中的透明与可信。评估这些维度，确保 AI Agent 符合伦理标准，同时在其运行语境中保持公平。

#### 3.4.2 危害、毒性与偏见

安全的一个侧面是确保 Agent 的输出不含有害内容，例如仇恨言论、骚扰或极端偏见的表述。毒性评测常使用专门的测试集和指标，例如 RealToxicityPrompts——一组可能诱发毒性内容的提示词——用自动毒性检测器或人工评分员检查回复。指标包括含毒性语言的回复占比，或分类器给出的平均毒性分数。HELM 把毒性和偏见指标纳入整体评估，显示模型多频繁地产出冒犯性内容或表现出不该有的偏见。对交互式 Agent，可以给挑衅性或伦理上具挑战性的输入（红队测试），再测量其失败率（多频繁地以不安全方式回应）。CoSafe 等安全数据集正针对这一点：Yu 等人提出 CoSafe，用设计来诱骗对话 Agent 打破安全规则的对抗性提示（例如用户以微妙方式索取自残建议或非法指令）来评估对话 Agent。CoSafe 揭示出即使先进的 Agent 也有脆弱点，例如会落入基于共指的攻击（用户用含糊指代绕过过滤器）。评估过程是监控 Agent 面对对抗性查询时的回复是否违反政策。有了数值分数（如「Agent 在 X% 的对抗案例中产出了不被允许的回复」），安全性就被量化了。

#### 3.4.3 合规与隐私

除了避免明显的毒性，许多部署要求 Agent 遵守特定的监管或政策约束。例如金融聊天机器人不得泄露机密信息或提供特定类型的投资建议，医疗助手不得偏离既定医疗指南。合规评估可能高度领域特定，需要构造场景来测试 Agent 是否守住边界——例如用户向医疗机器人索取处方药推荐，正确且安全的行为是拒绝并建议咨询医生。

在企业语境中，合规评估可能需要反映真实政策的专有测试用例。一种做法是把这些关切整合进评测框架。例如面向企业的 HELM 基准被提议纳入领域特定的提示词和指标（如金融术语的准确性、回复的合规性），覆盖金融、法律等领域。流程是收集有代表性的企业场景（可能含机密或定制数据），并设计反映真实成功标准的评测指标——例如「Agent 的回复是否遵循了全部法律免责声明要求」。再如 TheAgentCompany 在结构化正确性约束下评估企业 AI Agent，要求它们在完成任务时遵循预定义的组织政策。

表 1. 评测目标及其指标

4. 评测过程

4.1 交互模式

LLM Agent 的评测可以在多种交互模式、借助不同工具进行。一个基本区分是离线评测（使用预先生成的静态数据集）与在线评估（涉及反应式模拟、人在回路或线上系统监控）。

#### 4.1.1 静态与离线评测

离线评测常作为基线，依赖数据集和静态测试用例：代表 Agent 可能面临的挑战的任务、提示词或对话集合。模拟对话可以用来帮助构建这些数据，但它们在多次运行之间是惰性的、不变的。离线评测相对更便宜、更简单、易维护，但通常缺乏足够的细腻度来覆盖 LLM Agent 可能给出或被期望给出的广泛回复。因此它们更容易发生错误传播，对系统表现的刻画一般也不够准确。

#### 4.1.2 动态与在线评测

与其他机器学习系统一样，在线评估通常发生在 LLM Agent 部署之后。在线评测不依赖合成、历史或人工构造的数据，而是利用模拟或真实的用户交互。这种自适应数据对识别静态测试发现不了的痛点和问题至关重要，而且往往富含领域上下文——这些是合成或通用基准难以捕捉的。动态评测可以用代理来模拟用户或环境，对 Agent 行为做出反应式的实时响应。例如在网页 Agent 评估中，研究者构建了网页模拟器（MiniWoB、WebShop、WebArena 等），Agent 的行为（点击链接、填写表单）可以被编程验证其顺序是否正确。

评测驱动开发（Evaluation-driven Development，EDD）的概念也已被提出：把评测作为 Agent 开发周期的内在部分。它主张对 Agent 做持续评测——开发期离线、部署后在线——以发现回归并适应新用例。相关文献还给出了一个参考架构，其中 AgentOps 组件监控生产环境中的 Agent 表现，并把洞察反馈给开发者。这仍是一个新兴想法，但它强调：评测不是一次性任务，而是持续过程，对会学习或演化的 Agent 尤其如此。

4.2 评测数据

对 LLM Agent 评测的兴趣增长，催生了大量针对第 3 节所述能力的多样化数据集、基准和排行榜。许多资源旨在反映真实世界的复杂性，由人工标注、合成和交互生成的数据混合构建。例如 AAAR-1.0、ScienceAgentBench、TaskBench 提供结构化、专家标注的基准，用于评估研究推理、科学工作流和多工具规划。FlowBench、ToolBench、API-Bank 则聚焦大型 API 库上的工具使用与函数调用。这类基准通常不仅包含标准工具序列，还包含期望的参数结构，支持细粒度评估。

与此同时，AssistantBench、AppWorld、WebArena 等数据集在网页和应用环境中模拟更开放、更交互的 Agent 行为，强调动态决策、长时程规划和用户-Agent 交互。若干基准还支持安全与稳健性测试：AgentHarm 评估潜在有害行为，AgentDojo 评估对提示注入攻击的抵抗力。Berkeley Function-Calling Leaderboard（BFCL）和 Holistic Agent Leaderboard 等排行榜通过标准化测试用例、自动化指标（如 AST 正确性、胜率）和排名机制，把这些评测整合起来供系统间比较。

4.3 指标计算方法

基于代码的方法是最确定、最客观的路线。它依赖显式规则、测试用例或断言来验证 Agent 的回复是否满足预设标准，对输出定义明确的任务特别有效：数值计算、结构化查询生成、编程任务的语法正确性。主要优点是一致性和可复现性，做基准非常可靠。缺点是不灵活：面对开放式或定性的回复——自然语言生成、创造性问题求解——正确性本身是主观的，代码方法就力不从心。尽管如此，它仍是评估「正确性有明确定义」的结构化任务的基础技术。

LLM-as-a-Judge 借助 LLM 的推理能力，按指令给出的定性标准评估 Agent 回复。因为能处理摘要、推理、对话交互这类主观而细腻的任务，这个方法获得了广泛关注。近期的一个扩展是 Agent-as-a-Judge：评估过程由多个 AI Agent 交互完成以精化判断，有望提升评估可靠性。这类方法高度可扩展、能适应复杂任务，因此受到越来越多的重视。

人在回路的评估对主观侧面（自然度、用户满意度）和安全攸关的判断仍是黄金标准。形式包括用户研究、专家审计（领域专家审查 Agent 输出）、众包标注（按相关性、正确性、语气等维度给输出评分）。在内容生成、策略决策、对话连贯性等开放式任务中，它的可靠性最高。但它昂贵、耗时、难以规模化，对需要频繁评估的大规模自动化系统并不现实。

4.4 评测工具

过程维度中值得注意的一点，是支持自动化、可扩展、持续评测工作流的软件框架与平台的出现。这些工具让评测直接融入开发生命周期，反映了 Agent 构建中评测驱动开发（EDD）的运动。OpenAI Evals 是一个开源框架，允许开发者为模型指定评测任务和指标，自动执行并报告结果（虽未在学术文献中正式描述，但反映了实践需求）。DeepEval、InspectAI、Phoenix、GALILEO 等开源或商业工具提供丰富的分析、评测编排和调试能力。此外，Azure AI Foundry、Google Vortex AI、LangGraph、Amazon Bedrock 等 Agent 开发平台也越来越多地内置评测功能，帮助开发者监控表现、发现回归、让 Agent 适应演变中的用户需求。Xia 等人进一步提出 AgentOps 架构，持续监控已部署的 Agent，通过实时反馈和质量控制闭合开发与部署之间的环。

4.5 评测环境

评测环境指评估发生的场所。与软件工程类似，这里存在一个权衡：更真实（但往往更贵、可能更不安全）对更简单、更受控（但通常对最终表现的代表性更弱）。评估系统的场所通常由系统的预期用途决定：一个没有编辑权限的简单 LLM Agent 可以直接在其工作环境中测试；而一个要与许多相互纠缠的系统协作并做出修改的 Agent，则更可能在 mock API 或沙箱环境中评估。对约束更少的系统，评测环境可以是网页模拟器，如 MiniWoB、WebShop 或 WebArena。随着 Agent 开发推进，评测环境往往随之演化——从较小的 mock API 环境，到性能和可信度得到确认后的真实部署。

5. 企业场景特有的挑战

当 LLM Agent 从研究演示走向企业部署，新的挑战随之出现。企业通常同时要求高表现与可预测的可靠性、法规合规、数据安全和可维护性——这些在评测中常被忽视。本节讨论这些关切并勾勒未来方向。

5.1 基于角色的访问带来的复杂性

企业环境中评测 LLM Agent 的一个关键挑战，是需要考虑基于角色的访问控制（RBAC）——它管理用户访问数据和服务的权限。在这类环境中，用户按角色拥有不同级别的访问权，代表用户行事的 Agent 必须遵守同样的约束。这给 Agent 评测引入了复杂性：Agent 检索信息或采取行动的能力不是均一的，而是与用户权限在上下文上绑定的。

为应对这一点，一些评测框架开始把访问控制约束纳入设计。例如 IntellAgent 包含要求验证用户身份的评测任务，并强制执行「拒绝访问其他用户信息」的策略。通过把角色特定的限制嵌入任务生成，这类方法更准确地建模了 Agent 在权限敏感的企业语境中的行为。

5.2 可靠性保证

可靠性保证在企业场景尤其重要：Agent 被期望在合规与审计框架内运行，这些框架要求确定性或可重复、可解释的行为。在这样的语境中，偶尔成功是不够的；Agent 必须在不同时间和使用场景中可靠表现，才算达到可上生产的标准。

评估可靠性并不容易。LLM Agent 本质上是随机的，测量一致性需要把同一任务执行多次并观察结果的变化。这带来显著的评估开销：每个输入跑多次试验在计算上很昂贵，当任务涉及工具、记忆或多 Agent 协调时尤其如此。而且，要得出有意义的结论，基准必须包含有代表性的数据集，反映 Agent 可能遇到的任务类型和条件。

一些工作已开始应对这个挑战。例如 τ-benchmark 明确纳入 pass^k 指标来评估 Agent 的一致性。把它应用到零售和机票预订等领域后，作者表明当前的 Agent 在一致性上仍有困难。

5.3 动态与长时程交互

评估 LLM Agent 在动态、演化环境中的长时程任务表现，是一大挑战。当前多数基准聚焦短回合或单次交互，而真实的企业 Agent 常常在与用户、系统和数据的交互中持续运行很长时间。

解决这个挑战对理解 Agent 随时间的行为至关重要，尤其在可靠性、适应性和目标对齐贯穿 Agent 生命周期的企业场景。标准的短期评测无法捕捉性能漂移、上下文保持，或决策对业务结果的累积效应这类现象。

一些研究开始用长时间运行的模拟和超长对话作为评测工具。例如 Park 等人在一个持续运行的模拟小镇环境中观察生成式 Agent，研究跨多日交互中的涌现行为。类似地，Maharana 等人通过 600 轮对话评估长期对话记忆，聚焦 Agent 在超长对话中保持连贯与上下文的能力。

5.4 遵守领域政策与合规要求

企业 Agent 评测的另一个重大挑战，是确保 Agent 能在领域特定的政策和合规约束内运行。企业通常执行严格的运营规则——审批工作流、数据保留政策、使用配额，以及 GDPR、HIPAA 等法规——Agent 在整个任务执行中都必须遵守。在这类语境中评估 Agent，不止是测量任务成功；还要验证 Agent 行为符合正式的政策约束和法律合规标准。例如生成财务报告的 Agent 必须避免未经授权访问机密预测，并确保生成内容遵循监管报告标准。如果评测时没有显式建模这些约束，在传统基准上「正确」的 Agent 仍可能因政策违规或合规风险在生产中失败。

6. 未来研究方向

随着 LLM Agent 在复杂性和应用范围上持续增长，未来研究必须推进更稳健、更实用、更可扩展的评测方法。我们指出四个能显著推进该领域的方向：

整体性评测框架。 当前评测常聚焦孤立维度：任务成功、规划质量或工具使用。但真实应用中的 Agent 必须同时平衡多种能力。未来工作应发展整体性评测框架，在多个相互依赖的维度上评估 Agent 表现。

更真实的评测设定。 为缩小实验室与生产环境的差距，Agent 评测必须走向更真实的条件，包括构建纳入企业特有要素的评测环境：动态多用户交互、基于角色的访问控制、领域特定知识。这可以通过真实部署试验，或通过模拟企业工作流的仿真环境来实现。

自动化与可扩展的评测技术。 人工评估 Agent 行为——尤其在多轮或长时程场景中——昂贵且难以规模化。未来研究应探索自动化评测方法以减少人工、提高可复现性，包括用合成数据生成可控测试用例、用仿真环境模拟任务上下文，以及推进 LLM-as-a-Judge、Agent-as-a-Judge 等基于 LLM 的评测技术。

时间与成本有界的评测协议。 评测必须高效，能支撑 Agent 的迭代开发。今天的方法——尤其需要重复试验或人在回路评估的——既耗时又耗资源。未来研究应发展时间与成本有界的评测协议，在深度和效率之间取得平衡。

总之，未来研究应聚焦发展整体、真实、可扩展且高效的评测方法。这些方向对规模化构建可靠、可信的 LLM Agent 至关重要。

署名与许可：原文 Evaluation and Benchmarking of LLM Agents: A Survey，作者 Mahmoud Mohammadi、Yipeng Li、Jane Lo、Wendy Yip（SAP Labs），arXiv:2507.21504，2025-07-29，发表于 KDD '25（DOI: 10.1145/3711896.3736570）。原文以 CC BY 4.0 许可发布。中文全译由智测团队完成，译文同样以 CC BY 4.0 发布；图 1 版权归原作者。原文地址：https://arxiv.org/abs/2507.21504 。译文中省略了参考文献列表与文内引注编号；基准、工具与指标名称保留英文。如译文与原文有出入，以英文原文为准。