4.3 Agent 靠谱吗？——评估与测试
小李的 Agent 完成了一个任务：修复了 5 个 Bug。小李很开心，直到他发现——
- 2 个 Bug 确实修好了
- 1 个 Bug 「修好了」但引入了新 Bug
- 1 个 Bug 只是注释掉了报错代码
- 1 个 Bug 完全没修
Agent 说它修好了，但「修好了」不等于「修对了」。
为什么评估 Agent 这么难
评估一个 Chat 的输出很简单——看它回答对不对就行。但评估一个 Agent 的输出很难，因为：
| 挑战 | 说明 |
|---|---|
| 多步执行 | Agent 执行了 20 步，错在哪一步？ |
| 工具依赖 | Agent 调用了外部工具，是 Agent 错了还是工具返回了错误数据？ |
| 路径多样 | 同一任务可以有 10 条不同的执行路径，哪条更好？ |
| 状态变化 | Agent 修改了代码/数据，怎么验证改对了？ |
| 成本考量 | 每次评估都要跑一遍 Agent，成本不低 |
五个评估维度
一个靠谱的 Agent 评估体系，要覆盖五个维度：
任务完成度
做完了没？做到了什么程度？
执行效率
花了多少步/Token/时间？
工具使用
工具选对了吗？参数传对了吗？
错误处理
出错时怎么处理的？
安全合规
有没有违反规则？
| 维度 | 问什么 | 举例 |
|---|---|---|
| 任务完成度 | 任务做完了没？做到了什么程度？ | 5 个 Bug 修了几个？ |
| 执行效率 | 花了多少步/Token/时间？ | 修 5 个 Bug 用了 200 步，是不是太多？ |
| 工具使用 | 工具选对了吗？参数传对了吗？ | 该用搜索却用了遍历？ |
| 错误处理 | 出错时怎么处理的？ | 文件不存在是报错还是优雅降级？ |
| 安全合规 | 有没有违反规则？ | 有没有访问不该访问的文件？ |
小李回头看 Agent 的表现：
| 维度 | 评估 |
|---|---|
| 任务完成度 | 2/5 真正修好，1/5 引入新问题 → 差 |
| 执行效率 | 每个平均 40 步，尚可 |
| 工具使用 | 选对了工具，但分析不够深入 |
| 错误处理 | 第 4 个 Bug 选择注释掉报错代码而不是修复 → 危险 |
| 安全合规 | 没有越权操作 → 合规 |
三种评估方法
方法一：自动评估——跑测试
最直接的评估方式：写测试用例，看 Agent 能不能通过。
测试用例设计：
- 输入：一个包含 5 个已知 Bug 的代码库
- 预期：5 个 Bug 全部修复，无新 Bug 引入
- 验证：运行自动化测试套件 + 代码差异对比适合有明确预期输出的场景。但 Agent 可能有多种正确的解决方式，自动评估可能误判。
方法二：人工评估——逐行审查
人类审查 Agent 的每一步操作：
| 评分项 | 1 分 | 3 分 | 5 分 |
|---|---|---|---|
| 步骤必要性 | 大量冗余 | 偶有冗余 | 每步都有价值 |
| 决策正确性 | 多步判断错误 | 大部分正确 | 判断精准 |
| 错误处理 | 忽略或掩盖 | 基本处理 | 优雅处理 |
| 代码质量 | 不可用 | 可用但粗糙 | 可直接提交 |
最准确，但成本最高。适合关键任务的评估。
方法三：LLM-as-Judge——AI 评估 AI
用一个 LLM 来评估 Agent 的输出：
评估提示词：
你是一个代码质量审查员。请评估以下 Agent 的执行结果：
任务：修复 5 个 Bug
Agent 输出：[执行轨迹和修改结果]
请从以下维度评分（1-5）：
1. Bug 是否真正被修复？
2. 是否引入了新问题？
3. 代码质量如何？
4. 执行过程是否高效？速度快，成本低，但评估 LLM 本身可能有偏见或遗漏。适合快速筛选，不替代人工审查。
执行轨迹分析——看过程不只是看结果
Agent 的执行轨迹（Execution Trace）是评估的金矿。它记录了 Agent 每一步做了什么：
步骤 1：搜索 "console.log" → 找到 23 处
步骤 2：读取 app.js → 发现 3 处 console.log
步骤 3：修改 app.js → 删除 3 处 console.log
步骤 4：读取 utils.js → 发现 5 处 console.log
步骤 5：修改 utils.js → 删除 5 处 console.log
⚠️ 但其中 2 处是正式日志，不是调试语句
步骤 6：运行测试 → 2 个测试失败
⚠️ 因为删除了正式日志
步骤 7：修改 utils.js → 恢复 2 处正式日志
步骤 8：运行测试 → 全部通过从轨迹中可以发现：
| 分析维度 | 发现 |
|---|---|
| 步骤必要性 | 步骤 5 删除了不该删的 → 判断失误 |
| 决策正确性 | 步骤 5 误判了「正式日志」和「调试日志」 |
| 错误处理 | 步骤 6-7 发现问题并修正 → 错误恢复能力好 |
| 路径效率 | 可以在步骤 4 就区分日志类型，避免步骤 5-7 的弯路 |
轨迹分析的价值
结果好 ≠ 过程好。 Agent 可能通过「运气」得到了正确结果，但过程低效或危险。轨迹分析帮你找到真正的改进点。
持续评估体系
评估不应该是一次性的，而应该贯穿 Agent 的整个生命周期：
开发阶段单元测试工具
│
▼
迭代阶段A/B 测试
│
▼
生产阶段实时监控 + 审计日志
常见问题诊断清单
| 问题 | 可能原因 | 诊断方法 |
|---|---|---|
| 任务未完成 | 提示词不够清晰 / 工具不足 | 检查系统提示词和工具配置 |
| 无限循环 | 缺少终止条件 / 判断逻辑有误 | 检查循环终止条件和步骤计数 |
| 走偏 | 提示词缺少边界 / 记忆检索无关信息 | 检查系统提示词和记忆检索结果 |
| 高 Token 消耗 | 步骤冗余 / 上下文膨胀 | 分析轨迹，找出可压缩的部分 |
| 静默失败 | 错误处理不当 / 异常被吞 | 检查错误处理逻辑 |
评估基准
学术和工业界有一些标准化的 Agent 评估基准：
| 基准 | 覆盖范围 | 特点 |
|---|---|---|
| AgentBench | 8 个子任务（购物、浏览、操作系统等） | 学术标准，全面 |
| WebArena | 真实网页环境 | 贴近真实场景 |
| ToolBench | 工具使用/API 调用 | 专注工具能力 |
| SWE-bench | 软件工程任务 | 代码修复专项 |
这些基准对大多数开发者来说偏学术化，但了解它们有助于理解 Agent 的评估方法论。
本节核心要点
- 评估 Agent 的五个维度：任务完成度、执行效率、工具使用、错误处理、安全合规
- 三种评估方法：自动评估（跑测试）、人工评估（逐行审查）、LLM-as-Judge（AI 评估 AI）
- 执行轨迹分析是评估的金矿——看过程不只是看结果
- 评估应该持续贯穿 Agent 的整个生命周期
- 结果好 ≠ 过程好，轨迹分析帮找到真正的改进点
思考题：你有没有遇到过 AI 编程工具「看起来做对了但其实做错了」的情况？你会用什么方法来发现这种问题？
下一节预告：前面讲的都是「怎么做对」。现在让我们看看「为什么做错」——9 种 Agent 失败模式，每一种都可能在你放松警惕时出现。