几乎每个团队都经历过这一幕：Agent 在内测环境跑得好好的，一上线就被用户按在地上。不是功能坏了，是没人说得清它到底能扛多少并发。业务方问「能支持多少人同时用」，只能回一句「应该没问题吧」。
这个回答之所以说不出口，是因为 Agent 和普通接口压根不是一回事。普通接口的压测逻辑很成熟——固定请求、看 QPS 和响应时间、找拐点、留余量。Agent 有三处不一样：一次请求特别慢（几十秒到几分钟，因为中间串了多次模型调用和工具调用）、每次请求的价格差很大（取决于 token 用量，而 token 用量取决于任务复杂度）、上游不是你能控制的（模型服务的限流、排队和突发抖动都会传导到你这里）。
压测这件事在站内还是空白。已经写过的是上线之后怎么看着它跑（服务器资源与服务监控、生产监控指标怎么设），以及跑起来之后怎么拦住失控（限流与配额、异常分级与熔断）。这篇管的是更早的那一步：上线之前，怎么用一次压测换回一句敢写进文档的容量结论。
一、先认清三处不一样，否则指标就选错了
第一，慢，而且慢得不均匀。同一个接口，简单的问答两秒返回，复杂的任务要跑两分钟。用「平均响应时间」描述它没有意义——平均值会被大量的短任务拉低，而你真正会崩的时候是长任务堆积。所以 Agent 的延迟必须看分位数，而且要看两个：首字延迟和端到端完成时间。
第二，贵，而且贵得随负载涨。传统压测压到系统崩为止，成本是固定的（机器钱）。Agent 压测压到崩之前，你的账单已经在涨了：每多跑一轮就多花一轮 token 钱。所以压测必须先设预算上限，这不是小心，是硬性前置条件。
第三，上游的瓶颈会伪装成你的瓶颈。你去打模型服务，打到某个并发之后延迟飙升，很可能不是你的代码有问题，而是上游开始限流了（通常会返回 429 或让请求排队）。这时候得出结论「我们只能撑 10 并发」是错的——你测到的是上游配额，不是你的容量。这一点和站内 工具调用失败怎么排查 里的分层定位法是一个思路：先分清失败发生在哪一层，再谈结论。
二、压测前先定三件事，不定就别开跑
1. 目标场景要说清楚是哪种负载。Agent 的负载至少有三类，压测方法完全不同：交互式（人等着看结果，几十秒内要出首字，关心 P95）、批处理（一次提交一批任务，不关心单条多快，关心总时长和单位成本）、定时任务（每天固定时刻同时启动一批，关心的是短时间内的并发峰值有没有超出配额）。拿交互式的指标去评批处理场景，结论一定是废的。
2. 成功标准要先写下来。建议写三条，缺一条都算没通过：P95 端到端完成时间不超过 X 秒、任务成功率不低于 Y%（把超时、工具报错、模型拒答都算失败）、单任务平均成本不超过 Z 元。第三条最容易被忽略，但它决定的是「能不能长期开着」。
3. 样本要真实。这是压测里最省事也最致命的偷懒。用「你好，介绍一下自己」压出来的数据会好看到毫无意义——它跳过了检索、跳过了一长串工具调用、跳过了最吃 token 的环节。正确做法是从真实历史任务里采样：短任务、中等任务、长任务各占一定比例，再放几个已知最复杂的极端样本进去当压力点。压测集的组成建议直接写进脚本注释里，否则三个月后没人记得测的是什么。
三、四个必测指标，外加一个系统指标
下面五个数字，缺一个你的容量结论就不完整：
- 首字延迟（TTFT）：从发请求到第一个 token 返回的时间。它决定用户「觉得快不快」。流式输出下这个指标尤其重要，具体机制可参考站内 AI Agent 流式输出怎么做。
- 输出速度（token/秒）：首字之后每秒能吐多少。它决定用户「觉得顺不顺」。注意它受你选的模型档位影响极大，压测结论要绑定模型版本。
- 端到端完成时间：从发请求到任务真正结束。这是最会暴露问题的一个——如果首字很快但完成时间很长，说明瓶颈在工具调用或后端处理，不在模型。
- 单任务成本：token 用量 × 单价，按上面三类样本分别算。这个数字和负载强相关（并发高时重试变多、上下文变长），必须在压测里实测，不能拿单次调用的账单去乘。成本口径的完整算法可参考站内 AI Agent 成本怎么算、怎么省。
- 系统侧：可支撑并发与排队时长。同一时刻有多少任务在跑、超出的部分排了多久、排到多长时开始有人放弃。这一条是把技术指标翻译成业务语言的桥梁。
四、五步跑完一轮压测
第一步：从 1 并发开始，按梯度往上加
不要一上来就打峰值。按 1 → 3 → 5 → 10 → 20 这样的梯度走，每一档跑够样本量再进下一档（样本太少时分位数没有意义，至少几十条起步）。每档之间留出冷却时间，别让上一档的残留任务污染下一档。
第二步：盯拐点，而不是盯绝对值
把每一档的 P95 完成时间和成功率画成两条线。健康的形状是：前几档几乎平，到某一档之后开始明显上翘。开始上翘的那个点就是你的实用上限——不是最好看的那个数字，是第一个变坏的数字。有一条经验判断很实用：从某一档到下一档，P95 涨了 50% 以上而吞吐只涨了不到 20%，说明已经过拐点了。
第三步：区分「冷测」和「热测」
有缓存的情况下，第二次跑同一批任务会明显更快更便宜（提示词缓存和结果缓存都在起作用，机制见 AI Agent 缓存怎么用）。所以至少要跑两轮：冷启动轮（清空缓存，代表真实新场景）和热负载轮（缓存生效，代表线上稳态）。两个数字都要报出来。只报热负载的数据，等于把上线第一天最惨的情况藏起来了。
第四步：定位瓶颈到底在哪一层
看到延迟上翘之后，先别改代码，先定位。按这个顺序问四个问题：是上游在限流吗（看有没有 429 和排队时长）、是工具调用串行吗（看一个任务里有多少次工具往返，能不能并行）、是上下文越滚越长吗（看后面几轮任务的输入 token 是不是明显比前面大，思路见 上下文管理怎么做）、是重试在放大负载吗（一次失败触发重试，等于自己给自己加压 100%）。
第五步：把结论写成一句能执行的话
压测报告最没用的写法是给一堆图表，最有用的写法是给一句结论加一套预案。推荐的格式是：「在模型 A、任务结构 B、P95 完成时间不超过 C 秒的前提下，可稳定支撑 N 个并发任务；超过 N 时按下列顺序降级」。降级阶梯通常有四档，顺序建议是：排队缓冲 → 降档到更便宜的模型 → 拆任务分批跑 → 明确拒绝并给用户提示。这四档的取舍逻辑和 异常分级 是同一套思路：分级的目的是把有限资源优先给最重要的那部分请求。
五、五个坑，踩一个结论就不可信
坑一：没设预算上限就开压。Agent 压测是「一边测一边烧钱」。开跑前先算一笔账：单任务成本 × 计划任务数 = 这轮预算，脚本里写死上限并在达到时熔断。
坑二：把重试算成成功。一个任务重试三次才成功，在成功率统计里应该记为「成功但成本三倍」，不能只记成功。否则你会得出一个既不真实也不可持续的结论。
坑三：用 mock 工具替掉真实工具。mock 会让延迟凭空变短，测出来的容量虚高。真要 mock 也应该给 mock 加上接近真实的延迟分布，并且明确标注这份数据不能用于对外承诺。
坑四：只测一次就写进文档。模型服务是会变的，上游配额也会变。压测结论必须带上日期和模型版本，并且约定复查周期（比如每次换模型、每次大改工具链之后重跑）。
坑五：拿压测数据当 SLA 承诺。压测给的是「当前配置下的经验上限」，不是合同条款。对外承诺要留余量，通常按实测拐点的一半到七成写比较稳。
六、优缺点和适合人群
它能给你什么：一句敢写进文档的容量结论；知道瓶颈在哪一层，改起来不猜；把「单任务成本」变成一个可管理的数字，而不是月底看账单才知道；以及一套过载时的降级顺序，出事时不至于临时拍脑袋。
它的局限：成本不低（每轮都在烧 token 和时间）；模型服务本身会变，结论有保质期；离线压测无法完全复现真实用户的行为分布（用户会以你想不到的方式用）；上游限流这件事你测不准，只能问或观察。
适合谁：准备把 Agent 从内测推到真实用户面前的团队；已经上线但经常被流量打崩、想搞清楚上限的团队；以及要给业务方一个交付物、需要拿数字说话的负责人。
不适合谁：还在验证「这个功能到底有没有人用」的阶段——这时候最该做的是省钱的原型验证，不是压测；以及完全是内部小范围使用、并发从来不超过个位数的场景，为它建流程是浪费。
总结
- 为什么不一样：Agent 慢（几十秒级）、贵（按 token 花）、有上游（限流会伪装成你的瓶颈）——所以不能套用 QPS 那一套。
- 三件前置：定场景（交互式 / 批处理 / 定时）、定成功标准（P95 时间 + 成功率 + 单任务成本）、用真实任务采样而不是寒暄语。
- 五个指标：首字延迟、输出速度、端到端完成时间、单任务成本、可支撑并发与排队时长。
- 五步流程：梯度加压 → 找拐点 → 冷热各测一轮 → 定位瓶颈在哪层 → 写成「能撑 N 并发 + 四档降级」的结论。
- 底线：没设预算上限、把重试算成功、用 mock 工具、只测一次、拿压测当 SLA——踩中任意一条，这份报告就不能信。
最后一句：压测的价值不在于得到一个漂亮的数字，而在于知道第一个出问题的地方在哪。知道上限在哪、知道超了怎么退，比「应该没问题」让人睡得着。
