Graph Engineering 来了，但它不是什么新东西

2026年7月18号，Peter Steinberger 在 X 上发了六个词，「Are we still talking loops or did we shift to graphs yet?」，575K views，评论区瞬间分成两派，一派说这是下一个范式，另一派说又来了。

朋友们，Graph Engineering，图工程，来了。

我第一反应跟你一样，又造新词？Prompt Engineering 的余温还在，Context Engineering 刚火没几周，Loop Engineering 还没聊透呢，这又来一层？

但是拆开看完之后，我觉得这事儿本身不复杂。它不是什么革命性的新发明，而是工程化阶段自然演进到这一步了。今天咱们一起把这个概念消化掉。

先别急着看 Graph Engineering 是什么，我们往回倒一下，把前面几个「xxx Engineering」的关系理清楚。因为我发现很多人把这几个概念当成平行的、互相替代的东西在理解，但其实它们是嵌套的。

想象一组俄罗斯套娃。

最里面那个最小的娃娃，是 Prompt Engineering。研究的是怎么写一条高质量的提示词，让模型单次输出更好的结果。你精心组织语言，给几个 few-shot 示例，调整语气和格式要求。这一层解决的是「单次对话质量」的问题。

套在外面一层的，是 Context Engineering。它不只关心你写了什么提示词，而是关心模型在这一次调用里「看到了什么」。RAG 检索回来的文档、对话历史的摘要、工具调用的结果、系统指令里塞的背景知识，这些加在一起构成了模型的上下文窗口。Context Engineering 研究的是如何精心组织这个窗口里的所有信息，让模型拥有做出好决策所需的全部背景。

再往外套一层，是 Harness Engineering。这个词国内讨论得不多，但概念很直觉，它研究的是给模型套一个「运行环境」。模型不是裸奔的，它跑在一个 harness 里面，这个 harness 负责调用工具、做结果验证、处理异常、管理权限。你可以理解为，Context Engineering 管「模型看到什么」，Harness Engineering 管「模型在什么环境里跑」。

再往外一层，是 Loop Engineering。最早我们理解 Agent 运行就是一个简单的 while 循环，感知环境、执行动作、观察结果、判断是否完成、没完成就继续。Loop Engineering 研究的是怎么让这个循环跑得更聪明，比如在循环外面再套一层父循环，让 agent 自己感知环境变化，减少人工干预，持续执行直到完成目标。核心理念是，不要再手写提示词了，去设计那个循环和它的退出条件。

好，现在你手里有了一个四层套娃。Prompt 在最里面，Context 包着 Prompt，Harness 包着 Context，Loop 包着 Harness。

Graph Engineering，就是最外面那一层。

有人把这五层的关系总结得很清晰，AI应用有五层工程学，Prompt → Context → Harness → Loop → Graph，每一层都不是取代上一层，而是在更外面包了一层。

那 Graph Engineering 到底在解决什么问题？

Loop Engineering 的世界里，你有一个 agent，它在一个循环里不断地执行任务。但实际场景中，你可能需要多个 agent 并行在跑，而且互相之间有依赖关系。一个 agent 负责检索资料，另一个负责写作，第三个负责审核，审核不通过要打回给写作的那个重来。

这不是一个 while 循环能描述的结构了。

对应到计算机里面的概念，这是一张图，Graph。更准确地说，是一张有向图，Directed Graph。因为数据和控制流是有方向的，A 跑完的结果要传给 B，B 跑完可能传给 C，也可能打回给 A。

注意，这不是 DAG（有向无环图），因为实际场景里是有环的。审核失败了要回到写作节点，方案不行要回到分析节点。这个结构更像是 FSM，有限状态机。 Agent 在图中的各种状态间切换，由条件触发状态迁移，持续执行直到到达终止状态。

我说它像 FSM 不是在打比方。学术界已经在这么干了。ICML 2025 有一篇叫 MetaAgent 的论文，提出了一个基于有限状态机的框架，可以自动生成多 Agent 系统。给定任务描述，它自动设计 Agent 的组合、状态和转换规则，部署时由 FSM 控制 Agent 的行为和状态迁移。

所以你看，Graph Engineering 研究的核心问题就是，如何用图（有向图/状态机）来组织多个 Agent 的协作与流转，解决真实场景中的复杂问题。

接下来是最值得聊的部分，这东西到底是真的新，还是换了层皮？

坦率地讲，两边都对。

先说真正新的部分。社区里有一个「四问自测」，我觉得总结得很到位，你是不是把一个臃肿的上下文拆成了多个专门的、干净的上下文？你是不是有真正的并行执行然后合并结果？你的控制流是不是可以画成一张图来审计，而不是埋在一个 agent 的长对话记录里？如果这三个问题你都能答「是」，那你确实在做图工程，不是在画流程图装样子。

并行 fan-out/fan-in 是单循环真正做不到的事。 举个具体的例子，你要做一份每日研究简报，需要从10个信息源抓取内容。单循环的 agent 只能一个一个来，上下文越塞越满，最后自己审核自己写的东西，基本等于橡皮图章。换成图结构，10个检索节点并行跑，结果合并后传给写作节点（写作节点只看到干净的笔记，不看原始HTML），写完传给审核节点（全新的上下文，不带写作时的思路惯性），审核不过打回重写。每个节点有独立的 context，有专门的 prompt 和工具，互不污染。

再说「换皮」的部分。状态机和图编排这个概念，在计算机科学里存在了几十年。XState 库的作者 David Kpiano 看到 Graph Engineering 这个词的时候，反应大概是「这不就是我干了十年的事儿吗」。LangGraph 在这个词火之前就已经在做图结构的 Agent 编排了，Microsoft AutoGen 的 GraphFlow、Google ADK 的图工作流，都是先有实践后有名字。

反对派里我觉得说得最有道理的是 @PawelHuryn 的观点，他说不管你画的是循环还是图，底层的纪律没变过，你得能定义清楚「什么叫完成，什么叫正确」。画再漂亮的拓扑结构，如果你说不清楚成功标准，那就是用更花哨的方式在失败。

我自己的判断是这样的。

Graph Engineering 不是革命，是演进。就像从单线程编程到多线程编程，底层的逻辑没变（还是在写代码），但你面对的问题变了（需要并发和协调），所以你需要新的思维模型和工具来描述和解决它。

回到那个俄罗斯套娃的比喻。Prompt Engineering 教你写好一条指令，Context Engineering 教你组织好模型的视野，Harness Engineering 教你搭好运行环境，Loop Engineering 教你设计好单个 agent 的自主循环，Graph Engineering 教你编排好多个 agent 的协作网络。

每一层都不是否定上一层，而是在上一层的基础上往外包了一圈。 你不会因为学了 Graph Engineering 就不需要写好 prompt 了。每个图里的节点，里面跑的还是一个 loop，loop 里面还是需要好的 harness、好的 context、好的 prompt。

所以如果有人跟你说「Loop Engineering is dead, long live Graph Engineering」，你可以笑一下。Loop 没死，它变成了 Graph 里的一个节点。就像线程没死，它变成了线程池里的一个 worker。

真正值得关注的不是这个名字，而是这个阶段。 我们正在从「一个 agent 打天下」走向「多个专业 agent 协作完成复杂任务」的阶段。这个转变是真实的，它需要新的思维模型来描述。Graph，有向图，状态机，不管你叫它什么，本质上就是在回答一个问题，多个 agent 之间怎么分工、怎么传递信息、怎么处理异常、怎么知道什么时候该停。

这个问题不新，但它变得越来越重要了。

谢谢你看我的文章，我们，下次再见。

/ 作者：青玉白露

延伸阅读

• 我把MCP全部干掉了，换成了Skill：MCP和Skill到底有什么区别？为什么Skill比MCP节省98%的token？从一个实际切换者的视角，拆解背后的技术逻辑和真实体感。