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

AI Agent 的标准心智模型通常假设采用 HTTP：客户端发送请求，Agent 进行处理，最后返回响应。这种模式清晰、同步、且易于推理。当一个基于 LLM 的函数执行失败时，你会收到一个错误代码；当它成功时，你就可以继续下一步。

一旦你将 HTTP 接口换成 Kafka 主题或 SQS 队列，上述每一个假设都会开始动摇。队列保证的是“至少一次交付”（at-least-once delivery），而你的 Agent 具有随机性。这种组合产生了一些在确定性系统中并不存在的故障模式——而且修复方法也与传统微服务所采用的方法不同。

本文将探讨当 AI Agent 消费消息队列时实际发生的变化：幂等性、顺序性、背压、死信处理，以及一种特定的故障模式——即重播的消息在第二次触发时会导致 Agent 产生不同的行为。

每篇智能体教程都从单个用户、单个会话和单个上下文窗口开始。智能体读取状态、推理、行动、写回。清晰、确定。对于团队实际使用的场景来说，这种假设完全错误。

真实的协作产品——共享规划看板、多用户支持队列、文档协作副驾驶、团队项目助手——需要多个用户同时与同一个智能体交互。当两个人在同一秒内向智能体发出相互矛盾的指令时，其中一个人的修改就会消失。智能体不会告诉他们，甚至自己都不知道发生了什么。

这就是多用户共享智能体状态问题，它是一个披着AI外衣的分布式系统问题。

几乎所有关于构建 AI Agent 的教程都以同样的方式开场：用户输入消息，Agent 进行推理，Agent 返回响应。这个模型对聊天机器人和副驾驶（Copilot）来说运行良好，却无法描述各组织正在大规模部署的大多数生产 AI 工作。

在企业环境中默默发挥最大价值的 Agent，并不等待消息。它们在数据库行发生变更时唤醒，在队列深度超过阈值时唤醒，在凌晨 3 点的定时任务触发时唤醒，或在监控检测到指标漂移超出范围时唤醒。它们在没有用户在场的情况下行动。一旦失败，没有人会察觉，直到损失已经累积到难以挽回。

构建这类主动型 Agent 需要一套与构建被动式助手截然不同的设计语汇。适用于对话型 AI 的会话（Session）思维模型，在 Agent 循环运行、在后台重试、没有人类兜底的场景下会彻底失效。

当智能体决定记住某件事——"用户更喜欢邮件而非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% 之间。经典的分布式系统故障模式——死锁、活锁、优先级反转——又回来了，只是穿上了新衣服。