平均每天一千次请求，可能都挤在早上半小时
试点阶段十名员工轮流使用，回答速度稳定，大家认为系统已经可以推广。正式上线后，销售晨会前批量生成客户摘要，运营同时整理日报，客服又在处理咨询，所有请求集中到同一时间，界面开始转圈。
日均数量看起来不高，峰值却可能超过模型、向量库或 CRM 接口的限制。一个节点变慢，后面的任务继续堆积，最终用户只看到“系统不稳定”，很难判断到底是哪一层出了问题。
容量估算要从业务节奏开始，不是只问模型每秒多少次
先统计哪些岗位使用、每人一次会触发多少模型与工具调用、任务集中在什么时段、单次最长多久。批量任务、长文件处理和多步骤 Agent 可能一次产生很多内部请求，不能只按用户点击次数计算。
月底结算、营销活动、周报和早晚交接通常是高峰。容量测试应重现这些真实节奏，并同时观察模型限流、数据库连接、文件处理、外部接口和通知系统，而不是只压一个聊天页面。
- 按业务高峰而不是日均量估算。
- 计算一次任务背后的模型与工具调用。
- 同时观察第三方接口、队列和数据库瓶颈。
任务要分优先级，不能让批量周报堵住客户现场
面向客户的实时回复、当天订单和内部批量整理不应排在同一队列。高优先级任务保留资源，低优先级任务可以延后、分批或在非高峰执行。系统要告诉用户预计等待，而不是所有任务都显示处理中。
还可以限制单个部门、账号或自动任务的并发，防止一段错误脚本占满资源。限流不是拒绝业务，而是保证重要流程在高峰时仍然可用。
降级方案要让员工知道还能怎么完成工作
模型不可用时，系统可以切换到简化流程、使用缓存资料、只做检索不做生成，或回到人工模板。外部接口变慢时则先保存草稿，等待恢复后再回写，避免用户重复提交造成多份记录。
降级必须经过演练。员工要知道什么时候等待、什么时候改走人工、谁负责恢复和怎样避免重复执行。只有技术文档里写了备用方案，现场人员不知道，真正故障时仍然会乱。
企业 AI 的上线标准应该包括忙的时候也能工作
演示成功证明功能方向可行，容量与异常测试才证明系统适合生产。企业不一定一开始就为极端规模投入大量资源，但要知道当前上限、扩容条件和超过上限后的行为。
把峰值、限流、排队和降级提前设计，能减少上线后的突然停摆，也让成本更可控。稳定不是永远不慢，而是在忙的时候仍能保护关键任务，并让用户知道接下来会发生什么。
要点总结
- 需要，规模不大也可能在固定时段集中使用，可采用与真实人数相符的轻量测试。
- 不是，还可能受知识库、数据库、文件处理、业务接口、网络和通知服务影响。
- 合理限流配合优先级、等待提示和分批执行，通常比所有任务一起卡住更可控。
参考来源说明
本文围绕“试用时十个人很顺，上线三百人就卡：企业 AI 要提前做峰值和限流设计”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。