作者：Gwen Davis
排版：Alan Wang
大多数多智能体工作流的失败，归根结底源于缺乏结构设计，而不是模型能力不足。了解三种让智能体系统更加可靠的工程模式。

如果你构建过一个多智能体工作流，你很可能见过那种难以解释的失败方式。

系统流程看似完成，智能体也都执行了各自的操作。但在某个环节，总有一些微妙的问题悄然发生。你可能会看到一个智能体关闭了另一个智能体刚刚创建的 issue，或者提交了一项变更，却在下游检查中失败，而它甚至不知道还有这个检查存在。

这是因为，当智能体开始处理彼此相关的任务——例如问题分流、提出变更、运行检查以及创建 pull request——它们就会对状态、执行顺序和验证机制做出隐含的假设。如果没有提供明确的指令、数据格式和接口约定，事情往往不会按你预期的方式发展。

我们在 GitHub 围绕 GitHub Copilot、内部自动化以及新兴的多智能体编排模式开展智能体体验相关工作的过程中发现：多智能体系统的行为，与其说像聊天界面，不如说更像分布式系统。

本文面向正在构建多智能体系统的工程师。我们将梳理它们最常见的失败原因，以及能够提升系统可靠性的工程模式。

什么是多智能体系统，以及如何使用它们

当单个智能体不足以端到端、可靠地解决问题时，团队往往会采用多智能体工作流。但引入多个智能体的同时，也带来了新的故障风险面：共享状态、顺序假设、隐式交接，以及非确定性行为。

我们看到开发者在以下场景中使用多智能体工作流：

• 代码库维护与依赖更新

• 自动化代码质量检查与重构

• 规范驱动的功能实现

• Issue 与 Pull Request 分流

这些场景只有在每一个步骤都被明确化、并受到约束时，才能可靠运行。

1. 自然语言是混乱的，类型化 Schema 才让系统可靠

多智能体工作流往往在早期就失败，因为智能体之间交换的是混乱的自然语言或不一致的 JSON。字段名发生变化、数据类型不匹配、格式漂移，而且没有任何机制强制一致性。

就像在开发初期建立清晰的契约可以帮助团队协作、避免互相踩踏一样，类型化接口和严格的 Schema 会在每一个边界增加结构约束。智能体传递的是可被机器校验的数据，无效消息会快速失败，下游步骤无需再去猜测某个 payload 的含义。

大多数团队会从定义期望智能体返回的数据结构开始：

type UserProfile = {
  id: number;
  email: string;
  plan: "free" | "pro" | "enterprise";
};

这会将调试方式从“查看日志然后猜测问题”转变为“这个 payload 违反了 Schema X”。将 Schema 违规视为契约失败：在错误状态传播之前进行重试、修复或升级处理。

结论： 在多智能体工作流中，类型化 Schema 是基本前提。没有它，其他一切都无法可靠运行。了解 GitHub Models 如何在真实项目中实现结构化、可重复的 AI 工作流。👉

2. 模糊意图会破坏智能体，Action Schema 让意图清晰

即便有了类型化数据，多智能体工作流仍然会失败，因为 LLM 并不会遵循“隐含意图”，它们只遵循“明确指令”。

“分析这个 issue 并帮助团队采取行动”听起来很清楚。但不同的智能体可能会关闭、分配、升级，或什么都不做——每种都合理，却都无法自动化。

Action Schema 通过定义允许的精确动作集合及其结构来解决这个问题。不是每一步都必须结构化，但最终结果必须收敛为一个小而明确的动作集合。

例如，一个 Action Schema 可能是这样：

const ActionSchema = z.discriminatedUnion("type", [
  { type: "request-more-info", missing: string[] },
  { type: "assign", assignee: string },
  { type: "close-as-duplicate", duplicateOf: number },
  { type: "no-action" }
]);

有了这样的定义，智能体必须返回且仅返回一个合法动作。任何其他结果都会验证失败，并被重试或升级处理。

结论： 大多数智能体失败，本质上是动作失败。为了在工作流更早阶段——也就是在指令层面——减少歧义，这份关于如何编写高效自定义指令的指南会很有帮助。👉

3. 松散接口会制造错误，MCP 提供智能体所需的结构

类型化 Schema、受限动作以及结构化推理，只有在被持续强制执行时才有效。否则，它们只是约定，而不是保证。

Model Context Protocol（MCP）就是将这些模式转化为契约的强制执行层。

MCP 为每一个工具和资源定义明确的输入与输出 Schema，并在执行前进行验证。

{
  "name": "create_issue",
  "input_schema": { ... },
  "output_schema": { ... }
}

在 MCP 的约束下，智能体无法随意添加字段、遗漏必填项或跨接口漂移。验证发生在执行之前，从而阻止错误状态进入生产系统。

结论： Schema 定义结构，Action Schema 定义意图，而 MCP 负责强制执行两者。进一步了解 MCP 的工作原理，以及它为何如此重要。👉

多智能体工作流的设计原则

基于我们在 GitHub 构建和运行智能体系统的经验，以下原则有助于在规模化场景下提升多智能体工作流的可靠性：

• 优先面向失败设计

• 校验每一个智能体边界

• 先约束行为，再增加智能体

• 记录中间状态

• 预期重试与部分失败

• 将智能体视为分布式系统，而不是聊天流程

一起迈向更可靠的未来

当结构被明确表达时，多智能体系统才能真正发挥作用。当你引入类型化 Schema、受限动作以及由 MCP 强制执行的结构化接口后，智能体才会开始像可靠的系统组件一样运行。

这种转变既简单又强大：把智能体当作代码，而不是聊天界面。

了解 MCP 如何实现结构化、确定性的智能体与工具交互。👉