智能体压测的难点，不是把模型请求并发数调高，而是复现一次真实任务从接收请求到最终动作的完整闭环。典型链路包含任务拆解、模型推理、工具选择、参数校验、网络调用、检索或数据库访问、结果解析、上下文拼接、再次推理，以及异常处理和结果回写。只压测单轮模型推理，得到的往往只是GPU吞吐，无法说明系统能否稳定完成业务任务。
先建立任务链路模型
压测前应把业务任务拆成可观测阶段，并明确每个阶段的串并行关系。需要记录首轮推理、工具选择、网络往返、工具执行、数据检索、结果解析、后续推理，以及重试和超时处理分别耗时多少。
尤其要区分串行调用与并行调用。多个工具串行执行时，任一环节的延迟都会累积到最终响应；并行调用虽然能够缩短部分耗时，却可能增加CPU调度、连接管理、内存访问和结果合并压力。压测模型必须保留这种真实依赖，不能把所有步骤简单并发化。
压力模型要接近真实任务
有效的压测流量不应只有“请求数量”，还应包含任务复杂度：单次任务包含多少轮模型推理、调用多少工具、上下文如何增长、检索结果规模如何变化，以及异常和重试出现时链路如何继续。
测试数据也应覆盖短任务、长上下文、工具调用较少和调用较多等类型。否则，平均延迟可能很好看，但一旦进入多轮推理或大规模知识库访问，内存带宽、缓存、网络和存储就可能成为瓶颈。
结果不能只看平均值
评估指标至少应覆盖完整任务耗时、有效任务吞吐、失败与重试比例，以及高并发下的P50、P95和P99延迟。更重要的是建立端到端耗时与资源指标的对应关系：若模型推理只占总耗时的一小部分，继续增加GPU未必有效；若CPU调度、数据复制或工具执行占主导，优化编排、连接管理、索引和上下文大小可能更有价值。
一次合格的智能体压测，最终应回答一个采购和架构都关心的问题：系统变慢时，究竟是模型算力不足，还是调度、数据搬运、外部工具和尾延迟拖慢了整个闭环。只有复现真实链路，压测结果才具备决策意义。