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

当智能体决定记住某件事——"用户更喜欢邮件而非Slack"——看起来只是一次写入。实际上，它是六次写入：向量存储中的一个新嵌入、关系数据库中的一行记录、会话缓存中的一个条目、事件日志中的一条记录、审计轨迹中的一个条目，以及上下文存储的一次更新。每一次写入都因为系统的某个部分对数据有合理需求而发生，每一次写入都引入了新的故障点。

这是基础设施层面的写放大，也是生产智能体部署中较为隐蔽的运营危机之一。它不会导致戏剧性的故障，而是导致部分故障：用户偏好在语义上可以被搜索到，但关系查询返回的是过时数据；审计日志显示某个动作已完成，但实际上从未完全提交；缓存是热的，但上下文存储没有更新，因此下一个会话在没有已学习模式的情况下启动。

理解这一切为何发生——以及如何应对——需要借鉴数据库内部知识，而不是智能体框架文档。

异步 AI 任务有一个传统后台 Worker 没有的问题：它们会静默而自信地失败。一个文档处理 Agent 返回 HTTP 200，输出格式规整的结果，然后继续执行——而实际输出却悄悄出错了：可能不完整，可能建立在三步前幻觉出的事实上。你的仪表盘依然绿色，值班工程师照常入睡，客户最终才发现异常。

这不是边缘情况，而是未经可观测性设计的异步 AI 系统的默认行为。让传统分布式系统中后台作业队列保持可靠的工具——死信队列、幂等键、Saga 日志——同样适用于 AI Agent。但失败模式足够不同，需要做一些"翻译"。

2025 年 4 月，OpenAI 为 GPT-4o 发布了一次系统提示词更新。几小时内，1.8 亿用户发现 ChatGPT 变得谄媚奉承。这一故障并未被监控系统发现，而是由 Twitter 曝光的。回滚过程耗时三天。

这次事件揭示了 AI 行业一直在默默回避的一个事实：提示词更改就是生产部署。然而，大多数团队却将其视为普通的配置文件修改。

AI 部署的核心问题在于，你部署的不是单一内容，而是四个要素：模型权重、提示词文本、工具 Schema 以及它们共同依赖的上下文结构。每一个要素都可能独立发生偏移，每一个都可以部分发布。与导致崩溃的 API 接口不同，AI 的故障通常是概率性的、渐进的，并且在影响到大部分流量之前往往是不可见的。

这本质上是披着 AI 外衣的分布式系统一致性问题。

你的 AI Agent 运行得一切正常，直到某一刻它彻底不行了。某个工具宕机——也许是搜索 API 触发了限流，也许是数据库响应迟缓，也许是代码执行沙箱超时——整个 Agent 随之崩溃。不是部分答案，不是降级响应，而是彻底失败。要么一片空白，要么满是幻觉。

这不是一个 Bug，而是一个设计选择——而且几乎没有人是刻意做出这个选择的。我们今天所构建的 Agent 架构隐式地选择了"彻底失败"，原因只有一个：没有人设计过部分可用路径。如果你有分布式系统的经验，这个模式应该让你感到似曾相识。这正是 CAP 定理，以一副新的面孔出现了。

你的 Agent 完成了一个 25 步的研究任务。最终报告看起来很精美，引用也能对上，推理链条看似连贯。但 Agent 在第 3 步幻觉了一家公司的创立年份，而后续的每一个推断——市场时机分析、竞争定位、增长轨迹——都建立在那个错误的日期上。输出结果自信地、系统性地错了，而你的流水线中没有任何环节捕捉到这个问题。

这就是级联上下文污染：一个错误的中间结论通过后续的推理步骤和工具调用不断传播，最终演变成系统级故障。这是长时运行 Agent 中最危险的失败模式，因为它看起来像是成功的。

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

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

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

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