引言：又一个新词，但先别急着下结论
2026 年 7 月的一个周末，Peter Steinberger 的一条推文带起了"Graph Engineering（图工程）"这个说法。LangChain 联合创始人 Harrison Chase 在随后的博客里给出了一个罕见的坦诚开场：这是继 Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering 之后，X 平台"AI 内容工厂"产出的最新一环——称这些词为 buzzword，既容易也准确。
但 Chase 紧接着补充了一句更重要的话：这些词之所以会不断出现，是有真实原因的。LLM 是一种新型的、非鲁棒、非确定性的软件，工程师们在持续尝试各种新策略让它可靠地工作——不管你用的是 Prompt、Agent、Loop 还是 Graph，这些都只是实现细节，目标始终是同一个：让 LLM 的能力真正为你所用。新策略带来新词汇，词汇会更迭，但底层要解决的问题不会变。
这篇文章不打算把 Graph Engineering 包装成什么石破天惊的新发明——事实上 LangGraph 团队自己也说了，这套思路他们已经实践了三年。真正值得讨论的是：这套思路具体是什么、什么时候该用、什么时候不该用，以及行业中一个相当扎实的反面声音——认为这个词正在把很多团队引入一个"更贵、更难调试"的陷阱。
一、概念界定：图是什么，与 Loop、知识图谱有什么关系
1.1 核心定义
Graph Engineering 的核心主张是：把 Agent 系统显式建模为一张图。在 LangGraph 的抽象里，节点（Node）做实际的工作——可以是确定性代码，可以是单次 LLM 调用，可以是工具调用，也可以是一整个带内部循环的完整 Agent；边（Edge）定义下一步发生什么——有些边是确定性的，有些是条件边，依据节点的执行结果、当前状态或某个外部信号来判断走向。
你可以把这套结构类比成一个状态机（State Machine）：图定义了整个工作流、在其中流转的状态，以及步骤与步骤之间的转移规则。这个类比不是随口一提——它恰恰是本文第四部分批判性视角的核心论点所在。
这样做的意义在于，把系统设计者对"这个系统该如何运作"的世界知识，显式编码进拓扑结构里，而不是完全交给模型临场判断。Chase 的表述是：正如 Prompt 里包含的领域知识让你的 Agent 区别于通用 ChatGPT，图这种"认知架构"也在扮演同样的角色——让你能更紧密地控制行为，在你想要 Agent 遵循特定路径的时候，把这条路径直接写进拓扑。
1.2 与 Loop Engineering：包含关系，不是替代关系
一个容易产生的误解是，把 Graph Engineering 理解为 Loop Engineering 的"升级版"或"更高级形态"。LangChain 明确否定了这种递进叙事——“Loop Engineering 不是图的替代方案，而是图的一种简单形式”。用 David Khourshid 的话说：一个循环本质上就是一个有向的、带环的图（directed cyclic graph）[ref:2]。事实上，LangChain 自家基于简单 Agent 循环构建的框架，本身就是搭建在 LangGraph 之上的。
这也解释了为什么生产环境中的 Agent 图通常不是 DAG（有向无环图）：重试失败的工具调用、等待用户补充缺失信息、验证后修改答案、反复调用工具直到信息足够、暂停等待人工输入后再恢复——这些都要求图里存在环。循环（Loop）是核心，图（Graph）只是给这个核心提供了更丰富的拓扑表达能力。
1.3 与知识图谱工程的区分
这里有必要澄清一个纯粹因为同名而容易混淆的概念：本文讨论的 Graph Engineering，与传统意义上的Knowledge Graph（知识图谱）工程是两个完全不同的领域。知识图谱回答的是"系统知道什么"——一种用于表示实体与关系的数据结构；本文讨论的图，回答的是"系统由谁构成、彼此如何协作"——一种用于组织执行流程的编排结构。两者可以出现在同一套架构里（比如一个节点内部检索的是知识图谱），但解决的是完全不同层面的问题，不应混为一谈。
1.4 术语脉络一览
| 术语 | 关注对象 | 核心原语 |
|---|---|---|
| Prompt Engineering | 单轮提示词的表达方式 | 措辞、示例、格式约束 |
| Context Engineering | 该往上下文窗口里放什么信息 | 检索、压缩、排序 |
| Harness Engineering | 单个 Agent 运行所在的环境 | 工具、沙箱、状态持久化、评估 |
| Loop Engineering | 自动驱动 Agent 运行的系统 | 定时触发、子智能体分工、外部状态 |
| Graph Engineering | 多个工作单元之间的拓扑与流转规则 | 节点、边、条件路由、动态派生 |
二、什么时候该用图，什么时候不该用
2.1 该用的场景
真实世界的 Agent 工作流往往具备可预测的结构：客服 Agent 需要先分类再决定回答还是升级；编码 Agent 需要先检查仓库再提出改动；合规流程要求先经过审批才能执行对外部世界产生实际影响的动作。图可以把"哪些路径是合法的、哪里该让模型自主判断、哪里必须由系统强制确定性行为"直接编码进拓扑，而不是每次都寄望于模型临场做出正确判断。
一个例子是一个使用三个子 Agent 做检索的知识库 Agent：GitHub 子 Agent 负责代码、Issue、PR；Notion 子 Agent 负责内部文档和 Wiki；Slack 子 Agent 负责相关讨论线程。整个工作流有三个固定阶段：分类、检索、综合。结果是代码逻辑与模型推理协同工作——模型只在真正需要判断力的地方进行推理，其余交给代码处理，整个 Agent 因此变得更便宜、更快、也更可预测。
2.2 不该用的场景
某些任务本质上更"自主"，硬塞进确定性路径反而是错误方向。这类场景更适合直接使用 Agent Harness（如 Deep Agents），而不是把它建模成图。
一个真实的反例是通用型深度研究（Deep Research）：一个研究型 Agent 需要规划、委派、搜索、阅读、综合——这些动作彼此的先后顺序很难提前钉死。LangChain 自己早期用预定义的 LangGraph 工作流实现深度研究，后来转向了更自主的核心循环。开源项目 GPT Researcher 也做了同样的迁移——把图状的多 Agent 流水线换成了 Deep Agents，让规划、委派、上下文管理这些能力在 Harness 内部自然涌现，而不是被硬编码进图结构里。
2.3 混合光谱：三种确定性程度的节点共存于同一张图
LangChain 给出了一个更具体的复合案例：一个把 Slack 请求转换成"待审阅 PR"的文档 Agent。这张图里的每个节点，落在确定性—自主性光谱上的位置各不相同：
| 节点类型 | 具体节点 | 实现方式 | 确定性程度 |
|---|---|---|---|
| 固定步骤（Fixed steps） | Slack/Linear 操作 | 纯代码逻辑与 API 调用 | 完全确定性 |
| 模型步骤（Model steps） | 分类器、结果综合 | 单次 LLM 调用，不携带工具 | 中等，单点判断 |
| Agent 步骤（Agent steps） | 参考文档 Agent、概念文档 Agent | 完整的自主 Agent，在对应代码库内自行完成开放式任务 | 高度自主 |
正是这种确定性与自主性的混合，让该系统同时具备了可预测性、强大能力和执行效率——这也是 LangGraph 相较于其他 Agent 框架，能够在众多同类产品中脱颖而出的关键原因所在：它在确定性路径与自主步骤之间找到了一个可控的平衡点。
2.4 动态转移：不是所有边都要提前定义好
LangGraph 三年实践给出的另一条经验是：并非所有边都需要提前静态定义。有些节点需要在运行时才能决定该派生出多少下游工作——典型场景是 Map-Reduce：把输入拆分成若干份，分别派给 worker 处理，再汇总结果，但 worker 的数量取决于输入本身，事先根本无法知道。
LangGraph 用Send机制处理这个问题——它让一个节点在运行时把工作动态路由到一个或多个下游节点，而不必事先把每一条转移路径都写死。一个示意性的思路大致是：一个"拆分"节点根据输入的实际长度，在运行时决定要派生出多少个Send调用，每个调用携带各自的子任务载荷，分别路由到同一个"worker"节点的不同实例上，最后统一汇入一个"合并"节点。这类"你知道该分发、但不知道分发给多少个目标"的场景,在真实系统里相当常见——你可能知道调研任务应该先扇出再综合,但不知道会有多少信息源;你可能知道一个主控节点应该把任务委派给多个 worker,但要等任务真正开始才能确定该调用哪几个具体的 worker。图需要在运行时依然保持这种弹性。
三、“新在哪里”：一次诚实的自我追问
Chase 在文中提出了一个相当克制的问题：把 Agent 系统建模为图这件事本身并不新——LangGraph 团队已经这样做了三年。那么这波"图工程"热潮里，究竟有什么是真正变化了的？
他给出的"比较宽厚的解读"是：变化的是节点内部能放的东西。早期，节点里放的通常是确定性代码，或者一次单独的 LLM 调用；而现在，Agent 本身已经足够可靠、可以承担真实工作，这意味着一个节点可以是一整次完整的 Agent 运行——你编排的对象从"编排 LLM 调用"，升级为了"编排 Agent"。
编码 Agent 是这一新模式的典型代表：它们是当下生产环境中最有效、最具影响力的 Agent 之一，把一个编码 Agent 作为一个节点嵌入到更大的图里，是一种新近才变得实用的模式——这在三年前基本无法想象，因为当时的 Agent 本身还不够可靠，不足以被当作一个"黑盒工作单元"塞进更大系统的某个节点位置。
四、批判性视角：“图工程陷阱”
如果只呈现上面这些正面论述，这篇文章就变成了单方面的产品推广。行业中确实存在一个相当扎实的反面声音，值得认真对待。
4.1 核心论据：图工程常被过度营销
批判性观点的核心判断是：图工程常常被营销为 AI 的下一次进化，但如果没有确定性约束和状态机逻辑，它往往只是一种更昂贵的方式来构建同样不可预测的系统。很多团队急于用复杂的多 Agent 图取代简单的 Agent 循环，结果只是把一套架构问题，换成了另一套更贵、更难调试的架构问题。
这个论证的一个关键洞察是：循环是宽容的，图是不宽容的——一个循环允许 Agent 边走边想清楚该怎么做；而一张图会强迫你承认，这个工作流里到底有多少部分你其实根本还没有真正建模清楚。如果你在没有确定性基础的情况下就直接搭图，你搭出来的不是一个系统，而是一个无法审计、无法复现的黑盒。
4.2 具体代价：延迟爆炸与上下文变成垃圾场
这一视角展开了两条具体的工程代价：
第一，naive 的图/ReAct 编排容易把每一步变成顺序阻塞。如果你让一个 Agent 并行比较三个地区的指标，一个朴素的实现方式往往是查完第一个地区、等结果返回，再查第二个，如此顺序进行——这种执行方式会让延迟和 Token 消耗呈指数级增长。
第二，上下文窗口会逐渐变成"垃圾场"。每一轮迭代都在往上下文里堆新数据、过时的工具调用结果、中间推理过程，最终真正重要的指令会被执行过程产生的操作噪音掩埋。这正是 Context Rot（上下文腐化）的一种具体表现形式——模型迷失原始目标，不是因为它不够聪明，而是因为它被执行细节的技术噪音淹没了。
4.3 解法：区分"动态派单"与"持久协调"
这一视角提出的核心解法，是把 Agent 系统要处理的问题拆解成两类性质截然不同的问题：
- 动态派单（Dynamic Dispatch）：根据刚刚学到的信息，决定接下来该做什么。这类问题是短暂的、局部的，完整地活在单一进程内部——这正是标准 ReAct 循环能够完美胜任的场景。
- 持久协调（Durable Coordination）：处理"工作跨越了单次进程生命周期之后，如何不丢失已有进度"这一问题——涉及需要人工审批的关卡、可能持续数天的等待、需要在系统重启之后依然能够恢复。这类问题需要的是真正的状态机和持久化执行引擎，而不是一个更大号的循环 [ref:1]。
两者的差异可以概括为：
| 维度 | 动态派单（ReAct） | 持久协调（状态机） |
|---|---|---|
| 状态持久性 | 短暂（存于内存） | 持久（数据库/事件日志） |
| 失败恢复模式 | 从头重试 | 从最近检查点恢复 |
| 适用场景 | 推理、工具选择 | 合规审批、人工介入、长时程任务 |
| 复杂度 | 低（单一循环） | 高（需要编排引擎） |
这一视角指出的问题是：很多团队直接用 LangGraph 这类框架去同时解决这两类问题，结果把"推理"和"执行协调"这两个本应分离的关注点混在了一起。更稳妥的做法,是用一个正式的状态机去约束模型能触碰的工具空间——按阶段限制工具集：规划阶段只给只读工具，实施阶段才给编辑工具。这样做的意义不只是安全，更重要的是把问题空间对模型收窄——当状态空间被压缩之后，更小、更便宜的模型也能完成原本只有顶级模型才能胜任的任务。
由此得出的工程建议是：停止试图用 Prompt 把逻辑问题祈祷式地解决掉。如果退款需要经理审批，这不该只是系统提示里的一条建议，而应该是状态机里一条硬编码的转移规则。把编排逻辑从 LLM 内部移出、放进一个确定性引擎里，你同时换来了可观测性——你能精确看到哪个状态转移失败了、为什么失败、当时的输入是什么，而不是在一段对话轨迹的"第 12 轮"里大海捞针。这一视角给出的最终判断是：最成功的系统往往采用混合架构——外层是一个确定性的状态机来管理工作流，内层特定节点内部是一个动态的 ReAct 循环来处理推理——这一结论与 LangChain 官方博客中"混合光谱"案例的设计思路，实际上高度一致。
五、企业级工程治理挑战
把这些抽象的架构判断落到生产环境，图编排会带来三类具体的治理挑战，都源于同一个根本原因：图的拓扑本质上混合了异构节点——自主 Agent、确定性函数、路由器、人工审批关卡——彼此的行为模式、失败模式、成本结构都不相同。
身份治理问题：图里的每一个独立运作的调用方，都需要有明确、可解析的身份——不能在审计时用"是图做的"这种笼统答案来回应"这个动作到底是谁执行的"。当一个节点本身就是一整个 Agent 运行时，这个问题会被进一步放大：需要追问的是这个节点内部具体哪一次工具调用、由哪个子调用方发起。
成本控制问题：图的扇出（Fan-out）、重试、动态派生子任务，都会成倍放大模型调用和工具调用的实际次数，而且这种放大往往不是线性的。不能假设成本会自然收敛——需要针对每一层扇出显式设置预算上限和限流规则，尤其是在使用Send这类动态派生机制时，派生数量本身如果失控，成本曲线会失控得很快。
可观测性问题：需要把编排层自己记录的执行轨迹，和实际发生的模型调用、工具调用、延迟数据关联起来，才能真正定位"哪个节点失败了、为什么失败、输入是什么"——而不是在一堆混杂的对话轨迹里大海捞针，这一点与前文批判性视角提出的"停止看第 12 轮，开始看失败的状态转移"完全呼应。
对于计划在近期把某个多 Agent 图推上生产环境的团队，一份可执行的自检清单大致包括：
- 图中每一个独立运作的调用方，是否都有一个明确、可解析的身份标识？
- 每一次模型调用与工具调用，是否携带了稳定的图/运行/节点标识元数据，以便事后追溯到具体的执行路径？
- 编排层是否真实记录了运行时实际发生的工作图（而不只是设计时的静态拓扑图）？
- 涉及外部世界副作用的敏感工具操作，前面是否设有明确的、代码强制的审批关卡，而不是仅靠 Prompt 里的一句提醒？
- 图中扇出/动态派生的节点，是否设置了显式的预算上限和熔断机制？
结论与展望
Graph Engineering 不是能够否定 Loop Engineering 的更高级范式，也不是包治百病的新灵药——它是一个用来思考"完全交给模型自主判断"与"完全用代码写死流程"这两个极端之间该如何取得平衡的框架。真正的工程决策，不在于"要不要用图"，而在于具体到每一个节点，该放多少确定性代码、放多少模型判断。
LangChain 官方的三年实践经验和"图工程陷阱"一文的批判视角，表面上立场相反，实际上在最关键的落脚点上高度一致：两者都指向"确定性外层结构 + 局部自主推理"这一混合架构。分歧主要在于强调重心——前者更强调图这种表达方式本身带来的收益（世界知识的显式编码、动态转移的灵活性），后者更警惕把这种表达方式草率地套用在本该用简单状态机就能解决的问题上，从而引入不必要的复杂度和成本。
至于"Graph Engineering"这个词本身能不能长期存活，值得保持开放态度——就像"org graph""work graph"这类更具体的说法，未必能撑过下一轮术语更迭。但无论词汇如何变化，治理、预算、护栏、身份、可追溯性这些底层需求都不会因为换了一个新名词就自动消失。这大概才是这类"buzzword"真正值得被认真讨论的原因：它们背后指向的工程问题是真实的，即便词汇本身终将被下一个词汇取代。
