interrupt() 函数来工作。该函数接受任何 JSON 可序列化的值,该值将显示给调用者。当您准备好继续时,通过使用 Command 重新调用图来恢复执行,然后该值成为节点内部 interrupt() 调用的返回值。
与静态断点(在特定节点之前或之后暂停)不同,中断是动态的 — 它们可以放置在代码中的任何位置,并且可以基于您的应用程序逻辑有条件地执行。
- **检查点保持您的位置:**检查点器写入确切的图状态,以便您稍后可以恢复,即使在错误状态下也是如此。
- **
thread_id是您的指针:**设置config={"configurable": {"thread_id": ...}}来告诉检查点器要加载哪个状态。 - **中断有效负载显示为
__interrupt__:**您传递给interrupt()的值在__interrupt__字段中返回给调用者,以便您知道图在等待什么。
thread_id 实际上是您的持久游标。重用它会恢复相同的检查点;使用新值会启动具有空状态的全新线程。
使用 interrupt 暂停
interrupt 函数暂停图执行并向调用者返回一个值。当您在节点内调用 interrupt 时,LangGraph 保存当前图状态并等待您使用输入恢复执行。
要使用 interrupt,您需要:
- 一个检查点器来持久化图状态(在生产环境中使用持久检查点器)
- 配置中的线程 ID,以便运行时知道要从哪个状态恢复
- 在您想要暂停的位置调用
interrupt()(有效负载必须是 JSON 可序列化的)
interrupt 时,会发生以下情况:
- 图执行被暂停在调用
interrupt的确切位置 - 状态被保存使用检查点器,以便稍后可以恢复执行,在生产环境中,这应该是一个持久检查点器(例如由数据库支持)
- 值被返回给调用者在
__interrupt__下;它可以是任何 JSON 可序列化的值(字符串、对象、数组等) - 图无限期等待直到您使用响应恢复执行
- 响应被传回到节点当您恢复时,成为
interrupt()调用的返回值
恢复中断
在中断暂停执行后,您通过使用包含恢复值的Command 再次调用图来恢复图。恢复值传回给 interrupt 调用,允许节点使用外部输入继续执行。
- You must use the same thread ID when resuming that was used when the interrupt occurred
- The value passed to
Command(resume=...)becomes the return value of theinterruptcall - The node restarts from the beginning of the node where the
interruptwas called when resumed, so any code before theinterruptruns again - You can pass any JSON-serializable value as the resume value
Common patterns
中断解锁的关键是能够暂停执行并等待外部输入。这对于各种用例很有用,包括:- Approval workflows: Pause before executing critical actions (API calls, database changes, financial transactions)
- Review and edit: Let humans review and modify LLM outputs or tool calls before continuing
- Interrupting tool calls: Pause before executing tool calls to review and edit the tool call before execution
- Validating human input: Pause before proceeding to the next step to validate human input
Approve or reject
中断最常见的用途之一是在关键操作之前暂停并请求批准。例如,您可能希望要求人工批准 API 调用、数据库更改或任何其他重要决策。true 以批准或 false 以拒绝:
Full example
Full example
Review and edit state
有时您希望让人类在继续之前审查和编辑图状态的一部分。这对于纠正 LLM、添加缺失信息或进行调整很有用。Full example
Full example
Interrupts in tools
You can also place interrupts directly inside tool functions. This makes the tool itself pause for approval whenever it’s called, and allows for human review and editing of the tool call before it is executed. First, define a tool that usesinterrupt:
Full example
Full example
Validating human input
Sometimes you need to validate input from humans and ask again if it’s invalid. You can do this using multipleinterrupt calls in a loop.
Full example
Full example
Rules of interrupts
When you callinterrupt within a node, LangGraph suspends execution by raising an exception that signals the runtime to pause. This exception propagates up through the call stack and is caught by the runtime, which notifies the graph to save the current state and wait for external input.
When execution resumes (after you provide the requested input), the runtime restarts the entire node from the beginning—it does not resume from the exact line where interrupt was called. This means any code that ran before the interrupt will execute again. Because of this, there’s a few important rules to follow when working with interrupts to ensure they behave as expected.
Do not wrap interrupt calls in try/except
The way that interrupt pauses execution at the point of the call is by throwing a special exception. If you wrap the interrupt call in a try/except block, you will catch this exception and the interrupt will not be passed back to the graph.
- ✅ Separate
interruptcalls from error-prone code - ✅ Use specific exception types in try/except blocks
- 🔴 Do not wrap
interruptcalls in bare try/except blocks
Do not reorder interrupt calls within a node
It’s common to use multiple interrupts in a single node, however this can lead to unexpected behavior if not handled carefully.
When a node contains multiple interrupt calls, LangGraph keeps a list of resume values specific to the task executing the node. Whenever execution resumes, it starts at the beginning of the node. For each interrupt encountered, LangGraph checks if a matching value exists in the task’s resume list. Matching is strictly index-based, so the order of interrupt calls within the node is important.
- ✅ Keep
interruptcalls consistent across node executions
- 🔴 Do not conditionally skip
interruptcalls within a node - 🔴 Do not loop
interruptcalls using logic that isn’t deterministic across executions
Do not return complex values in interrupt calls
Depending on which checkpointer is used, complex values may not be serializable (e.g. you can’t serialize a function). To make your graphs adaptable to any deployment, it’s best practice to only use values that can be reasonably serialized.
- ✅ Pass simple, JSON-serializable types to
interrupt - ✅ Pass dictionaries/objects with simple values
- 🔴 Do not pass functions, class instances, or other complex objects to
interrupt
Side effects called before interrupt must be idempotent
Because interrupts work by re-running the nodes they were called from, side effects called before interrupt should (ideally) be idempotent. For context, idempotency means that the same operation can be applied multiple times without changing the result beyond the initial execution.
As an example, you might have an API call to update a record inside of a node. If interrupt is called after that call is made, it will be re-run multiple times when the node is resumed, potentially overwriting the initial update or creating duplicate records.
- ✅ Use idempotent operations before
interrupt - ✅ Place side effects after
interruptcalls - ✅ Separate side effects into separate nodes when possible
- 🔴 Do not perform non-idempotent operations before
interrupt - 🔴 Do not create new records without checking if they exist
Using with subgraphs called as functions
When invoking a subgraph within a node, the parent graph will resume execution from the beginning of the node where the subgraph was invoked and theinterrupt was triggered. Similarly, the subgraph will also resume from the beginning of the node where interrupt was called.
Debugging with interrupts
To debug and test a graph, you can use static interrupts as breakpoints to step through the graph execution one node at a time. Static interrupts are triggered at defined points either before or after a node executes. You can set these by specifyinginterrupt_before and interrupt_after when compiling the graph.
Static interrupts are not recommended for human-in-the-loop workflows. Use the
interrupt method instead.- At compile time
- At run time
- The breakpoints are set during
compiletime. interrupt_beforespecifies the nodes where execution should pause before the node is executed.interrupt_afterspecifies the nodes where execution should pause after the node is executed.- A checkpointer is required to enable breakpoints.
- The graph is run until the first breakpoint is hit.
- The graph is resumed by passing in
Nonefor the input. This will run the graph until the next breakpoint is hit.
Using LangGraph Studio
You can use LangGraph Studio to set static interrupts in your graph in the UI before running the graph. You can also use the UI to inspect the graph state at any point in the execution.