智能体的测试策略：从单元到端到端的验证体系

智能体的测试策略：从单元到端到端的验证体系

"这个智能体改了提示词之后到底变好还是变坏了？"——这个问题在多数团队里靠感觉回答，其结果就是每次改动都在引入不可见的回归。智能体的非确定性让传统测试方法大面积失灵：输出没有唯一正确答案、同样的输入每次运行轨迹不同、bug 藏在提示词与检索质量里而非代码里，assert equals 无处安放。但"不可精确断言"不等于"不可测试"。这两年，智能体测试已经发展出一套自己的方法论：分层验证、评测集驱动、评审模型校准、回归门禁。这篇文章把这套方法整理成一个可以落地的工程体系。

传统测试为什么失灵，哪些部分依然坚挺

先划清边界。智能体系统不是一团均匀的非确定性，它由确定性部分与概率性部分拼成。工具函数、数据解析、路由逻辑、权限校验、提示词模板的渲染——这些是纯代码行为，传统单元测试完全适用，必须照常覆盖：工具函数抛错的边界条件、JSON 解析对畸形输出的容错、路由规则对边界输入的分类，都是毫秒级、可精确断言的测试目标。失灵的是对模型输出的端点断言：同一个提问，今天回答的措辞与昨天不同，答案内容都对；评测一道开放题的好坏，不存在能写成布尔表达式的标准答案。

这个边界划清之后，测试策略就清晰了：确定性部分用传统测试钉死，概率性部分用统计化的评测方法覆盖，两层用不同的基础设施、不同的执行频率、不同的通过标准。很多团队的误区是把所有验证都推给"跑一遍看看感觉"，结果确定性部分的低级 bug（解析崩溃、权限绕过）混在模型波动里无法归因。

智能体版测试金字塔

把传统测试金字塔移植到智能体，得到一个三层结构。底层是确定性单元测试：覆盖工具函数、解析器、路由、模板渲染，运行毫秒级，每次提交必跑，与传统 CI 无异。中层是组件级评测：对单个环节用数据集驱动的方式度量质量——检索环节测命中率（hit-rate）与 MRR（排名质量），工具选择环节测"给定场景该调哪个工具"的选择正确率，单轮生成环节用评审模型按评分细则打分。组件评测是三层里性价比最高的一层：它把端到端任务拆成可归因的环节，出问题时能定位是"检索没召回"还是"生成跑偏"，数据集规模五十到两百条即可给出统计上有意义的信号，运行分钟级，适合每次改动后触发。

顶层是端到端轨迹评测：在预发布环境跑完整任务，评估四个维度——任务是否完成（产物校验或目标达成判定）、用了多少步（效率）、花了多少 token（成本）、轨迹是否合理（有没有绕路、空转、危险操作）。代码执行类的智能体可以直接在沙箱里验证产物真实性：生成的测试真的跑过、修改的文件真的通过编译——这类"以结果为准"的判定比评审文本更可靠。轨迹评测运行小时级、环境要求高，放在预发布环境按日或按发布触发。

flowchart TB
    P["智能体改动（提示词 / 模型 / 检索）"] --> L1["第一层：确定性单元测试<br/>工具 / 解析 / 路由（毫秒级，每次提交）"]
    L1 --> L2["第二层：组件级评测<br/>检索命中率 / 工具选择 / 单轮评分（分钟级）"]
    L2 --> L3["第三层：端到端轨迹评测<br/>完成率 / 步数 / 成本 / 轨迹合理性（小时级）"]
    L3 --> G{"指标达标？"}
    G -->|"是"| REL["灰度发布：5% 流量对比验证"]
    G -->|"否"| FIX["定位回归环节并修复"]
    FIX --> L1

评测集建设与评审模型校准

评测集是整套体系的资产核心。来源有两个：线上坏 case 的沉淀（每次生产失败都自动入集，这是最真实分布的样本）与人工构造的边界用例（恶意输入、提示注入、超长上下文、权限边界）。规模上，每个核心场景五十到两百条是启动线，几百条即可捕捉大多数回归；评测集要版本化并与功能迭代同步——新支持的场景要有对应的评测条目，否则新功能永远处于无防护状态。

概率性输出的判定主要靠评审模型（LLM-as-Judge），但它本身是个模型，有偏差需要校准。已知的三类偏差：位置偏差（对比两个答案时偏好先出现的）、长度偏差（偏好更长的回答）、自我偏好（偏好自己家族模型生成的文本）。缓解手段都是工程动作：按评分细则逐项打分而不是笼统给总分（细则把"回答质量"拆成事实性、完整性、格式三项，每项独立判定）；对比类判定交换顺序跑两遍取一致结果；定期抽样人工标注，计算评审模型与人工的一致率（如 Cohen's kappa），一致率不达标的判定维度要回炉修改细则。工具层面，Ragas 专攻 RAG 评测、DeepEval 与 Promptfoo 提供本地化的评测执行、Braintrust 与 LangSmith 把评测与观测数据打通，选择哪家的本质考量只有两个：数据能否私有部署、与现有观测体系的集成成本。

回归门禁与上线闭环

测试体系的终点是让改动变得安全。回归门禁的做法：核心评测集接入 CI，提示词、检索配置、模型版本任何一项变更都触发全量评测，核心指标设定阈值，跌破即阻断发布——把"感觉还行"换成"指标说话"。这套机制最大的价值在防"静默漂移"：模型供应商更新同名模型的权重、检索索引的增量重建、依赖服务的行为变化，都不会产生任何报错，只有评测集能捕捉它们。有团队的经验是把评测探针定时（每日）跑一遍核心集，把评测从发布门禁升级为常态监控。

上线环节的配套是灰度对比：新版本先放 5% 流量，用观测系统对比新旧版本的任务成功率、成本与耗时分布，无回归再放量。最后的闭环是把线上灰度期发现的新坏 case 再次沉淀进评测集——评测集因此始终跟着真实分布走，而不是停留在一年前的老题库。测试策略至此形成完整回路：生产问题变成评测条目，评测条目守护下一次发布，每一次迭代都在扩大防护网。这套回路的本质，是把智能体工程从"手工作坊式的调提示词"升级为"有质量门禁的持续交付"。

生产环境的最后一环：质量抽样与反馈信号

评测集覆盖不了真实分布的尾部，生产环境的质量抽样是最后一道防线。机制设计按风险分层：失败任务全量复核、涉及高风险动作（删除、支付、外发）的任务全量复核、成功任务按百分比抽样——抽样率随业务风险调节，金融与医疗场景 5% 到 10%，通用工具类 0.5% 到 2% 就够。判定通道双轨并行：人工复核保证判断质量，评审模型批量初筛降低人工量，两者定期对齐校准。抽样的价值不止于发现问题，更在于维持团队对真实输出质量的手感——只看指标曲线的团队，对"质量在慢慢变差"的感知总是迟到的。

用户反馈信号要用对地方。点赞点踩是最直接的信号，但有系统性偏差：用户只在极端体验时反馈，负反馈率还与功能可见度正相关，所以它不能当作质量指标读数。正确的用法是把每条负反馈当作 bad case 挖掘器：人工复盘并归因到四类之一——检索失败、工具错误、模型能力不足、需求理解偏差——归因分布的周趋势才是真正的质量仪表盘，它告诉你该往哪个环节投入修复资源。

会话回放的例行化是成熟团队的标志性实践：每周固定时间、工程师轮值、回放抽样的会话记录——包括成功的会话，因为成功也可能只是运气好（该失败但被容错逻辑兜住的案例，往往是下一个生产事故的种子）。回放发现的问题当场归类：进评测集、进修复队列、或直接判定为可接受行为。这个仪式比任何工具采购都更有效地维持团队的质量敏感度，它的成本每周不过一两小时。

还有一条容易被忽视的纪律：评测数据自身的隐私管理。从线上沉淀的评测集包含真实用户输入——代码、文档、个人信息——评测集的访问控制、脱敏处理与保留策略要按数据资产的规格管理；跨团队或对外共享评测集之前必须做脱敏审查。最后，测试投入本身要做风险定价：内部低风险工具可以精简到组件评测加人工抽检，面向外部用户的高风险场景才上全套体系——把测试当作风险对冲来预算，而不是一刀切的流程负担，这样才能让质量体系在组织里活得下去。

最后补两个实践层面的细节。一是评测环境的真实性落差：轨迹评测若在 mock 工具上跑，验证的只是"如果工具都正常，模型规划得对不对"，而生产故障有一大半发生在工具层——真实接口的超时、字段变更、限流。务实的折中是预发布环境接真实工具的只读副本，写操作走沙箱替身，让轨迹评测尽量踩在真实的地面而不是假设上。二是非确定性的统计处理：对波动明显的用例，同一 case 跑三到五次取多数结果（把自洽性的思想用于测试），通过标准从"每次都对"放宽为"多数正确且失败模式可解释"；同时对"翻牌用例"（时过时不过的用例）设立专门的 flaky 观察名单，连续多轮不稳定就降级为人工抽检对象，避免它们反复打断 CI——测试体系的可信度，恰恰取决于它自身的误报率。

小结

智能体测试的核心洞察是把系统拆成两半：确定性部分沿用传统单元测试钉死，概率性部分用三层金字塔覆盖——毫秒级的确定性单测、分钟级的组件评测（检索命中率、工具选择、单轮评分）、小时级的端到端轨迹评测（完成率、步数、成本、轨迹合理性）。评测集是资产核心，坏 case 沉淀与边界用例构造双源供给；评审模型是主要裁判，细则拆分、顺序交换与人工对齐校准缺一不可。回归门禁与每日探针把测试从发布动作升级为常态监控，灰度对比守住最后一道闸。改提示词不再靠感觉，是智能体工程成熟度的第一标志。