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

设置

安装

This tutorial requires the langchain package:
For more details, see our Installation guide.

LangSmith 设置

Set up LangSmith to inspect what is happening inside your agent. Then set the following environment variables:

选择 LLM

Select a chat model from LangChain’s suite of integrations:
👉 Read the OpenAI chat model integration docs

1. 定义自定义状态

First, define a custom state schema that tracks which step is currently active:
The current_step field is the core of the state machine pattern - it determines which configuration (prompt + tools) is loaded on each turn.

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

Create tools that update the workflow state. These tools allow the agent to record information and transition to the next step. The key is using Command to update state, including the current_step field:
Notice how record_warranty_status and record_issue_type return Command objects that update both the data (warranty_status, issue_type) AND the current_step. This is how the state machine works - tools control workflow progression.

3. 定义步骤配置

Define prompts and tools for each step. First, define the prompts for each step:
Then map step names to their configurations using a dictionary:
This dictionary-based configuration makes it easy to:
  • See all steps at a glance
  • Add new steps (just add another entry)
  • Understand the workflow dependencies (requires field)
  • Use prompt templates with state variables (e.g., {warranty_status})

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

Create middleware that reads current_step from state and applies the appropriate configuration. We’ll use the @wrap_model_call decorator for a clean implementation:
This middleware:
  1. Reads current step: Gets current_step from state (defaults to “warranty_collector”).
  2. Looks up configuration: Finds the matching entry in STEP_CONFIG.
  3. Validates dependencies: Ensures required state fields exist.
  4. Formats prompt: Injects state values into the prompt template.
  5. Applies configuration: Overrides the system prompt and available tools.
The request.override() method is key - it allows us to dynamically change the agent’s behavior based on state without creating separate agent instances.

5. 创建智能体

Now create the agent with the step-based middleware and a checkpointer for state persistence:
Why a checkpointer? The checkpointer maintains state across conversation turns. Without it, the current_step state would be lost between user messages, breaking the workflow.

6. 测试工作流

Test the complete workflow:
Expected flow:
  1. Warranty verification step: Asks about warranty status
  2. Issue classification step: Asks about the problem, determines it’s hardware
  3. Resolution step: Provides warranty repair instructions

7. 理解状态转换

Let’s trace what happens at each turn:

第 1 轮:初始消息

Middleware applies:
  • System prompt: WARRANTY_COLLECTOR_PROMPT
  • Tools: [record_warranty_status]

第 2 轮:记录保修后

Tool call: recordWarrantyStatus("in_warranty") returns:
Next turn, middleware applies:
  • System prompt: ISSUE_CLASSIFIER_PROMPT (formatted with warranty_status="in_warranty")
  • Tools: [record_issue_type]

第 3 轮:问题分类后

Tool call: recordIssueType("hardware") returns:
Next turn, middleware applies:
  • System prompt: RESOLUTION_SPECIALIST_PROMPT (formatted with warranty_status and issue_type)
  • Tools: [provide_solution, escalate_to_human]
The key insight: Tools drive the workflow by updating current_step, and middleware responds by applying the appropriate configuration on the next turn.

8. 管理消息历史

As the agent progresses through steps, message history grows. Use summarization middleware to compress earlier messages while preserving conversational context:
See the short-term memory guide for other memory management techniques.

9. 增加灵活性:返回上一步

Some workflows need to allow users to return to previous steps to correct information (e.g., changing warranty status or issue classification). However, not all transitions make sense—for example, you typically can’t go back once a refund has been processed. For this support workflow, we’ll add tools to return to the warranty verification and issue classification steps.
If your workflow requires arbitrary transitions between most steps, consider whether you need a structured workflow at all. This pattern works best when steps follow a clear sequential progression with occasional backwards transitions for corrections.
Add “go back” tools to the resolution step:
Update the resolution specialist’s prompt to mention these tools:
Now the agent can handle corrections:

完整示例

Here’s everything together in a runnable script:

后续步骤