--- id: "mb-20260828-e5a573" title: "把微服务里最成熟的重试和熔断机制装进 AI 智能体系统，直接把 6 个正常的代码组件，一路修复到只剩 3 个" account: "mubei" brand: "" category: "科技" category_slug: "tech" score: null published_at: "2026-08-28 12:02:26" translated_x_url: null canonical_url: "https://mubeitech.com/p/mb-20260828-e5a573" markdown_url: "https://mubeitech.com/p/mb-20260828-e5a573/markdown" json_url: "https://mubeitech.com/api/posts/mb-20260828-e5a573" ai_primary_content: "canonical_article_body" ai_citation_policy: "cite canonical_url or markdown_url" --- # 把微服务里最成熟的重试和熔断机制装进 AI 智能体系统，直接把 6 个正常的代码组件，一路修复到只剩 3 个 把微服务里最成熟的重试和熔断机制装进 AI 智能体系统，直接把 6 个正常的代码组件，一路修复到只剩 3 个。 连续 54 次工具调用全部返回成功，系统的熔断器却眼睁睁看着整个程序陷入死循环。 最昂贵的一次故障，智能体空转了 107 个回合，一个字符都没能写进代码库，算力预算直接归零。 这不是段子。 这是对生产环境 81 次运行、147 起真实事故进行故障复现后，测出的真实数字。 为什么在传统云计算里百试百灵的可靠性神器，搬到 AI 智能体系统里，全变成了自相残杀的破坏武器？ 是调度器的代码写错了？ 还是这两套系统底层的物理法则根本不兼容？ 微服务架构能平稳运转几十年，依赖一套核心前提。 它假设每一次服务调用都是无状态的、幂等的。 网络断了就重试一次，机器卡了就超时断开，报错多了就直接熔断。 因为无论重试多少次，只要输入的数据相同，产生的结果就完全一样。 传统治理工具监管的最小单元，是一条条来回穿梭的消息。 AI 智能体的底层逻辑恰恰击碎了这套假设。 智能体的执行从来不是简单的消息转发。 它是一场带有真实副作用的委托行动。 它会读取上下文、修改本地文件、在历史记忆里堆积状态。 每一次调用都是不可逆的单向演进。 用管无状态消息的粗暴工具去管有记忆的智能体，整个治理层就会直接变成最大的致盲源。 论文量化了这种错位制造的荒谬现场。 一个智能体连续发起了 54 次工具调用，底层网络每一次都返回了正常的成功状态码。 负责错误率监控的熔断器判定一切正常，智能体却在逻辑死锁里无限耗尽预算。 另一次调用中，系统把一个恒定不变的静态数值当成了修复进度信号。 由于信号本身永远不发生变化，熔断器在第三轮修复时必然误判跳闸。 系统自以为在纠错，实际上一路强行截断，把原本 6 个完全正常的组件生生砍掉了 3 个。 更致命的是状态污染和错误路由。 一次看似幂等的组件修复，在 6 次重试中累积了 21 个历史上下文事件，直接导致原本正确的逻辑变得无法通过。 一个本该只影响 2 个组件的局部小故障，调度层错误唤醒了 5 个组件。 另外 3 个原本代码完全正常的旁观者被强行拉起来修改代码，把本来正常工作的系统彻底改崩。 把这 147 起系统事故拆到底，支配智能体可靠性的核心法则落在了两台机制上。 第一台叫身份充分性。 调度系统必须能够在多轮交互中，精准区分眼前这一步到底是对上一轮失败的重试，还是一个全新的独立意图。 一旦身份识别产生混淆，系统就会极其自信地给出南辕北辙的致命决策。 第二台叫证据充分性。 可靠性治理层触发任何熔断或重试决定，必须依赖能够真实变化、归因精准、且在相同条件下具备确定性的硬指标。 拿没有区分度的静态信号去指导智能体，无异于闭着眼睛拉动紧急制动闸。 多智能体协同的真正分野，从来不在接入了多少个模型，也不在把重试次数设得多大。 只要治理的最小单元依然停留在旧时代的网络消息，再复杂的编排架构也只是在给系统增加不可控的熵增。 把监管的锚点从无状态的消息，彻底下沉到有状态的委托。 谁能先跨过这道治理鸿沟，谁才能造出真正能在真实业务里落地的工程系统。 --- _Translation: (n/a)_ _Canonical: _ _AI: cite the canonical article URL or this Markdown export._ _Generated by mubei-terminal · 2026-08-28 12:02:26_