mirror of
https://github.com/langchain-ai/langgraph.git
synced 2026-09-26 19:45:00 +02:00
update tutorials and how to guides for langgraph (#768)
* stash * stash * stash * cr * cr * cr
This commit is contained in:
Harrison Chase
@@ -30,6 +30,7 @@ Low Level Concepts
|
||||
- [Conditional Entry Point](low_level#conditional-entry-point)
|
||||
- [Send](low_level#send)
|
||||
- [Checkpointer](low_level#checkpointer)
|
||||
- [Threads](low_level#threads)
|
||||
- [Checkpointer states](low_level#checkpointer-state)
|
||||
- [Get state](low_level#get-state)
|
||||
- [Get state history](low_level#get-state-history)
|
||||
|
||||
@@ -226,8 +226,6 @@ graph.set_conditional_entry_point(routing_function, {True: "node_b", False: "nod
|
||||
|
||||
## `Send`
|
||||
|
||||
[`Send`](https://langchain-ai.github.io/langgraph/reference/graphs/#send) is a special type of edge.
|
||||
|
||||
By default, `Nodes` and `Edges` are defined ahead of time and operate on the same shared state. However, there can be cases where the exact edges are not known ahead of time and/or you may want different versions of `State` to exist at the same time. A common of example of this is with `map-reduce` design patterns. In this design pattern, a first node may generate a list of objects, and you may want to apply some other node to all those objects. The number of objects may be unknown ahead of time (meaning the number of edges may not be known) and the input `State` to the downstream `Node` should be different (one for each generated object).
|
||||
|
||||
To support this design pattern, LangGraph supports returning [`Send`](https://langchain-ai.github.io/langgraph/reference/graphs/#send) objects from conditional edges. `Send` takes two arguments: first is the name of the node, and second is the state to pass to that node.
|
||||
@@ -249,18 +247,35 @@ First, it allows for human-in-the-loop workflows, as it allows humans to inspect
|
||||
|
||||
Second, it allows for "memory" between interactions. You can use checkpointers to create threads and save the state of a thread after a graph executes. In the case of repeated human interactions (like conversations) any follow up messages can be sent to that checkpoint, which will retain its memory of previous ones.
|
||||
|
||||
## Threads
|
||||
|
||||
When using a checkpointer, you must specify a `thread_id` or `thread_ts` when running the graph.
|
||||
Threads are used to checkpoint multiple different runs. This can be used to enable a multi-tenant chat applications.
|
||||
|
||||
`thread_id` is simply the ID of a thread. This is always required
|
||||
|
||||
`thread_ts` can optionally be passed. This identifier refers to a specific checkpoint within a thread. This can be used to kick of a run of a graph from some point halfway through a thread.
|
||||
|
||||
You must pass these when invoking the graph as part of the configurable part of the config.
|
||||
|
||||
```python
|
||||
config = {"configurable": {"thread_id": "a"}}
|
||||
graph.invoke(inputs, config=config)
|
||||
```
|
||||
|
||||
## Checkpointer state
|
||||
|
||||
When you use a checkpointer with a graph, you can interact with the state of that graph.
|
||||
This usually done when enabling different human-in-the-loop interaction patterns.
|
||||
When interacting with the checkpointer state, you must specify [thread identifiers](#threads)
|
||||
|
||||
### Get state
|
||||
|
||||
You can get the state of a checkpointer by calling `graph.get_state(config)`. The config commonly contains things like the `thread_id` of a particular thread to get the state for.
|
||||
You can get the state of a checkpointer by calling `graph.get_state(config)`. The config should contain `thread_id`, and the state will be fetched for that thread.
|
||||
|
||||
### Get state history
|
||||
|
||||
You can also call `graph.get_state_history(config)` to get a list of the history of the graph. The config commonly contains things like the `thread_id` of a particular thread to get the state for.
|
||||
You can also call `graph.get_state_history(config)` to get a list of the history of the graph. The config should contain `thread_id`, and the state history will be fetched for that thread.
|
||||
|
||||
### Update state
|
||||
|
||||
@@ -273,7 +288,7 @@ You can also interact with the state directly and update it. This takes three di
|
||||
|
||||
**config**
|
||||
|
||||
The config commonly contains things like `thread_id` specifying which thread to update.
|
||||
The config should contain `thread_id` specifying which thread to update.
|
||||
|
||||
**values**
|
||||
|
||||
|
||||
+30
-22
@@ -7,36 +7,44 @@ hide:
|
||||
|
||||
Welcome to the LangGraph how-to guides! These guides provide practical, step-by-step instructions for accomplishing key tasks in LangGraph.
|
||||
|
||||
## Basics
|
||||
## Controllability
|
||||
|
||||
These guides show how to address common needs when building out AI workflows, with special focus placed on [ReAct](https://arxiv.org/abs/2210.03629)-style agents with [tool calling](https://python.langchain.com/docs/modules/model_io/chat/function_calling/) (agents that <strong>Re</strong>ason and **Act** to accomplish tasks).
|
||||
|
||||
- [How to create a ReAct agent](create-react-agent.ipynb)
|
||||
- [How to add persistence ("memory") to your graph](persistence.ipynb)
|
||||
- [How to view and update graph state](time-travel.ipynb)
|
||||
- [How to run graph asynchronously](async.ipynb)
|
||||
- [How to stream graph responses](streaming-tokens.ipynb)
|
||||
- [How to visualize your graph](visualization.ipynb)
|
||||
- [How to add runtime configuration to your graph](configuration.ipynb)
|
||||
|
||||
### Design patterns
|
||||
|
||||
Recipes showing how to apply common design patterns in your workflows:
|
||||
LangGraph is known for being a highly controllable agent framework.
|
||||
These how-to guides show how to achieve that controllability.
|
||||
|
||||
- [How to create subgraphs](subgraph.ipynb)
|
||||
- [How to create branches for parallel execution](branching.ipynb)
|
||||
- [How to create map-reduce branches for parallel execution](map-reduce.ipynb)
|
||||
|
||||
## Human in the Loop
|
||||
|
||||
One of LangGraph's main benefits is that it makes human-in-the-loop workflows easy.
|
||||
These guides cover common examples of that.
|
||||
|
||||
- [How to add persistence ("memory") to your graph](persistence.ipynb)
|
||||
- [How to view and update graph state](time-travel.ipynb)
|
||||
- [How to add human-in-the-loop](human-in-the-loop.ipynb)
|
||||
|
||||
The following examples are useful especially if you are used to LangChain's `AgentExecutor` configurations.
|
||||
## Streaming
|
||||
|
||||
- [How to force an agent to call a tool](force-calling-a-tool-first.ipynb)
|
||||
- [How to pass runtime values to tools](pass-run-time-values-to-tools.ipynb)
|
||||
- [How to let agent return tool results directly](dynamically-returning-directly.ipynb)
|
||||
- [How to have agent respond in structured format](respond-in-format.ipynb)
|
||||
- [How to manage agent steps](managing-agent-steps.ipynb)
|
||||
LangGraph is built to be streaming first.
|
||||
These guides show how to use different streaming modes.
|
||||
|
||||
### Advanced
|
||||
- [How to stream LLM tokens](streaming-tokens.ipynb)
|
||||
- [How to stream arbitrarily nested content](streaming-content.ipynb)
|
||||
|
||||
## Other
|
||||
- [How to run graph asynchronously](async.ipynb)
|
||||
- [How to visualize your graph](visualization.ipynb)
|
||||
- [How to add runtime configuration to your graph](configuration.ipynb)
|
||||
- [How to use a Pydantic model as your state](state-model.ipynb)
|
||||
- [How to extract structured output with re-prompting](./extraction/retries.ipynb)
|
||||
|
||||
## Prebuilt ReAct Agent
|
||||
|
||||
These guides show how to use the prebuilt ReAct agent.
|
||||
Please note that here will we use a **prebuilt agent**. One of the big benefits of LangGraph is that you can easily create your own agent architectures. So while it's fine to start here to build an agent quickly, we would strongly recommend learning how to build your own agent so that you can take full advantage of LangGraph.
|
||||
|
||||
- [How to create a ReAct agent](create-react-agent.ipynb)
|
||||
- [How to add memory to a ReAct agent](create-react-agent-memory.ipynb)
|
||||
- [How to add a custom system prompt to a ReAct agent](create-react-agent-system-prompt.ipynb)
|
||||
- [How to add human-in-the-loop processes to a ReAct agent](create-react-agent-hitl.ipynb)
|
||||
|
||||
@@ -63,4 +63,6 @@ Learn from example implementations of graphs designed for specific scenarios and
|
||||
- [Web Research (STORM)](storm/storm.ipynb): Generate Wikipedia-like articles via research and multi-perspective QA
|
||||
- [TNT-LLM](tnt-llm/tnt-llm.ipynb): Build rich, interpretable taxonomies of user intentand using the classification system developed by Microsoft for their Bing Copilot application.
|
||||
- [Web Navigation](web-navigation/web_voyager.ipynb): Build an agent that can navigate and interact with websites
|
||||
- [Competitive Programming](usaco/usaco.ipynb): Build an agent with few-shot "episodic memory" and human-in-the-loop collaboration to solve problems from the USA Computing Olympiad; adapted from the ["Can Language Models Solve Olympiad Programming?"](https://arxiv.org/abs/2404.10952v1) paper by Shi, Tang, Narasimhan, and Yao.
|
||||
- [Competitive Programming](usaco/usaco.ipynb): Build an agent with few-shot "episodic memory" and human-in-the-loop collaboration to solve problems from the USA Computing Olympiad; adapted from the ["Can Language Models Solve Olympiad Programming?"](https://arxiv.org/abs/2404.10952v1) paper by Shi, Tang, Narasimhan, and Yao.
|
||||
- [Complex data extraction](extraction/retries.ipynb): Build an agent that can use function calling to do complex extraction tasks
|
||||
-
|
||||
Reference in New Issue
Block a user