目录

• 一、为什么 Agent Eval 变得重要？
• 二、Agent Eval 不是模型评测
• 三、没有 Eval 的 Agent 会出现什么问题？
• 四、Agent Eval 的完整流程
• 五、第一步：定义任务
• 六、第二步：运行试验
• 七、第三步：收集轨迹
• 八、第四步：检查结果
• 九、第五步：评估打分
• 十、第六步：得出分数
• 十一、第七步：持续改进
• 十二、三层 Grader 体系
• 十三、Code Grader：用代码做稳定评测
• 十四、LLM Grader：用模型评复杂结果
• 十五、Human Grader：用人类做最终校验
• 十六、一个复杂例子：评测代码修复 Agent
• 十七、一个简单例子：评测错别字修复 Agent
• 十八、Agent Eval 和 Agent Loop 的关系
• 十九、如何从零搭建一个最小 Agent Eval？
• 二十、常见误区
• 二十一、总结

---

如果说 2025 年大家都在讨论“谁能做 Agent”，那么接下来更重要的问题可能是：

谁能证明自己的 Agent 真的可靠？

做一个 Agent 并不难。

让模型能调用工具、能读文件、能操作浏览器、能跑命令，就可以做出一个看起来很厉害的 Agent。

但真正难的是：

它每次都可靠吗？
它失败时能被发现吗？
它换模型后效果变好还是变差？
它到底是稳定完成任务，还是偶尔靠运气成功？
它有没有把任务做对，而不是只是说自己做对了？

这些问题，靠感觉很难回答。

所以我们需要 Agent Eval。

一句话解释：

Agent Eval 不是评测一个模型，而是评测整个 Agent 系统。

这个系统包括：

Model
Agent Framework
Tools
Workflow
Memory
Prompt
Permissions
Validation

也就是：

模型 + Agent 框架 + 工具 + 工作流 + 上下文 + 权限 + 验证机制

---

一、为什么 Agent Eval 变得重要？

传统模型评测通常问的是：

这个模型数学能力怎么样？
代码能力怎么样？
中文能力怎么样？
推理能力怎么样？

但 Agent 出现之后，问题变了。

Agent 不只是回答问题，它会行动。

它可能会：

修改代码
运行测试
调用 API
操作浏览器
查询数据库
发送请求
生成文件
读取私有文档

这时我们要评估的就不只是模型本身，而是整个执行系统。

因为一个 Agent 的表现，可能受到很多因素影响：

模型有没有理解任务
工具是否设计合理
工作流是否合适
上下文是否保留了关键信息
失败时是否会重试
重试是否有边界
是否运行了验证
是否有权限控制
最终输出是否真实可信

所以，Agent Eval 的对象不是单点能力，而是完整链路。

---

二、Agent Eval 不是模型评测

这是最重要的一点。

Agent Eval 评的不是：

哪个模型更聪明

而是：

这个 Agent 系统能不能稳定完成任务

同一个模型，放在不同 Agent 系统里，表现可能完全不同。

比如模型本身很强，但工具设计很差：

搜索工具返回大量噪音
文件工具不能精确读取
测试工具没有错误摘要
浏览器工具不稳定

Agent 依然可能表现很差。

反过来，一个模型不是最强，但配上合理工具、清晰流程和严格验证，也可能在某类任务中非常可靠。

所以 Agent Eval 更像是在评估一个工作系统。

它评的是：

模型会不会判断
工具能不能执行
流程是否合理
结果是否验证
失败是否可追踪
系统是否能持续改进

这也是为什么我们不能只看模型排行榜来判断一个 Agent 好不好。

---

三、没有 Eval 的 Agent 会出现什么问题？

如果没有 Agent Eval，最常见的问题有四个。

1. 问题靠用户投诉才发现

Agent 出错以后，系统自己不知道。

只有用户发现结果不对，才会反馈：

你这个代码没有修好
你这个答案引用错了
你这个操作删错文件了
你这个结果和数据库对不上

这很危险。

一个成熟系统不应该只靠用户投诉发现问题。

2. 换模型不敢上线

比如你现在用模型 A，想换成模型 B。

没有 Eval 时，你只能凭感觉：

好像模型 B 更聪明
好像模型 B 更快
好像模型 B 便宜一些

但你不知道：

它在真实任务上成功率是否更高
它是否更容易乱调用工具
它是否更容易跳过验证
它是否在复杂任务上退化

没有 Eval，就不敢放心上线。

3. 不知道是回归还是随机波动

Agent 失败一次，到底说明什么？

可能是：

代码真的退化了
模型偶然失误
工具调用失败
测试环境不稳定
任务本身描述不清

没有 Eval 和轨迹记录，就很难区分。

4. Agent 成功全靠运气

有些 Agent 看起来能完成任务，但稳定性很差。

今天成功，明天失败。
这个项目成功，换个项目失败。
简单任务成功，复杂任务失败。

没有 Eval，就无法量化它到底有多可靠。

---

四、Agent Eval 的完整流程

一个完整的 Agent Eval 流程，可以拆成七步：

1. 定义任务
2. 运行试验
3. 收集轨迹
4. 检查结果
5. 评估打分
6. 得出分数
7. 持续改进

这七步构成一个闭环。

任务 -> 执行 -> 记录 -> 判断 -> 打分 -> 反馈 -> 改进

如果 Agent Loop 是让 Agent 完成任务的循环，那么 Agent Eval 就是让 Agent 系统持续变可靠的循环。

---

五、第一步：定义任务

Eval 的第一步是定义任务。

你不能只说：

评测一下我的 Agent。

这太模糊了。

你需要明确：

Agent 要解决什么问题？
输入是什么？
期望输出是什么？
什么算成功？
什么算失败？
是否允许部分成功？
有哪些边界条件？

例如，评测一个代码修复 Agent，可以定义任务：

输入：一个包含 Bug 的代码仓库和 Bug 描述
目标：修改代码修复 Bug
成功条件：
1. 相关测试通过
2. 没有引入新的测试失败
3. 修改范围合理
4. 最终说明清楚

评测一个客服 Agent，可以定义任务：

输入：用户问题和知识库
目标：基于知识库回答问题
成功条件：
1. 回答准确
2. 引用来源正确
3. 不知道时不胡编
4. 不泄露无权限信息

任务定义越清晰，Eval 越有意义。

---

六、第二步：运行试验

定义任务后，就要让 Agent 真正执行任务。

这一步不是让模型回答一道题，而是让整个 Agent 系统跑起来。

包括：

模型推理
工具调用
文件读写
浏览器操作
API 调用
测试执行
工作流切换
错误重试
最终输出

也就是说，Eval 要尽量接近真实运行环境。

如果真实 Agent 会调用工具，那 Eval 里也应该允许调用工具。
如果真实 Agent 会运行测试，那 Eval 里也应该记录测试结果。
如果真实 Agent 会走多轮循环，那 Eval 里也应该保留多轮过程。

否则评出来的结果就不真实。

---

七、第三步：收集轨迹

Agent 执行任务时，要收集完整轨迹。

轨迹通常叫 trace。

它记录的是 Agent 做了什么。

比如：

用户输入是什么
Agent 制定了什么计划
调用了哪些工具
每个工具输入是什么
每个工具输出是什么
读了哪些文件
改了哪些文件
运行了哪些测试
测试结果是什么
中间失败过几次
最终输出是什么

Trace 的价值非常大。

没有 trace，你只知道结果成功或失败。
有 trace，你能知道为什么成功、为什么失败。

比如一个代码 Agent 最终失败了。

没有 trace 时，你只能看到：

任务失败。

有 trace 时，你可能发现：

Agent 找错了文件
Agent 没有运行测试
Agent 忽略了关键报错
Agent 修改了不该改的文件
Agent 过早停止

这才是真正可改进的信息。

---

八、第四步：检查结果

收集轨迹后，要检查结果。

检查结果不是简单看 Agent 有没有说“完成了”。

而是要看：

任务目标是否完成
输出是否符合要求
验证是否通过
有没有副作用
有没有违反约束
有没有安全问题

代码任务可以检查：

测试是否通过
构建是否通过
Lint 是否通过
修改范围是否合理
是否引入新 Bug

问答任务可以检查：

答案是否准确
引用是否真实
是否基于给定资料
是否存在幻觉
是否泄露不该看的内容

浏览器操作任务可以检查：

页面状态是否正确
按钮是否真的点击成功
表单是否真的提交
截图是否符合预期

这一步的核心是：

不要相信 Agent 自己说完成了，要用外部标准判断。

---

九、第五步：评估打分

检查之后，需要打分。

打分可以很简单：

成功 / 失败

也可以更细：

0 分：完全失败
1 分：部分完成，但关键目标失败
2 分：完成主要目标，但有小问题
3 分：完全完成，验证通过

还可以拆成多个维度：

正确性：结果是否正确
完整性：是否完成所有要求
效率：用了多少轮、多少工具调用
安全性：是否遵守权限边界
可解释性：是否说明了过程
稳定性：多次运行是否一致

例如代码 Agent 可以这样打分：

测试通过：40 分
修改范围合理：20 分
没有引入新问题：20 分
最终说明清楚：10 分
工具使用合理：10 分

这样比一句“表现不错”更可用。

---

十、第六步：得出分数

打分之后，就可以得到量化结果。

比如：

总任务数：100
成功任务：82
部分成功：10
失败任务：8
成功率：82%
平均工具调用次数：6.3
平均耗时：48 秒
高风险失败：2 次

这些数据可以帮助你判断：

Agent 是否可上线
新模型是否比旧模型更好
某个工作流是否更稳定
某个工具是否经常导致失败
哪些任务类型最容易失败

这一步让 Agent 从“感觉不错”变成“数据证明”。

---

十一、第七步：持续改进

Eval 的最终目的不是打分，而是改进。

当你发现失败案例后，可以改：

Prompt
工具定义
工作流
上下文管理
测试集
权限规则
停止条件
错误处理方式

例如：

发现 Agent 经常忘记运行测试
-> 在工作流中加入强制验证步骤
-> 在 Eval 中加入“未运行测试扣分”

再比如：

发现 Agent 经常误改无关文件
-> 限制修改范围
-> 加入 diff 检查
-> 加入人工确认

这就是 Agent Eval 的闭环：

发现问题 -> 定位原因 -> 修改系统 -> 再次评测

成熟的 Agent 系统，就是这样一点点变可靠的。

---

十二、三层 Grader 体系

Agent Eval 里很重要的一个概念是 Grader，也就是评分器。

常见可以分成三层：

1. Code Grader
2. LLM Grader
3. Human Grader

它们各有适合的场景。

Code Grader：稳定、便宜、可扩展
LLM Grader：灵活、能处理复杂语义
Human Grader：最可靠，适合最终校验

真实系统里，通常不会只用一种 Grader，而是组合使用。

---

十三、Code Grader：用代码做稳定评测

Code Grader 是最稳定的一类评测方式。

它用程序来判断结果。

比如：

单元测试是否通过
接口返回是否正确
输出 JSON 是否符合 schema
文件是否存在
字段是否完整
工具是否被正确调用

代码 Agent 的评测特别适合 Code Grader。

例如：

运行 pytest
运行 npm test
运行 pnpm build
检查 diff
检查输出文件

优点：

稳定
便宜
速度快
可批量运行
结果明确

缺点：

只能评确定性强的问题
不擅长判断语义质量
不擅长评开放式答案

比如它可以判断测试是否通过，但不一定能判断“方案设计是否优雅”。

---

十四、LLM Grader：用模型评复杂结果

LLM Grader 是用另一个模型来做评审。

它适合评估更复杂、更开放的结果。

比如：

回答是否符合资料
总结是否完整
方案是否合理
代码解释是否清楚
是否遗漏关键约束
多个答案哪个更好

LLM Grader 可以使用 rubric，也就是评分标准。

例如：

请从 1 到 5 分评价答案：
1. 是否回答了用户问题
2. 是否引用了正确资料
3. 是否避免编造
4. 是否表达清晰
5. 是否没有泄露敏感信息

优点：

灵活
能处理自然语言
能评复杂任务
适合开放式输出

缺点：

成本更高
本身也可能误判
需要设计好评分标准
最好配合抽样人工复核

LLM Grader 不是万能裁判，但它能覆盖 Code Grader 难以覆盖的语义质量问题。

---

十五、Human Grader：用人类做最终校验

Human Grader 是人工评审。

它通常用于高价值、高风险、难自动判断的任务。

比如：

医疗建议
法律文本
复杂架构设计
企业级方案评估
重要客户回复
上线前抽检

人工评审可以做：

专家评审
抽样检查
A/B Test
用户满意度评价
标注失败原因

优点：

最可靠
能理解复杂背景
能发现自动评测漏掉的问题

缺点：

成本高
速度慢
不适合全量评测
标准需要统一

所以 Human Grader 更适合做最终兜底，而不是每次都全量使用。

---

十六、一个复杂例子：评测代码修复 Agent

假设你有一个代码修复 Agent。

它的任务是：

根据 Bug 描述，自动修改代码，并让测试通过。

我们可以这样设计 Eval。

1. 定义任务集

准备 100 个历史 Bug。

每个任务包含：

Bug 描述
初始代码仓库
相关测试
期望行为
禁止修改的文件

2. 运行 Agent

让 Agent 对每个任务执行：

读取 Bug 描述
分析代码
修改文件
运行测试
输出总结

3. 收集 Trace

记录：

读了哪些文件
改了哪些文件
运行了哪些命令
测试失败过几次
最终 diff 是什么
最终说明是什么

4. Code Grader 打分

自动检查：

相关测试是否通过
全量测试是否通过
是否修改了禁止文件
输出是否符合格式

5. LLM Grader 评审

让模型评估：

修改是否聚焦
解释是否合理
是否存在过度重构
是否可能引入隐藏风险

6. Human Grader 抽检

人工抽样检查：

高风险修改
失败案例
LLM Grader 分歧案例
上线前关键任务

7. 输出报告

最终报告可以是：

总成功率：84%
平均修复时间：3 分钟
平均工具调用：8 次
最常见失败原因：没有正确定位入口文件
高风险失败：3 个
建议改进：加强初始文件定位策略

这时你就不再是凭感觉判断 Agent 好不好，而是有数据。

---

十七、一个简单例子：评测错别字修复 Agent

再看一个非常简单的例子。

任务：

把文本中的 agnet 改成 agent。

输入：

我今天学习了 agnet loop。

期望输出：

我今天学习了 agent loop。

Code Grader 可以直接判断：

expected = "我今天学习了 agent loop。"
actual = agent_output

score = 1 if actual == expected else 0

这个任务不需要 LLM Grader，也不需要 Human Grader。

这说明一个原则：

能用代码评的，就优先用代码评。

只有代码无法判断语义质量时，再使用 LLM Grader 或 Human Grader。

---

十八、Agent Eval 和 Agent Loop 的关系

Agent Loop 关注的是：

Agent 如何完成一次任务

它的循环是：

目标 -> 计划 -> 行动 -> 观察 -> 修正 -> 验证 -> 完成

Agent Eval 关注的是：

如何判断 Agent 系统是否可靠

它的循环是：

定义任务 -> 运行 Agent -> 收集轨迹 -> 评分 -> 分析失败 -> 改进 Agent

两者关系可以这样理解：

Agent Loop：执行层
Agent Eval：质量层

没有 Agent Loop，Agent 做不了复杂任务。
没有 Agent Eval，你不知道 Agent 做得好不好。

所以一个成熟 Agent 系统，应该同时具备：

能做事的 Loop
能评估的 Eval
能改进的反馈闭环

---

十九、如何从零搭建一个最小 Agent Eval？

如果你想自己做一个最小版本，可以从下面开始。

1. 准备任务集

先准备 20 个真实任务。

例如代码 Agent：

10 个简单 Bug
5 个中等 Bug
5 个复杂 Bug

2. 定义成功标准

每个任务都要有明确标准：

哪些测试必须通过
哪些文件不能改
输出必须包含什么内容

3. 记录运行过程

至少记录：

输入
最终输出
工具调用
修改文件
测试结果
错误日志

4. 先用 Code Grader

能自动判断的先自动判断：

测试是否通过
文件是否存在
输出格式是否正确

5. 再加 LLM Grader

对复杂输出加模型评分：

是否回答完整
是否解释清楚
是否符合约束

6. 人工抽检

每次随机抽 5-10 个结果人工看。

重点看：

失败案例
低分案例
模型判断不确定案例
高风险任务

7. 根据失败改系统

不要只看分数，要看失败原因。

例如：

失败原因：经常找错文件
改进方式：增强搜索策略

失败原因：经常忘记验证
改进方式：强制运行测试

失败原因：输出解释不清楚
改进方式：修改最终报告模板

这就是一个最小可用的 Agent Eval 闭环。

---

二十、常见误区

1. 只评模型，不评系统

Agent 的表现不只由模型决定。

工具、工作流、上下文和验证都会影响结果。

2. 只看最终答案，不看过程

Agent 的过程很重要。

一个结果对了，但过程危险，也可能不能上线。

比如：

最终测试通过了，但 Agent 顺手删除了大量无关代码。

这就有风险。

3. 只用 LLM Grader

LLM Grader 很灵活，但不是所有东西都要用模型评。

能用代码判断的，就用代码判断。

4. 没有失败分类

只知道失败率不够。

还要知道为什么失败：

理解错误
工具错误
权限错误
测试错误
上下文丢失
工作流选择错误

5. Eval 集合太干净

真实世界的问题往往很脏。

Eval 里应该包含：

模糊描述
错误输入
边界情况
工具失败
上下文很长
权限不足
多步骤任务

否则评出来的 Agent 只会在理想环境里表现好。

---

二十一、总结

Agent Eval 的核心不是问：

这个模型聪不聪明？

而是问：

这个 Agent 系统能不能稳定、可靠、可验证地完成任务？

它评估的是完整系统：

Model
Agent Framework
Tool
Workflow
Context
Permission
Validation
Trace

一个完整的 Agent Eval 流程包括：

定义任务
-> 运行试验
-> 收集轨迹
-> 检查结果
-> 评估打分
-> 得出分数
-> 持续改进

评分方式可以分三层：

Code Grader：稳定、便宜、适合确定性任务
LLM Grader：灵活、适合复杂语义任务
Human Grader：最可靠，适合高风险最终校验

如果说 Agent Loop 解决的是“Agent 如何做事”，Dynamic Workflows 解决的是“Agent 该用什么方式做事”，那么 Agent Eval 解决的就是：

Agent 做完以后，我们如何证明它真的做对了？

未来做 Agent 的门槛会越来越低。

真正拉开差距的，可能不是谁能做出一个会动的 Agent，而是谁能做出一个可评测、可追踪、可改进、可上线的 Agent。

一句话总结：

Agent 很容易做，Agent Eval 才是真正的护城河。