Skip to main content

Documentation Index

Fetch the complete documentation index at: https://nvd-54.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

路由器架构中,一个路由步骤对输入进行分类,并将其定向到专业化的智能体。当你有不同的垂直领域(需要各自专属智能体的独立知识域)时,这特别有用。

关键特征

  • 路由器分解查询
  • 零个或多个专业智能体被并行调用
  • 结果被合成为连贯的响应

何时使用

当你有不同的垂直领域(需要各自专属智能体的独立知识域)、需要并行查询多个来源、并且想要将结果合成为组合响应时,使用路由器模式。

基本实现

路由器对查询进行分类,并将其定向到适当的智能体。使用 Command 进行单智能体路由,或使用 Send 并行扇出到多个智能体。
使用 Command 路由到单个专业智能体:
import { z } from "zod";
import { Command } from "@langchain/langgraph";

const ClassificationResult = z.object({
  query: z.string(),
  agent: z.string(),
});

function classifyQuery(query: string): z.infer<typeof ClassificationResult> {
  // 使用 LLM 对查询进行分类并确定合适的智能体
  // 分类逻辑在此
  ...
}

function routeQuery(state: z.infer<typeof ClassificationResult>) {
  const classification = classifyQuery(state.query);

  // 路由到选定的智能体
  return new Command({ goto: classification.agent });
}
如需完整实现,请参阅下面的教程。

教程:使用路由构建多源知识库

构建一个路由器,并行查询 GitHub、Notion 和 Slack,然后将结果合成为连贯的答案。涵盖状态定义、专业智能体、使用 Send 进行并行执行和结果合成。

无状态 vs 有状态

两种方法:

无状态

每个请求被独立路由——调用之间没有记忆。如需多轮对话,请参阅有状态路由器
路由器 vs 子智能体:两种模式都可以将工作分发给多个智能体,但它们在路由决策的方式上有所不同:
  • 路由器:一个专用的路由步骤(通常是单次 LLM 调用或基于规则的逻辑)对输入进行分类并分发给智能体。路由器本身通常不维护对话历史或执行多轮编排——它是一个预处理步骤。
  • 子智能体:一个主管智能体动态决定在持续对话中调用哪些子智能体。主智能体维护上下文,可以跨轮次调用多个子智能体,并编排复杂的多步工作流。
当你有明确的输入类别并希望确定性或轻量级分类时,使用路由器。当你需要灵活的、感知对话的编排,让 LLM 根据不断演变的上下文决定下一步时,使用主管

有状态

对于多轮对话,你需要跨调用维护上下文。

工具包装

最简单的方法:将无状态路由器包装为会话智能体可以调用的工具。会话智能体处理记忆和上下文;路由器保持无状态。这避免了跨多个并行智能体管理对话历史的复杂性。
const searchDocs = tool(
  async ({ query }) => {
    const result = await workflow.invoke({ query });
    return result.finalAnswer;
  },
  {
    name: "search_docs",
    description: "Search across multiple documentation sources",
    schema: z.object({
      query: z.string().describe("The search query"),
    }),
  }
);

// 会话智能体使用路由器作为工具
const conversationalAgent = createAgent({
  model,
  tools: [searchDocs],
  systemPrompt: "You are a helpful assistant. Use search_docs to answer questions.",
});

完整持久化

如果你需要路由器本身维护状态,使用持久化来存储消息历史。当路由到智能体时,从状态中获取先前的消息,并选择性地将它们包含在智能体的上下文中——这是上下文工程的一个杠杆。
有状态路由器需要自定义历史管理。 如果路由器在不同轮次之间切换智能体,当智能体有不同的语气或提示词时,对话对终端用户来说可能不够流畅。使用并行调用时,你需要在路由器层面维护历史(输入和合成输出),并在路由逻辑中利用这些历史。考虑使用交接模式子智能体模式代替——两者都为多轮对话提供了更清晰的语义。