评测这事卡住了很多 AI 产品经理Demo 阶段跑通一次很容易真到上线前验收同一个 Agent 换个说法就不会了或者同一批用例昨天能过今天过不了再或者 Agent 明明调用了正确工具结果却答非所问。这里面的难点不在某一个模型的输出质量而在 Agent 系统本身是“多轮多步 工具调用 非确定性输出”的组合体传统软件测试那套“输入一确定、输出就确定”的方法直接失效了。这次我们专门聊一个问题AI 产品经理如何做 Agent 评测重点不是让你写一堆测试框架代码而是给你一套从评测维度、评测集建设、人工评分、自动化判题、失败归因到成本观测的完整流程。哪怕你手里没有专门的 Agent 评测平台只用 Excel、一个脚本、几个 GPT API Key也能跑通评测闭环。这套方法适合几类人正在做 Agent 型产品智能客服、行业顾问、自动化助手的产品经理需要对比多个 Agent 框架或大模型的选型负责人还有想给自己的 Prompt 工程加上回归测试的技术负责人。读完这篇文章你应该能回答三个问题一个 Agent 到底该测什么、怎么量化好坏、评测结果怎么变成产品改进依据。1. AI Agent 评测核心能力速览能力项说明核心目标对 Agent 的多轮对话、任务规划、工具调用、最终结果进行可量化的效果评估评测维度任务成功率、完成度、工具调用准确率、步骤效率、幻觉率、回复质量、稳定性评测形式手工用例 评分卡 半自动脚本 LLM-as-Judge 自动判题评测集构成任务卡片、前置条件、用户输入、黄金结果、验收点、难度分层基础设施要求可调用 Agent 的 API/SDK、日志系统、工具 mock 环境、评测结果存储输出产物评测报告、缺陷列表、失败归因、版本对比结论、上线建议适合场景选型评测、版本回归、Prompt 调优验证、上线前风险验收难点非确定性输出、长链路错误定位难、工具调用校验复杂、回归成本高这张表是整篇文章的骨架。下面每一节都会展开讲怎么落地。2. AI 产品经理做 Agent 评测的适用场景与使用边界Agent 评测不是所有场景都要做全套先把投入产出比看明白。2.1 需要做系统评测的场景第一类是选型评测。公司在 Agent 框架、底座模型、Agent 平台之间做选择时不能只看官方 Demo 和榜单分数要在自己的业务场景上跑同一批用例用同一套标准打分结果才能用于决策。第二类是版本回归。无论是改了 Prompt、换了模型、还是升级了工具接口都要跑一次回归集确认修复了一个问题但没有引入新问题。第三类是上线前验收。Agent 一旦涉及工具调用、外部接口、用户数据上线前必须有验收标准。比如财务问答 Agent 调用了查询接口答错一个数字就是事故。2.2 不应该过度评测的场景如果 Agent 还在非常早期的 Demo 阶段产品方向都没定不要急着建几百条用例的评测集。先把 10 到 20 条核心场景跑通确认这件事本身有价值再投入资源建设评测体系。评测是工具不是目的。2.3 使用边界与合规要求做 Agent 评测时可能会用到用户对话日志、真实业务数据、受版权保护的文档。这里必须强调几条底线评测集里的数据要脱敏不能用真实姓名、手机号、身份证、企业机密等敏感数据。涉及图片、语音、视频、人物肖像的 Agent 任务必须确认素材授权。工具调用评测尽量不要打真实业务接口用沙箱、mock 服务或专门测试账号避免产生脏数据。评测过程中记录的用户行为数据要遵循最小化原则只在测试环境留存。这些不是形式要求。真实业务里因为评测时调用真实支付接口、真实发送短信而翻车的案例并不少。3. Agent 评测维度与指标体系设计评测一个 Agent不能只说“好用”或“不好用”。要把它拆成结果指标、过程指标、体验指标三层。3.1 结果指标任务到底完成没有结果指标回答的是“用户的目标达成了没有”这是最高优先级。指标定义判断方式任务成功率Agent 是否在允许的步骤内完整达成用户目标对照黄金结果人工或自动判题完成度目标未完全达成时完成了多少按验收点拆分统计通过比例正确率给出的结果是否准确无事实性错误对照知识库或权威答案拒绝率遇到不合法请求时是否合理拒绝检查是否有越权行为实际评测中任务成功率是第一步。一个 Agent 如果任务成功率只有 40%其他指标再好看也不能上线。3.2 过程指标工具调用和路径对不对结果对过程不一定对。过程指标主要看 Agent 是否走了一条合理路径。指标定义判断方式工具调用准确率需要调用工具时是否调对了工具、传对了参数对比专家路径中的工具调用序列无效调用率是否存在不必要的、重复的、错误的工具调用统计工具调用日志步骤效率完成任务用了多少步和专家路径差多少对比期望步数与实际步数多轮收敛能力对话是否在合理轮次内收敛有没有反复绕圈记录对话轮数从评测实践看一个典型问题是 Agent 连续多次调用同一工具拿同一份数据参数完全相同。这种重复调用不会体现在“任务成功率”上但会直接推高 token 成本和响应延迟。过程指标就是用来抓这类问题的。3.3 体验指标输出质量与交互感受体验指标负责评价“像不像一个合格助手”。建议关注四个点回答结构是否清晰有没有长段落堆砌。是否主动说明不确定性。知道不知道要分开不能用确定语气编造答案。追问是否合理。信息不足时是否用提问补齐关键参数。指令遵循度。用户明确说“不要解释直接给表格”是否还输出大段文字。这些指标比较主观建议用评分卡量化每个维度按 1 到 4 分打分方便后续做统计分析。4. Agent 评测集的建设任务库、黄金答案与验收点评测集是整个评测体系的地基。用例质量不高后面所有指标都是数字游戏。4.1 任务从哪来最推荐的来源是真实用户日志。找产品上线前后客户问得最多的 20 类问题每个问题再拆几个变体。如果没有用户日志就从业务方那里收集客服高频问题、销售常见咨询、内部运营常用操作。这条来源比产品经理自己编的用例可靠得多。4.2 任务卡的结构每一条评测用例建议用任务卡的方式管理。参考结构如下{ task_id: T004, scene: 费用报销咨询, difficulty: medium, user_goal: 用户想知道差旅报销的流程和需要提交的材料, input: 我下周出差回来之后报销需要走什么流程要准备哪些材料, preconditions: { knowledge_base: v2.3, tool_mock: expense_approval_api }, expected_path: [ 调用报销政策查询, 调用报销材料清单查询, 输出步骤式回答 ], acceptance_points: [ 点出来需要发票, 点出来需要填写报销单, 点出来审批流程最多几个工作日, 不得输出与政策无关的信息 ], golden_answer: 首先登录 OA 系统填写报销单上传发票和行程单部门经理审批后由财务审核正常 3 个工作日内到账。 }这个结构把一条用例拆成目标、输入、前置条件、期望路径、验收点、黄金答案六要素。其中验收点最重要它决定了自动判题时能拆出哪几个检查项。4.3 样例数量与难度分层评测集不是越多越好关键是覆盖度和分层。一个稳妥的做法是每个核心场景至少准备 10 到 30 条用例具体数量根据业务风险决定。难度分四层简单单轮、直接查询、中等多轮澄清、困难多工具调用、对抗误导信息、边界请求。优先保证“真实高频场景”的用例数量对抗样例用于压力测试占比不用太高。一个常见误区是评测集全部用产品经理自己写的“标准问法”导致 Agent 在真实用户五花八门的表达方式面前表现很差。建议在用例里刻意加入口语化表达、错别字、同义改写和省略主语的说法。5. 手工评测流程与评分卡设计自动化评测做得再好第一轮上线前和核心样例回归时仍然需要人工过一遍。手工评测的目标不是“测多”而是“测深”。5.1 手工评测前准备准备一个干净的测试环境固定模型版本、Prompt 版本、知识库版本。评测过程中跑出来的结果和日志都要落盘。建议用下面的记录格式run_id,task_id,model_version,prompt_version,result_type,success,tool_calls,error_type,comment run_001,T004,gpt-4o-2024-08,prompt_v3,full_success,total_steps:4,tool1:2,expense_error,补充回答里漏了发票说明每一条记录里的result_type可以取值full_success、partial_success、failed、refused、hallucination。人工评测时最忌讳只记“通过/不通过”一定要留下失败原因和现场描述否则后续无法归因。5.2 评分卡设计评分卡建议按四个维度打分每个维度 1 到 4 分维度1 分2 分3 分4 分任务完成完全没完成部分完成目标达成但有遗漏目标完整达成工具调用错误调用或乱调调对了但参数有误调用正确路径略绕调用精准符合专家路径回复质量答案错误或幻觉有正确信息但结构混乱结构清晰略有冗余准确、简洁、结构好指令遵循违反明确指令部分执行基本遵守完全遵守人工打分最大的问题是评分漂移。同一个回答周一打 3 分周五可能就打 2 分。缓解办法是双人抽评、明确打分锚点、以及对争议样本进行讨论后校准。5.3 手工评测步骤固定测试入口建议通过 API 调用而非网页复制粘贴。每组跑测前记录模型版本、Prompt 版本、工具 mock 环境。逐条跑用例观察中间步骤的 tool_call 参数。每条用例结束后立即记录结果避免事后凭记忆补录。失败用例保留完整对话上下文包括工具返回的原始数据。每跑 30 条左右做一次评分校准避免前紧后松。6. Agent 自动化评测、工具调用校验与批量跑测人工评测一次只能跑几十条到了回归阶段用例集上千条时就必须上自动化。Agent 自动化评测分三块结果校验、路径校验、质量判题。6.1 结果校验字段级断言对于有明确输出的 Agent如查询订单状态、计算费用可以用字段级断言。先定义期望输出的 JSON Schema再检查 Agent 输出是否符合结构。def validate_schema(output: dict, expected_schema: dict) - bool: for key, expected_type in expected_schema.items(): if key not in output: return False if isinstance(expected_type, str) and not isinstance(output[key], eval(expected_type)): return False return True schema { order_status: str, eta_days: int, should_refund: bool } print(validate_schema(agent_output, schema))这种断言只适合结构固定、取值可枚举的任务不适合开放型问答。6.2 工具调用校验用 mock 服务验证参数Agent 的核心风险在工具调用。校验工具调用最安全的方式是用 mock 服务替换真实接口。mock 服务记录每次请求的参数评测结束后比对参数是否正确。# mock 服务示例实际路径按项目调整 python -m mock_server --port 8000 --schema ./tool_schema.json每个 mock 接口返回预设的固定数据比如查询订单接口固定返回“状态为已发货”。这样评测可以重复不受外部数据变化影响。同时要断言 Agent 是否在调用接口前取得了必要参数比如用户没提供订单号Agent 应该先追问而不是直接传空参数调用。6.3 LLM-as-Judge用裁判模型判主观题对开放型回答建议用裁判模型做初步筛选再用人工抽检。裁判模型的 Prompt 需要把评分标准写清楚并要求输出 JSON 结构。{ score: 3, reason: 任务目标达成但回答中缺少审批流程的时限说明, missed_points: [审批时限] }裁判模型不适合独立做最终判定它的价值是快速过滤掉明显不合格的用例把人工精力集中在边界样本上。6.4 批量跑测脚本模板下面是一个批量跑测的流程模板实际 Agent 接口需要按项目替换。import json import time import requests with open(eval_set.json, r, encodingutf-8) as f: eval_set json.load(f) results [] for item in eval_set: payload { prompt: item[input], conversation_id: feval_{item[task_id]}_{int(time.time())} } try: resp requests.post( http://your-agent-service:8000/api/chat, jsonpayload, timeout120 ) data resp.json() results.append({ task_id: item[task_id], input: item[input], output: data[answer], tool_calls: data.get(tool_calls, []), latency: data.get(latency_ms), token: data.get(token_usage, {}) }) except Exception as e: results.append({ task_id: item[task_id], input: item[input], error: str(e) }) time.sleep(0.5) with open(run_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)批量跑测时注意三点接口要支持流式或长超时跑测之间加短延迟失败任务加入重试队列而不是直接中断。评测任务必须幂等重复跑同一条用例不应产生业务副作用。7. Agent 接口 API、日志采集与成本观测Agent 评测不能只看“对不对”还要看“贵不贵、慢不慢”。这一节关注怎么通过接口和日志拿到性能与成本数据。7.1 打通日志管道做 Agent 评测之前先确认日志里能捞到这几样数据完整对话轮次包括用户输入和 Agent 输出。每次工具调用的名称、参数、返回值摘要。每轮耗时、总耗时。prompt_tokens、completion_tokens、总 token 数。模型名称和 Prompt 版本号。如果 Agent 平台没有现成日志可以用一个装饰器或中间件在调用前后打印结构化日志落到本地 JSON Lines 文件。import json import time def log_agent_call(agent_func, *args, **kwargs): start time.time() response agent_func(*args, **kwargs) cost time.time() - start log_entry { func: agent_func.__name__, args: args, kwargs: kwargs, latency: cost, output_preview: response[:200] } with open(agent_log.jsonl, a, encodingutf-8) as f: f.write(json.dumps(log_entry, ensure_asciiFalse) \n) return response这里只是演示记录方式生产环境建议接入正式日志系统避免日志文件无限增长。7.2 成本观测表每次评测完把 token 使用情况汇总成一张成本表任务场景平均总 token平均耗时工具调用次数估算单价单次成本报销流程咨询18004.2s2按实际计费按实际计费订单查询9002.1s1按实际计费按实际计费从评估成本的角度比绝对 token 数更重要的是token 损耗率。比如同样回答一个问题Prompt 版本 A 用 1000 token版本 B 用 3000 token如果成功率没有显著提升版本 B 就需要优化。7.3 成本异常怎么看两件事要重点盯工具返回内容太长导致 context 爆炸以及 Agent 反复调用同一工具导致 token 重复消耗。这两类问题通过日志聚合一眼就能看出来评判标准是对比同一场景下不同版本的平均 token 数是否异常偏高。8. Agent 评测常见问题与排查方法做 Agent 评测过程中有几个问题会反复出现。这里整理了一张排查表问题现象可能原因排查方式解决方案同一用例跑两次结果不同模型采样温度过高或非确定性输出检查推理参数重跑 3 次评测时固定 temperature输出差异性过大时标记为不稳定长尾任务一直不收敛任务定义不清晰、缺少示例查看对话日志分析中途偏离点在 Prompt 中加入 few-shot 示例或收紧工具约束工具调用参数频繁错误工具描述粒度不够查看 tool call 参数的报错信息优化工具描述补充参数示例和边界说明Agent 反复调用同一工具上下文探测失败或没有记忆上次结果查看工具调用时间线开启上下文压缩或要求 Agent 优先复用已有信息自动判题与人工体验不一致判题标准太机械抽检自动判题结果引入 LLM-as-Judge 双判题不一致时走人工复核评测集越来越大跑测很慢全量回归没有分层统计单条用例耗时区分冒烟集、回归集、全量集按阶段选择执行范围API 偶发超时网络抖动或服务端限流查看服务日志和配额批量任务加超时重试与并发控制一个容易踩的坑是评测结果“局部复现”。产品经理在网页上试成功一条一提交自动化回归就失败。多数情况下不是代码不同而是网页前端带了历史对话上下文而自动化接口是新会话。因此评测时一定要明确声明上下文是否清空保证起点一致。9. Agent 评测最佳实践与工程化建议评测体系建设到后期比的不是单次跑测而是流程可持续性。下面几条实践比较有代表性。9.1 先人工后自动先小样后全量没有跑通少量人工评测之前不要急着写大量自动化判题脚本。先拿 30 条用例人工细分出错点把评测维度校准再扩展到 100 条、500 条。一上来就自动化通常只是在自动复制人工判断的偏差。9.2 分级回归集评测集建议分成三个级别冒烟集20 到 30 条核心用例每天改 Prompt 后跑一遍。回归集核心场景全量用例每次发布前跑一遍。长尾集低频但高风险的任务每周或每版本跑一遍。分级可以控制评测成本。比如冒烟集只需要两三个分钟适合高频迭代回归集耗时长放在夜间或发布前一天。9.3 版本可追溯每次评测跑测必须记下模型版本、Prompt 版本、知识库版本、工具 mock 版本。没有版本号的评测结果根本不具备参考价值。建议在代码仓库里给 Prompt 打 tag评测报告里直接引用对应 hash。9.4 评测资产单独管理Agent 评测的三类资产要分目录管理agent-eval/ ├── eval_sets/ # 评测集按场景分文件 │ ├── expense_report.json │ ├── order_query.json │ └── compliance.json ├── runs/ # 每次跑测结果 │ ├── 20250110_v3.json │ └── 20250111_v4.json └── reports/ # 评测报告 └── 20250111_regression.md目录结构清晰后续做趋势分析、版本对比就非常方便。9.5 评测模型也要防“作弊”如果用裁判模型自动判题要防止 Agent 输出恰好迎合裁判模型的措辞。做法是裁判模型不直接读 Agent 的最终答复而是同时读工具调用记录综合判断。另外每条评测任务建议加入验证性问题防止只测“话术”不测“工具链路”。9.6 工具 mock 环境要保真mock 数据不能太完美。如果 mock 接口永远返回统一格式、无异常、无网络延迟评测结果会偏乐观。建议 mock 环境中加入少量异常用例比如接口超时、参数不合法、返回空列表以观察 Agent 的降级行为。10. 总结与下一步做 Agent 评测最值得先做的事情有三件整理出 20 条真实场景用例并加上验收点设计一张包含结果、过程、体验的评分卡把一次完整跑测的日志存下来作为基线。这三件做完Agent 评测就从“感觉好用”变成了“有数据可讨论”。最容易踩的坑是试图一步到位建设“全自动评测平台”。上自动化之前先想清楚你的黄金答案能不能稳定、可量化地判定。如果任务本身是开放型对话强行用规则断言只能得到一个失真分数。接下来可以从三个方向继续扩展。一是把评测集规模扩大到覆盖更多边缘场景二是引入更细粒度的失败归因将错误归因到模型、Prompt、工具描述还是数据问题三是把每次评测的 token 成本和延迟纳入看板形成稳定可观测的评测基线。下次再有人问“这个 Agent 效果怎么样”你就可以直接打开评测报告指给他看成功率、工具调用准确率和成本趋势表——这比任何口头描述都更有说服力。