评估与调试：Agent 效果怎么衡量
Agent 比普通对话模型难评估得多，因为涉及多步推理、工具调用、长任务执行。这篇讲 Agent 的评估维度、评估方法、调试技巧，以及怎么定位和优化常见问题。
大家好，我是黒漂技术佬。
普通大模型问答，看回答对不对就行。Agent 复杂多了：规划对不对、工具选得对不对、参数对不对、结果准不准、用了多少步、花了多少钱……
Agent 难评估也难调试，因为中间步骤多，出问题不知道是哪一步错了。
这篇讲 Agent 怎么评估、怎么调试、常见问题怎么定位。
一、为什么 Agent 难评估？
对比普通问答
| 普通问答 | Agent |
|---|---|
| 单轮输入输出 | 多轮循环、多步骤 |
| 只看最终答案 | 还要看过程对不对 |
| 评估维度单一 | 维度多（正确率、步数、成本、工具准确率） |
| 容易做评测集 | 评测集难做，任务多样 |
Agent 评估的难点
- 过程也很重要：答案对了但过程瞎蒙的，下次可能就错了
- 任务多样性：不同任务差异大，很难一套指标通吃
- 非确定性：同样的输入每次结果可能不一样
- 长任务难评估：步骤多，中间错了一步可能最后还蒙对了
- 成本高：跑一次评测要调用很多次模型
二、评估维度
1. 结果正确性（最终效果）
最终答案对不对，有没有解决用户问题。
- 正确率：答对的比例
- 完整性：有没有遗漏关键点
- 相关性：有没有答非所问
- 事实准确性：有没有幻觉、编造信息
2. 过程质量
执行过程好不好，路径对不对。
- 工具调用准确率：该调用的工具选对了吗？
- 参数正确率：工具参数填对了吗？
- 步数效率：用了多少步完成，是不是最优路径
- 规划合理性：任务拆解合不合理
- 有没有多余步骤：是不是绕路了
3. 效率与成本
- 总 token 消耗：花了多少钱
- 执行时间：用户等了多久
- 工具调用次数：调用了多少次工具
- 平均步数：完成一个任务平均几轮
4. 鲁棒性
稳不稳定，异常情况能不能处理。
- 容错率：工具报错了能不能调整
- 异常处理：遇到意外情况会不会崩
- 一致性：同样的问题多次执行，结果差多少
5. 安全与可控性
- 会不会调用不该用的工具
- 有没有越权操作
- 输出有没有有害内容
三、评估方法
方法 1：人工评估
人来打分，最准确但最贵最慢。
怎么做：
- 准备一批测试用例
- 跑 Agent 得到结果（包括过程）
- 人按维度打分
优点：最准确，能评估主观质量
缺点：慢、贵、不可持续、人也会有偏差
适用：核心场景的抽样评估、最终上线前验收
方法 2：自动评测集
准备一批有标准答案的测试题，自动跑自动判分。
怎么做：
测试集 = [ {"question": "北京今天天气？", "expected_answer": "包含温度和天气状况", "expected_tools": ["weather"]}, ... ]自动跑每个问题，检查：
- 最终答案是否正确（可以用模型打分）
- 调用的工具对不对
- 步数是否在合理范围
优点：可重复、快、能持续跑
缺点：测试集制作成本高，覆盖不了所有场景
适用：回归测试，每次改代码跑一遍看有没有退步
方法 3：LLM 打分
用另一个大模型当评委，给 Agent 的回答打分。
Prompt 示例：
请评估以下Agent回答的质量，从以下几个维度打分（1-5分）： 1. 正确性：答案是否正确 2. 完整性：是否完整回答了问题 3. 相关性：有没有答非所问 问题：xxx 回答：xxx 请输出JSON格式的评分。优点：比人工便宜快，比规则灵活
缺点：大模型当评委也会有偏差，不稳定
建议：跟人工抽样结合用
方法 4：端到端任务成功率
针对完整任务，看能不能成功完成。
比如「订一张明天去上海的机票」，成功标准：
- 正确查询航班
- 正确选择符合条件的
- 正确下单（模拟）
优点：最贴近真实业务效果
缺点：判定成功失败的标准不好定
方法 5：单组件评估
拆开评估每个模块：
- 工具选择准确率：给问题，看选的工具对不对
- 参数正确率：工具参数填对了吗
- 检索命中率：RAG 搜出来的内容相关吗
- 规划质量：任务拆解合不合理
哪个模块差就优化哪个。
四、调试方法
1. 日志追踪
把每一步都打日志，出问题回看。
要记录的信息：
- 每轮的输入 prompt
- 模型的输出（Thought、Action、参数）
- 工具调用的输入输出
- 每轮的 token 消耗和耗时
- 最终答案
示例日志结构：
Step 1: Thought: 需要查北京天气 Action: get_weather Action Input: {"city": "北京"} Observation: 北京晴，25-32℃ Tokens: 456 Time: 1.2s Step 2: Thought: 信息足够，可以回答了 Final Answer: ...2. 中间结果可视化
把 Agent 的执行过程展示出来，每一步都能看到。
很多框架都有追踪工具：
- LangChain 的 LangSmith
- Langfuse
- 自己做个简单的前端展示
能看到每一步在干嘛，调试效率高很多。
3. Bad Case 分析
收集失败案例，分类统计原因：
| 失败类型 | 数量 | 占比 | 优化方向 |
|---|---|---|---|
| 工具选错了 | 12 | 30% | 优化工具描述 |
| 参数填错了 | 8 | 20% | 优化参数说明 |
| 检索不相关 | 15 | 37.5% | 优化 RAG |
| 规划跑偏 | 5 | 12.5% | 优化系统提示词 |
针对性优化，效率最高。
4. 单步调试
把 Agent 拆开来测：
- 先测工具选择对不对
- 再测参数对不对
- 再测工具返回结果处理对不对
- 最后看整体
5. 固定种子
有些模型支持 seed 参数，固定了之后输出更稳定，调试的时候方便复现。
五、常见问题定位
问题 1：回答不对，是幻觉
定位：看有没有调用检索工具？检索到的内容对不对？模型有没有照着资料答？
可能原因：
- 没调用检索工具，模型自己瞎答 → 优化系统提示词，强制检索
- 检索了但内容不相关 → 优化 RAG 质量
- 检索到了但模型不用 → 加强 prompt 约束，要求引用来源
问题 2：工具选不对
定位：看 Thought 是怎么想的，为什么选了这个工具。
可能原因：
- 工具描述不清楚 → 改写 description，更明确
- 工具太多，模型混淆了 → 减少工具数量，合并相似工具
- 系统提示词没说清楚什么时候用什么 → 补充使用说明
问题 3：工具参数填错
定位：看 Action Input 里的参数。
可能原因：
- 参数描述不清楚 → 补充参数说明和例子
- 参数格式没说清 → 明确格式要求（日期格式、单位等）
- 模型能力不够 → 换更强的模型，或者加参数校验后重试
问题 4：死循环，反复调用同一个工具
定位：看 Observation 返回了什么，模型为什么一直调。
可能原因：
- 工具返回结果模型理解不了 → 优化返回格式，更清晰
- 模型判断不了什么时候该停 → prompt 里强调信息足够就给答案
- 工具返回错误，模型不知道怎么处理 → 错误信息写清楚，告诉它怎么修正
问题 5：步数太多，效率低
定位：看每一步都在干嘛，有没有多余步骤。
可能原因：
- 规划不好，绕路了 → 优化规划能力
- 一次只调一个工具，其实可以并行 → 开并行工具调用
- 工具返回信息太少，要多次查 → 优化工具返回更多信息
问题 6：上下文溢出
定位：看 token 使用量，是不是接近上限了。
可能原因：
- 历史太长 → 加摘要、滑动窗口
- 工具返回结果太长 → 截断、摘要
- 步数太多 → 优化效率，减少步数
六、优化优先级建议
第一步：先把基础做对
- 工具描述写清楚
- 系统提示词完整
- 参数校验加上
- 错误处理做好
基础不牢，后面优化都是白搭。
第二步：优化 RAG 质量
如果 Agent 主要靠知识库，RAG 质量就是瓶颈。先把检索准确率提上去。
第三步：优化工具选择
工具选错了，后面全白搭。工具描述、工具数量、使用说明都要打磨。
第四步：优化规划和效率
基础都对了，再优化步数、成本、速度。
第五步：持续 Bad Case 迭代
上线后收集失败案例，每周分析优化，逐步提升。
七、评估工具推荐
LangSmith
LangChain 官方的调试监控平台，能看每一步的输入输出、token、耗时，非常好用。
Langfuse
开源的 LLM 应用观测平台，支持追踪、评估、成本统计。
Helicone
专注 OpenAI 的监控和分析工具。
PromptLayer
也是 LLM 请求记录和调试工具。
自研
简单场景自己打日志存数据库也行，核心是能回看每一步。
八、本篇小结
- Agent 评估比普通问答难，因为多步骤、多维度、非确定性
- 评估维度：结果正确性、过程质量、效率成本、鲁棒性、安全性
- 评估方法：人工评估（最准）、自动评测集（可回归）、LLM打分（折中）、端到端成功率、单组件评估
- 调试方法：详细日志、过程可视化、Bad Case 分析、单步调试、固定种子复现
- 常见问题：幻觉（RAG相关）、工具选错、参数错、死循环、步数多、上下文溢出
- 优化顺序：先基础做对 → 再优化RAG → 再工具选择 → 再效率成本 → 持续Bad Case迭代
- 调试工具：LangSmith、Langfuse、Helicone 等，能大大提升调试效率
下一篇讲安全与可控性：Agent 输出怎么校验、权限怎么控制、怎么防止越权操作。
我是黒漂技术佬。
