状态机模式描述了智能体的行为随着任务不同状态的推进而变化的工作流程。本教程展示如何通过使用工具调用来动态更改单个智能体的配置来实现状态机——根据当前状态更新其可用工具和指令。 The state can be determined from multiple sources: the agent’s past actions (tool calls), external state (such as API call results), or even initial user input (for example, by running a classifier to determine user intent). 在本教程中,你将构建一个客户支持智能体,它可以: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.
- 在继续之前收集保修信息。
- 将问题分类为硬件或软件。
- 提供解决方案或升级到人工支持。
- 跨多个回合维护对话状态。
Setup
Installation
This tutorial requires thelangchain package:
LangSmith
Set up LangSmith to inspect what is happening inside your agent. Then set the following environment variables:Select an LLM
Select a chat model from LangChain’s suite of integrations:- OpenAI
- Anthropic
- Azure
- Google Gemini
- AWS Bedrock
- HuggingFace
- OpenRouter
1. Define custom state
First, define a custom state schema that tracks which step is currently active: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 manage workflow state
Create tools that update the workflow state. These tools allow the agent to record information and transition to the next step. The key is usingCommand to update state, including the current_step field:
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 step configurations
Define prompts and tools for each step. First, define the prompts for each step:View complete prompt definitions
View complete prompt definitions
- See all steps at a glance
- Add new steps (just add another entry)
- Understand the workflow dependencies (
requiresfield) - Use prompt templates with state variables (e.g.,
{warranty_status})
4. Create step-based middleware
Create middleware that readscurrent_step from state and applies the appropriate configuration. We’ll use the @wrap_model_call decorator for a clean implementation:
- Reads current step: Gets
current_stepfrom state (defaults to “warranty_collector”). - Looks up configuration: Finds the matching entry in
STEP_CONFIG. - Validates dependencies: Ensures required state fields exist.
- Formats prompt: Injects state values into the prompt template.
- Applies configuration: Overrides the system prompt and available tools.
request.override() method is key - it allows us to dynamically change the agent’s behavior based on state without creating separate agent instances.
5. Create the agent
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 workflow
Test the complete workflow:- Warranty verification step: Asks about warranty status
- Issue classification step: Asks about the problem, determines it’s hardware
- Resolution step: Provides warranty repair instructions
7. Understanding state transitions
Let’s trace what happens at each turn:Turn 1: Initial message
- System prompt:
WARRANTY_COLLECTOR_PROMPT - Tools:
[record_warranty_status]
Turn 2: After warranty recorded
Tool call:record_warranty_status("in_warranty") returns:
- System prompt:
ISSUE_CLASSIFIER_PROMPT(formatted withwarranty_status="in_warranty") - Tools:
[record_issue_type]
Turn 3: After issue classified
Tool call:record_issue_type("hardware") returns:
- System prompt:
RESOLUTION_SPECIALIST_PROMPT(formatted withwarranty_statusandissue_type) - Tools:
[provide_solution, escalate_to_human]
current_step, and middleware responds by applying the appropriate configuration on the next turn.
8. Manage message history
As the agent progresses through steps, message history grows. Use summarization middleware to compress earlier messages while preserving conversational context:9. Add flexibility: Go back
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. Add “go back” tools to the resolution step:Complete example
Here’s everything together in a runnable script:Next steps
- Learn about the subagents pattern for centralized orchestration
- Explore middleware for more dynamic behaviors
- Read the multi-agent overview to compare patterns
- Use LangSmith to debug and monitor your multi-agent system
连接这些文档到 Claude、VSCode 等工具,通过 MCP 获取实时答案。

