从偶尔成功到稳定可用：AI Agent 的评测闭环
1. 为什么 AI Agent 会“时灵时不灵”
先说说我自己的切身体会。去年年底，我带着团队做了一个面向企业内部知识库的 AI Agent 系统，核心能力是让用户用自然语言提问，Agent 自动规划检索路径、调用接口、聚合答案。内测阶段最折磨人的不是模型能力不够，而是同一个问题今天能答对、明天换个说法就翻车，有时候连着问三遍结果都不一样。当时团队里有人开玩笑说，这玩意儿跟薛定谔的猫似的，不打开对话框永远不知道它今天行不行。
这不是个例。做过 Agent 的人都有这种感受：传统软件的逻辑是确定的，同样的输入走同样的分支，输出必然一致。但 Agent 不一样，它依赖大语言模型的概率生成，模型参数没变、Prompt 没变，输出也可能漂移。更麻烦的是，Agent 会自己做工具调用，哪一步选错了工具、哪一步解析参数失败、哪一步上下文被截断，都可能让整个任务失败。这种不确定性叠加起来，就表现为“偶尔成功”。
我见过很多团队在这个阶段的第一反应是“调 Prompt”——把指令写得更长、更细，加 few-shot 示例，甚至换更大的模型。这些手段不是没用，但都属于“盲人摸象”。你没有评测体系，就不知道问题到底出在哪个环节：是意图理解错了？是工具选择错了？还是答案生成阶段的幻觉？没有量化数据，你只能靠试，而试出来的结论往往不可复现。
真正把我们从泥潭里拉出来的，是一套评测闭环。简单说，就是用一套持续运行的评测机制，把 Agent 的行为变成可量化、可追踪、可对比的数据，然后根据数据反推改进点，再验证改进效果，形成“评测—发现—修复—回归”的循环。这篇文章就把这套闭环的完整打法拆开来讲，从评测集建设、指标设计、平台搭建到线上监控，每个环节我都会结合自己的实操经历给出可落地的方案。
这套东西适合谁？我认为所有正在做 Agent 应用、尤其是打算把 Agent 推向生产环境的人，都应该看一遍。哪怕你只是用 LangChain、MetaGPT 这类框架做原型，提前建立评测意识，也能少走很多弯路。如果你已经在踩“今天行明天不行”的坑，这篇文章大概率能帮你找到堵漏的方向。
2. 先搞清楚 Agent 评测和传统评测的本质差异
2.1 传统软件测试为什么失灵
做后台开发出身的人，一开始接触 Agent 评测时会本能地想用传统测试的思路：写用例、断言输出、跑回归。这套东西在普通业务系统里很成熟，但在 Agent 场景下会碰壁。
举个例子。你给一个客服 Agent 写测试用例：“用户说’我要退款’，Agent 应该调用退款接口。”可实际上用户可能说“我不想要了”，可能说“把钱退给我”，可能说“刚买的东西能退吗”，语气和措辞千变万化。你要覆盖所有说法，用例数量会爆炸。就算你覆盖了，模型输出还有随机性，同一个输入在不同温度参数下可能给出不同的工具调用计划。基于确定性断言的测试框架，在 Agent 场景下基本是水土不服的。
更本质的区别在于，传统测试检验的是“程序是否按规格说明执行”，而 Agent 评测检验的是“Agent 是否在开放、不确定的环境中做出了合理决策”。后者没有唯一的正确答案，只有“好”与“坏”的程度差异。这就是为什么很多团队做 Agent 评测时感觉使不上劲——不是他们不会写用例，而是评测的底层逻辑不一样。
2.2 把评测当成“陪练教练”而不是“考试机器”
转型的第一步是心态。我后来跟团队说，别再想着一次评测给 Agent 打个分定个生死，评测系统的定位应该是“陪练教练”——它不是来宣判结果的，而是通过持续、结构化的反馈，帮你看清 Agent 的能力边界在哪、瓶颈在哪、改完之后有没有真的进步。
这个思路决定了评测闭环的整体架构。它至少需要四个环节：
- 评测集建设：准备一批覆盖典型场景的测试任务，标注好预期行为或评分标准；
- 评测执行：自动跑任务，采集 Agent 的中间决策过程和最终输出；
- 指标评估：用多维度的指标量化表现，给出可对比的分数；
- 结果分析与回流：把失败案例分类、归因，反哺到 Prompt 调优、工具优化、模型选型等环节。
这四个环节连成一个环，跑得越多次，系统越稳定。这也是“闭环”二字的真正含义——不是一次性评测，而是持续运转的机制。
我见过不少团队卡在“评测集建设”这一步，总觉得手工标注太费劲，想找个开源数据集一键解决。这个思路不能说错，但本地化场景的数据往往只能自己积累，开源数据集只能作为冷启动的补充。评测集的完善程度，决定了闭环的上限。这个后面会详细展开。
2.3 从“偶尔成功”到“稳定可用”需要什么
“偶尔成功”的本质，是 Agent 在大部分评测任务上通过率还行，但存在一批不确定的“灰色地带”——有时候过、有时候挂。从运营角度看，这就是可用性的致命伤：用户碰到一次失败，就可能对系统失去信任。
要走到“稳定可用”，需要的不是把平均分从 80 提到 90，而是要把失败的方差拉低——让那些“时好时坏”的任务稳定下来。这里面有两层含义：一是提高确定性，让同一任务的多次执行结果趋于一致；二是提高容错性，让 Agent 在部分环节出错时能自动纠偏，而不是让错误一路传导到最终结果。
这两点都需要评测系统给出细粒度证据。只统计“通过率”是不够的，你要能回答这些问题：失败集中在哪些场景？是第一步就错了还是最后一步错了？工具调用失败和答案错误的比例是多少？换成另一个模型后，行为模式有什么变化？没有评测闭环，这些问题只能靠拍脑袋回答。
3. 评测集怎么建：从种子用例到持续沉淀
3.1 先别追求“全面”，从真实对话里挖用例
很多团队建评测集容易走两个极端：要么随手写二三十条用例就开跑，要么花几个月时间想建一个“完美覆盖”的几百条用例集。我的经验是，两个极端都不对。起步阶段更务实的做法，是从真实用户对话日志里挖种子用例，先把闭环跑起来，再用运营节奏去持续补充。
具体操作上，我会把对话日志按结果质量分层抽样。比如先把日志按用户是否追问、是否主动结束、是否给出负面反馈分成几类，每类随机抽一批，人工判断这些对话里 Agent 的表现是否达标。达标的，沉淀为正向用例；不达标的，经过整理后变成挑战性用例。这样建出来的评测集不是拍脑袋写的，而是真实需求的映射。
抽样数量上没有绝对标准，但我建议至少覆盖你业务里最核心的 10~20 个场景，每个场景 5~10 条用例，首批 50~200 条比较合适。太少看不出统计规律，太多也不好，因为初期你的标注标准和评测脚本都在迭代，用例太多会导致改动成本陡增。
3.2 用例结构：评测用例不是一条“问题 + 答案”
写 Agent 评测用例时，最容易犯的错误是把它当成传统的 QA 对：“用户问什么，期望答什么”。Agent 是有中间决策过程的，期望输出不仅仅是最终答案，还包括过程中的行为。
我习惯给每条用例设计一个 JSON 结构，包含几个关键字段：
{ "task_id": "T-001", "description": "用户咨询订单物流状态并催促发货", "dialogue": [ {"role": "user", "content": "我上周买的东西怎么还没到？"}, {"role": "assistant", "content": "您好，请提供一下您的订单号。"}, {"role": "user", "content": "订单号是 20240115-8899"} ], "expected_tools": ["query_order_status", "create_reminder"], "expected_behavior": { "must_include": ["发货时间", "物流单号"], "must_not_include": ["补偿", "退货建议"] }, "difficulty": "medium", "scenario": "order_inquiry" }这里面expected_tools是预期调用的工具列表——注意这里的顺序可以不强制，但工具集合本身最好明确，因为工具调用是 Agent 的核心行为。expected_behavior里must_include是答案里必须包含的信息点，must_not_include是绝不能出现的内容。这两类约束比单纯比对字符串要灵活得多。
我见过有人把dialogue写得很长、很复杂，希望测 Agent 的多轮对话能力。这没问题，但建议按难度分级，从单轮到多轮再到带干扰信息的复杂对话逐级增加。评测集里全是难题也不行——你会看不清 Agent 的基础能力是否退化，所以要让简单用例占一定比例，起到“基础回归”的作用。
3.3 评测集的迭代和维护要当成“产品运营”
评测集不是一成不变的资产。线上运行的 Agent 会持续遇到新问题，这些新问题要定期打捞进评测集。我团队的做法是两周做一次评测集复盘：从线上日志和用户反馈里捞候选用例，由产品经理和开发一起评审，决定哪些进入评测集、哪些调整标注、哪些淘汰。
淘汰也很重要。有些用例一开始标注的预期行为和产品策略已经不符了，如果不及时调整，评测系统就会变成一个“阻碍创新”的东西——新 Prompt 明明更好，但因为旧用例标注过时，分数反而下降。这种问题我踩过不止一次，解决方案就是给评测集加上“有效期”的概念，定期全量审查一遍标注质量。
另外一个容易被忽略的点是防泄漏。不要把评测集里的用例直接写进 Prompt 的 few-shot 示例里，否则评测结果就失真了，Agent 等于开卷考试。我的策略是专门维护一个“训练集”和一个“测试集”，训练集用来调 Prompt，测试集只在最终评估时跑。这个划分在项目早期就要做好，否则后期溯源时会很混乱。
4. 指标设计：别被“单一准确率”骗了
4.1 功效、效率、成本、护栏四个维度缺一不可
评测指标的设计，决定了你从评测系统里能看到什么。一开始我也只盯着“任务完成率”，后来发现这个数字高不代表系统好用。举一个真实例子：我们的 Agent 有一次把“查询天气”这类简单任务完成率做到了 98%，但用户满意度并没有提升，因为大部分用户问的是多跳推理的复杂问题，而这类任务的完成率只有 60%。单一指标掩盖了短板。
后来我把指标拆成四个维度，缺一不可：
- 功效（Efficacy）：任务完成情况本身。包括完成率、信息准确率、覆盖度等。
- 效率（Efficiency）：完成任务消耗的资源。包括响应时间、工具调用次数、Token 消耗。
- 成本（Cost）：单次任务的平均成本。包括模型 API 费用、运行成本、人工介入频率。
- 护栏（Safety）：是否触及安全边界。包括拒答率、不当内容率、敏感操作遗漏率。
这四个维度像汽车的仪表盘：功效是车速，效率是油耗，成本是油钱，护栏是刹车系统。只看车速，你发现不了油耗飙升的问题；只看油耗，你可能在安全边缘疯狂试探。Agent 评测如果只看一个数字，本质上跟不看没有太大区别——因为你无法定位优化方向。
4.2 打分机制：从“硬匹配”走向分层评分
评测集里每条用例怎么打分？传统做法是匹配期望输出，但 Agent 的输出是自然语言，硬匹配几乎不可行。我的建议是分层评分，每层用不同的评估逻辑。
第一层是行为层，看 Agent 是否调用了预期工具。这一层可以用结构化比对，相对客观。第二层是结果层，看最终答案是否覆盖了关键信息点。这里可以直接人工标注，也可以引入 LLM-as-a-Judge 辅助评估。第三层是体验层，看答案是否自然、是否符合用户预期。这一层主观性最强，适合抽样评估而不是全量评估。
分数设计上不要用简单的 0/1 二分。我的做法是 0~4 分五档：0 分是完全失败；1 分是虽然没完成任务但没输出错误内容；2 分是完成了部分要求；3 分是完成了但不够好；4 分是完美。这五个档位的语义要写清楚，让标注者和 LLM 评估都遵循同一标准。为什么不用 0/1？因为 0/1 会让“部分成功”和“完全失败”混在一起，你无法判断系统是在量变积累还是质变突破。
4.3 LLM-as-a-Judge 能用，但不能盲信
LLM-as-a-Judge 已经是很常见的做法了——就是让一个更强大的 LLM 当裁判，给 Agent 的答案打分。实测下来这东西确实能省大量人力，但有几个坑必须提前知道。
第一是裁判偏差。让裁判模型对比两个答案时，它往往会倾向于语言更流畅、结构更清晰的答案，哪怕另一个答案信息更准确。我们实测过很多次，用 GPT-4 级别的模型当裁判，把答案顺序调换一下，胜负关系都可能翻转。解决方案是尽量用“绝对标准评分”而不是“相对比较”，因为你让裁判按 rubrics 打分，比让裁判二选一更稳定。
第二是自我偏好。裁判模型跟被评测模型如果是同一家公司的产品，可能对同类风格有偏好。这不是玄学，是真的存在。我的习惯是优先用一个模型家族做被评测 Agent，用另一个模型家族的模型做裁判，至少能规避一部分系统性偏差。
第三是回归验证。LLM 裁判本身也会漂移——同一个 Prompt 今天打 4 分明天打 3 分。所以每批评测跑完后，我会抽样约 10% 的案例让人工复核，统计人工与裁判的一致率。一致率低于 90% 就要检查裁判 Prompt 是否有歧义、评分标准是否需要细化。裁判质量本身也要被监控，不然闭环就建立在流沙上。
5. 评测平台怎么搭：先离线后在线，逐步自动化
5.1 架构分层：评测执行、评测数据和评估逻辑解耦
搭建评测系统的架构时，我建议一开始就把三个模块拆开：评测执行器、评测数据集、评估逻辑。这三个模块如果耦合在一起，后期迭代会非常痛苦。
评测执行器负责按配置跑任务：给定一条用例，调用被测 Agent 的接口，收集整个执行过程（包括模型输出、工具调用记录、中间状态），最终产出一份原始执行报告。评测数据集负责存储和管理用例，包括用例的版本、创建时间、标签、难度等元信息。评估逻辑负责把原始报告变成可量化的指标——它读取执行报告和评测集标注，产出完成率、得分、失败归因等结果。
这三层解耦之后，你可以随意替换其中一层而不影响其他层。比如想换一个更便宜的模型做 Agent，你只需要改执行器里的模型配置，评测集和评估逻辑完全不用动。想调整评分维度，只需要改评估逻辑，历史执行报告还在，可以重新回放评分。这比把代码写死在一起要灵活得多。
5.2 离线评测是第一优先：先把 CI 接入跑起来
我强烈建议，评测闭环的第一步是先把离线评测接进 CI，让它能自动化跑起来。这里说的离线评测，是指用固定评测集、在固定环境下对 Agent 进行批量测试。它不需要等真实用户流量，随时可以跑，是开发过程的“第一道防线”。
接入 CI 的实操方式是维护一组命令行脚本，比如用 Python 写一个run_eval.py，传入评测集的版本和 Agent 的配置，输出评测报告。然后在 CI 流水线里加一个 stage，每次代码合并前自动跑一遍关键评测集，报告里给出门禁结论——是否允许合入。这样做的好处是让评测结果直接参与开发流程，而不是等发版前临时抱佛脚。
这个阶段不建议一上来就追求全自动化评估。先人工看一部分评测结果，积累标注经验和失败案例，等到评估 Prompt 稳定了再逐步放开自动评分。我自己经历了一个过程：第一个月基本上是人工点评 + LLM 辅助；第二个月开始让 LLM 自动打 80% 的分，人工只复核临界案例；第三个月才敢把自动评分作为门禁标准。步子迈太快，容易被 LLM 裁判的随机性坑到。
5.3 在线评测要有“影子模式”：不干扰真实用户
离线评测跑顺之后，就可以考虑在线评测了。在线评测有两种玩法：一种是直接在真实流量上做 A/B 测试，另一种是先跑“影子模式”。我强烈建议先跑影子模式。
影子模式的意思是：把真实用户的请求同时发给线上 Agent 和一个候选 Agent，候选 Agent 的输出只记录、不返回给用户。这样你可以在不影响用户体验的前提下，持续收集候选版本的表现数据。线上 Agent 表现如何、候选 Agent 表现如何，用同一批真实流量做对比，这是离线评测做不到的。
影子模式唯一的代价是资源消耗——你需要多调一组模型 API。但比起上线后翻车带来的损失，这点成本完全值得。我团队用这个方案评估过一次系统 Prompt 的大改，影子模式跑了一周，用真实流量发现新 Prompt 在复杂意图场景下完成率提升了 12%，但在简单场景下有小幅回退。如果没有影子模式，这种精细的对比几乎不可能在灰度发布前拿到。
有个细节要提醒：影子模式的日志要完整记录输入、输出、推理链路，并且要能做逐条对比。我当时就踩了个坑，影子模式的日志没有记录工具调用参数，导致后面分析“为什么新版本突然表现更好”时完全无从下手。记录一定要完整，宁可多存数据，也不要事后缺字段。
6. 回归巡检：用“慢跑测试”持续守护稳定性
6.1 为什么需要定期回归：模型会漂移，系统会老化
评测闭环跑起来之后，很多人以为万事大吉了，其实还有一个隐形的敌人：模型漂移。模型提供商会不定期更新底层模型，哪怕你的 Prompt 没改，模型版本一变，行为也会跟着变。更隐蔽的是，上游数据变化也会影响 Agent 表现——比如知识库更新、工具接口字段调整，这些事情在开发时根本不会意识到。
我团队就遇到过：一个一直表现良好的工作流，突然连续两周的评测通过率掉了 5%。查了半天原因，发现不是代码改动，而是知识库里新增了一批用户上传的 PDF，检索器在召回时被这些新内容“带偏”了。如果没有定期回归评测，这个问题可能要到用户投诉才暴露。
所以评测闭环里一定要包含一个“回归巡检”环节。所谓回归巡检，就是把核心评测集定期自动跑一遍，把结果和基线对比，发现异常就触发告警。这个机制不需要每天跑全量用例——成本太高——但要保证核心用例的覆盖率，并且要有明确的分级告警策略。
6.2 巡检频率怎么定：按变更粒度分级
巡检频率没有统一标准，我的做法是按变更粒度分级：
提交级巡检：每次代码或 Prompt 变更都跑，只跑最小核心集，通常几十条，控制在几分钟内完成。这条接在 CI 里，用来挡低级错误。
夜间巡检：每天凌晨跑一次，跑全量评测集，比如 500 条左右，覆盖主要场景。第二天早上看报告，发现异常立即定位。这条负责日常监控。
周度深度巡检：每周跑一次扩充评测集，包含新收集的线上问题用例和边界用例。用来发现长尾问题，为下一轮评测集迭代提供素材。
这个分级体系在成本和质量之间做了平衡。如果每次提交都跑全量，工程师的等待时间会让人抓狂；如果只看夜间结果，问题暴露又会滞后半天。分级之后，我团队基本上能做到“提交级挡住低级错误，夜间级发现波动，周度级挖掘深层问题”。
6.3 基线管理：没有基线，回归巡检就是“空气跑”
做回归巡检，一定要先确立基线。什么叫基线？就是某个时间点、某个配置下的评测结果，作为后续对比的参照物。没有基线，你看到今天通过率 88%，明天 90%，根本不知道这个变化是进步还是回归，因为你没有参照系。
基线的管理要版本化。我的习惯是每次正式发版后，把该版本的评测结果快照保存下来，记录评测集的版本、Agent 的配置、评测时间、通过率、分维度得分等信息。后续巡检结果自动跟最近一个基线做对比，差值超过阈值就告警。
阈值怎么定？不建议定一个固定值，比如“通过率低于 90% 就告警”。因为不同场景的波动性差异很大——简单查询任务通过率应该很稳定，差 1% 就要关注；复杂多跳任务波动 3%~5% 可能都是正常的。我给每个场景单独设定告警阈值，基于历史波动数据计算标准差，超过 2 倍标准差才告警。虽然复杂了一些，但能显著减少无意义的告警轰炸。
7. 失败驱动的优化：这一点是闭环的发动机
7.1 失败归因：到底是模型不行，还是工具不行，还是 Prompt 不行
评测闭环最终的产出，是一批失败案例和归因结果。归因是整个闭环里最有技术含量的一环，也是最容易被忽略的。我发现很多团队的评测系统能跑出“通过率 75%”，但问他“剩下 25% 为什么失败”，他只能支支吾吾说“模型太笨了”——这就是归因没做好。
归因至少要拆成几层：第一层是意图理解层，看看模型是否理解用户需求，如果第一步就把意图理解错了，后面全盘皆输；第二层是工具调用层，看看模型是否选了正确的工具、是否传了正确参数，比如查天气调成了查日历，这属于工具选择错误；第三层是答案生成层，看看模型有没有产生幻觉，或者遗漏了关键信息，这属于最终输出质量的问题。
我的做法是在评测报告里增加一个error_type字段，每次执行失败时把失败类型自动打上标签。这样你就可以直接统计“70% 的失败来自工具参数错误，15% 来自幻觉，15% 来自意图理解”。下一步优化就非常明确了：集中精力修工具调用的参数解析，而不是盲目调整整个 Prompt。
7.2 每次优化只改一个变量
这一点是我最想强调的实操心得：评测闭环的核心价值是“因果可追溯”，但如果你在一次优化里同时改了 Prompt、换了模型、调整了工具定义，然后评测分数涨了，你根本无法确定是哪个变更产生了作用。
我团队内部有一条“铁律”：每次优化只改一个变量。比如这周只调 Prompt 里关于输出格式的约束，跑评测对比；下周只换工具选择的 few-shot 示例，再跑评测对比。这样做虽然慢，但每一轮改进都能精准沉淀到经验库里。
有人会觉得这样太慢、不够“敏捷”。但我的体会是，Agent 系统优化的本质是小步快跑加持续验证，一蹴而就的大改大概率引入新问题。评测闭环的价值不是让你“改得更快”，而是让你“改得更准”。每次改动后，用评测结果说话，这个习惯坚持一段时间，系统的稳定性会肉眼可见地提升。
7.3 建立失败案例库和“复活机制”
每轮评测产生的失败案例，不能评完就扔。我的习惯是把失败案例按主题入库，并定期做“复活验证”——所有已标记为失败案例的问题，在每次关键优化后重新跑一遍，看有多少从失败转为了成功。这个机制在本质上是一个“坏问题清单”，它确保你不断在向已知的短板进攻，而不是被新用例牵着走。
失败案例库还有一个用途：指导评测集的增补。如果线上出现了新的失败类型，且评测集里没有覆盖，那就说明评测集的场景设计有盲区，需要补用例。很多时候，你优化系统的速度赶不上新问题冒出来的速度，失败案例库就是连接线上和离线的桥梁。
我建议失败案例库的每条记录至少包含：对话上下文、Agent 的完整推理路径、失败的工具调用、预期行为和实际行为的对比、失败类型、当时的 Agent 配置版本。信息越完整，复盘时越省力。现在很多团队已经有自动化的 tracing 工具，把这些信息自动结构化地收集起来并不困难。
8. 线上监控与评测系统的联动
8.1 线上指标不能只看接口成功率
很多团队做监控，盯的是接口成功率、响应延迟、错误码。这些指标对 Agent 系统远远不够——因为 Agent 的接口可能返回 200 OK，但回答的内容是错的、是没用的、甚至是瞎编的。接口层面的“成功”，在 Agent 场景里可能是业务层面的“灾难”。
线上监控至少要增加几类信号：用户负面反馈率（点踩、主动退出、重复提问）、Agent 自我纠错率（是否在执行失败后重新尝试）、关键步骤失败率（工具调用失败、检索超时、解析失败）、以及会话级的完成信号（比如用户是否在对话中达成了目标，如成功提交工单、获取到有效信息）。这些信号没有标准答案，要根据业务定义，但方向上一定要从“系统健康”走向“业务健康”。
我团队的做法是把这些信号汇聚成三个大盘：一个是稳定性大盘，关注异常率、超时率、重试率；一个是质量大盘，关注负面反馈率、会话长度分布、话题完成率；一个是成本大盘，关注每会话成本、模型调用次数、Token 消耗趋势。三个大盘联合看，才能看清系统真实状态。
8.2 线上异常案例如何自动回流到评测集
线上监控发现异常之后，下一步是把异常案例回流到评测集，形成新的挑战用例。这一步如果纯靠人工，流程很容易断掉。所以我建议做半自动回流：线上监控打捞一批疑似异常案例，人工确认后一键加入评测集。
具体实现上，我会在监控系统里加一个“疑似失败”的规则，比如用户反馈负面情绪词、用户连续追问同一话题超过两次、Agent 调用了错误的工具类型等。符合条件的会话自动进入一个待审队列，每日由产品经理或测试人员过一遍，确认是真实问题的就入库。这样评测集就能跟着线上问题同步演进，闭环才真正“闭环”得住。
这里有个经验教训：自动打捞的规则要宽松，人工过滤的标准要严格。宁可多捞一些误报，也不要漏掉真正的问题。打捞规则过严，会让你对线上问题视而不见；过滤标准过松，会让评测集里混入大量噪声用例，反而稀释评测集的针对性。
8.3 模型升级前必做的一次“体检”
最后再说一个我很看重的实践：每次底层模型发布新版本，或者你想升级模型版本时，一定要先跑一次全量回归评测，再决定是否切换。大模型厂商发布新版本通常会有性能提升，但提升往往是不均衡的——某些任务变好了，某些任务可能反而变差了。你如果不亲自用你的业务场景评测，只看官方公告，很可能被带到坑里。
我经历过一次真实翻车：某个模型新版本在公开 benchmark 上所有指标都在涨，我们评估了一个核心场景觉得也不错，就直接切换到线上。结果第二天发现，这个新版本在处理长上下文时会悄悄漏掉用户早期提到的需求，导致一批任务失败。这个坑绕了三天才定位到。如果当初老老实实跑一周影子模式，可能早就发现问题了。
凡是涉及模型版本切换，我建议走一个固定流程：新模型跑全量离线评测 → 对比新旧模型的评测差异 → 挑出差异显著的场景人工复核 → 灰度切换 → 灰度期间用影子模式或小流量对比 → 确认稳定后全量切换。这个流程不复杂，但每一步都有必要，因为它把“赌运气”变成了“做决策”。
9. 常见问题速查与关键心得
9.1 踩坑记录：这段时间最深刻的几个问题
第一个坑是评测集用例质量参差不齐。一开始我们为了凑数量，找实习生写了一批用例，结果标注标准不统一，同样的任务有的人标 3 分有的人标 4 分，导致评测结果噪声很大。后来我们建立了标注规范文档，还做了双人标注一致性检测，才把这个坑填上。
第二个坑是评估 Prompt 和自己的业务 Prompt 混乱。评估用的 Prompt 里如果混入了业务上下文，会对结果的客观性产生微妙影响。比如评估 Prompt 里写了“你是一个乐于助人的客服助手”，这会影响裁判对生硬但正确回答的容忍度。建议评估 Prompt 和业务 Prompt 严格隔离，各自独立维护。
第三个坑是只关注平均分，忽略了分场景的分布。平均分从 3.2 涨到 3.4 看起来很美好，但拆开看发现简单场景涨了 0.3、复杂场景反而跌了 0.2。如果只看平均分，你甚至会误以为系统变好了。我从那以后做任何评测结论，都要求按场景、按用例类型拆开汇报。
第四个坑是忘记定期清理评测集。业务策略调整后，一些旧用例的标注已经不符合新预期了，不更新就会阻碍优化方向。我的教训是给评测集加上“定期体检”制度，每个季度做一次全量标注复核，该改的改，该删的删。
9.2 不同阶段做不同的事
如果你现在刚开始做 Agent 评测，不要一上来就搭建复杂的平台。从 Excel 表格记录评测结果开始就够了，先把闭环的最小版本跑通：几条用例、一个人工评分、一份失败清单。闭环的“环”是最重要的，规模可以后面再加。
当评测集规模超过一两百条时，再考虑上自动化评估、评测集管理和报表系统。这里的顺序很重要——先有数据意识和闭环机制，再上工具，否则工具只会放大你已有的混乱。
9.3 我个人最珍视的一个习惯
说了这么多，如果要我总结一条最重要的心得体会，我会说：把评测当成 Agent 开发的“第二大脑”。所有对系统的改动，都通过评测来验证；所有评测结果，都沉淀为对系统能力边界的认知。这个过程会逐渐形成团队的共同记忆——知道系统擅长什么、不擅长什么、哪些该改、哪些不该改。
我见过很多团队花了大价钱在模型选择、Prompt 调优、框架搭建上，却忽视了评测体系的建设。等到系统上线被用户打脸，才发现自己连“系统到底行不行”都没有一个靠谱的答案。评测闭环本身不产生价值，但它是一切优化决策的地基。把这块地基打好，从“偶尔成功”走向“稳定可用”就只是时间问题。
