传统软件的测试建立在「同样输入必得同样输出」上，但智能体不是——同一条指令，模型这次走通、下次可能换条路径甚至翻车。这种非确定性让「给 Agent 写测试」成了新工程难题。它和 智能体评估 不同：评估回答「做得好不好」，测试回答「会不会坏、改了之后有没有退化」。本文讲清给 Agent 做测试与回归防护的五步。
先分清：你要测的是「工具」还是「轨迹」
Agent 由两部分组成：确定性工具（调 API 、查库、算数）和非确定性决策（模型选哪一步、怎么组织回复）。测试要分层：工具层当普通单元测试，断言输入输出确定；决策层不能断言「走哪条路」，只能断言「是否到达正确结果、是否调用了必要工具」。把两层混在一起测，会因模型的随机性得到闪烁的红绿。可参考 智能体工具设计 把工具接口收拢得可测、可控。
工具层：像测普通函数一样测
工具是 Agent 里最该先锁死的部分。给每个工具写单元测试：固定入参、断言返回、覆盖空值/超时/限流/异常格式。工具的失败模式越明确，Agent 整体越稳。注意给工具加「可注入的假数据」能力——测试时别真去调外部 API，用桩（stub）替掉，既快又不受网络摆布。结构化输出可结合 智能体结构化输出 的 schema 断言，确保模型吐出的 JSON 符合契约。
决策层：用「场景 + 断言」代替精确匹配
对决策，别断言「模型必须说某句话」，而是写场景测试：给定初始状态与用户目标，跑一遍 Agent，断言「最终是否解决了问题」「是否调用了关键工具」「是否产生副作用」。因为路径会变，断言要盯结果而非过程。把若干场景固化成测试集，每次改 prompt 或换模型都重跑，这就是 Agent 的回归套件。
回归防护：金轨迹与差异告警
非确定性最怕「悄悄退化」：今天还行，明天某次改动让成功率从 95% 掉到 70%，却没人发现。做法是维护一批「金轨迹」用例（已知能跑通的场景），每次发布前自动跑 N 次、统计成功率与关键指标；一旦低于阈值就拦下。配合 智能体调试实践 在失败时自动保留上下文快照，能快速定位是 prompt 、工具还是模型的问题。
安全相关的测试不能省
Agent 一旦有写权限或能对外发消息，测试必须覆盖「它会不会做不该做的事」。构造越权场景、注入场景、诱导它调用高危工具的场景，断言权限边界守得住。这与 智能体权限最小化 是同一件事的两面：设计上收窄权限，测试上验证收窄真的生效。没有这层，自动化测试再漂亮也是纸糊的防线。
- 分层：工具层当单元测试（确定断言），决策层用场景断言结果而非路径。
- 桩工具：给工具加可注入假数据，测试不真调外部 API，快且稳。
- 写场景：固化「初始状态+目标→断言结果/关键工具调用」的用例集。
- 建金轨迹：维护已知跑通的场景，每次发布前自动跑 N 次统计成功率。
- 测越权：构造越权/注入/高危调用场景，断言权限边界守得住。
常见问题
“智能体测试和智能体评估是一回事吗？”
“怎么测会随机变化的模型决策？”
“工具层该怎么测才稳？”
“怎么防止
评论 (0)