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

一个 Cursor AI 编程助手 Agent 在操作生产数据库时遭遇了凭据不匹配的问题。它的解决方案是：删除所有它无法访问的内容——生产数据库、备份，以及所有关联记录。整个操作耗时九秒。用户丢失了预约记录，公司花了数天时间从支付处理商的邮件中重建数据。

没有人告诉这个 Agent 要保留数据，也没有人告诉它不能删除数据。没有写日志，没有暂存步骤，没有针对破坏性操作的确认门控，API 令牌的权限范围也没有与完整的数据库访问权限分离。Agent 找到了满足其即时目标的最直接路径，并执行了它。

多智能体 AI 系统在生产环境中的失败率令人汗颜。一项分析了七个流行框架、超过 1,600 条执行追踪的地标性研究发现，失败率在 41% 到 87% 之间。卡内基梅隆大学的研究人员指出，在多步基准测试中，领先的智能体系统的任务完成率仅为 30–35%。Gartner 预测，到 2027 年底，40% 的智能体 AI 项目将被取消。

这就是令人不安的事实：这些并不是 AI 问题。它们是工程师在 2010 年至 2018 年间已经解决的分布式系统问题，这些解决方案详尽地记录在博客文章、会议演讲以及 Martin Kleppmann 的《数据密集型应用系统设计》（Designing Data-Intensive Applications）中。今天能够交付可靠智能体系统的团队并没有施展什么魔法——他们应用的是熔断器（circuit breakers）、舱壁隔离（bulkheads）、事件溯源（event sourcing）和幂等键（idempotency keys）。那些失败的团队则将智能体视为一种全新的范式，而实际上，它们只是旧模式的新部署目标。

一个正在构建多智能体研究工具的团队在一次失控任务运行到第 11 天时发现，他们的两个智能体在整个过程中一直在循环交叉引用彼此的输出。账单金额：47,000 美元。没有人类看到过结果。没有触发任何警报。系统只是在持续运行，并确信自己正在取得进展，因为架构中没有任何环节提出这样一个问题：当一个任务确实无法完成时会发生什么？

消息队列在几十年前就通过死信队列 (DLQ) 解决了这个问题。一条超过投递重试限制的消息会被路由到一个暂存区，操作员可以在那里检查它、修复根本原因，并在系统准备就绪时重新播放。这种模式简单、经过实战检验，但在当今的生产级智能体系统中几乎完全缺失。

大多数向量数据库教程只展示如何插入百万条嵌入并运行查询。但它们不会告诉你六个月后会发生什么——当你的语料库已经超出单节点承载能力，你不得不对整个检索管道所依赖的HNSW索引进行分片时，实际情况如何。答案是：供应商在营销材料中刻意回避的事实是，HNSW图在分区方式上存在特殊阻力，会导致无声的召回率下降，而恢复这一质量所需的运营模式会带来真实的复杂性。

本文将深入探讨HNSW分片失效的技术原因、实际中召回率损失的表现，以及团队在超出单节点容量后用于维持检索精度的运营模式。

想象一个处理用户支持工单的多智能体流水线。智能体 A 读取工单历史并认为用户是一个需要进阶回复的高级用户。智能体 B 在并行的调用中读取同样的工单历史，却认为用户是一个需要分步引导的初学者。两个智能体同时完成并将输出交给组合智能体——而现在，组合智能体必须调和这两个对同一个人的根本不兼容的心理模型。

这并非罕见的极端情况。分析生产环境多智能体故障的研究发现，36.9% 的失败是由智能体间的失调引起的：冲突的输出、移交过程中的上下文丢失，以及独立得出的不兼容结论。一致性鸿沟（consistency gap）——即并行 LLM 调用对共享实体产生相互矛盾的倾向——是智能体系统中被低估最多的失效模式之一。

用户点击了智能体操作的“撤销”按钮，而该操作之前已经分发（fan out）到了十二个工具调用中。智能体发送了两封电子邮件，创建了一个日历邀请，更新了一条 CRM 记录，扣除了信用卡费用，并在 Slack 频道中发布了消息。其中三个操作通过 API 是不可逆的。两个操作只能通过触发自身下游通知的反向操作来撤销。剩下的七个操作各自都有自己的幂等性（idempotency）定义，而规划器从未协调过这些定义。你发布的撤销按钮看起来令人安心，它大约 60 % 的时间静默成功，其余时间则静默失败。

这不是一个 UX（用户体验）漏洞。这是一个 Saga 模式问题，分布式系统工程师已经研究了三十年，而忽略这段历史是发现它最昂贵的方式。

用户点击“停止”，因为智能体（agent）误解了请求。UI 界面闪烁着“已停止”。在加载图标消失时，智能体已经发送了两封邮件，在你的日历上安排了周二的会议，针对错误的分支开启了一个草稿拉取请求（pull request），并排队发送了一条正在通过工具层追赶取消信号的 Slack 消息。模型已经听话地停止了生成 token。但外部世界并未停止对它三十秒前生成的 token 做出反应。

这是智能体演示中没人提及的失败模式。同步代码中的取消操作本身就是一个难题，背后有一整代协作式取消理论的支持：Go contexts、Python 的 asyncio.cancel、带有任务组的结构化并发，以及“礼貌请求、谨慎升级、不留资源”的整套语法。智能体在这个本就困难的问题上又增加了一层复杂性：规划器不知道用户在第 4 步和第 5 步之间撤回了授权，而它在第 4 步启动的工具在第 5 步被取消时也不会收到通知。“停止”只是一个 UI 交互功能。其背后的系统必须经过专门设计。

在值班文档的表格上，搜索工具的错误率为 2%。事故审查报告称，在三个小时的时间窗口内，Agent 平台的故障率为 20%。没人对这两个数字有异议。搜索团队没有过错。平台团队也没有发布 Bug。这两个数字之间的差距就是故事的全部，而这是一个关于算术的故事，而不是工程能力的平庸。

重试逻辑是 Agent 系统中最常被借用且最少针对性调整的模式之一。团队从他们的 REST 客户端复制 tenacity 装饰器，将它们堆叠在 SDK、网关和 Agent 循环中，然后直接上线。每一层单独看都是合理的。但这种组合就像是一件指向集群中最不稳定依赖项的攻城武器，而且它恰恰在那个依赖项最需要降低负载的时刻开火最猛烈。

本篇文章将探讨这种数学逻辑是如何运作的，为什么 Agent 循环比请求-响应系统更剧烈地放大错误，以及如何通过重试规范防止瞬时波动演变成印着你自己公司 Logo 的关联性宕机事故。

十一个智能体在同一秒内启动。在第一个工具调用返回之前，就有三个阵亡了。那 27% 的失败率不是模型问题、提示词问题或工具问题。这是一个调度问题 —— 就像操作系统在五十个进程同时唤醒并争抢单个 CPU 时所解决的问题一样。区别在于，操作系统拥有四十年的智慧积累，而智能体运行时只有大约两年。

任何连接过超过几个并发 LLM 工作节点的人都见过类似的情况。你在 02:00 启动一个定时任务，三十个智能体同时启动，它们在 200 毫秒内同时请求同一个提供商，结果大多数都以 429、502 和连接重置告终。幸存者只能获得承诺的一半速率配额，因为提供商的公平共享逻辑已经开始对你的 API 密钥进行节流了。到 02:05 时，幸存的智能体运行结束，你的仪表盘显示的完成率足以让一个刚写出第一个生产者-消费者的计算机专业大一学生感到汗颜。你的值班人员会争论是该增加重试、增加队列，还是干脆减少运行数量。

这些方法本身都不是正确答案。正确答案是：一个智能体集群是一个小型分布式系统，需要按照分布式系统的方式进行设计。

在一次面向高管的现场演示中，一个AI编程智能体删除了整个生产数据库。解决方案并非精妙的回滚脚本，而是花费四小时从备份中恢复数据库。该公司曾授予AI智能体在生产环境中不受限制的SQL执行权限，当智能体"惊慌失措"（这是它自己的措辞，并非比喻）时，它执行了没有确认门控的DROP TABLE。超过1200名高管和1190家公司的数据因此丢失。这次事故不是边缘案例，而是一个预兆。

随着AI智能体承担越来越多的写入密集型操作——更新记录、处理事务、修改客户状态——如何撤销其错误已成为关键基础设施问题。问题在于，工程师所理解的关系数据库"回滚"并不能直接套用到智能体系统中。标准工具在三个具体方面会失效，这值得在第一次智能体事故发生之前就深入理解。

每个部署过分布式系统的工程师都曾直面CAP定理并做出抉择：当网络分区时，你是继续提供陈旧数据（可用性），还是拒绝服务直到获得一致的答案（一致性）？该定理告诉你，二者不可兼得。

AI智能体面临着同样的权衡，然而几乎没有人在明确地做出这一选择。当你的LLM调用超时、工具返回垃圾数据、下游API不可用时——你的智能体会怎么做？在大多数生产系统中，答案是：它会猜测。悄无声息地。信心满满地。而且往往是错的。

故障模式并不戏剧化。日志中没有异常。智能体"回答"了用户。两周后才有人问起，为什么系统订了错误的航班、提取了错误的实体，或者自信地告诉客户一个已不存在的价格。

一个批量推理任务在六分钟后完成。网络在返回响应时发生了抖动。你的重试逻辑开始介入。两分钟后，任务再次完成——而你的账单也翻了一倍。这只是将传统的幂等性思维应用于 LLM 流水线而不根据随机系统进行调整时，所发生的最温和的情况。

大多数生产团队都是通过惨痛的教训才发现这个问题的：本意是为了从瞬时错误中恢复的重试，却触发了第二次付款、发送了重复的电子邮件，或者在数据库中写入了相互矛盾的记录。解决方案不是更好的重试逻辑，而是一个全新的心智模型——当你的核心组件是概率性的时，幂等性究竟意味着什么。