引言又一个新词但先别急着下结论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 做检索的知识库 AgentGitHub 子 Agent 负责代码、Issue、PRNotion 子 Agent 负责内部文档和 WikiSlack 子 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 stepsSlack/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 graphwork graph这类更具体的说法未必能撑过下一轮术语更迭。但无论词汇如何变化治理、预算、护栏、身份、可追溯性这些底层需求都不会因为换了一个新名词就自动消失。这大概才是这类buzzword真正值得被认真讨论的原因它们背后指向的工程问题是真实的即便词汇本身终将被下一个词汇取代。