Agent 怎么做回归测试：提示词一改就全变
数据截至 2026-07，各项目能力以官方文档当前版本为准。
给 agent 做回归测试，关键不是想办法让输出变得确定，而是换一个断言的层次：别断言它”说了什么原话”，去断言它”取到了哪些事实、调了哪些工具、产出的结构化字段对不对”。只要断言层选对，提示词天天改也能有一套稳定跑的回归；断言层选错，你写多少测试用例都会被一次无害的措辞调整全部打红。
常见的误解是”LLM 输出不确定，所以 agent 根本没法做回归测试，只能靠人肉试”。这个结论下得太早。不确定的是措辞，不是行为。同一个订单查询 agent，你改了系统提示词的语气，它回复的句子会变，但它该不该调 query_order 这个工具、该不该在缺少订单号时反问用户、返回的 JSON 里 status 字段该不该是 shipped——这些是可以稳定断言的。真正让人放弃回归测试的，往往是第一版测试直接对着完整回复做了字符串比对，跑三次红三次，然后大家就觉得”这事做不了”。
一、先给改动分类，决定要回归多大范围
不是每次改动都要跑全量。把改动分成四类，回归范围完全不同：
- 纯措辞类：改了语气、加了一句礼貌用语、调整了输出模板的排版。理论上不该影响行为，但恰恰是这类改动最容易顺手改坏——比如在系统提示词里加了一句”回答尽量简洁”，结果 agent 为了简洁把该调的工具跳过了。这类改动要跑的是”行为不变”断言：工具调用序列和结构化字段应当与基线一致。
- 规则类：加了新约束、改了判断边界、调整了什么情况该转人工。这类必须跑全量，因为一条新规则很容易和旧规则打架。
- 工具类：加了工具、改了工具的参数 schema 或描述文案。工具描述是提示词的一部分，改一个字段的说明就可能让模型在两个相似工具之间改选。这类要重点跑”工具选择”相关的用例。
- 模型或框架类：换模型、升级框架版本、改了编排图的结构。这类改动的影响面最大，属于必须全量重跑并且人工抽查的级别。
实操上建议在提交信息里标一下改动类型，回归脚本按类型决定跑哪一批用例。全量跑一次的成本不低，全都跑等于都不跑。
二、攒一套黄金用例集，来源是线上真实失败
黄金用例集是回归测试的地基，它的质量决定了这套东西有没有用。凭空想出来的用例通常没什么价值，因为它们往往正好覆盖你已经想到的路径。真正有效的来源有这么几处：
- 线上真实失败的对话。用户投诉、人工介入、agent 转人工的记录，逐条脱敏后进用例集。这是最贵也最有效的用例来源。
- 每次修 bug 时的那个输入。修完就把触发它的输入加进去，这是回归测试最经典的用法——保证同一个坑不掉第二次。
- 边界与恶意输入。空输入、超长输入、明显越权的请求、故意误导的诱导性问法。
- 正常主路径的少量样本。数量不用多，作用是当有人把 agent 改坏到连正常任务都跑不通时能立刻发现。
用例条数不要贪多。一套几十条、每条都对应过一次真实问题的用例集，比一大堆自动生成的样本有用得多。每条用例除了输入，还要记清楚：期望调用的工具、期望的结构化输出、允许的浮动范围、以及”这条用例当初为什么被加进来”。最后这一项经常被省掉，但半年后没人记得某条用例在防什么，它就迟早会被当成噪声删掉。
三、断言写在三层，唯独不写在原文
具体断言什么，这是整篇最实操的部分。建议只在下面三层写断言：
第一层：结构化产物。 让 agent 除了自然语言回复之外，同时输出一份结构化结果（JSON 或函数调用参数）。测试断言全部打在这份结构上：字段存不存在、类型对不对、枚举值在不在允许集合里、金额有没有算错。这一层可以做严格相等断言，跑多少次都稳定。
第二层：工具调用轨迹。 记录整轮任务里 agent 调了哪些工具、顺序如何、参数是什么。断言可以写成”必须调用过 query_order”、“不得调用 refund 除非前面出现过人工确认”、“工具调用总次数不超过 8 次”。轨迹断言能抓到大量提示词改坏之后的隐性行为漂移——回复读起来还挺像样，但它其实压根没查数据库，答案是编的。
第三层：关键事实点。 对自然语言回复只断言”必须包含哪几个关键信息”，用关键词或轻量的语义判断，不做全文比对。比如客服回复里必须出现实际的物流状态词，必须出现订单号，不得出现价格承诺类措辞。这一层可以配一个负向清单，专门拦”不该说的话”，这比正向要求它”说得好”更容易测。
至于”回答质量好不好”这类主观维度，可以用模型当裁判打分，但要清楚它本身也是不稳定的一环，只适合作趋势观察，不适合作为拦发布的红线。关于评估维度怎么设计，可以配合看怎么评估一个 Agent 好不好用那一篇。
四、跑一次不算数，用通过率代替通过
传统单测跑一次通过就是通过。agent 不行，同一条用例同一版提示词，反复跑可能时通时不通。所以回归的判定标准应该改成：每条用例重复跑若干次（我自己的折中是三到五次，成本允许可以更多），记录通过率，然后比较的是这一版的通过率相对基线有没有掉。
这样做有两个好处。一是能发现”本来就不稳”的用例——如果它在基线上就时通时不通，那它一直是颗定时炸弹，只是以前运气好没炸。二是能区分真回归和偶发抖动：全通变成偶尔挂一次，和全通变成全挂，是两种性质完全不同的问题。
配套要做的还有把随机性尽量压住：温度设成 0 或很低的值、固定随机种子（如果所用接口支持）、把当前时间、随机 ID 这类会漂的输入固定成测试夹具。有些团队还会把工具调用整体做成可回放的录制，让外部接口在回归时返回固定数据——否则昨天库存有货、今天缺货，agent 行为变了，那不是它的错。
五、把轨迹存下来，回归失败时才有得比
回归报红之后最耗时间的不是修，是搞清楚哪里变了。所以运行记录要存全：每一步的输入输出、模型返回的原始内容、工具调用参数与返回值、耗时和 token 用量。存下来之后，新旧两次运行可以直接做轨迹级 diff，一眼看出是在第几步开始分叉的。
框架层面在这件事上帮得上忙。按多篇第三方实战对比的口径，LangGraph 以有向图组织执行流，节点是函数或 LLM 调用，状态以带类型的字典在节点间传递，并提供 checkpointing、streaming 和 human-in-the-loop 这几类原语，支持可持久化的长时运行工作流——状态可持久化这一点，正好让”存下每一步、失败后从某个节点重放”变得自然。CrewAI 在 2025 年加入了 Flows，一种事件驱动的 pipeline 模式，面向更可预测的生产型负载，所以”CrewAI 只能做原型”这个流传较广的旧结论已经不准确了。AutoGen 方面需要知道的是：微软已把重心转向更大的 Agent Framework，AutoGen 的主要新功能开发停止，进入维护模式，仍有 bug 修复和安全补丁——存量项目不必恐慌迁移，但如果你正打算围绕它建长期的回归与可观测性基础设施，这个状态值得纳入考量。以上均为第三方对比口径，各框架的具体能力以其官方文档当前版本为准。
状态持久化和断点恢复这条线，Agent 的 checkpoint 与长任务恢复讲得更细。
六、成本和耗时也要进回归
只测对错不测代价，很容易出现这种情况：新版提示词把准确率提上去了，代价是每次任务多绕三轮、token 用量翻倍。所以回归报告里建议固定带三个非功能指标：单次任务的 token 用量、端到端耗时、工具调用次数。给每项设一个上限阈值，超了就报黄。
框架本身在 token 开销上也有差异。有一次第三方实测对比给出的排序是 LangGraph 的 token 效率最好、AutoGen 开销最大，这是单次对比的口径，换一套任务未必复现，只能当作选型时的一个参考信号而非定论。真正靠谱的做法还是在你自己的用例集上实测——你的提示词长度、工具数量、上下文策略，对开销的影响远大于框架之间的默认差异。这块可以延伸看Agent 的 token 效率与成本控制。
七、什么时候不该建这套东西
回归测试有实打实的建设成本和维护成本，不是每个项目都该上。有一条提醒值得前置：当单个 agent 只调一两个工具、流程基本线性时，直接用 OpenAI Agents SDK 或 Anthropic Claude Agent SDK 这类路径，在 2026 年往往比套一层多智能体框架更快，也就是说你可能根本不需要多智能体的那套复杂度，对应的回归体系自然也可以简化成十几条断言脚本。
判断标准可以简单点：如果 agent 出错的代价只是用户重问一遍，那人工抽查加少量冒烟用例就够；如果它会动钱、动数据、动线上配置，那前面这些该做的一样都不能省。框架选型的整体权衡，SDK 还是多智能体框架那篇有更完整的对比。
八、这套办法的局限，得说在前面
诚实地讲，agent 回归测试目前做不到传统单测那种安全感，有几个问题短期内解不掉：
- 黄金用例集会腐化。业务规则变了，昨天的正确答案今天变成错的，用例集需要人定期维护。没人维护的用例集会先变成噪声，然后被整体禁用。
- 模型裁判本身不稳。用模型给回答质量打分，分数会随裁判模型版本变化而漂移，不同批次之间的分数不能直接横比。
- 通过率的统计意义有限。跑三五次得到的通过率，置信区间很宽，小幅下滑未必是真回归。想要更强的结论就要跑更多次，成本会跟着上去。
- 覆盖率无法量化。传统测试有代码覆盖率可看，agent 的”行为空间覆盖率”目前没有公认的度量方式，用例集覆盖到哪一步，基本靠经验判断。
- 换模型等于换了整个被测对象。跨模型的基线不能直接沿用，换模型后要重新建基线，这一步没有捷径。
承认这些局限，反而更容易把这套东西建起来——目标不是”保证不出错”，是”改坏的时候能在上线前发现”，这两者的投入产出差着量级。
小结
给 agent 做回归，第一件事是把断言从自然语言原文挪到结构化产物、工具调用轨迹和关键事实点这三层上。用例集要来自线上真实失败，每条都记清楚它在防什么。判定标准从”跑一次通过”改成”多次采样的通过率相对基线没有下滑”，同时把随机性来源固定住。运行轨迹要完整存档，出问题时才能做 diff 定位到分叉点，成本和耗时也一并纳入回归报告。最后要清楚这套办法的边界：它不保证 agent 不出错，只保证你改坏的时候有机会在上线前看见。