Skip to main content

概览

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

为什么使用监督者?

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

概念

我们将涵盖以下概念:

设置

安装

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

LangSmith

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

组件

我们需要从 LangChain 的集成套件中选择一个聊天模型:
👉 Read the OpenAI chat model integration docs

1. 定义工具

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

2. 创建专业子智能体

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

创建日历智能体

日历智能体理解自然语言的日程安排请求,并将它们转换为精确的 API 调用。它处理日期解析、可用性检查和事件创建。
测试日历智能体,看看它如何处理自然语言日程安排:
智能体将”下周二下午 2 点”解析为 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. 进阶:控制信息流

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

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

这允许子智能体看到完整的对话上下文,这对于解决诸如”安排在明天同一时间”(引用之前的对话)等歧义很有用。
你可以在 LangSmith 追踪的聊天模型调用中查看子智能体接收到的完整上下文。

控制监督者接收的内容

你也可以自定义返回给监督者的信息:
重要提示: 确保子智能体的提示词强调其最终消息应包含所有相关信息。一个常见的失败模式是子智能体执行工具调用但不在最终响应中包含结果。

8. 关键要点

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

下一步

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