mirror of
https://github.com/langchain-ai/langgraph.git
synced 2026-09-06 17:57:49 +02:00
docs: re-enable strict mode (#4638)
- Turn on strict mode to fail docs build if there are any internal broken anchor links. - Fix broken anchor links. - Delete storm tutorial that has fake markdown inside it (we'll figure out how to deal with it later)
This commit is contained in:
Eugene Yurtsev
@@ -31,7 +31,7 @@ After each step, an example file directory is provided to demonstrate how code c
|
||||
|
||||
## Specify Dependencies
|
||||
|
||||
Dependencies can optionally be specified in one of the following files: `pyproject.toml`, `setup.py`, or `requirements.txt`. If none of these files is created, then dependencies can be specified later in the [LangGraph configuration file](#create-langgraph-api-config).
|
||||
Dependencies can optionally be specified in one of the following files: `pyproject.toml`, `setup.py`, or `requirements.txt`. If none of these files is created, then dependencies can be specified later in the [LangGraph configuration file](#create-langgraph-configuration-file).
|
||||
|
||||
The dependencies below will be included in the image, you can also use them in your code, as long as with a compatible version range:
|
||||
|
||||
|
||||
@@ -31,7 +31,7 @@ After each step, an example file directory is provided to demonstrate how code c
|
||||
|
||||
## Specify Dependencies
|
||||
|
||||
Dependencies can optionally be specified in one of the following files: `pyproject.toml`, `setup.py`, or `requirements.txt`. If none of these files is created, then dependencies can be specified later in the [LangGraph configuration file](#create-langgraph-api-config).
|
||||
Dependencies can optionally be specified in one of the following files: `pyproject.toml`, `setup.py`, or `requirements.txt`. If none of these files is created, then dependencies can be specified later in the [LangGraph configuration file](#create-langgraph-configuration-file).
|
||||
|
||||
The dependencies below will be included in the image, you can also use them in your code, as long as with a compatible version range:
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ Before deploying, review the [conceptual guide for the Standalone Container](../
|
||||
`<database_name_1>` and `database_name_2` are different databases within the same instance, but `<hostname_1>` is shared. **The same database cannot be used for separate deployments**.
|
||||
|
||||
1. `LANGSMITH_API_KEY`: (if using [Lite](../../concepts/langgraph_server.md#server-versions)) LangSmith API key. This will be used to authenticate ONCE at server start up.
|
||||
1. `LANGGRAPH_CLOUD_LICENSE_KEY`: (if using [Enterprise](../../concepts/langgraph_data_plane.md#lite-vs-enterprise)) LangGraph Platform license key. This will be used to authenticate ONCE at server start up.
|
||||
1. `LANGGRAPH_CLOUD_LICENSE_KEY`: (if using [Enterprise](../../concepts/langgraph_data_plane.md#licensing)) LangGraph Platform license key. This will be used to authenticate ONCE at server start up.
|
||||
1. `LANGSMITH_ENDPOINT`: To send traces to a [self-hosted LangSmith](https://docs.smith.langchain.com/self_hosting) instance, set `LANGSMITH_ENDPOINT` to the hostname of the self-hosted LangSmith instance.
|
||||
|
||||
## Kubernetes (Helm)
|
||||
|
||||
@@ -4,7 +4,8 @@ With LangGraph Cloud you have the ability to return to any of your prior states
|
||||
|
||||
## Setup
|
||||
|
||||
We are not going to show the full code for the graph we are hosting, but you can see it [here](../../how-tos/human_in_the_loop/time-travel.ipynb#build-the-agent) if you want to. Once this graph is hosted, we are ready to invoke it and wait for user input.
|
||||
The examples below are executed against a specific deployment on LangGraph Cloud. You will use
|
||||
the SDK in a similar way, but you will expect to see different results based on the graph you have deployed.
|
||||
|
||||
### SDK initialization
|
||||
|
||||
|
||||
@@ -210,14 +210,14 @@ Basic usage example:
|
||||
|
||||
### Supported stream modes
|
||||
|
||||
| Mode | Description | LangGraph Library Method |
|
||||
|----------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------|
|
||||
| [`values`](#stream-graph-state) | Stream the full graph state after each [super-step](../../concepts/low_level.md#graphs). | `.stream()` / `.astream()` with [`stream_mode="values"`](../../how-tos/streaming.md#stream-graph-state) |
|
||||
| [`updates`](#stream-graph-state) | Streams the updates to the state after each step of the graph. If multiple updates are made in the same step (e.g., multiple nodes are run), those updates are streamed separately. | `.stream()` / `.astream()` with [`stream_mode="updates"`](../../how-tos/streaming.md#stream-graph-state) |
|
||||
| [`messages-tuple`](#messages) | Streams LLM tokens and metadata for the graph node where the LLM is invoked (useful for chat apps). | `.stream()` / `.astream()` with [`stream_mode="messages"`](../../how-tos/streaming.md#messages) |
|
||||
| [`debug`](#debug) | Streams as much information as possible throughout the execution of the graph. | `.stream()` / `.astream()` with [`stream_mode="debug"`](../../how-tos/streaming.md#stream-graph-state) |
|
||||
| [`custom`](#stream-custom-data) | Streams custom data from inside your graph | `.stream()` / `.astream()` with [`stream_mode="custom"`](../../how-tos/streaming.md#stream-custom-data) |
|
||||
| [`events`](#stream-events) | Stream all events (including the state of the graph); mainly useful when migrating large LCEL apps. | `.astream_events()`
|
||||
| Mode | Description | LangGraph Library Method |
|
||||
|----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------|
|
||||
| [`values`](#stream-graph-state) | Stream the full graph state after each [super-step](../../concepts/low_level.md#graphs). | `.stream()` / `.astream()` with [`stream_mode="values"`](../../how-tos/streaming.md#stream-graph-state) |
|
||||
| [`updates`](#stream-graph-state) | Streams the updates to the state after each step of the graph. If multiple updates are made in the same step (e.g., multiple nodes are run), those updates are streamed separately. | `.stream()` / `.astream()` with [`stream_mode="updates"`](../../how-tos/streaming.md#stream-graph-state) |
|
||||
| [`messages-tuple`](#messages) | Streams LLM tokens and metadata for the graph node where the LLM is invoked (useful for chat apps). | `.stream()` / `.astream()` with [`stream_mode="messages"`](../../how-tos/streaming.md#messages) |
|
||||
| [`debug`](#debug) | Streams as much information as possible throughout the execution of the graph. | `.stream()` / `.astream()` with [`stream_mode="debug"`](../../how-tos/streaming.md#stream-graph-state) |
|
||||
| [`custom`](#stream-custom-data) | Streams custom data from inside your graph | `.stream()` / `.astream()` with [`stream_mode="custom"`](../../how-tos/streaming.md#stream-custom-data) |
|
||||
| [`events`](#stream-events) | Stream all events (including the state of the graph); mainly useful when migrating large LCEL apps. | `.astream_events()` |
|
||||
|
||||
### Stream multiple modes
|
||||
|
||||
@@ -644,13 +644,7 @@ The streamed output from [`messages-tuple` mode](#supported-stream-modes) is a t
|
||||
|
||||
- `message_chunk`: the token or message segment from the LLM.
|
||||
- `metadata`: a dictionary containing details about the graph node and LLM invocation.
|
||||
|
||||
> If your LLM is not available as a LangChain integration, you can stream its outputs using `custom` mode instead. See [use with any LLM](#use-with-any-llm) for details.
|
||||
|
||||
!!! warning "Manual config required for async in Python < 3.11"
|
||||
|
||||
When using Python < 3.11 with async code in your graph, you must explicitly pass `RunnableConfig` to `ainvoke()` to enable proper streaming. See [Async with Python < 3.11](#async) for details or upgrade to Python 3.11+.
|
||||
|
||||
??? example "Example graph"
|
||||
|
||||
```python
|
||||
@@ -748,43 +742,7 @@ The streamed output from [`messages-tuple` mode](#supported-stream-modes) is a t
|
||||
|
||||
## Stream custom data
|
||||
|
||||
To send **custom user-defined data** from inside a LangGraph node or tool, follow these steps:
|
||||
|
||||
1. Use `get_stream_writer()` to access the stream writer and emit custom data.
|
||||
2. Set `stream_mode="custom"` when calling `.stream()` or `.astream()` to get the custom data in the stream. You can combine multiple modes (e.g., `["updates", "custom"]`), but at least one must be `"custom"`.
|
||||
|
||||
!!! warning "No `get_stream_writer()` in async for Python < 3.11"
|
||||
|
||||
In async code running on Python < 3.11, `get_stream_writer()` will not work.
|
||||
Instead, add a `writer` parameter to your node or tool and pass it manually.
|
||||
See [Async with Python < 3.11](#async) for usage examples.
|
||||
|
||||
??? example "Example graph"
|
||||
|
||||
```python
|
||||
from typing import TypedDict
|
||||
from langgraph.config import get_stream_writer
|
||||
from langgraph.graph import StateGraph, START
|
||||
|
||||
class State(TypedDict):
|
||||
query: str
|
||||
answer: str
|
||||
|
||||
def node(state: State):
|
||||
writer = get_stream_writer() # (1)!
|
||||
writer({"custom_key": "Generating custom data inside node"}) # (2)!
|
||||
return {"answer": "some data"}
|
||||
|
||||
graph = (
|
||||
StateGraph(State)
|
||||
.add_node(node)
|
||||
.add_edge(START, "node")
|
||||
.compile()
|
||||
)
|
||||
```
|
||||
|
||||
1. Get the stream writer to send custom data.
|
||||
2. Emit a custom key-value pair (e.g., progress update).
|
||||
To send **custom user-defined data**:
|
||||
|
||||
=== "Python"
|
||||
|
||||
@@ -829,8 +787,6 @@ To send **custom user-defined data** from inside a LangGraph node or tool, follo
|
||||
}"
|
||||
```
|
||||
|
||||
See [this guide](../../how-tos/streaming.md#stream-custom-data) for more examples.
|
||||
|
||||
## Stream events
|
||||
|
||||
To stream all events, including the state of the graph:
|
||||
|
||||
@@ -147,7 +147,7 @@ If a [node](./low_level.md#nodes) contains multiple operations, you may find it
|
||||
Once you have enabled durable execution in your workflow, you can resume execution for the following scenarios:
|
||||
|
||||
- **Pausing and Resuming Workflows:** Use the [interrupt][langgraph.types.interrupt] function to pause a workflow at specific points and the [Command][langgraph.types.Command] primitive to resume it with updated state. See [**Human-in-the-Loop**](./human_in_the_loop.md) for more details.
|
||||
- **Recovering from Failures:** Automatically resume workflows from the last successful checkpoint after an exception (e.g., LLM provider outage). This involves executing the workflow with the same thread identifier by providing it with a `None` as the input value (see this [example](./functional_api.md#resuming-after-an-error) with the functional API).
|
||||
- **Recovering from Failures:** Automatically resume workflows from the last successful checkpoint after an exception (e.g., LLM provider outage). This involves executing the workflow with the same thread identifier by providing it with a `None` as the input value (see this [example](../how-tos/use-functional-api.md#resuming-after-an-error) with the functional API).
|
||||
|
||||
## Starting Points for Resuming Workflows
|
||||
|
||||
|
||||
@@ -136,7 +136,7 @@ def workflow(topic: str) -> dict:
|
||||
|
||||
## Entrypoint
|
||||
|
||||
The [`@entrypoint`][langgraph.func.entrypoint] decorator can be used to create a workflow from a function. It encapsulates workflow logic and manages execution flow, including handling *long-running tasks* and [interrupts](./low_level.md#interrupt).
|
||||
The [`@entrypoint`][langgraph.func.entrypoint] decorator can be used to create a workflow from a function. It encapsulates workflow logic and manages execution flow, including handling *long-running tasks* and [interrupts](./human_in_the_loop.md).
|
||||
|
||||
### Definition
|
||||
|
||||
@@ -184,12 +184,12 @@ You will usually want to pass a **checkpointer** to the `@entrypoint` decorator
|
||||
When declaring an `entrypoint`, you can request access to additional parameters that will be injected automatically at run time. These parameters include:
|
||||
|
||||
|
||||
| Parameter | Description |
|
||||
|--------------|---------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| **previous** | Access the the state associated with the previous `checkpoint` for the given thread. See [state management](#state-management). |
|
||||
| **store** | An instance of [BaseStore][langgraph.store.base.BaseStore]. Useful for [long-term memory](#long-term-memory). |
|
||||
| **writer** | For streaming custom data, to write custom data to the `custom` stream. Useful for [streaming custom data](#streaming-custom-data). |
|
||||
| **config** | For accessing run time configuration. See [RunnableConfig](https://python.langchain.com/docs/concepts/runnables/#runnableconfig) for information. |
|
||||
| Parameter | Description |
|
||||
|--------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| **previous** | Access the the state associated with the previous `checkpoint` for the given thread. See [short-term-memory](#short-term-memory). |
|
||||
| **store** | An instance of [BaseStore][langgraph.store.base.BaseStore]. Useful for [long-term memory](../how-tos/use-functional-api.md#long-term-memory). |
|
||||
| **writer** | Use to access the StreamWriter when working with Async Python < 3.11. See [streaming with functional API for details](../how-tos/use-functional-api.md#streaming). |
|
||||
| **config** | For accessing run time configuration. See [RunnableConfig](https://python.langchain.com/docs/concepts/runnables/#runnableconfig) for information. |
|
||||
|
||||
!!! important
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ LangGraph supports robust **human-in-the-loop (HIL)** workflows, enabling human
|
||||
|
||||
## Typical use cases
|
||||
|
||||
1. [**🛠️ Reviewing tool calls**](#review-tool-calls): Humans can review, edit, or approve tool calls requested by the LLM before tool execution.
|
||||
1. [**🛠️ Reviewing tool calls**](../how-tos/human_in_the_loop/add-human-in-the-loop.md#review-tool-calls): Humans can review, edit, or approve tool calls requested by the LLM before tool execution.
|
||||
2. **✅ Validating LLM outputs**: Humans can review, edit, or approve content generated by the LLM.
|
||||
3. **💡 Providing context**: Enable the LLM to explicitly request human input for clarification or additional details or to support multi-turn conversations.
|
||||
|
||||
|
||||
@@ -68,7 +68,7 @@ When implementing a LangGraph application, a [checkpointer](../concepts/persiste
|
||||
|
||||
There is no direct access to the database. All access to the database occurs through the [LangGraph Server](../concepts/langgraph_server.md).
|
||||
|
||||
The database is never deleted until the deployment itself is deleted. See [Automatic Deletion](#automatic-deletion) for additional details.
|
||||
The database is never deleted until the deployment itself is deleted.
|
||||
|
||||
!!! info
|
||||
A custom Postgres instance can be configured for [Self-Hosted Data Plane](../concepts/langgraph_self_hosted_data_plane.md) and [Self-Hosted Control Plane](../concepts/langgraph_self_hosted_control_plane.md) deployments.
|
||||
|
||||
@@ -362,7 +362,7 @@ Use [conditional edges](#conditional-edges) to route between nodes conditionally
|
||||
|
||||
### Navigating to a node in a parent graph
|
||||
|
||||
If you are using [subgraphs](#subgraphs), you might want to navigate from a node within a subgraph to a different subgraph (i.e. a different node in the parent graph). To do so, you can specify `graph=Command.PARENT` in `Command`:
|
||||
If you are using [subgraphs](./subgraphs.md), you might want to navigate from a node within a subgraph to a different subgraph (i.e. a different node in the parent graph). To do so, you can specify `graph=Command.PARENT` in `Command`:
|
||||
|
||||
```python
|
||||
def my_node(state: State) -> Command[Literal["other_subgraph"]]:
|
||||
|
||||
@@ -11,7 +11,7 @@ An [agent](./agentic_concepts.md#agent-architectures) is _a system that uses an
|
||||
- context grows too complex for a single agent to keep track of
|
||||
- there is a need for multiple specialization areas in the system (e.g. planner, researcher, math expert, etc.)
|
||||
|
||||
To tackle these, you might consider breaking your application into multiple smaller, independent agents and composing them into a **multi-agent system**. These independent agents can be as simple as a prompt and an LLM call, or as complex as a [ReAct](./agentic_concepts.md#react-implementation) agent (and more!).
|
||||
To tackle these, you might consider breaking your application into multiple smaller, independent agents and composing them into a **multi-agent system**. These independent agents can be as simple as a prompt and an LLM call, or as complex as a [ReAct](./agentic_concepts.md#tool-calling-agent) agent (and more!).
|
||||
|
||||
The primary benefits of using multi-agent systems are:
|
||||
|
||||
@@ -36,7 +36,7 @@ There are several ways to connect agents in a multi-agent system:
|
||||
In multi-agent architectures, agents can be represented as graph nodes. Each agent node executes its step(s) and decides whether to finish execution or route to another agent, including potentially routing to itself (e.g., running in a loop). A common pattern in multi-agent interactions is **handoffs**, where one agent *hands off* control to another. Handoffs allow you to specify:
|
||||
|
||||
- __destination__: target agent to navigate to (e.g., name of the node to go to)
|
||||
- __payload__: [information to pass to that agent](#communication-between-agents) (e.g., state update)
|
||||
- __payload__: [information to pass to that agent](#communication-and-state-management) (e.g., state update)
|
||||
|
||||
To implement handoffs in LangGraph, agent nodes can return [`Command`](./low_level.md#command) object that allows you to combine both control flow and state updates:
|
||||
|
||||
@@ -52,7 +52,7 @@ def agent(state) -> Command[Literal["agent", "another_agent"]]:
|
||||
)
|
||||
```
|
||||
|
||||
In a more complex scenario where each agent node is itself a graph (i.e., a [subgraph](./low_level.md#subgraphs)), a node in one of the agent subgraphs might want to navigate to a different agent. For example, if you have two agents, `alice` and `bob` (subgraph nodes in a parent graph), and `alice` needs to navigate to `bob`, you can set `graph=Command.PARENT` in the `Command` object:
|
||||
In a more complex scenario where each agent node is itself a graph (i.e., a [subgraph](./subgraphs.md)), a node in one of the agent subgraphs might want to navigate to a different agent. For example, if you have two agents, `alice` and `bob` (subgraph nodes in a parent graph), and `alice` needs to navigate to `bob`, you can set `graph=Command.PARENT` in the `Command` object:
|
||||
|
||||
```python
|
||||
def some_node_inside_alice(state):
|
||||
@@ -214,7 +214,7 @@ Check out this [tutorial](https://langchain-ai.github.io/langgraph/tutorials/mul
|
||||
|
||||
### Supervisor (tool-calling)
|
||||
|
||||
In this variant of the [supervisor](#supervisor) architecture, we define individual agents as **tools** and use a tool-calling LLM in the supervisor node. This can be implemented as a [ReAct](./agentic_concepts.md#react-implementation)-style agent with two nodes — an LLM node (supervisor) and a tool-calling node that executes tools (agents in this case).
|
||||
In this variant of the [supervisor](#supervisor) architecture, we define a supervisor [agent](./agentic_concepts.md#agent-architectures) which is responsible for calling sub-agents. The sub-agents are exposed to the supervisor as tools, and the supervisor agent decides which tool to call next. The supervisor agent follows a [standard implementation](./agentic_concepts.md#tool-calling-agent) as an LLM running in a while loop calling tools until it decides to stop.
|
||||
|
||||
```python
|
||||
from typing import Annotated
|
||||
@@ -413,5 +413,5 @@ There are two high-level approaches to achieve that:
|
||||
|
||||
An agent might need to have a different state schema from the rest of the agents. For example, a search agent might only need to keep track of queries and retrieved documents. There are two ways to achieve this in LangGraph:
|
||||
|
||||
- Define [subgraph](./low_level.md#subgraphs) agents with a separate state schema. If there are no shared state keys (channels) between the subgraph and the parent graph, it’s important to [add input / output transformations](../how-tos/subgraph.ipynb#different-state-schemas) so that the parent graph knows how to communicate with the subgraphs.
|
||||
- Define [subgraph](./subgraphs.md) agents with a separate state schema. If there are no shared state keys (channels) between the subgraph and the parent graph, it’s important to [add input / output transformations](../how-tos/subgraph.ipynb#different-state-schemas) so that the parent graph knows how to communicate with the subgraphs.
|
||||
- Define agent node functions with a [private input state schema](../how-tos/graph-api.ipynb/#pass-private-state-between-nodes) that is distinct from the overall graph state schema. This allows passing information that is only needed for executing that particular agent.
|
||||
@@ -16,7 +16,7 @@ There are three main categories of data you can stream:
|
||||
|
||||
## What’s possible with LangGraph streaming
|
||||
|
||||
- [**Stream LLM tokens**](../how-tos/streaming.md#llm-tokens-messages) — capture token streams from anywhere: inside nodes, subgraphs, or tools.
|
||||
- [**Stream LLM tokens**](../how-tos/streaming.md#messages) — capture token streams from anywhere: inside nodes, subgraphs, or tools.
|
||||
- [**Emit progress notifications from tools**](../how-tos/streaming.md#stream-custom-data) — send custom updates or progress signals directly from tool functions.
|
||||
- [**Stream from subgraphs**](../how-tos/streaming.md#subgraphs) — include outputs from both the parent graph and any nested subgraphs.
|
||||
- [**Use any LLM**](../how-tos/streaming.md#use-with-any-llm) — stream tokens from any LLM, even if it's not a LangChain model using the `custom` streaming mode.
|
||||
|
||||
@@ -142,7 +142,7 @@ To use `interrupt` in your graph, you need to:
|
||||
1. [**Specify a checkpointer**](../../concepts/persistence.md#checkpoints) to save the graph state after each step.
|
||||
2. **Call `interrupt()`** in the appropriate place. See the [Design Patterns](#design-patterns) section for examples.
|
||||
3. **Run the graph** with a [**thread ID**](../../concepts/persistence.md#threads) until the `interrupt` is hit.
|
||||
4. **Resume execution** using `invoke`/`ainvoke`/`stream`/`astream` (see [**The `Command` primitive**](#the-command-primitive)).
|
||||
4. **Resume execution** using `invoke`/`ainvoke`/`stream`/`astream` (see [**The `Command` primitive**](#resume-using-the-command-primitive)).
|
||||
|
||||
## Design patterns
|
||||
|
||||
|
||||
@@ -66,14 +66,13 @@ Basic usage example:
|
||||
|
||||
### Supported stream modes
|
||||
|
||||
| Mode | Description |
|
||||
|-------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [`values`](#stream-graph-state) | Streams the full value of the state after each step of the graph. |
|
||||
| [`updates`](#stream-graph-state) | Streams the updates to the state after each step of the graph. If multiple updates are made in the same step (e.g., multiple nodes are run), those updates are streamed separately. |
|
||||
| [`custom`](#custom) | Streams custom data from inside your graph nodes. |
|
||||
| [`messages`](#messages) | Streams LLM tokens and metadata for the graph node where the LLM is invoked. |
|
||||
| [`debug`](#debug) | Streams as much information as possible throughout the execution of the graph. |
|
||||
|
||||
| Mode | Description |
|
||||
|----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [`values`](#stream-graph-state) | Streams the full value of the state after each step of the graph. |
|
||||
| [`updates`](#stream-graph-state) | Streams the updates to the state after each step of the graph. If multiple updates are made in the same step (e.g., multiple nodes are run), those updates are streamed separately. |
|
||||
| [`custom`](#stream-custom-data) | Streams custom data from inside your graph nodes. |
|
||||
| [`messages`](#messages) | Streams LLM tokens and metadata for the graph node where the LLM is invoked. |
|
||||
| [`debug`](#debug) | Streams as much information as possible throughout the execution of the graph. |
|
||||
|
||||
### Stream multiple modes
|
||||
|
||||
@@ -474,7 +473,7 @@ To send **custom user-defined data** from inside a LangGraph node or tool, follo
|
||||
|
||||
In async code running on Python < 3.11, `get_stream_writer()` will not work.
|
||||
Instead, add a `writer` parameter to your node or tool and pass it manually.
|
||||
See [Async with Python < 3.11](#async-with-python-3-11) for usage examples.
|
||||
See [Async with Python < 3.11](#async) for usage examples.
|
||||
|
||||
|
||||
=== "node"
|
||||
|
||||
@@ -290,10 +290,12 @@ for mode, chunk in main.stream( # (5)!
|
||||
('updates', {'main': 5})
|
||||
```
|
||||
|
||||
|
||||
|
||||
!!! important "Async with Python < 3.11"
|
||||
|
||||
If using Python < 3.11 and writing async code, using `get_stream_writer()` will not work. Instead please
|
||||
use the `StreamWriter` class directly. See [Async with Python < 3.11](../how-tos/streaming.md#async-with-python-<3.11) for more details.
|
||||
use the `StreamWriter` class directly. See [Async with Python < 3.11](../how-tos/streaming.md#async) for more details.
|
||||
|
||||
```python
|
||||
from langgraph.types import StreamWriter
|
||||
|
||||
@@ -65,7 +65,7 @@ The results are page summaries our chat bot can use to answer questions:
|
||||
|
||||
## 4. Define the graph
|
||||
|
||||
For the `StateGraph` you created in the [first tutorial](./1-build-basic-chatbot.md#2-create-a-stategraph), add `bind_tools` on the LLM. This lets the LLM know the correct JSON format to use if it wants to use the search engine.
|
||||
For the `StateGraph` you created in the [first tutorial](./1-build-basic-chatbot.md), add `bind_tools` on the LLM. This lets the LLM know the correct JSON format to use if it wants to use the search engine.
|
||||
|
||||
Let's first select our LLM:
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
Agents can be unreliable and may need human input to successfully accomplish tasks. Similarly, for some actions, you may want to require human approval before running to ensure that everything is running as intended.
|
||||
|
||||
LangGraph's [persistence](../../concepts/persistence.md) layer supports **human-in-the-loop** workflows, allowing execution to pause and resume based on user feedback. The primary interface to this functionality is the [`interrupt`](../../concepts/human_in_the_loop.md#interrupt) function. Calling `interrupt` inside a node will pause execution. Execution can be resumed, together with new input from a human, by passing in a [Command](../../concepts/human_in_the_loop.md#the-command-primitive). `interrupt` is ergonomically similar to Python's built-in `input()`, [with some caveats](../../concepts/human_in_the_loop.md#interrupt).
|
||||
LangGraph's [persistence](../../concepts/persistence.md) layer supports **human-in-the-loop** workflows, allowing execution to pause and resume based on user feedback. The primary interface to this functionality is the [`interrupt`](../../how-tos/human_in_the_loop/add-human-in-the-loop.md) function. Calling `interrupt` inside a node will pause execution. Execution can be resumed, together with new input from a human, by passing in a [Command](../../concepts/low_level.md#command). `interrupt` is ergonomically similar to Python's built-in `input()`, [with some caveats](../../how-tos/human_in_the_loop/add-human-in-the-loop.md).
|
||||
|
||||
!!! note
|
||||
|
||||
@@ -165,7 +165,7 @@ snapshot.next
|
||||
|
||||
## 5. Resume execution
|
||||
|
||||
To resume execution, pass a [`Command`](../../concepts/human_in_the_loop.md#the-command-primitive) object containing data expected by the tool. The format of this data can be customized based on needs. For this example, use a dict with a key `"data"`:
|
||||
To resume execution, pass a [`Command`](../../concepts/low_level.md#command) object containing data expected by the tool. The format of this data can be customized based on needs. For this example, use a dict with a key `"data"`:
|
||||
|
||||
``` python
|
||||
human_response = (
|
||||
|
||||
File diff suppressed because one or more lines are too long
+2
-2
@@ -421,7 +421,7 @@ validation:
|
||||
# it's only an issue for tutorials/storm/storm.ipynb
|
||||
# because it creates anchors in the generated report
|
||||
# and those anchors are not available in the actual doc
|
||||
anchors: info
|
||||
anchors: warn
|
||||
# this is needed to handle headers with anchors for nav
|
||||
not_found: info
|
||||
copyright: >
|
||||
@@ -430,4 +430,4 @@ extra_css:
|
||||
- stylesheets/navigation_title_ovverides.css
|
||||
- stylesheets/version_admonitions.css
|
||||
- stylesheets/logos.css
|
||||
- stylesheets/sticky_navigation.css
|
||||
- stylesheets/sticky_navigation.css
|
||||
|
||||
Reference in New Issue
Block a user