Skip to main content

概述

监督者模式是一种多智能体架构,其中中央监督者智能体协调专门的工作者智能体。当任务需要不同类型的专业知识时,这种方法表现出色。与其构建一个管理跨领域工具选择的智能体,不如创建由理解整体工作流程的监督者协调的专注专家。 在本教程中,你将构建一个个人助手系统,通过一个真实的工作流程来展示这些优势。该系统将协调两个职责根本不同的专家:
  • 一个日历智能体,处理日程安排、可用性检查和事件管理。
  • 一个电子邮件智能体,管理通信、起草消息和发送通知。
我们还将整合人在回路中审查,允许用户根据需要批准、编辑和拒绝操作(例如外发电子邮件)。

为什么使用监督者?

多智能体架构允许你将工具分配给工作者,每个工作者都有自己的提示或指令。考虑一个直接访问所有日历和电子邮件 API 的智能体:它必须从许多相似的工具中选择,理解每个 API 的确切格式,并同时处理多个领域。如果性能下降,将相关工具和关联提示分成逻辑组(部分是为了管理迭代改进)可能会有所帮助。

概念

我们将涵盖以下概念:

设置

安装

本教程需要 langchain 包:
更多详情,请参阅我们的安装指南

LangSmith

设置 LangSmith 以检查智能体内部发生的情况。然后设置以下环境变量:

组件

我们需要从 LangChain 的集成套件中选择一个聊天模型:
👉 阅读 OpenAI 聊天模型集成文档

1. 定义工具

首先定义需要结构化输入的工具。在实际应用中,这些工具会调用真实的 API(Google Calendar、SendGrid 等)。在本教程中,你将使用存根来演示该模式。

2. 创建专门的子智能体

接下来,我们将创建处理每个领域的专门子智能体。

创建日历智能体

日历智能体理解自然语言调度请求,并将其转换为精确的 API 调用。它处理日期解析、可用性检查和事件创建。
测试日历智能体,看看它如何处理自然语言调度:
该智能体将 “next Tuesday at 2pm” 解析为 ISO 格式(“2024-01-16T14:00:00”),计算结束时间,调用 create_calendar_event,并返回自然语言确认。

创建电子邮件智能体

电子邮件智能体处理消息撰写和发送。它专注于提取收件人信息、撰写合适的主题行和正文文本,以及管理电子邮件通信。
使用自然语言请求测试电子邮件智能体:
该智能体从非正式请求中推断收件人,撰写专业的主题行和正文,调用 send_email,并返回确认。每个子智能体都有一个狭窄的关注点,配备特定领域的工具和提示,使其能够在其特定任务上表现出色。

3. 将子智能体包装为工具

现在将每个子智能体包装为监督者可以调用的工具。这是创建分层系统的关键架构步骤。监督者将看到像 “schedule_event” 这样的高级工具,而不是像 “create_calendar_event” 这样的低级工具。
工具描述帮助监督者决定何时使用每个工具,因此请确保它们清晰具体。我们只返回子智能体的最终响应,因为监督者不需要看到中间推理或工具调用。

4. 创建监督者智能体

现在创建协调子智能体的监督者。监督者只看到高级工具,并在领域级别(而不是单个 API 级别)做出路由决策。

5. 使用监督者

现在使用需要跨多个领域协调的复杂请求来测试你的完整系统:

示例 1:简单的单领域请求

监督者将其识别为日历任务,调用 schedule_event,日历智能体处理日期解析和事件创建。
要全面了解信息流,包括每次聊天模型调用的提示和响应,请查看上述运行的 LangSmith 跟踪

示例 2:复杂的多领域请求

监督者认识到这需要日历和电子邮件操作,为会议调用 schedule_event,然后为提醒调用 manage_email。每个子智能体完成其任务,监督者将两个结果综合成一个连贯的响应。
请参阅 LangSmith 跟踪 以查看上述运行的详细信息流,包括各个聊天模型的提示和响应。

完整的工作示例

以下是所有内容组合在一起的可运行脚本:

理解架构

你的系统有三层。底层包含需要精确格式的刚性 API 工具。中间层包含接受自然语言、将其转换为结构化 API 调用并返回自然语言确认的子智能体。顶层包含路由到高级功能并综合结果的监督者。 这种关注点分离提供了几个好处:每层都有一个专注的职责,你可以添加新领域而不影响现有领域,并且你可以独立测试和迭代每一层。

6. 添加人在回路中审查

将敏感操作纳入人在回路中审查可能是谨慎的。LangChain 包含内置中间件来审查工具调用,在本例中是子智能体调用的工具。 让我们为两个子智能体都添加人在回路中审查:
  • 我们配置 create_calendar_eventsend_email 工具以中断,允许所有响应类型approveeditreject
  • 我们仅在顶层智能体添加检查点保存器。这是暂停和恢复执行所必需的。
让我们重复该查询。注意,我们将中断事件收集到一个列表中以便访问下游:
这次我们中断了执行。让我们检查中断事件:
我们可以通过使用 Command 引用其 ID 来为每个中断指定决策。有关更多详细信息,请参阅人在回路中指南。为演示目的,这里我们将接受日历事件,但编辑外发电子邮件的主题:
运行继续使用我们的输入。

7. 高级:控制信息流

默认情况下,子智能体只接收来自监督者的请求字符串。你可能希望传递额外的上下文,例如对话历史或用户偏好。

向子智能体传递额外的对话上下文

这允许子智能体看到完整的对话上下文,这对于解决诸如 “schedule it for the same time tomorrow”(引用之前的对话)之类的歧义很有用。
你可以在 LangSmith 跟踪的聊天模型调用中查看子智能体接收的完整上下文。

控制监督者接收的内容

你还可以自定义流回监督者的信息:
重要提示: 确保子智能体提示强调其最终消息应包含所有相关信息。一个常见的失败模式是子智能体执行工具调用但未将结果包含在其最终响应中。
要查看一个完整的、演示了带有在回路中审查和高级信息流控制的完整监督者模式的工作示例,请查看 LangChain.js 示例中的 supervisor_complete.ts

8. 关键要点

监督者模式创建了抽象层,每层都有明确的职责。设计监督者系统时,从清晰的领域边界开始,为每个子智能体提供专注的工具和提示。为监督者编写清晰的工具描述,在集成之前独立测试每一层,并根据你的特定需求控制信息流。
何时使用监督者模式当你有多个不同的领域(日历、电子邮件、CRM、数据库),每个领域有多个工具或复杂逻辑,你想要集中式工作流控制,并且子智能体不需要直接与用户对话时,请使用监督者模式。对于只有几个工具的更简单情况,请使用单个智能体。当智能体需要与用户对话时,请使用交接。对于智能体之间的点对点协作,请考虑其他多智能体模式。

后续步骤

了解用于智能体到智能体对话的交接,探索上下文工程以微调信息流,阅读多智能体概述以比较不同模式,并使用 LangSmith 调试和监控你的多智能体系统。