多智能体架构入门指南与核心概念解析

从单一调用大型语言模型（LLM），到构建能够协同工作的多智能体系统，这中间存在显著的工程挑战。本文将深入解析 Multi-Agent 架构的核心理念、主流模式与关键技术实现，帮助你掌握构建高效协作 AI 系统的核心方法。

为什么需要 Multi-Agent 架构？

单一 LLM 在处理复杂任务时，其局限性日益凸显：

• 上下文长度限制：难以承载和处理超长、信息密集的连续任务。
• 单线程执行：无法并行处理任务的不同环节，导致整体效率低下。
• 能力范围有限：单个模型难以同时精通代码生成、网络搜索、数据分析等多个专业领域。
• 系统容错性低：任务链中任一环节出错，都可能导致整个流程失败。

Multi-Agent 架构应运而生，旨在解决上述痛点。其核心思想非常直观：与其依赖一个“全能模型”疲于应付，不如组建一个“专业团队”，将复杂任务进行分解，由多个各司其职的智能体协作完成。

核心架构模式解析

目前，主流的 Multi-Agent 架构主要有两种模式，分别适用于不同的任务场景。

Orchestrator-Worker（编排者-工作者模式）

这是最符合直觉且应用广泛的架构模式。你可以将其类比为一个项目团队：Orchestrator（编排者） 担任项目经理或“大脑”角色，负责理解全局任务、制定计划、分配工作并汇总结果；而 Worker（工作者） 则是各领域的专家或“执行者”，专注于完成自己擅长的具体子任务。

用户请求
↓
[Orchestrator Agent] ← 负责规划、分解、调度
↓ ↓ ↓
[Worker A] [Worker B] [Worker C] ← 代码执行/网络搜索/数据库查询...
↓ ↓ ↓
[Orchestrator Agent] ← 汇总结果、决策下一步
↓
最终响应

这种模式特别适合任务边界清晰、可并行拆分的复杂需求。例如，“调研市场竞品、撰写分析报告、并生成演示PPT”这一任务，可以由研究、写作、设计三个 Worker 并行执行，最后由 Orchestrator 整合交付。

Pipeline（流水线模式）

另一种模式是 Pipeline，即流水线架构。在此模式下，各个 Agent 像工厂流水线上的工人一样串行工作，上一个 Agent 的输出直接成为下一个 Agent 的输入，每一道“工序”都有明确的职责。

Agent A → Agent B → Agent C → 输出
 (研究)   (写作)   (校对)

它非常适合处理那些具有严格先后依赖关系、每一步都需要进行加工处理的工作流。典型例子是数据处理流程：“收集原始数据 → 清洗整理 → 分析建模 → 可视化呈现”。

完整实践案例：开发一个 Todo 应用

理论略显抽象，我们通过一个具体案例来加深理解。假设用户提出需求：“帮我开发一个 Todo 应用”。一个典型的 Multi-Agent 系统协作流程如下：

用户：“帮我开发一个 Todo 应用”
↓
[Orchestrator] 分解为 4 个子任务：
① 需求分析
② 后端开发
③ 前端开发
④ 测试
↓
┌──────────────────────────────┐
│        并行执行 ②③           │
│ [Backend Agent]              │
│ → 工具：write_file, run_cmd  │
│ → 产出：Express API          │
│                              │
│ [Frontend Agent]             │
│ → 工具：write_file           │
│ → 产出：React 组件           │
└──────────────────────────────┘
↓
[Test Agent] 串行执行
→ 工具：run_tests
→ 发现 Bug → 反馈给 Backend Agent
↓
[Orchestrator] 汇总
→ 最终交付

这个案例巧妙融合了两种架构模式：后端和前端开发可以并行进行，体现了 Orchestrator-Worker 模式；而测试环节发现问题后，需要串行反馈给后端修复，这又体现了 Pipeline 模式。在实际项目中，这种混合使用的情况非常普遍。

Sub-Agent 概念详解

理解了 Multi-Agent 的基本架构后，需要厘清一个容易混淆的概念：Sub-Agent。

• Multi-Agent：这是一个架构概念，泛指“多个 Agent 协作完成任务”的系统设计，强调整体形态。
• Sub-Agent：这是一个角色概念，特指在某个上级 Agent 管辖下运行的下级 Agent，强调层级和从属关系。

简而言之：一个有 Sub-Agent 的系统一定是 Multi-Agent 系统，但一个 Multi-Agent 系统不一定非要有明确的 Sub-Agent 层级。

Sub-Agent 的强大之处在于它天然支持递归嵌套，这是构建复杂、可扩展智能体系统的基石。想象一下这样的树状结构：

用户
└─ Orchestrator（顶层 Agent）
   ├─ Research Agent（Sub-Agent）
   │   ├─ Web Search Agent（Sub-Sub-Agent）
   │   └─ Paper Analysis Agent（Sub-Sub-Agent）
   └─ Writing Agent（Sub-Agent）
       ├─ Outline Agent（Sub-Sub-Agent）
       └─ Draft Agent（Sub-Sub-Agent）

在这种结构下，每一层的 Agent 只需管理和协调自己的直接下级，无需了解系统全貌。这种“分而治之”的思想，极大地提升了复杂系统的可维护性和可扩展性。

技术实现：LangGraph Supervisor 动态编排

了解了设计理念，我们来看如何落地。在 LangChain 生态中，来自 LangGraph 的 Supervisor 是实现 Multi-Agent 动态编排的推荐方案。

Supervisor 的工作流程

Supervisor 的核心是一个决策中枢，本身也是一个 LLM 调用。其工作流可概括为：

用户输入
↓
[Supervisor Node] ← LLM 决策路由
↓        ↓        ↓
[Agent A] [Agent B] [Agent C]
↓        ↓        ↓
[Supervisor Node] ← 再次决策：继续？结束？换人？
↓
FINISH

每一轮交互，Supervisor 都会重新审视当前对话状态和任务进展，然后决定下一步该由哪个 Agent 接手，或直接宣告任务完成。

完整代码示例：研究+编码双 Agent 系统

以下是一个研究（Research）与编码（Coder）双 Agent 系统的实现示例：

import { createReactAgent } from "@langchain/langgraph/prebuilt";
import { StateGraph, MessagesAnnotation } from "@langchain/langgraph";
import { ChatAnthropic } from "@langchain/anthropic";
import { tool } from "@langchain/core/tools";
import { z } from "zod";
import { HumanMessage, SystemMessage } from "@langchain/core/messages";

const llm = new ChatAnthropic({ model: "claude-opus-4-5" });

// ── 1. 定义各 Sub-Agent 的工具 ──────────────────────────
const searchTool = tool(async ({ query }) => {
  return `搜索"${query}"的结果：找到3篇相关文章...`; // 替换为真实搜索
}, {
  name: "web_search",
  description: "搜索互联网信息",
  schema: z.object({ query: z.string() }),
});

const writeCodeTool = tool(async ({ task }) => {
  return `// 生成的代码\nconsole.log("${task}");`; // 替换为真实实现
}, {
  name: "write_code",
  description: "编写代码",
  schema: z.object({ task: z.string() }),
});

// ── 2. 创建 Sub-Agent（用 createReactAgent）─────────────
const researchAgent = createReactAgent({
  llm,
  tools: [searchTool],
  messageModifier: new SystemMessage("你是研究专家，负责搜集和分析信息。"),
});

const coderAgent = createReactAgent({
  llm,
  tools: [writeCodeTool],
  messageModifier: new SystemMessage("你是编程专家，负责编写高质量代码。"),
});

// ── 3. 将 Sub-Agent 包装成 Graph Node ───────────────────
async function researchNode(state) {
  const result = await researchAgent.invoke(state);
  // 给消息打上来源标记，Supervisor 可以感知谁做了什么
  const lastMsg = result.messages.at(-1);
  lastMsg.name = "ResearchAgent";
  return { messages: result.messages };
}

async function coderNode(state) {
  const result = await coderAgent.invoke(state);
  const lastMsg = result.messages.at(-1);
  lastMsg.name = "CoderAgent";
  return { messages: result.messages };
}

// ── 4. 创建 Supervisor ───────────────────────────────────
const members = ["ResearchAgent", "CoderAgent"];
const supervisorPrompt = `你是一个任务调度 Supervisor，管理以下 Agent 团队：
${members.map(m => `- ${m}`).join("\n")}

根据当前对话，决定下一步由谁来执行，或者任务已完成返回 FINISH。
规则：
- 需要信息收集/研究 → ResearchAgent
- 需要编写/修改代码 → CoderAgent
- 任务已全部完成 → FINISH

只返回一个名字：${[...members, "FINISH"].join(" | ")}`;

const routeSchema = z.object({
  next: z.enum(["ResearchAgent", "CoderAgent", "FINISH"]),
});

async function supervisorNode(state) {
  const response = await llm.withStructuredOutput(routeSchema).invoke([
    new SystemMessage(supervisorPrompt),
    ...state.messages,
  ]);
  return { next: response.next };
}

// ── 5. 构建 StateGraph ───────────────────────────────────
const AgentState = MessagesAnnotation.spec({
  // 扩展状态：记录路由决策
  next: { value: (x, y) => y ?? x, default: () => "ResearchAgent" },
});

const graph = new StateGraph(AgentState)
  .addNode("Supervisor", supervisorNode)
  .addNode("ResearchAgent", researchNode)
  .addNode("CoderAgent", coderNode)
  // Supervisor → 动态路由到对应 Agent 或结束
  .addConditionalEdges("Supervisor", (state) => state.next, {
    ResearchAgent: "ResearchAgent",
    CoderAgent: "CoderAgent",
    FINISH: "__end__",
  })
  // 每个 Agent 完成后回到 Supervisor
  .addEdge("ResearchAgent", "Supervisor")
  .addEdge("CoderAgent", "Supervisor")
  // 入口
  .addEdge("__start__", "Supervisor");

const app = graph.compile();

// ── 6. 运行 ─────────────────────────────────────────────
const result = await app.invoke({
  messages: [new HumanMessage("研究 Fastify 框架，然后写一个最简单的示例")]
});
console.log(result.messages.at(-1).content);

执行过程追踪

以上述代码为例，当输入“研究 Fastify，然后写示例”时，系统的执行流程如下：

输入：“研究 Fastify，然后写示例”
↓
[Supervisor] → 判断：需要先研究 → “ResearchAgent”
↓
[ResearchAgent] → 调用 web_search 工具搜索 Fastify 相关资料
                → 完成，回到 Supervisor
↓
[Supervisor] → 判断：已有资料，需要写代码 → “CoderAgent”
↓
[CoderAgent] → 根据研究结果调用 write_code 工具生成示例
             → 完成，回到 Supervisor
↓
[Supervisor] → 判断：任务完成 → “FINISH”
↓
输出最终结果

Supervisor 的三大核心优势

使用 Supervisor 模式进行编排，带来了几个显著的工程优势：

1. 动态路由：Supervisor 在每一轮都重新决策，可以根据上一个 Agent 的输出灵活调整执行路径，而非预先设定死板流程。这意味着如果 ResearchAgent 返回的资料不足，Supervisor 可以决定让它再次补充。

2. 自动循环与重试：当某个 Agent 执行出错或结果不满足要求时，Supervisor 可以轻松地将任务重新派发给同一个或另一个 Agent，天然支持了重试逻辑，无需编写额外的错误处理代码。

3. 状态透明共享：所有 Agent 共享同一个 messages 状态数组，每个 Agent 都能看到完整的对话历史上下文。数据在 Agent 间的传递是自动、透明的，无需手动拼接和转发。

关键设计原则与最佳实践

在动手搭建 Multi-Agent 系统时，遵循以下工程原则至关重要：

单一职责原则：这是最重要的原则。每个 Agent 应只专注于一件事，其工具集也应尽量精简。职责越清晰，Supervisor 的路由决策就越准确，Agent 的输出也越可预期。

明确的输入输出契约：Agent 之间传递的消息格式需要统一。在上面的示例代码中，我们给消息打上 name 标记，就是一种简单的契约——Supervisor 通过 name 字段就能知道消息来源，从而做出下一步判断。

防止无限循环：在生产环境中，必须为 Supervisor 设置最大迭代轮次（recursionLimit），避免多个 Agent 互相推诿或陷入死循环。

const app = graph.compile();
const result = await app.invoke(input, { recursionLimit: 20 });

错误隔离：某个 Worker 或 Sub-Agent 内部发生的异常，不应导致整个图（Graph）崩溃。推荐做法是在 Node 函数内部进行 try/catch，将错误信息作为一条普通消息返回给 Supervisor，由它来决定是重试、换人还是报错。

总结与对比

总而言之，Multi-Agent 远不止是“多调用几次 LLM”那么简单，它是一套完整的、借鉴了传统软件工程思想的架构范式。为了更清晰地对比，我们可以看下面这个表格：

如今，在生产环境中部署的智能体软件，几乎都将 Multi-Agent 架构作为标配，以解决多任务、长流程复杂任务的效率与可靠性问题。典型的例子如 Cursor 编辑器中的智能体，就利用了 Sub-Agent 机制来更好地处理大型开发任务。

理解并掌握这套架构范式，你就获得了构建那些“真正能独立完成复杂工作的 AI 系统”的基础框架。这不仅是技术的组合，更是一种解决问题的思维方式。