多智能体协作卡死难题：交接规则缺失才是元凶

当智能体互相“ghosting”：一个真实的流水线故障

一位开发者在 Reddit 上分享了自己搭建多智能体（multi-agent）流水线的踩坑经历，这个案例几乎浓缩了当下 AI Agent 工程化的核心痛点。

他的设想很理想：一个规划智能体（planning agent）、一个编码智能体（coding agent）和一个审查智能体（review agent）按顺序交接工作，整条流水线无需人工干预即可自动流转。然而现实却是——审查智能体经常陷入无限等待，因为编码智能体发出的“完成”信号在每一次运行中的结构都不一样。

这种“智能体中途互相放鸽子”（ghosting each other mid-pipeline）的现象，正是许多团队从 Demo 走向生产环境时撞上的第一堵墙。

根因不在智能体本身，而在交接契约

帖主对故障做了根因分析，归纳出两个关键问题，这两点值得每个做 Agent 编排的人记在笔记本上。

缺失共享的完成状态 Schema

第一个根因是：各个智能体之间没有一套共享的完成状态模式（shared schema for completion status）。编码智能体每次表示“我做完了”的方式都不一致——有时是一段自然语言，有时是某种结构化字段，有时甚至语义模糊。下游的审查智能体无法可靠地解析这个信号，自然就会一直干等。

这暴露了一个被低估的事实：在多智能体系统里，智能体之间传递的不只是“内容”，更是“状态”。如果状态没有被明确定义成机器可读的契约，交接就变成了一场碰运气的猜谜。

Schema（模式）在这里指的是一份对数据结构和字段语义的正式约定，类似于接口文档或数据库表结构定义。在多智能体系统中，完成状态 Schema 通常会规定：用哪个字段表示任务状态（如 status: "completed" | "failed" | "pending"）、错误信息放在哪里、输出产物如何引用等。常见的实现方式包括 JSON Schema、Pydantic 模型（Python）或 TypeScript 类型定义。没有这层约定时，大语言模型生成的输出天然具有不确定性——同一个意图可能被表达为 {"done": true}、"任务已完成" 或 {"result": "finished"}，三种格式对人类都可读，但对依赖固定字段的下游程序来说则完全不同，这正是审查智能体陷入无限等待的直接原因。

把异步运行时当成同步来处理

第二个根因更隐蔽：委派逻辑（delegation logic）假设了同步响应，但实际运行时却是异步的。当代码按照“调用后立即拿到结果”的思路来写，而底层却以异步方式执行时，等待逻辑就会变成一个永远不会被满足的开放式阻塞（open-ended wait）。

帖主坦言，这个问题花了“难为情地久”才定位到。这恰恰说明异步与同步语义的错配，在分布式 Agent 系统中极难通过直觉发现。

同步（synchronous）调用意味着调用方会阻塞等待，直到被调用方返回结果；异步（asynchronous）调用则是调用方发出请求后立即继续执行，结果通过回调、Promise、事件或轮询等机制在未来某个时刻获取。在 Agent 编排框架（如 LangGraph、AutoGen、CrewAI 等）中，每个智能体的执行往往是独立的异步任务，调用外部 API、执行代码或等待人工审核都会引入不确定的延迟。如果编排代码以同步思维写成——即假设"调用编码智能体后下一行就能读到它的输出"——那么在异步运行时中，这个"下一行"实际上会在结果就绪之前就被执行，导致读取到空值或触发永久性阻塞。这类 bug 在本地单线程测试中往往不会出现，只在并发或分布式部署时才暴露，是多智能体系统中最难复现和定位的一类问题。

两步修复：状态契约 + 超时重试层

针对上述根因，作者做了两项关键改动，思路清晰且可复用。

其一，在智能体之间增加显式的状态契约（explicit state contracts）。不再依赖各智能体“自由发挥”地汇报完成情况，而是定义一套统一的、结构化的状态格式。只要所有智能体都遵守同一份契约，下游就能确定性地判断“上游到底做完了没有”。

其二，引入超时与重试层（timeout/retry layer），替代开放式等待。与其让审查智能体无限期地挂起，不如设定一个合理的超时阈值：超时后触发重试或降级处理。这相当于给整条流水线装上了“熔断器”，避免单点阻塞拖垮全局。

这两项改动背后的工程哲学是一致的——用确定性的规则取代隐式的假设。

超时与重试（timeout/retry）机制在分布式系统工程中有成熟的模式参考。超时防止单点无限阻塞，通常分为连接超时和读取超时两类；重试策略则包括立即重试、固定间隔重试和指数退避（exponential backoff）三种，后者在处理下游服务过载时尤为重要。熔断器（Circuit Breaker）模式更进一步：当某个智能体连续失败超过阈值后，熔断器会暂时"断开"对它的调用，让系统快速失败而非持续等待，待恢复后再自动重试。这些模式在微服务领域已广泛应用，但在 Agent 编排场景中仍属于需要开发者主动实现的基础设施，而非大多数框架的开箱即用功能。

核心教训：编排的脆弱源于未定义的交接规则

帖主总结出的核心教训一针见血：编排的崩溃不是因为智能体本身不行，而是因为交接规则没有被定义（undefined handoff rules）。

这个观点对整个 AI Agent 领域都有启发意义。很多团队在调优时会反复折腾单个智能体的 Prompt、模型选择和能力边界，却忽视了智能体之间那层“胶水”——交接协议、状态同步、错误处理。而生产环境中的真正故障，往往就发生在这些被忽视的接缝处。

换句话说，多智能体系统的可靠性，更多取决于协议设计而非个体智能。一个由三个“平庸但契约清晰”的智能体组成的系统，可能远比三个“聪明却各说各话”的智能体稳定得多。

如果你的智能体开始互相放鸽子，先查什么？

帖主最后抛出一个开放问题：如果你的智能体在流水线中途开始互相“ghosting”，你会首先检查什么？

结合这个案例，几个值得优先排查的方向包括：

• 交接信号是否有统一 Schema：各智能体对“完成/失败/待处理”的表达是否一致、是否机器可解析。
• 运行时是同步还是异步：等待逻辑是否与底层执行模型匹配，是否存在永远不会被满足的阻塞。
• 是否存在超时兜底：所有的等待点是否都有超时与重试机制，避免开放式挂起。
• 状态是否可观测：当某个智能体卡住时，能否快速定位它在等待什么、上游发了什么。

对于正在把 Agent 系统推向生产的开发者而言，这个真实故障提供了一份低成本的检查清单。多智能体编排的下一个瓶颈，大概率不在模型能力，而在工程契约。