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

我上个季度合作过的一个团队发布了一个包含七个步骤的智能体（agent），并以显而易见的方式构建了其延迟预算：搜索返回耗时 200ms，SQL 查询耗时 80ms，电子邮件发送耗时 150ms，链条中的其他环节以此类推。将中位数相加，再加入一些缓冲，数学计算表明该智能体能轻松地保持在两秒的 SLA 之内。仪表板连续几周证实了这一点。中值延迟（median latency）表现优异。接着，客户开始抱怨该功能慢得无法使用，而仪表板看起来依然是代表正常的绿色。

他们互相转述的故事是错误的，因为他们是围绕 sum(p50) 构建的架构，而用户体验到的却是 sum(p99)。经过三到四个步骤后，链条中的 任何 环节掉入其自身尾部概率（tail probability）的可能性就不再微不足道了。经过七个步骤后，这种概率接近于掷硬币。没有任何单项工具的仪表板变红，因为没有任何单项服务表现异常 —— 问题在于没有人负责这种乘法复合（multiplicative composition）效应。

这并不是什么新教训。分布式系统研究人员已经为此撰写了四十年的文章。新鲜的是，每个构建智能体的团队都在最后期限的压力下，痛苦地重新发现这一点。

用户报告 Agent 给出了错误答案。你打开 Trace。模型的推理过程看起来没问题。工具调用全部返回 200 OK。Harness 日志显示没有重试、没有截断、没有异常。然而，答案就是错的。于是你花了接下来的两个小时，将三个具有不同格式、不同时钟的独立日志流缝合在一起，最终发现某个工具针对特定的查询形状静默返回了 {"result": null}，模型将这个 null 合理化为一个听起来合乎逻辑的事实，而 Harness 则愉快地将这个幻觉转发给了用户。这三个层级中的任何一个都没有单独记录任何警报。故障发生在连接处。

这是生产级 Agent 系统中最主要的故障模式，而大多数团队都在使用单层工具进行调试。模型团队归咎于工具。工具团队归咎于模型。平台团队归咎于 Harness。每个人都部分正确，因为 Agent 故障几乎从来不是单一组件的 Bug —— 它是三个组件之间的失配，而每个组件都在不同的“步骤”心理模型上运行。在你的 Trace 基础设施反映这一现实之前，你将不断为披着不同外衣的同类事故买单。

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