智能体应用的并发特征与传统 API 不同

发布时间:2026-04-28 13:15

传统 API 请求大多几十毫秒返回，智能体（Agent）应用的同一请求可能挂住几分钟——它要连续调用模型、查询外部工具、再组织答案。这个差别决定了并发设计不能照搬老经验。 三个显著特征 长连接：客户端要等最终结果，连接存活时间从毫秒级变成分钟级，流式输出（一边生成一边推送）成为标配，服务端要同时维持大量挂起的连接。 多轮调用：一次用户请求在内部触发多次模型调用与外部查询，任何一步慢或失败都会放大到整体时延。后端容量不能只按用户请求数估算，要按内部调用链的总时长估算。 峰值难预测：任务型应用的并发跟着业务节奏走，报表生成、批量总结容易在同一时段扎堆，瞬时并发可能是日常的数倍。 容量与超时怎么设计 容量口径：不要按 QPS（每秒请求数）规划，按"同时进行的会话数 × 单会话资源占用"规划，GPU 推理服务尤其要看并发批大小。 超时分两层：单步调用设短超时，比如单次工具查询 10 秒；整个会话设总预算，比如 120 秒，超了就返回阶段性结果，让用户选择继续或放弃。 排队与降级：并发超限进队列，队列满则快速拒绝并告知预计等待；高峰期可把非核心功能（如长文摘要）降级为异步任务。 断线与重试：流式连接中断后要能续传或重放，重试加退避间隔，避免故障时客户端风暴式重连。 网关层的设计逻辑不同 传统网关追求把单次请求耗时压到最低，智能体网关更关心把长时间占用管理好：连接空闲超时要与模型生成节奏匹配，中间状态要能落库，服务重启后会话能恢复。灰度发布也要换思路，一个模型版本的切换会影响所有进行中的会话，新版本先接新会话、旧会话跑完再迁移，是减少冲击的常规做法。 收一句：智能体服务的稳定性，一半取决于模型能力，另一半取决于排队、超时、降级这三件"无聊"的设计。后一半没做好，前一半的能力用户根本体验不到。