核心论点客服 Agent 的分布式难题长得和 Web 服务不一样——LLM 调用秒级起步让并发模型彻底变形、多 Agent 并行让部分失败成为常态而非异常、锁保护的从一行数据变成一段跨多次 LLM 调用的业务流程。本系列讲的是这些老问题的新形态。分布式的老问题在 Agent 里变了样并发一高、单进程撑不住、得水平扩展这是普通分布式常识。真正值得讲的是分布式的老问题在 Agent 里换了形态锁保护的对象不再是一行数据而是一次具体的纠纷协调实例——用dispute:{conversation_id}:{order_id}这个业务语义 key互斥的是某会话里某笔订单的那次协调事实收集→买方/卖方并行→仲裁跨 3 次 LLM、秒级防的是同一纠纷被并发触发两遍、烧两遍 LLM 还出两份矛盾裁决。这把细锁只活在纠纷协调器里——普通聊天路径只读幂等无需此类去重锁持有期一次协调的执行时长秒级TTL 仅作进程崩溃兜底跑完立即释放。部分失败不是某个 HTTP 返回 500而是买方分析成功、卖方分析成功、仲裁却挂了这种语义半成品故障传播不是简单的服务不可达而是共享的 LLM/向量库一抖动所有 Agent 角色一起变慢或超时。连撑不住的破法都不一样Web 请求毫秒级返回、先顶不住 CPU而 LLM 调用秒级起步单进程的并发槽位被长耗时等待占死——先耗尽的是连接/线程池CPU 可能才 20%。这些老问题的新形态才是本系列要拆的。客服 Agent 的三重压力压力表现分布式映射和传统 Web 服务的区别高并发大促咨询峰值水平扩展 → 状态如何在节点间一致单次请求秒级而非毫秒级并发槽位被长耗时 LLM 等待占死先耗尽的是连接/线程池而非 CPU更致命的是 LLM 响应时间方差极大正常 2 秒、异常可能数十秒一旦变慢堆积请求反堵本可正常响应的调用形成传统毫秒服务少见的超时雪崩低延迟用户等不得并行调用 → 部分失败如何兜底部分失败是三个角色成功俩、仲裁挂了的语义半成品不是一个干净的 HTTP 500多依赖LLM/向量库/Redis/外部 API依赖故障如何隔离、不雪崩LLM/向量库是跨角色共享的单点热点一抖则买方/卖方/仲裁全体变慢故障沿角色链而非服务调用链传播这三重压力叠加正是传统分布式系统经典难题在 Agent 场景的投影——但每一项的破法和形态都和 Web 服务不同这正是后续各章要拆的。Shop-Agent 的分布式架构全景本章只画支撑三个新形态的分布式机制并行协调、分布式锁、依赖扇出。完整拓扑含常规推理链路留到对应章节展开。纠纷场景分布式锁用户消息编排层纠纷协调BuyerAgentSellerAgentMediatorAgentRedisLLM / 向量库 / 外部 API对应三个新形态纠纷协调并行调动 Buyer/Seller 再由 Mediator 裁决低延迟→部分失败的语义半成品、协调前抢一把分布式锁防重复执行高并发→会话订单粒度的锁争抢见《分布式锁——纠纷协调中的原子性保障》、所有 Agent 共享 LLM/向量库/外部 API多依赖→沿角色链的故障传播。关键指标QPS、p99 延迟、可用性目标QPS决定要扩几个节点——但 Agent 扩容的触发器不是 CPU 水位而是被长耗时 LLM 等待占死的并发槽位/连接池水位呼应上文破的位置不同节点一多会话订单粒度的状态一致立刻成为问题。p99 延迟用户感知的慢由最慢那次依赖决定并行调用把 p99 从串行之和压到最慢之一但越多并行依赖 越大故障面必须处理三个角色成功俩的语义半成品式部分失败。可用性目标比如 99.9%。要容忍的不只是节点随时挂掉还有 LLM/向量库这类共享依赖的整体抖动属故障隔离范畴见多依赖与第 15 篇而一旦网络分区发生该保一致还是保可用才是 CAP 要回答的——见下节。CAP 在客服场景的实践偏向 AP客服对话不能等一致。Shop-Agent 在纠纷协调前会抢一把 Redis 分布式锁key dispute:{conversation_id}:{order_id}TTL 5 分钟——仅作进程崩溃兜底正常流程跑完即释放不会真持有那么久抢到锁 → 正常协调没抢到锁已被同会话占用→直接返回处理中而不是阻塞或重复执行。这本质是一个AP 选择宁可暂时放弃强一致同一时刻只允许一个协调流程也要保住可用性与正确性。CP 系统在这种情况会宁可拒绝服务对客服体验更糟。注意这把锁正是开头说的新形态①的落地——它保护的不是某行数据而是一段持续数秒、跨 3 次 LLM 调用的协调流程CAP 的取舍也因此发生在业务流程级而非存储级。核心要点客服 Agent 的分布式难题不是要不要上而是老问题锁 / 部分失败 / 故障传播换了新形态。锁保护的是一次具体的纠纷协调实例而非一行数据、部分失败是语义半成品、故障沿角色链传播——都和 Web 服务不同。连撑不住的破法都不同先耗尽的是被长耗时 LLM 等待占死的连接/线程池而非 CPU。架构上编排层之下以并行协调纠纷为主链路见图常规推理链路留待后续章节。客服场景在 CAP 上偏 AP用分布式锁换可用性宁可返回处理中也不阻塞。