1. 从“确定性”到“涌现性”Agent评测的本质挑战最近和几个做AI应用落地的朋友聊天大家不约而同地都在吐槽同一个问题给Agent做评测简直比给传统软件做测试难上一个数量级。这感觉就像以前你测试一个计算器按“11”它必须输出“2”错了就是bug但现在你测试的是一个“实习生”你问它“11等于几”它可能先跟你探讨一番数学哲学然后告诉你“在大多数情况下等于2但在某些模运算或特定语境下可能有其他含义”。你没法直接判它错但离你想要的“2”这个确定答案又差了那么点意思。这就是Agent评测的核心困境评测对象从“确定性程序”变成了“具有涌现能力的智能体”。传统软件测试无论是单元测试、集成测试还是系统测试其基石是“确定性输入-输出”映射。给定相同的输入和环境程序的执行路径和输出结果必须是完全可预测、可重复的。我们评测的是代码的逻辑正确性。而基于大语言模型LLM构建的Agent其核心能力来源于模型的“涌现性”和“概率性”。它没有固定的执行路径每次调用都可能因为模型本身的随机性如temperature参数、上下文prompt的细微差异、甚至外部工具调用的状态而产生不同的推理过程和输出结果。我们评测的是智能体的任务完成度和决策合理性。这个根本性的转变带来了评测维度、方法、标准和成本的全方位升级。传统测试像是在检查一台精密钟表的每个齿轮是否啮合准确而Agent评测则像是在评估一个策略顾问的临场表现、知识广度、逻辑严谨性和沟通有效性。后者显然要复杂、主观且昂贵得多。接下来我们就从几个关键维度拆解这“难10倍”究竟难在哪里。2. 评测维度的爆炸从功能正确到综合智能传统测试的维度相对清晰主要围绕“功能”展开。我们关心的是这个功能点实现了没有边界条件处理了吗性能达标了吗安全漏洞有吗这些维度大多可以量化例如通过/失败的测试用例数、响应时间毫秒数、CPU占用率百分比。Agent的评测维度则呈现指数级扩张因为它模拟的是“人”在复杂环境中的综合能力。我们可以将其粗略分为几个层面2.1 任务执行层效果、效率与可靠性这是最接近传统功能测试的部分但内涵已大不相同。任务完成度Success Rate这是最核心的指标。Agent是否理解了任务Intent Understanding它最终是否输出了用户期望的结果或完成了用户期望的操作例如一个数据分析Agent用户问“帮我找出上个月销售额最高的产品”Agent是否准确输出了产品名称和销售额这里又细分为硬性完成输出完全符合标准答案。在简单、封闭任务中可能实现。软性完成输出答案在语义上正确但表述不同。例如标准答案是“产品A销售额100万”Agent回答“销售额冠军是产品A达到了100万元”这通常也被认为是成功的。部分完成只完成了任务的一部分或答案包含错误信息。评估“完成度”本身就需要定义复杂的匹配规则从简单的字符串匹配到基于嵌入向量的语义相似度计算再到使用另一个LLM作为裁判LLM-as-a-Judge进行评分成本陡增。执行效率EfficiencyAgent用了多少步推理步骤或工具调用次数完成任务消耗了多少Token直接关联成本耗时多长一个虽然能完成任务但绕了巨大弯路、调用十几次无关工具的Agent显然是不高效的。可靠性Reliability在相同的提示词Prompt和环境下多次运行Agent其输出结果的一致性如何一个波动巨大的Agent无法用于生产环境。此外还包括对异常输入模糊、错误、对抗性提示的鲁棒性。2.2 认知与决策层思维过程的可解释与合理性这是传统测试几乎不涉及的领域却是Agent智能的核心。推理链的合理性Reasoning ChainAgent的思考过程Chain-of-Thought是否逻辑自洽是否避免了事实错误和逻辑谬误例如在回答一个数学问题时它的演算步骤是否正确这部分评测往往需要“白盒化”即要求Agent输出其中间推理步骤但这又会增加复杂度和可能的信息泄露风险。规划与工具使用能力Planning Tool Use对于复杂任务Agent是否能将其分解为合理的子任务Planning是否能正确选择并调用合适的工具如计算器、搜索引擎、API调用工具时的参数是否准确例如用户让Agent“查一下北京明天飞上海的航班并选一个下午出发、价格低于1000元的”Agent需要规划1调用搜索工具获取航班列表2调用过滤或计算工具筛选时间和价格3组织结果并回复。其中任何一步规划错误或工具调用失败都会导致任务失败。知识运用与事实准确性Knowledge FactualityAgent的回答是否基于准确的事实是否会产生“幻觉”Hallucination即编造看似合理但完全不存在的信息这是LLM的固有问题也是评测的重点和难点。2.3 交互与安全层对话体验与风险控制Agent通常以对话形式交互这引入了人机交互HCI和安全方面的维度。交互流畅性Interaction FluencyAgent的回复是否自然、连贯、符合上下文是否会出现答非所问、重复或突然中断对话的情况安全性Safety与合规性这是高压红线。评测需要覆盖提示词注入Prompt Injection防止用户通过精心构造的输入诱导Agent突破系统设定的限制执行非法或越权操作。越狱Jailbreak防止用户绕过模型的安全对齐机制使其生成有害、偏见、歧视性或违法内容。信息泄露防止Agent在对话中泄露其系统提示词、内部指令或训练数据中的敏感信息。价值观对齐输出内容是否符合伦理道德和社会公序良俗。 这类评测往往需要构建大量的对抗性测试用例并需要人工进行敏感、细致的审核成本极高。3. 评测方法的困境自动化之难与人工评估之贵面对如此多维度的评测需求传统软件测试中成熟的自动化测试框架如xUnit, Selenium几乎失灵。我们不得不探索新的方法并面临新的取舍。3.1 自动化评测的探索与局限目前自动化评测Agent主要依靠以下几种方式但各有局限基于规则的匹配Rule-based适用于输出结构固定、答案封闭的场景。例如测试一个计算器Agent可以断言其输出是否与标准计算结果匹配。但对于开放域问答规则很难制定。基于模型的评估Model-based Evaluation这是当前的主流研究方向尤其是使用“LLM-as-a-Judge”即用一个通常更强的LLM作为裁判来评估目标Agent的输出。具体做法是将任务描述、Agent输出、有时还包括参考标准答案一起构成一个提示词让裁判LLM从特定维度如相关性、准确性、有帮助性进行打分或比较。优点灵活能处理开放域问题一定程度上模拟了人类判断。缺点成本高每次评估都是一次LLM API调用大规模测试下费用不菲。裁判本身不可靠裁判LLM也有自己的偏差、幻觉和不稳定性。可能出现“盲人领盲人”的情况。评分一致性同样的输出不同裁判模型甚至同一模型不同时间给出的分数可能有波动。维度局限很难用这种方法评估工具调用的正确性、执行效率等非文本维度。端到端集成测试将Agent部署到一个模拟或真实的环境中运行一系列测试工作流Workflow检查最终的业务状态是否达到预期。例如测试一个电商客服Agent模拟用户从咨询、下单到退货的全流程检查订单系统、库存系统的状态变更是否正确。这种方法最贴近真实场景但搭建复杂的模拟环境成本极高且测试用例的设计覆盖度挑战巨大。3.2 人工评估黄金标准与成本黑洞在目前阶段对于关键任务、复杂任务或涉及安全、价值观的评估人工评估仍然是不可替代的“黄金标准”。人类评估者能理解细微的语境、判断逻辑的严谨性、感知交互的自然度这是任何自动化方法难以完全替代的。 然而人工评估的代价是巨大的金钱成本聘请和培训专业的评估人员通常需要领域知识费用高昂。时间成本评估耗时无法支持快速的迭代开发如一天多次的DevOps流程。一致性问题不同评估者之间可能存在主观差异需要制定详细的评估指南并进行校准这本身又是一项复杂工作。可扩展性差难以应对海量测试用例的评估需求。因此一个现实的Agent评测体系往往是自动化评测与人工评估的混合。用自动化方法覆盖回归测试、冒烟测试和大量简单场景用人工评估聚焦于核心场景、复杂逻辑和安全审查。如何设计这个混合策略的配比本身就是一项重要的工程决策。4. 基准测试的缺失寻找Agent领域的“ImageNet”在传统软件和机器学习领域我们有丰富的基准测试Benchmark来横向比较不同系统的能力。例如ImageNet之于计算机视觉GLUE/SuperGLUE之于自然语言理解。这些基准提供了标准化的数据集和评估指标让比较变得相对公平和高效。对于Agent尤其是通用任务Agent目前还缺乏公认的、权威的基准测试。现有的评测集往往聚焦于某个单一能力工具使用如ToolBench评估Agent调用API工具的能力。推理与数学如GSM8K、MATH但这类数据集通常直接测试LLM而非嵌入了规划、工具调用循环的完整Agent。代码生成与执行如HumanEval评估编码能力Code Interpreter类Agent可以在此测试。安全与对抗如Prompt Injection数据集、Jailbreak攻击集。真正的挑战在于如何构建一个能综合评估Agent“规划-推理-工具调用-执行-交互”全链条能力的基准。这样的基准需要复杂且真实的任务不是单一问答而是多步骤项目如“请为我策划一个三天的北京旅游行程并估算大致预算需要查询天气、交通和门票信息”。可配置的环境提供模拟的或真实可访问的工具集如搜索、计算、日历、文件操作API。可自动化的评估标准不仅看最终输出还要评估其执行过程是否合理、高效、安全。这需要为每个任务定义清晰的成功条件Success Criteria和评估函数Evaluation Function。一些框架如AgentBench、AutoGen的评估模块正在朝这个方向努力但离形成一个像ImageNet那样被广泛接受的行业标准还有很长的路要走。没有统一的基准就意味着每个团队都需要投入大量资源构建自己的评测体系和测试用例这是“难10倍”在基础设施层面的体现。5. 工程实践构建可持续的Agent评测流水线尽管困难重重但在工程实践中我们仍然需要建立一套尽可能高效、可靠的Agent评测体系。以下是一些可行的思路和注意事项5.1 分层评测聚焦核心不要试图用一个评测套件覆盖所有维度。建议分层进行单元测试层LLM Prompt层隔离测试核心LLM调用和Prompt模板。例如给定固定的Prompt和输入测试LLM输出的稳定性、是否包含敏感词。可以使用llm库或自定义脚本进行批量调用和规则检查。组件测试层Agent核心逻辑层测试Agent的规划逻辑、工具路由选择、状态管理等功能。可以模拟工具调用验证在给定输入和状态下Agent是否生成了正确的计划和工具调用请求。这部分的测试相对更“确定”可以借鉴传统单元测试。集成测试层端到端工作流层在模拟环境中运行完整的工作流。这是最复杂的一层重点测试多个Agent协作、长链条任务、异常处理等。需要精心设计测试场景和断言条件。人工验收层关键场景与安全层定期对核心用户场景、新上线的复杂功能以及随机抽样的交互进行人工评估确保体验和质量底线。5.2 善用“LLM-as-a-Judge”但保持警惕在集成测试和验收测试中可以大量采用LLM作为裁判进行自动化评分。实践中需要注意设计好的评分指令Rubric给裁判LLM的指令必须清晰、无歧义明确评分维度、分值和标准。例如“请从‘任务完成度’1-5分、‘回复有帮助性’1-5分两个维度评分。任务完成度标准5分-完全解决用户问题...1分-完全无关。”使用一致性更高的裁判模型目前GPT-4-Turbo、Claude-3-Opus等顶级模型在作为裁判时表现相对更稳定。虽然成本高但对于关键评测值得投入。设置参考基准与校准不要只看绝对分数。每次评测时加入一些已知质量的“锚点”样本如人工标注为优、中、差的回答观察裁判模型对这些锚点的评分是否稳定以监控裁判模型本身的波动。结合其他信号不要完全依赖LLM裁判的分数。将其与执行步数、耗时、工具调用成功率等客观指标结合进行综合判断。5.3 构建高质量的测试用例库测试用例的质量直接决定评测的有效性。来源多样化从真实用户日志中抽取高频、典型的查询设计边缘案例和对抗性案例覆盖所有已集成的工具和功能。标注丰富的元数据为每个测试用例标注其测试目标如测试工具调用、测试长上下文理解、测试抗注入能力、难度等级、所属领域等便于分类管理和分析。持续维护与更新随着Agent能力的迭代和用户需求的变化测试用例库需要不断补充和更新。这是一个活的资产。5.4 监控线上表现闭环反馈线下评测再完善也无法完全模拟线上真实环境的复杂性和多样性。因此必须建立强大的线上监控体系关键指标监控如任务完成率可通过用户反馈、后续行为推断、平均会话轮次、工具调用错误率、API延迟与成本。用户反馈收集提供便捷的“点赞/点踩”或反馈入口将用户明确标记为不满意的会话自动纳入测试用例库进行回归测试。根因分析RCA当线上出现bad case时能快速回溯Agent的完整思维链和工具调用记录定位问题是出在Prompt设计、工具能力、模型理解还是其他环节。Agent评测的“难”本质上是智能体复杂性对传统质量保障体系的降维打击。它要求测试工程师、算法工程师和产品经理更紧密地协作从思维上接受不确定性在方法上融合自动化与人工在工程上构建分层、迭代的评估系统。这条路没有银弹唯有深入理解Agent的工作原理紧密结合业务场景持续投入和优化才能在智能体时代守住产品质量的生命线。 从确定性测试到智能体评估：Agent评测的维度、方法与工程实践
1. 从“确定性”到“涌现性”Agent评测的本质挑战最近和几个做AI应用落地的朋友聊天大家不约而同地都在吐槽同一个问题给Agent做评测简直比给传统软件做测试难上一个数量级。这感觉就像以前你测试一个计算器按“11”它必须输出“2”错了就是bug但现在你测试的是一个“实习生”你问它“11等于几”它可能先跟你探讨一番数学哲学然后告诉你“在大多数情况下等于2但在某些模运算或特定语境下可能有其他含义”。你没法直接判它错但离你想要的“2”这个确定答案又差了那么点意思。这就是Agent评测的核心困境评测对象从“确定性程序”变成了“具有涌现能力的智能体”。传统软件测试无论是单元测试、集成测试还是系统测试其基石是“确定性输入-输出”映射。给定相同的输入和环境程序的执行路径和输出结果必须是完全可预测、可重复的。我们评测的是代码的逻辑正确性。而基于大语言模型LLM构建的Agent其核心能力来源于模型的“涌现性”和“概率性”。它没有固定的执行路径每次调用都可能因为模型本身的随机性如temperature参数、上下文prompt的细微差异、甚至外部工具调用的状态而产生不同的推理过程和输出结果。我们评测的是智能体的任务完成度和决策合理性。这个根本性的转变带来了评测维度、方法、标准和成本的全方位升级。传统测试像是在检查一台精密钟表的每个齿轮是否啮合准确而Agent评测则像是在评估一个策略顾问的临场表现、知识广度、逻辑严谨性和沟通有效性。后者显然要复杂、主观且昂贵得多。接下来我们就从几个关键维度拆解这“难10倍”究竟难在哪里。2. 评测维度的爆炸从功能正确到综合智能传统测试的维度相对清晰主要围绕“功能”展开。我们关心的是这个功能点实现了没有边界条件处理了吗性能达标了吗安全漏洞有吗这些维度大多可以量化例如通过/失败的测试用例数、响应时间毫秒数、CPU占用率百分比。Agent的评测维度则呈现指数级扩张因为它模拟的是“人”在复杂环境中的综合能力。我们可以将其粗略分为几个层面2.1 任务执行层效果、效率与可靠性这是最接近传统功能测试的部分但内涵已大不相同。任务完成度Success Rate这是最核心的指标。Agent是否理解了任务Intent Understanding它最终是否输出了用户期望的结果或完成了用户期望的操作例如一个数据分析Agent用户问“帮我找出上个月销售额最高的产品”Agent是否准确输出了产品名称和销售额这里又细分为硬性完成输出完全符合标准答案。在简单、封闭任务中可能实现。软性完成输出答案在语义上正确但表述不同。例如标准答案是“产品A销售额100万”Agent回答“销售额冠军是产品A达到了100万元”这通常也被认为是成功的。部分完成只完成了任务的一部分或答案包含错误信息。评估“完成度”本身就需要定义复杂的匹配规则从简单的字符串匹配到基于嵌入向量的语义相似度计算再到使用另一个LLM作为裁判LLM-as-a-Judge进行评分成本陡增。执行效率EfficiencyAgent用了多少步推理步骤或工具调用次数完成任务消耗了多少Token直接关联成本耗时多长一个虽然能完成任务但绕了巨大弯路、调用十几次无关工具的Agent显然是不高效的。可靠性Reliability在相同的提示词Prompt和环境下多次运行Agent其输出结果的一致性如何一个波动巨大的Agent无法用于生产环境。此外还包括对异常输入模糊、错误、对抗性提示的鲁棒性。2.2 认知与决策层思维过程的可解释与合理性这是传统测试几乎不涉及的领域却是Agent智能的核心。推理链的合理性Reasoning ChainAgent的思考过程Chain-of-Thought是否逻辑自洽是否避免了事实错误和逻辑谬误例如在回答一个数学问题时它的演算步骤是否正确这部分评测往往需要“白盒化”即要求Agent输出其中间推理步骤但这又会增加复杂度和可能的信息泄露风险。规划与工具使用能力Planning Tool Use对于复杂任务Agent是否能将其分解为合理的子任务Planning是否能正确选择并调用合适的工具如计算器、搜索引擎、API调用工具时的参数是否准确例如用户让Agent“查一下北京明天飞上海的航班并选一个下午出发、价格低于1000元的”Agent需要规划1调用搜索工具获取航班列表2调用过滤或计算工具筛选时间和价格3组织结果并回复。其中任何一步规划错误或工具调用失败都会导致任务失败。知识运用与事实准确性Knowledge FactualityAgent的回答是否基于准确的事实是否会产生“幻觉”Hallucination即编造看似合理但完全不存在的信息这是LLM的固有问题也是评测的重点和难点。2.3 交互与安全层对话体验与风险控制Agent通常以对话形式交互这引入了人机交互HCI和安全方面的维度。交互流畅性Interaction FluencyAgent的回复是否自然、连贯、符合上下文是否会出现答非所问、重复或突然中断对话的情况安全性Safety与合规性这是高压红线。评测需要覆盖提示词注入Prompt Injection防止用户通过精心构造的输入诱导Agent突破系统设定的限制执行非法或越权操作。越狱Jailbreak防止用户绕过模型的安全对齐机制使其生成有害、偏见、歧视性或违法内容。信息泄露防止Agent在对话中泄露其系统提示词、内部指令或训练数据中的敏感信息。价值观对齐输出内容是否符合伦理道德和社会公序良俗。 这类评测往往需要构建大量的对抗性测试用例并需要人工进行敏感、细致的审核成本极高。3. 评测方法的困境自动化之难与人工评估之贵面对如此多维度的评测需求传统软件测试中成熟的自动化测试框架如xUnit, Selenium几乎失灵。我们不得不探索新的方法并面临新的取舍。3.1 自动化评测的探索与局限目前自动化评测Agent主要依靠以下几种方式但各有局限基于规则的匹配Rule-based适用于输出结构固定、答案封闭的场景。例如测试一个计算器Agent可以断言其输出是否与标准计算结果匹配。但对于开放域问答规则很难制定。基于模型的评估Model-based Evaluation这是当前的主流研究方向尤其是使用“LLM-as-a-Judge”即用一个通常更强的LLM作为裁判来评估目标Agent的输出。具体做法是将任务描述、Agent输出、有时还包括参考标准答案一起构成一个提示词让裁判LLM从特定维度如相关性、准确性、有帮助性进行打分或比较。优点灵活能处理开放域问题一定程度上模拟了人类判断。缺点成本高每次评估都是一次LLM API调用大规模测试下费用不菲。裁判本身不可靠裁判LLM也有自己的偏差、幻觉和不稳定性。可能出现“盲人领盲人”的情况。评分一致性同样的输出不同裁判模型甚至同一模型不同时间给出的分数可能有波动。维度局限很难用这种方法评估工具调用的正确性、执行效率等非文本维度。端到端集成测试将Agent部署到一个模拟或真实的环境中运行一系列测试工作流Workflow检查最终的业务状态是否达到预期。例如测试一个电商客服Agent模拟用户从咨询、下单到退货的全流程检查订单系统、库存系统的状态变更是否正确。这种方法最贴近真实场景但搭建复杂的模拟环境成本极高且测试用例的设计覆盖度挑战巨大。3.2 人工评估黄金标准与成本黑洞在目前阶段对于关键任务、复杂任务或涉及安全、价值观的评估人工评估仍然是不可替代的“黄金标准”。人类评估者能理解细微的语境、判断逻辑的严谨性、感知交互的自然度这是任何自动化方法难以完全替代的。 然而人工评估的代价是巨大的金钱成本聘请和培训专业的评估人员通常需要领域知识费用高昂。时间成本评估耗时无法支持快速的迭代开发如一天多次的DevOps流程。一致性问题不同评估者之间可能存在主观差异需要制定详细的评估指南并进行校准这本身又是一项复杂工作。可扩展性差难以应对海量测试用例的评估需求。因此一个现实的Agent评测体系往往是自动化评测与人工评估的混合。用自动化方法覆盖回归测试、冒烟测试和大量简单场景用人工评估聚焦于核心场景、复杂逻辑和安全审查。如何设计这个混合策略的配比本身就是一项重要的工程决策。4. 基准测试的缺失寻找Agent领域的“ImageNet”在传统软件和机器学习领域我们有丰富的基准测试Benchmark来横向比较不同系统的能力。例如ImageNet之于计算机视觉GLUE/SuperGLUE之于自然语言理解。这些基准提供了标准化的数据集和评估指标让比较变得相对公平和高效。对于Agent尤其是通用任务Agent目前还缺乏公认的、权威的基准测试。现有的评测集往往聚焦于某个单一能力工具使用如ToolBench评估Agent调用API工具的能力。推理与数学如GSM8K、MATH但这类数据集通常直接测试LLM而非嵌入了规划、工具调用循环的完整Agent。代码生成与执行如HumanEval评估编码能力Code Interpreter类Agent可以在此测试。安全与对抗如Prompt Injection数据集、Jailbreak攻击集。真正的挑战在于如何构建一个能综合评估Agent“规划-推理-工具调用-执行-交互”全链条能力的基准。这样的基准需要复杂且真实的任务不是单一问答而是多步骤项目如“请为我策划一个三天的北京旅游行程并估算大致预算需要查询天气、交通和门票信息”。可配置的环境提供模拟的或真实可访问的工具集如搜索、计算、日历、文件操作API。可自动化的评估标准不仅看最终输出还要评估其执行过程是否合理、高效、安全。这需要为每个任务定义清晰的成功条件Success Criteria和评估函数Evaluation Function。一些框架如AgentBench、AutoGen的评估模块正在朝这个方向努力但离形成一个像ImageNet那样被广泛接受的行业标准还有很长的路要走。没有统一的基准就意味着每个团队都需要投入大量资源构建自己的评测体系和测试用例这是“难10倍”在基础设施层面的体现。5. 工程实践构建可持续的Agent评测流水线尽管困难重重但在工程实践中我们仍然需要建立一套尽可能高效、可靠的Agent评测体系。以下是一些可行的思路和注意事项5.1 分层评测聚焦核心不要试图用一个评测套件覆盖所有维度。建议分层进行单元测试层LLM Prompt层隔离测试核心LLM调用和Prompt模板。例如给定固定的Prompt和输入测试LLM输出的稳定性、是否包含敏感词。可以使用llm库或自定义脚本进行批量调用和规则检查。组件测试层Agent核心逻辑层测试Agent的规划逻辑、工具路由选择、状态管理等功能。可以模拟工具调用验证在给定输入和状态下Agent是否生成了正确的计划和工具调用请求。这部分的测试相对更“确定”可以借鉴传统单元测试。集成测试层端到端工作流层在模拟环境中运行完整的工作流。这是最复杂的一层重点测试多个Agent协作、长链条任务、异常处理等。需要精心设计测试场景和断言条件。人工验收层关键场景与安全层定期对核心用户场景、新上线的复杂功能以及随机抽样的交互进行人工评估确保体验和质量底线。5.2 善用“LLM-as-a-Judge”但保持警惕在集成测试和验收测试中可以大量采用LLM作为裁判进行自动化评分。实践中需要注意设计好的评分指令Rubric给裁判LLM的指令必须清晰、无歧义明确评分维度、分值和标准。例如“请从‘任务完成度’1-5分、‘回复有帮助性’1-5分两个维度评分。任务完成度标准5分-完全解决用户问题...1分-完全无关。”使用一致性更高的裁判模型目前GPT-4-Turbo、Claude-3-Opus等顶级模型在作为裁判时表现相对更稳定。虽然成本高但对于关键评测值得投入。设置参考基准与校准不要只看绝对分数。每次评测时加入一些已知质量的“锚点”样本如人工标注为优、中、差的回答观察裁判模型对这些锚点的评分是否稳定以监控裁判模型本身的波动。结合其他信号不要完全依赖LLM裁判的分数。将其与执行步数、耗时、工具调用成功率等客观指标结合进行综合判断。5.3 构建高质量的测试用例库测试用例的质量直接决定评测的有效性。来源多样化从真实用户日志中抽取高频、典型的查询设计边缘案例和对抗性案例覆盖所有已集成的工具和功能。标注丰富的元数据为每个测试用例标注其测试目标如测试工具调用、测试长上下文理解、测试抗注入能力、难度等级、所属领域等便于分类管理和分析。持续维护与更新随着Agent能力的迭代和用户需求的变化测试用例库需要不断补充和更新。这是一个活的资产。5.4 监控线上表现闭环反馈线下评测再完善也无法完全模拟线上真实环境的复杂性和多样性。因此必须建立强大的线上监控体系关键指标监控如任务完成率可通过用户反馈、后续行为推断、平均会话轮次、工具调用错误率、API延迟与成本。用户反馈收集提供便捷的“点赞/点踩”或反馈入口将用户明确标记为不满意的会话自动纳入测试用例库进行回归测试。根因分析RCA当线上出现bad case时能快速回溯Agent的完整思维链和工具调用记录定位问题是出在Prompt设计、工具能力、模型理解还是其他环节。Agent评测的“难”本质上是智能体复杂性对传统质量保障体系的降维打击。它要求测试工程师、算法工程师和产品经理更紧密地协作从思维上接受不确定性在方法上融合自动化与人工在工程上构建分层、迭代的评估系统。这条路没有银弹唯有深入理解Agent的工作原理紧密结合业务场景持续投入和优化才能在智能体时代守住产品质量的生命线。