如何为 Agent 项目设计测试？

核心回答

Agent 项目需要同时测试确定性代码、模型决策和完整业务任务。我会先把需求对应到成功条件：底层用单元与接口测试保证工具和状态处理正确，中间固定上下文检查工具选择、参数和关键分支，最后在可重置环境里运行端到端任务，核对真实产物与外部状态。

正常路径之外，还要覆盖缺少信息、错误工具参数、超时限流、重复提交、权限变化和多轮上下文污染。模型输出存在波动，因此不能只看一次回答，也不能要求所有合法执行都沿同一条轨迹。

三层测试怎样分工

代码与工具层测试输入校验、数据转换、异常映射、存储、幂等和状态迁移。能用确定性断言验证的内容，就用普通自动化测试处理；把模型替换为可控返回值，可以集中检查应用是否正确执行工具请求。

决策层固定用户输入、历史消息和工具结果，检查是否需要调用工具、选了什么工具、必要参数是否正确、该追问时是否追问。只有业务上必要的约束才写成断言，例如查询必须限定用户权限，而不是规定模型必须先读某个文件再读另一个文件。

端到端层使用真实编排与代表性依赖，检查用户任务能否完成。查询任务核对事实与证据，写操作核对最终记录以及是否重复，代码任务运行相应功能与回归检查。单测通过只能说明局部规则，不能证明这些模块已经正确连接。

模拟依赖和真实依赖各测什么

模拟工具可以稳定制造超时、错误码、空结果或部分成功，便于复现失败和比较不同决策。集成测试仍要覆盖真实接口的鉴权、返回结构和异常行为，否则模拟对象可能与真实服务逐渐脱节。

测试环境按运行隔离数据与工作区，每次恢复相同初始状态；避免上次留下的文件、聊天历史或缓存让下一次“直接成功”。涉及支付、发信等副作用时使用测试服务或隔离资源，不让回归测试影响真实用户。

多轮与失败恢复怎样验证

除了单句请求，还要测试澄清后继续、用户中途修改条件、取消任务，以及一次工具失败后的恢复。检查恢复是否使用了最新参数，有没有重复已完成的外部动作，失败最终是否被正确反馈。

对于同义改写、增加无关上下文等变化，可以约定结果应保持的关系，而不保存唯一答案文本。涉及随机决策时重复运行关键任务，并同时记录失败率、重试次数和开销；低温度设置也不等于整个系统完全确定。

怎样把测试接入日常迭代

把稳定的函数、接口和业务回归用于快速反馈；完整模型评测按变更影响和成本安排。改工具结构重点看工具与决策层，改Prompt重点看相关行为与保留任务，改检索或状态结构则补相应集成和端到端检查。

保留失败输入、环境版本、模型输出、工具回执和评分原因。新增失败案例进入回归集，修复后既验证原问题，也检查邻近场景，避免把一次修复做成只匹配某种问法的特例。

常见追问

只做函数单测够吗？ 不够。函数都正确，仍可能工具选错、上下文漏传或状态交接错误；需要决策层和端到端测试补齐。

每次都跑完整模型评测吗？ 按影响范围选择。小改动先运行能发现该类错误的检查，模型或编排发生广泛变化时再扩大范围，让测试成本与风险匹配。

对应教程

参考资料