---
title: "不占住连接，也能扛住 AI 助手的流量"
url: https://tanghoong.com/zh-hans/work/ai-assistant-queue-architecture/
locale: zh-hans
description: "把 AI 客服助手的请求路径从同步改为队列加前端轮询：超时上限不再支配一次对话，客户被并行服务而不是彼此排队。"
---
# 不占住连接，也能扛住 AI 助手的流量

> 重构 AI 客服助手的请求路径：一次对话改为进队列并由前端轮询，而不是占住一条同步连接 —— 已交付并合并。

- **角色:** Senior Web Developer
- **能力:** 应用 AI · 架构 · 可靠性
- **领域:** 带 AI 客服助手的生产环境电商平台
- **变更:** 同步请求路径 → 队列 + 前端轮询

## 背景

一个线上电商平台，除了既有的业务流程之外，还有一个服务客户的 AI 客服助手。

## 问题与模糊之处

每一个 LLM 产品的中心都有一个结构性的错配：一次模型回合动辄数十秒，而一个网页请求在抵达模型的路上会经过的所有东西 —— 网关、防火墙、代理 —— 它们的超时预算都是为毫秒级请求设计的。所以同步设计会同时有两种失效模式。明显的那一种是：一个慢回答可能超过路径上某一处的上限。被忽略的那一种是：它跑的时候占住了那条路径，于是下一位客户排在后面等。从外面看，这两种一模一样：AI 很慢。而两者都不是模型的问题。

## 我的角色

我参与公司的 AI 客服系统 —— 知识结构、响应路由、工具调用、会话管理、评测、安全控制与转人工 —— 并且设计并交付了这里描述的请求路径变更。平台本身的生产环境电商系统也由我维护。

## 需求发现

有用的问题不是「怎么让模型更快」，而是「这条路径上有什么东西预期请求会很快结束？而当它没有结束的时候，其他人会怎么样？」回答这个问题，就把题目从模型调优换成了连接架构。

## 架构与取舍

不再同步处理。请求进队列；浏览器每隔几秒轮询一次，准备好就渲染出来。没有任何东西占住连接，所以路径上的超时上限不再支配一次对话，客户是被并行服务的，而不是彼此排队。代价是客户端稍微复杂一点、以及一个看得见的等待状态 —— 这个交换我会再做一次，因为另一个选择是让它安静地、而且不公平地失败。

## 实现与集成

在平台既有框架上的 queue workers，搭配前端轮询，以及模型调用外围的重试与错误处理。另外带进两项控制：闲置会话会到期 —— 安静下来的对话会被提示一次，没有响应就关闭并释放它占住的资源；以及较轻的请求路由到较小的模型层级，而不是每一次调用都打最大的模型 —— 这是不牺牲重要回答质量的前提下，最简单的推理成本控制。

## 生产环境控制

模型调用外围的重试与错误处理；会话生命周期管理；以及一套「设计进去而不是事后加上」的评测思路 —— 包含一次回答需要检索并合并多项信息时的正确性，以及在对抗性与社交工程探测下的行为。那套评测是正在建立中，不是已经上线的加固 —— 我描述的是一个设计，不是一个结果。

## 成果

这次重构已完成并合并进平台。这项工作不公布任何性能数字，未来也不会 —— 我没有一个能诚实宣称的生产环境结果。

## 可复用的经验

当一个 AI 功能被说成「慢」，先量路径，再去动模型。以我的经验，模型做的还是它一直在做的事，是它周围的架构改变了使用者的体验 —— 而修法几乎永远是：不要再占住连接。

## 证据待补

客户那套助手的任何东西都不发布 —— 知识结构、提示词、评测集、任何性能数字，都不发布。上面描述的机制是通用的，不属于客户；用我自己的内容做的独立实现是另一套系统，与该雇主的业务无关。