做过AI Agent相关开发的朋友应该都有同感：写一个能跑通的代理不难，难的是让它稳定地跑完一百遍。LLM天然带有随机性，同样的输入，今天输出这个结果，明天就可能换个路径，哪怕最终答案都对，中间调用的工具顺序、传参格式、思考链路都可能不一样。这意味着，传统单元测试里"断言返回值符合预期"那套玩法，到了Deepagents这类Agent框架上，直接失灵——你没法断言Token流里的每一句话。Deepagents这个名字，本质上指向的是一类具备自主规划、工具调用、多步执行能力的Agent框架。它的质量保障，不能靠"多调试几次"，必须靠一套专门为"非确定性系统"设计的自动化测试体系。这篇文章我会从三个层面拆解：Agent测试和传统测试到底差在哪、Deepagents自动化测试该怎么设计断言和用例、以及我在实践中踩过的坑和沉淀下来的排查方法。无论你是正在做AI应用的QA、负责Agent平台的工程师，还是刚接触这个领域想建立测试体系的新手，这套思路都可以直接落地。1. 为什么AI代理测试和传统测试不在一个维度在动手写测试用例之前，最要紧的是想明白一个问题：我们对一个Agent的"正确"到底该怎么定义。这个定义想不清楚，后面所有的断言、回归、稳定性建设都是空中楼阁。1.1 不确定性带来的测试哲学转变传统软件测试的本质是"验算"。你有一个确定函数，输入1+1，断言输出2，跑一万次也是一样的结果。如果某次跑出3，那就是bug，定位修复即可。AI代理完全不是这么回事。Deepagents这类框架让模型自己决定调用哪个工具、按什么顺序调用、如何拆解子任务。这是个开环系统，输出空间几乎是无限的。用一个固定答案去套一个开放系统，测试用例本身就会变成抖动的源头：这次跑通了，下次跑不通，你说这是产品坏了还是测试写错了？所以我在实际项目中把测试哲学从"验算"换成了"监考"。传统测试是检查学生交上来的答案是不是100；Agent测试是给监考老师一个评分标准：学生有没有在规定时间内交卷、有没有作弊抄隔壁、答题过程是否符合考试纪律，至于中间草稿纸上的演算步骤，只要不违规，写不写都行。这个转变非常关键。它意味着断言的对象从"终态字符串"迁移到了"行为轨迹与终态达成"两层。我后面会详细展开这两层的具体写法。1.2 Deepagents测试体系的设计理念基于"监考"这个思路，我给Deepagents测试体系定了三条设计原则。第一条是行为可观测。测试环境里所有工具调用必须留下结构化日志，不能只有自然语言文本。框架每次调用工具时的名称、入参、出参、延迟，都要能JSON化落盘。这是后续一切断言的基础——你没法断言一个你看不到的过程。第二条是环境可隔离。Agent测试绝对不能打在真实生产服务上。我见过团队直接拿生产环境当测试场，结果Agent半夜调用了一个真实的下单接口，产生了实际扣款。这种事故一次就足够让人长记性。测试环境里，外部服务全部用可控的桩实现或容器化Mock，数据源用种子数据快照。第三条是结果可复现。对于给定的测试用例，要么你接受"路径不同但殊途同归"，要么你把随机性压到可控范围。一个实用做法是固定模型版本、温度参数设为接近0、禁用流式输出。这样虽然不百分百保证确定性，但能把"合法路径"的数量从无限压缩到有限几类，让断言规则可以覆盖。2. Deepagents自动化测试的关键设计：断言、工具调用与状态管理理清了理念，接下来就是具体设计。Deepagents的测试用例，我在项目里通常拆成三个核心组件：前置条件、执行动作、断言规则。前置条件和传统测试一样，构造输入与状态；执行动作就是跑Agent；差别全在断言规则上。2.1 断言的不再是返回值而是行为轨迹刚才说了，Deepagents测试的第一层断言是行为轨迹。所谓轨迹，就是Agent从开始到结束的完整工具调用序列。我第一个建议是：不要严格比对该序列，除非你的场景是"必须按固定流程操作"。举个例子，一个查天气的Agent，它可以先查城市编码再查天气，也可以直接传城市名查天气。两条路径的结果完全一样，但严格序列比对会让测试用例变成易碎的瓷器。正确做法是提取轨迹的关键特征：调用了哪些工具、工具的入参是否满足约束、是否有重复无效调用、是否有循环死锁。在代码层面，我一般把完整的工具调用Sequence做一个投影运算，只保留我们关心的属性，然后对投影结果做断言。比如"必须调用过SearchTool""SearchTool的关键词参数非空""从发起请求到返回结果的总步数不超过N步"。这样既有约束力，又留足了Agent自主规划的弹性空间。2.2 工具调用链的验证方法第二层断言，是对每个工具调用的出入参进行约束性校验。这里的核心不是断言"精确等于某某值"，而是断言"满足某个不变量"。我总结了三类验证方法，实战中配合使用。第一类是Schema校验。每个工具在框架里都有输入Schema，测试时对Agent实际传入的参数做JSON Schema校验，字段类型错误、必填项缺失这种低级幻觉立刻就能抓出来。这相当于给Agent的工具使用划了一条底线：你可以自由发挥，但话不能乱说。第二类是领域不变量校验。特定业务场景下的硬约束。比如金额字段不能为负数、用户身份必须是测试白名单内的ID、时间参数不能早于某个基准点。这类校验往往比Schema校验更贴近业务，也更能抓住真正有杀伤力的bug。第三类是副作用校验。工具不是无痕的，它会有数据库写入、缓存更新、外部资源占用。测试要在Agent执行完成后比对前置状态与后置状态，排除泄漏的脏数据。这个需求引出下一个关键设计。2.3 状态管理与隔离Deepagents有状态，这是它和普通API的重要区别。对话上下文、中间变量、临时文件、外部服务连接，都会在执行过程中累积。测试如果不管理状态，用例之间会互相污染，出现"A用例单独跑能过，跟着B用例跑就失败"的邪门问题。我推荐的办法是事务级回滚 + 环境级重建双管齐下。事务级回滚针对数据库这类有事务支持的组件。每个测试用例外层包一个事务，执行完直接回滚，数据恢复到测试前状态。缓存类组件则在用例开始前删除相关Key，形成干净起点。环境级重建针对Agent持有的上下文对象。Deepagents运行时会维护agent state，测试必须确保每个用例拿到的是全新初始化的State，不能复用上一个用例残留的中间变量。这块我在框架层封装了一个fixture，每个用例自动实例化新Agent、注入新会话ID。效果立竿见影，状态串扰导致的口角问题基本清零。3. 实操：搭建一套Deepagents质量保障基线从设计落到工程，下面是我在模拟项目X里完整落地过的一套Deepagents测试体系。这套体系可以按需裁剪，但整体架构是经过验证的。3.1 测试环境与资源配置Deepagents测试环境和传统API测试环境最大的区别是：你需要一个可控的LLM网关。LLM调用是Agent测试中最大的变量源和成本源。直接打供应商的在线接口，网络抖动、限流、随机性会把测试结果搅成一锅粥。我建议团队在测试环境里部署一个代理网关，统一拦截测试用例里的模型调用。网关要提供几个能力：按预置内容响应（模拟固定模型输出）、按用例维度限制调用次数、记录每次调用的Token消耗与耗时。有了这个网关，你在测试用例里可以对Agent说"最多只能调用N次LLM"，超过就断言失败，防止循环失控。外部依赖方面，我的基线配置是：数据库用PostgreSQL容器，初始数据从SQL快照恢复搜索/检索类工具用一个预置索引的轻量向量库替代，数据量几百条，覆盖典型场景HTTP类外部API全部用接口Mock服务，按路由规则返回固定Fixture文件系统操作指向临时目录，用例结束自动清空特别注意：LLM网关不等于把模型换成"人教版教材"。真实项目里我会区分两类用例。冒烟测试用网关的定值响应，追求速度与稳定；完整回归用真实模型，跑完整场景，追求探索未知问题。两者缺一不可。3.2 第一类测试：确定性单元测试这类测试针对的是Agent内部不需要模型参与的纯逻辑模块。虽然Deepagents的核心是LLM，但工程上一定存在大量非智能组件，比如工具调用参数的预处理、结果解析器、提示词模板渲染、错误处理分发。这些组件是确定性的，完全可以按传统单测方式来写。我用pytest框架，针对每个纯函数模块维护一份测试矩阵。核心价值不在于测试多复杂，而在于给Agent系统建立一个"确定性锚点"——每当提示词模板或工具定义发生变化时，先跑这批测试，能第一时间发现模板语法错误、参数名不匹配这类低级问题，不用每次都启动完整Agent链路。这类测试的覆盖率在项目里大约占30%左右。别小看这30%，它们保证了Agent运行时的地基是稳的。地基不稳，上层再聪明的模型也会被绊倒。3.3 第二类测试：端到端场景测试重头戏在这里。端到端场景测试模拟一个真实用户从发起请求到目标达成的完整链路。我给每个场景维护一个结构化用例文件，包含场景描述、初始环境、预期行为不变量、禁止行为列表。场景设计上，我遵循"二八法则"。先梳理线上运营反馈中高频率出现的Top 20用户需求，把它们固化为场景用例。比如"用户查询本月账单并申请备注修改""用户咨询退货政策并引导提交售后单"。这20个场景覆盖了80%的生产流量形态，是稳定性的基本盘。每个场景用例的断言，按照前面说的两层结构来写。行为轨迹层面：断言必须在N步内完成、必须调用特定核心工具、不得调用禁区工具。业务结果层面：断言最终写入数据库的实体状态、对外返回的关键字段。双断言确保Agent既干成了事，又没干出格。为了保证场景测试高效执行，我给测试框架设置了超时熔断。单个场景最长允许多久，由场景复杂度决定，但每个用例都硬性设上限，优雅超时并导出截止当前的轨迹日志，方便排查是卡死还是慢。3.4 第三类测试：稳定性压力测试场景测试解决"对不对"，压力测试解决"扛不扛得住"。Deepagents的压力测试我是从三个维度做的。并发维度，同一场景用例并发N个实例，观察资源占用和接口错误率。连续维度，同一场景串行循环执行N次，观察Token消耗是否有泄漏、内存是否持续增长、外部桩服务是否有连接泄漏。长链路维度，构造一个需要多个工具交替调用、跨数个上下文轮次的复杂任务，验证长时间运行下Agent的规划能力和上下文记忆衰减情况。压力测试的通过标准，不是"零失败"。LLM系统里零失败是不现实的理想态。我定的标准是：连续运行的失败率低于2%，且任何一次失败都能在30秒内由重试机制拉起，不会造成死循环或状态错乱。实际操作中会发现，很多在场景测试里跑得好好的用例，一进压力测试就出事。最常见的两类，一是Agent进入循环策略反复调用同一个工具，Token成本爆炸；二是并发场景下多个实例共享某个工具的内部可变状态，产生竞态。这两类问题都需要靠压测来暴露。4. 高频问题与排查实录测试体系建起来之后，运维的挑战才真正开始。下面是我在Deepagents测试建设过程中遇到的几类高频问题，全部来自实际记录，每一类都对应着可以复用的排查思路。4.1 断言抖动问题：测试结果忽绿忽红这是Agent测试里最让人血压升高的问题。同一份代码，同一个用例，上一条跑得好好的，下一条就红了，而且没有任何代码变更。等十分钟再跑一次，又绿了。我排查这类问题有个固定流程。第一步看日志，把失败用例的完整轨迹和成功用例的轨迹做diff，观察差异发生在哪个环节。是LLM调用返回不同了，还是某个工具Mock返回值被并发修改了。第二步检查测试隔离性，看是不是有共享的可变状态在用例间泄漏。第三步才轮到模型随机性。一开始我经常归咎于"LLM随机性"，后来发现一大半抖动其实是测试自身不干净造成的。Shared fixture、环境变量被某个用例改写、Mock服务内部计数器跨用例累积，这些才是真正的元凶。把状态隔离做好之后，抖动率能下降一半以上。剩下的模型随机性抖动，通过放宽非关键路径的断言粒度来消化。4.2 工具副作用导致的状态污染Deepagents执行过程中经常会出现连带副作用。比如一个"查询用户订单"的工具，可能顺手在访问日志表里写了一行记录；一个"生成报告"的工具，可能向消息队列推送了一个通知。单次执行看不出问题，但测试用例一多，这些副作用就像漏水的水龙头，把测试环境的地板全泡湿了。我总结的排查信号是：用例单独跑全绿，按某个固定顺序跑就翻车，且失败位置和顺序密切相关。这种九成是副作用污染。解决方案分两层。第一层，对所有测试用到的工具做副作用审计，凡是会写外部状态的工具，要么改成Mock版本，要么在用例结束后做状态回滚。第二层，引入"执行前后快照比对"机制，跑完用例自动比对数据库表行数、缓存Key集合、消息队列积压量，一旦差异超出阈值直接标红。这个机制起来后，测试环境的稳定性上了一个台阶。副作用不再靠人肉排查，系统会自动捕捉。4.3 成本控制与超时设计Deepagents测试跑久了，最肉疼的是Token账单。场景测试跑一次可能只要几万Token，但压力测试一晚跑下来，消耗可以上百万。我见过团队上线AI功能后，测试环境成本比生产还高一截，财务过来拍桌子的场面。成本控制我用了三板斧。第一板斧是分级执行。日常提交只跑确定性单测和冒烟场景，完整场景测试在夜间定时跑，压力测试只在发版前跑。第二板斧是规划限制器。每个用例设置最大LLM调用次数，一旦突破就被判失败，防止Agent陷入乱试循环。第三板斧是调用结果缓存。相同输入条件下，命中断言规则的路径结果缓存复用，避免反复烧钱。超时设计是个容易被忽视的细节。Agent测试的超时不能简单"到点杀进程"——杀进程丢的是调试线索。我会在超时触发时先尝试导出当前完整轨迹与工具调用链，再做中断。这样即使用例最终是红的，也拿到了足够分析的数据，不会白白烧一次请求只得到一个"timeout"。5. 稳定性建设的进阶心得如果前面的内容是在解决"有没有"，这一节想聊的是"稳不稳"。Deepagents测试体系跑到后期，真正拉开团队差距的不是用例数量，而是对稳定性细节的处理，这里分享三个我反复打磨过的点。5.1 重试策略与指数退避Agent执行过程中的失败，很多是临时性的。Mock服务偶发延迟、外部API限流、LLM网关瞬时拥堵，这类故障重试一下就好了。但重试要有策略，最简单粗暴的"失败就立即重跑"是下策，会让系统在负载高峰时雪上加霜。我在框架层实现了指数退避重试。第一次失败等待短信级别的时间，第二次翻倍，最多重试四轮。重试之间还加入了随机抖动，避免多个并发用例同时重试形成谐振峰。更关键的是，重试只重跑失败的那一步动作链，不重新执行整个Agent流程。这里需要Deepagents具备步骤级状态快照能力，运行到每个工具调用处都记录检查点，从检查点恢复推进。这套机制上线后，压测的最终成功率从96%级别提到了逼近100%。5.2 回归测试基线的维护稳定性还体现在"不倒退"。AI系统是持续迭代的，提示词文件在改、工具定义在改、模型版本在换。每次改动都可能让原本稳定的行为变得不稳定。回归测试基线就是把每个场景的"历史成功轨迹特征"沉淀下来，做增量比对。具体做法，我把每次发布的成功用例轨迹投影哈希后存入基线库。新版本跑完同样用例，生成新的轨迹哈希，和基线比对。如果哈希完全一致，说明行为收敛；如果差异较大，就需要人工审查差异原因，确认是"预期的优化"还是"非预期的漂移"。这个机制让我在模型升级时心里有底。换模型前先跑基线库，观察漂移面的范围，再决定是灰度切流还是继续用老版本。没有这层基线保护，每次模型升级都是一场赌运气。5.3 把测试当作产品功能本身来建设最后一个心得，可能听起来有点虚，但它是整个体系的根基：Deepagents测试不能当作QA的负担项目来做，它应该被当作一条独立的产品线来建设。我观察到一个普遍现象：AI项目早期测试都是员工抽空用脚本堆一些临时用例，接口一变脚本就崩，然后没人维护，自动化测试就名存实亡了。要让测试体系活下来，必须赋予它和业务功能同等级的资源投入。团队里要有明确负责人维护测试框架，用例要有版本管理，测试环境的搭建和销毁要实现一键化，以及最关键的一点——测试用例的可读性必须当作代码质量来要求，让新成员能看懂得能改。我见过太多测试资产变成"僵尸代码"的案例。那些用例其实跑过也发现过问题，但因为没人维护，断言越写越粗糙，最后全被注释掉或者干脆被删除。Deepagents这个领域变化太快，测试资产如果不用产品化的标准去维护，三个月就报废，届时稳定性建设等于从零再来。最后的一点私货Deepagents的自动化测试走到今天，我感触最深的一点是：与其追求消除所有随机性，不如学会与不确定性共舞。LLM的创造力正是Agent产品的价值来源，你不能既想要它灵活规划，又想让它每条路径都可预测。测试体系的全部艺术，在于划定一条"范围合理的边界"——边界之内自由发挥，边界之外有规则托底。在这个领域待久了会形成一种直觉：看到一次测试失败，先不急着翻代码，而是去看Agent的行为轨迹里，它是在哪一步开始"偏离"的。很多时候不是逻辑错了，是它在尝试一个你没预料到的合理路径，而你的测试太窄了。改断言，而不是改产品，这本身就是AI系统开发的常态。最后分享一个感觉：把测试体系稳定建设好之后，团队最大的变化是敢改了。有了可信赖的回归网络，提示词调优、工具增删、模型替换都不再是如履薄冰的事，反而变成了可以快速验证的实验过程。真正卡住AI应用落地速度的，往往不是模型能力不够，而是你不知道改完这一版会不会把线上已经稳的功能改坏。一套高质量的自动化测试，补齐的正是这个安全感缺口。如果你也正在被Agent稳定性问题困扰，我建议从最小闭环开始：先固定测试环境，再写三个核心场景的端到端用例，最后压上压力和回归层。跑通这条路，小步快跑，前面提到的所有复杂设计都会在需要它们的时刻自然浮现出来。
做过AI Agent相关开发的朋友应该都有同感：写一个能跑通的代理不难，难的是让它稳定地跑完一百遍。LLM天然带有随机性，同样的输入，今天输出这个结果，明天就可能换个路径，哪怕最终答案都对，中间调用的工具顺序、传参格式、思考链路都可能不一样。这意味着，传统单元测试里"断言返回值符合预期"那套玩法，到了Deepagents这类Agent框架上，直接失灵——你没法断言Token流里的每一句话。Deepagents这个名字，本质上指向的是一类具备自主规划、工具调用、多步执行能力的Agent框架。它的质量保障，不能靠"多调试几次"，必须靠一套专门为"非确定性系统"设计的自动化测试体系。这篇文章我会从三个层面拆解：Agent测试和传统测试到底差在哪、Deepagents自动化测试该怎么设计断言和用例、以及我在实践中踩过的坑和沉淀下来的排查方法。无论你是正在做AI应用的QA、负责Agent平台的工程师，还是刚接触这个领域想建立测试体系的新手，这套思路都可以直接落地。1. 为什么AI代理测试和传统测试不在一个维度在动手写测试用例之前，最要紧的是想明白一个问题：我们对一个Agent的"正确"到底该怎么定义。这个定义想不清楚，后面所有的断言、回归、稳定性建设都是空中楼阁。1.1 不确定性带来的测试哲学转变传统软件测试的本质是"验算"。你有一个确定函数，输入1+1，断言输出2，跑一万次也是一样的结果。如果某次跑出3，那就是bug，定位修复即可。AI代理完全不是这么回事。Deepagents这类框架让模型自己决定调用哪个工具、按什么顺序调用、如何拆解子任务。这是个开环系统，输出空间几乎是无限的。用一个固定答案去套一个开放系统，测试用例本身就会变成抖动的源头：这次跑通了，下次跑不通，你说这是产品坏了还是测试写错了？所以我在实际项目中把测试哲学从"验算"换成了"监考"。传统测试是检查学生交上来的答案是不是100；Agent测试是给监考老师一个评分标准：学生有没有在规定时间内交卷、有没有作弊抄隔壁、答题过程是否符合考试纪律，至于中间草稿纸上的演算步骤，只要不违规，写不写都行。这个转变非常关键。它意味着断言的对象从"终态字符串"迁移到了"行为轨迹与终态达成"两层。我后面会详细展开这两层的具体写法。1.2 Deepagents测试体系的设计理念基于"监考"这个思路，我给Deepagents测试体系定了三条设计原则。第一条是行为可观测。测试环境里所有工具调用必须留下结构化日志，不能只有自然语言文本。框架每次调用工具时的名称、入参、出参、延迟，都要能JSON化落盘。这是后续一切断言的基础——你没法断言一个你看不到的过程。第二条是环境可隔离。Agent测试绝对不能打在真实生产服务上。我见过团队直接拿生产环境当测试场，结果Agent半夜调用了一个真实的下单接口，产生了实际扣款。这种事故一次就足够让人长记性。测试环境里，外部服务全部用可控的桩实现或容器化Mock，数据源用种子数据快照。第三条是结果可复现。对于给定的测试用例，要么你接受"路径不同但殊途同归"，要么你把随机性压到可控范围。一个实用做法是固定模型版本、温度参数设为接近0、禁用流式输出。这样虽然不百分百保证确定性，但能把"合法路径"的数量从无限压缩到有限几类，让断言规则可以覆盖。2. Deepagents自动化测试的关键设计：断言、工具调用与状态管理理清了理念，接下来就是具体设计。Deepagents的测试用例，我在项目里通常拆成三个核心组件：前置条件、执行动作、断言规则。前置条件和传统测试一样，构造输入与状态；执行动作就是跑Agent；差别全在断言规则上。2.1 断言的不再是返回值而是行为轨迹刚才说了，Deepagents测试的第一层断言是行为轨迹。所谓轨迹，就是Agent从开始到结束的完整工具调用序列。我第一个建议是：不要严格比对该序列，除非你的场景是"必须按固定流程操作"。举个例子，一个查天气的Agent，它可以先查城市编码再查天气，也可以直接传城市名查天气。两条路径的结果完全一样，但严格序列比对会让测试用例变成易碎的瓷器。正确做法是提取轨迹的关键特征：调用了哪些工具、工具的入参是否满足约束、是否有重复无效调用、是否有循环死锁。在代码层面，我一般把完整的工具调用Sequence做一个投影运算，只保留我们关心的属性，然后对投影结果做断言。比如"必须调用过SearchTool""SearchTool的关键词参数非空""从发起请求到返回结果的总步数不超过N步"。这样既有约束力，又留足了Agent自主规划的弹性空间。2.2 工具调用链的验证方法第二层断言，是对每个工具调用的出入参进行约束性校验。这里的核心不是断言"精确等于某某值"，而是断言"满足某个不变量"。我总结了三类验证方法，实战中配合使用。第一类是Schema校验。每个工具在框架里都有输入Schema，测试时对Agent实际传入的参数做JSON Schema校验，字段类型错误、必填项缺失这种低级幻觉立刻就能抓出来。这相当于给Agent的工具使用划了一条底线：你可以自由发挥，但话不能乱说。第二类是领域不变量校验。特定业务场景下的硬约束。比如金额字段不能为负数、用户身份必须是测试白名单内的ID、时间参数不能早于某个基准点。这类校验往往比Schema校验更贴近业务，也更能抓住真正有杀伤力的bug。第三类是副作用校验。工具不是无痕的，它会有数据库写入、缓存更新、外部资源占用。测试要在Agent执行完成后比对前置状态与后置状态，排除泄漏的脏数据。这个需求引出下一个关键设计。2.3 状态管理与隔离Deepagents有状态，这是它和普通API的重要区别。对话上下文、中间变量、临时文件、外部服务连接，都会在执行过程中累积。测试如果不管理状态，用例之间会互相污染，出现"A用例单独跑能过，跟着B用例跑就失败"的邪门问题。我推荐的办法是事务级回滚 + 环境级重建双管齐下。事务级回滚针对数据库这类有事务支持的组件。每个测试用例外层包一个事务，执行完直接回滚，数据恢复到测试前状态。缓存类组件则在用例开始前删除相关Key，形成干净起点。环境级重建针对Agent持有的上下文对象。Deepagents运行时会维护agent state，测试必须确保每个用例拿到的是全新初始化的State，不能复用上一个用例残留的中间变量。这块我在框架层封装了一个fixture，每个用例自动实例化新Agent、注入新会话ID。效果立竿见影，状态串扰导致的口角问题基本清零。3. 实操：搭建一套Deepagents质量保障基线从设计落到工程，下面是我在模拟项目X里完整落地过的一套Deepagents测试体系。这套体系可以按需裁剪，但整体架构是经过验证的。3.1 测试环境与资源配置Deepagents测试环境和传统API测试环境最大的区别是：你需要一个可控的LLM网关。LLM调用是Agent测试中最大的变量源和成本源。直接打供应商的在线接口，网络抖动、限流、随机性会把测试结果搅成一锅粥。我建议团队在测试环境里部署一个代理网关，统一拦截测试用例里的模型调用。网关要提供几个能力：按预置内容响应（模拟固定模型输出）、按用例维度限制调用次数、记录每次调用的Token消耗与耗时。有了这个网关，你在测试用例里可以对Agent说"最多只能调用N次LLM"，超过就断言失败，防止循环失控。外部依赖方面，我的基线配置是：数据库用PostgreSQL容器，初始数据从SQL快照恢复搜索/检索类工具用一个预置索引的轻量向量库替代，数据量几百条，覆盖典型场景HTTP类外部API全部用接口Mock服务，按路由规则返回固定Fixture文件系统操作指向临时目录，用例结束自动清空特别注意：LLM网关不等于把模型换成"人教版教材"。真实项目里我会区分两类用例。冒烟测试用网关的定值响应，追求速度与稳定；完整回归用真实模型，跑完整场景，追求探索未知问题。两者缺一不可。3.2 第一类测试：确定性单元测试这类测试针对的是Agent内部不需要模型参与的纯逻辑模块。虽然Deepagents的核心是LLM，但工程上一定存在大量非智能组件，比如工具调用参数的预处理、结果解析器、提示词模板渲染、错误处理分发。这些组件是确定性的，完全可以按传统单测方式来写。我用pytest框架，针对每个纯函数模块维护一份测试矩阵。核心价值不在于测试多复杂，而在于给Agent系统建立一个"确定性锚点"——每当提示词模板或工具定义发生变化时，先跑这批测试，能第一时间发现模板语法错误、参数名不匹配这类低级问题，不用每次都启动完整Agent链路。这类测试的覆盖率在项目里大约占30%左右。别小看这30%，它们保证了Agent运行时的地基是稳的。地基不稳，上层再聪明的模型也会被绊倒。3.3 第二类测试：端到端场景测试重头戏在这里。端到端场景测试模拟一个真实用户从发起请求到目标达成的完整链路。我给每个场景维护一个结构化用例文件，包含场景描述、初始环境、预期行为不变量、禁止行为列表。场景设计上，我遵循"二八法则"。先梳理线上运营反馈中高频率出现的Top 20用户需求，把它们固化为场景用例。比如"用户查询本月账单并申请备注修改""用户咨询退货政策并引导提交售后单"。这20个场景覆盖了80%的生产流量形态，是稳定性的基本盘。每个场景用例的断言，按照前面说的两层结构来写。行为轨迹层面：断言必须在N步内完成、必须调用特定核心工具、不得调用禁区工具。业务结果层面：断言最终写入数据库的实体状态、对外返回的关键字段。双断言确保Agent既干成了事，又没干出格。为了保证场景测试高效执行，我给测试框架设置了超时熔断。单个场景最长允许多久，由场景复杂度决定，但每个用例都硬性设上限，优雅超时并导出截止当前的轨迹日志，方便排查是卡死还是慢。3.4 第三类测试：稳定性压力测试场景测试解决"对不对"，压力测试解决"扛不扛得住"。Deepagents的压力测试我是从三个维度做的。并发维度，同一场景用例并发N个实例，观察资源占用和接口错误率。连续维度，同一场景串行循环执行N次，观察Token消耗是否有泄漏、内存是否持续增长、外部桩服务是否有连接泄漏。长链路维度，构造一个需要多个工具交替调用、跨数个上下文轮次的复杂任务，验证长时间运行下Agent的规划能力和上下文记忆衰减情况。压力测试的通过标准，不是"零失败"。LLM系统里零失败是不现实的理想态。我定的标准是：连续运行的失败率低于2%，且任何一次失败都能在30秒内由重试机制拉起，不会造成死循环或状态错乱。实际操作中会发现，很多在场景测试里跑得好好的用例，一进压力测试就出事。最常见的两类，一是Agent进入循环策略反复调用同一个工具，Token成本爆炸；二是并发场景下多个实例共享某个工具的内部可变状态，产生竞态。这两类问题都需要靠压测来暴露。4. 高频问题与排查实录测试体系建起来之后，运维的挑战才真正开始。下面是我在Deepagents测试建设过程中遇到的几类高频问题，全部来自实际记录，每一类都对应着可以复用的排查思路。4.1 断言抖动问题：测试结果忽绿忽红这是Agent测试里最让人血压升高的问题。同一份代码，同一个用例，上一条跑得好好的，下一条就红了，而且没有任何代码变更。等十分钟再跑一次，又绿了。我排查这类问题有个固定流程。第一步看日志，把失败用例的完整轨迹和成功用例的轨迹做diff，观察差异发生在哪个环节。是LLM调用返回不同了，还是某个工具Mock返回值被并发修改了。第二步检查测试隔离性，看是不是有共享的可变状态在用例间泄漏。第三步才轮到模型随机性。一开始我经常归咎于"LLM随机性"，后来发现一大半抖动其实是测试自身不干净造成的。Shared fixture、环境变量被某个用例改写、Mock服务内部计数器跨用例累积，这些才是真正的元凶。把状态隔离做好之后，抖动率能下降一半以上。剩下的模型随机性抖动，通过放宽非关键路径的断言粒度来消化。4.2 工具副作用导致的状态污染Deepagents执行过程中经常会出现连带副作用。比如一个"查询用户订单"的工具，可能顺手在访问日志表里写了一行记录；一个"生成报告"的工具，可能向消息队列推送了一个通知。单次执行看不出问题，但测试用例一多，这些副作用就像漏水的水龙头，把测试环境的地板全泡湿了。我总结的排查信号是：用例单独跑全绿，按某个固定顺序跑就翻车，且失败位置和顺序密切相关。这种九成是副作用污染。解决方案分两层。第一层，对所有测试用到的工具做副作用审计，凡是会写外部状态的工具，要么改成Mock版本，要么在用例结束后做状态回滚。第二层，引入"执行前后快照比对"机制，跑完用例自动比对数据库表行数、缓存Key集合、消息队列积压量，一旦差异超出阈值直接标红。这个机制起来后，测试环境的稳定性上了一个台阶。副作用不再靠人肉排查，系统会自动捕捉。4.3 成本控制与超时设计Deepagents测试跑久了，最肉疼的是Token账单。场景测试跑一次可能只要几万Token，但压力测试一晚跑下来，消耗可以上百万。我见过团队上线AI功能后，测试环境成本比生产还高一截，财务过来拍桌子的场面。成本控制我用了三板斧。第一板斧是分级执行。日常提交只跑确定性单测和冒烟场景，完整场景测试在夜间定时跑，压力测试只在发版前跑。第二板斧是规划限制器。每个用例设置最大LLM调用次数，一旦突破就被判失败，防止Agent陷入乱试循环。第三板斧是调用结果缓存。相同输入条件下，命中断言规则的路径结果缓存复用，避免反复烧钱。超时设计是个容易被忽视的细节。Agent测试的超时不能简单"到点杀进程"——杀进程丢的是调试线索。我会在超时触发时先尝试导出当前完整轨迹与工具调用链，再做中断。这样即使用例最终是红的，也拿到了足够分析的数据，不会白白烧一次请求只得到一个"timeout"。5. 稳定性建设的进阶心得如果前面的内容是在解决"有没有"，这一节想聊的是"稳不稳"。Deepagents测试体系跑到后期，真正拉开团队差距的不是用例数量，而是对稳定性细节的处理，这里分享三个我反复打磨过的点。5.1 重试策略与指数退避Agent执行过程中的失败，很多是临时性的。Mock服务偶发延迟、外部API限流、LLM网关瞬时拥堵，这类故障重试一下就好了。但重试要有策略，最简单粗暴的"失败就立即重跑"是下策，会让系统在负载高峰时雪上加霜。我在框架层实现了指数退避重试。第一次失败等待短信级别的时间，第二次翻倍，最多重试四轮。重试之间还加入了随机抖动，避免多个并发用例同时重试形成谐振峰。更关键的是，重试只重跑失败的那一步动作链，不重新执行整个Agent流程。这里需要Deepagents具备步骤级状态快照能力，运行到每个工具调用处都记录检查点，从检查点恢复推进。这套机制上线后，压测的最终成功率从96%级别提到了逼近100%。5.2 回归测试基线的维护稳定性还体现在"不倒退"。AI系统是持续迭代的，提示词文件在改、工具定义在改、模型版本在换。每次改动都可能让原本稳定的行为变得不稳定。回归测试基线就是把每个场景的"历史成功轨迹特征"沉淀下来，做增量比对。具体做法，我把每次发布的成功用例轨迹投影哈希后存入基线库。新版本跑完同样用例，生成新的轨迹哈希，和基线比对。如果哈希完全一致，说明行为收敛；如果差异较大，就需要人工审查差异原因，确认是"预期的优化"还是"非预期的漂移"。这个机制让我在模型升级时心里有底。换模型前先跑基线库，观察漂移面的范围，再决定是灰度切流还是继续用老版本。没有这层基线保护，每次模型升级都是一场赌运气。5.3 把测试当作产品功能本身来建设最后一个心得，可能听起来有点虚，但它是整个体系的根基：Deepagents测试不能当作QA的负担项目来做，它应该被当作一条独立的产品线来建设。我观察到一个普遍现象：AI项目早期测试都是员工抽空用脚本堆一些临时用例，接口一变脚本就崩，然后没人维护，自动化测试就名存实亡了。要让测试体系活下来，必须赋予它和业务功能同等级的资源投入。团队里要有明确负责人维护测试框架，用例要有版本管理，测试环境的搭建和销毁要实现一键化，以及最关键的一点——测试用例的可读性必须当作代码质量来要求，让新成员能看懂得能改。我见过太多测试资产变成"僵尸代码"的案例。那些用例其实跑过也发现过问题，但因为没人维护，断言越写越粗糙，最后全被注释掉或者干脆被删除。Deepagents这个领域变化太快，测试资产如果不用产品化的标准去维护，三个月就报废，届时稳定性建设等于从零再来。最后的一点私货Deepagents的自动化测试走到今天，我感触最深的一点是：与其追求消除所有随机性，不如学会与不确定性共舞。LLM的创造力正是Agent产品的价值来源，你不能既想要它灵活规划，又想让它每条路径都可预测。测试体系的全部艺术，在于划定一条"范围合理的边界"——边界之内自由发挥，边界之外有规则托底。在这个领域待久了会形成一种直觉：看到一次测试失败，先不急着翻代码，而是去看Agent的行为轨迹里，它是在哪一步开始"偏离"的。很多时候不是逻辑错了，是它在尝试一个你没预料到的合理路径，而你的测试太窄了。改断言，而不是改产品，这本身就是AI系统开发的常态。最后分享一个感觉：把测试体系稳定建设好之后，团队最大的变化是敢改了。有了可信赖的回归网络，提示词调优、工具增删、模型替换都不再是如履薄冰的事，反而变成了可以快速验证的实验过程。真正卡住AI应用落地速度的，往往不是模型能力不够，而是你不知道改完这一版会不会把线上已经稳的功能改坏。一套高质量的自动化测试，补齐的正是这个安全感缺口。如果你也正在被Agent稳定性问题困扰，我建议从最小闭环开始：先固定测试环境，再写三个核心场景的端到端用例，最后压上压力和回归层。跑通这条路，小步快跑，前面提到的所有复杂设计都会在需要它们的时刻自然浮现出来。