模型能力评测：从 LLM Eval 到 Agent Eval
系列：开源模型评测
来源公众号：智能大时代
发布时间：2026-09-06 22:45
原文链接：阅读公众号原文
过去两年，大模型开始从 LLM 走向 Agent。
早期大家主要通过 Chat 的方式“使用模型”：提供 Prompt，模型输出一段文本。今天越来越多的操作，是让模型直接“做事”——完成信息搜集、代码开发、处理邮件、整理表格。
随着模型从“回答问题”走向“完成任务”，一个新的问题也变得重要：
应该如何评价一个 Agent？
如果不能可靠地评价 Agent，我们就很难回答一些最基本的问题：它到底能完成多少任务？是否会产生越权或错误操作？新模型真的比旧模型更好吗？这个版本是否可以应用到实际业务场景？
从 LLM Eval 到 Agent Eval
传统 LLM Eval 的基本结构相对简单，评测也比较直接。
在固定 Prompt、采样参数和评测流程的情况下，可以通过某种标准答案、规则或者 Judge 判断模型的输出质量。
例如数学题可以检查最终答案是否正确，代码题可以使用测试用例进行评分，而问答等主观任务可以让其他能力较强的模型或者专业 Judge 模型评价文本质量。
因此，传统 LLM Eval 的核心评测对象更接近模型本身的输出能力。
但 Agent 不一样。
Agent 不像传统 LLM 一样仅仅输出文本，而是会根据当前环境实际调用工具完成任务，过程中会涉及一系列连续的执行步骤。
举个例子，假设我们让一个 Coding Agent 修复 GitHub Issue。
它可能需要：
1. 阅读 Issue；
2. 搜索代码；
3. 打开多个文件；
4. 修改实现；
5. 执行测试；
6. 根据错误继续修改；
7. 最终提交 Patch。
整个过程远远超出了：Prompt → Response。下面的抽象流程更能反映 Agent 的执行过程：
Task ↓ Agent ↓ Action ↓ Environment ↓ Observation ↓ Action ↓ Environment ↓ ... ↓ Outcome
Agent 通过观察当前环境，选择合适的动作，动作改变环境后得到新的 Observation，然后继续选择动作，最终得到一个结果。
因此，Agent Eval 的评测对象也从一次简单的 Response，扩展成了一次完整的任务执行，也就是一个 Trial。
评测系统不仅要关注最终的 Outcome，还需要记录 Agent 和环境交互过程中产生的 Trajectory。
2. 一个 Agent 的表现，到底由什么决定？
我们刚才大致了解了 LLM Eval 和 Agent Eval 的差异，接下来进一步分析，一个 Agent 的实际表现到底由什么决定。
一个 Agent 的表现至少受到下面几个部分影响。
Model
也就是大模型。
大模型决定推理、规划、代码理解、工具选择等基础能力。
Scaffold
模型外部的 Agent 配套机制。
包括：
• System Prompt；
• Context 管理；
• Memory；
• Tool description；
• Planning 策略；
• Retry 机制；
• Reflection；
• Sub-agent；
• Context compression。
同一个模型换一个 Scaffold，最终表现可能完全不同。
Environment
Agent 所处的环境。
例如 Coding Agent 的：
• Repository；
• Shell；
• Docker；
• Test environment。
Office Agent 的：
• Email；
• Calendar；
• Spreadsheet；
• Browser。
Environment 决定 Agent 能看到什么、能操作什么，以及一个 Action 最终会产生什么结果。
如果我们的目标是比较某个特定变量，例如 Model 或 Scaffold，就应该尽量保证 Environment 一致，避免环境差异影响结果。
Task
Task 表示 Agent 被要求完成的事情。
不同业务场景对 Agent 的能力要求并不一样，例如编程、科研、办公、客服等场景，对模型能力和工具能力的侧重点都有明显差异。
因此，也不存在完全脱离 Task 的“Agent 总能力”。
一个 Agent 在 Coding Benchmark 上表现很好，并不意味着它在办公、科研或者客服场景中一定表现同样优秀。
所以在设计 Eval 时，一个非常重要的问题就是：
我们选择的 Task，是否真的代表了希望评估的业务能力？
Protocol
除了上面的元素，还有一个经常被忽略的变量：评测协议，也就是 Protocol。
Protocol 定义一次 Eval 应该如何运行，包括资源预算、采样方式和执行限制。
例如：
• 最多允许多少步？
• 最多使用多少 Token？
• timeout 是多久？
• 是否允许 retry？
• 是否允许联网？
• 是否提供 memory？
• temperature 是多少？
• 可以调用多少次工具？
• 每道题运行一次还是十次？
这些条件都有可能明显影响最终结果。
因此，脱离 Protocol 单独讨论一个 Agent 的分数，很多时候意义并不大。
Agent Eval 评的是一个 System
了解一个 Agent 系统包含哪些部分之后，就可以进一步理解，为什么 Agent Eval 应该从系统角度来看。
比如当我们说：
“某模型在某 Agent Benchmark 上得到了 70%。”
背后发生的事情涉及：
Model × Scaffold × Environment × Task × Protocol ↓ Trial ↓ Trajectory ↓ Outcome ↓ Grader ↓ Score
其中 Trajectory 是 Agent 完成任务过程中产生的一系列可观察行为，例如：
Observation → Action / Tool Call → Tool Result → State Change → Observation → ...
而 Outcome 是任务结束以后，环境最终处于什么状态，以及 Agent 实际产生了什么可验证的结果。
例如 Coding Agent 中：
代码是否真的被修复？ 测试是否通过？ 有没有引入新的 regression？
Agent Eval 评测的通常不是一个裸模型，而是 Model、Scaffold、Environment 和 Protocol 共同组成的完整系统。
Agent Eval 的关键，是控制变量
明白 Agent Score 是一个系统测量结果以后，就会发现，Agent Eval 并不只能用来比较模型。
需要评什么，取决于我们真正关注什么。
例如，如果我们想比较不同模型在当前 Agent 系统中的表现，可以：
固定 Task 固定 Environment 固定 Scaffold 固定 Protocol 只替换 Model
这时就是一个相对受控的 Model Comparison。
如果想比较不同 Agent Scaffold，则可以：
固定 Model 固定 Task 固定 Environment 固定 Protocol 只替换 Scaffold
这时评估的就是 Prompt、Memory、Planning、Retry、Context Strategy 等 Agent 设计。
如果问题是：
目前什么 Agent 系统最适合完成这个业务任务？
那就完全可以允许不同模型使用不同的：
• Prompt；
• Context Strategy；
• Tool；
• Retry；
• Planning；
• Memory。
关键不在于“Eval 一定评什么”，而在于：
我们希望回答什么问题，以及为了回答这个问题，需要控制哪些变量。
Agent 越容易做，Eval 越重要
随着 Coding Agent 能力越来越强，实现一个新的 Agent 门槛正在越来越低。
在这个趋势下，系统开发的瓶颈正在逐渐从：
“能不能把 Agent 做出来？”
转向：
“怎么知道这个 Agent 到底做得好不好？”
后一个问题往往比前一个问题更困难。
因为你需要定义：
什么叫正确？ 什么叫完成？ 什么错误可以接受？ 什么错误绝对不能发生？ 任务应该怎么构造？ 业务能力应该怎么覆盖？ 结果应该如何验证？
而且真正进入业务场景之后，客户和开发团队更加关心的往往也是：
准确率是多少？ 成功率是多少？ 稳定性怎么样？ 成本是多少？ 会不会越权？ 模型升级以后到底变好了还是变差了？
这些问题最终都指向 Eval。
换句话说：
Agent implementation 正在越来越容易，而高质量的 Evaluation 正在变得越来越昂贵。
这里的“昂贵”不仅是计算和开发成本。
高质量 Eval 往往需要业务专家参与任务设计，需要构造可复现的 Environment，需要设计可靠的 Grader，需要处理随机性、统计结果，还需要长期维护 Benchmark。
所以 Agent Eval 真正困难的地方，并不是执行几道 Benchmark，然后得到一个分数。
真正困难的是建立一套可信的测量系统：
什么任务能够代表真实能力？环境应该如何构造？过程应该记录什么？结果应该如何验证？