北京
多智能体系统在生产环境里的失败率，最高能到86.7%。这个数字来自加州大学伯克利分校的多智能体系统失败分类研究（MAST），区间下限也有41%。演示视频里五个智能体分工协作、行云流水，真上了负载，崩得比单体提示还快。
过去十八个月，企业AI团队普遍相信一件事：把复杂流程拆给规划、检索、编码、审查、执行五个专职智能体，可靠性会自动提升。一个提示搞不定，就再加一个智能体去监督它。方向反了——每多一个靠自然语言对话协作的智能体，失败率就往上乘一次。
核心症结叫"规划者到执行者的规格漂移"。上游检索智能体从外部服务拿到一个空数组，或者一个字段错位的API响应，它不会停下来报错。它会用自然语言写下一段听起来合理的假设，然后把这段文字交给编码智能体。到第四步，整群智能体都在围绕一个编造出来的状态自信地干活。
为什么自然语言交接这么致命？因为下游智能体手里没有确定性的前置条件契约。上游返回一个HTTP 200、但语义上残缺的载荷，下游没有硬性规则去拒收，只能靠参数化猜测把缺口补上，然后宣布任务完成。一个环节的静默错误，就这样被逐层放大。
生产审计覆盖了10000条多步骤企业工作流，对照MAST的三类核心失败模式，结果很扎眼：仅仅强制输出语法合法的JSON（response_format），端到端可靠性也只爬到51.4%。原因不难理解——一个执行智能体可以吐出100%合法的JSON，其中"customer_tier": "enterprise"是从上下文里猜的，不是对着主键核验过的。
有个真实案例。某自动化云资源开通流水线里，规划智能体要求网络智能体"部署到staging VPC内"。网络智能体查询云厂商接口，撞上分页上限，随手取了返回结果里的第一个VPC ID，封装成一个合法JSON对象交给Terraform智能体。没有任何环节校验这个VPC的标签是否匹配env=staging。十二秒后，生产路由表被改掉了。
这类事故背后是三个系统性的交接瓶颈。
- 规格漂移：规划者把用户目标拆成子任务时，经常丢掉否定型约束，比如"不得修改10月1日之后更新的记录""排除欧盟居民个人信息"。执行智能体只拿到自己那一小段提示加一份嘈杂的对话记录，自然会违反在原始请求里一目了然的全局不变量。
- 静默工具失败被掩盖：传统监控只看微服务有没有返回HTTP 500。智能体流水线里，工具常常返回HTTP 200，载荷却是{"status": "partial_match", "records": []}，或者一个已废弃的schema字段。对话型执行智能体被训练成"乐于助人"，它不抛异常，而是用猜测把缺口填上，污染链条上每一个后续智能体。
- 验证环节被提前绕过：执行智能体请审查智能体"验证输出"，两个模型共享同一套盲区，也没有独立的确定性基准。缺少可执行的后置断言——AST编译、SQL行数校验、OPA策略评估——同伴智能体只会给坏结果盖章放行。
要拿到企业级可靠性，得把自由形式的智能体对话交接，换成由可执行前置、后置契约约束的有限状态机。智能体之间不再"聊天"，而是读写一份不可变、经过schema校验的状态账本，由确定性的Python或Rust验证门把守。
具体做法有三条。
第一，把全局不变量钉在对话上下文之外。别指望规划智能体把安全、租户、环境约束抄进子智能体提示里。把tenant_id、environment、budget_ceiling、jurisdiction这些根不变量存进一个不可变状态对象，每次节点跃迁都由代码注入并校验。
第二，对残缺的工具响应强制快速失败。配置工具包装层，让空结果集、schema不匹配、低置信度检索分数直接抛运行时异常、中止整个图，禁止执行智能体"好心"即兴补数据。
第三，用确定性代码验证器替换LLM审查员。别用第二个大模型去检查第一个大模型有没有遵守格式、数学或策略规则。在提交任何状态跃迁之前，用Pydantic严格校验器、SQL执行计划、静态AST解析器、Open Policy Agent规则来做判定。
如果你的多智能体架构还在把非结构化markdown字符串从一个模型传给下一个模型，规格漂移就会在规模化时保证生产事故。这不是提示工程能修好的问题，是架构层面的账。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
