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

在值班文档的表格上，搜索工具的错误率为 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 流水线而不根据随机系统进行调整时，所发生的最温和的情况。

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

当一个多智能体系统开始出现奇怪的行为——给出不一致的答案、丢失任务追踪、做出与早期推理相矛盾的决策——本能反应是责怪模型。调整提示词，换一个更强的模型，添加更多上下文。

真正的原因往往更平凡，也更危险：并发写入导致的共享状态损坏。两个智能体读取同一块内存，都计算出更新，其中一个默默地覆盖了另一个。结果状态在技术上是有效的——没有异常抛出，没有模式违规——但在语义上是错误的。之后读取它的每一个智能体都在对错误信息进行正确的推理。

这种故障模式在单个操作层面是不可见的，在测试环境中难以复现，仅通过查看输出几乎无法与模型错误区分开来。O'Reilly 2025年关于多智能体内存工程的研究发现，36.9%的多智能体系统故障源于智能体间的不对齐——智能体在对共享信息的不一致视图上运行。这不是一个理论上的顾虑。

你的负载均衡器将一个传入的智能体请求分配给副本 3。但用户的对话历史存储在副本 7 的内存中。副本 3 完全不知道过去六轮发生了什么，于是它从头开始，让用户一头雾水，你的值班工程师在凌晨 2 点被叫醒。你启用了会话粘滞。现在该用户的所有请求永远路由到副本 7。你用一个正确性问题换来了一个可扩展性天花板。

就在这一刻，团队意识到：AI 智能体的"水平扩展"和 Web 服务器的水平扩展根本不是同一个问题。修复方式不同，而那些看似直接的路径会以可预见的方式失败。

一个团队交付了一个文档处理智能体（agent）。它在开发环境中表现完美：读取文件、提取数据、将结果写入数据库，并发送确认 webhook。他们运行了 50 个测试用例，全部通过。

部署两周后，在 100 个并发智能体实例运行时，数据库中出现了 40,000 条重复记录，三个下游服务收到了数千个虚假的 webhook，一个共享配置文件被两个同时运行的智能体各覆盖了一半。

智能体本身没有出错。系统崩溃是因为没有任何一个独立的智能体测试曾被要求与其他智能体共同处于同一个运行环境中。

大多数分布式追踪方案在引入 Agent 之前都运作良好。一旦系统中出现 Agent A 跨微服务边界调用 Agent B——Agent B 调用工具服务器、工具服务器再查询向量数据库——原本连贯的端到端视图就会碎片化为互不相连的片段。追踪后端展示的是一个个孤立的操作，而你失去的是因果链：为什么某件事发生了，哪个用户请求触发了它，以及那 800 毫秒究竟消耗在了哪里。

这不是监控配置问题，而是上下文传播架构问题。它有着特定的技术形态，大多数团队都是在付出代价后才意识到这一点。

这种场景每次都如出一辙。你的智能体正在预订酒店房间，支付API调用返回200后、确认信息存储之前发生了网络超时。智能体框架发起重试，支付再次执行，客户被扣了两次款。支持团队升级处理，某位高管说AI"幻觉出了重复扣款"——这种说法是错的，但听起来有道理，因为没人愿意承认他们的重试逻辑从一开始就是坏的。

这不是AI问题，而是分布式系统问题——被AI层全盘照搬，却没有带来分布式系统工程师几十年苦心钻研出的应对之道。标准的智能体重试逻辑假设操作是幂等的，而大多数工具调用并非如此。

每个事件流系统最终都会将同一条消息投递两次。网络抖动、Broker 重启、偏移量提交失败——至少一次投递不是 Bug，而是契约。传统消费者能够优雅地处理这种情况，因为它们是确定性的：处理同一事件两次，得到相同的结果，写入相同的记录。第二次写入是一个空操作（no-op）。

LLM 不是确定性处理器。相同的提示词加上相同的输入，每次运行都会产生不同的输出。即使设置了 temperature=0，浮点运算、批次组合效应以及硬件调度的差异也会引入方差。针对"确定性" LLM 设置的研究发现，在自然发生的多次运行中，准确率差异高达 15%，最优与最差性能之间的差距甚至达到 70%。至少一次投递加上非确定性处理器，并不会给你带来至多一次的行为，只会带来不可预测的行为——这是一场蓄势待发的生产环境危机。

大多数构建多步 agent 管道的工程师会在第一次生产故障后约两周发现同一个问题：他们在 API 网关设置了 5 秒超时，但 agent 管道有四跳，而整个系统的行为就好像根本没有超时一样。第三跳的 agent 不知道上游调用方三秒前就已放弃等待，它继续运行、继续调用工具、继续生成 token——而用户早已离开。

这不是配置错误，而是结构性问题。延迟约束默认不会跨 agent 边界传播，主流编排框架也没有任何一个让截止时间传播变得容易。结果是一类看起来像延迟问题、实则是上下文传播问题的故障。