LangGraph 图工程三年实践
原文：3 Years of Graph Engineering with LangGraph 作者：Sydney Runkle & Harrison Chase 日期：2026-07-22
「图工程（Graph Engineering）」这个词上周末火了，起因是这条推文。它是 X 平台 AI 内容工厂产出的最新术语，继提示工程、上下文工程、Harness 工程和循环工程之后又一个新词。
说这些词是热词既诱人也准确，但它们的存在和涌现是有原因的：它们确实描述了构建者面临的真实挑战和设计决策。
归根结底，目标是驾驭 LLM 的力量来为我们做有用的事。你用提示、Agent、循环还是图，这些只是实现细节。之所以涌现出这么多术语，是因为让 LLM 干活真的很难。它们是一种新型的、不鲁棒的、非确定性软件，我们不断尝试新的策略来让它们工作。而这些新策略又催生了新的热词。
抛开热词不谈，将 Agent 系统表示为图（即「图工程」）是一种相当合理的驾驭 LLM 的方式。具体来说，它允许你（作为构建者）将你对系统应当如何运作的先验认知施加到更受限的路径中，而不是完全依赖 LLM 的判断。更实际地说，它让你在希望 Agent 遵循特定路径时能够更紧地控制行为。
正是这种直觉驱动我们在三年前构建了 LangGraph，一个帮助构建这类 Agent 系统的框架。如今，LangGraph 月下载量超过 6500 万次，被创业公司和大型企业广泛使用。相比市面上琳琅满目的 Agent 框架，LangGraph 之所以能脱颖而出，是因为它在确定性路径和 Agent 化步骤之间取得了一种平衡。
以下是我们三年来将 Agent 系统构建为图的实践心得。
将 Agent 建模为图
图给你一种具体的方式来定义 Agent 遵循的工作流。
在 LangGraph 中，节点做工作。一个节点可以是一段确定性代码、一次 LLM 调用、一次工具调用，或者一个拥有自己内部循环的完整 Agent。边定义下一步做什么。有些边是确定性的，另一些是条件性的——取决于节点结果、当前状态或某些外部信号。
你可以把这看作一个状态机。图定义工作流、在其中流转的状态，以及步骤之间的转换。
何时将 Agent 表示为图
真实世界的 Agent 工作流通常具有可预测的结构：客服 Agent 在回答问题或升级处理前会先分类用户问题，编码 Agent 在提出修改建议前会先检查代码仓库，合规工作流在采取外部行动前需要审批。
图让你可以直接编码这种结构：有效路径、模型在哪里有选择权、系统应在哪里强制执行确定性行为——而不是每次都指望模型做出正确判断。
通过将系统表示为图，你在编码你对这个系统应该如何运作的领域认知。就像提示词包含领域知识使你的 Agent 区别于通用 ChatGPT 一样，这些「认知架构」也可以做到。
以一个知识库 Agent 为例，它使用三个子代理进行搜索：GitHub Agent 搜索代码、Issue 和 PR，Notion Agent 搜索内部文档和 Wiki，Slack Agent 搜索相关讨论串。工作流有三个固定阶段：分类 → 搜索 → 综合。结果是代码和模型推理协同工作：模型在其能增值的地方进行推理，代码处理其余部分，Agent 变得更便宜、更快、更可预测。
何时不该用图
有些任务本质上是更 Agent 化的，强迫它们进入确定性路径是错误的选择。在这种情况下，你不应该把系统表示为图，而应该直接使用一个 Agent Harness（如 Deep Agents）。
通用的深度研究是一个好例子：研究型 Agent 需要规划、委托、搜索、阅读和综合，这些步骤很难提前确定下来。我们最早在预定义的 LangGraph 工作流上构建深度研究，后来迁移到更 Agent 化的核心循环。GPT Researcher，一个流行的深度研究实现，也做了同样的迁移——把图状的多 Agent 流水线换成 Deep Agents，让规划、委托和上下文管理在 Harness 中涌现，而不是硬编码在图里。
LangGraph 教给我们的事
我们三年来一直在构建图驱动的 Agent。以下是我们学到的东西。
第一，Agent 图通常不是 DAG。 生产级 Agent 需要循环：重试失败的工具调用、向用户询问缺失的信息、经过验证后修改回答、反复调用工具直到获得足够的上下文、暂停等待人工输入再恢复。循环是 Agent 系统的核心部分，所以 Agent 图大概率不是 DAG。
第二，循环就是简单的图。 循环工程不是图的替代品，而是图的简单版本。正如 David Khourshid 所说，循环就是一个有向循环图。事实上，基于简单 Agent 循环的 LangChain 框架也是构建在 LangGraph 之上的。
第三，动态转换很重要。 你并不总是想提前定义每一条边。有时一个节点在运行时才决定要创建多少工作量。Map-Reduce 就是经典案例：将输入拆分成多份，每份发给一个工作者，然后合并结果。工作者的数量取决于输入，你无法提前知道这个数字。LangGraph 通过 Send 来处理这个问题，它让节点可以将工作动态路由到一个或多个下游节点，无需静态定义每条转换。
这一点很重要，因为有用的 Agent 系统混合了已知结构和运行时变化。你可能知道研究应该先展开再综合，但不知道会有多少个来源。你可能知道主管应该向工作者委托，但不知道任务开始前具体要用哪个工作者。图在运行时仍然需要灵活性。
真正新的是什么
将 Agent 系统表示为图并不新，我们已经做了三年了！那么这波「图工程」新浪潮中有没有什么真正改变了的东西？
一个宽容的解读是：变化在于你可以在节点里放什么。早期，节点是确定性代码或单次 LLM 调用。现在，Agent 本身已经可靠到可以托付真实工作，一个节点可以是一次完整的 Agent 运行——你在编排 Agent，而不仅仅是 LLM 调用。
编码 Agent 是这方面最好的例子。它们是当今生产中效果最好、影响最大的 Agent 之一，将其作为一个节点嵌入更大的图中是一种新近变得可行的模式。
考虑一个文档 Agent，它接收一条这样的 Slack 请求：
「帮忙给我们的 API 写份概念文档」
然后产出待审核的 Pull Request：
这个图中每个节点都处于「确定性→Agent 化」光谱的不同位置：
- 固定步骤：Slack 和 Linear 操作由预设代码和 API 调用驱动
- 模型步骤：分类器和综合步骤使用单次 LLM 调用，无工具
- Agent 步骤：参考文档 Agent 和概念文档 Agent 在相关代码库中完成更开放的工作
这种确定性与 Agent 化的混合正是文档 Agent 可预测、强大且高效的原因。
更大的图景
图工程不是一个新想法。它是一个已经确立的构建可靠 Agent 的方法的最新叫法。它和循环工程、Harness 工程背后的理念是一样的：在每一步把模型推理放在正确的位置，配以正确的上下文。
如果你想尝试图工程，试试 LangGraph。
致谢：感谢 @huntlovell 和 @nfcampos 的审阅。
译者注：这篇文章是 LangChain 联合创始人 Harrison Chase 对「图工程」这个新热词的回应，本质上是一篇深度技术博客。核心观点是：图工程不是噱头，它是构建可靠 Agent 系统的有效范式——在确定性代码和 LLM 自由推理之间找到正确的平衡点。对实际开发最有价值的两个判断：(1) 有明确业务流程的场景用图建模，开放式探索任务用纯 Agent Harness；(2) 现代趋势是把 Agent 本身当节点嵌入更大的图中编排。这对我们用 LangGraph 做 Agent 架构设计有直接参考意义。