1. 项目概述：当AI Agent遭遇流量洪峰

最近和几个做AI应用的朋友聊天，发现一个挺普遍的现象：大家辛辛苦苦开发出来的AI Agent，在内部测试、小范围演示时都跑得挺欢，界面炫酷，响应也快。可一旦放到线上，用户量稍微一上来，或者搞个营销活动引点流，系统立马就“趴窝”了——响应超时、错误率飙升，甚至直接宕机。这感觉就像精心打造了一辆跑车，平时在自家车库门口开开没问题，真上了高速公路，没跑几公里就爆缸了。

这背后的核心问题，往往不是AI模型本身不够聪明，而是我们构建的AI Agent服务架构，在应对高并发、大流量的冲击时，存在设计缺陷或性能瓶颈。一个AI Agent，从接收用户请求到返回最终结果，中间可能涉及意图识别、工具调用、大模型推理、上下文管理、外部API集成等多个环节。任何一个环节成为短板，都可能让整个系统在流量洪峰面前溃不成军。

今天，我们不谈空洞的理论，直接结合我过去参与或深度复盘过的五个真实压测案例，来拆解那些导致AI Agent“扛不住”的典型陷阱。这些案例覆盖了从简单的问答机器人到复杂的多步骤工作流Agent，我们将用JMeter、Locust等压测工具的数据说话，看看问题到底出在哪里，以及我们是如何定位和解决的。无论你是刚开始接触AI Agent开发的工程师，还是正在为线上服务的稳定性头疼的架构师，相信这些来自一线的“踩坑”经验，都能给你带来实实在在的启发。

2. 压测基础与AI Agent特性

在深入案例之前，我们有必要统一一下认知：什么是有效的压测，以及AI Agent服务压测的特殊性在哪里。很多团队对压测的理解还停留在“用工具发一堆请求看看会不会挂”的层面，这远远不够。

2.1 压测的核心目标与关键指标

压测不是为了把系统打挂，而是为了摸清系统的能力边界，发现瓶颈，为容量规划和架构优化提供数据支撑。对于AI Agent这类服务，我们需要重点关注以下几类指标：

1. 吞吐量与响应时间（Throughput & Response Time）：这是最直观的指标。吞吐量指系统单位时间（如每秒）能成功处理的请求数（QPS）。响应时间则包括平均响应时间、P90/P95/P99分位响应时间。对于AI交互，P99响应时间尤为重要，因为它反映了绝大多数用户的体验，一次长达10秒的等待就足以让用户失去耐心。
2. 错误率（Error Rate）：在高压下，服务返回非200状态码（如500、502、504）或业务逻辑错误的比例。一个健康的系统，错误率在峰值流量下也应保持在极低水平（如<0.1%）。
3. 资源利用率（Resource Utilization）：包括CPU使用率、内存占用、磁盘I/O、网络I/O，以及对于AI服务至关重要的GPU显存利用率和计算单元占用率。瓶颈往往首先体现在资源饱和上。
4. 并发用户/连接数（Concurrent Users/Connections）：模拟真实用户同时在线发起请求的场景。需要注意，“并发”不等于“QPS”。一个用户可能在一个会话中连续发起多个请求（思考链），这模拟的是更真实的交互压力。

2.2 AI Agent服务的独特挑战

与传统Web服务相比，对AI Agent进行压测和优化，需要特别关注以下几点：

• 长尾延迟与不确定性：大模型推理时间波动很大，一次简单的分类可能只需100ms，而一次复杂的推理或代码生成可能需要5-10秒。压测脚本必须能模拟这种请求处理时间的差异，而不是简单的固定思考时间。
• 有状态性与上下文管理：很多Agent是会话式的，需要维护对话历史（上下文）。压测时需要模拟带Session的连续对话，这对服务器的内存（存储上下文）和上下文窗口的管理逻辑都是考验。
• 外部工具调用的链式反应：Agent的核心能力之一是调用外部工具（API、数据库查询、代码执行等）。一次用户请求可能触发多次工具调用，形成链式或树状结构。任何一个外部工具响应慢或失败，都会级联放大，导致整个Agent请求超时。压测时必须将这些依赖服务的响应模拟或隔离考虑进去。
• 令牌（Token）消耗与成本：高并发下，输入输出的令牌数会急剧增加，直接关联到云API成本或自部署模型的算力成本。压测时也需要观察令牌生成速率，作为成本评估和限流设计的依据。

理解了这些基础，我们就能带着更专业的眼光，去审视下面这些真实案例中暴露出的问题了。我们的压测工具主要使用JMeter和Locust，两者各有侧重：JMeter功能全面，组件丰富，适合复杂场景的编排；Locust基于Python代码编写压测逻辑，更加灵活，适合模拟复杂的AI交互流水线。

3. 案例一：被“慢速依赖”拖垮的客服助手

第一个案例来自一个电商客服AI助手项目。这个Agent的功能是理解用户关于订单、物流、售后的自然语言提问，然后通过调用内部多个业务API（订单查询、物流跟踪、工单系统）来获取信息，最后组织成友好文本回复给用户。

3.1 场景与压测配置

• Agent类型：工具调用型（Tool-Calling Agent）。
• 架构简述：用户请求先经过一个基于FastAPI的Agent网关，网关调用大模型（初期为云端GPT-4 API，后迁移为本地部署的DeepSeek）进行意图识别和工具参数提取，然后并发调用对应的内部RESTful API，汇总结果后再次调用大模型生成最终回复。
• 压测目标：验证在“双十一”级别流量下，客服入口的承载能力。
• 压测工具：JMeter。使用HTTP Request采样器模拟用户提问，JSON Extractor提取会话ID以实现对话连续性，Constant Throughput Timer控制吞吐量。

3.2 压测现象与瓶颈定位

我们逐步将吞吐量从50 QPS提升到200 QPS。在约120 QPS时，监控仪表盘开始报警：

1. 响应时间：平均响应时间从800ms陡增至5s以上，P99响应时间超过15s。
2. 错误率：HTTP 504（网关超时）错误率开始出现，并随着压力增大而升高至10%。
3. 资源监控：Agent网关服务器的CPU和内存使用率并不高（均<50%），但网络连接数很高。关键发现：后端某个“物流状态查询”的内部API，其平均响应时间从正常的200ms恶化到了2s，且该服务的CPU使用率达到95%。

我们使用JMeter的PerfMon插件监控了各服务器资源，并结合分布式链路追踪（如SkyWalking），清晰地看到：大部分超时的请求，时间都卡在调用“物流查询API”这一步。即使Agent网关设置了单个工具调用超时（如3s），但大量请求堆积在等待这个慢速API的响应上，耗尽了网关的HTTP连接池和工作线程，导致新请求无法被及时处理，引发连锁超时。

3.3 解决方案与架构优化

问题的根因是一个慢速的外部依赖，在高并发下成为了整个系统的瓶颈。我们采取了多管齐下的方案：

1. 依赖服务治理与扩容：这是根本。与物流系统团队协同，优化其数据库查询，增加缓存层（Redis缓存物流轨迹，TTL设置2分钟），并对该服务进行水平扩容。优化后，该API的P99响应时间稳定在300ms以内。
2. Agent网关异步化与超时控制：将Agent网关中工具调用的逻辑改为完全异步非阻塞。使用asyncio（Python）或异步HTTP客户端（如httpx），使得在等待某个工具响应时，当前工作线程可以释放去处理其他请求。同时，为每个工具调用设置严格的、短于全局超时的独立超时（如1.5s）。
3. 引入熔断与降级机制：为每个依赖服务配置熔断器（如使用resilience4j或tenacity库）。当物流查询API的错误率或延迟超过阈值时，熔断器打开，后续请求直接快速失败（返回“物流信息暂不可用，请稍后再试”的降级回复），而不再等待。这避免了单个故障点拖垮整个服务。熔断器会定期进入半开状态试探依赖是否恢复。
4. 连接池与线程池调优：合理配置HTTP客户端连接池大小和最大连接数，使其与后端服务的承载能力匹配。避免创建过多连接压垮依赖服务，也避免连接不足导致等待。

实操心得：对于工具调用型Agent，必须将每个外部依赖都视为潜在的“坏邻居”。在设计之初就要为它们配置独立的超时、熔断和降级策略。压测时，不仅要压Agent本身，更要模拟依赖服务出现延迟或故障时的场景，验证系统的韧性（Resilience）。

4. 案例二：上下文管理导致的内存泄漏

第二个案例是一个用于内部技术文档问答的AI Agent。它允许用户上传PDF/Word文档，然后进行基于文档内容的问答。Agent会利用嵌入模型（Embedding）将文档切片并向量化存储，用户提问时进行向量检索，并将检索到的片段作为上下文送给大模型生成答案。

4.1 场景与压测配置

• Agent类型：检索增强生成（RAG）型Agent。
• 架构简述：Flask后端。每个用户会话（Session）会在服务器内存中维护一个对话历史列表，用于实现多轮问答的连贯性。历史记录包括用户问题和AI答案，最多保留10轮。
• 压测目标：模拟多名技术员工同时进行多轮深度技术问答的场景。
• 压测工具：Locust。利用其编程灵活性，编写了模拟用户行为的TaskSet：用户登录->搜索文档->连续进行多轮问答->退出。

4.2 压测现象与瓶颈定位

压测开始时一切正常。但在持续运行约30分钟后，即使维持固定的并发用户数，系统的响应时间也开始缓慢增长，错误率攀升。监控发现：

1. 内存使用率：呈现只增不减的“斜坡式”上涨，直到触发服务器的内存上限（如95%），导致进程被OOM Killer终止或响应极其缓慢。
2. 垃圾回收（GC）：Python的GC活动异常频繁，但每次回收释放的内存很少，说明有大量对象无法被回收。
3. 线程堆栈分析：使用py-spy或memory-profiler等工具对进程进行堆内存快照分析，发现大量Session对象及其内部的对话历史列表没有被释放。

问题很明显：内存泄漏。根源在于会话（Session）管理逻辑。我们的实现是将Session对象存储在全局字典中，键是Session ID。理论上，用户“退出”或会话超时后，应该从字典中删除该Session。但压测脚本模拟的用户“退出”行为，只是停止了发送请求，并没有触发服务端的会话销毁逻辑。而服务端设置的会话过期时间较长（如2小时），且清理过期会话的定时任务（cron job）执行间隔太长或出现了故障，导致大量无用的Session对象常驻内存。

4.3 解决方案与优化实践

解决内存泄漏需要从对象生命周期管理入手：

1. 重构会话存储与清理机制：
   • 立即将会话存储从内存迁移到外部存储：如Redis。Redis自带TTL（过期时间）功能，设置合理的过期时间（如30分钟不活动则过期），内存管理由Redis负责，应用服务变得无状态，便于水平扩展。
   • 如果仍需内存存储：实现一个健壮的、带有最近最少使用（LRU）淘汰策略的缓存字典，并设置一个绝对的内存上限。同时，确保有一个高优先级的后台线程，定期扫描并清理长时间无活动的会话。
2. 优化上下文数据结构：检查存储在会话中的对话历史对象。我们最初存储了完整的问答文本，后来优化为只存储消息的元数据（如角色、内容哈希）和必要的Token计数，大文本内容本身也存入Redis。这显著减少了单个会话对象的内存占用。
3. 引入内存监控与告警：在监控系统中增加应用进程的堆内存使用趋势监控。设置两个告警阈值：一个是“持续增长告警”（如1小时内内存增长超过200MB且未回落），用于早期发现泄漏；另一个是“绝对阈值告警”（如内存使用率>80%），用于防止宕机。
4. 压测时强制验证内存稳定性：将内存泄漏测试作为压测的必选项。任何压测场景，都必须持续运行足够长的时间（至少1-2小时），并观察内存曲线是否在达到一个稳定值后保持平稳，或呈现正常的“锯齿状”（GC回收）波动，而非单边上涨。

注意事项：在AI Agent开发中，由于大模型交互和上下文管理会涉及大量文本数据的暂存，内存管理意识必须非常强。避免在内存中缓存过大的对象（如整个向量库），对于会话、缓存等，优先考虑使用Redis、Memcached等外部高性能缓存服务。自研内存管理模块时，务必进行严格的生命周期测试。

5. 案例三：大模型API限流与令牌消耗瓶颈

第三个案例是一个面向C端用户的创意写作AI Agent。它直接调用第三方大模型API（如OpenAI GPT-4、Anthropic Claude）来生成故事、诗歌等。在免费推广期间，用户量激增。

5.1 场景与压测配置

• Agent类型：纯大模型调用代理（LLM Proxy Agent）。
• 架构简述：Node.js后端作为中继，接收用户请求，添加一些系统提示词（Prompt）后，转发给第三方大模型API，然后将结果返回给用户。为了控制成本，对用户输入和模型输出进行了令牌数统计。
• 压测目标：评估在突发流量下，服务能否稳定运行，以及预测API调用成本。
• 压测工具：JMeter分布式压测。使用多台压力机，模拟来自不同地区用户的短文本和长文本生成请求。

5.2 压测现象与瓶颈定位

压测启动后，在QPS达到约150时，服务突然出现大量429（Too Many Requests）错误。降低压力后恢复，但一提高压力又复现。监控发现：

1. 错误日志：清晰显示来自第三方API的429状态码和rate_limit_exceeded的错误信息。
2. 令牌消耗速率：我们的监控面板显示，输入和输出令牌的消耗速率（Tokens per Minute, TPM）达到了一个非常高的水平，接近我们账户的套餐限制。
3. 响应时间：即使在非429错误期间，平均响应时间也因排队等待而增加。

瓶颈有两个层面：

1. 频率限流（Rate Limit）：第三方API对每分钟/每秒的请求次数（RPM）有严格限制。我们的突发流量超过了这个限制。
2. 令牌限流（Token Limit）：更隐蔽的是对每分钟消耗的令牌数（TPM）的限制。即使请求数没超，但如果大量用户请求生成长文本，总的TPM也可能超限。我们的压测脚本包含了生成长故事的需求，正好触发了这个限制。

5.3 解决方案与优化实践

面对无法控制的外部API限流，必须在自身服务层做好精细化的流量整形和队列管理。

1. 实现客户端速率限制（Client-Side Rate Limiting）：
   • 在调用第三方API的客户端代码中，实现一个令牌桶（Token Bucket）或漏桶（Leaky Bucket）算法。根据购买的API套餐（如10,000 TPM， 500 RPM），在应用层设置一个稍低于官方限制的阈值（如9,000 TPM， 450 RPM），作为安全缓冲。
   • 所有对外部API的请求都必须通过这个限流器。如果桶内令牌不足，请求不是立即失败，而是进入一个优先级队列等待，直到有可用令牌。这可以将突发的429错误转化为响应时间的增加，保证服务的可用性。
2. 请求批处理与优化：对于某些非实时性要求极高的场景，可以考虑将短时间内多个用户的同类请求（如“写一首关于春天的五言诗”）合并（Batch）成一个包含多个消息的请求发送给大模型API。这能有效减少请求次数（RPM），但需要处理API返回结果的拆分和对应。注意：这需要大模型API支持批处理功能。
3. 动态降级与模型切换：在监控到TPM即将用尽或响应时间过长时，可以动态地将一部分流量降级到更便宜、速率限制更高的模型（如从GPT-4降级到GPT-3.5-Turbo），或者切换到备用的其他厂商API，保证核心服务不中断。
4. 成本与用量监控预警：建立实时的令牌消耗监控和预测系统。不仅监控当前TPM/RPM，还根据历史趋势预测未来一小时的消耗量。当用量达到预设阈值的80%时，就发出预警，以便人工或自动介入调整限流策略。

实操心得：依赖第三方大模型API，就像在别人的公路上开车，必须严格遵守交通规则（限速限流）。客户端限流是必须品，而不是可选项。在设计之初，就要把限流、队列、降级作为架构的核心组件。压测时，要专门针对限流场景进行测试，验证你的限流算法和队列机制是否真的能平滑流量，避免雪崩。

6. 案例四：GPU推理服务并发能力不足

第四个案例是一个企业内部自研的代码生成Agent，使用开源大模型（如CodeLlama）在本地GPU服务器上部署。模型通过vLLM或TGI（Text Generation Inference）这类高性能推理服务框架提供API。

6.1 场景与压测配置

• Agent类型：自托管大模型驱动型Agent。
• 架构简述：Agent业务逻辑服务（Python）与模型推理服务（vLLM）分离部署。业务服务通过HTTP调用本机的vLLM API。vLLM配置了张量并行（Tensor Parallelism）以利用多卡。
• 压测目标：评估单台GPU服务器（如搭载2张A100）能支撑的最大并发代码生成请求。
• 压测工具：Locust，直接对vLLM的API端点以及整合后的Agent服务端点分别进行压测。

6.2 压测现象与瓶颈定位

压测vLLM API时，随着并发请求数增加，观察到：

1. 吞吐量曲线：在并发数较低时，QPS随并发数线性增长。但当并发数达到一个临界值（例如20）后，QPS增长停滞，甚至略有下降。
2. 响应时间：P50响应时间尚可，但P99响应时间急剧上升，出现明显的长尾效应。
3. GPU监控：使用nvidia-smi或gpustat观察，发现GPU利用率并未达到100%，但GPU内存利用率很高。vLLM的日志显示出现了“Cache miss”和“Swapping”相关的警告。

瓶颈在于vLLM的KV Cache（键值缓存）管理。为了加速自回归生成，vLLM会将计算好的注意力键值对缓存起来。每个并发请求都会占用一部分GPU显存作为其KV Cache。当并发请求数过多时，显存被占满。此时，vLLM不得不将部分请求的KV Cache交换到CPU内存，在需要时再换回GPU，这个过程（Swapping）会导致严重的延迟抖动，这就是P99响应时间恶化的根源。GPU计算单元（SM）因为等待数据而闲置，所以计算利用率不高。

6.3 解决方案与优化实践

优化自托管模型推理的并发能力，核心在于显存资源的精细化管理和推理参数的调优。

1. 调整vLLM/TGI配置参数：
   • max_num_seqs/max_batch_size：这是控制并发处理序列数的关键参数。它应该设置为一个值，使得所有并发序列的KV Cache总大小不超过GPU显存的安全阈值（需预留一部分给模型权重和激活值）。需要通过压测找到这个最佳值，而不是盲目设大。
   • gpu_memory_utilization：控制vLLM可使用的GPU显存比例。默认0.9（90%），在显存紧张时可以适当调低，但会影响最大序列长度。
   • block_size：KV Cache的分配单元。对于较短序列的对话场景，可以尝试调小block_size（如16），以减少内部碎片，容纳更多并发序列。
2. 启用PagedAttention与量化：确保使用的是支持PagedAttention的vLLM版本，它像操作系统管理内存一样管理KV Cache，能极大减少显存碎片。同时，考虑使用模型量化（如AWQ、GPTQ），将模型权重从FP16转换为INT4/INT8，可以显著减少模型本身的显存占用，从而腾出更多空间给KV Cache，支持更高并发。
3. 业务层请求队列与调度：在Agent业务服务层，实现一个智能请求队列。当vLLM服务返回“忙”的状态（如HTTP 503）或预测其处理时间过长时，将请求排队，并给用户返回“排队中”的提示，而不是让请求直接失败或无限等待。这可以提升用户体验和系统稳定性。
4. 水平扩展与负载均衡：当单机GPU的并发能力达到上限时，唯一的办法就是水平扩展。部署多个vLLM实例（可能分布在多台GPU服务器上），在Agent业务层通过负载均衡器（如Nginx）分发请求。对于状态性的长对话，需要保证同一会话的请求路由到同一个vLLM实例（会话保持）。

注意事项：GPU推理服务的并发能力，首先受限于显存，其次才是算力。在规划资源时，不能只看模型参数大小，必须根据目标并发数和平均序列长度，估算KV Cache的显存需求。压测时，要使用符合真实业务分布的请求长度（输入token数+输出token数）来测试，才能得到准确的容量规划数据。

7. 案例五：Agent工作流引擎中的阻塞陷阱

第五个案例是一个复杂的多Agent协作系统，用于自动化处理客户提交的申请表单。工作流包括：表单解析Agent -> 信息校验Agent -> 风险评估Agent -> 文档生成Agent，各个Agent之间通过消息队列（RabbitMQ）进行异步通信。

7.1 场景与压测配置

• Agent类型：工作流编排型（多Agent协作）。
• 架构简述：使用LangGraph或Prefect等框架编排工作流。每个Agent是一个独立的微服务。初始请求触发工作流后，生成一个全局任务ID，后续步骤通过消息传递。
• 压测目标：测试整个工作流管道从端到端的吞吐量和延迟。
• 压测工具：JMeter。模拟用户提交表单的请求，并监听消息队列中最终完成的消息，以计算端到端延迟。

7.2 压测现象与瓶颈定位

压测时，随着提交请求速率增加，系统出现以下问题：

1. 吞吐量天花板低：即使每个微服务资源利用率都不高，整体QPS也无法提升。
2. 端到端延迟不稳定：部分请求处理极快，部分请求却异常缓慢，延迟分布差异巨大。
3. 消息队列堆积：发现“信息校验Agent”的消费队列出现严重堆积，而其他Agent的队列几乎是空的。

通过分析工作流代码和日志，发现了瓶颈所在：“信息校验Agent”中有一段同步调用外部“身份证核验系统”的代码。这个外部调用平均响应时间有500ms，且是同步阻塞的。这意味着处理该任务的线程在等待期间什么也做不了。而该Agent的服务实例配置的线程池或工作进程数是有限的。当并发请求超过这个数目，新的工作项（消息）就只能排队等待，即使CPU很闲。这造成了线程池耗尽，形成了整个工作流管道中最细的“瓶颈”，拖慢了全局速度。

7.3 解决方案与架构优化

在异步架构中混入同步阻塞调用是致命伤。解决方案的核心是“将阻塞操作异步化”。

1. 重构阻塞调用为异步非阻塞：
   • 将“身份证核验”这类同步HTTP调用，改为使用异步HTTP客户端（如aiohttp,httpx）。
   • 如果外部系统只提供同步API，可以将其封装在一个单独的线程池中执行，避免阻塞主事件循环（对于Pythonasyncio）或工作线程。
2. 调整并发模型与资源配置：
   • 对于使用asyncio的Python服务，确保所有I/O操作都是异步的。增加事件循环的数量或使用uvloop加速。
   • 对于多进程/多线程模型的服务（如Java Spring），合理调大处理“信息校验”这类慢任务的线程池大小，但这不是根本办法，只是缓解。根本还是要去阻塞化。
3. 工作流设计模式优化：
   • 并行化：检查工作流步骤间是否有依赖关系。如果“信息校验”和“风险评估”可以并行执行，那么将它们设计为并行分支，可以缩短关键路径长度。
   • 超时与补偿：为工作流中的每个步骤设置合理的超时时间。如果“信息校验”步骤超时，可以触发一个补偿逻辑（如标记为“待人工复核”），并让工作流继续向下推进，而不是无限期卡住。
4. 引入背压（Backpressure）机制：当“信息校验Agent”的队列长度超过阈值时，可以在工作流入口处实施背压，例如暂时拒绝新的表单提交请求，返回“系统繁忙，请稍后再试”。这可以防止无效请求堆积，保护系统不崩溃。

实操心得：在微服务或工作流架构中，性能由最慢的同步阻塞点决定。设计时必须用“异步思维”审视每一个环节，特别是I/O操作（网络、数据库、磁盘）。压测多Agent系统时，要有全链路的追踪和监控，能快速定位到延迟贡献最大的那个服务和方法。消息队列的监控（队列长度、消费速率）是发现此类问题的“晴雨表”。

8. 总结：构建高韧性AI Agent的压测清单

回顾这五个案例，从外部依赖、内存管理、API限流、推理并发到工作流阻塞，每一个坑都足以让一个AI Agent在流量面前倒下。要让你的AI Agent真正扛住流量洪峰，不能只靠运气，必须进行系统性的设计和验证。

基于这些经验，我整理了一份AI Agent压测与韧性建设清单，供你在设计和评估自己的系统时参考：

1. 依赖治理：

   • [ ] 是否为每个外部API/工具调用设置了独立的、短于全局的超时时间？
   • [ ] 是否为核心依赖服务配置了熔断器（Circuit Breaker）？
   • [ ] 是否有清晰的服务降级方案（如缓存兜底、默认值返回、功能阉割）？
   • [ ] 压测时是否模拟过依赖服务延迟升高或完全失败的场景？

2. 资源与状态管理：

   • [ ] 会话（Session）等状态信息是否存储在外部缓存（如Redis）中，而非应用内存？
   • [ ] 如果必须在内存中缓存，是否有LRU淘汰机制和内存上限保护？
   • [ ] 是否有内存和GC的监控与告警，能及时发现泄漏趋势？
   • [ ] 压测是否包含长时间稳定性测试（如2小时以上），观察内存曲线是否平稳？

3. 流量管控与成本：

   • [ ] 调用第三方大模型API时，是否实现了客户端速率限制（令牌桶/漏桶）？
   • [ ] 限流器前端是否有请求队列，能将突发错误转化为延迟增加？
   • [ ] 是否有实时监控令牌消耗速率（TPM/RPM）并设置预警？
   • [ ] 是否有模型降级或多厂商切换的容灾方案？

4. 推理服务优化：

   • [ ] 自托管模型是否使用vLLM/TGI等高性能推理框架并开启PagedAttention？
   • [ ] 是否根据GPU显存和业务并发需求，精细调优了max_num_seqs等参数？
   • [ ] 是否考虑过使用模型量化来提升单卡并发能力？
   • [ ] 业务层面对推理服务是否有请求队列和优雅降级机制？

5. 架构与并发模式：

   • [ ] 整个服务链路中是否消除了同步阻塞调用（特别是I/O）？
   • [ ] 工作流中可并行的步骤是否已并行化？
   • [ ] 是否有全链路追踪，能快速定位性能瓶颈？
   • [ ] 消息队列的堆积情况是否纳入核心监控？

压测不是一次性的任务，而是一个持续的过程。随着业务增长、模型迭代、依赖变更，系统的瓶颈会动态转移。将压测作为CI/CD管道的一部分，定期自动执行，才能让你的AI Agent在真实的流量洪峰来临时，真正做到从容不迫。