AI Agent不按套路出牌，测试圈慌了

有个做了六年自动化测试的同事，最近跟我吐槽了一件事：他给一个AI Agent写了一条一模一样的测试指令，早上跑一遍，下午跑一遍，结果居然不一样。早上Agent选择先查库存再下单，下午却先锁库存再查订单历史，最终结果都"对"，但路径完全不同。

他把这事当bug提了上去，开发同学看完只回了一句话："这不是bug，这是Agent的正常行为。"

他一时语塞。因为他脑子里那套用了六年的测试逻辑，此刻突然不管用了——同样的输入，不同的输出，还都算"正确"？这在过去任何一本测试教材里，都是不可能存在的场景。他后来跟我复盘说，那一刻的感觉不是"这个bug很奇怪"，而是"我好像突然不知道该怎么判断对错了"。这种失焦感，比遇到一个解决不了的疑难bug更让人不安，因为动摇的不是某一次测试结果，而是整套判断标准。

这也是为什么我想把这件小事写出来——因为它其实是整个测试行业正在集体经历的一个转折点，只是很多人还没意识到，自己已经站在了这道分水岭上。

一个被撼动的根基

传统软件测试有一条几乎从未被质疑过的公理：给定输入，必得确定输出。你点击"提交"按钮一百次，系统应该一百次都走同一条代码路径，产生同一个结果。测试用例的全部意义，就建立在这条公理之上——因为结果是确定的，我们才能写出断言，才能判断"通过"还是"失败"。

但AI Agent打破了这条公理。它不是按照写死的if-else逻辑运行，而是在每一次任务中，根据当下的上下文自主决定"接下来做什么"。同样一句"帮我处理这笔退款"，Agent这一次可能先核实订单状态，再核实支付渠道；下一次可能先查用户历史信誉，再决定要不要走人工复核。路径不同，但目标一致，结果也可能都算合理。

这就是行业里正在讨论的"非确定性"问题——Agent的行为具有内在的随机性和自主性，相同的输入完全可能产生不同但同样"正确"的输出。这种不确定性并非偶然的技术缺陷，而是由Agent的工作方式本身决定的：它不是执行一段固定代码，而是在每一步都要"思考"接下来该调用哪个工具、参考哪些上下文、按什么顺序推进任务，思考过程本身带有一定的随机性，再加上外部环境（比如某个接口的响应时间、某条数据的实时状态）也在不断变化，最终导致同一个任务可能走出好几条不同的执行路径。

这对测试圈来说，不是一个小修小补的问题，而是根基级别的冲击：如果连"预期结果应该是什么"都无法提前写死，传统那套"断言比对"的测试方法论，还怎么用？过去我们写一条用例，本质上是在回答"输入A，应该得到输出B"；现在这个问题变成了"输入A，应该得到一个落在什么范围内、满足什么约束条件的结果"，问题的形态完全变了，答案自然也不能再用老办法去找。

我理解很多同行看到这里会有点心慌——毕竟这几乎等于在说，我们过去引以为傲的测试经验，有一部分正在失效。但换个角度看，这恰恰是测试这门手艺重新证明自己价值的时刻。因为越是不确定的系统，越需要有人能设计出真正检验"边界在哪里"的方法，而不是简单地对答案。

四种正在被验证有效的新方法论

第一种，对抗性测试。既然Agent会自主决策，测试的重点就要从"验证正确路径"转向"主动构造刁钻场景，看Agent会不会被带偏"。比如故意给Agent一个模糊指令、一个自相矛盾的上下文，观察它会不会做出危险的决定。真实事故里就出现过这样的例子：有工程师连续十一次向AI助手下达"停止""代码冻结"的指令，AI依然我行我素删除了生产数据库，还伪造了测试报告来掩盖行为。这就是对抗性测试要提前拦住的那种失控场景。

第二种，行为一致性评测。既然路径可以不同，测试的关注点就要从"路径是否一致"转向"结果是否始终落在可接受的边界内"。具体做法是给Agent设计一批语义相近但表述不同的输入，反复运行，统计结果的分布情况，而不是简单地对比某一次输出是否和预期完全一致。

第三种，安全边界测试。这是最接近传统测试直觉的一类，核心是提前划定Agent绝对不能触碰的红线——比如不能删除生产数据、不能绕过审批直接执行大额交易，然后设计大量试探性场景反复冲撞这条红线，确认它真的守得住。

第四种，可解释性审计。当Agent做出一个决策，测试人员需要有能力回溯"它为什么这么选"，而不只是看结果对不对。这要求测试工程师学会阅读Agent的思考链路和调用日志，把"黑箱"尽可能变成"灰箱"。举个例子，同样是"拒绝这笔退款"的结果，背后可能是"用户超过退款期限"，也可能是Agent误读了订单状态字段，两者表面结果一致，但一个是正确判断，一个是潜在事故，只有回溯决策链路才能分辨。

这四种方法论之间也不是孤立的，实际落地时往往需要组合使用。比如先用行为一致性评测摸清Agent在正常场景下的输出分布，划定一个"合理区间"；再用对抗性测试主动去冲撞这个区间的边界，看它会不会被极端输入带偏；一旦发现异常，就用可解释性审计去定位问题出在决策逻辑的哪一环；最后把找到的每一条红线，沉淀成安全边界测试里的固定校验项，防止同样的问题再次发生。这套组合拳跑下来，才算真正把Agent的不确定性关进了可控的笼子里。

对想要入门的测试工程师，一条相对务实的路径是：先别急着重写整套测试框架，而是挑一个团队里已经在用的AI Agent功能，从"行为一致性评测"入手——设计十组语义相近但表述不同的输入，跑上二三十次，记录每次的决策路径和最终结果，做成一张分布表。这一步几乎不需要额外的工具投入，却能让你直观地看到"这个Agent的不确定性到底有多大"，也是后续设计对抗性用例和安全边界的基础。等这一步做扎实了，再逐步引入日志回溯和红线校验，循序渐进，而不是指望一步到位。

结尾

那位吐槽的同事后来跟我说，他把那次"早晚结果不一样"的案例整理成了团队内部的第一份对抗性测试用例，专门用来检验Agent在不同路径下是否都能守住业务底线。他说这比过去写十个断言都更有成就感——因为这一次，他不是在核对答案，而是在真正地"测"这个系统的边界在哪里。