从 Benchmark 到企业实践：系统理解 LLM Agent Evaluation

传统 LLM 评测通常面对一个相对简单的问题：给模型一段输入，它能否生成正确答案？Agent 改变了这个问题。一个 Agent 可能要规划、搜索、调用工具、修改环境、处理错误，并在几十步之后才给出结果。最终答案正确，不代表过程可靠；任务失败，也不代表此前每一步都毫无价值。

本文以 ACL 2026 Findings 论文 A Survey on Evaluation of LLM-based Agents 为主线，系统整理 Agent Evaluation 的对象、Benchmark、环境、指标和开发框架，并进一步回答几个更实际的问题：Conversational Agent 怎样测试？Trajectory 如何评分？Human-in-the-loop 是否等于人工干预？怎样把 LLM 与 Harness 分开评测？做一个垂类 Research Agent 时，应该使用 Langfuse，还是完全自己实现 Eval？

论文出处：Asaf Yehudai, Lilach Eden, Alan Li, Guy Uziel, Yilun Zhao, Roy Bar-Haim, Arman Cohan, and Michal Shmueli-Scheuer. 2026. A Survey on Evaluation of LLM-based Agents. Findings of ACL 2026, pages 26690–26714. DOI: 10.18653/v1/2026.findings-acl.1330。

本文会明确区分两类内容：对论文分类和结论的整理，以及基于这些结论给出的工程实践建议。

Agent Eval 与普通 LLM Eval 的根本区别

普通 LLM Eval 常被抽象为：

Input → Model → Output → Score

Agent Eval 面对的是一条会改变环境的执行轨迹：

Task
  ↓
Observation → Planning → Action / Tool Call
     ↑                            ↓
     └────── New Environment State
                         ↓
                   Final Outcome

因此，Agent Eval 至少要回答三类问题：

结果是否正确：任务最终有没有完成？
过程是否可靠：规划、工具选择、参数、状态更新和错误恢复是否合理？
系统是否可部署：成本、延迟、稳定性、安全和合规是否可接受？

这也是为什么只检查最终文本会产生误判。Agent 可能声称“退款已完成”，但数据库根本没有变化；也可能确实完成了退款，却绕过身份验证，形成严重的安全问题。

论文给出的 Agent Eval 版图

论文 Figure 1 把领域划分为四个主要区域：Agent基础能力、特定应用Agent（垂类Agent）、通用Agent，以及用于开发和评测 Agent的框架。

基础能力评测

论文重点整理了四种能力。

Planning and Multi-Step Reasoning

这里评测 Agent 是否能：

将复杂目标拆成子任务；
维护长期计划；
跟踪环境状态；
根据执行结果调整计划；
在失败后恢复。

代表性工作包括 PlanBench、FlowBench 和 NaturalPlan。现有模型通常可以应付短期战术规划，但在长流程、带约束的战略规划中仍容易失败。

Function Calling and Tool Use

工具使用不只是“是否生成了一个函数调用”，而是多个子问题：

识别是否需要工具
→ 选择正确工具
→ 提取并填写参数
→ 执行工具
→ 理解工具结果
→ 决定下一步

早期 BFCL、ToolBench 等评测更关注单步函数选择和参数结构；后来的工作开始加入多轮、嵌套调用、隐式参数、状态依赖和真实 MCP Server，使评测更接近实际 Agent。

Self-Reflection

Self-Reflection 评测 Agent 能否理解外部反馈、修正信念，并改变后续行动。关键不是让模型生成一段“反思”，而是反思是否真正改善了决策。

这一方向仍缺少高度标准化的方法。只比较反思前后的最终正确率，会掩盖 Prompt 技巧、反馈质量和任务难度等因素。

Memory

Memory Eval 关注 Agent 是否能在长对话、多 Session 和持续任务中正确保存、检索并使用信息。需要区分：

episodic memory：过去发生过什么；
semantic memory：已经获得的事实知识；
procedural memory：怎样执行某种操作。

仅仅能在长上下文中找到一句话，不等于具备可靠的 Agent Memory。真正困难的是动态更新、处理事实冲突、跨任务切换，并避免把过时信息继续当成当前状态。

应用型 Agent Benchmark

Web Agent

Web Agent 的演进体现了整个 Agent Eval 的变化：从静态页面和下一步动作预测，走向真实或沙盒网站中的长流程操作。

Mind2Web 更接近基于缓存轨迹的静态评测；
WebArena 提供可改变状态的动态网站环境；
WebVoyager 等工作进一步强调视觉输入与真实网页交互；
安全向 Benchmark 开始检查政策遵守和风险操作。

静态环境容易扩展，但无法表现错误的连锁反应。动态环境中，一次错误点击会改变之后看到的页面，错误会沿轨迹累积，这才更接近实际 Agent。

Software Engineering Agent

SWE-bench 将真实 GitHub Issue、完整代码仓库、可执行环境和测试组合起来。它的核心结构是：

Issue + Repository + Agent Patch + Executable Tests

SWE-bench Verified 通过人工清洗和容器化提高可复现性。后续 Benchmark 则开始覆盖更长、更复杂的多文件任务、CLI 操作、测试生成和管理决策。

Scientific Agent

Scientific Agent Eval 已经从知识问答扩展到完整研究流程，包括：

科研构想；
假设与实验设计；
科学代码生成；
论文复现；
Peer Review；
端到端科学发现。

ScienceAgentBench、CORE-Bench、PaperBench 和 SciCode 分别覆盖其中不同环节。科学任务很难用一个统一成功率表示，因此通常需要层级化 Rubric，将复杂任务拆成可以单独评分的研究子任务。

Conversational Agent

Conversational Agent Benchmark 不是评价“聊天听起来是否自然”，而是测试 Agent 能否通过多轮对话完成真实业务任务，同时正确调用 API 并遵守政策。

可以把它与 SWE-bench 直接对应：

SWE-bench	Conversational Agent Benchmark
GitHub Issue	用户隐藏目标
Repository 初始状态	订单、航班、账户等数据库状态
修改代码、运行命令	对话与业务 API 调用
单元测试	最终数据库 State Matching
Coding 约束	身份、退款、隐私等业务政策

以取消订单为例，一条测试通常包含：

初始订单和用户数据；
一个未必完整表达的用户目标；
可调用的查询、验证、取消和退款工具；
业务政策；
LLM 驱动的 User Simulator；
预期最终状态和允许的操作约束。

τ-Bench 使用零售、航空等场景测试模拟用户、API 工具和政策遵循。τ²-Bench 进一步加入 dual control：Agent 和模拟用户都可以通过工具改变共享环境。例如技术支持过程中，用户不只是说“已经重启路由器”，而是真的通过模拟工具修改设备状态。IntellAgent 尝试从数据库 Schema 和政策文档自动生成测试；ALMITA 则通过中间任务图生成不同对话分支，再进行人工过滤。

这类评测至少应拆成四项：

对话：是否理解意图并询问必要信息；
工具：选择、参数和返回值处理是否正确；
任务：最终环境状态是否正确；
合规：是否绕过身份验证、权限或业务政策。

Generalist Agent

Generalist Agent 需要跨应用完成任务，同时组合推理、浏览、文件处理、代码执行和工具调用。GAIA 偏向综合推理和工具选择；OSWorld 通过 GUI 操作完整计算机环境；AppWorld 主要通过代码和结构化 API 操作应用；HAL 等平台尝试统一多个 Benchmark。

它们面临的关键问题是：不同 Benchmark 的工具、环境和 Harness 接口不一致，很难在相同条件下比较同一个 Agent。

Figure 1 是完整清单吗

Figure 1 是很好的“研究版图”，但不是完整的 Eval Checklist。它回答了“评什么能力、评什么应用、有哪些代表 Benchmark”，却没有完全展开“怎样判断一个 Agent 好不好”。

论文 Section 5 给出五个更接近 Benchmark 设计的问题：

维度	需要回答的问题
Data curation	数据由人工、合成、真实日志还是混合方式构建？
Environment	是静态 Trace，还是可以改变状态的动态环境？
Interface	Agent 使用代码、Terminal、Tool API 还是 GUI？
Metric	使用单元测试、状态匹配、动作匹配还是答案匹配？
Safety	是否检查权限、隐私、危险操作和政策违规？

此外，一个面向实际部署的 Eval 还应加入成本、延迟、稳定性、错误恢复、可复现性和 Harness 归因。因此，更完整的视角是：

能力层：Agent会什么
任务层：Agent在什么业务中工作
执行层：Agent如何完成任务、在哪里失败
系统层：Agent是否高效、稳定、安全、可部署

三种评测粒度

论文将开发框架支持的质量评测大致分为 Final Response、Stepwise 和 Trajectory 三个层次。

Final Response Evaluation

只评价最终输出，例如：

答案是否正确；
是否忠实于来源；
语气是否符合要求；
最终数据库状态是否匹配。

这种方式便宜、容易自动化，适合大规模回归测试，但无法定位中间步骤的问题。

Stepwise Evaluation

逐步检查：

路由是否正确；
是否选择正确工具；
参数是否合法；
Retrieval 是否相关；
当前动作是否推进目标。

它便于定位错误，但把步骤完全孤立也有风险。某一步单独看似多余，结合后续状态可能是合理的探索；某一步本身合法，放在错误顺序中却可能造成安全问题。

Trajectory-Based Assessment

Trajectory Eval 把完整的“观察—决策—工具调用—状态变化”序列作为整体评测。

Reference-based

预先定义一条或多条认可的轨迹，再与 Agent 实际轨迹比较。常见匹配方式包括：

Exact：动作、参数和顺序全部相同；
Partial：只比较关键步骤；
Subset：实际轨迹必须包含所有必要步骤；
Ordered：步骤可以不连续，但必须保持关键顺序；
Unordered：只要求动作集合完整；
Graph-based：检查是否访问必要节点、走合法分支和状态转换。

Reference-based 可复现，但容易把“不同但正确”的路径判错。对于需要先验证身份、再读取数据的流程，参考图通常比单一动作序列更合适。

Reference-free

不提供标准路径，而是让规则、人工或 LLM Judge 根据 Rubric 判断实际轨迹：

是否连贯；
是否持续推进目标；
工具选择是否合理；
是否低效或循环；
是否能从错误中恢复；
是否违反政策。

它可以接受新路径，但 Judge 可能把“看起来合理但实际上错误”的行动判为正确。因此，LLM Judge 应固定模型和 Prompt，要求引用具体 Step ID，并使用人工样本校准。

实践中最可靠的方式通常是混合评测：

程序化硬检查
├─ 最终状态
├─ 参数 Schema
├─ 权限与政策
└─ 必要步骤

Reference-based 约束
├─ 关键顺序
├─ 合法状态转换
└─ 禁止路径

Reference-free Judge
├─ 策略合理性
├─ 效率
├─ 解释质量
└─ 错误恢复

安全违规不宜只扣少量平均分。越权退款、数据泄漏等严重事件更适合做 Hard Gate，直接判定该任务失败。

Supporting Capabilities、Human-in-the-loop 与 Gym Environment

这三个词很容易混在一起。

Supporting Capabilities

Supporting Capabilities 不是 Agent 的能力，而是 Eval 平台为了管理评测流程提供的配套功能，例如：

Dataset 和实验管理；
Trace 与生产监控；
人工标注；
Synthetic Data Generation；
A/B Comparison；
从生产失败中生成回归样本。

这些能力解决的是“怎样组织考试、阅卷、比较版本和管理成绩”。

Human-in-the-loop

论文这里的 Human-in-the-loop 主要不是“人在每次执行中帮 Agent 完成任务”，而是：

专家标注结果；
人工建立 Gold Dataset；
审核 LLM Judge 的低置信度样本；
从生产日志中筛选和脱敏失败案例；
校准自动评测器。

如果人在 Agent 执行过程中给提示或接管操作，更准确的说法是 Human Intervention、Human Escalation 或 Human-Agent Collaboration。

Gym-like Environment

Gym-like Environment 是 Agent 真正参加测试的可交互沙盒。典型接口可以抽象为：

observation = env.reset(task)

while not done:
    action = agent.act(observation)
    observation, reward, done, info = env.step(action)

它需要具备几个特征：

可交互：Agent 的动作会改变环境；
可重置：每次恢复相同初始状态；
可执行：工具、代码或点击会真实产生结果；
可验证：可以检查最终状态；
可记录：完整轨迹能够用于后续分析；
相对隔离：避免测试误操作真实账户和生产数据。

BrowserGym 提供 Web 环境，SWE-Gym 提供代码仓库和终端环境，MLGym 提供机器学习实验环境。可以用一句话区分各个概念：

Benchmark Task：考什么题
Gym Environment：在哪里考试
Metric / Evaluator：怎样判卷
Supporting Capabilities：怎样管理考试与成绩

怎样把 LLM 与 Harness 分开评测

论文指出，许多 Agent Benchmark 同时改变 backbone LLM 与 Agent Harness，导致性能提升难以归因。这里的 Harness 包括：

System Prompt；
Planner、Router 和 Executor；
Memory 与 Context Management；
Retrieval；
Tool Schema 和执行策略；
Retry、Error Recovery 和终止逻辑；
Guardrails。

需要注意：Harness 无法在完全没有 LLM 的情况下得到一个有意义的端到端总分。Harness 的价值本来就是帮助某个 LLM 完成任务。正确方法是受控实验。

固定模型，只改变 Harness

需要固定：

模型的具体版本和推理配置；
Task Dataset；
工具权限和环境初始状态；
Token、时间、步骤和 Retry Budget；
随机性与重复运行次数。

然后比较：

同一个 LLM + Minimal Harness
同一个 LLM + Planner
同一个 LLM + Planner + Memory
同一个 LLM + Planner + Memory + Retry

这类 Ablation Study 可以回答每个模块带来了多少增益，以及增益是否值得额外成本。

再跨多个模型验证

只固定一个 LLM 仍不够，因为 Harness 与模型可能存在强交互。强模型可能不需要复杂 Planner，弱模型可能无法遵守复杂编排。更可靠的设计是 Model × Harness 矩阵：

	Minimal	Harness A	Harness B
Model 1	55%	68%	64%
Model 2	70%	74%	80%
Model 3	75%	73%	84%

此时应该报告：

Harness 在不同模型上的平均增益；
Model 与 Harness 的交互；
Task Success 与 pass@k；
Cost per Successful Task；
延迟、步骤数和工具调用数；
安全违规与错误恢复率。

Harness 组件仍然可以独立测试

Harness 的机械模块可以不调用真实 LLM：

用固定输入测试 Router；
用 Mock Tool 测试超时、重试和幂等性；
用构造轨迹测试 Context Manager；
用状态机测试终止和循环检测；
用固定工具调用测试参数验证和权限控制。

因此完整方案是：

组件级确定性测试
       +
固定 LLM 的 Harness Ablation
       +
多个 LLM 的交叉验证
       +
真实沙盒中的端到端测试

垂类 Research Agent：使用 Langfuse，还是自己实现 Eval

这不是二选一。更实用的边界是：

评测语义和 Grader 自己实现；Trace、Dataset、Experiment、标注与 Dashboard 借助现有平台。

Langfuse、LangSmith、Phoenix 等平台擅长：

收集和查看 Trace；
管理 Dataset；
对同一数据集运行不同配置；
保存代码、人工和 LLM Judge 的 Score；
统计成本与延迟；
A/B 比较；
将生产 Trace 回流为回归样本。

但它们无法替你定义：什么叫“高质量研究”、哪些来源必须找到、Citation 怎样才算支持 Claim，以及哪些错误必须直接阻止发布。这些是垂类产品的核心知识。

Research Agent 的评测维度

一个可用的起点是把评测拆成五层。

Retrieval

关键来源召回率；
一手来源占比；
来源权威性；
是否覆盖反面证据；
是否满足时间范围；
是否存在重复或失效链接。

Citation

Citation Validity：来源是否真实存在；
Citation Entailment：来源是否支持对应 Claim；
Citation Placement：引用是否放在正确陈述之后；
Citation Completeness：关键事实是否都有证据。

Synthesis

是否区分事实、推断和意见；
是否处理来源冲突；
是否说明不确定性；
是否真正回答用户问题；
是否避免只把多篇文章拼贴在一起。

Trajectory

Query 是否逐渐收敛；
是否优先寻找一手资料；
是否真正打开和阅读来源；
搜索失败后是否改变策略；
是否重复搜索；
达到充分证据后是否及时停止。

System

完成时间；
Token 与 API 成本；
搜索及工具调用次数；
多次运行稳定性；
安全、隐私与 Prompt Injection 风险。

其中 URL、结构、数字容差、工具异常等问题应优先用确定性代码检查；综合质量和证据权衡再交给领域专家或经过校准的 LLM Judge。

一个最小可行的 Eval 项目

可以从下面的结构开始：

eval/
├── datasets/
│   ├── golden_cases.jsonl
│   ├── adversarial_cases.jsonl
│   └── regression_cases.jsonl
├── graders/
│   ├── citation_validity.py
│   ├── citation_entailment.py
│   ├── source_quality.py
│   └── synthesis_judge.py
├── rubrics/
│   └── research_quality_v1.md
└── run_eval.py

早期原型甚至可以只用 JSONL、pytest 和一个简单实验报告。等到需要多人标注、大量 Trace、持续生产监控和版本对比时，再接入评测平台。不要把“拥有漂亮的 Trace UI”误认为“已经拥有可信的 Eval”。

企业内部通常怎样做

成熟团队通常采用混合架构：

企业真正长期积累的通常有三类资产。

Golden Set

由领域专家确认的高质量任务，包括常见任务、高价值任务、边界条件和安全案例。规模不一定巨大，但每一条都要有明确的预期行为和评分标准。

Regression Set

每次生产事故都应尽可能转化成以后必须通过的测试：

线上失败
→ 根因分析
→ 脱敏并最小化
→ 加入 Regression Dataset
→ 修复 Agent
→ 永久防止同类问题回归

Eval Gate

模型、Prompt、Tool Schema、Retrieval、Memory 或 Planner 发生变化时自动运行 Eval。发布条件可能包括：

核心任务成功率不得下降
关键业务 Slice 不得显著退化
Citation Correctness 达到阈值
严重安全违规为 0
P95 延迟与平均成本不超预算

上线后没有标准答案的真实流量，则通过用户反馈、工具错误、异常终止、成本漂移、Citation 抽查、LLM Judge 抽样和专家复核进行监控。线上 Eval 负责发现新问题，离线 Eval 负责防止问题再次出现。

论文指出的趋势与仍未解决的问题

论文总结了两个显著趋势：

从简化、静态任务走向真实、动态、长流程环境；
从容易过时的固定 Benchmark 走向持续更新的 Live Benchmark。

同时仍有几个关键缺口：

粗粒度成功率无法定位失败步骤；
成本、延迟与资源消耗尚未成为标准指标；
人工构建 Benchmark 难以扩展；
安全、鲁棒性和政策合规覆盖不足；
backbone LLM 与 Harness 的贡献难以解耦。

这些问题共同说明：Agent Eval 不是选择一个 Benchmark 跑出一个分数，而是在建立一套持续运行的质量工程系统。

一个可执行的 Agent Eval Checklist

如果从零开始设计垂类 Agent Eval，可以依次回答：

用户真正希望完成的任务是什么？
最终成功能否通过环境状态或程序化规则验证？
哪些中间步骤是必要的，哪些路径被禁止？
Agent 使用什么接口：代码、Tool API 还是 GUI？
如何构造可重置、隔离的动态环境？
哪些指标可以确定性计算，哪些需要 Judge？
LLM Judge 是否经过人工标注校准？
是否测量多次运行的稳定性，而不只测一次成功？
是否记录 Token、延迟、工具调用和成功任务成本？
是否把严重安全违规设置为 Hard Gate？
是否固定 LLM 对 Harness 进行 Ablation？
是否跨多个模型验证 Harness 的泛化性？
生产失败能否自动或半自动回流到 Regression Set？
Dataset、Rubric、Evaluator 和 Harness 是否都有版本？

总结

Agent Eval 的核心不是“最后回答得像不像”，而是衡量一个系统能否在动态环境中可靠、经济、合规地完成目标。

论文提供的 Figure 1 适合建立领域地图：规划、工具、反思、记忆，以及 Web、SWE、科研、对话和通用 Agent。但真正设计评测时，还必须加入环境、接口、数据、指标、安全、轨迹、成本和稳定性。

对于垂类 Agent，最现实的做法不是把评测全部交给 Langfuse，也不是从头重写整套平台，而是保留自己的 Dataset、Rubric 和 Grader，把通用的 Trace、实验、标注与监控交给成熟基础设施。到了企业环境，Eval 最终会成为一个闭环：专家定义质量，离线实验阻止退化，线上监控发现新问题，生产失败再沉淀为新的回归测试。

换句话说：Benchmark 给你一个分数；成熟的 Eval 系统告诉你为什么失败、改变了什么、能不能上线，以及下一轮应该改哪里。