你花了一周搭好一个 Agent：它能调用工具、能理解意图、能返回结果。跑几个 demo 看起来都不错。然后上线第一天，用户就问：”为什么它删了我的文件？”
Agent 的测试和传统代码不是一个游戏。
传统代码的输入输出是确定的，你写测试用例跑一遍就知道对不对。Agent 的输入输出不固定——同样的问题，它今天回答 A，明天回答 B，后天可能决定调一个你不认识的 API。
这篇文章不聊学术评测指标，只解决一件事：你的 Agent 上线前，应该做哪些测试，怎么测，测什么。
读完你会得到：
- 一套覆盖 Agent 核心能力的测试分类框架
- 每个类别下可执行的测试方法和清单
- 一份可以直接复制跑的回归检查单
一、Agent 测试为什么难
先承认一个基本事实：你不可能穷尽所有输入。
Agent 的核心难点在于三个不确定性：
- 意图理解不确定：用户说”帮我整理下这份资料”，Agent 到底理解成什么？
- 工具调用不确定：同一个意图，它这次调工具 A，下次可能调工具 B，或者干脆不调。
- 输出格式不确定：你让它返回 JSON，它可能偶尔返回带解释的 Markdown 包裹 JSON。
这些不确定性导致传统单元测试的方法——写一个输入，断言一个输出——在 Agent 身上直接退化成”碰运气”。
但这不意味着不能测。你需要换一套思路：不测”它说了什么”，测”它做对了什么事、没做不该做的事”。
二、Agent 测试的四个层级
我把 Agent 的测试分成四个层级，从底层到表层，每一层覆盖不同维度的风险。
层级 1：意图路由测试
这一层回答一个最基本的问题：Agent 能不能正确识别用户的真实意图？
你需要覆盖的场景：
- 正常意图：用户表达明确，比如”帮我总结这篇文档的前三个要点”。
- 模糊意图：用户表达不明确，比如”看看这个”（附了一个文件链接）。
- 多意图叠加：一个请求里包含多个任务，比如”先总结这篇，然后把关键词翻译成英文”。
- 越界意图：用户请求超出 Agent 的能力范围，比如让一个文档总结 Agent 去改写代码。
测试方法：
准备 20-30 条代表性输入（不需要几百条，但必须覆盖上述四类），对每条输入判断：
- Agent 是否正确识别了意图？
- 识别的意图是否对应了正确的下游动作？
- 对越界意图，Agent 是否拒绝了而不是硬着头皮做？
通过标准： 正常意图和模糊意图的正确识别率 ≥ 90%；越界意图的拒绝率 = 100%。
层级 2：工具调用安全测试
这一层回答：Agent 调用的工具对不对？调得安全吗？
这是最容易出安全事故的一层。你的 Agent 可能有权限读文件、写文件、调 API、发邮件。一旦工具调用错了，后果不可逆。
你需要测试的场景：
- 工具选择正确性：给定明确的意图，Agent 是否调用了正确的工具？（比如用户问天气，它调了天气 API 而不是搜索引擎。）
- 工具参数正确性：调用工具时传的参数是否合理？有没有缺参数或多传敏感信息？
- 工具的幂等性保护：用户连续发同样的请求，Agent 会不会重复执行破坏性操作？（比如删文件、发邮件。）
- 工具的权限边界：有没有工具被调了但它本不该有权限调用？
测试方法：
- 为每个工具写 3-5 条测试用例，覆盖正常调用、边界调用和异常调用。
- 对破坏性工具（删除、发送、写入），必须测试幂等性和二次确认机制。
- 在隔离环境（沙箱、mock API）中跑测试，绝对不能连生产。
通过标准： 工具选择正确率 ≥ 95%；破坏性操作的重复触发必须被拦截；所有工具调用必须符合权限矩阵。
层级 3：输出质量测试
这一层回答：Agent 的输出在质量上能不能用？
不是”它有没有回答问题”，而是”它回答得好不好、有没有遗漏、有没有幻觉”。
你需要关注的维度：
- 事实准确性：回答中涉及事实的部分，能不能追溯到可靠的来源？有没有编造？
- 格式一致性：输出格式是否稳定？如果你要 JSON，它是否每次都返回合法的 JSON？
- 完整性：是否遗漏了用户请求中的关键约束？（比如用户说”用中文回答”，它用了英文。）
- 长度控制：有没有过度输出（几千字的废话）或输出不足（一两句打发了）？
测试方法：
- 准备一组”黄金标准”问题（10-20 个），对每个问题准备人工验证的预期答案或评分标准。
- 用 LLM 作为评分器（LLM-as-a-Judge）做初步质量打分，然后人工抽查。
- 对格式类要求，直接写自动化断言（JSON Schema 校验、关键词检查等）。
通过标准： 事实准确率 ≥ 95%（不能有编造）；格式一致性 ≥ 98%；人类评分均值 ≥ 4/5。
层级 4：回归与性能测试
最后一层回答：Agent 改了 prompt、换了模型或加了新工具之后，旧功能还在吗？
这是 Agent 开发中最大的坑：你以为只是”微调了一下提示词”，结果之前能用的功能全废了。
你需要测试：
- Prompt 变更回归：每次修改系统 prompt 后，跑一遍核心测试用例集，确认没有功能倒退。
- 模型切换回归：更换底层模型时，跑同样的测试集，比较性能差异。
- 新工具集成回归：加了一个新工具后，确认现有工具调用没有被干扰。
- 性能退化：响应时间是否有明显增长？Token 消耗是否暴涨？
测试方法：
- 维护一个核心回归测试集（10-15 条关键用例），每次变更前跑一遍。
- 记录关键指标基线：响应时间、Token 消耗、任务成功率。
- 设置阈值：任意指标偏离基线超过 20% 时，必须人工审查原因。
通过标准： 核心用例零失败；性能指标在基线 ±20% 以内。
三、一份可以直接跑的回归检查清单
下面是我日常使用的回归检查单。每次 Agent 有 code/prompt/模型变更时，逐条跑一遍。
发布前检查
- 意图识别测试：20-30 条测试输入，正确识别率 ≥ 90%
- 越界意图拒绝：所有越界请求均被正确拒绝（无硬执行）
- 工具选择正确性：每个工具 3-5 条用例，正确率 ≥ 95%
- 破坏性操作保护：幂等性测试通过，重复请求不触发二次执行
- 权限矩阵验证：所有工具调用均在授权范围内
- 事实准确性抽查：回答中事实部分可追溯或标注待确认
- 格式一致性验证：JSON/结构化输出通过 Schema 校验
- 约束遵守：语言、长度、格式等用户约束均未被忽略
- 回归测试集通过：核心 10-15 条用例全部通过
- 性能基线对比：响应时间和 Token 消耗在基线 ±20% 以内
变更时追加
- Prompt 变更已记录新旧版本差异
- 模型切换已记录新旧模型名称和版本
- 新工具已添加对应测试用例
- 旧工具的测试用例已更新（如果接口有变动）
四、测试工具和自动化
Agent 测试不一定要写一堆测试框架。我推荐的工具链：
- 用例管理：一个简单的 Markdown/JSON 文件就能维护，不需要重型工具。
- 自动化断言：Pytest + JSON Schema 校验，足够覆盖格式和结构类测试。
- LLM-as-a-Judge：用同一个模型或更强的模型做质量打分，但必须配合人工抽查。
- 沙箱环境：工具调用测试必须在隔离环境中进行，可以用 mock server 或本地临时目录。
- 持续集成：把回归测试集接入 CI/CD，每次 commit 后自动跑，失败则阻止合并。
关键原则：不要把所有测试都交给 LLM 做判断。结构化、可自动断言的部分，用脚本；主观质量部分，用 LLM + 人工校验。
五、什么时候可以算”测够了”
实话实说，Agent 永远测不完。但以下信号出现时，你可以更有信心地发布：
- 核心回归测试集连续 3 次变更无失败。
- 破坏性操作的保护机制在所有测试用例中生效。
- 你能够清楚地列出 Agent 不能做什么（能力边界清单）。
- 你有一份最近一次回归测试的通过记录，而不是凭感觉说”最近没出过问题”。
发布不是终点，而是监控的起点。下一篇我会写 Agent 上线后的运维和监控该怎么做。
待确认：
- 文中标注的通过率标准（90%、95%、98%）为经验建议，具体数值需根据实际项目调整。
