Skip to main content
状态机模式 描述了智能体的行为随着任务在不同状态间转换而改变的工作流。本教程展示如何通过使用工具调用来动态更改单个智能体的配置,从而实现状态机——根据当前状态更新其可用工具和指令。状态可以从多个来源确定:智能体的过去操作(工具调用)、外部状态(例如 API 调用结果),甚至是初始用户输入(例如,通过运行分类器来确定用户意图)。 在本教程中,您将构建一个执行以下操作的客户支持智能体:
  • 在继续之前收集保修信息。
  • 将问题分类为硬件或软件问题。
  • 提供解决方案或升级到人工支持。
  • 在多轮对话中维护对话状态。
子智能体模式(其中子智能体作为工具被调用)不同,状态机模式使用单个智能体,其配置根据工作流进度而变化。每个“步骤”只是相同底层智能体的不同配置(系统提示 + 工具),根据状态动态选择。 以下是我们将构建的工作流:

设置

安装

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

LangSmith

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

选择 LLM

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

1. 定义自定义状态

首先,定义一个自定义状态模式,用于跟踪当前处于哪个步骤:
current_step 字段是状态机模式的核心——它决定了每轮对话中加载哪个配置(提示 + 工具)。

2. 创建管理工作流状态的工具

创建更新工作流状态的工具。这些工具允许智能体记录信息并转换到下一步。 关键是使用 Command 来更新状态,包括 current_step 字段:
注意 record_warranty_statusrecord_issue_type 如何返回 Command 对象,这些对象同时更新数据(warranty_statusissue_type)和 current_step。这就是状态机的工作方式——工具控制工作流的推进。

3. 定义步骤配置

为每个步骤定义提示和工具。首先,为每个步骤定义提示:
然后使用字典将步骤名称映射到其配置:
这种基于字典的配置使得以下操作变得容易:
  • 一目了然地查看所有步骤
  • 添加新步骤(只需添加另一个条目)
  • 理解工作流依赖关系(requires 字段)
  • 使用带有状态变量的提示模板(例如 {warranty_status}

4. 创建基于步骤的中间件

创建一个中间件,从状态中读取 current_step 并应用相应的配置。我们将使用 @wrap_model_call 装饰器来实现简洁的实现:
这个中间件:
  1. 读取当前步骤:从状态中获取 current_step(默认为 “warranty_collector”)。
  2. 查找配置:在 STEP_CONFIG 中找到匹配的条目。
  3. 验证依赖关系:确保所需的状态字段存在。
  4. 格式化提示:将状态值注入提示模板。
  5. 应用配置:覆盖系统提示和可用工具。
request.override() 方法是关键——它允许我们根据状态动态更改智能体的行为,而无需创建单独的智能体实例。

5. 创建智能体

现在创建带有基于步骤的中间件和用于状态持久化的检查点的智能体:
为什么需要检查点? 检查点在对话轮次之间维护状态。没有它,current_step 状态会在用户消息之间丢失,从而破坏工作流。

6. 测试工作流

测试完整的工作流:
预期流程:
  1. 保修验证步骤:询问保修状态
  2. 问题分类步骤:询问问题,确定是硬件问题
  3. 解决步骤:提供保修维修说明

7. 理解状态转换

让我们追踪每轮对话中发生的情况:

第 1 轮:初始消息

中间件应用:
  • 系统提示:WARRANTY_COLLECTOR_PROMPT
  • 工具:[record_warranty_status]

第 2 轮:保修记录后

工具调用:record_warranty_status("in_warranty") 返回:
下一轮,中间件应用:
  • 系统提示:ISSUE_CLASSIFIER_PROMPT(使用 warranty_status="in_warranty" 格式化)
  • 工具:[record_issue_type]

第 3 轮:问题分类后

工具调用:record_issue_type("hardware") 返回:
下一轮,中间件应用:
  • 系统提示:RESOLUTION_SPECIALIST_PROMPT(使用 warranty_statusissue_type 格式化)
  • 工具:[provide_solution, escalate_to_human]
关键洞察:工具通过更新 current_step 来驱动工作流,而中间件通过在下一轮应用相应的配置来响应

8. 管理消息历史

随着智能体逐步推进,消息历史会增长。使用摘要中间件来压缩早期消息,同时保留对话上下文:
有关其他内存管理技术,请参阅短期内存指南

9. 增加灵活性:返回

某些工作流需要允许用户返回到之前的步骤以更正信息(例如,更改保修状态或问题分类)。然而,并非所有转换都有意义——例如,一旦处理了退款,通常就不能返回。对于这个支持工作流,我们将添加工具以返回到保修验证和问题分类步骤。
如果您的工作流需要在大多数步骤之间进行任意转换,请考虑是否真的需要结构化工作流。当步骤遵循清晰的顺序进展,偶尔需要向后转换进行更正时,此模式效果最佳。
在解决步骤中添加“返回”工具:
更新解决专家的提示以提及这些工具:
现在智能体可以处理更正:

完整示例

以下是可运行脚本中的完整内容:

后续步骤