AI Agent 并发与可靠性：100 人同时用不崩的工程设计

当你把 Agent 从“自己用”变成“多人用”，故障通常会以一种非常不体面的方式出现：

同一时间 50 个请求打到模型/工具，开始 429（rate limit）或超时。
你加了重试，结果把对方 API 打挂，自己的队列也被挤爆。
多个并发请求写同一个会话状态，记忆被覆盖，回答开始串台。

这篇文章不讲“多买服务器”，只讲能落地的工程解法：把 Agent 当成线上系统，围绕失败设计。

一、先把“并发”说清楚：你在同时扛哪些东西？

在 Agent 系统里，并发不是一个维度，而是至少四个并发面：

用户并发：同时多少人发请求。
步骤并发：一个请求内部可能并发调用多个工具/检索。
外部依赖并发：模型供应商、向量库、业务 API、文件系统、数据库。
状态并发：同一会话多请求同时读写状态（最容易串台）。

你做可靠性设计的目标不是“永不失败”，而是：

失败可控（不扩散）
恢复可预期（可重试且幂等）
体验可接受（降级而不是崩溃）
过程可观测（能定位、能回放、能复盘）

二、第一层：入口限流与排队（别让系统一上来就炸）

2.1 不要把所有请求直接打到模型

模型/工具通常是最贵、最慢、最容易被限流的依赖。你需要“入口治理”：

全局限流：保护供应商配额
用户级限流：防止单个用户打爆系统
会话级串行：同一会话默认串行处理，避免状态竞争

2.2 一个可落地的三段式队列

你可以按成本和优先级拆三层：

快速路径（Fast path）：能在 1~2 秒内完成的（纯检索/缓存命中/无需 LLM）。
标准路径（Normal）：一次 LLM + 少量工具调用。
重任务路径（Heavy）：多步规划、长文生成、多工具并发。

核心思想：别让重任务挤占轻任务的可用性。

三、第二层：超时、重试与幂等（重试不是“再来一次”）

3.1 超时要分层，不要只设一个大 timeout

模型调用：例如 30s（带 streaming 可更长，但必须有心跳）
检索/向量库：例如 2~5s
业务 API：例如 3~10s（看 SLA）

超时的意义是：把“坏请求”尽快变成可控失败，释放资源。

3.2 重试的正确姿势：指数退避 + 抖动 + 预算

重试至少要满足：

指数退避：$1s, 2s, 4s...$
抖动（jitter）：避免所有请求同一时刻重试
重试预算：每个请求最多重试 N 次，或总重试时长不超过阈值

3.3 幂等是底线：否则重试会制造“重复副作用”

凡是可能产生副作用的工具调用（下单、发邮件、写数据库），必须有幂等键：

idempotency_key = user_id + conversation_id + step_id + request_id

当你在面试里讲可靠性，幂等通常是“工程味”的关键加分点。

四、第三层：会话隔离与并发一致性（串台是致命体验）

4.1 同一会话并发的两种安全策略

策略 A：会话级排队（推荐起步）

同一 conversation_id 的请求排队串行执行
代价：同一会话的并发吞吐低
收益：最简单、最稳定、不串台

策略 B：乐观锁 + 合并（高阶）

状态带 version
写入时检查版本；冲突则合并或回滚重放
代价：复杂
收益：可以并发，但要解决“状态合并语义”

如果你还没有成熟的状态机，不建议直接上 B。

4.2 把“状态”当成数据库记录，而不是 prompt 文本

你应该能回答：

状态存在哪里（DB/Redis）
状态 schema 是什么（字段级）
每轮请求更新哪些字段
如何回放一条会话的状态演进

配合结构化输出，你可以把“状态更新”做成可校验协议：

结构化输出与 Schema 控制

五、第四层：降级、熔断与体验兜底（让系统“难用但可用”）

当外部依赖不稳定时，你要有明确降级路径：

5.1 模型不可用的降级

返回缓存的上一次成功答案（带“可能过期”提示）
只给“下一步需要你补充的信息”（而不是硬编答案）
切换到更便宜/更快的模型（质量下降但能用）

5.2 工具不可用的降级

返回“我无法完成步骤 X，因为工具 Y 超时”，并给替代方案
把任务切换为“生成操作清单/手工步骤”

5.3 熔断：防止坏依赖拖死全系统

当某个工具连续失败时：

短时间内直接拒绝调用（熔断打开）
只允许少量探活请求
恢复后逐步放量

六、可观测性：没有 tracing，你永远在猜

Agent 的观测不只要日志，还需要“可回放”。推荐最小采集：

trace_id：贯穿一次用户请求
conversation_id / user_id
step_id / tool_name / tool_latency_ms / tool_error
model / prompt_tokens / completion_tokens / cost
retry_count / timeout_count / circuit_breaker_state
citations_count（如果有 RAG 引用）

然后把失败分成可行动的类别：

入口限流导致的拒绝（容量问题）
外部依赖 429/5xx（配额/供应商问题）
工具超时（SLA 或网络）
状态冲突（并发一致性）
输出校验失败（协议/Prompt/Schema）

这也是“项目含金量”的核心来源：你能用数据讲清楚系统怎么变好。

七、一个最小可上线架构（你可以直接画在面试白板上）

你可以用这套骨架讲清楚“并发与可靠性”闭环：

API Gateway：认证 + 限流 + 路由
Job Queue：按会话/优先级排队
Agent Worker：执行 planning + tool calling
State Store：会话状态 + 摘要 + 版本
Evidence Store：向量库/知识库（RAG）
Observability：trace + metrics + replay

如果你在选题 5 做好了记忆与状态，这里就是自然延伸。

八、落地清单：从“能跑”到“能扛”

按这个顺序做，成本最低，收益最大：

会话级串行（排队）+ 用户级限流
分层超时 + 指数退避重试 + 幂等键
工具熔断 + 降级路径
状态 schema + 版本化写入
tracing + 关键指标 + 失败分类

下一步如果你想继续把系统做“更复杂”，可以进入多 Agent 编排或安全权限：

多 Agent 协作架构（选题 7）
Agent 安全与权限控制（选题 9）