夜雨聆风团队花了两周调优了一个客服 Agent 的 prompt，上线后才发现，之前能正确处理的退货流程，现在第一步就卡住了。没有人改了退货逻辑，Agent 只是"换了种方式理解"用户的诉求。这种问题在 Agent 应用里每天都在发生——模型升级、prompt 改动、工具接口变更，任何一个环节都可能让 Agent 的行为悄悄漂移，而传统测试完全覆盖不到。
测试 Agent 到底难在哪
传统软件测试建立在确定性之上：输入 x，期望输出 y，断言通过或不通过。但 Agent 的不确定性让这套框架失效了。同一个 prompt，模型可能用不同的工具组合、不同的推理路径、不同的措辞来完成任务。你没法写一个断言说"工具调用顺序必须精确等于 A→B→C"，因为模型今天选择 A→C→B 也可能完成任务。
单元测试只能覆盖到工具函数本身的正确性——这个 API 返回了预期的数据——但测不到 Agent 在什么情况下选择了这个工具、为什么跳过了另一个工具、整个推理链路是否合理。端到端测试又太贵，每次跑一遍完整流程的时间成本和 token 成本都让人望而却步。上线后靠人工巡检更不现实，一个客服 Agent 每天处理几千个会话，靠肉眼盯不过来。
Agent 测试的核心矛盾在于：Agent 的输出空间太大，传统断言覆盖不住；同时 Agent 的行为又太容易漂移，不测试不行。
生产日志就是最好的测试用例
这个思路听起来简单，但在 Agent 场景下很有效：既然 Agent 在生产环境里已经处理过大量真实请求，这些请求的执行轨迹（trace）就是最好的测试用例。一个 trace 记录了 Agent 从接收到用户输入到返回最终结果的完整路径——模型调用、工具选择、中间推理、最终输出，每一步都有。把生产 trace 回放到测试环境，就是让 Agent 面对同样的输入，看它是否还走同样的推理路径、得出同样的结果。
这不是简单的"把输入重放一遍"。Agent 的 trace 比传统 API 的请求日志丰富得多。一个典型的 Agent trace 包含：
用户输入和系统指令 每次 LLM 调用的完整对话历史 工具调用的参数、返回值和执行耗时 Agent 内部的状态变更（如任务队列、子 Agent 调用） 最终输出和中间推理步骤
这套数据结构天然适合做回归测试——你可以精确地知道"这个输入在线上走通了，产生了期望的结果"，然后把它变成自动化用例，在每次部署前验证新版本是否还能走通。
架构拆解
一个完整的 trace 回放测试系统需要四个层次。
采集层：生产 trace 的捕获与存储
trace 采集是整个系统的基础。目前主流方案有两种：一是通过 Agent 框架的 instrumentation 自动采集，LangChain/LangGraph、CrewAI、AutoGen 都有内置的 trace 回调；二是通过 OpenTelemetry 的 GenAI 语义约定手动埋点，适合自定义 Agent 框架。
采集的关键不是"把数据存下来"——这在可观测性场景已经做得很好了。关键是为 trace 打上标签，标明哪些 trace 适合作为测试用例。理想候选 trace 的特征：任务完成度高、用户反馈正面、工具调用路径清晰、没有异常中断。这需要接入用户反馈信号或任务完成状态判断。
转换层：从 trace 到测试用例
trace 不能直接当测试用例用，需要做结构化转换。一条生产 trace 包含的信息量远大于一个测试用例需要的——需要提取出"输入"和"期望输出"的对应关系。
转换层做三件事：
第一，从 trace 中提取"输入上下文"。这包括用户消息、系统指令、会话历史、以及 Agent 在交互时能访问的所有工具和知识库状态。输入上下文定义了测试用例的"前置条件"。
第二，从 trace 中提取"期望行为"。这不是简单的"期望输出文本"，而是一个行为约束集合：期望使用的工具、期望的调用参数范围、期望的最终输出格式、期望的推理路径模式。约束的粒度可调——对新模型版本的回归测试可以宽松一些，只检查关键路径节点；对关键业务场景可以严格一些，要求精确匹配某些步骤。
第三，对 trace 做去重和筛选。大量相似 trace（比如"查天气"这种简单请求）不需要全部变成测试用例，按场景聚类后每个类别保留代表性样本即可。
执行层：回放与比较
回放不是在测试环境里跑一遍完整的 Agent 流程——那样太贵也太慢。回放需要做两层隔离：
第一层，工具调用隔离。回放测试不能真的去调用外部 API（扣款、发邮件、改数据库），所以工具层需要 mock。但 mock 不是简单的"返回固定数据"，而是根据生产 trace 中记录的工具调用参数和返回值，构建一个"predictable mock"——给定相同的输入参数，返回相同的响应。这样就隔离了外部依赖，只测试 Agent 的决策逻辑本身。
第二层，LLM 调用隔离。模型是个黑盒，你没法 mock 它。但你可以在测试中记录新版本的 LLM 输出，与生产 trace 中的原始输出做结构化比较。比较的不是文本是否相同——那太脆弱了——而是比较语义等价性、工具调用选择的一致性、以及推理路径的相似度。
评估层：差异判定与告警
回放执行完成后，系统产生差异报告。差异不一定都是回归——模型换了种方式完成相同任务，不算 bug。所以评估层需要做三层判定：
第一层，功能等价性判定。Agent 的最终输出是否语义等价？用户目标是否被满足？这可以用 LLM-as-judge 来做，也可以用严格的 schema 校验。
第二层，路径一致性判定。Agent 是否使用了相同的工具集？工具调用的顺序是否合理？这一步不是要求精确匹配，而是检测"异常路径"——比如以前用搜索工具获取信息，现在直接编造答案，这就是明显的回归。
第三层，性能退化判定。工具调用次数是否显著增加？推理 token 消耗是否翻倍？即使功能等价，性能退化也是需要关注的回归信号。
工程落地中的关键取舍
trace 样本量
生产环境每天产生几万条 trace，不可能全部变成测试用例。按场景聚类后，每个业务场景保留 5-10 个代表性 trace 就够了。关键是要保证场景覆盖度——退货流程、退款流程、客服升级流程各覆盖几个典型路径，比单纯堆数量有效得多。
测试频率与成本
trace 回放测试的 token 成本主要来自 LLM 调用。优化手段有两个：一是利用 LLM 调用的缓存，同一测试用例多次运行时，如果输入不变，输出可以缓存命中；二是对测试用例分级，核心业务场景每次部署都跑，非关键场景按天或按周跑。
误报处理
模型的不确定性决定了 trace 回放测试必然有误报。一个常见的做法是"两次失败才告警"——同一测试用例连续两次回放都失败，才判定为真实回归。第一次失败标记为"待观察"，第二次失败才发告警。这能过滤掉大部分模型输出波动导致的假阳性。
trace 的时效性
生产 trace 有保质期。三个月前的 trace 对应的业务逻辑、工具接口、prompt 可能都已经变了，用它做测试用例反而产生误导。建议 trace 测试用例的有效期不超过 30 天，之后自动归档或重新从生产环境采集。
工具链的现状
LangSmith 的 trace-based testing 功能已经比较成熟，支持从 trace 创建测试用例、在 CI/CD 中批量执行、以及自动比对结果。Arize Phoenix 的 trace replay 功能侧重于问题排查和调试场景，配合 OpenTelemetry 的 GenAI 语义约定使用。如果你用的是自定义 Agent 框架，基于 OpenTelemetry 的 trace 格式自行构建回放管道也是可行的——核心是 trace 数据模型和 mock 层的设计。
工具层面还有一个趋势值得关注：trace 格式正在走向标准化。OpenTelemetry 的 GenAI 语义约定（v1.30.0+）定义了一套统一的 Agent trace 属性，包括 gen_ai.agent.step 这样的标准 span。这意味着不同工具产生的 trace 可以互相转换，测试用例也可以跨平台复用。
什么时候该上这套东西
如果团队只有一两个 Agent 应用，出错时人工排查就行，trace 回放测试的投入产出比不高。但一旦 Agent 应用进入以下状态，就值得认真考虑：
每周都有 prompt 或模型更新，但回归测试全靠人工 线上出过因为 prompt 改动导致行为漂移的问题 团队开始搭建 CI/CD 流水线，但 Agent 测试还是一片空白 不同版本的 Agent 行为差异大，团队内部对"什么算正常行为"没有统一标准
trace 回放测试不是银弹。它解决不了 Agent 的根本能力问题——模型能力不行，再多的测试也救不了。但它能解决一个很实际的问题：当你的 Agent 行为发生变化时，你能第一时间知道，而不是等用户投诉了才发现。
#AI应用架构 #AI应用开发 #Agent应用架构 #Agent应用开发
