AI 驱动的客户服务平台在负载测试中表现良好，但在生产环境中却崩溃了。原因是传统负载测试无法模拟 AI 对话的复杂性，包括上下文累积、非确定性行为和多模态输入。为了有效测试 AI 代理，需要模拟对话模式、分析认知负荷、进行对抗性输入测试，并采用新的指标来衡量对话健康、认知负荷和经济效益。
译自：Why Load Tests Lie: Harsh Truth About AI Agent Performance
作者：Sudhakar Reddy Narra
想象一下：您的团队刚刚完成了负载测试，有 10,000 名并发用户正在全力测试您闪亮的新型 AI 驱动客户服务平台。仪表板显示绿色，响应时间远低于目标，错误率几乎为零，吞吐量更是超出了预期。您选择在周五下午上线。
然而到了周一早上，系统却崩溃了。但奇怪的是：您只有 300 名活跃用户，而之前的负载测试轻松处理了 10,000 名用户而毫无压力。
没有网络峰值，也没有传统意义上的隐藏 bug。原因是什么？是没人想到要测试的东西：人们实际如何与 AI 代理 进行对话。
传统负载测试的基本缺陷
在过去的几十年里，负载测试 一直是合理的。您一直在测试 API，比如命中一个端点，得到一个响应，然后重复。增加虚拟用户数量直到系统崩溃。数学很简单：请求越多，负载越大。找到瓶颈，优化，然后就完成了。
然后 AI 代理出现了，并颠覆了我们所知的一切。
问题在于：AI 代理打破了传统负载测试所依据的几乎所有假设。
假设 1：请求是独立的
传统思维：每次 API 调用都是独立的。第 1 个请求与第 1,000 个请求没有任何影响。它们是孤立的事件。
AI 现实：对话会携带之前发生的一切。它就像不断堆积的对话包袱。
看看这个——用户的第一个消息：“我的订单还没到。”
- 消耗的 Token：150
- 延迟：800 毫秒
- 成本：0.0003 美元（几乎可以忽略不计）
同一用户在同一对话中的第十条消息：“那我买的保险怎么办？”
- 消耗的 Token：2,400（因为现在你携带了九条消息的上下文）
- 延迟：3,200 毫秒（慢了四倍）
- 成本：0.0048 美元（贵了 16 倍）
您的负载测试？它以全新的、干净的上下文命中该端点 10,000 次。生产环境中有 300 人在进行深入、曲折的对话，而您的测试从未模拟过这些。负载特征完全不同。
当您第一次在生产环境中看到这种情况时，可能会感到惊讶。性能下降的曲线比任何人预期的都要陡峭得多。
假设 2：行为是可预测的
传统思维：相同的输入 = 相同的输出 = 相似的响应时间。传统系统是确定性的。
AI 现实：又错了。有人问，“为什么我被收费两次？”根据 AI 代理在那一刻的决定，您会得到截然不同的性能。如果您跟踪成千上万个相同的查询，您可能会发现，例如：
- 22% 的情况下：响应时间低于一秒（代理模式匹配到 FAQ，很容易解决）
- 54% 的情况下：1 到 3 秒（需要检索订单历史，进行一些分析）
- 19% 的情况下：3 到 7 秒（陷入了复杂的推理过程，涉及多个数据源）
- 5% 的情况下：7 到 15 秒（代理决定需要“高级推理处理”，涉及工具链）
完全相同的问题。响应时间差异高达十五倍。您的 p99 延迟服务级别目标 (SLO)？基本上取决于代理当天的心情。
假设 3：测试流量代表生产流量
传统思维：模拟真实的请求模式，就能找到瓶颈。
AI 现实：瓶颈源于对话动态，这些动态不可能完全模拟。
典型的负载测试脚本：
loop:
query = random_question_from_list()
response = agent.ask(query)
sleep(random(1,5))
生产现实：
- 用户：“查询我的订单”
- 代理：[提供跟踪信息。]
- 用户：“什么时候能到？”
- 代理：[计算预计送达时间，考虑天气、节假日。]
- 用户：“我可以更改收货地址吗？”
- 代理：[检查订单状态，检索地址验证 API，计算费用。]
- 用户：“如果我不在家呢？”
- 代理：[查询配送选项、过去的配送偏好，生成替代方案。]
四次交流，每次都基于之前的上下文，每次都触发不同的代码路径，每次都消耗更多资源。传统负载测试从未模拟过这一点。
实际导致 AI 代理系统崩溃的原因
当您分析多个行业中多个 AI 代理部署的生产事件时，会出现一些清晰的模式，而这些模式是传统负载测试从未捕捉到的：
模式 1：上下文雪崩
用户对话不会干净利落地结束；它们会分支、迂回，并最终讨论与开始时完全不同的内容。
一个帮助台代理在与用户进行 12 次往返后，其上下文窗口容量就达到了 90%。当第 13 条消息进来时，系统“进入循环”并触发紧急上下文压缩。压缩？需要 4.2 秒。用户认为系统冻结了，刷新页面，开始了一个新会话。原来的会话现在只是挂在那里，孤立无援，仍在消耗资源。
现在，将这种情况乘以多个并发进行的对话。系统开始“挣扎”——不是因为请求量，而是因为它拼命地试图管理上下文窗口，在空中 juggling 太多球而导致上下文管理混乱。
负载测试从未捕捉到这一点，因为它们从未模拟过对话深度分布。它们只是命中端点。没有人想到测试“当 15% 的用户进行马拉松式的 20 条消息对话时会发生什么？”
模式 2：推理螺旋
某些查询会触发递归思考。代理会自我质疑，探索替代方案，回溯，重试。
示例：用户问：“考虑到我的使用模式和预算，最经济高效的解决方案是什么？”代理触发了：
- 使用情况分析（三次 API 调用）
- 七种计划选项的成本计算
- 预算限制评估
- 权衡分析（这导致了六个推理步骤）
- 推荐生成
- 置信度评分（重新评估替代方案）
总计：22 秒，8,400 个 Token，单个请求花费 0.168 美元。
负载测试遗漏了什么：查询复杂性分布 在真实用户意图下。
模式 3：多模态内存炸弹
用户上传图像、文档和截图。每个都会保留在对话上下文中。
示例：一个支持聊天允许上传图像进行故障排除。用户在八条消息中上传了四张截图。到第九条消息时，上下文包含了：
- 九对文本消息（4,200 个 Token）
- 四张图片（视觉编码后有效为 16,800 个 Token）
- 总上下文：21,000 个 Token
代理响应时间从 1.2 秒下降到 8.7 秒。Token 成本飙升九倍。每个对话的内存消耗增加了 370MB。
负载测试遗漏了什么：对话生命周期中的多模态上下文累积。
模式 4：工具链级联
带有工具（API 调用、数据库查询和网络搜索）的代理会触发不可预测的链式反应。
示例：用户问：“将我的账户活动与行业基准进行比较。”
代理的推理路径：
- 获取用户账户数据（SQL 查询）
- 识别相关行业基准（网络搜索）
- 检索基准数据（外部 API）
- 数据格式不匹配 — 触发数据转换
- 使用不同参数重试外部 API
- 聚合和比较（计算）
- 生成可视化（图像生成 API）
- 总结发现
八次工具调用，三次重试，总共 27 秒，涉及多个外部依赖。步骤 5 的失败导致了重试循环。
负载测试遗漏了什么：真实世界查询下的工具编排复杂性。
测试实际重要内容的 H2
策略 1：对话模式模拟
围绕对话原型构建负载测试，而不是单个请求。
定义对话模式：
- 快速解决者：一到三条消息，简单查询，命中 FAQ
- 标准支持：四到八条消息，中等上下文，两到三个工具调用
- 复杂调查：九到十五条消息，深度上下文，五个以上工具调用
- 马拉松会话：十五条以上消息，触发上下文管理，多模态
负载测试组成：
- 40% 快速解决者
- 35% 标准支持
- 20% 复杂调查
- 5% 马拉松会话
模拟真实的对话流程，而不仅仅是端点命中。
策略 2：认知负荷分析
衡量打破系统的因素——认知负荷，而不仅仅是请求量。
测试期间跟踪：
- 每个对话消耗的 Token（而不是每个请求）
- 上下文窗口利用率随时间的变化
- 工具调用链和深度
- 推理步骤计数
- 模型切换频率（从快到慢的模型）
要找到的瓶颈：
- Token 预算耗尽
- 上下文窗口饱和
- 工具调用速率限制
- 推理超时阈值
- 成本失控情况
策略 3：对抗性输入测试
生产用户提出的问题是测试脚本从未想象过的。
对抗性测试类别：
- 模糊性炸弹：含糊不清的问题，迫使进行大量推理。
- “似乎有什么不对劲。”
- “你能帮我处理那件事吗？”
- 上下文爆炸器：需要大量历史上下文的问题。
- “总结一下我们讨论过的关于 [主题] 的所有内容。”
- “这与你上周提出的建议相比如何？”
- 工具链触发器：跨多个系统级联的查询。
- “找到满足这七个标准的最低成本选项。”
- “分析我的账户趋势并提出优化建议。”
- 多模态复杂性：混合内容类型，需要不同处理。
- 单一查询中的文本+图像+文档。
- 引用早期图像的后续问题。
策略 4：认知混沌工程
基础设施混沌工程：杀死 Pod，注入延迟，饱和资源。
AI 混沌工程：破坏认知能力。
要进行的实验：
- Token 预算限流：人为减少可用 Token 并观察降级情况。
- 上下文窗口压力测试：强制对话超过典型长度。
- 工具故障注入：使随机工具调用失败，观察重试行为。
- 模型降级场景：在对话中途切换到更便宜的模型。
- 推理延迟注入：减慢 大型语言模型 (LLM) 的响应速度，测试超时处理。
实际预测失败的指标
传统：每秒请求数、延迟百分位数、错误率、吞吐量。
AI 代理系统需要：
-
对话健康指标
- 平均对话深度（每会话消息数）
- 上下文利用率曲线（对话过程中的 Token 消耗）
- 对话放弃率（用户放弃）
- 上下文压缩频率（系统空间不足）
-
认知负荷指标
- Token 燃烧率（所有对话的 Token/秒）
- 推理深度分布（简单/中等/复杂查询比例）
- 工具调用率和链深度
- 模型升级频率（从廉价到昂贵的模型切换）
-
经济指标
- 每次对话成本（不是每次请求）
- Token 浪费率（在失败操作上消耗的 Token）
- 成本异常检测（意外昂贵的对话）
-
质量指标
- 响应相关性下降（随对话深度增加）
- 工具成功率（API 调用是否提供了有用数据？）
- 上下文连贯性得分（代理是否还记得之前的讨论？）
- 人工接管率（需要人工干预的代理故障）
真实世界测试框架
以下是组织在生产环境中发现有效的实践：
第一阶段：基线现实
- 部署到 5% 的生产流量。
- 记录所有内容：Token、延迟、工具、上下文、成本。
- 构建实际行为的分布模型。
- 确定您真实的对话模式。
第二阶段：合成现实主义
- 生成与真实分布匹配的合成对话。
- 包含对抗性案例（占负载的 2-5%）。
- 模拟对话生命周期（不仅仅是请求）。
- 测试 Token 预算限制、上下文饱和、工具故障。
第三阶段：持续验证
- 部署前运行生产级别的测试。
- 与基线模型进行比较。
- 对分布变化（如 Token 消耗增加 40%）发出警报。
- 进行金丝雀部署并监控认知负荷。
令人不安的结论
传统的负载测试是为已经不复存在的世界设计的。它假设是无状态 API、确定性行为和位于您基础设施中的性能瓶颈。
AI 代理打破了整个规则手册。
它们是有状态的（对话会累积上下文）。它们是非确定性的（相同的查询，每次性能都不同）。它们受限于 Token 等认知资源，而不仅仅是 CPU 和内存。它们以不可预测的方式编排工具。并且它们迫使您在质量、成本和速度之间取得平衡，这会让人头疼。
您的负载测试通过是因为它们测试的是关于系统如何工作的错误心智模型。
它们证明了您的基础设施可以处理每秒 10,000 个请求。但生产环境在 300 名并发用户时就崩溃了，因为这些用户正在进行复杂、分支的对话，而您的测试从未尝试模拟过。
这是一个令人不安的事实：性能工程社区花费了数十年的时间来完善负载测试。我们在这方面做得非常好，现在我们需要承认，对于 AI 代理，我们的大部分专业知识都无法转移。我们基本上是从零开始。
传统指标仍然很重要，但它们已不足够。您需要测试对话模式、认知负荷、Token 消耗曲线、上下文窗口动态。所有这些使 AI 代理根本不同的东西。
问题不在于“您的负载测试是否足够复杂？”而在于“您是在测试现实，还是在测试一个与用户实际如何与您的 AI 互动毫无关系的模拟？”
您的 AI 代理注定会在生产环境中失败。这几乎是肯定的。真正的问题是：您会理解原因，还是会盯着所有指标都显示绿色的仪表板，而用户却在愤怒地退出？
怎么做
- 审计当前测试：有多少比例模拟了真实的对话流程，有多少是孤立请求？
- 注入认知负荷：在监控中加入 Token 消耗、上下文利用率和推理深度。
- 定义对话模式：将真实用户行为映射到对话原型。
- 构建了解对话的测试：模拟会话，而不是请求。
- 设置认知负荷 SLO：不仅仅是延迟——每次交互的 Token 消耗、上下文利用率、成本。
负载测试的未来不在于更复杂的请求生成器。它在于与生产现实相匹配的认知负荷模拟。
