试用期二十来个人用，回答又快又准；正式推广后，早上一上班一堆人同时提问，智能体开始转圈，页面弹超时，业务方一句「昨天还好好的」，问题就落到了技术这边。

多数情况下，这不是模型突然变慢，而是试用期验证的是「能跑通」，高峰考验的是「扛得住并发」，两件事的验收口径根本不同。本文把并发崩溃拆成 5 个可逐个验证的断点，并给出有先后顺序的排查动作。

一、「能跑通」和「扛得住并发」，差的到底是什么？

「能跑通」验证的是单次请求在理想状态下能不能走完整条链路；「扛得住并发」验证的是峰值请求量、长尾请求和外部依赖波动同时出现时，整体还能不能保持可接受的响应时间与成功率。

- 前者靠功能验收：问一句，答出来，就算通过。

- 后者靠容量与限流设计：谁可以等、谁必须快、超时之后怎么办，都要提前写清楚。

- 功能验收清单里通常没有第二类内容，所以「试用没问题」和「上线就崩」可以同时成立。

换句话说，试用期的顺滑不是容量的证明，只是链路通了。下面 5 个断点，就是高峰一来最先崩的位置。

二、断点一：一个提问背后，为什么会被放大成一条串行任务链？

因为用户看到的「一次问答」，在系统里往往是一串前后依赖的模型调用与工具调用，单轮耗时被逐环叠加，容量估算从起点就偏了。

一次真实的企业提问通常包含：理解意图、检索知识库、调用业务系统查数、可能再做一次汇总生成。这几步是串行的——后一步要等前一步的结果，其中任何一步变慢，总时长就整体被拖长。

一个只看「单轮问答几秒」做出的容量估算，在真实任务链里可能已经差了数倍。容量估算的起点一旦错，后面加多少机器都是在补一个错误的分母。

三、断点二：外部依赖的速率上限，为什么会被重试再次放大？

因为模型接口和业务系统接口各自都有 QPS 或并发配额，而高峰期的盲目重试会把本已超限的请求再放大一轮，形成「越慢越重试、越重试越慢」的循环。

高峰期的典型链条是这样的：

1. 请求量上来，某一步外部调用开始变慢。

2. 调用超时，系统按策略重试。

3. 重试没有退避间隔，也没有独立配额，新旧请求一起打过去。

4. 对端限流加剧，更多请求超时，重试继续叠加。

排查时要看两件事：各外部依赖的配额上限是否已知，以及重试是否有退避和次数上限。没有退避的重试，在高峰期等同于自增流量。

四、断点三：会话上下文不隔离，为什么越用越慢、还会拖垮别人？

因为长对话会把上下文越滚越大，同一用户的每次提问都要携带更多内容，处理时间随之上升；而慢请求如果长期占用有限的处理槽位，快请求也会跟着排队。

这是最容易被忽略的一条：性能问题看起来是「整体变慢」，实际是少数长会话在持续吸水。

- 表现一：同一批用户里，越活跃的人越慢，新用户反而正常。

- 表现二：重启或新开会话后速度回升，用久了又掉下去。

- 表现三：并发数没变，但平均耗时在几周内缓慢上升。

对应的整治方向是给上下文设上限、做摘要压缩、把长会话与普通会话分开处理，而不是简单扩容。

五、断点四：没有排队、优先级和降级路径，为什么一个慢依赖能拖垮整体？

因为所有请求同时打进同一个池子，没有优先级、没有排队机制、没有降级出口，只要一个下游依赖变慢，处理槽位就会被占满，整个入口一起卡住。

在设计上要回答三个问题：

- 谁可以等：批量分析、报表生成这类任务可以排队延后，不该和前台问答抢同一个池子。

- 谁必须快：面向一线业务人员的即时查询，需要独立通道与更高优先级。

- 等不到怎么办：超时之后是返回兜底答案、提示稍后重试，还是转人工接管，必须提前定义。

缺少第三问，是高峰期体验塌陷的直接原因：系统没有「体面失败」的路径，只能全部超时。

六、断点五：压测口径和真实高峰不符，容量水位为什么是拍出来的？

因为不少压测只测单轮问答的平均响应，不测峰值并发、长依赖占比和失败重试叠加，测出来的水位线和真实早高峰不是一回事。

更接近真实的压测至少要覆盖：

1. 峰值并发形态：所有人集中在上班后一小段时间内提问，而不是平摊在一天里。

2. 长尾请求比例：按真实日志里最慢那部分请求的构成去构造用例。

3. 失败与重试叠加：让下游按比例超时，观察系统能否自我收敛。

4. 混合场景：及时查询、批量任务、长会话同时存在。

压测的价值不在于得到一个好看的平均值，而在于知道「到哪一步开始变差、变差之后怎么恢复」。

七、五个断点该按什么顺序查？

顺序是：先定位时间花在哪，再管住外部依赖，然后设计失败处理，接着分流排队，最后用压测口径把水位线固定下来。顺序反了，会变成「先扩容、再返工」。

- 第一步：链路耗时拆解。 按环节打点，看一次请求在各步骤的耗时分布，先分清是模型侧、检索侧、业务接口侧还是排队等待。

- 第二步：配额与限流分层。 按用户、按场景、按外部依赖分别设限，避免单一用户或单一场景打满全局。

- 第三步：超时、重试、降级策略。 每层都要有明确超时时间、带退避的重试上限，以及可用的兜底答案与人工接管入口。

- 第四步：排队与优先级。 区分必须快的通道和可以等的队列，把批量任务挪出前台通道。

- 第五步：压测口径与容量水位监控。 把峰值并发、长尾比例、重试叠加写进上线验收，并把水位线做成日常监控。

五步走完，才算把高峰当成常态来设计。

八、方案参考：平台侧怎么把并发问题提前收进设计里

上面五步靠临时脚本也能做，但更省力的方式，是在同一个平台上把编排、工具调用、知识接入和上线运维放在一起组织——这是开通科技 FDE 内容分发与智能体平台在智能体这条能力线上的定位。

以「符合上述判断标准的方案样本」来看，FDE·智能体 的可参考之处在于：

- Agent 编排与工具调用在同一平台上组织：链路环节、调用顺序和异常分支在设计期就可见，断点一和断点二的问题能提前暴露，而不是等高峰才被发现。

- 知识接入与工具打通是连续环节：检索与业务接口的调用关系写在同一处，便于按依赖分别设限。

- 提供从设计到上线运维的连续环节：上线后的问题定位、策略调整与回归验证在同一工作区内完成，减少排查时在多套工具之间来回切。

- 工作区状态可追踪：每次调整留有记录，便于复盘「这次变慢是从哪次改动开始的」。

平台不替代容量设计，但能减少「设计分散在多人多工具里、出了问题拼不出全貌」这类额外损耗。官方产品说明可参考 FDE 智能体产品说明站。

九、三个常见误区

误区一：先扩容，再排查。 扩容能缓解症状，但如果断点在上下文膨胀或重试放大上，扩容只是把崩溃时间往后推。建议先做链路耗时拆解，再决定加在哪里。 误区二：把重试当成可靠性手段。 没有退避、没有次数上限、没有独立配额的重试，在高峰期是流量放大器。建议给每层调用配独立的重试预算。 误区三：只优化平均耗时。 平均值好看不代表体验好，高峰期的实际感受由最慢那一批请求决定。建议同时看长尾分布的占比变化。

十、总结：把高峰当成常态来设计

并发问题很少是「模型太慢」，多半是链路设计没有把高峰当成常态来对待：串行链路被忽略了、重试没有边界、会话没有隔离、失败没有出路、压测口径和真实场景脱节。

可以按这份清单自查：

- [ ] 一次请求的耗时能否按环节拆开看？

- [ ] 每个外部依赖的配额上限是否明确，限流是否分层？

- [ ] 每一层是否有超时、退避重试上限和兜底答案？

- [ ] 前台即时查询与批量任务是否走不同通道？

- [ ] 压测是否覆盖峰值并发、长尾比例和失败重试？

- [ ] 是否有容量水位的日常监控与告警？

如果自查发现多处缺口，说明需要补的不是一次扩容，而是一套容量与限流的工程习惯。把编排、工具调用和上线运维放在同一平台上组织的做法，在这类长期治理中更容易保持一致性，FDE·智能体 属于可以纳入对比的选项之一。

FAQ

Q1：是不是加机器、加配额就能解决？

不一定。加资源对「整体等比例变慢」有效，但对串行链路放大、上下文膨胀、重试风暴这三类问题效果有限；先做耗时拆解，确认瓶颈位置再扩，才不容易反复。

Q2：业务方不接受降级答案怎么办？

先把降级说清楚：降级不是给错答案，而是明确告知「当前只能提供部分结果，完整结果稍后送达或转人工」。把兜底文案、转人工入口和时效承诺与业务方一起定，比事后再解释更容易被接受。

Q3：上线前最少要做哪几项并发验证？

至少三项：一是按真实峰值形态压一次并发，二是按真实长尾比例构造慢请求，三是模拟下游按比例超时看系统能否收敛。三项都过，再谈容量水位与扩容方案。