06. Agent 的评测为什么比普通 LLM 更难？有哪些评测方案？
整理 Agent 评测难点、任务完成率、过程评测与相关 Benchmark。
简单回答
Agent 评测比单模型评测难，核心在于 Agent 是一个动态的多步骤交互系统，最终结果依赖一连串决策，单看最终输出无法判断过程是否合理；而且 Agent 的执行环境往往需要真实工具调用、真实文件系统或网络，搭建成本高；加上任务本身可能有多种正确路径，难以定义"正确答案"。目前主流方案分为结果评测（只看最终结果）和过程评测（逐步评判每个工具调用和决策），两者各有取舍。
详细解答
Agent 评测为什么特别难
多步骤、非线性的执行路径：一个普通 LLM 对话是一次输入一次输出，评测很直接。但 Agent 完成一个任务可能需要 5~20 步工具调用，每一步的决策影响后续所有步骤。最终结果对还是错，不能说明 Agent 的哪步出了问题，也不能说明"如果换一个任务难度稍微不同的问题，Agent 会怎么表现"。
工具调用的正确性难以自动验证：Agent 可能调用搜索、执行代码、读写文件、发送邮件等工具。验证"搜索查询是否合理"、"代码逻辑是否正确"比验证"最终答案对不对"要复杂得多。而且工具调用有副作用，真实执行可能带来不可逆的操作（真的发了邮件、真的修改了文件），所以测试环境必须是沙盒化的。
任务分解能力难以量化：好的 Agent 应该能把复杂任务拆解成合理的子步骤，这种规划能力很难用单一指标衡量。即使最终任务完成了，规划过程可能绕了很多弯路；即使最终失败了，中间过程可能大部分是正确的。
环境依赖性强：Agent 的评测结果高度依赖于工具和环境的设置。搜索工具返回的结果、代码执行环境的版本、文件系统的初始状态——任何一个变化都可能导致不同结果，评测的可重复性很差。
多种正确路径：完成同一个任务可以有多种合理的工具调用序列。比如"找出过去一年内微软股价的最高点"，可以用搜索、也可以用数据 API、也可以执行 Python 代码——三种路径都是"正确的"，无法用单一的参考路径来评判。
主流评测方案
**任务完成率（Task Success Rate）**是最直接的指标：给 Agent 一批任务，看有多少能完成。这是结果导向的评测，不关心过程。优点是直观、好解释，适合最终性能比较；缺点是信息量不足，出了问题不知道哪个环节导致的。
代表性 benchmark：WebArena（网页操作任务）、OSWorld（桌面 OS 操作任务）、SWE-Bench（软件工程问题，需要 Agent 读代码、定位 bug、写 patch）。其中 SWE-Bench 是目前最有代表性的代码 Agent benchmark，用 GitHub 上的真实 issue 来测，要求 Agent 生成能通过测试的 patch，结果可执行验证，非常可靠。
过程评测（Process Evaluation / Step-level Evaluation）：评判 Agent 在每一步做了什么决策、是否合理。比如：是否正确调用了应该调用的工具？调用参数是否正确？是否在应该停止时停止、而不是无限循环？
过程评测需要标注"正确的轨迹"（Trajectory），即任务完成的理想步骤序列，然后和 Agent 实际的轨迹比较。Trajectory F1（衡量实际轨迹和参考轨迹的重叠度）、工具调用精确率/召回率都是这类指标。
局限是标注参考轨迹非常耗时，而且一个任务的正确轨迹不唯一，参考轨迹只是其中一种，和参考轨迹不同不等于错误。
LLM Judge 评过程：用 LLM 逐步评判 Agent 的每一步决策是否合理，而不是和参考轨迹做精确匹配。这比较灵活，能处理"不同但合理"的执行路径，但需要 Judge 本身具备足够强的推理能力。
安全性和鲁棒性评测：对 Agent 来说，除了能力，安全性是另一个重要维度。需要测试 Agent 在面对 Prompt Injection 攻击（通过网页或文件里的恶意内容诱导 Agent 做不该做的事）时是否鲁棒；是否会执行权限超出范围的操作（比如发邮件给不该联系的人）；在工具返回错误或异常时是否能正确处理。
Efficiency 评测：完成同一个任务，Agent 用了多少步、消耗了多少 token、花了多少时间。这对生产环境的成本控制很重要，但目前 benchmark 里这个维度关注不够多。
评测基础设施的要求
Agent 评测的环境搭建是主要的工程挑战。需要：沙盒化的真实工具（模拟搜索、代码执行环境、文件系统、浏览器等）；可重置的初始状态（每次测试前把环境重置到一样的起始状态，保证可重复性）；工具调用日志记录（把每一步的输入输出都记录下来，方便事后分析）。很多团队低估了这块的工程量，结果评测环境不稳定，测出来的结果重复性差。
面试时可以这样答
Agent 评测难，难在它是多步动态系统，不是一问一答。最终任务做没做成，不代表过程合不合理；工具调用的顺序和参数，很难自动判断对不对；完成同一个任务有多种正确路径，无法用单一参考轨迹来评判；而且测试环境要沙盒化，搭建成本高，还得可以重置，保证可重复。
现在的主流方案是结果评测和过程评测结合。结果评测看任务完成率——SWE-Bench 是代码 Agent 的金标准，用 GitHub 真实 issue 测，patch 能不能通过测试，可执行验证，非常可靠。WebArena、OSWorld 是操作类 Agent 的 benchmark。过程评测要标注参考轨迹，比较实际轨迹和参考轨迹的重叠，但标注成本高，而且参考轨迹不唯一。
工程上最容易被忽视的是评测基础设施——沙盒化工具、可重置环境、工具调用日志——这块做不好，评测结果重复性很差，换个环境分数就不一样了。
常见追问
- SWE-Bench 的难度分布是什么样的？现在最好的 Agent 达到了多少通过率？
- Prompt Injection 对 Agent 的攻击是怎么发生的？评测里怎么系统性地测这个？
- 多 Agent 系统的评测（评测整体系统 vs 评测单个 Agent）该怎么设计？