1. 为什么“感觉还行”是AI Agent评估里最危险的信号做AI Agent开发的人几乎都经历过这样一个阶段Demo跑通了几个典型case表现不错团队里传阅一圈大家都说“挺智能的”然后就准备上线了。结果真实用户一进来各种离谱的失败模式全冒出来了——该调用工具的时候在胡说八道该追问澄清的时候自作主张多轮对话到第三轮就忘了前面说过什么。问题出在哪出在“感觉还行”这四个字上。AI Agent和传统软件最大的区别在于它的行为空间是开放的。传统函数你输入A它返回B测试用例覆盖到了就基本稳了。但Agent面对的是自然语言的模糊性、工具调用的不确定性、多步推理的累积误差以及环境状态的动态变化。你用几个手挑的case去评估它本质上是在用“幸存者偏差”安慰自己。2026年这个时间节点业界对Agent评估的共识已经比较清晰了评估不是一个阶段而是一条流水线。它至少包含四个层次——单步能力评估、轨迹级评估、端到端任务评估、以及在线生产环境评估。缺了任何一层你看到的都只是局部真相。这篇文章想做的事情很具体把Agent评估这件事从“跑个benchmark看分数”的认知水平拉高到“建立一套可持续运转的评估体系”的工程水平。不管你现在是在用LangGraph搭多智能体系统还是在用扣子这类平台做应用编排或者基于Spring AI做企业级Agent下面这些内容都能直接对应到你的日常工作上。先给一个判断标准如果你的Agent评估只依赖一个benchmark的总分那你的评估基本等于没做。原因后面会展开讲但你可以先记住这个结论。2. 拆开看Agent评估到底在评什么2.1 从“最终答案对不对”到“每一步走得合不合理”传统模型评估的核心问题是“输出对不对”。分类任务看准确率生成任务看BLEU、ROUGE或者现在的LLM-as-Judge打分。这套逻辑搬到Agent上立刻就不够用了。举个具体例子。你让Agent帮用户查“上周北京飞上海最便宜的航班并且帮我订一个靠窗座位”。Agent最终确实给出了一个航班号和座位确认用户说“谢谢”。从最终结果看任务完成了。但如果你把中间轨迹拉出来看第一步Agent直接调用了订票API没有先搜索航班列表第二步订票API返回错误因为缺少航班ID参数第三步Agent重新搜索航班拿到列表第四步Agent选了一个航班但选的是“最便宜”而不是“时间最合适”第五步订座成功最终结果是“完成”了但中间有一次无效API调用、一次决策偏差。如果用户的需求是“最便宜”那第四步其实是对的但如果用户隐含需求是“时间合理且价格适中”那Agent的决策就偏了。这些信息只看最终答案是完全看不到的。所以Agent评估的第一个认知升级是评估对象从“输出”变成了“轨迹”。轨迹里包含了工具选择、参数构造、推理步骤、状态转移、错误恢复等一整套行为序列。你需要评估的是这个序列的质量而不仅仅是终点的对错。2.2 四个评估层次的实际含义我把Agent评估拆成四个层次每个层次解决的问题不同用的方法和工具也不同。第一层单步能力评估。这是最细粒度的评估看的是Agent在单个决策点上的表现。比如给定当前对话历史和可用工具列表Agent是否选择了正确的工具工具参数是否构造正确推理链是否逻辑自洽这一层通常用构造好的测试集来做每个测试用例聚焦一个决策点。好处是定位问题精准坏处是构造成本高而且单步对不代表整体对。第二层轨迹级评估。把一次完整任务执行的所有步骤串起来看。关注的是步骤之间是否连贯有没有冗余调用错误恢复是否合理是否出现了“绕远路”的情况这一层的评估往往需要定义一套轨迹质量指标比如步骤效率、工具调用准确率、推理一致性等。第三层端到端任务评估。这是最接近用户感知的评估。给定一个任务描述看Agent最终是否完成了任务完成质量如何。这一层通常用任务成功率、用户满意度、任务完成时间等指标。但要注意端到端成功不代表过程没问题所以它必须和轨迹级评估配合使用。第四层在线生产环境评估。这是最真实但也最复杂的评估。Agent上线后面对的是真实用户的千奇百怪的需求。你需要通过日志分析、用户反馈、A/B测试、影子模式等手段来持续评估。这一层的挑战在于没有标准答案而且分布会漂移。四个层次的关系可以这样理解单步评估告诉你“零件好不好”轨迹评估告诉你“装配工艺对不对”端到端评估告诉你“产品能不能用”在线评估告诉你“用户满不满意”。缺任何一层你的评估体系都是有盲区的。2.3 一个常见的误区把Benchmark当成绩单现在市面上有不少Agent相关的benchmark比如AgentBench、ToolBench、WebArena等等。这些benchmark有价值吗有但它们的作用是“横向对比”和“基线参考”不是“你的Agent好不好用”的最终答案。原因很简单benchmark的任务分布是固定的而你的用户需求分布是独特的。你在某个benchmark上拿了高分只能说明你的Agent在那类任务上表现不错不能说明它在你的业务场景里表现好。更危险的是有些团队会针对benchmark做“过拟合”——专门优化benchmark里出现的任务类型结果上线后遇到真实用户就崩了。我的建议是benchmark用来做技术选型和版本对比但不要用它来替代你自己的评估集。你自己的评估集必须来自真实业务场景哪怕规模小一点也比benchmark更有参考价值。3. 构建评估集的实操路径从零到可持续运转3.1 评估集从哪来三条获取渠道的优先级排序评估集的质量直接决定评估结果的可信度。我见过太多团队在这件事上偷懒——随便找几个同事写几条测试用例然后就当成评估集用了。结果评估分数很好看上线后一塌糊涂。正确的做法是建立三条获取渠道并按优先级排序第一优先级真实用户日志。这是最宝贵的评估数据来源。从生产环境里采样真实用户的请求覆盖不同的任务类型、不同的复杂度、不同的用户表达方式。如果Agent还没上线那就从客服记录、用户反馈、产品需求文档里提取真实场景。真实数据的价值在于它包含了你想不到的边缘case和表达变体。第二优先级领域专家构造。找对业务最熟悉的人让他们基于经验构造评估用例。这些人知道哪些场景容易出问题、哪些边界条件容易被忽略。专家构造的用例往往能覆盖到真实日志里暂时没出现但迟早会出现的情况。第三优先级合成数据。用LLM生成评估用例或者对现有用例做变体扩展。合成数据的优势是成本低、速度快但劣势是可能引入分布偏差。我的经验是合成数据可以用来扩充评估集的多样性但不能作为主要来源。三条渠道的配比我一般建议是5:3:2或者6:2:2。真实数据占大头专家数据做补充合成数据做扩展。3.2 评估用例的结构化设计一条好的评估用例不是简单的一句“帮我查天气”。它应该包含以下结构化信息任务描述用户原始请求保留真实表达期望行为Agent应该做什么不应该做什么可用工具这个场景下Agent能调用的工具列表成功标准怎样算成功怎样算部分成功怎样算失败难度标签简单、中等、困难场景标签属于哪类任务查询、操作、推理、多轮对话等陷阱标记这个用例里有没有故意设置的坑比如模糊指令、矛盾信息、工具不可用等这样结构化的好处是评估结果可以按维度切片分析。比如你可以很快看出“Agent在模糊指令下的表现明显差于明确指令”或者“多轮对话场景的成功率比单轮低20%”。这些洞察比一个总分有价值得多。3.3 评估集的规模与迭代节奏规模上我的经验是起步阶段100-200条稳定运行后500-1000条。少于100条统计意义太弱多于1000条维护成本太高而且边际收益递减。更重要的是迭代节奏。评估集不是建好就放在那儿的它需要跟着业务一起进化。我建议的节奏是每周从生产日志里采样新的失败case补充到评估集每月回顾评估集删除过时的用例调整难度分布每季度做一次全面审视确保评估集和当前业务重点对齐这里有个容易忽略的点评估集里要保留一定比例的“历史失败case”。这些case是Agent曾经踩过的坑保留它们可以防止回归。每次Agent更新后先跑一遍历史失败case确保没有“旧病复发”。3.4 一个容易踩的坑评估集泄露这是我在实际项目中见过的最隐蔽的问题之一。简单说就是开发团队在优化Agent时直接针对评估集里的case做调整导致评估分数虚高但泛化能力没提升。避免评估集泄露的方法有几个评估集和开发集分离开发时用的调试case和最终评估用的case必须是两套定期更换评估集每隔一段时间用新的真实数据替换一部分旧用例监控评估分数和线上指标的相关性如果评估分数涨了但线上指标没动很可能就是泄露了4. 工具选型DeepEval、RAGAS这些框架到底怎么选4.1 评估框架的能力矩阵现在市面上的评估框架不少我挑几个有代表性的说一下它们各自适合什么场景。框架核心定位适合场景主要限制DeepEval通用LLM评估框架单步评估、轨迹评估对Agent特有指标支持一般RAGASRAG系统评估检索增强生成场景偏RAGAgent场景覆盖有限LangSmith全链路可观测评估基于LangChain/LangGraph的Agent和LangChain生态绑定较深自建评估流水线完全定制有特殊评估需求的团队开发和维护成本高选型的时候不要追求“最强大”要追求“最匹配”。如果你的Agent是基于LangGraph搭的LangSmith的集成度最好上手最快。如果你需要评估RAG部分的质量RAGAS的指标设计更专业。如果你需要高度定制的评估逻辑自建流水线虽然成本高但最灵活。4.2 LLM-as-Judge的正确打开方式用LLM来评估LLM的输出这已经是业界标配了。但LLM-as-Judge有个很大的问题它本身也会犯错而且它的错误模式和你评估的Agent的错误模式可能不一样。我见过一个团队用GPT-4做Judge评估一个基于开源模型的Agent。结果Judge给出的分数普遍偏高因为GPT-4倾向于“理解”Agent的输出意图即使输出本身有瑕疵。这就导致评估结果失真。正确使用LLM-as-Judge的方法用多个Judge模型不要只用一个模型做Judge用2-3个不同来源的模型交叉验证设计详细的评分标准不要只给一个“好/中/差”的选项要给出具体的评分维度和每个维度的描述定期人工校准每隔一段时间人工抽检一批Judge的评分结果看是否和人类判断一致保留Judge的推理过程让Judge输出评分理由方便排查异常评分4.3 人工评估不可替代的场景虽然自动化评估效率高但有些场景必须人工介入主观质量评估比如Agent的回复语气是否合适、是否得体复杂推理验证多步推理的中间步骤是否正确自动化很难判断边缘case发现人工评估往往能发现自动化评估漏掉的问题评估标准校准自动化评估的标准需要人工来定义和调整我的建议是自动化评估做日常回归人工评估做定期深度检查。比例大概是9:1或者8:2。5. 错误分析从失败case里挖出真正的改进点5.1 错误分类体系怎么建错误分析是评估体系里最容易被忽视但价值最高的环节。很多团队跑完评估看到分数不理想就开始盲目调prompt、换模型、加工具。这种“病急乱投医”的做法效率极低。正确的做法是先建立错误分类体系。我一般把Agent的错误分成以下几大类第一类理解错误。Agent没有正确理解用户意图。细分包括意图识别错误、实体提取错误、上下文理解错误、模糊指令处理不当等。第二类规划错误。Agent理解了意图但任务分解或步骤规划有问题。细分包括步骤遗漏、步骤顺序错误、冗余步骤、子任务划分不合理等。第三类工具使用错误。Agent在调用工具时出错。细分包括工具选择错误、参数构造错误、工具返回结果解析错误、工具不可用时的处理不当等。第四类推理错误。Agent在推理过程中出错。细分包括逻辑跳跃、事实性错误、数学计算错误、多步推理累积误差等。第五类输出错误。Agent最终输出有问题。细分包括格式错误、信息遗漏、信息冗余、语气不当等。有了这套分类体系每次评估后你就能快速定位问题集中在哪个环节。如果80%的错误都是工具使用错误那你就知道该去优化工具描述和参数校验而不是去调prompt。5.2 从错误分布到改进优先级错误分类之后下一步是排优先级。不是所有错误都值得立刻修。我一般用两个维度来排影响面这个错误影响多少比例的用户请求严重度这个错误导致的后果有多严重把错误分到四个象限里高影响面低影响面高严重度立即修复尽快修复低严重度排期修复观察即可比如“工具选择错误”如果影响面大且严重度高比如订错了航班那就必须立即修。而“输出语气偶尔不够礼貌”如果影响面小且严重度低就可以先放一放。5.3 一个真实的排查链路示例说一个我实际遇到过的case。有个Agent在“查询订单状态”这个任务上成功率只有60%远低于其他任务。按照错误分类体系我先看错误分布理解错误5%规划错误10%工具使用错误70%推理错误10%输出错误5%问题明显集中在工具使用上。进一步看工具使用的错误细分工具选择错误10%参数构造错误80%结果解析错误10%参数构造错误占了绝对大头。把具体的错误case拉出来看发现大部分是订单号格式问题。用户输入的订单号有时候带空格、有时候带横线、有时候大小写混用而Agent在构造API参数时没有做规范化处理。修复方案就很明确了在工具调用前加一层参数预处理对订单号做标准化。改完之后这个任务的成功率从60%提到了92%。这个例子的价值在于如果你不建错误分类体系你可能会以为是Agent“不够聪明”然后去换更大的模型成本高且不一定有效。但有了分类体系你就能精准定位到是一个参数预处理的问题修复成本极低。6. 把评估嵌进开发流程持续评估的工程化落地6.1 CI/CD里的评估门禁评估不应该是一个独立的活动它应该嵌到开发流程里。我的做法是在CI/CD流水线里加一道“评估门禁”每次代码合并前自动跑一遍核心评估集如果核心指标下降超过阈值比如成功率下降超过3%阻止合并如果核心指标持平或提升允许合并但记录评估报告这样做的效果是评估从“事后检查”变成了“事前预防”。开发者在提交代码前就知道自己的改动有没有引入回归。6.2 线上监控与离线评估的闭环离线评估再全面也覆盖不了线上环境的全部情况。所以必须建立线上监控和离线评估的闭环线上监控发现异常case → 采样后加入评估集 → 离线评估复现问题 → 修复后离线验证 → 上线后线上验证这个闭环跑通之后你的评估体系就有了自我进化的能力。评估集越来越贴近真实场景Agent的表现也越来越稳。6.3 评估报告怎么写才有决策价值最后说一个实操细节评估报告怎么写。我见过很多评估报告密密麻麻全是数字但看完不知道要干什么。好的评估报告应该回答三个问题当前Agent的整体表现如何用核心指标趋势图回答主要问题在哪里用错误分类典型case回答下一步该做什么用改进优先级预期收益回答报告不用长一页纸能说清楚最好。关键是要有决策价值而不是数据堆砌。7. 一些踩过坑之后才明白的事说几个我在实际项目中踩过的坑都是文档里不会写的。第一个坑评估集建得太“干净”。一开始我构造评估用例的时候总是不自觉地把用户输入写得很规范、很明确。结果Agent在评估集上表现很好上线后遇到真实用户的模糊表达就崩了。后来我强制要求评估集里至少30%的用例要包含模糊表达、错别字、口语化表达、甚至矛盾信息。第二个坑只看总分不看分布。有段时间我特别关注Agent的整体成功率从70%涨到75%就很开心。后来把评估结果按场景切片一看发现“查询类”任务成功率90%“操作类”任务成功率只有50%。整体涨了5%是因为查询类任务涨了10%操作类其实没动。如果早点看分布就能更早发现操作类任务的问题。第三个坑用评估分数做唯一决策依据。有一次两个版本的AgentA版本评估分数高2%但B版本在几个关键场景上表现更好。如果只看总分就选A了但实际上B更适合业务需求。后来我养成了一个习惯评估分数是参考关键场景的表现才是决策依据。第四个坑忽略评估本身的成本。评估是要花钱的——LLM-as-Judge要调API人工评估要花时间评估集的维护也要投入。一开始我没算这笔账后来发现评估成本占了整个项目预算的15%。所以评估体系的设计也要考虑ROI不是越复杂越好。第五个坑评估和开发脱节。最开始的时候评估是单独一个团队在做开发是另一个团队。结果评估团队报了一堆问题开发团队觉得“这些case不真实”“用户不会这么用”。后来我把评估和开发放在同一个团队里评估人员参与开发讨论开发人员参与评估集构造问题就少了很多。8. 关于Agent评估我现在的几个基本判断写到这里分享几个我目前对Agent评估的基本判断不一定对但都是实际做下来形成的认知。判断一评估的粒度会越来越细。现在很多团队还在做端到端评估但未来一定会往轨迹级、甚至单步级走。因为端到端评估只能告诉你“好不好”不能告诉你“哪里不好”。而Agent的优化恰恰需要知道“哪里不好”。判断二评估会从“离线”走向“在线”。离线评估是必要的但不够。真实用户的行为分布是动态变化的离线评估集永远滞后。未来的评估体系一定是离线和在线结合的甚至以在线为主。判断三评估的自动化程度会越来越高但人工不会消失。LLM-as-Judge会越来越强自动化评估的覆盖面会越来越广。但人工评估会转向更高价值的工作——定义评估标准、校准自动化评估、发现新的失败模式。判断四评估会成为Agent开发的核心竞争力。当大家的模型能力都差不多的时候谁能更快地发现和修复问题谁就能做出更好的Agent。而发现和修复问题的能力本质上就是评估能力。最后说一个我经常用的检验标准如果你的Agent评估体系不能在一个小时内告诉你“这次改动有没有让Agent变好”那你的评估体系就还没建好。这个标准很粗暴但很实用。