评估与调试Agent 效果怎么衡量Agent 比普通对话模型难评估得多因为涉及多步推理、工具调用、长任务执行。这篇讲 Agent 的评估维度、评估方法、调试技巧以及怎么定位和优化常见问题。大家好我是黒漂技术佬。普通大模型问答看回答对不对就行。Agent 复杂多了规划对不对、工具选得对不对、参数对不对、结果准不准、用了多少步、花了多少钱……Agent 难评估也难调试因为中间步骤多出问题不知道是哪一步错了。这篇讲 Agent 怎么评估、怎么调试、常见问题怎么定位。一、为什么 Agent 难评估对比普通问答普通问答Agent单轮输入输出多轮循环、多步骤只看最终答案还要看过程对不对评估维度单一维度多正确率、步数、成本、工具准确率容易做评测集评测集难做任务多样Agent 评估的难点过程也很重要答案对了但过程瞎蒙的下次可能就错了任务多样性不同任务差异大很难一套指标通吃非确定性同样的输入每次结果可能不一样长任务难评估步骤多中间错了一步可能最后还蒙对了成本高跑一次评测要调用很多次模型二、评估维度1. 结果正确性最终效果最终答案对不对有没有解决用户问题。正确率答对的比例完整性有没有遗漏关键点相关性有没有答非所问事实准确性有没有幻觉、编造信息2. 过程质量执行过程好不好路径对不对。工具调用准确率该调用的工具选对了吗参数正确率工具参数填对了吗步数效率用了多少步完成是不是最优路径规划合理性任务拆解合不合理有没有多余步骤是不是绕路了3. 效率与成本总 token 消耗花了多少钱执行时间用户等了多久工具调用次数调用了多少次工具平均步数完成一个任务平均几轮4. 鲁棒性稳不稳定异常情况能不能处理。容错率工具报错了能不能调整异常处理遇到意外情况会不会崩一致性同样的问题多次执行结果差多少5. 安全与可控性会不会调用不该用的工具有没有越权操作输出有没有有害内容三、评估方法方法 1人工评估人来打分最准确但最贵最慢。怎么做准备一批测试用例跑 Agent 得到结果包括过程人按维度打分优点最准确能评估主观质量缺点慢、贵、不可持续、人也会有偏差适用核心场景的抽样评估、最终上线前验收方法 2自动评测集准备一批有标准答案的测试题自动跑自动判分。怎么做测试集 [ {question: 北京今天天气, expected_answer: 包含温度和天气状况, expected_tools: [weather]}, ... ]自动跑每个问题检查最终答案是否正确可以用模型打分调用的工具对不对步数是否在合理范围优点可重复、快、能持续跑缺点测试集制作成本高覆盖不了所有场景适用回归测试每次改代码跑一遍看有没有退步方法 3LLM 打分用另一个大模型当评委给 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 的 LangSmithLangfuse自己做个简单的前端展示能看到每一步在干嘛调试效率高很多。3. Bad Case 分析收集失败案例分类统计原因失败类型数量占比优化方向工具选错了1230%优化工具描述参数填错了820%优化参数说明检索不相关1537.5%优化 RAG规划跑偏512.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 迭代上线后收集失败案例每周分析优化逐步提升。七、评估工具推荐LangSmithLangChain 官方的调试监控平台能看每一步的输入输出、token、耗时非常好用。Langfuse开源的 LLM 应用观测平台支持追踪、评估、成本统计。Helicone专注 OpenAI 的监控和分析工具。PromptLayer也是 LLM 请求记录和调试工具。自研简单场景自己打日志存数据库也行核心是能回看每一步。八、本篇小结Agent 评估比普通问答难因为多步骤、多维度、非确定性评估维度结果正确性、过程质量、效率成本、鲁棒性、安全性评估方法人工评估最准、自动评测集可回归、LLM打分折中、端到端成功率、单组件评估调试方法详细日志、过程可视化、Bad Case 分析、单步调试、固定种子复现常见问题幻觉RAG相关、工具选错、参数错、死循环、步数多、上下文溢出优化顺序先基础做对 → 再优化RAG → 再工具选择 → 再效率成本 → 持续Bad Case迭代调试工具LangSmith、Langfuse、Helicone 等能大大提升调试效率下一篇讲安全与可控性Agent 输出怎么校验、权限怎么控制、怎么防止越权操作。我是黒漂技术佬。
评估与调试Agent 效果怎么衡量Agent 比普通对话模型难评估得多因为涉及多步推理、工具调用、长任务执行。这篇讲 Agent 的评估维度、评估方法、调试技巧以及怎么定位和优化常见问题。大家好我是黒漂技术佬。普通大模型问答看回答对不对就行。Agent 复杂多了规划对不对、工具选得对不对、参数对不对、结果准不准、用了多少步、花了多少钱……Agent 难评估也难调试因为中间步骤多出问题不知道是哪一步错了。这篇讲 Agent 怎么评估、怎么调试、常见问题怎么定位。一、为什么 Agent 难评估对比普通问答普通问答Agent单轮输入输出多轮循环、多步骤只看最终答案还要看过程对不对评估维度单一维度多正确率、步数、成本、工具准确率容易做评测集评测集难做任务多样Agent 评估的难点过程也很重要答案对了但过程瞎蒙的下次可能就错了任务多样性不同任务差异大很难一套指标通吃非确定性同样的输入每次结果可能不一样长任务难评估步骤多中间错了一步可能最后还蒙对了成本高跑一次评测要调用很多次模型二、评估维度1. 结果正确性最终效果最终答案对不对有没有解决用户问题。正确率答对的比例完整性有没有遗漏关键点相关性有没有答非所问事实准确性有没有幻觉、编造信息2. 过程质量执行过程好不好路径对不对。工具调用准确率该调用的工具选对了吗参数正确率工具参数填对了吗步数效率用了多少步完成是不是最优路径规划合理性任务拆解合不合理有没有多余步骤是不是绕路了3. 效率与成本总 token 消耗花了多少钱执行时间用户等了多久工具调用次数调用了多少次工具平均步数完成一个任务平均几轮4. 鲁棒性稳不稳定异常情况能不能处理。容错率工具报错了能不能调整异常处理遇到意外情况会不会崩一致性同样的问题多次执行结果差多少5. 安全与可控性会不会调用不该用的工具有没有越权操作输出有没有有害内容三、评估方法方法 1人工评估人来打分最准确但最贵最慢。怎么做准备一批测试用例跑 Agent 得到结果包括过程人按维度打分优点最准确能评估主观质量缺点慢、贵、不可持续、人也会有偏差适用核心场景的抽样评估、最终上线前验收方法 2自动评测集准备一批有标准答案的测试题自动跑自动判分。怎么做测试集 [ {question: 北京今天天气, expected_answer: 包含温度和天气状况, expected_tools: [weather]}, ... ]自动跑每个问题检查最终答案是否正确可以用模型打分调用的工具对不对步数是否在合理范围优点可重复、快、能持续跑缺点测试集制作成本高覆盖不了所有场景适用回归测试每次改代码跑一遍看有没有退步方法 3LLM 打分用另一个大模型当评委给 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 的 LangSmithLangfuse自己做个简单的前端展示能看到每一步在干嘛调试效率高很多。3. Bad Case 分析收集失败案例分类统计原因失败类型数量占比优化方向工具选错了1230%优化工具描述参数填错了820%优化参数说明检索不相关1537.5%优化 RAG规划跑偏512.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 迭代上线后收集失败案例每周分析优化逐步提升。七、评估工具推荐LangSmithLangChain 官方的调试监控平台能看每一步的输入输出、token、耗时非常好用。Langfuse开源的 LLM 应用观测平台支持追踪、评估、成本统计。Helicone专注 OpenAI 的监控和分析工具。PromptLayer也是 LLM 请求记录和调试工具。自研简单场景自己打日志存数据库也行核心是能回看每一步。八、本篇小结Agent 评估比普通问答难因为多步骤、多维度、非确定性评估维度结果正确性、过程质量、效率成本、鲁棒性、安全性评估方法人工评估最准、自动评测集可回归、LLM打分折中、端到端成功率、单组件评估调试方法详细日志、过程可视化、Bad Case 分析、单步调试、固定种子复现常见问题幻觉RAG相关、工具选错、参数错、死循环、步数多、上下文溢出优化顺序先基础做对 → 再优化RAG → 再工具选择 → 再效率成本 → 持续Bad Case迭代调试工具LangSmith、Langfuse、Helicone 等能大大提升调试效率下一篇讲安全与可控性Agent 输出怎么校验、权限怎么控制、怎么防止越权操作。我是黒漂技术佬。
双梁正问题 【 torch 实战】（Python代码实现）)
