3 Years of Graph Engineering with LangGraph使用 LangGraph 进行图工程的三年历程

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.在 LangGraph 中，节点负责执行任务。一个节点可以是确定性的代码、单次 LLM 调用、工具调用，也可以是一个拥有完整内部循环的智能体。

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”.通过将系统表示为图，你实际上是在编码你对该系统应如何运作的领域知识。正如提示词中包含的领域知识让你的智能体区别于普通的 ChatGPT 一样，这些“认知架构”也能起到同样的作用。

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.以一个使用三个子智能体进行搜索的知识库智能体为例：一个用于代码、问题和拉取请求的 GitHub 智能体，一个用于内部文档和维基的 Notion 智能体，以及一个用于相关线程的 Slack 智能体。该工作流包含三个固定阶段：分类、搜索、综合。

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 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).有些任务本质上更具自主性，强行将其纳入确定性路径是不明智的。在这种情况下，你不应将系统表示为图，而应仅使用智能体工具链（如 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, 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.通用的深度研究就是一个很好的例子：研究型智能体需要以难以预先确定的方式进行规划、委派、搜索、阅读和综合。我们早期的深度研究是基于预定义的 LangGraph 工作流构建的，后来转向了更具智能体特性的核心循环。流行的深度研究实现 GPT Researcher 也做了同样的调整，将其图结构的各种多智能体管道替换为 Deep Agents，以便规划、委派和上下文管理在工具链中自然涌现，而不是硬编码在图中。

What building LangGraph taught us构建 LangGraph 教会了我们什么

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.首先，智能体图通常不是有向无环图（DAG）。

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.生产环境中的智能体需要循环：重试失败的工具调用、向用户询问缺失信息、在验证后修改答案、反复调用工具直到获得足够的上下文，以及在恢复前暂停等待人工输入。循环是智能体系统的核心部分，因此它们通常不是 DAG。

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.循环工程并不是图工程的替代品，而是其简化的版本。正如 David Khourshid 所言，循环只是一个有向循环图。事实上，基于简单智能体循环的 LangChain 框架，其底层也是构建在 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.你并不总是希望预先定义所有的边。有时节点需要在运行时决定产生多少工作量。Map-reduce 就是经典案例：将输入拆分为多个部分，分发给不同的工作节点，然后合并结果。工作节点的数量取决于输入，而你无法提前知道这个数量。

LangGraph handles this with Send, which lets a node route work to one or more downstream nodes dynamically, without statically defining every transition.LangGraph 通过 Send 功能处理这个问题，它允许节点动态地将工作路由到一个或多个下游节点，而无需静态定义每一条转换路径。

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! Has anything 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 — you're orchestrating agents, not just LLM calls.一个宽泛的解读是，变化在于你可以在节点中放入什么。早期，节点通常是确定性代码或单次 LLM 调用。现在，由于智能体本身已经足够可靠，可以胜任实际工作，因此一个节点可以是一个完整的智能体运行过程——你是在编排智能体，而不仅仅是编排 LLM 调用。

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:考虑一个将 Slack 请求转换为如下形式的文档智能体：

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.固定步骤：Slack 和 Linear 操作由设定的代码和 API 调用驱动。
• Model steps: the classifier and the synthesize step use a single LLM call with no tools.模型步骤：分类器和综合步骤使用单次 LLM 调用，不使用工具。
• 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.如果你想尝试图工程，欢迎体验 LangGraph。