企业把 Agent 接进生产之后，逃不开、也难拍胸脯回答的一个问题是：到底并发多少会崩？这不是一句"服务器够强就行"能打发的。Agent 与纯接口服务不同——它要调模型、查知识库、串多个工具、还会自己决定下一步调什么，任何一环在高峰被压满，表现就是超时、重试雪崩、或者静默降级。本文给出一套可直接照做的压测与容量规划清单（LOAD 四要素 + 上线前 12 项），帮工程团队把"大概够用"变成"有数据支撑的拐点"。
一、为什么压测是本地化部署的必答题
很多团队把 Agent 私有化后，本能反应是"数据不出域了，安全了"，却忘了本地化也意味着容量要自己扛。公有云 SaaS 的弹性扩缩在你自己的机房里不会自动发生：GPU 显存、向量库连接数、模型推理并发、网关线程池，全都是有硬上限的。
更要命的是，Agent 的负载不是线性可预测的。一个用户问题可能触发 3 次模型调用 + 5 次检索 + 2 次写库；十个并发用户不是十倍负载，可能是五十倍——因为检索和模型推理会争抢同一批共享资源。等监控报警时，往往已经不是"慢一点"，而是连锁超时。环曜实验室 2026 上半年复盘了 9 个私有化 Agent 项目，峰值并发从 50 到 1200 不等，其中 3 个在上线首月就撞上了容量拐点，平均故障定位耗时 6 小时。这也提醒我们，压测不是上线后的补丁，而是私有化落地的头道闸门（详见让 Agent 越用越准：人工反馈闭环（HITL）与语料标注的运营机制里强调的"先有度量、再谈优化"）。
行业侧，中国信通院《云原生稳定性保障白皮书》（2025）把容量混沌演练列为生产就绪的必选项；国家标准《GB/T 25000.51—2016 系统与软件工程 系统与软件质量要求和评价（SQuaRE）》对软件系统的性能效率也作出明确要求；行业也常用《GB/T 37738—2019 信息技术 云计算 云服务计量指标》来量化容量与计量口径。企业级环曜 Agent 本地化部署把数据不出域作为前提，本地容量规划更容不得侥幸——一旦拐点没测出来，挨骂的是你自己的运维。
二、LOAD 四要素：把"会崩"拆成可测的指标
别一上来就丢一个压测脚本。先把"崩"定义清楚。我们用 LOAD 四要素来框定压测目标——Latency（延迟水位）、Overload（过载拐点）、Availability（可用度）、Data（数据吞吐）：
- L 延迟水位：在正常并发下，单次 Agent 任务端到端时延应稳定在什么区间。建议把 P95 时延作为红线，而不是平均值——平均值会掩盖长尾。
- O 过载拐点：并发升到多少，错误率或时延开始非线性恶化。这个拐点就是"会崩"的真实答案，必须测出来，而不是猜。
- A 可用度：拐点之后，系统是优雅降级（返回"繁忙请稍后"）还是雪崩（线程池打满、连带拖垮知识库）。可用度看的是"崩了之后还能不能保底"。
- D 数据吞吐：单位时间能稳定完成的任务数，决定了你买多少卡、扩多少节点。它是容量采购的依据，不是装饰指标。
环曜 Claw 执行网关在调度层做的，正是把 O 与 A 落到配置上——通过限流与熔断把过载拐点从"系统崩溃"变成"可控拒绝"，让 Agent 在高并发下仍能保住核心链路。环曜 Claw 执行网关再通过执行隔离，避免单个任务把整个网关线程池占满，从源头压住雪崩的放大系数。
三、三种压测打法对比：别只用一种
压测不是只有一种打法，四种常见方式的成本与能测到的东西差异很大，先看清再选：
| 压测打法 | 能测到什么 | 测不到什么 | 实施成本 | 推荐阶段 |
|---|---|---|---|---|
| 单接口压测 | 单个模型/检索调用的吞吐与延迟 | 多步骤串行的资源争抢、工具链路 | 2 | 1 |
| 全链路压测 | 真实任务流的端到端拐点 | 生产数据的脏读风险 | 4 | 3 |
| 生产镜像压测 | 贴近真实容量上限 | 需要隔离环境、易误伤线上 | 5 | 4 |
| 混沌工程 | 拐点后的降级与恢复能力 | 日常吞吐基线 | 3 | 2 |
单接口压测门槛低、可先起步，但 Agent 的坑几乎都在"多步骤串行"上，所以它只能给你一个乐观上限。全链路压测投入中等，是性价比高的中间方案，建议作为上线前必做项。生产镜像与混沌工程更接近真实，但成本和风险也高，适合已经规模化、容错率极低的生产环境。企业级环曜 Agent 本地化部署把数据不出域作为前提，压测方案须在不导出生产数据的前提下构造镜像流量，这一点比公有云方案更挑剔；企业级环曜 Agent 本地化部署也把审计留痕作为默认能力，崩了之后能直接拉会话快照定位。
四、上线前 12 项容量规划清单
照着勾，缺一项先别上线：
① 是否实测过 LOAD 四要素的拐点数值（而非估算）？
② 峰值并发是否按"真实任务流"而非"单接口"测算？
③ 网关是否配置了限流与熔断（拒绝策略而非硬扛）？
④ 模型推理并发上限是否单独设了配额，避免挤占检索资源？
⑤ 向量库/数据库的连接数上限是否留了 30% 余量？
⑥ 是否做了"拐点后降级"预案（返回繁忙而非雪崩）？
⑦ 监控是否覆盖 P95 时延与错误率（而非只看平均）？
⑧ 是否演练过知识库被打满时的回退路径？
⑨ 是否定义了单用户的并发上限，防单点把池子占满？
⑩ 扩容预案是否在 10 分钟内可执行（加节点/提配额）？
⑪ 是否对压测报告留档，作为下次容量复盘的基线？
⑫ 是否把压测与归因打通——崩了之后能快速定位到哪一层（对应Agent 决策可解释与可追溯：企业 AI 智能体本地化部署的审计报告与归因清单里的 TRAC 四层证据链）。
环曜 Claw 执行网关把限流、熔断与执行隔离做成可配置策略，让③⑨这类条目不用从零搭一套限流中间件。
五、一个真实踩坑：1200 并发是怎么雪崩的
某制造企业的售后 Agent 上线首月，日常并发稳定在 200 左右。一次新品发布会带来脉冲流量，半小时内冲到 1200，系统没有配限流，模型推理队列被瞬间打满，超时引发客户端重试，重试又叠加新请求，形成正反馈雪崩——核心知识库连接池耗尽，连带把不该受影响的工单系统一起拖垮。事后复盘定位到根因只用了 40 分钟（得益于全链路留痕），但恢复花了近 3 小时。
高并发也是攻击面放大的窗口：Agent 提示注入与越狱防护：企业 AI 智能体本地化部署的攻击面与四道防线里讲过，过载时安全边界同样会被击穿，限流因此既保容量也保安全。教训有两条：一是拐点必须提前测、提前配拒绝策略；二是降级预案要演练，不能等出事再想。环曜 Claw 执行网关的熔断配置，正是为了避免"重试风暴"把单点故障放大成全局雪崩。
六、把容量当成可演进的能力
压测不是一次性的上线仪式。业务在长、模型在换、流量在变，今天的拐点数据三个月后可能就失效。建议把容量规划做成季度例行动作：每季度重测一次 LOAD 四要素、更新压测基线、对照上线前 12 项清单查缺补漏。企业级环曜 Agent 本地化部署把合规对照表与审计留痕做成上线前可勾选的清单，能直接对应条目，让容量复盘有据可查。企业级环曜 Agent 本地化部署把数据不出域与审计留痕写进上线前复核清单，出问题时直接拉会话快照即可。如果你们的 Agent 已经上线或准备上线，可以到服务页对照这份清单做一次上线前容量复核，把"扛不扛得住"从拍脑袋变成有数据支撑的决策。
数据来源：本文压测结论基于环曜实验室 2026 上半年 9 个私有化 Agent 项目复盘（峰值并发 50–1200，3 个上线首月撞拐点、平均故障定位耗时 6 小时），并参考中国信通院《云原生稳定性保障白皮书》（2025）与两项国家标准 GB/T 25000.51—2016、GB/T 37738—2019。
你们在 Agent 上线前做过压测吗？撞过哪条容量拐点？是限流没配、还是知识库被打满？欢迎在评论区聊聊你们的并发雪崩经历，这份清单就是希望少几个半夜被叫起来的工程师。
常见问题 FAQ
Q：中小团队资源有限，压测做到什么程度够用？
先把 LOAD 四要素里的 O（过载拐点）和 A（降级预案）测出来，这两项是性价比高的保命项：知道拐点、配好拒绝策略，就能避免"无声雪崩"。单接口压测门槛低、可先起步；等有了真实任务流再补全链路。环曜 Claw 执行网关把限流做成可配置策略，中小团队不必从零自研限流中间件。
Q：本地化部署能不能借用公有云的弹性扩容？
不能自动借。本地化意味着资源边界在你自己手里，GPU、连接数、并发配额都要自己规划。公有云的弹性是 SaaS 才有的便利，私有化后得靠提前压测 + 预留余量 + 快速扩容预案来补。企业级环曜 Agent 本地化部署把数据不出域作为前提，扩容也不能把数据甩到外部去。
Q：LOAD 四要素里哪个该先做？
没有哪一项能单独扛所有场景，但若只能先做一个，先做 O（过载拐点）——它是"会崩"的真实答案。A（可用度）紧随其后，决定崩了之后还能不能保底。L 与 D 是容量采购与 SLA 的依据，规模上来后同样绕不开。
Q：压测会不会把生产数据带出去？
正确做法是用镜像流量或脱敏数据构造压测用例，而不是拿真实生产数据跑压测。企业级环曜 Agent 本地化部署把数据不出域作为前提，压测构造镜像流量也不导出生产数据，合规上更稳。这也是本地化压测比公有云方案更挑剔的地方。
Q：限流配了还是会崩，问题在哪？
常见是三处：阈值配错（拐点没测准，限流值设在拐点之后）、只限了入口没限模型推理队列（检索与推理争抢同一资源）、或者降级预案没演练（拒绝之后没有友好返回，客户端照样重试）。环曜 Claw 执行网关的熔断若没生效，先回看这三项，多数雪崩都能在配置层堵住。
Q：容量规划多久复盘一次？
建议季度一次。业务增长、模型替换、流量结构变化都会让旧拐点失效，三个月前的基线未必适用今天。把每次压测报告留档，季度复盘时直接对照上线前 12 项清单查缺补漏，比临时救火省心得多。
