A 团队的智能体宣传其成功率为 99%。B 团队的智能体也宣传 99%。调用这两者的全新联合工作流在状况良好时成功率为 98%，而在状况不佳时仅为 96% —— 负责该联合工作流的团队现在成了两个他们不拥有、无法在本地复现、且未编写评估集的系统的事实上的 SRE。每个上游团队都达到了其 SLO（服务水平目标）。但复合产品却未达标。边界正确一侧的报警器却始终保持沉默。
这是独立失败率的数学问题，自从组织开始允许智能体相互调用以来，它就一直潜伏在显而易见的地方。五个可靠性为 99% 的组件会给你带来 95% 的端到端可靠性。十个组件则会降至 90%。一个每步成功率为 95% 的 20 步流程，其最终成功率仅为 36% —— 超过一半的操作在完成前就会失败。当一个工作流链接了 50 个组件时 —— 一旦企业级智能体开始调用子智能体，再由子智能体调用工具智能体，这种情况并不罕见 —— 一个每个环节都“99% 可靠”的系统，在大约十次请求中就会失败四次。
研究人员在分析了超过 150 个任务中的五个流行多智能体框架后，发现失败率在 41% 到 87% 之间，其中排名前三的失败原因是：步骤重复、推理与行动不匹配，以及对终止条件的忽视 —— 观察发现，与单智能体基准相比，非结构化的多智能体网络会将错误放大高达 17 倍。这其中的数学逻辑并不深奥。问题在于，组织的 SLO 表、仪表板、轮值安排和 PRD 仍然是以单个智能体为单位进行定义的。
单跳谬误
当微服务网格（Microservice Meshes）还是新鲜事物时，每个团队都以同样的方式吸取了同样的教训：边缘侧 200 ms 的 p95 延迟目标意味着每个下游跳转（Hop）都必须分摊该预算的一部分，而拥有面向用户端点的团队必须负责具体的切分工作。一个实际的拆解可能是：为 TLS 和边缘分配 20 ms，为应用逻辑分配 70 ms，为缓存和数据库分配 80 ms，并为序列化和 GC 留出 30 ms 的余量。SRE 社区花了十年时间构建仪表板、链路追踪（Tracing）和告警，以展示每次跳转对最终用户指标的贡献 —— 这些方法包括数学推导出的下游分配方案、显示哪个跳转突然变慢的堆叠条形图，以及指明缓慢 Span 名称的分布式追踪。
智能体网格继承了相同的形态，却没有任何积累了十年的工具支撑。智能体规格表上的 99% 这一数字几乎总是在独立运行的情况下测得的：一个基准测试运行、一个精心挑选的评估集，或者一个友好的分布，这些与上游调用者实际发送的提示词（Prompts）毫无共同之处。当联合工作流停止工作时，上游团队会向下游团队提交工单。下游团队运行其独立评估，发现 99% 的数字依然是 99%，然后关闭工单。而客户看到的依然是 Bug。
解决方法不是“要求下游智能体提供更高的 SLO”。解决方法与微服务学到的一样：为每一跳分配一个预算 ，以联合工作流实际关心的指标为单位，配以显示每跳贡献的仪表板，以及在单跳出问题前就针对复合系统 触发的告警。
逐跳可靠性预算
直接借用微服务的操作手册。定义联合工作流的可靠性目标 —— 假设为 95% 的端到端成功率 —— 并在智能体链条中进行分解。一个需要 95% 成功率的四跳链条既可以被均匀切分（每一跳承担 1.27% 的失败预算，即每跳达到约 98.7%），也可以根据团队拥有更多余量的环节进行加权。一个组织只能做到 96% 的环节会成为已知约束，从而收紧其他所有环节的预算。而一个拥有 99.5% 余量的环节则可以为下游更艰难的环节释放预算。
必须落地的纪律不是电子表格，而是执行 。预算只有体现在以下三个地方才是真实的：
复合 SLO 拥有自己的仪表板和告警，独立于任何单个智能体的 SLO。
每跳预算不仅出现在下游所有者的仪表板上，也出现在上游调用者 的仪表板上。
复合系统的错误预算消耗率（Burn-rate）告警触发速度要足够快，以便在每跳所有者察觉到自己的指标正常之前，就启动事件处理程序。
如果没有这三点，逐跳预算就只是一篇没人会打开的 Notion 页面。有了它们，联合工作流的所有者就能拥有与 SRE 团队在结账端点变慢时相同的态势感知能力。
命名调用者可以绕过的失败模式
微服务拥有 HTTP 状态码。503 意味着重试，422 意味着停止并显示校验错误，401 意味着刷新凭据。调用者可以针对这些状态编写代码，因为契约是确定的。
平均而言，智能体调用完全不具备这些。下游智能体可能会拒绝请求（通过文字叙述）、抛出工具执行错误（带有没人解析的堆栈追踪）、超时（在垂直上游自身的截止时间触发后无声无息地发生），或者返回格式错误的结构化输出，导致两个堆栈帧之后的上游解析器崩溃。上游调用者没有清晰的方法来区分“暂时的，重试”、“你的输入有误，不要重试”还是“我根据政策拒绝，你永远不会成功”。因此，上游只能重试所有操作，这既增加了费用，又使失败模式恶化 —— 这是生产环境多智能体事后分析中反复出现的发现。
智能体之间的契约层必须明确命名这些失败模式。具体而言：
一个类型化的错误信封 —— refusal、tool_error、timeout、schema_violation、policy_block —— 由下游智能体以结构化的方式发出，而不是混入自由格式的字符串中。
由下游智能体拥有的针对每种错误类型的重试策略提示，这样上游调用者就无需进行逆向工程。
记录每种错误类型含义及调用者应采取措施的逐跳运行手册（Runbook） —— 相当于智能体领域的“当结账返回 503 时该怎么办”。
2025 年出现的 A2A 协议开始将其中一些内容正式化 —— 类型化的任务状态、结构化的制品（Artifacts）、广为人知的智能体发现端点、基于 HTTPS 的 JSON-RPC —— 采用该协议的组织意识到，其大部分价值并不在于线路格式（Wire Format） 。而在于终于有人在某个地方写下了失败模式究竟是什么。
针对边缘的评估，而非仅仅针对智能体 多智能体系统中最常见的评估模式也是最具误导性的：每个团队针对自己的智能体运行评估，发布分数，并假设联合工作流的效果是这些分数的“与（AND）”操作。事实并非如此。联合工作流的分布取决于上游智能体实际发送的内容，而这几乎从未是下游智能体评估集所提取的分布。下游团队针对意图分类明确的干净查询分布构建了评估；而上游智能体提供给他们的则是其自身 LLM 输出的混乱、部分重新格式化、偶尔违反 Schema 的结果。
针对边缘（per-edge）的评估是对“握手”过程的评分：在上游智能体的实际输出分布下，下游智能体是否仍能达到其目标？这比针对单个智能体的评估更难设置，因为它需要捕获真实的客流数据并针对下游进行回放——但这是捕捉智能体网格（agent meshes）中最昂贵 Bug 类别的唯一评估方式，即下游智能体在隔离状态下表现良好，但在组合状态下却出现崩溃。
版本矩阵测试模式（version-matrix testing pattern）是这种评估的自然延伸。任何未经明确共同测试的智能体版本组合都是未经测试的。当 A 团队将其模型从即将弃用的快照升级到新快照时，针对边缘的评估必须针对每个消耗其输出的下游重新运行——即使 A 团队的独立评估显示为绿色，即使 B 团队没有发布任何新内容。破坏并不发生在任何一个智能体内部。它发生在接缝处。
将 Schema 版本化作为“破坏性”与“增量性”的分界线 REST API 在二十年前学到的版本管理规范同样适用于智能体的输出 Schema，而大多数组织正在通过惨痛的教训重新学习这一点。类似于语义化版本（semver）风格的变更分类——破坏性（breaking）与增量性（additive）——必须成为智能体部署流程中首要考虑的部分：
破坏性变更 ：重命名字段、删除字段、更改类型、更改允许的枚举值、收紧校验规则。增量性变更 ：添加可选字段、扩展枚举、放宽校验规则。 破坏性变更带有一个弃用窗口（deprecation window）和 contract_version 的提升，以便下游消费者进行锁定。增量性变更则可以自由发布。当一个破坏性的 Schema 变更在没有弃用条目的情况下发布时，能使其失败的 CI 门控只需要五行 Lint 代码——而这正是“上游调用者的解析器在凌晨 3 点崩溃”与“上游调用者有两个月时间进行迁移”之间的区别。
架构上的认知很小但至关重要：智能体的结构化输出是一个公共 API。它具有任何公共 API 都会遇到的合约稳定性问题。请像对待公共 API 那样对待它。
共享的事故频道与确定责任人的耗时 (time-to-owner) 当联合工作流降级时，必须迅速完成两件事：必须有人知道它降级了，并且必须有正确的人知道该由哪一环负责。确定责任人的耗时（Time-to-owner）——即从“事故开启”到“拥有故障部件的团队进入现场”的挂钟时间——在这里是一个被低估的指标。在跨团队的智能体依赖中，确定责任人的耗时可能会延长到数小时，因为值班（on-call）轮换是按智能体范围划分的，而没有人为接缝处负责值班。
解决办法是操作层面的，而非架构层面的。为跨团队智能体依赖建立一个共享的事故频道，上游和下游的所有者都订阅其中。为两个智能体之间的“边缘”建立一个服务目录条目，并指定负责人。建立一个定期的评审机制，两个团队在任何一方发布模型升级之前，每月共同查看针对边缘的评估和针对边缘的 SLO。
这听起来很繁重，直到你亲眼目睹一个持续 72 小时的事故在三个团队之间踢皮球，每个团队都运行了自己的独立评估，看到自己的指标是绿色，然后各自关闭了工单。升级延迟不是人的问题。这是一个伪装成人的问题的系统问题——各团队之间没有共享依赖路径的当前视图、针对边缘的合约或触及接缝的近期变更。
架构上的认知 智能体对智能体的组合具有微服务网格的所有一致性、延迟和可靠性成本——但却没有微服务积累了十年的工具链。尚未在智能体之间建立 SLA 层的组织，将会以惨痛的方式发现独立故障率的数学规律。通常是在旗舰级工作流上线三个月后，此时综合成功率已悄然从“我们在演示日达到了目标”漂移到“我们每天都无法达到目标，而没有人的独立仪表盘能发现这一点”。
必须到位的四个组成部分——带有综合告警的针对每一环的可靠性预算、定义了失败模式的类型化合约层、对握手过程进行评分的针对边缘的评估，以及具有破坏性与增量性规范的版本化 Schema——这些并不陌生。它们正是每个微服务组织在 2014 年至 2020 年间构建的相同四件套。唯一的新鲜事是它们现在适用于智能体了，而今天发布智能体网格的组织大多像是在 2014 年那样运营：每个团队都对自己的指标充满信心，综合效果却在悄悄流失，直到客户投诉线程超过一百条回复时，才有人看向接缝处。
领先于此的团队正在做一件具体的事情。他们将两个智能体之间的边缘视为一个由人拥有的资产——不是某人 PRD 中顺带提到的一句话，不是某人评估中的隐式假设，也不是没人打开的 Notion 文档。一个负责人、一份预算、一个告警、一个合约、一个评估。五样东西。一旦这五样东西存在，数学就不再是意外，而是变成了预算项，而这正是它从一开始就该存在的地方。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
