核心论点：客服 Agent 的分布式难题长得和 Web 服务不一样——LLM 调用秒级起步让并发模型彻底变形、多 Agent 并行让"部分失败"成为常态而非异常、锁保护的从"一行数据"变成"一段跨多次 LLM 调用的业务流程"。本系列讲的是这些老问题的新形态。

分布式的老问题，在 Agent 里变了样

并发一高、单进程撑不住、得水平扩展，这是普通分布式常识。真正值得讲的是分布式的老问题在 Agent 里换了形态：

1. 锁保护的对象不再是一行数据，而是一次具体的纠纷协调实例——用 dispute:{conversation_id}:{order_id} 这个业务语义 key，互斥的是"某会话里某笔订单的那次协调"（事实收集→买方/卖方并行→仲裁，跨 3 次 LLM、秒级），防的是同一纠纷被并发触发两遍、烧两遍 LLM 还出两份矛盾裁决。这把细锁只活在纠纷协调器里——普通聊天路径只读幂等，无需此类去重锁；持有期=一次协调的执行时长（秒级），TTL 仅作进程崩溃兜底，跑完立即释放。
2. 部分失败不是某个 HTTP 返回 500，而是"买方分析成功、卖方分析成功、仲裁却挂了"这种语义半成品；
3. 故障传播不是简单的服务不可达，而是共享的 LLM/向量库一抖动，所有 Agent 角色一起变慢或超时。

连"撑不住"的破法都不一样：Web 请求毫秒级返回、先顶不住 CPU；而 LLM 调用秒级起步，单进程的并发槽位被长耗时等待占死——先耗尽的是连接/线程池，CPU 可能才 20%。这些"老问题的新形态"，才是本系列要拆的。

客服 Agent 的三重压力

这三重压力叠加，正是传统分布式系统经典难题在 Agent 场景的投影——但每一项的破法和形态都和 Web 服务不同，这正是后续各章要拆的。

Shop-Agent 的分布式架构全景

本章只画支撑"三个新形态"的分布式机制：并行协调、分布式锁、依赖扇出。完整拓扑（含常规推理链路）留到对应章节展开。

对应三个新形态：纠纷协调并行调动 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：用分布式锁换可用性，宁可返回"处理中"也不阻塞。