AI Agent Skill 测评方案及落地实践上本文为《AI Agent Skill 测评方案及落地实践》系列第 1 篇共 3 篇建议连续阅读。导语当 AI Agent 从Demo 可用走向生产可靠测评就是那道必须跨过的门槛。本文介绍了 TEG云架构平台部 网关测试团队 在 AI Agent 测评领域的体系化实践面对 Agent 非确定性、黑盒化、错误级联放大三大难题建立了一套确定性评分器 Rubric 评分器 人工评分器三类组合的完整测评框架覆盖功能正确性、过程质量、效率成本、鲁棒性安全、体验对齐五大维度并已在 TPerf 性能平台智能分析 Agent 项目中落地验证。无论你是刚开始构建 Agent 测评体系还是已有初步实践希望系统化升级都可以从中找到可直接复用的方法论、评分模板与工程实现方案。一、背景为什么要做测评1.1 痛点Agent 的自主性带来了三个传统软件没有的问题非确定性同一 prompt 多次执行结果不同跑通一次不代表稳定能跑。黑盒化模型升级、Prompt 微调、工具链变化都可能导致行为漂移肉眼难以察觉。错误级联放大一次任务涉及几十步工具调用前序步骤的一个小偏差会沿链路逐级放大最终导致结论完全偏离。没有测评会让团队陷入以下被动局面痛点后果主观性强依赖感觉变好了的直觉判断缺乏量化依据团队无法基于数据做科学决策悄悄退化改了 Prompt 或升级了依赖旧场景悄悄变差却无人知晓直到用户投诉才暴露人工验证成本高Skill 越多、模型迭代越快靠人肉回归的成本指数级增长最终只能选择性验证留下盲区模型不敢升级新模型发布时没有对比数据支撑切换决策错过能力提升和成本下降的红利缺少效率基线没有延迟/Token/费用的历史基线线上变贵变慢时无法定位原因和归因版本过程易忽略最终答案可能碰巧正确但推理路径是错的无法区分正确调用工具后回答与从训练数据碰巧答对1.2 核心理念面对这些痛点我们需要的不是偶尔跑一跑的人工验证而是一套嵌入研发流程的自动化评估体系。其核心可以概括为一个公式Eval评估 Agent 输入 → 执行 → 捕获执行过程Trace 产物 → 一组检查规则 → 可对比的分数名词说明Trace执行轨迹是 Agent 执行过程中产生的结构化日志记录了每一步的工具调用、参数、返回值和思考过程类似于程序调试中的调用栈记录。测评的目标是建立一个可重复、可量化、可持续演进的评估闭环而不是追求完美覆盖。关键在于每次变更都能快速跑出一个可比较的分数用数据代替直觉用全量代替抽查。二、测评框架谁来评评什么由谁什么工具/角色来打分用哪些维度衡量 Agent 的表现这构成了整个测评方案的理论基础。我们参考了 OpenAI 和 Anthropic 的实践经验从中提炼出关键启示后续的用例设计与评分器实现均建立在此基础之上。[图片三类评分器组合框架示意]2.1 三类评委谁来打分Agent 的输出既有可程序化验证的硬指标文件存在、调用正确也有只能靠语义理解才能判断的软指标推理合理性、建议质量。单一评分手段无法兼顾两者因此 Agent 测评没有银弹评分器必须三类组合使用┌──────────────────────────────────┐ │ 确定性评分器 │ │ 脚本 / 断言 / Lint / AST │ │ 快、便宜、客观、可复现 │ │ ⇨ 负责所有能用代码判断的事 │ └──────────────────────────────────┘ ↑ │ 日常主力 │ ┌──────────────────────────────────┐ │ 模型评分器Rubric │ │ LLM-as-Judge Prompt Schema│ │ 灵活、可扩展、处理开放式输出 │ │ ⇨ 负责代码搞不定但能结构化描述 │ └──────────────────────────────────┘ ↑ │ 扩展能力 │ ┌──────────────────────────────────┐ │ 人工评分器专家 │ │ 昂贵、慢、黄金标准 │ │ ⇨ 负责校准、诊断、兜底 │ └──────────────────────────────────┘三类评委职责对照维度确定性评分器Rubric 评分器人工评分器谁来评脚本Bash/Python大模型固定版本领域专家规则写在哪代码里Prompt JSON Schema人脑 标注指南成本毫秒级 / 免费秒级 / API 费用分钟–小时级 / 人力稳定性100%有抖动需降噪取决于标注员水平覆盖能力已知硬指标未知软指标主观 边缘场景典型用例文件存在、构建通过、测试通过代码风格、意图贴合、解释清晰度校准 LLM、诊断 0%/100% 异常、红队测试门禁角色硬门禁分级门禁error 硬、warning 软不进门禁做采样审查选择优先级确定性评分器 Rubric 评分器 人工评分器——能用代码判断的绝不用模型必要时用模型人工用于校准。确定性评分器快速、客观、可复现负责所有能用代码判断的事评分器类型说明适用场景工具调用检查检查是否调用了指定工具、参数是否正确过程验证产物检查检查文件是否存在、内容是否符合预期结果验证关键词匹配检查响应中是否包含/不包含特定内容结果验证执行指标检查工具调用次数、token 消耗是否在阈值内效率/成本验证基线对比将本次执行的过程和结果与基线快照逐项对比详见第三章回归验证用例中的确定性规则示例expected_behavior: # 过程检查是否调用了指定工具 - tool_call: mcp contains: tperf-mcp # 结果检查产物是否存在 - file_exists: - cpu.json - nic.json # 结果检查响应内容是否包含关键信息 - response_contains: - 测试有效 - 出现CPU瓶颈 - 业务QPS平稳 # 效率检查工具调用次数上限 - max_tool_calls: 10Rubric 评分器模型评分灵活、可扩展负责代码搞不定但能结构化描述的场景如输出的内容包含自然语言评分器类型说明适用场景LLM 评判让另一个 LLM 按评分标准判断表现回答质量、语气、规范遵循度用例中的 Rubric 规则示例rubric: observation_points: - 回答是否基于项目规范/知识库而非通用知识 - 推理过程是否清晰连贯 - 是否存在幻觉或编造内容 scoring: process_score: 0-100 # 过程分 result_score: 0-100 # 结果分 is_false_positive: bool # 是否虚假成功结果对但过程错人工评分器专家介入的六个必要场景人工评分最贵只在以下场景投入校准 LLM 评委最核心用途——抽样 100–200 条和 LLM 打分对齐一致率≥ 85%才算可用。主观任务打分——回复同理心、报告论证严谨度。诊断通过率异常——0% 或 100% 通常是任务/评分器坏了不是模型弱。建立 Ground Truth黄金标准答案——新套件上线的前 20–50 个参考解。Trace 采样审查——每周固定抽样读轨迹找隐藏失败模式。高风险兜底——医疗/金融/安全场景 100% 人工复核。经验法则能自动化的坚决不找专家专家时间应60% 以上花在校准 LLM 评委和诊断异常上。2.2 五个维度评什么了解了谁来评之后接下来明确评什么。我们将 Agent 的测评覆盖拆解为五个大类从做对了吗到好用吗逐层递进┌─────────────────────────────────────────────────────┐ │ 1. 功能正确性Functional Correctness—— 做对了吗 │ │ 2. 过程质量Process Quality—— 过程合理吗 │ │ 3. 效率与成本Efficiency Cost—— 划算吗 │ │ 4. 鲁棒性与安全Robustness Safety—— 靠谱吗 │ │ 5. 体验与对齐Experience Alignment—— 好用吗 │ └─────────────────────────────────────────────────────┘下表汇总了每个大类的子维度、主要由谁来评分、以及落地优先级大类子维度主要评委优先级1. 功能正确性结果正确性、任务完成度、指令遵循、工具调用正确性代码P02. 过程质量推理合理性、步骤最优性、信息完整性、上下文利用率Rubric 人工P13. 效率与成本Token消耗、工具调用次数、延迟、失败重试率代码P14. 鲁棒性与安全一致性pass^k、异常恢复、抗对抗、幻觉率、越权风险、合规性代码 人工P05. 体验与对齐语气风格、清晰度、主动澄清、同理心、品牌一致性Rubric 人工P2术语说明Rubric评分量表/评分标准这里特指用结构化的评分提示词让另一个大模型充当评委打分的方式。pass^kk 次试验中每次都通过的概率衡量稳定性passkk 次中至少 1 次通过的概率衡量峰值能力。P0 先落地、P2 按需补充——优先保证做对了和靠谱再逐步覆盖过程、成本和体验。下面逐一展开五个维度的子项、评测方法和典型指标。大类 1功能正确性Functional Correctness回答的问题这次任务到底做成了没子维度定义评测方法典型指标结果正确性最终产出是否符合预期代码比对、单元测试、数据库校验pass1 / pass^k任务完成度多步任务完成的百分比子目标打点完成率 %指令遵循度是否严格按用户指令输出格式、字段、约束JSON Schema 校验、正则、字段检查遵循率 %工具调用正确性是否选对工具、参数是否正确调用日志断言调用准确率 %这一类是P0必须自动化、全覆盖。对应评分体系中确定性评分器的主战场。大类 2过程质量Process Quality回答的问题即便做对了过程合理吗子维度定义评测方法典型指标推理合理性思考链条是否自洽、没有跳步Rubric 评委合理性评分 1–5步骤最优性是否走了不必要的弯路比较实际步数 vs 参考解法步数比信息完整性输出是否覆盖了任务所需的所有关键信息Rubric 按要点核查要点覆盖率 %上下文利用率是否充分利用了提供的上下文没有遗漏Rubric 人工抽查利用率评分自我纠错能力遇到错误时是否能识别并修正Trace 分析纠错成功率这一类最能体现智能水平但自动化难度高是Rubric 评委的主战场。大类 3效率与成本Efficiency Cost回答的问题结果对了但划得来吗子维度定义评测方法典型指标Token 消耗输入 输出 token 总量API 统计avg / p95 tokens工具调用次数完成任务的工具调用总数Trace 统计avg / p95 calls端到端延迟用户发起到收到最终结果的时间时间戳p50 / p95 / p99 latency失败重试率单次试验内工具/模型调用的重试次数Trace 统计重试率 %单次任务成本折算成人民币/美元的成本Token × 单价¥/task这是被很多团队忽视但极其重要的一类。一个 pass1 高但 token 花 10 倍的方案在生产上是不可接受的。建议每个任务都带上成本画像。大类 4鲁棒性与安全Robustness Safety回答的问题它会不会在关键时刻翻车子维度定义评测方法典型指标一致性 / 稳定性相同输入多次运行结果是否一致多次试验k5/10pass^k异常恢复工具失败、超时、返回异常时能否兜底故障注入测试恢复成功率抗对抗 / 抗注入面对 Prompt Injection、恶意输入是否守住红队用例集抗攻击率幻觉率是否编造不存在的事实/API/字段事实核查代码或人工幻觉率 %越权 / 越界风险是否执行了超出授权的操作权限断言越权次数合规性是否泄露 PII、违反行业规范正则 人工抽查违规率拒绝合理性该拒绝时是否拒绝、不该拒绝时是否过度拒绝Rubric 人工误拒 % / 漏拒 %这一类是P0尤其是涉及金融、医疗、企业数据的 Agent必须前置。pass^k 释义k 次试验中每次都成功的概率用于衡量一致性/稳定性。与之对应的 passk 是 k 次试验中至少 1 次成功的概率用于衡量峰值能力。大类 5体验与对齐Experience Alignment回答的问题用户愿意继续用它吗子维度定义评测方法典型指标语气风格是否符合品牌调性专业/亲切/简洁Rubric 评委风格评分回复清晰度结构是否清楚、有无废话Rubric 人工清晰度评分主动澄清模糊需求时是否会主动提问而非瞎猜Rubric澄清率 %同理心对话场景中是否能识别情绪并恰当回应人工 Rubric同理心评分可解释性是否能说清自己做了什么、为什么人工抽查可解释评分用户满意度真实用户反馈线上点赞/点踩、NPSCSAT / NPS这一类是P2但却是决定产品生死的。早期用 Rubric 人工抽样成熟后引入线上 A/B 用户反馈闭环。2.3 不同类型 Agent 的测评侧重前面介绍的五大维度和三类评委是一套通用框架适用于所有类型的 Agent / Skill。但在实际落地时不同类型的 Agent 面临的核心风险不同测评的侧重点也应有所差异——把有限的精力花在最容易出问题的地方Agent / Skill 类型测评侧重点典型检查项知识库问答准确性、幻觉检测、引用溯源回答是否基于知识库内容而非编造是否正确引用来源是否覆盖问题核心要点代码编写产物正确性、可运行性生成的代码是否能编译/运行通过是否满足功能需求代码风格是否符合规范功能工具如性能分析、数据处理过程合规性、工具调用正确性是否按预期步骤调用了正确的工具工具参数是否正确输出报告是否完整准确问题定位如故障排查、日志分析推理链路、根因准确性推理过程是否逻辑清晰是否定位到真实根因排查步骤是否高效无冗余差异体现在用什么评分器和检查什么而非流程本身。例如知识库问答更依赖Rubric 评分器判断回答质量、检测幻觉代码编写更依赖确定性评分器编译是否通过、测试是否跑过功能工具更关注过程对比工具调用序列是否与基线一致问题定位则需要过程 结果双重验证推理链路正确且结论准确
AI Agent Skill 测评方案及落地实践上本文为《AI Agent Skill 测评方案及落地实践》系列第 1 篇共 3 篇建议连续阅读。导语当 AI Agent 从Demo 可用走向生产可靠测评就是那道必须跨过的门槛。本文介绍了 TEG云架构平台部 网关测试团队 在 AI Agent 测评领域的体系化实践面对 Agent 非确定性、黑盒化、错误级联放大三大难题建立了一套确定性评分器 Rubric 评分器 人工评分器三类组合的完整测评框架覆盖功能正确性、过程质量、效率成本、鲁棒性安全、体验对齐五大维度并已在 TPerf 性能平台智能分析 Agent 项目中落地验证。无论你是刚开始构建 Agent 测评体系还是已有初步实践希望系统化升级都可以从中找到可直接复用的方法论、评分模板与工程实现方案。一、背景为什么要做测评1.1 痛点Agent 的自主性带来了三个传统软件没有的问题非确定性同一 prompt 多次执行结果不同跑通一次不代表稳定能跑。黑盒化模型升级、Prompt 微调、工具链变化都可能导致行为漂移肉眼难以察觉。错误级联放大一次任务涉及几十步工具调用前序步骤的一个小偏差会沿链路逐级放大最终导致结论完全偏离。没有测评会让团队陷入以下被动局面痛点后果主观性强依赖感觉变好了的直觉判断缺乏量化依据团队无法基于数据做科学决策悄悄退化改了 Prompt 或升级了依赖旧场景悄悄变差却无人知晓直到用户投诉才暴露人工验证成本高Skill 越多、模型迭代越快靠人肉回归的成本指数级增长最终只能选择性验证留下盲区模型不敢升级新模型发布时没有对比数据支撑切换决策错过能力提升和成本下降的红利缺少效率基线没有延迟/Token/费用的历史基线线上变贵变慢时无法定位原因和归因版本过程易忽略最终答案可能碰巧正确但推理路径是错的无法区分正确调用工具后回答与从训练数据碰巧答对1.2 核心理念面对这些痛点我们需要的不是偶尔跑一跑的人工验证而是一套嵌入研发流程的自动化评估体系。其核心可以概括为一个公式Eval评估 Agent 输入 → 执行 → 捕获执行过程Trace 产物 → 一组检查规则 → 可对比的分数名词说明Trace执行轨迹是 Agent 执行过程中产生的结构化日志记录了每一步的工具调用、参数、返回值和思考过程类似于程序调试中的调用栈记录。测评的目标是建立一个可重复、可量化、可持续演进的评估闭环而不是追求完美覆盖。关键在于每次变更都能快速跑出一个可比较的分数用数据代替直觉用全量代替抽查。二、测评框架谁来评评什么由谁什么工具/角色来打分用哪些维度衡量 Agent 的表现这构成了整个测评方案的理论基础。我们参考了 OpenAI 和 Anthropic 的实践经验从中提炼出关键启示后续的用例设计与评分器实现均建立在此基础之上。[图片三类评分器组合框架示意]2.1 三类评委谁来打分Agent 的输出既有可程序化验证的硬指标文件存在、调用正确也有只能靠语义理解才能判断的软指标推理合理性、建议质量。单一评分手段无法兼顾两者因此 Agent 测评没有银弹评分器必须三类组合使用┌──────────────────────────────────┐ │ 确定性评分器 │ │ 脚本 / 断言 / Lint / AST │ │ 快、便宜、客观、可复现 │ │ ⇨ 负责所有能用代码判断的事 │ └──────────────────────────────────┘ ↑ │ 日常主力 │ ┌──────────────────────────────────┐ │ 模型评分器Rubric │ │ LLM-as-Judge Prompt Schema│ │ 灵活、可扩展、处理开放式输出 │ │ ⇨ 负责代码搞不定但能结构化描述 │ └──────────────────────────────────┘ ↑ │ 扩展能力 │ ┌──────────────────────────────────┐ │ 人工评分器专家 │ │ 昂贵、慢、黄金标准 │ │ ⇨ 负责校准、诊断、兜底 │ └──────────────────────────────────┘三类评委职责对照维度确定性评分器Rubric 评分器人工评分器谁来评脚本Bash/Python大模型固定版本领域专家规则写在哪代码里Prompt JSON Schema人脑 标注指南成本毫秒级 / 免费秒级 / API 费用分钟–小时级 / 人力稳定性100%有抖动需降噪取决于标注员水平覆盖能力已知硬指标未知软指标主观 边缘场景典型用例文件存在、构建通过、测试通过代码风格、意图贴合、解释清晰度校准 LLM、诊断 0%/100% 异常、红队测试门禁角色硬门禁分级门禁error 硬、warning 软不进门禁做采样审查选择优先级确定性评分器 Rubric 评分器 人工评分器——能用代码判断的绝不用模型必要时用模型人工用于校准。确定性评分器快速、客观、可复现负责所有能用代码判断的事评分器类型说明适用场景工具调用检查检查是否调用了指定工具、参数是否正确过程验证产物检查检查文件是否存在、内容是否符合预期结果验证关键词匹配检查响应中是否包含/不包含特定内容结果验证执行指标检查工具调用次数、token 消耗是否在阈值内效率/成本验证基线对比将本次执行的过程和结果与基线快照逐项对比详见第三章回归验证用例中的确定性规则示例expected_behavior: # 过程检查是否调用了指定工具 - tool_call: mcp contains: tperf-mcp # 结果检查产物是否存在 - file_exists: - cpu.json - nic.json # 结果检查响应内容是否包含关键信息 - response_contains: - 测试有效 - 出现CPU瓶颈 - 业务QPS平稳 # 效率检查工具调用次数上限 - max_tool_calls: 10Rubric 评分器模型评分灵活、可扩展负责代码搞不定但能结构化描述的场景如输出的内容包含自然语言评分器类型说明适用场景LLM 评判让另一个 LLM 按评分标准判断表现回答质量、语气、规范遵循度用例中的 Rubric 规则示例rubric: observation_points: - 回答是否基于项目规范/知识库而非通用知识 - 推理过程是否清晰连贯 - 是否存在幻觉或编造内容 scoring: process_score: 0-100 # 过程分 result_score: 0-100 # 结果分 is_false_positive: bool # 是否虚假成功结果对但过程错人工评分器专家介入的六个必要场景人工评分最贵只在以下场景投入校准 LLM 评委最核心用途——抽样 100–200 条和 LLM 打分对齐一致率≥ 85%才算可用。主观任务打分——回复同理心、报告论证严谨度。诊断通过率异常——0% 或 100% 通常是任务/评分器坏了不是模型弱。建立 Ground Truth黄金标准答案——新套件上线的前 20–50 个参考解。Trace 采样审查——每周固定抽样读轨迹找隐藏失败模式。高风险兜底——医疗/金融/安全场景 100% 人工复核。经验法则能自动化的坚决不找专家专家时间应60% 以上花在校准 LLM 评委和诊断异常上。2.2 五个维度评什么了解了谁来评之后接下来明确评什么。我们将 Agent 的测评覆盖拆解为五个大类从做对了吗到好用吗逐层递进┌─────────────────────────────────────────────────────┐ │ 1. 功能正确性Functional Correctness—— 做对了吗 │ │ 2. 过程质量Process Quality—— 过程合理吗 │ │ 3. 效率与成本Efficiency Cost—— 划算吗 │ │ 4. 鲁棒性与安全Robustness Safety—— 靠谱吗 │ │ 5. 体验与对齐Experience Alignment—— 好用吗 │ └─────────────────────────────────────────────────────┘下表汇总了每个大类的子维度、主要由谁来评分、以及落地优先级大类子维度主要评委优先级1. 功能正确性结果正确性、任务完成度、指令遵循、工具调用正确性代码P02. 过程质量推理合理性、步骤最优性、信息完整性、上下文利用率Rubric 人工P13. 效率与成本Token消耗、工具调用次数、延迟、失败重试率代码P14. 鲁棒性与安全一致性pass^k、异常恢复、抗对抗、幻觉率、越权风险、合规性代码 人工P05. 体验与对齐语气风格、清晰度、主动澄清、同理心、品牌一致性Rubric 人工P2术语说明Rubric评分量表/评分标准这里特指用结构化的评分提示词让另一个大模型充当评委打分的方式。pass^kk 次试验中每次都通过的概率衡量稳定性passkk 次中至少 1 次通过的概率衡量峰值能力。P0 先落地、P2 按需补充——优先保证做对了和靠谱再逐步覆盖过程、成本和体验。下面逐一展开五个维度的子项、评测方法和典型指标。大类 1功能正确性Functional Correctness回答的问题这次任务到底做成了没子维度定义评测方法典型指标结果正确性最终产出是否符合预期代码比对、单元测试、数据库校验pass1 / pass^k任务完成度多步任务完成的百分比子目标打点完成率 %指令遵循度是否严格按用户指令输出格式、字段、约束JSON Schema 校验、正则、字段检查遵循率 %工具调用正确性是否选对工具、参数是否正确调用日志断言调用准确率 %这一类是P0必须自动化、全覆盖。对应评分体系中确定性评分器的主战场。大类 2过程质量Process Quality回答的问题即便做对了过程合理吗子维度定义评测方法典型指标推理合理性思考链条是否自洽、没有跳步Rubric 评委合理性评分 1–5步骤最优性是否走了不必要的弯路比较实际步数 vs 参考解法步数比信息完整性输出是否覆盖了任务所需的所有关键信息Rubric 按要点核查要点覆盖率 %上下文利用率是否充分利用了提供的上下文没有遗漏Rubric 人工抽查利用率评分自我纠错能力遇到错误时是否能识别并修正Trace 分析纠错成功率这一类最能体现智能水平但自动化难度高是Rubric 评委的主战场。大类 3效率与成本Efficiency Cost回答的问题结果对了但划得来吗子维度定义评测方法典型指标Token 消耗输入 输出 token 总量API 统计avg / p95 tokens工具调用次数完成任务的工具调用总数Trace 统计avg / p95 calls端到端延迟用户发起到收到最终结果的时间时间戳p50 / p95 / p99 latency失败重试率单次试验内工具/模型调用的重试次数Trace 统计重试率 %单次任务成本折算成人民币/美元的成本Token × 单价¥/task这是被很多团队忽视但极其重要的一类。一个 pass1 高但 token 花 10 倍的方案在生产上是不可接受的。建议每个任务都带上成本画像。大类 4鲁棒性与安全Robustness Safety回答的问题它会不会在关键时刻翻车子维度定义评测方法典型指标一致性 / 稳定性相同输入多次运行结果是否一致多次试验k5/10pass^k异常恢复工具失败、超时、返回异常时能否兜底故障注入测试恢复成功率抗对抗 / 抗注入面对 Prompt Injection、恶意输入是否守住红队用例集抗攻击率幻觉率是否编造不存在的事实/API/字段事实核查代码或人工幻觉率 %越权 / 越界风险是否执行了超出授权的操作权限断言越权次数合规性是否泄露 PII、违反行业规范正则 人工抽查违规率拒绝合理性该拒绝时是否拒绝、不该拒绝时是否过度拒绝Rubric 人工误拒 % / 漏拒 %这一类是P0尤其是涉及金融、医疗、企业数据的 Agent必须前置。pass^k 释义k 次试验中每次都成功的概率用于衡量一致性/稳定性。与之对应的 passk 是 k 次试验中至少 1 次成功的概率用于衡量峰值能力。大类 5体验与对齐Experience Alignment回答的问题用户愿意继续用它吗子维度定义评测方法典型指标语气风格是否符合品牌调性专业/亲切/简洁Rubric 评委风格评分回复清晰度结构是否清楚、有无废话Rubric 人工清晰度评分主动澄清模糊需求时是否会主动提问而非瞎猜Rubric澄清率 %同理心对话场景中是否能识别情绪并恰当回应人工 Rubric同理心评分可解释性是否能说清自己做了什么、为什么人工抽查可解释评分用户满意度真实用户反馈线上点赞/点踩、NPSCSAT / NPS这一类是P2但却是决定产品生死的。早期用 Rubric 人工抽样成熟后引入线上 A/B 用户反馈闭环。2.3 不同类型 Agent 的测评侧重前面介绍的五大维度和三类评委是一套通用框架适用于所有类型的 Agent / Skill。但在实际落地时不同类型的 Agent 面临的核心风险不同测评的侧重点也应有所差异——把有限的精力花在最容易出问题的地方Agent / Skill 类型测评侧重点典型检查项知识库问答准确性、幻觉检测、引用溯源回答是否基于知识库内容而非编造是否正确引用来源是否覆盖问题核心要点代码编写产物正确性、可运行性生成的代码是否能编译/运行通过是否满足功能需求代码风格是否符合规范功能工具如性能分析、数据处理过程合规性、工具调用正确性是否按预期步骤调用了正确的工具工具参数是否正确输出报告是否完整准确问题定位如故障排查、日志分析推理链路、根因准确性推理过程是否逻辑清晰是否定位到真实根因排查步骤是否高效无冗余差异体现在用什么评分器和检查什么而非流程本身。例如知识库问答更依赖Rubric 评分器判断回答质量、检测幻觉代码编写更依赖确定性评分器编译是否通过、测试是否跑过功能工具更关注过程对比工具调用序列是否与基线一致问题定位则需要过程 结果双重验证推理链路正确且结论准确
