系列AI Agent 工程实践上一篇第 29 篇《成本控制》下一篇第 31 篇《Agent 如何部署》一、开场改提示词改崩了别的场景一个团队优化了退款话术的提示词效果很好。一周后客服反馈退款场景好了但查物流场景的回答变啰嗦了因为没人测过提示词改动对其他场景的影响。没有测试优化就是拆东墙补西墙。上篇29讲成本控制这篇讲改了不崩的护栏——测试。二、问题背景不测 vs 系统测试不测版# 改完手动聊两句没问题就发 def test_agent(): pass # 没有系统测试版def test_refund_tool(): with mock_provider(reply_with_toolrefund): out run_agent(我要退款) assert 退款 in out # 行为可验证差别不测 每次改动是赌博系统测试 改动有护栏。三、错误尝试三种测试翻车错误 1只手动测 happy path开发者自己聊两句就发。边界场景乱码、长文本、注入全靠用户撞。错误 2不测 LLM 输出因为LLM 输出不确定就放弃测试结果工具调用、流程分支这些确定部分也没测。错误 3不隔离外部依赖测试真调 API又慢又烧钱又不稳定网络一抖就红。四、关键观察Agent 要分四层测Unit Test工具函数、格式转换等纯逻辑——确定性必测。Tool Test工具行为权限、schema、副作用——用 mock 外部。Prompt Test / Regression提示词改动后Golden Dataset 上的表现不退化。Mock LLM用假模型固定返回让流程是否会调对工具可被稳定验证。LLM 输出不确定 ≠ 不能测。能测的是工具是否被调用、流程是否走到正确分支、确定性逻辑是否正确。不确定的生成质量交给 Golden Dataset 做回归对比而不是精确断言。五、最终方案测试分层tests/ ├── unit/ # 工具函数、schema 校验纯逻辑 ├── tool/ # 工具行为mock 外部依赖 ├── prompt/ # 提示词回归跑 Golden Dataset └── conftest.py # mock_provider 固定 LLM 返回Golden Dataset 示例JSON[ {input: 我要退款, expect_tool: refund, expect_contains: 退款}, {input: 北京天气, expect_tool: get_weather, expect_contains: ℃} ]测试分层Mermaid六、代码对比无测试 vs 有 mock 测试无测试问题# 改了 prompt靠手聊验证 def run_agent(inp): ...有 mock 测试生产def test_refund_flow(): with mock_provider(tool_calls[{name: refund}]): out run_agent(我要退款) assert 退款 in out # 验证行为 assert called(refund) # 验证调对工具关键差异用mock_provider固定返回测试流程是否调对工具稳定可重复不真调 API快且不烧钱。七、设计权衡测到什么程度场景建议理由工具/逻辑必测 Unit Tool确定性价值高提示词改动必跑 Golden Dataset 回归防退化生成质量用区间/规则断言不精确匹配LLM 不确定端到端关键路径少量不必全覆成本高、易碎反过度工程不要为 LLM 生成内容写精确匹配断言——它天生不确定硬测只会产生脆弱测试。八、总结✅ 无测试 改提示词改崩别场景优化变拆东墙。✅ 三种翻车只手测 happy path、因不确定放弃测、不隔离外部依赖。✅ 分四层Unit / Tool / Prompt 回归 / Mock LLM。✅ LLM 不确定 ≠ 不能测工具调用、流程分支、确定性逻辑都可验。✅ 反过度工程生成内容用区间断言不精确匹配。下一篇把这一切跑起来的最后一步——部署。31参考资料带用途说明本系列29成本控制测试用 Mock LLM 不烧钱呼应29成本意识。本系列24Tool Registry本文 Tool Test 直接复用24Registry 的call接口做行为验证。本系列18Agent 如何做 BenchmarkBenchmark 是质量的系统性评测本文回归测试是其工程落地。pytest 文档docs.pytest.org本文测试框架的实现参考。本文是 AI Agent 工程实践系列的第 30 篇第四阶段第十篇。系列导航上一篇第 29 篇《成本控制》下一篇第 31 篇《Agent 如何部署》