27 · 失败归因、回归测试与可观测性
「AI-Agent 面试深度指南」· 模块七 · 评估与优化 · 第 27 篇 / 共 32 篇
引言
一个典型的困惑：评测分数从 82% 掉到 79%，团队花了两周调优提示词，分数回到 83%——但没人知道是哪个改动起了作用，也不知道下次会不会再掉。
这类问题源于缺了两样东西：归因能力（知道分数变化来自哪里）与可观测性（知道线上到底发生了什么）。本文讲三层内容：如何从轨迹中定位首个错误、如何建立回归测试体系、以及如何设计 Agent 的可观测性。
一、失败归因：找到第一个错误
1.1 五层归因框架
能力层：模型根本不会（推理能力不足、领域知识缺失）→ 换模型或后训练。
信息层：上下文里没有关键信息（检索未召回、历史被压缩掉、工具返回被截断）→ 修检索与上下文。
决策层：信息都有但选错了工具或参数 → 修工具描述、提示词、示例。
执行层：工具本身报错、超时、返回格式异常 → 修工程（重试、超时、校验）。
验证层：做对了但判错 → 验证器 bug（最容易被忽略，也最会误导人）。
多数线上问题落在信息层与决策层，而不是能力层。这个结论能帮你省下大量"换模型"的预算。
1.2 实操方法：从后往前回溯
注意是"第一个"错误而非"最后一个"——后续错误往往是第一个的连锁反应。
1.3 两类回归任务
端到端回归：同一任务从零跑完整流程，保证基本能力不退化。这是基础，但慢且贵。
轨迹前缀回归（Trajectory Prefix）：把历史轨迹的前 k 步作为上下文，检查模型在关键分岔点的判断是否正确：
- 作用域判断（该管什么、不该管什么）；
- 当前指令是否覆盖旧指令（用户改主意了）；
- 是否需要澄清（信息不足时会不会追问）；
- 危险动作前是否确认。
优势：更便宜、更稳定，能测出端到端测试容易漏掉的"边界判断力"。这是生产级评估的关键补充。
1.4 边界集 + 保留集
任何一次修改，都要同时在两类样本上验证：
- 边界集：这次改动应当改善的样本；
- 保留集：不应被影响的样本。
只测前者会把过拟合当成进步，只测后者会把无效修改当成安全。两套都要跑——这条原则贯穿全书，也是区分"调过参"和"做对过评估"的分水岭。
二、回归测试体系
2.1 用例从哪来
每个 bug 一条用例：修完就加进回归集，防止复发。这是最有效也最容易被忽略的来源。
生产失败案例：定期抽样回流（第 25 篇）。
边界构造：针对已知风险人工设计。
2.2 CI 中的分层执行
- 冒烟集（快、便宜）：20–50 条核心用例，每次提交都跑；
- 全量集：几百条，每日或发版前跑；
- 性能阈值：低于阈值阻断发布。
注意：Agent 评测有随机性，同样的代码两次跑分可能不同。因此设置阈值时要留出波动区间，或对关键用例要求多次运行取平均。
2.3 版本管理
评测集、验证器、prompt、工具定义都要版本化。否则你会遇到"上周 85% 这周 79%，但什么都没改"——实际上可能只是换了模型版本或工具描述被别人改了。
三、可观测性：Agent 系统的神经系统
3.1 三层数据结构
Trace：一次完整任务——trace_id、用户、总成本、最终结果。
Span：每个步骤（模型调用、工具执行、检索、人工介入）——耗时、输入输出、状态。
Metric：聚合指标——成功率、轮数、成本、延迟、工具错误率、重复调用率。
3.2 必须采集的字段
模型与版本、完整输入（脱敏后）、完整输出、token 与成本（含缓存命中数）、耗时、工具名与参数、错误类型、重试次数、用户反馈。
3.3 为什么 Agent 的观测比普通服务更难
普通服务的失败是"硬失败"（报错、超时、5xx），容易捕获。Agent 的失败往往是软失败——没报错，但做错了、做偏了、或者答非所问。
因此需要额外的软失败信号：
- 用户是否立即追问或重问（说明没答好）；
- 用户是否手动修改/放弃（复制率、放弃率）；
- 是否触发人工转接；
- 用户显式反馈（点踩）。
3.4 隐私处理
采集前脱敏（手机号、身份证、银行卡）；敏感字段哈希或丢弃；按合规要求设置保留期与删除接口。观测系统本身不能成为数据泄露的源头。
四、A/B 实验与消融
4.1 A/B 实验的五个要点
一次只改一个变量（提示词、工具集、模型、流程四选一），否则无法归因。
随机与分层：按用户或会话随机分组，避免用时间片切分（上午与下午流量不同，会引入混淆）。
样本量先算再跑：先看置信区间是否排除 0，再谈提升。
护栏指标：除了目标指标，还要监控成本、延迟、错误率、投诉率——防止"指标优化、体验恶化"。
特性开关：双层开关（全局默认 + 灰度覆盖），支持快速回滚。
4.2 消融基础设施（被严重低估）
能一键关掉某个特性（“是否使用记忆”“是否启用重排”“是否启用反思”）并跑同一评测集，才能知道这个特性的真实贡献。
很多系统堆了一堆模块，其中一半是负收益——没有消融，你永远不知道是哪一半。
4.3 提示词敏感性测试
对提示词做轻微扰动（换措辞、调顺序、换同义词）多次评测，看结果方差。方差大说明系统脆弱，需要加强结构化或补示例。这个测试的性价比极高——一次成本，长期收益。
五、从数据到改进路线图
5.1 四步法
5.2 持续改进的节奏
- 每日：看核心指标与告警；
- 每周：抽样分析 20 条失败轨迹，补充评测集；
- 每月：做一次完整消融，清理无贡献甚至负收益的模块。
六、面试考点与答题框架
6.1 高频真题
Q1：Agent 的埋点和普通后端服务有什么不同？
答：三点——① 必须记录模型输入输出完整快照（脱敏后），因为失败往往体现在内容而非状态码；② 必须记录 token 与成本（含缓存命中）；③ 必须采集"软失败"信号（用户是否追问、是否放弃、是否转人工），因为软失败不会报错。
Q2：改动后怎么确认真的变好了？
答：四步——边界集 + 保留集双验证（防止过拟合与回归）；跑够样本量看置信区间；灰度发布并监控护栏指标；保留回滚开关。若条件允许，再做一次消融，确认收益来自这个改动而非其他因素。
Q3：轨迹前缀回归解决什么问题？
答：端到端回归只能测"整体成不成"，但很多关键能力体现在分岔点的判断上（是否需要澄清、新指令是否覆盖旧指令、危险动作前是否确认）。轨迹前缀回归把历史前 k 步作为上下文，直接测这些判断，更便宜也更稳定。
6.2 加分点
- 能给出五层归因框架并指出"多数问题在信息层与决策层"；
- 能说出"软失败信号"这类 Agent 特有观测点；
- 强调消融基础设施的价值（一半模块可能是负收益）。
小结
评估的产出不是分数，而是可执行的改进假设。要得到它，需要三件事：能归因（五层框架 + 首个错误定位）、能防回归（边界集 + 保留集 + CI 分层执行）、看得见（trace/span/metric + 软失败信号）。三者齐备，你的 Agent 系统才具备持续变好的能力——这才是长期竞争力的来源。
