它通过了CI，也通过了你的评估。客户拿到的却仍是错误答案。
内容提要
AI功能存在可观测性缺口：传统服务故障明显，AI代理却会静默返回错误答案。以支持代理为例，通过分布式追踪可定位问题——检索时版本过滤为空导致返回旧版文档，而忠实度评估无法发现。建议用确定性测试断言检索约束，用模型评估答案质量，并保留提示、模型、检索配置等上下文，将评估结果链接回追踪。
延伸解读
AI代理的静默失败与可观测性缺口
传统服务故障会以500错误或延迟飙升等形式明显暴露，而AI代理即使返回200并通过忠实度检查，仍可能给出错误答案。文章指出，这种静默失败无法通过常规告警捕获，需要从运行系统中获取证据。Dynatrace报告显示，77%的平台工程团队在部分服务中嵌入了可观测性，但仅40%在所有部署中完全集成，这一缺口在AI场景下成为隐患。
从追踪中定位检索约束缺失
支持代理案例中，客户请求2026.3版本的导出配置，但检索工具调用时product_version为null，返回了2024.1等旧版本文档。分布式追踪显示三次重复搜索和空版本过滤，但忠实度评估仍通过，因为答案忠实于检索到的文档。问题根源是检索前置条件未被断言，而非生成失败。这提示需要区分相关性评估与有效性检查。
确定性测试与模型评估的分工
文章建议用确定性测试断言检索约束，例如直接调用search_docs并验证返回文档的版本元数据，无需模型参与。对于答案质量，则使用模型评估，并保留提示版本、模型ID、检索配置和文档版本等上下文，通过追踪和跨度ID链接评估结果。注意OpenTelemetry API在跨度结束后忽略属性更新，因此评估结果应作为独立链接结果存储。
修复验证与持续监控的要点
修复后需针对行为变化添加回归测试：重复搜索应测试但不锁定单一工具序列，版本过滤应覆盖当前版本、旧版本、无关文档和无支持答案等场景。答案评估需多次运行以应对输出波动。发布后应同时观察延迟、任务成功、工具调用和令牌数，避免将工具调用减少或令牌下降误判为改进，它们也可能意味着遗漏了必要步骤。
Q&A
为什么AI代理的故障比传统服务更难被发现？
传统服务故障会明显报错，如500错误、延迟飙升或依赖无响应；而AI代理会静默失败，返回200状态码并通过忠实度检查，但客户仍得到错误答案。你无法对“错误”设置警报，需要来自运行系统的证据。
在支持代理案例中，分布式追踪如何帮助定位错误答案的根源？
通过分布式追踪可以查看一次受影响运行的轨迹，包括每个模型调用和工具调用及其参数与结果。案例中追踪显示三次相同的搜索调用，且参数中product_version为null，导致返回旧版本文档（2024.1、2023.9），而请求版本是2026.3。追踪还显示搜索之间没有模型调用，表明是执行框架而非模型发起了重试。
为什么忠实度评估无法发现版本不匹配的问题？
忠实度（或 groundedness）只评估答案是否由提供的来源支持，不评估来源本身是否正确。案例中答案准确复述了检索到的文档，因此忠实度通过，但文档是旧版本，对客户请求的版本无效。检索评估器也无效，因为旧版本文档与查询相关，只是对请求版本无效。相关性不等于有效性。
如何用确定性测试防止检索版本过滤缺失？
可以编写不涉及模型的确定性测试，直接断言检索函数的行为。例如，提供带版本元数据的文档夹具，调用search_docs并断言返回的文档版本全部等于请求版本。这种测试廉价、确定性强，适合放入CI。
评估AI功能时为什么需要保留上下文？应保留哪些信息？
因为评估需要可追溯，以便事后复查答案。应记录提示版本、模型ID、检索配置、文档ID和版本，并与发布关联。保留足够的允许证据以便回读答案，敏感内容在导出前脱敏。通过trace和span ID链接结果。如果评分在span关闭后完成，应存储单独的链接结果，而不是写入已结束的span。
修复AI代理问题后，如何验证修复有效且没有引入新问题？
针对每个修复验证其应改变的行为。对于重复搜索，添加回归测试重现重复但不扼杀合法重试，避免固定单一工具序列。对于版本不匹配，恢复过滤器并添加测试用例：当前版本、客户明确指定的旧支持版本、无关文档、无可支持答案。在输出变化时重复运行答案评估。使用代码断言可直接验证的内容，用模型评判答案质量，并用人工审核的示例验证评判器。发布后比较相似请求的延迟和任务成功率，同时关注工具调用和令牌计数，避免误读。
