引子上周我在公司跑一组智能体回归测试同一个任务跑了 30 遍通过率 67%。同事看了一眼说那这智能体到底行不行我答不上来。在传统软件测试里行不行是个非黑即白的问题。同一个输入跑 100 遍结果应该一模一样。assert add(2, 3) span classwx-em-red 5这个测试要么 pass要么 fail没有中间状态。但智能体不是这样的。同一个任务temperature 不同输出的文本可能不同。同一组 30 次运行可能出现多种不同的输出文本但其中大部分都算答对了。这不是智能体的问题。这是测试方法的问题。我们用确定性测试的尺子去量一个概率性的东西量出来的数据没有决策价值。这篇文章不讨论智能体本身只讨论一件事传统测试方法为什么对智能体失效以及失效之后该怎么调整思路。传统测试的三个假设所有传统软件测试方法论都建立在三个前提上。这三个前提在智能体场景下全部不成立。假设一相同输入产生相同输出这是测试可重复性的基础。一个 bug 能复现说明输入和输出之间有确定的因果关系。测试工程师写用例、造数据、跑脚本核心逻辑就是控制变量、观察输出。智能体打破了这个假设。同样的任务描述同一个模型同样的 API 调用输出可能不同。原因有三temperature 参数控制生成的随机性。temperature 0 时每次采样路径不同。上下文窗口截断对话历史超过窗口限制时早期信息被丢弃。同样的任务在第 3 轮和第 13 轮跑上下文不同输出不同。外部依赖波动工具调用API、数据库、网页抓取的响应时间和返回内容可能有微小差异这些差异会进入 LLM 的下一轮推理放大成不同的输出。假设二预期结果可以精确描述传统测试用例的标准格式是输入预期输出实际输出结果add(2, 3)55pass预期输出是精确的、可比较的。assert expected /span actual一行代码搞定。智能体的输出不是这样的。分析这份销售数据——什么叫分析对了智能体 A 输出了 3 个图表 一段文字总结得 78 分智能体 B 输出了 5 个图表 三段文字总结得 72 分智能体 C 只输了一段文字但指出了关键趋势得 85 分三个输出格式完全不同但质量有高低。预期输出无法用精确值描述只能用评分标准来衡量。评分代替断言之后新问题来了谁来评怎么评评的标准一致吗这些是后面几篇要展开的内容这里只点出问题。假设三缺陷可以精确复现传统测试发现 bug 后第一步是复现。复现不了开发不认。智能体的缺陷复现困难。一个任务在第 7 次运行时失败了第 8 次用同样的参数跑可能又成功了。不是 bug 修了是随机性导致的波动。这导致三个后果缺陷报告质量下降无法提供稳定的复现步骤开发无法定位根因。回归判断失真改了一行代码跑测试发现通过率从 67% 变成 65%不知道是代码改坏了还是随机波动。根因定位靠猜输出错误时不知道是 Prompt 问题、工具问题、模型问题、还是上下文问题。失效的五个环节传统测试流程有五个核心环节。智能体场景下每个环节都需要改造。环节一用例设计传统方式写精确的预期输出。智能体场景预期输出是模糊的。需要改为写成功标准而非预期值。比如计算 25 * 4 100 / 5这个任务传统测试预期输出 120智能体测试成功标准 输出中包含数字120且没有明显的计算错误再比如分析销售数据生成周报传统测试无法写用例输出不固定智能体测试成功标准 包含至少 3 个分析维度 有明确的结论 数据引用正确环节二环境控制传统方式固定测试环境控制所有变量。智能体场景需要控制的是 LLM 相关的变量temperature测试时建议固定避免随机性干扰seed如果模型支持固定随机种子提高可重复性模型版本锁定具体版本如qwen-plus-0813避免模型升级导致行为漂移工具状态Mock 外部依赖避免网络波动影响测试结果环节三执行策略传统方式每个用例跑一次pass 或 fail。智能体场景需要多次运行统计分布。单次运行 → 统计 30 次运行的成功率 单次断言 → 统计分布P50、P90、通过率这不是多跑几次那么简单。需要定义运行次数30 次是经验值中心极限定理n≥30 时样本均值近似正态分布通过阈值成功率 ≥ 70% 算通过还是 ≥ 80%这取决于业务场景波动容忍度P50 和 P90 的差异超过多少需要告警环节四缺陷定位传统方式看日志、看堆栈、看输入输出差异。智能体场景智能体的执行过程是黑盒的。需要额外的可测性设计结构化日志每个阶段规划、执行、反思、总结输出标准化日志状态暴露暴露当前阶段、已执行子任务、失败原因检查点机制关键节点输出检查点支持断点验证这些是第 6 篇的内容这里只提结论不可测的系统无法自动化智能体需要主动暴露内部状态。环节五回归判断传统方式跑测试对比 pass/fail 数量。智能体场景需要对比的是分布不是单次结果。旧版本30 次运行通过率 67%平均 token 消耗 4200 新版本30 次运行通过率 65%平均 token 消耗 4500 结论通过率下降 2%token 消耗增加 7%。需要判断 1. 2% 的下降是统计显著还是随机波动 2. 7% 的 token 增加是否在预算范围内 3. 哪些用例从 pass 变成了 fail这需要版本对比工具不是简单的 diff。这是第 15 篇的内容。代码温度对稳定性的影响理论讲完了看数据。下面这个脚本用同一个智能体、同一个任务、不同 temperature 各跑 30 次统计成功率和输出一致性。#!/usr/bin/env python3 温度对智能体稳定性的影响实验 对比 temperature0.3/0.7/1.0 三种设置下 同一任务跑 30 次的成功率和输出一致性。 注CustomAgent 是你项目中的封装实际使用时替换为你的 Agent 类。 核心逻辑固定 temperature多次运行统计分布。 import os import statistics import requests from collections import Counter # 你的 API Key从环境变量读取 API_KEY os.getenv(DASHSCOPE_API_KEY) API_URL https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions MODEL qwen-plus TASK 计算 25 * 4 100 / 5把结果存储到记忆中 EXPECTED_ANSWER 120 N_RUNS 30 TEMPERATURES [0.3, 0.7, 1.0] def call_llm(temperature: float) - dict: 调用 LLM API resp requests.post(API_URL, headers{ Authorization: fBearer {API_KEY}, Content-Type: application/json, }, json{ model: MODEL, messages: [{role: user, content: TASK}], max_tokens: 2048, temperature: temperature, }, timeout60) if resp.status_code span classwx-em-red 200: result resp.json() return { success: True, content: result[choices][0][message][content], tokens: result.get(usage, {}).get(total_tokens, 0), } return {success: False, error: resp.text[:200]} def check_success(result: dict) - bool: 检查任务是否成功输出包含正确答案 if not result.get(success): return False return EXPECTED_ANSWER in result.get(content, ) def check_output_consistency(results: list) - float: 检查输出一致性最高频输出占总成功数的比例 outputs [r.get(content, ).strip() for r in results if r.get(success)] if not outputs: return 0.0 counts Counter(outputs) most_common_count counts.most_common(1)[0][1] return most_common_count / len(outputs) def run_experiment(): print(f任务: {TASK}) print(f运行次数: {N_RUNS} 次/温度) print(f模型: {MODEL}) print() for temp in TEMPERATURES: results [] for i in range(N_RUNS): result call_llm(temp) results.append(result) # 统计 success_count sum(1 for r in results if check_success(r)) success_rate success_count / N_RUNS consistency check_output_consistency(results) tokens [r.get(tokens, 0) for r in results if r.get(success)] avg_tokens statistics.mean(tokens) if tokens else 0 print(ftemperature{temp}: 成功率{success_rate:.0%}, f一致性{consistency:.0%}, 平均Token{avg_tokens:.0f}) if __name__ /span __main__: run_experiment()数据是 2026-05-08 真实跑的模型 qwen-plus每个温度跑 30 次temperature成功率输出一致性唯一输出数平均 TokenP50 Token平均耗时0.3100%50%61671653.6s0.7100%50%71651653.7s1.0100%67%91561513.5s几个观察简单任务下 temperature 影响有限计算题对所有 temperature 都 100% 正确。temperature 的差异在更复杂的任务如创意写作、推理中会更明显。输出一致性不是单调的temperature1.0 时一致性反而更高67% vs 50%。这说明一致性不仅受 temperature 影响还和采样路径、任务类型有关。Token 消耗没有随 temperature 单调变化temperature1.0 时平均 token 反而更少156 vs 167。temperature 控制的是概率分布的平滑度不是输出长度。这个实验说明至少在数学计算这类确定性任务上temperature 对 token 消耗的影响不大。至于创意写作或推理任务需要单独验证。耗时差异不大3.5s vs 3.6s在误差范围内。这个实验说明一件事temperature 对简单任务影响有限但对复杂任务推理、创意、安全的影响需要单独评估。测试时固定 temperature 是为了保证可比性不是因为 temperature 一定会导致失败。补充说明这个实验用的是 qwen-plus 模型任务类型是数学计算。不同模型、不同任务类型的 temperature 敏感度可能完全不同。下一篇我们会测创意写作和推理任务数据会更有趣。交付物智能体测试 vs 传统测试对比清单下面这个清单列出了 12 个关键差异点。每个差异点都对应一个需要改造的环节。#对比维度传统软件测试智能体测试改造方向1输出确定性相同输入 → 相同输出相同输入 → 不同输出从断言改为统计分布2预期描述精确值expected actual模糊标准评分从 assert 改为评分机制3缺陷复现可精确复现概率性出现多次运行 日志追踪4用例设计输入 预期输出输入 成功标准从精确值改为条件判断5执行次数1 次≥30 次统计显著性6环境控制固定 OS/依赖/配置固定 temperature/seed/模型版本控制 LLM 相关变量7失败判断pass/fail成功率/质量分从二元判断改为连续评分8回归对比diff 输出对比分布版本间统计检验9根因定位日志 堆栈结构化日志 检查点可测性改造10性能指标响应时间/吞吐量延迟/Token 消耗/成功率增加 LLM 特有指标11测试数据边界值/等价类梯度难度/对抗样本增加模糊测试12报告输出pass/fail 统计多维度得分 趋势从表格改为雷达图温度设置建议基于上面的实验给出测试场景的温度设置建议测试阶段建议 temperature理由单元测试0.1-0.3最大化可重复性快速定位问题集成测试0.3平衡稳定性和真实性回归测试0.3版本间可比减少随机波动干扰探索性测试0.7-1.0发现边界 case测试多样性生产环境按业务场景定客服场景低温度稳定创意场景高温度多样核心原则测试时温度要低生产时温度按需求定。测试的目的是发现问题不是模拟生产。生产环境的 temperature 由业务需求决定但测试环境必须固定否则数据不可比。总结传统测试方法对智能体失效不是不太好使是根本不对。确定性测试的尺子量不了概率性的东西。需要改造的不是一两个环节是从用例设计到回归判断的全链路。这篇文章列出了 12 个差异点给出了温度设置建议。但具体怎么改造——测试数据怎么设计、评分机制怎么做、可测性怎么加——后面逐篇展开。下一篇讲智能体测试的 6 维能力模型。单一分数没有决策价值需要按业务场景设计权重。