AI Agent稳定性突破：构建评测闭环的完整指南

做 AI Agent 的朋友应该都有过这种经历上午还跑得好好的流程下午就突然断在一个工具调用上同一个请求连发三次三次结果都不一样改了某个提示词这个场景通过了另一个场景反而崩了。这种“偶尔成功”的状态是 Agent 落地前最让人头疼的阶段。而打破这个局面的关键不是堆更多模型技巧而是把评测做成一条真正的闭环——从定义标准、跑批评测、分析失败到回归验证让每一次改动都有数据说话让稳定性从“靠运气”变成“可管理”。这篇文章我会从评测闭环的核心设计讲起结合实操经验逐步拆解怎么构建测试集、怎么定判分标准、怎么跑回归、怎么从失败中挖出问题。不管你是正在调 Agent 的开发者、设计智能体应用的产品经理还是负责质量保障的测试工程师这套方法都能直接拿去做参考。1. 为什么 AI Agent 总会“偶尔成功”1.1 传统测试方式管不住 Agent很多人最开始调试 Agent用的还是传统软件那套思路给几个输入看输出对不对错了就改改完再跑一遍。这套思路在常规业务系统里没问题因为传统系统是确定性的——同一个输入必然得到同一个输出断言结果稳定可复现。但 Agent 不是这样。Agent 的核心是模型推理加工具调用模型天生带概率性即使输入完全相同输出也可能有细微差异甚至出现更理想或更离谱的结果。再加上任务拆解路径的多样性、外部接口响应的不稳定性整个系统变成了一个“在不确定性中寻找确定结果”的系统。用传统测试的思维去管这种系统会发现永远测不全、测不稳今天通过明天挂根本没有抓手。1.2 “偶尔成功”的三个根源从我的实操经验来看Agent 表现飘忽不定原因基本落在三个层面。第一层是模型概率性。采样温度、模型版本波动、上下文长度变化都会影响生成结果。很多团队会把温度调到 0但即使这样某些模型在复杂推理下仍然有随机性只是波动幅度变小而已。这意味着单次验证根本不足以说明问题必须靠批量抽样观察分布。第二层是规划链路的不稳定性。Agent 在跑一个任务时会经历“理解任务 → 拆解步骤 → 选择工具 → 解析结果 → 决定下一步”的循环。任何一个环节要是给出次优选择、选了错误的工具或者解析外部数据出错整个决策链就偏了。这种错误往往不是逻辑上有 bug而是模型的规划能力在特定场景下不够稳导致同样的任务有时候走通有时候绕弯路甚至卡死。第三层是环境和上下游的不可控。外部 API 的响应延迟、返回字段的变化、限流策略的触发都会影响 Agent 的执行结果。很多时候你改好了 Agent 自身的逻辑但上游接口抖动一下评测就失败了。这类失败容易被误判为 Agent 问题导致你白改一通。所以评测闭环的第一步就是要先把“环境因素”和“自身逻辑问题”分开。1.3 评测闭环到底在解决什么问题一句话总结评测闭环解决的是“不可见”的问题。Agent 的内部决策链条复杂如果你只盯着端到端的成功或失败很难定位是哪一步出了问题。评测闭环通过结构化的测试集、多维度的得分体系、逐条失败分析和回归对比让系统表现变得可见、可量、可追踪。有了这个闭环每一次改动是好是坏不再靠感觉而是靠数据稳定性也从“碰运气”变成了可以持续优化的工程指标。我见过不少团队把大量精力花在调提示词上但因为没有系统评测经常是改完 A 场景、坏了 B 场景团队就在这种“修东墙补西墙”的循环里消耗。评测闭环的价值恰恰在于用一套可重复的流程打破这个循环让优化方向始终朝着“整体变好”而不是“局部变好”走。2. 评测闭环的整体设计与思路拆解2.1 闭环的五个关键环节一条完整的 Agent 评测闭环通常由五个环节组成基线建立、用例设计、评测执行、失败分析与修复、回归验证。这五步形成一个环形结构跑完一轮之后用例库会更新基线会刷新然后进入下一轮循环。我在这里想特别强调一下“基线建立”。很多团队上来就建测试集测完发现一堆失败然后就开始瞎改改完再测但根本不知道自己改完是变好还是变坏。基线的作用是让你有个参照物先把当前版本完整跑一遍记录得分和失败用例分布后续每次改动都在同一套用例上跑对比得分差异。没有基线的评测就像没有起点的地图你走了半天也不知道自己在往哪走。2.2 评测维度不要只看一个成功率只看成功率是 Agent 评测最常见的误区。成功率当然重要但它太过宏观下调一个维度评测才有信息量。我实际在用的评测维度有五个任务完成率、稳定性、鲁棒性、安全性、执行效率。任务完成率好理解就是端到端跑通的比例。稳定性则是重复运行的一致性——同一个任务跑 N 次结果和中间路径的相似程度。比如一个查询任务跑 5 次有 3 次成功这是成功率的问题但如果 5 次都成功其中 3 次用了不同的工具和思路这就是稳定性问题。鲁棒性考察的是输入变化时系统还能不能正常工作比如换个措辞、换个数、加个无关信息Agent 是否依然能正确响应。安全性关注的是 Agent 会不会越权、有没有被提示词注入、会不会生成敏感内容。执行效率则包括平均耗时和 Token 消耗——一个任务要绕路 10 次工具调用才能完成和 3 次完成体验和成本完全不一样。这五个维度不是并列关系而是不同角度的观察。真正做闭环的时候你需要根据业务阶段设定权重。早期重点看任务完成率中期开始关注稳定性和鲁棒性上线前夕则必须把安全性和效率纳入门槛指标。2.3 指标之间的权衡逻辑多个指标放在一起必然会出现权衡。拿任务完成率和执行效率来说很多 Agent 为了提高成功率会加入“重试”机制失败一次就换个思路再来。结果成功率确实上去了但平均耗时翻了一倍。这时候你要问自己这个场景里用户更在意什么如果是内部自动化流程稳定性优先多花点时间可以接受如果是前台对话机器人拖沓的响应反而会造成用户流失那就要在“一次成功率”和“响应时延”之间找平衡。评测闭环的好处是这些权衡不是靠感觉拍板而是可以用折线图看趋势。比如连续几轮迭代里成功率在上升但 Token 消耗也在飙你就知道需要在某个节点停下来专门优化效率。这种数据驱动的取舍才是闭环的核心价值。3. 测试集怎么建固定集加动态集搭配3.1 固定集主链路的守护者测试集是整个评测闭环的基石。没有一套贴合业务场景的测试集后面所有环节都是空中楼阁。我的做法是把测试集分成两大部分固定集和动态集。固定集是核心业务主链路的真实场景用例数量不用特别大但每一条都要有代表性。这些用例一旦确定基本保持不变每次迭代都要跑。它们的作用是防止回归——确保你改了某个提示词或者调整了工具编排之后原本好用的核心流程没有退化。固定集的建设方式有两种。第一种是从线上日志里筛高频场景比如用户问得最多的 50 个问题或者业务核心链路里最关键的 30 个任务。第二种是把历史踩过的坑沉淀成用例例如之前某个任务经常失败修复后就可以把对应场景固化下来防止复发。我建议至少准备 50 到 100 条固定用例太少没有统计意义太多跑批成本会很高。在固定集里需要特别注意覆盖的均衡性。不要只放简单场景那会虚高得分也不要只放极端难题那会让团队失去信心。按实际业务分布来配比简单、中等、困难场景各占一定比例评测得分才反映真实水平。3.2 动态集探索边界的探针动态集的定位和静态集不同它不是用来守成而是用来发现未知问题。动态集的用例会持续更新通常来自线上真实流量采样、竞品对比场景、模型失败案例的转化以及一些边界测试和对抗性输入。我比较推荐的做法是每周从线上日志里采一轮新场景把真实用户的提问去敏后放进动态集。这么做的好处是测试集不会停留在构建完毕那一天的状态而是跟随业务演进而成长。很多问题你事先根本想不到比如用户用了一种完全没见过的说法或者把多个需求混在一个请求里只有真实流量才能帮你暴露这些盲点。动态集还有一个用途就是防过拟合。如果一套用例跑太久模型和提示词很可能已经在这个集合上过度适配了得分虚高但实际能力没有提升。定期从动态集抽新用例加入固定集可以把这种“作弊”空间压缩到最小。3.3 用例分级与跑批策略测试集建好之后还需要分层级管理。我一般把用例分成三个等级冒烟集、核心回归集、探索扩展集。冒烟集是每次改动后最快跑的数量少例如 10 到 20 条任务是 10 分钟内确认“基本功能没有坏”核心回归集是固定集加上最新沉淀的动态用例每次正式提交前跑全量作为发布质量门禁探索扩展集则是动态集里还未沉淀的部分每周跑一次主要用来发现问题决策是否回补进回归集。分级的意义在于控制成本。Agent 评测的跑批速度比传统自动化测试慢很多一个任务可能要几十秒甚至几分钟。如果每次改一个标点符号都要跑全量工程师早就没有耐心了。分级之后日常开发用冒烟集挡大问题阶段性发布前再跑全套效率和覆盖都兼顾。4. 谁来判分规则、模型与人工的三层体系4.1 规则判分确定性优先测试集跑完只是一半另一半是结果评价。Agent 的输出是自然语言和工具调用序列怎么判断它做得好不好是整个闭环里最容易产生争议的地方。我的原则是能规则判分的优先用规则规则判不了的交给模型模型拿不准的由人来仲裁。规则判分适合有明确格式标准的任务比如输出必须是 JSON、工具调用参数必须包含指定字段、返回结果必须和期望值精确匹配。这类检查用代码就能完成速度快、结果稳定、没有争议。开发评测框架时我建议把能用规则验证的部分全部用规则验证这样可以省下大量模型判分成本也为后续模型判分提供结构化依据。4.2 模型判分LLM-as-Judge 的操作细节对于开放式任务比如“给用户的产品文案提出改进建议”或“根据文档生成一份摘要”规则就无法覆盖了这时候要用模型判分也就是大家说的 LLM-as-Judge。用一个能力较强的模型充当裁判按照预先定义的标准给 Agent 的输出打分或者给出好坏判断。模型判分看着省事实际用起来坑很多。裁判模型同样有幻觉、偏好和一致性波动问题而且对提示词的依赖非常大。我用模型判分时有几个固定习惯第一评分标准要写得足够细把“好”“中”“差”对应到可观察的行为特征上不能只让裁判模型凭感觉打分第二给裁判模型设置思维链让它先描述看到的现象再给分大幅减少乱喷现象第三设置参考样例在评分提示词里附上几个标准答案示例让裁判模型对齐尺度第四温度和采样参数固定不然裁判自己都在波动你还怎么判断 Agent 稳不稳定。4.3 人工仲裁与校准机制规则和模型判分再完善总会有边界情况。我的做法是把人工放在“仲裁层”而不是“主判层”——也就是全量评测由规则和模型完成但会按比例抽检例如每批评测抽 10% 的失败用例和 5% 的成功用例由人来复核。如果人工复评和模型判分的结论不一致就在评分标准里找原因通过调整评分提示词或补充评分规则来校准。这里有个关键指标要盯住人工仲裁反判率。如果人工抽查发现模型裁判打错分、打分不合理的比例超过一定阈值那说明整个评测体系本身不可信。此时应该停下迭代优化先修评分体系再谈 Agent 优化。先稳住一把准的尺子再量东西这个顺序不能颠倒。我见过一些团队花了很大功夫建了评测集最后卡在裁判模型上每次评测结果都不稳定同一个输出这次给高分下次给低分。折腾几轮之后团队对评测失去信心直接回归到“拍脑袋改参数”的状态。避免这个局面关键就是先在判分环节建立可信度再谈其他。5. 从零落地一套评测闭环的实操过程5.1 跑通最小闭环的框架搭建说起来都懂做起来才是真功夫。我在这里给出一个可落地的路径照着这条路走半天到一天就能把最小闭环跑起来。第一步先搭一个评测执行框架。不需要多重的平台一个能加载配置、执行用例、收集结果、输出报告的脚本就够用。我给你一个极简的骨架参考import json from dataclasses import dataclass, asdict dataclass class EvalCase: case_id: str prompt: str expected: dict dataclass class EvalResult: case_id: str actual: dict rule_score: dict judge_score: dict class EvalRunner: def __init__(self, cases, agent, judge): self.cases cases self.agent agent self.judge judge def run_all(self): results [] for case in self.cases: actual self.agent.run(case.prompt) rule_score self._rule_check(case, actual) judge_score self.judge.evaluate(case, actual) results.append(EvalResult(case.case_id, actual, rule_score, judge_score)) return results def _rule_check(self, case, actual): # 这里写具体的格式校验/字段匹配逻辑 checks { has_required_fields: actual[tool_calls][0][name] case.expected[tool] } return checks这个骨架虽然不是完整代码但把关键逻辑捋清了用例定义、执行、规则校验、模型判分、结果收集。你实际搭建时把 Agent 调用接口和 Judge 调用接口改成你自己的实现核心结构可以直接照搬。第二步定义你的评测配置。配置里包括使用哪个模型版本、温度参数是多少、重试策略怎么设、超时时间多长。这些参数必须全部固定下来否则评测结果会被环境变量污染。我踩过最典型的坑就是模型版本悄悄升级了评测得分一夜之间变了几个百分点排查半天才发现不是 Agent 的问题。第三步把第一版测试集灌进去跑第一轮全量评测得到基线得分。先不急着优化把基线落进历史记录表里作为后续对比的锚点。5.2 从失败用例中定位问题模式跑完第一轮评测工作才算刚开始。我强烈建议你不要只看整体得分而是把全部失败用例拉出来逐条过一遍。看失败用例时先做分类而不是单点分析。我常用的分类维度有任务理解失败、工具选择错误、工具调用参数错误、结果解析错误、外部依赖超时、输出格式不符合预期。把失败用例打上标签之后按标签聚合统计你会立刻看出问题主要集中在哪个环节。举个例子假设 30 条失败用例里有 18 条都集中在“工具调用参数错误”那就说明 Agent 在参数生成环节有系统性问题。这时候你去翻具体日志很可能发现它总把某个字段的值从字符串当成了数字或者某个可选参数老是遗漏。对照分类去修效率比一条条瞎试高得多。在定位问题的时候务必把 trace、中间结果、工具返回值都记录下来。很多 Agent 失失败之后日志只留下最后一段输出中间的规划决策过程全丢了这样就很难定位问题。我的习惯是评测框架里直接内置 trace 收集机制每个步骤的模型输入输出、工具请求和响应都落盘哪怕不是每次都要看出了问题也能回溯。5.3 迭代优化与回归验证修完问题之后需要回到闭环的最后一个环节回归验证。把改动重新在固定集上跑一遍对比基线的得分变化。这里要特别注意一个现象单点变好不代表整体变好。有时候改了一个提示词原本失败的场景通过了但同样模型思考链路在其他场景下可能引入了新偏差导致其他用例反而失败了。回归对比的价值就是让你在合并改动之前从数据层面确认“净收益是正的”而不是凭感觉说感觉改得不错。当回归验证确认改动有效之后顺手做一件事把新修复的场景固化成用例。如果这条场景之前在测试集里没有覆盖到赶紧补进去防止下次又踩同样的问题。这一步是评测闭环真正螺旋上升的动力来源——每修一个错就补一条用例代码就不会反复在同一个坑里打转。5.4 回归报告建议的呈现形式评测报告不一定要做成高大上的可视化看板但至少要包含三个部分总体得分对比、失败用例分布、本次改动说明。总体得分对比回答“变好了还是变坏了”失败用例分布回答“问题集中在哪里”本次改动说明回答“是什么导致了变化”。我在内部一般用一张表格来对比版本差异指标上一版本本版本变化任务完成率72.6%78.3%5.7%平均工具调用次数6.25.1-1.1平均耗时34.8s29.6s-5.2s规则判分通过率88.0%91.5%3.5%模型判分均分3.6 / 5.03.9 / 5.00.3有了这样的表每一次迭代是好是坏一目了然。沉淀三个月之后你还能从趋势图上看出哪个阶段的改动效率最高哪个维度长期没有进步便于安排后续优化重点。6. 常见问题与避坑实录6.1 评测中容易踩的坑速查表问题典型症状根本原因解决建议评测结果波动大同一版本两次跑分差异超过 5%模型参数没固定 / 测试环境不隔离锁定模型版本温度设为固定值固定超时和并发参数提示词过拟合测试集得分高线上表现差测试集长期不变模型已经在上面过拟合定期轮换动态集保留一个不外传的 holdout 盲测集裁判模型打分不一致同一个输出本次给高下次给低评分标准模糊裁判模型提示词不稳定细化评分标准加入参考样例模型判分启用思维链环境波动导致误判外部接口超时Agent 被判失败上下游依赖不稳定被当成了 Agent 逻辑问题评测框架里加环境健康检查不把环境失败计入 Agent 得分用例质量差失败用例看不出规律修了也没用用例本身不贴近真实场景或者描述有歧义用例尽量从真实日志采样避免人工臆造题目评测速度太慢全量回归要跑几小时团队不想跑用例数量大执行串行没有分级策略冒烟集快筛全量回归降频必要场景做外部依赖 mock6.2 评测过拟合比想象中更隐蔽上面表里提到了过拟合这块想再展开一下。模型和传统程序有一个很大的区别模型会“记住”你的测试集。如果你在提示词开发过程中反复使用同一套用例做调优模型会在这些特定的输入上表现越来越好但换一个说法、换一组新输入立刻打回原形。对抗评测过拟合我目前觉得有效的办法有三个。第一是维护一个不会进入开发视野的 hhm盲测集只在关键节点用来做一次总线验证平时不给任何人看防止它被潜移默化地影响。第二是定期从线上采新用例把动态集中的新鲜血液补充到回归集里保证版本更新的同时用例也在更新。第三是做输入扰动对现有用例做少量改写比如同义词替换、语序调整、增加无关前缀让模型没法单凭记忆应付。盲测集的维护有一点要注意不要用开发时反复筛选用例的同一个模型来生成盲测集尽量使用人工和真实线上数据构建不然盲测的可信度会打折扣。6.3 评测体系自身的可信度维护评测闭环建好之后很容易出现一个问题团队过度信任评测结果把“评测通过”等同于“上线安全”。从我的经验来看评测体系本身也需要维护不是一锤子买卖。我在项目里会定期检查评测体系自身的有效性最直接的指标就是人工仲裁反判率。每个迭代周期我抽一部分模型判分的案例让人复核检查判分标准是否还在有效执行有没有出现尺度漂移。同时还会追踪一个关键数据线上实际失败率与评测内预估失败率之间的差距。如果线上表现长期比评测结果差很多大概率是评测集覆盖度不足需要回填更多线上真实数据。6.4 稳定性追优时的取舍清单做 Agent 稳定性优化的过程中很容易迷失方向因为可调的参数太多了提示词、工具定义、模型版本、温度、规划策略、重试逻辑每一个都有多种改法。我把自己的取舍判断整理成一张检查清单每次优化前会过一遍先确认你衡量“稳定”的核心指标是什么是一次成功率、失败重试率还是结果一致性再确认这次改动的影响范围是不是只在目标场景内生效会不会影响其他场景接着要评估改动代价新增的规则或工具调用会不会让单次响应的成本和时延明显上升最后要意识到有的问题适合在 Agent 层修有的问题必须治理上游解决前先分清问题的归属不要总想着用提示词跟外部依赖波动硬碰硬。开发 Agent 最大的乐趣之一是你永远有东西可以调、可以试但也正因为这样很容易陷入“盲目调参”的陷阱。评测闭环的意义就是用系统性的流程把每一次尝试变得有据可依。从偶尔成功到稳定可用没有捷径唯一的正路就是让质量可见让问题可控让每一次修改变得可追溯。