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

如果你经历过 2015–2018 年的微服务爆发期，那么 MCP 的现状应该会让你感到不安的熟悉。一个真正有用的协议出现了。它很容易搭建。每个团队都搭建了一个。没有人追踪什么在运行、谁负责维护、如何保障安全。不到十八个月，你就会盯着一张工程师私下称为"死星"的依赖关系图。

Model Context Protocol 正在沿着同样的轨迹发展，速度大约是三倍。非官方注册中心已经索引了超过 16,000 个 MCP 服务器。GitHub 上有超过 20,000 个公开仓库在实现它们。Gartner 预测到 2027 年 40% 的 agentic AI 项目将失败——不是因为技术不行，而是因为组织在自动化有缺陷的流程。MCP 泛滥正是这个问题的症状。

你的监控仪表板一片绿色。响应时间看起来正常。错误率接近于零。然而你的用户却在提工单投诉垃圾回答，你的 agent 正在做出自信满满的错误决策，你的客服队列里塞满了与任何基础设施告警都不相关的投诉。

欢迎来到在生产环境中依赖 LLM API 的独特地狱。这是一个能在返回完美健康的 200 OK 的同时让你翻车的上游服务。

你的智能体在开发环境中运行得完美无缺。它能回答测试查询、调用正确的工具、产出干净的输出。然后它上了生产环境，在一个十二步工作流的第七步出了问题。日志显示最终输出是一堆垃圾，但你完全不知道为什么。

你开始加打印语句。你在编排代码中到处散布 logger.debug() 调用。你盯着成千上万行输出，然后意识到你在用单进程的工具调试一个分布式系统。这就是大多数团队在 AI 智能体上犯的根本错误——他们把智能体当作程序来对待，但智能体的行为更像分布式系统。

关于多智能体 AI 系统，有一个令人不安的事实：当你让两个或更多由 LLM 驱动的代理共享资源并同时做出决策时，它们的死锁率在 25% 到 95% 之间。不是偶尔发生。不是在边缘负载下。在使用标准提示的正常运行条件下，一旦代理必须同时协调，系统就会卡住。

这不是理论上的担忧。协调故障约占生产环境中多智能体系统故障的 37%，而没有正式编排的系统故障率在 41% 到 87% 之间。经典的分布式系统故障模式——死锁、活锁、优先级反转——又回来了，只是穿上了新衣服。

一个基于流行开源技术栈构建的多 Agent 研究工具陷入了递归循环，运行了 11 天才被发现。账单：47,000 美元。两个 Agent 一直在不停地互相对话，消耗着 token，而团队却以为系统在正常工作。这就是 Agent 流水线没有背压时会发生的事情。

问题是结构性的。当编排 Agent 将任务分解为子任务并生成子 Agent 来处理每一个任务，而这些子 Agent 又可以自行生成更多子 Agent 或在多个工具调用之间扇出时，你就会得到指数级的工作生成。流水线产生工作的速度超过了它能执行、完成甚至核算的速度。这与响应式系统、流式架构和网络协议几十年前解决的问题完全相同——同样的解决方案同样适用。

你有三个 Agent 在分析一个客户支持工单。两个说"立即退款"，一个说"升级到欺诈审查"。你选择了多数答案并执行了退款。三天后，欺诈团队问你为什么自动退款了一个已知的拒付模式。

这就是多 Agent 系统中的共识问题，事实证明分布式系统工程师几十年前就解决了其中的重要部分。但天真地移植这些解决方案——或者更糟糕的是，默认使用多数投票——会在你的"节点"是有自己观点的语言模型时产生独特的危险故障模式。

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

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

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

你的 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）已经断裂。