Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering 之后，社区又出现了一个新词：Graph Engineering。
LangChain 的态度很直接：它当然带有 buzzword 色彩，但背后描述的问题真实存在。大模型是一种非确定、并不天然鲁棒的软件组件。开发者必须不断寻找新的结构，让模型在该自主判断的地方判断，在不该自由发挥的地方遵守明确路径。
LangGraph 正是从这种直觉出发。经过三年发展，官方文章称其在发布时月下载量已超过 6500 万。它受欢迎的原因不只是能画工作流，而是试图在确定性路径与 Agent 自主步骤之间取得平衡。
#Graph Engineering 到底在工程什么
图给 Agent 工作流一个可执行表示。
在 LangGraph 中：
- 节点负责完成工作，可以是普通代码、一次模型调用、一次工具调用，也可以是拥有内部循环的完整 Agent；
- 边决定下一步去哪里，可以固定，也可以根据节点结果、当前状态或外部信号动态选择；
- 状态在节点之间流动，保存工作流已经知道什么、完成了什么，以及接下来需要什么。
因此，LangGraph 更接近一个面向 Agent 的状态机，而不是一张只用于展示的流程图。图定义合法路径、状态演化和步骤之间的转换，运行时再由代码或模型执行节点逻辑。
Graph Engineering 的核心问题也不是“如何把所有任务画成图”，而是哪些决策应由系统预先约束，哪些决策应该留给模型。
#什么时候应该使用图
现实中的许多 Agent 工作流都有稳定骨架。
客服 Agent 通常先判断问题类型，再回答或升级；代码 Agent 通常先检查仓库，再提出修改；合规流程通常要求外部操作前获得批准。这些步骤的具体内容可能变化，但顺序和约束相对稳定。
图适合把这类领域知识编码为“认知架构”：
- 哪些路径有效；
- 哪些节点允许模型选择；
- 哪些操作必须由代码强制执行；
- 哪些位置需要人类审批；
- 失败后应该重试、回退还是暂停。
提示词保存的是任务层面的知识，图保存的是系统应当如何运行的知识。两者共同把一个通用模型变成特定业务里的 Agent。
#一个知识库 Agent 的图结构
假设一个企业知识 Agent 有三类搜索能力：GitHub Agent 查代码、Issue 和 Pull Request，Notion Agent 查内部文档，Slack Agent 查相关讨论。
工作流可以保留三段固定结构：分类、搜索、综合。
第一步由模型判断问题与哪些知识源相关；第二步并行调用相应搜索 Agent；第三步综合结果并生成带来源的答案。模型负责语义判断，代码负责调度、等待和汇总。
这种结构的价值不是“使用了多个 Agent”，而是让每一层只承担擅长的工作：模型处理模糊语义，确定性代码处理已知控制流。结果通常更便宜、更快，也更容易预测。
#什么时候不应该使用图
并非所有任务都有稳定的阶段划分。通用深度研究就是典型反例。
研究 Agent 需要规划、委派、搜索、阅读和综合，但每一步的数量、顺序与目标都会根据新信息变化。提前把所有路径硬编码进图，可能让系统为了遵守结构而失去探索能力。
LangChain 自己早期用预定义 LangGraph 工作流实现深度研究，后来转向更自主的 Agent 核心循环。GPT Researcher 也从图形化多 Agent 管线迁移到 Deep Agents，让规划、委派和上下文管理在 Harness 中动态发生。
这并不表示图与 Harness 二选一。更准确的区别是：
- 已知、稳定、需要强约束的结构放进图；
- 开放、难以预判、需要持续探索的部分放进 Agent Harness；
- 完整 Agent 仍然可以作为一个节点嵌入更大的图。
图负责边界，Harness 负责边界内的自主行动。
#第一条经验：生产 Agent 通常不是 DAG
很多数据管线使用有向无环图，因为任务从输入单向流向输出。但生产 Agent 经常需要循环：
- 工具调用失败后重试；
- 信息不足时向用户追问；
- 校验失败后修改答案；
- 反复调用工具直到上下文充足；
- 等待人类输入后从原位置恢复。
这些行为天然形成环。因此，Agent 图不应被误解为一次性从左到右执行的 DAG。循环不是异常路径，而是 Agent 处理不确定性的基本方式。
#第二条经验：Loop Engineering 本身就是图工程
Loop Engineering 经常被描述成 Graph Engineering 的替代方案，但循环本身就是最简单的有向循环图。
典型 Agent Loop 只有少数状态：模型思考、选择工具、观察结果，然后决定继续调用工具还是输出答案。它结构简单，却仍然包含节点、边、状态和终止条件。
LangChain 的基础 Agent 循环本身构建在 LangGraph 之上，也说明两种工程方法并不冲突。Loop Engineering 关注如何打磨一个核心循环；Graph Engineering 关注如何组合一个或多个循环，以及它们与确定性步骤之间的关系。
#第三条经验：图必须支持运行时动态转换
图有结构，不代表所有边都必须提前写死。
Map-Reduce 是最清楚的例子：系统知道应该拆分输入、分发给多个 Worker，然后合并结果，却无法在编译时知道需要几个 Worker。数量取决于任务本身。
LangGraph 的 Send API 允许一个节点在运行时把工作发送给一个或多个下游节点，不需要静态定义每一条转换。
动态转换让系统能够同时拥有已知骨架与运行时弹性：
- 研究任务确定要先分散搜索再综合，但来源数量动态变化；
- Supervisor 确定要委派任务，但具体需要哪些 Worker 运行后才知道；
- 文档处理确定要逐项分析，但文件数量来自用户输入。
真正实用的 Agent 图不是固定流程，而是带有受控动态性的状态机。
#三年后真正改变的，是节点里能放什么
用图描述软件系统不是新想法。Graph Engineering 今天重新受到关注，最合理的解释不是图本身变新，而是图节点的能力发生了变化。
早期节点通常是确定性代码或一次模型调用。如今 Agent 已经足够可靠，可以把一次完整 Agent 运行封装为节点。开发者编排的不再只是 LLM 调用，而是具备工具、上下文管理和内部循环的 Agent。
代码 Agent 是最典型的例子。它可以在一个节点内阅读仓库、搜索引用、修改文件并运行测试，外层图只负责决定什么时候调用它、向它传递什么目标，以及结果通过什么验证后进入下一阶段。
#一个文档 Agent 如何混合三种节点
文章给出一个把 Slack 请求变成待审核 Pull Request 的文档 Agent。它同时包含三种自动化层级：
#固定步骤
Slack 和 Linear 操作通过确定性代码与 API 完成。这些步骤协议清晰、输入输出稳定，不需要模型自由发挥。
#模型步骤
分类和最终综合使用不带工具的单次模型调用。它们需要语义理解，却没有必要启动完整 Agent Loop。
#Agent 步骤
参考文档 Agent 和概念文档 Agent 在各自代码库中完成开放任务。它们需要搜索、阅读、编辑和验证，因此适合用完整 Agent。
三个层级组合在同一张图里：固定步骤保证协议正确，模型步骤完成轻量判断，Agent 步骤处理开放工作。系统不会因为使用了 Agent，就让所有节点都变成 Agent。
#如何选择图、循环与 Harness
面对一个新任务，可以用四个问题判断结构：
- 哪些步骤无论输入如何都必须发生？把它们放进确定性图路径。
- 哪些位置只需要一次语义判断？使用单次模型节点。
- 哪些任务需要反复使用工具并根据结果调整计划？使用 Agent 节点或 Harness。
- 哪些动作具有外部影响或合规风险？在图上设置强制审批与恢复点。
不要为了“更 Agentic”而删除所有结构，也不要为了可控而预先规定模型的每一步。好的架构是让自主性与任务的不确定性成比例。
#Graph Engineering 的本质是分配判断权
三年的 LangGraph 实践最终指向一个朴素结论：可靠 Agent 不是把一切交给模型，也不是把一切写成流程。
Graph Engineering、Loop Engineering 和 Harness Engineering 都在回答同一个问题——模型应该在什么位置、拿着什么上下文、拥有多大判断权。
图的价值，是把开发者对系统的先验知识变成可执行约束；Agent 的价值，是在约束无法覆盖的空间里处理不确定性。当完整 Agent 可以成为图节点之后，两者之间不再是阵营选择，而是不同粒度的组合。