Skip to main content
多智能体系统将复杂的应用分解为多个专门的智能体，这些智能体协同工作以解决问题。与依赖单个智能体处理每个步骤不同，多智能体架构允许您将更小、更专注的智能体组合成一个协调的工作流程。 多智能体系统在以下情况下很有用：
  • 单个智能体拥有太多工具，难以做出关于使用哪个工具的明智决策。
  • 上下文或记忆量过大，单个智能体难以有效追踪。
  • 任务需要专业化（例如，规划者、研究人员、数学专家）。

​
多智能体模式

模式工作原理控制流程示例用例
工具调用一个 监督者 智能体调用其他智能体作为 工具。这些“工具”智能体不会直接与用户交流——它们只是运行自己的任务并返回结果。集中式：所有路由都通过调用智能体进行。任务编排、结构化工作流程。
交接当前智能体决定将 控制权 转交给另一个智能体。活跃的智能体发生变化，用户可能继续直接与新的智能体交互。去中心化：智能体可以改变活跃的智能体。多领域对话、专家接管。

Tutorial: Build a supervisor agent

学习如何使用监督者模式构建个人助理，其中中央监督智能体协调专门的工人智能体。 本教程演示了以下内容：
  • 为不同的领域（日历和电子邮件）创建专门的子智能体
  • 将子智能体包装为集中编排的工具
  • 为敏感操作添加人工审核

​
选择模式

问题工具调用交接
需要集中控制工作流程吗？✅ 是❌ 否
想要智能体直接与用户交互吗？❌ 否✅ 是
专家之间复杂、类似人类的对话？❌ 有限✅ 强
您可以混合这两种模式——使用交接进行智能体切换，并让每个智能体将子智能体作为工具调用以执行特定任务。

​
自定义智能体上下文

多智能体设计的核心是上下文工程——决定每个智能体能看到哪些信息。LangChain让您能够精细控制：
  • 每个智能体接收到的对话或状态的哪些部分。
  • 为子智能体定制的专业提示。
  • 中间推理的包含/排除。
  • 根据每个智能体自定义输入/输出格式。
您系统的质量高度依赖于上下文工程。目标是确保每个智能体都能访问到执行其任务所需的正确数据，无论它是作为工具还是作为活跃的智能体。

​
工具调用

在工具调用中，一个智能体（即“控制器”）将其他智能体视为在需要时调用的工具。控制器负责协调，而工具智能体执行特定任务并返回结果。 流程：
  1. 控制器接收输入并决定调用哪个工具（子智能体）。
  2. 工具智能体根据控制器的指令执行其任务。
  3. 工具智能体将结果返回给控制器。
  4. 控制器决定下一步操作或结束。
Agents used as tools are generally not expected to continue conversation with the user. Their role is to perform a task and return results to the controller agent. If you need subagents to be able to converse with the user, use handoffs instead.

​
Implementation

Below is a minimal example where the main agent is given access to a single subagent via a tool definition: CODE_BLOCK_1 In this pattern:
  1. The main agent invokes 调用子智能体1 when it decides the task matches the subagent’s description.
  2. The subagent runs independently and returns its result.
  3. The main agent receives the result and continues orchestration.

​
Where to customize

There are several points where you can control how context is passed between the main agent and its subagents:
  1. Subagent name ("subagent1_name"): This is how the main agent refers to the subagent. Since it influences prompting, choose it carefully.
  2. Subagent description ("subagent1_description"): This is what the main agent “knows” about the subagent. It directly shapes how the main agent decides when to call it.
  3. Input to the subagent: You can customize this input to better shape how the subagent interprets tasks. In the example above, we pass the agent-generated 查询 directly.
  4. Output from the subagent: This is the response passed back to the main agent. You can adjust what is returned to control how the main agent interprets results. In the example above, we return the final message text, but you could return additional state or metadata.

​
Control the input to the subagent

There are two main levers to control the input that the main agent passes to a subagent:
  • Modify the prompt – Adjust the main agent’s prompt or the tool metadata (i.e., sub-agent’s name and description) to better guide when and how it calls the subagent.
  • Context injection – Add input that isn’t practical to capture in a static prompt (e.g., full message history, prior results, task metadata) by adjusting the tool call to pull from the agent’s state.
CODE_BLOCK_2

​
Control the output from the subagent

Two common strategies for shaping what the main agent receives back from a subagent:
  • Modify the prompt – Refine the subagent’s prompt to specify exactly what should be returned.
    • Useful when outputs are incomplete, too verbose, or missing key details.
    • A common failure mode is that the subagent performs tool calls or reasoning but does not include the results in its final message. Remind it that the controller (and user) only see the final output, so all relevant info must be included there.
  • Custom output formatting – adjust or enrich the subagent’s response in code before handing it back to the main agent.
    • Example: pass specific state keys back to the main agent in addition to the final text.
    • This requires wrapping the result in a `命令（或等效结构），以便您可以将自定义状态与子智能体的响应合并。
import { tool, ToolMessage } from "langchain";
import { Command } from "@langchain/langgraph";
import * as z from "zod";

const callSubagent1 = tool(
  async ({ query }, config) => {
    const result = await subagent1.invoke({
      messages: [{ role: "user", content: query }]
    });

    // Return a Command to update multiple state keys
    return new Command({
      update: {
        // Pass back additional state from the subagent
        exampleStateKey: result.exampleStateKey,
        messages: [
          new ToolMessage({
            content: result.messages.at(-1)?.text,
            tool_call_id: config.toolCall?.id!
          })
        ]
      }
    });
  },
  {
    name: "subagent1_name",
    description: "subagent1_description",
    schema: z.object({
      query: z.string().describe("The query to send to subagent1")
    })
  }
);

​
交接

在交接过程中，智能体可以直接将控制权相互传递。活动的智能体会发生变化，用户将与当前拥有控制权的智能体进行交互。 流程：
  1. 当前智能体决定需要从另一个智能体那里获得帮助。
  2. 它将控制权（以及状态）传递给下一个智能体。
  3. 新的智能体直接与用户交互，直到它决定再次转交或完成。

​
实现（即将推出）

在GitHub上编辑此页面的源代码。
通过MCP将这些文档编程连接到Claude、VSCode等，以获取实时答案。