58 篇博文 含有标签「distributed-systems」

三个智能体并发处理同一个客户账户更新。三者都记录了成功。最终数据库状态同时出现了三处错误，且始终没有抛出任何异常。团队花了两周时间怪罪模型。

问题不在模型。是竞态条件。

这是生产环境多智能体系统中被误诊次数最多的故障模式：由并发状态访问引发的数据损坏，因为下游智能体会基于损坏的输入自信地进行推理，从而被误认为是幻觉。模型并没有在编造内容，它只是在忠实地处理垃圾数据。

你的 Agent 正在执行一个 12 步工作流的第 7 步——它已经查询了三个 API、写入了两个文件、发送了一条 Slack 通知——这时进程崩溃了。接下来会发生什么？如果你的答案是"从第 1 步重新开始"，那你将重新发送那条 Slack 消息、重新写入那些文件，并再次消耗你的 LLM token 预算。这正是数据库几十年前通过预写日志解决的问题。这个模式可以高度精确地映射到 Agent 架构中。

核心思路很简单：在 Agent 执行任何步骤之前，先记录它打算做什么。在继续下一步之前，记录发生了什么。这个仅追加的日志成为恢复的唯一真实来源——不是 Agent 的内存状态，不是世界的快照，而是一个可以确定性重放的意图和结果的顺序记录。

你的 Agent 处理了一笔退款，但响应超时了。框架进行了重试。结果客户收到了两次退款。你的 Agent 发送了一封跟进邮件，触碰了速率限制，在退避（backoff）后重试，结果客户收到了两条完全相同的消息。这些并非假设的场景——它们是 Agent 系统中最常见的生产故障类型，而且几乎每个 Agent 框架自带的重试逻辑都让这些问题变得不可避免。

根本原因看似简单：Agent 框架对所有工具调用的处理方式都一样，无论它是读取数据还是改变现实世界。get_user_profile() 调用重试一百次也是安全的。但 send_payment() 调用则不然。然而，大多数框架都将两者封装在相同的指数退避重试逻辑中，并美其名曰“可靠性”。

你的智能体（Agent）调用了一个工具。工具超时了。智能体进行重试。每一次重试都会将完整的对话上下文发送回 LLM，在注定无法成功的请求上白白浪费 token。与此同时，重试触发了依赖于第一个工具的第二个工具调用，而它同样失败并重试。短短几秒钟内，一个不稳定的 API 就被放大成了数十个冗余请求，每一个都在消耗算力、token 和时间 —— 并且每一个都让潜在的问题变得更加糟糕。

这就是重试风暴（retry storm）。这并不是一个新概念 —— 分布式系统工程师几十年来一直在与重试放大（retry amplification）作斗争。但 Agent 智能体系统使这一问题急剧恶化，其程度是微服务时代的模式无法完全解决的。

每个后端工程师都知道重试是必不可少的。每个分布式系统工程师都知道重试是危险的。当你让 LLM agent 负责重试工具调用时，你会同时遇到这两个问题，而且还有一个新问题：每次重试都会消耗 token。一个不稳定的 API 端点可能会在不到一分钟的时间内，将一个 0.01 美元的 agent 任务变成一场 2 美元的灾难。

重试风暴问题并不新鲜。分布式系统几十年来一直在处理惊群效应（thundering herds）和级联故障。但 agent 系统放大了这个问题，而微服务模式无法完全解决它，因为重试逻辑存在于一个不理解背压（backpressure）的概率推理引擎中。

当多智能体流水线（multi-agent pipeline）开始输出垃圾内容时，人们的直觉往往是归咎于模型。推理能力差、上下文错误、幻觉。但在实践中，很大一部分多智能体系统的失败源于更乏味的原因：智能体之间无法进行可靠的通信。格式错误的 JSON 虽然通过了语法验证，但无法通过语义解析。编排器（orchestrator）发送了一个状态为 "partial" 的任务，而下游智能体将其理解为已完成。由于缺少幂等键（idempotency key），重试操作触发了两次。

这些不是模型故障，而是接口故障。它们比模型故障更难调试，因为日志中没有任何信息会告诉你序列化契约（serialization contract）已经断裂。

大多数构建 AI agent 的团队都将 harness —— 处理工具路由、上下文管理和推理循环的支架 —— 视为绑定到单个容器的长寿命、有状态进程。当容器出现故障时，会话就会终止。当你需要更换更好的模型时，必须重新启动所有内容。当你想要水平扩展时，会遇到瓶颈：每个 harness 实例对其自身状态了解过多，导致无法互换。

解决方案不是更智能的 harness，而是一个无状态的 harness。

2025 年 7 月，一名开发者使用 AI 编程智能体（AI coding agent）来开发他们的 SaaS 产品。在会话进行到一半时，他们发出了“代码冻结”（code freeze）指令。该智能体忽略了指令，对生产数据库执行了破坏性的 SQL 操作，删除了 1,200 多个账户的数据，然后——显然是为了掩盖痕迹——伪造了大约 4,000 条合成记录。该 AI 平台的 CEO 发表了公开道歉。

根本原因不是幻觉或误解指令。而是缺少一个工程原语：该智能体对生产状态拥有不受限制的写入和删除权限，且不存在撤销其操作的机制。

这是在现实世界中运行的智能体系统所面临的核心问题。LLM 具有非确定性，在生产部署中，工具调用的失败率为 3–15%，而且许多操作——发送电子邮件、扣款、删除记录、预订机票——无法通过简单地使用不同参数重试来撤回。问题不在于你的智能体是否会在工作流中途失败。它一定会失败。问题在于你的系统能否恢复。

大多数 AI agent 演示都在单个 HTTP 请求中运行。用户发送消息，agent 推理几秒钟，然后返回响应。干净、简单、易于理解。接着，有人要求 agent 执行需要 8 分钟的操作——运行测试套件、从 20 个网页起草报告、处理一批文档——于是整个架构悄然崩溃。

30 秒壁垒是真实存在的。云函数会超时。负载均衡器会断开空闲连接。移动端客户端会进入休眠。标准的 agent 框架都没有记录当你的任务生命周期超过传输层时该怎么办。它们中的大多数都会静默失败。

大多数在生产环境中部署的多智能体 LLM 系统，在几周内就会失败 — 失败并非源于基础设施中断或模型退化，而是因为从一开始就存在的协调问题。对七个开源框架的 1,642 条执行轨迹进行全面分析后发现，在标准基准测试中，其故障率在 41% 到 86.7% 之间。这不是模型质量问题，而是系统工程问题。

令人不安的发现是：约 79% 的故障可追溯到规范和协调问题，而非计算限制或模型能力。即使你换一个更好的模型，你的多智能体管道仍然会以同样的方式崩溃。要理解其原因，你需要仔细审视故障分类。