# 3 Years of Graph Engineering with LangGraph
**作者**: Sydney Runkle
**日期**: 2026-07-18T00:34:54.000Z
**来源**: [https://x.com/sydneyrunkle/status/2079904256199360815](https://x.com/sydneyrunkle/status/2079904256199360815)
---
"Graph engineering" surfaced this weekend, kicked off by this tweet:
> **Peter Steinberger @steipete**: [原文链接](https://x.com/steipete/status/2078277297791189132)
>
> Are we still talking loops or did we shift to graphs yet?
It's the latest term to come out of X's AI content factory, joining prompt engineering, context engineering, harness engineering, and loop engineering. While it’s both tempting and accurate to call these terms buzzwords, they exist and emerge for a reason: they do describe real challenges and design decisions builders face.
At the end of the day, the goal is to harness the power of LLMs to do useful things for us. Whether you use prompting or agents or loops or graphs, those are implementation details. The reason so many terms exist is that getting LLMs to do work is hard. They are a new type of non-robust, non-deterministic software and we’re constantly trying new strategies to get them to work. And these new strategies lead to new buzzwords.
Buzzwords aside, representing agentic systems as graphs (”graph engineering”) is a very reasonable way to harness the power of LLMs. Specifically, it allows you (as the builder) to impose your preconceptions of how the system should work into more constrained paths, not relying solely on the judgement of the LLM. More concretely, it lets you more tightly control behavior when you want the agent to follow specific paths.
This intuition drove us to build LangGraph three years ago, as a framework to help build these types of agentic systems. Today, LangGraph is downloaded 65M+ times a month, and used by startups and enterprises alike.
Compared to the myriad of other agent frameworks out there, the reason LangGraph rose in popularity is because of the balance it strikes between deterministic paths and agentic steps.
Here’s what we’ve learned from years of building agentic systems as graphs.
## Modeling agents as graphs
A graph gives you a concrete way to define the workflow an agent follows.
In LangGraph, nodes do work. A node can be deterministic code, a single LLM call, a tool call, or a full agent with its own internal loop.
Edges define what happens next. Some edges are deterministic. Others are conditional, based on the result of a node, the current state, or some external signal.
You can think of this as a state machine. The graph defines the workflow, the state that moves through it, and the transitions between steps.
## When to represent agents as graphs
Real-world agent workflows often have predictable structure: a support agent classifies an issue before answering or escalating, a coding agent inspects the repository before proposing a change, and a compliance workflow requires approval before taking an external action.
Graphs let you encode that structure directly: the valid paths, where the model gets to choose, and where the system should enforce deterministic behavior instead of hoping the model makes the right call every time.
By representing the system as a graph, you are encoding your world knowledge of how this system should work. Just as prompts contain domain knowledge that separates your agent from generic ChatGPT, so can these “cognitive architectures”.
Take a knowledge base agent that uses three subagents for search: a GitHub agent for code, issues, and pull requests, a Notion agent for internal docs and wikis, and a Slack agent for relevant threads. The workflow has three fixed stages: classify, search, synthesize.
The result is code and model reasoning working together: the model reasons where it adds value, code handles the rest, and the agent gets cheaper, faster, and more predictable.
## When not to use custom graphs
Some tasks are more agentic by nature, and forcing them into deterministic paths is the wrong move. In these cases, you don’t want to represent the system as a graph but rather just use an agent harness (like Deep Agents).
Generic deep research is a good example: a research agent needs to plan, delegate, search, read, and synthesize in ways that are hard to pin down ahead of time. We built early deep research on predefined LangGraph workflows, then moved to a more agentic core loop. GPT Researcher, a popular deep research implementation, recently made the same move, swapping its graph-shaped multi-agent pipeline for Deep Agents so planning, delegation, and context management emerge in the harness rather than being hardcoded in the graph.
## What building LangGraph taught us
We've been building agents powered by graphs for the last three years. Here's what we've learned.
First, agent graphs are usually not DAGs.
Production agents need cycles: retrying failed tool calls, asking users for missing information, revising answers after validation, calling tools repeatedly until they have enough context, and pausing for human input before resuming. Looping is a core part of agentic systems, so they are likely not DAGs.
Second, loops are simple graphs.
Loop engineering isn't an alternative to graphs, so much as a simple version of them. As David Khourshid put it, a loop is just a directed, cyclic graph. In fact, the LangChain framework, which is based on a simple agentic loop, is built on top of LangGraph.
Third, dynamic transitions matter.
You do not always want to define every edge up front. Sometimes a node decides at runtime how much work to create. Map-reduce is the classic case: split an input into pieces, send each to a worker, then combine the results. The number of workers depends on the input, and you do not know that number in advance.
LangGraph handles this with Send, which lets a node route work to one or more downstream nodes dynamically, without statically defining every transition.
This is important because useful agent systems mix known structure with runtime variability. You might know research should fan out and then synthesize, but not how many sources there will be. You might know a supervisor should delegate to workers, but not know which specific workers to use until the task starts. Graphs still need flexibility at runtime.
## What's actually new
Representing agentic systems as graphs isn't new, we've been doing it for three years! So has anything actually changed in this new wave of “graph engineering”?
A generous interpretation would say that what's changed is what you can put inside a node. Early on, nodes were deterministic code or a single LLM call. Now that agents themselves are reliable enough to trust with real work, a node can be a full agent run, so you're orchestrating agents, not just LLM calls.
Coding agents are a good example of this. They're some of the most effective and impactful agents in production today, and embedding one as a node inside a larger graph is a newly practical pattern.
Consider a docs agent that turns a slack request, like this:
Into a ready for review pull request:
Each node in this graph sits at a different point on the deterministic-to-agentic scale:
- Fixed steps: the slack and linear operations are powered by set code and API calls.
- Model steps: the classifier and the synthesize step use a single LLM call with no tools.
- Agent steps: the reference docs agent and the conceptual docs agent complete more open ended work in their relevant codebases.
The mix of determinism and agency here is what makes this docs agent predictable, powerful, and efficient.
## The bigger idea
Graph engineering isn't a new idea. It's the latest name for a well established approach to building reliable agents.
It's the same idea behind loop engineering and harness engineering: building putting model reasoning in the right places, with the right context, at each step.
If you want to try out graph engineering, try out LangGraph.
## Acknowledgements
Co-authored by @hwchase17.
Thanks to @huntlovell and @nfcampos for thoughtful review!
## 相关链接
- [Harrison Chase reposted](https://x.com/hwchase17)
- [Sydney Runkle](https://x.com/sydneyrunkle)
- [@sydneyrunkle](https://x.com/sydneyrunkle)
- [4.5K](https://x.com/sydneyrunkle/status/2079904256199360815/analytics)
- [Jul 18](https://x.com/steipete/status/2078277297791189132)
- [2.9M](https://x.com/steipete/status/2078277297791189132/analytics)
- [LangGraph](https://docs.langchain.com/oss/python/langgraph/overview)
- [nodes](https://docs.langchain.com/oss/python/langgraph/graph-api#nodes)
- [Edges](https://docs.langchain.com/oss/python/langgraph/graph-api#edges)
- [cognitive architectures](https://www.langchain.com/blog/what-is-a-cognitive-architecture)
- [agent harness](https://www.langchain.com/blog/the-anatomy-of-an-agent-harness)
- [Deep Agents](https://docs.langchain.com/oss/python/deepagents/overview)
- [GPT Researcher](https://github.com/assafelovic/gpt-researcher)
- [swapping its graph-shaped multi-agent pipeline for Deep Agents](https://github.com/assafelovic/gpt-researcher/blob/main/deep_agents/README.md)
- [Loop engineering](https://www.langchain.com/blog/the-art-of-loop-engineering)
- [As David Khourshid put it](https://x.com/DavidKPiano/status/2079209887158989231)
- [LangChain](https://docs.langchain.com/build-overview)
- [Send](https://docs.langchain.com/oss/python/langgraph/use-graph-api#map-reduce-and-the-send-api)
- [loop engineering](https://www.langchain.com/blog/the-art-of-loop-engineering)
- [harness engineering](https://www.langchain.com/blog/how-to-build-a-custom-agent-harness)
- [LangGraph](https://docs.langchain.com/oss/python/langgraph/overview)
- [@hwchase17](https://x.com/@hwchase17)
- [@huntlovell](https://x.com/@huntlovell)
- [@nfcampos](https://x.com/@nfcampos)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [8:19 PM · Jul 22, 2026](https://x.com/sydneyrunkle/status/2079904256199360815)
- [4,506 Views](https://x.com/sydneyrunkle/status/2079904256199360815/analytics)
- [View quotes](https://x.com/sydneyrunkle/status/2079904256199360815/quotes)
---
*导出时间: 2026/7/22 21:43:01*
---
## 中文翻译
# 使用 LangGraph 进行图工程的三年
**作者**: Sydney Runkle
**日期**: 2026-07-18T00:34:54.000Z
**来源**: [https://x.com/sydneyrunkle/status/2079904256199360815](https://x.com/sydneyrunkle/status/2079904256199360815)
---
“图工程”这个概念在这个周末浮出水面，始于这条推文：
> **Peter Steinberger @steipete**: [原文链接](https://x.com/steipete/status/2078277297791189132)
>
> 我们还在讨论循环，还是已经转向图了？
这是 X 平台 AI 内容工厂产出的最新术语，与提示工程、上下文工程、套索工程和循环工程并列。虽然将这些术语称为流行语既诱人又准确，但它们的存在和涌现是有原因的：它们确实描述了构建者面临的实际挑战和设计决策。
归根结底，目标是利用 LLM 的力量为我们做有用的事情。无论你使用提示、代理、循环还是图，这些都只是实现细节。之所以存在这么多术语，是因为让 LLM 干活很难。它们是一种新型的不稳健、非确定性软件，我们不断尝试新策略来让它们工作。而这些新策略导致了新的流行语。
撇开流行语不谈，将代理系统表示为图（“图工程”）是利用 LLM 能力的一种非常合理的方式。具体来说，它允许你（作为构建者）将你对系统应该如何工作的预判施加到更受约束的路径上，而不完全依赖 LLM 的判断。更具体地说，当你希望代理遵循特定路径时，它能让你更紧密地控制行为。
正是这种直觉促使我们在三年前构建了 LangGraph，作为一个帮助构建此类代理系统的框架。如今，LangGraph 每月下载量超过 6500 万次，被初创公司和企业广泛使用。
与市面上无数其他的代理框架相比，LangGraph 之所以能兴起，是因为它在确定性路径和代理步骤之间取得了平衡。
以下是我们在将代理系统构建为图的多年过程中学到的东西。
## 将代理建模为图
图为你提供了一种定义代理所遵循工作流的具体方式。
在 LangGraph 中，节点负责工作。节点可以是确定性代码、单次 LLM 调用、工具调用，或者是具有自己内部循环的完整代理。
边定义接下来发生的事情。有些边是确定性的。其他的则是基于节点的结果、当前状态或某些外部信号的条件边。
你可以将其视为一个状态机。图定义了工作流、流经其中的状态以及步骤之间的转换。
## 何时将代理表示为图
现实世界的代理工作流通常具有可预测的结构：支持代理在回答或升级之前对问题进行分类，代码代理在提出更改之前检查仓库，合规工作流在采取外部行动之前需要批准。
图让你可以直接编码这种结构：有效路径、模型拥有选择权的地方，以及系统应该强制执行确定性行为而不是寄希望于模型每次都做出正确判断的地方。
通过将系统表示为图，你正在编码关于该系统应该如何工作的世界知识。正如提示词包含将你的代理与通用 ChatGPT 区分开来的领域知识一样，这些“认知架构”也能做到这一点。
以一个使用三个子代理进行搜索的知识库代理为例：一个用于代码、问题和拉取请求的 GitHub 代理，一个用于内部文档和 Wiki 的 Notion 代理，以及一个用于相关线索的 Slack 代理。该工作流有三个固定阶段：分类、搜索、综合。
结果是代码和模型推理协同工作：模型在其能增加价值的地方进行推理，代码处理其余部分，代理变得更便宜、更快速且更可预测。
## 何时不使用自定义图
有些任务本质上更具代理性，强行将它们纳入确定性路径是错误的举动。在这些情况下，你不希望将系统表示为图，而是只想使用代理套索（如 Deep Agents）。
通用深度研究就是一个很好的例子：研究代理需要以难以预先确定的方式进行规划、委派、搜索、阅读和综合。我们在预定义的 LangGraph 工作流上构建了早期的深度研究，然后转向了更核心的代理循环。GPT Researcher，一个流行的深度研究实现，最近也做出了同样的转变，将其图形化的多代理流水线换成了 Deep Agents，以便规划、委派和上下文管理在套索中涌现，而不是硬编码在图中。
## 构建 LangGraph 教给了我们什么
在过去三年里，我们一直在构建由图驱动的代理。以下是我们学到的东西。
首先，代理图通常不是 DAG（有向无环图）。
生产级代理需要循环：重试失败的工具调用，向用户询问缺失信息，在验证后修改答案，反复调用工具直到获得足够的上下文，以及在恢复之前暂停等待人工输入。循环是代理系统的核心部分，因此它们很可能不是 DAG。
其次，循环是简单的图。
循环工程并不是图的替代品，它更像是图的一种简单版本。正如 David Khourshid 所说，循环只是一个有向循环图。事实上，基于简单代理循环的 LangChain 框架就是构建在 LangGraph 之上的。
第三，动态转换很重要。
你并不总是希望预先定义每一条边。有时，节点会在运行时决定要创建多少工作。Map-reduce 是经典案例：将输入拆分为片段，将每个片段发送给工作线程，然后合并结果。工作线程的数量取决于输入，而你预先并不知道这个数字。
LangGraph 通过 Send 处理这个问题，它允许节点将工作动态路由到一个或多个下游节点，而无需静态定义每个转换。
这很重要，因为有用的代理系统混合了已知结构和运行时变异性。你可能知道研究应该发散然后综合，但不知道会有多少来源。你可能知道主管应该委派给工作线程，但不知道在任务开始之前具体要使用哪些工作线程。图在运行时仍然需要灵活性。
## 实际上什么是新的
将代理系统表示为图并不新鲜，我们已经这样做了三年！那么在这波新的“图工程”浪潮中，究竟有什么改变？
一种宽容的解释是，改变在于你可以在节点内部放什么。早期，节点是确定性代码或单次 LLM 调用。现在，代理本身已经足够可靠，可以胜任实际工作，因此一个节点可以是一次完整的代理运行，所以你是在编排代理，而不仅仅是 LLM 调用。
代码代理就是一个很好的例子。它们是当今生产环境中最有效、最具影响力的代理之一，将其作为节点嵌入到更大的图中是一种新近可行的模式。
考虑一个文档代理，它将 Slack 请求，像这样：
变成一个准备好供审核的拉取请求：
此图中的每个节点都位于确定性-代理谱系的不同点上：
- 固定步骤：Slack 和线性操作由设定的代码和 API 调用驱动。
- 模型步骤：分类器和综合步骤使用不带工具的单次 LLM 调用。
- 代理步骤：参考文档代理和概念文档代理在其相关的代码库中完成更开放的工作。
这里的确定性和代理性的混合，正是让这个文档代理可预测、强大且高效的原因。
## 更大的构想
图工程并不是一个新想法。它只是构建可靠代理这一既定方法的最新名称。
这与循环工程和套索工程背后的想法相同：在每一步都将模型推理放在正确的位置，并赋予正确的上下文。
如果你想尝试图工程，不妨试试 LangGraph。
## 致谢
由 @hwchase17 合著。
感谢 @huntlovell 和 @nfcampos 的悉心审阅！
## 相关链接
- [Harrison Chase reposted](https://x.com/hwchase17)
- [Sydney Runkle](https://x.com/sydneyrunkle)
- [@sydneyrunkle](https://x.com/sydneyrunkle)
- [4.5K](https://x.com/sydneyrunkle/status/2079904256199360815/analytics)
- [Jul 18](https://x.com/steipete/status/2078277297791189132)
- [2.9M](https://x.com/steipete/status/2078277297791189132/analytics)
- [LangGraph](https://docs.langchain.com/oss/python/langgraph/overview)
- [nodes](https://docs.langchain.com/oss/python/langgraph/graph-api#nodes)
- [Edges](https://docs.langchain.com/oss/python/langgraph/graph-api#edges)
- [cognitive architectures](https://www.langchain.com/blog/what-is-a-cognitive-architecture)
- [agent harness](https://www.langchain.com/blog/the-anatomy-of-an-agent-harness)
- [Deep Agents](https://docs.langchain.com/oss/python/deepagents/overview)
- [GPT Researcher](https://github.com/assafelovic/gpt-researcher)
- [swapping its graph-shaped multi-agent pipeline for Deep Agents](https://github.com/assafelovic/gpt-researcher/blob/main/deep_agents/README.md)
- [Loop engineering](https://www.langchain.com/blog/the-art-of-loop-engineering)
- [As David Khourshid put it](https://x.com/DavidKPiano/status/2079209887158989231)
- [LangChain](https://docs.langchain.com/build-overview)
- [Send](https://docs.langchain.com/oss/python/langgraph/use-graph-api#map-reduce-and-the-send-api)
- [loop engineering](https://www.langchain.com/blog/the-art-of-loop-engineering)
- [harness engineering](https://www.langchain.com/blog/how-to-build-a-custom-agent-harness)
- [LangGraph](https://docs.langchain.com/oss/python/langgraph/overview)
- [@hwchase17](https://x.com/@hwchase17)
- [@huntlovell](https://x.com/@huntlovell)
- [@nfcampos](https://x.com/@nfcampos)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [8:19 PM · Jul 22, 2026](https://x.com/sydneyrunkle/status/2079904256199360815)
- [4,506 Views](https://x.com/sydneyrunkle/status/2079904256199360815/analytics)
- [View quotes](https://x.com/sydneyrunkle/status/2079904256199360815/quotes)
---
*导出时间: 2026/7/22 21:43:01*