1. 一次凭空翻十倍的返利抽样评估为什么放跑高危故障前段时间我们在跑一个客服场景的Agent时遇到了一起让我印象很深的故障。某个用户在下单后申请退款系统竟然把89元的订单给退了890元。客服团队以为是人为操作失误查了一圈才发现是Agent在某个分支里把当前应付金额填成了原商品总价。这个分支触发的概率大概是0.4%触发条件还特别刁钻用户账号下必须同时存在两张优惠券且其中一张已经过期。我们当时的质检流程是每个版本跑200条抽样评估LLM打分四项平均过线就放行。结果那批评估里压根没出现这个场景上线后用户一投诉问题才暴露出来。这件事让我不得不重新审视手头这套评估体系的底层逻辑。传统Agent评估不管是用人工抽检还是LLM-as-judge本质上都建立在采样可信这个前提上从执行轨迹里随机抽一批打一遍分用这批样本的表现推断整体质量。但对于Agent这种状态空间极长尾、分支极多的系统来说这个前提几乎站不住脚。一个故障如果触发概率只有0.4%你在200条样本里看不到它太正常了更别提LLM打分对逻辑对但字段填错这类局部细节天然迟钝。这篇文章想分享的就是我们后续做的评估体系迭代从抽样打分变成全量trace信号扫描定向精判核心目标只有一句话——找到抽样评估会漏掉的Agent故障。我会把决策过程、数学模型、架构选型、落地踩坑都摊开讲适合正在做Agent质效、评估工具链、或者被线上故障追着跑的朋友参考。1.1 从事故现场反推Agent故障到底长什么样先把那起返利事故的日志摊开看。Agent的执行链路是这样的它先调用订单服务拿退款资格然后调用优惠计算服务算金额最后提交退款申请。问题出在第二步到第三步之间——Agent从工具返回里选择了original_total_amount这个字段而不是actual_pay_amount。更麻烦的是这个选择错误没有触发任何校验因为下游退款接口只校验金额是否为正数不校验金额是否小于实付金额。把这类故障归类你会发现它并不是响应质量差这种连续维度上的问题而是离散分支上的突变。Agent的语言能力让它能把每个步骤的解释说得合理但工具调用的参数和字段选择错一步结果就完全错了。这种故障有几个共同特征触发概率低、依赖特定的用户状态组合、不体现在最终回答的流畅度上。这也是为什么我当时意识到继续用加大抽样量的思路去堵这个口子是堵不住的。要么用巨量的样本去覆盖状态组合成本指数上涨要么换一种思路——不追求抽中而是把所有trace都记录下来用便宜信号去扫描异常找到可疑trace再让大模型精判。后者就是后文整套体系的起点。1.2 为什么人工评审也救不回来有人可能会说抽样评估不行那多上人工评审行不行。我们在做Agent质效之前也试过这条路几个经验丰富的测试同学对着trace一条条看。但问题在于Agent的trace天生就长一个会话可能是用户十几轮对话加上几十次工具调用的组合。人工看一条trace要几分钟一天能看几十条就算不错覆盖率反而比LLM打分更低。更现实的问题是疲劳产生的评审惯性。人在连续看过几十条看起来正常的trace之后再看到一条对话流畅但退款金额可疑的trace往往会顺着文本叙事滑过去因为那个错误的字段填在工具调用参数里不是显眼的那一行。我甚至觉得在长trace上LLM打分器其实也有类似的叙事偏好——它更关注Agent说的话前后是否连贯、最终回复是否礼貌对中间某个JSON字段的值是否合理敏感性非常低。所以那次事故之后我们定了一个基本原则评估流程里面向全量的机器信号扫描必须在前人在环和LLM精判只能做降维后的处理不能指望它们在海量原始trace里大海捞针。2. 摊开算一笔账想找出0.1%概率的Agent故障需要多少样本在讲架构之前我想先把采样评估为什么必然漏这个事用数学说透。很多团队不是不知道抽样会漏而是不知道漏得有多严重。这里面的关键公式很简单如果你要保证以置信度 1-α 测到至少一条故障率为 p 的故障需要的样本数大约是 n ≈ ln(α) / ln(1-p)。用这个公式算一笔账故障率1%的场景要95%置信度测到至少一条需要299条样本故障率0.1%需要2995条故障率0.01%需要接近3万条。我们当时每个版本跑200条抽样评估对应的其实是只能对故障率高于1.5%的问题有相对可靠的检出能力。而Agent线上的真实故障率有些高危问题的概率低到千分之几这个量级的差异不是靠多抽几百条能弥补的。2.1 更残酷的是非均匀采样空间上面这个公式还假设了故障在样本空间里均匀分布。但Agent真实的执行空间远非均匀用户状态、工具返回、对话历史排列组合出一个巨大无比的状态空间抽样评估的样本分布和真实流量分布有很大偏差。换句话说就算你把抽样量提到3000条抽到的3000条也可能是热门路径上的3000条而故障恰恰藏在冷门分支里。这跟传统Web测试很不一样。Web页面加载失败、接口报错这类故障通常不依赖于复杂的前置状态抽样几百个请求就能比较可靠地测出问题。Agent故障则很像特定星座下的特定天气——用户身份、优惠券状态、库存状态、时间窗口叠加起来才会触发。在这种环境下评估覆盖率必须按状态组合覆盖率算抽样条数只是一个非常粗糙的代理指标。当时我们内部做过一次实验把过去一个月全量trace分成两半从一半里随机抽200条看能覆盖到另一半里的多少个故障类型。结果覆盖率大概只有12%。这个数字让我彻底放弃了把抽样量翻倍的念头。2.2 LLM打分器本身的偏好盲区除了样本量LLM-as-judge作为打分器还有一层额外的盲区。我们对主流的开源和闭源打分模型做过一个简单的鲁棒性测试构造一批对话流畅但工具参数错误的trace让打分器评估。结果相当稳定如果最终回复是好的已经为您申请退款评分普遍偏高而如果把回复改成很抱歉退款失败哪怕失败原因讲得很准确评分都会明显下降。这说明打分器对对话体验的敏感度远高于工具执行正确性。这在早期纯对话助手的评估里有合理性但对带工具调用的Agent来说就是个巨大的误导信号。一个Agent如果每一步都调用错了工具参数但只要最终回复足够礼貌和流畅打分器照样会给高分。这让我认识到LLM打分不是不能用但只能用在已经被信号扫描锁定的小范围trace上作为第二道精确筛查工具而不是作为第一道全量过滤工具。第一道过滤必须交给确定性的机器信号这些信号虽然不完美但至少不会因为话术流畅而放过字段填错。2.3 环境依赖的故障根本无法靠离线抽样复现还有一类更隐蔽的问题部分Agent故障是环境依赖的遇到同样的输入这次执行出错下次执行可能就好了。比如某个上游工具偶发超时Agent在超时后的降级策略里选了一条错误的路径或者外部系统返回了某个特殊的空值触发了Agent的幻觉补全。这类故障你没法在离线评估集里稳定复现因为依赖的是真实外部环境的瞬时状态。用固定测试集去抽要么这次正好没复现要么复现了但无法判断是不是偶发。这是抽样评估的另一层局限它天然假设故障是可重复的、确定性的。Agent系统打破了这种假设。所以整套评估架构必须把记录trace和在线/近线信号扫描放在核心位置离线评测只能作为辅助。这是后面设计架构时最重要的认知。3. 把抽样打分改成全量信号扫描定向精判理解了盲区之后具体的技术方案就顺理成章了。我们最终落地的架构可以概括成一条管线全量记录trace机器信号初筛召回可疑traceLLM-as-judge对可疑trace做精判人工复核兜底。这条管线里没有哪一环是多余的每一环解决一个具体的信号问题。3.1 第一环全量trace事件流的落库设计全量扫描的前提是trace留存。我们在Agent框架的中间件层统一埋点把每次会话的每个关键事件都记录成结构化事件流包括用户输入、Agent的意图决策、每次工具调用的请求和返回、每一步的耗时、Agent内部的state state变化。事件流以追加写入的方式进入存储层按会话ID和时间片建立索引支持按用户、工具名、返回码快速过滤。我见过不少团队在这个环节会纠结要不要上向量数据库其实没必要。向量检索主要解决的是语义相似度搜索但故障扫描阶段需要的路径是精确过滤聚合统计普通的关系型存储或者时序存储反而更稳。我们把trace事件流存成JSONB列加索引的形式一个Agent会话对应一行工具调用嵌套成子数组够用且方便排查。存全量trace带来的存储成本问题需要提前规划。我们当时的量级是每天几万条会话每条trace几十KB到几百KB不等压缩后单日增量在GB级别完全可控。如果你们的Agent调用量再大一个数量级可以只保留原始trace七天七天以上的只保留信号抽取结果和统计聚合。原则是最近的可追溯历史的可统计。3.2 第二环机器信号初筛便宜又重要信号抽取是整套系统里最能拉开差距的部分。我们在每条trace上抽了五类信号每一类都有它的设计理由。第一类是工具调用返回码异常比如非2xx状态、超时、限流、返回体解析失败。这类信号实现最简单但噪音也最大后面会细说。第二类是重试行为偏离预期。Agent框架通常自带重试机制失败后重试是正常的。真正可疑的是重试间隙异常、重试次数远超配置上限、或者重试期间Agent改变了原有计划路径。我们用规则检测这次重试之后的动作和首次调用之前的计划动作是否不一致这个指标与故障的相关性还不错。第三类是步骤耗时异常。以每个工具调用的历史耗时分位数为基准比如超过该工具p95耗时的调用标记为慢调用。慢调用本身不是故障但如果慢调用之后Agent的逻辑分支发生了变化或者出现了超时降级就值得怀疑。第四类是意图-动作一致性。这是我们认为最核心的一类信号也是后来查出问题最多的一类。思路是每个Agent步骤在决策前会产出一个意图声明比如用户要求修改订单配送地址那么实际动作如果是调用了删除订单接口就构成意图-动作矛盾。这个一致性检测不一定要用大模型我们用了一个轻量级的文本分类模型加规则模板成本和延迟都很低但召回效果稳定。第五类是业务不变量断言。这部分必须靠业务团队提供比如退款金额不超过实付金额订单状态转换合法库存扣减次数与订单商品数量一致。这些不变量是Agent系统的物理定律一旦被打破不管指标多好看都是故障。我们把不变量配置成简单的声明式规则在信号抽取层逐条check。3.3 第三环可疑度打分与LLM精判的边界把五类信号在每条trace上汇总后会产生一个信号组合。我们做了一版梯度提升模型用几百个特征——信号是否触发、信号强度、涉及的实体类型、工具类型、出现的步骤位置——输出一个可疑度分数0到1。这个模型不需要大模型用现成的机器学习库就能训练训练数据来自历史故障标注和人工复核结果。然后关键的一步只有可疑度排在前5%到10%的trace才会被送进LLM-as-judge做精判。这样做有两个原因。一是成本全量trace如果每个都让大模型打一遍分成本至少是现在方案的十倍以上二是精确率LLM打分虽然对局部字段错误不敏感但如果你先通过信号把字段可能填错的trace筛出来再让LLM去检查这个参数值是否与上下文一致它的表现会好很多。换句话说扫描负责召回LLM负责精确率二者各自发挥优势。我们当时做过对照把全量trace直接交给LLM打分和现在的信号定向精判相比在相同成本下后者的故障检出率高出六倍左右。核心原因就是信号层已经把问题候选范围大幅缩小LLM不用再去大海捞针。4. 从可疑trace到工单聚类、回放确认与CI门禁落地把可疑trace筛出来只是第一步。如果直接把几千条可疑trace铺给开发排查整个系统会沦为告警疲劳制造机。我们在后续环节里做了三层处理分别是信号去重聚类、回放确认、和门禁语义设计每一步都有坑。4.1 同一根因只出一条工单按信号指纹聚类Agent故障有个特点同一个根因在不同trace里会表现出完全不同的表象。比如上游工具某天返回了一个奇怪的空值有的trace里Agent选择编了一个不存在的商品有的trace里Agent直接拒绝了用户请求有的trace里Agent把这个空值套到了别的字段上。如果单纯按错误信息去聚会得到几十个不同症状但根因只有一个。我们的做法是为每条可疑trace生成信号指纹。指纹由几个维度拼接而成主要触发的信号类型、涉及的实体类型订单类、用户类、商品类、工具名集合、错误消息的前缀、Agent发生决策变化的步骤位置。然后按指纹聚类同一个指纹簇只生成一张工单。工单里附带簇内代表trace、触发信号明细、涉及的不同症状列表。这个聚类思路需要反复调优。指纹太粗会把多个真实故障混成一条工单指纹太细又会一个故障拆成几十条。我们最终没有用严格的参数化聚类而是先按指纹分桶再让一个轻量聚类模型在桶内做一次合并效果比较稳定。另一个实用技巧是阈值可以动态调整故障量大的时候收紧指纹让一张工单的覆盖面更小故障量小的时候放宽避免漏掉关联故障。4.2 离线回放确认有些可疑是外部抖动可疑trace聚成工单后我们不会直接让开发去排查而是先进沙箱环境做一次回放确认。流程是把trace的输入、上下文、上游mock数据在沙箱里重新跑一遍看能否稳定复现同样的异常动作。选择mock数据时要注意必须尽量还原原始trace里的工具返回时序否则可能复现失败误判为偶发现象。回放确认这一环的价值在于过滤外部抖动。比如某个上游接口那几次真实调用超时了Agent降级策略选择了一个另类路径这在信号层看是可疑的但根本原因在上游不在Agent本身。回放时如果mock出正常的响应Agent的决策路径变得正常那这个信号就可以标注为外部异常导致的级联行为转给上游团队处理而不是扣在自己头上。当然不是所有故障都能稳定复现。对不可复现的可疑trace我们会保留在一个候选池里观察它在后续时间窗内的复现频率。如果某个不可复现的可疑模式在两个小时后的新数据里又出现了那它大概率不是偶发需要升级处理。这种时间窗聚集的判断方式帮我们抓到了几起上游服务劣化的早期信号。4.3 接入CI门禁门禁阈值不能只看故障数回放确认之后的工单会进入一个评估池最终在每次发版前做一次故障趋势门禁。我们把门禁接在CI流水线里阶段内容是拉取最近一批金丝雀流量trace或离线回放集跑一遍信号扫描和聚类统计新增可疑信号簇的数量。如果新增簇数超过配置阈值流水线阻断要求相关负责人在工单台里确认风险等级。这里有个特别容易踩的坑门禁阈值不能直接设成可疑工单总数小于N而要设成新增工单数小于N。原因很简单每次修复了一个老故障往往会连带暴露两三个新问题。如果你按总数设阈值修复完一批故障后总数不降反升流水线直接卡死团队会因此开始恨这套系统不出两周就会有人偷偷绕过门禁。我们最后用的是新增高危信号簇数量作为阻断条件同时把中等风险簇做成告警不阻断。高危的定义也简单粗暴与金额、权限、订单状态这类强业务不变量相关的信号默认高危其他信号默认中危。这样既保证核心风险被挡住又给团队留出修复问题的喘息空间。5. 跑完三个月之后哪些信号真有价值哪些在制造噪音架构上线之后的三个月是我们迭代最密集的阶段。前面设计的每类信号在真实数据里的表现和我们最初的设想并不完全一致。这里把实测数据摊开可以给后来人省下不少调优时间。当时生产环境日均采集几千条Agent trace累积十二万条左右。原有抽样评估流程200条/版本在这三个月里累计识别出9类故障全量信号扫描加定向精判额外识别出34类故障其中7类被业务方评估为高危。最典型的还是那类字段选错但对话流畅的问题扫描发现的数量远超预期。可疑trace占比大约8%也就是说每100条trace里有8条会触发至少一个信号。但这8%经过LLM精判和人工确认后只有三分之一左右被认定为真实故障。三分之二的误报来源主要是重试和超时信号错杀和业务不变量断言覆盖不全。5.1 信号有效性排序意图-动作一致率排第一从数据看信号的有效性排序很清楚。意图-动作一致性虽然在工程上实现起来最麻烦但产出最大。这类信号抓到的问题基本都是Agent规划层面的缺陷比如用户要求修改地址Agent调用了删除订单接口用户问订单状态Agent调用了创建售后单接口。这些问题一旦出现造成的业务影响通常很直接。第二位是状态跳转异常。我们的Agent内部有状态机某些状态转换在配置里不允许发生。当trace里出现未定义状态跳转时基本可以确认存在规划逻辑漏洞。这类信号数量不多但置信度极高几乎没有误报。第三位是工具返回码和重试行为。这类信号每天都会触发大量可疑标记但真正构成故障的比例不高。比如一个工具偶尔超时Agent自动重试一次成功了这其实是正常行为。如果重试策略按指数退避执行且最终成功就不应该被当作故障。我们后来在信号规则里专门加了一条以最终是否成功作为是否升级判定的先决条件误报数量立刻降下来了。步骤耗时排在最后它对性能类问题如Agent响应越来越慢有效对逻辑类故障几乎没有帮助。而且耗时信号容易受上游服务性能波动影响单独使用价值很低。我们后面把它降级为辅助信号只在与重试、超时信号同时出现时才会计入可疑度。5.2 误报率控制的几个关键经验误报率从三分之二降到三分之一经历了三个关键调整。第一是重试信号的重定义。前面提到最终成功是个好用的缓冲条件但还不够。我们后来又加了一条重试后Agent的执行路径是否与首轮计划一致。如果重试成功且后续路径一致基本排除故障如果重试过程中Agent改变了对某个参数的取值或者跳过了某个必要步骤即便最终成功也要标记为可疑。这条规则帮我们抓到一类隐蔽故障Agent在第一次调用失败后会主动用猜测值去填充参数靠碰运气绕过失败。第二是业务不变量的精细化。业务方最初提供的不变量断言只有金额类后来我们推动他们把订单状态机、库存约束、用户权限约束都配置进去。这些业务规则的引入让信号层能发现更多语义上的异常而不只是执行上的异常。第三是过滤已知的正常奇异路径。会有一些长期存在的、已知正常的业务分支在信号层看起来非常可疑。比如某些B端客户有特殊的审批流Agent会故意走一个绕过余额检查的合法业务流程。这类trace如果不加白名单会反复触发信号造成大量重复工单。我们在工单台里加了确认正常后加入白名单的操作白名单会同步回信号抽取层作为特征参与训练。5.3 容易被漏掉的两类Agent故障场景复盘过程中有两大类故障是容易被传统思路忽略的这里单独提一下。第一类是工具返回成功但内容可疑。很多监控只在工具返回出错时告警但如果工具成功返回了一个空列表Agent编造了一个不存在的订单号继续往下走这类故障从返回码层面完全看不出来。我们的对策是给关键工具配置响应内容的合理性断言比如退货接口的返回订单号必须与请求订单号一致库存接口返回商品数不能为负数。这些断言不复杂但需要工具设计和业务知识配合。第二类是跨trace的群体性异常。单个trace看一切正常但如果同一时间段内大量Agent都在同一个工具步骤上耗时变长或者大量Agent都在某个上游返回空值后选择了退而求其次的路径这就是群体性劣化的早期信号。我们后来加了一层按工具分组的时序聚合监控它不看单条trace的可疑度而是看信号激增趋势在集群层面的灵敏度比逐条扫描高得多。6. 给想自己搭这套体系的人几条实在建议如果你看完前面这些准备在团队里也搭一套类似的评估体系下面几条建议是我踩了三个月坑之后的真实体会按优先级排序。先别急着上模型把trace存全再说。没有全量trace后面所有信号扫描、聚类、回放都是空中楼阁。即便你一开始只能存七天原始trace也要先把这个习惯立住。很多团队一开始觉得存储成本高但Agent系统的调试和故障复盘如果缺少trace成本远比存储高得多。建议在Agent框架的中间件层统一埋点不要依赖每个业务场景自己上报否则覆盖率永远参差不齐。信号设计要贴近业务不变量。通用信号能兜底但真正能让这套体系在业务方那里建立信任的是那些懂业务的人提供的断言。金额守恒、数量守恒、状态机合法性这些高价值信号几乎每个Agent业务都能提炼出几条。推动业务团队把脑子里那些这肯定不会错的常识固化成断言规则比调十版机器学习模型都管用。阈值按分位走不设硬编码。不同业务、不同工具的正常耗时有几个数量级的差异硬编码阈值会带来大量误报。统一用历史数据的分位数比如p95、p99作为基线并定期重算基线。这个方法简单但极其有效我们内部所有耗时限值都是动态分位没有一处写死。扫描层别用大模型大模型只在精判层用。信号抽取和可疑度排序完全可以用规则加轻量模型完成大模型上得太早成本和延迟都会变成瓶颈而且大模型自身的波动性会在信号层引入噪声。保持扫描层确定性优先、精判层语义理解优先的职责划分系统才可控。最后提醒一下隐私和合规问题。Agent trace里往往包含用户输入、订单信息、账号信息信号抽取层之前一定要做脱敏处理比如把手机号、地址、姓名替换成脱敏占位符。这个在架构设计初期就要考虑否则后期数据治理会很难受。我对这套体系最满意的一点就是它不再执着于让评估集更大更全而是承认抽样评估的固有盲区转而在全量数据上做低成本的异常信号发现。这背后的理念也延续到了我们后续的Agent调试流程里出了问题先去翻trace看信号而不是先怀疑模型不行。如果你也正在被为什么测试都过了线上还是出事困扰不妨从今天开始先把Agent的每一条执行路径完整记录下来再去想怎么从中找出问题。
