别再追新词了，你早就在做"图工程"了

又来了。一个“图工程”的新词，被一条推文几分钟内炒热。但说穿了，这不过是老调重弹，那些在LangGraph、Google ADK等框架里默默运行了两年的节点和边，换了个新名字，换个马甲再登场。先聊聊笔者的几个观察。

一条推文，又一个新词

七月十七号那天，OpenClaw的开发者Peter Steinberger发了条推文，问题不长，但杀伤力不小：“我们现在还在聊循环，还是已经转向图了？”就这么一句话，不到一天时间，上千条回复涌入，“图工程”这个说法迅速在社交网络上流传开来，被当成交接“循环工程”的新班人。而“循环工程”这个词自己，也才在六月刚刚站稳脚跟。

值得玩味的是，这条推文发出来的时候，没有任何新框架发布，没有任何新模型上线，没有任何新能力落地。整个“图工程”概念的诞生，完全是推文底下的讨论催生出来的，属于典型的“话题先于产品”。

如果觉得这个节奏似曾相识，那说明你抓住了规律。过去十八个月里，让AI系统表现得更可靠这件事，被反反复复重新命名了四次：先是提示工程，然后是上下文工程，接着是脚手架工程，再然后是循环工程，现在轮到图工程。这五个词里面，有些确实在描述不同的问题，有些只是换了个角度讲同一件事。在跟风采用第五个新词之前，先把这些概念理清楚，可能更划算。

五个词，五种定义，先掰扯清楚

想搞明白这些概念之间的真实距离，最靠谱的办法不是听谁站台，而是把每个词的实际定义摆在桌面上，自己判断。

提示工程

提示工程，说的是在单次对话里，怎么设计给模型的指令。写一段提示词，拿到回复，评估效果，再迭代优化，这是最基础的一层。

上下文工程

上下文工程，管的是模型在推理时能接触到的所有信息，提示词本身之外的那部分：检索回来的文档、记忆内容、工具定义、会话历史。提示工程解决的是你对模型说了什么，上下文工程解决的是模型在回答之前知道什么。这两者的边界其实很清晰。

脚手架工程

脚手架工程，指的是围绕智能体的结构层：它不能突破的约束、它必须通过的验证关口、跨会话持续存在的状态。一段写得再好的提示词，如果架构层面没有任何东西拦着，也没法阻止智能体把你整个代码库重写一遍。这就是为什么光靠提示词不够，还得靠架构兜底。

循环工程

循环工程，设计的是单个智能体反复运行的那套发现、规划、执行、验证的循环。它决定了每一步由什么触发，什么算作完成，出错了怎么办。实际生产环境里，大多数系统其实是好几种循环工程模式组合着用，很少只依赖单一模式。

图工程

再往后就是图工程，被描述成把多个各自运行自己循环的智能体，通过节点、边、共享状态连接起来，而不是指望一个智能体从头到尾把所有事情按顺序处理完。

把这五个概念摆在一起看，画面就清晰多了。提示工程、上下文工程、脚手架工程，描述的其实是同一个单智能体问题的三个不同层面：你说了什么，它知道什么，它被允许做什么。这三者是互补关系，不是替代关系。而循环工程和图工程这两者，站得就近得多。说白了，图就是当单个循环不够用、需要好几个循环互相协作时，自然会得到的东西。图不是循环的对立面，而是循环的扩展形态。

图这种东西，其实一直都在

把AI系统建模成图而不是单一的顺序流程，这个思路不是2026年七月才冒出来的新鲜事，甚至都不是智能体编排这个领域独有的。图谱增强检索早就在用知识图谱，也就是代表实体和实体关系的结构化节点和边，来实现多跳推理，这是纯文本检索做不到的。图谱增强检索用这套思路的时间，比它前面那波循环工程周期还要长。本质上还是同一套节点和边的思维方式，只不过这次用在了检索场景，而不是编排场景。

只要AI系统需要表示一个问题的多条路径，总会有人想到用图来解决。智能体编排现在才追上这个思路，只能算是意料之中，谈不上有多新颖。

那些早就在做图工程的框架，一个一个盘

既然“图工程”描述的是智能体作为节点、通过边连接、共享状态的这套东西，那下面这几个框架已经在生产环境里跑了不短的时间了。

LangGraph

• 这是什么：LangChain出品的一个偏底层的编排框架，用来构建有状态、可长时间运行、显式建模成图结构的智能体。早在“图工程”这个词流行起来之前，它就已经在被大量实际使用了，如今在企业采用率上处于领先位置，月下载量达到千万级别。
• 编排模型：你需要定义一个StateGraph，往里面添加节点，再用条件边把这些节点连起来。智能体、工具、检查点都是节点，节点之间的转换是你自己定义的边。
• 状态管理：内置检查点机制，支持时间旅行式调试，也就是你可以回滚到执行过程中的某个早期节点，从那里重新开始回放。
• 最适合谁用：需要对分支、重试、人工介入环节有明确控制权的复杂有状态Python工作流。

微软Agent Framework

• 这是什么：AutoGen和Semantic Kernel的统一继任者，2026年4月正式进入通用可用阶段。
• 编排模型：把AutoGen的多智能体对话抽象和Semantic Kernel的企业级工具能力结合起来，同时加上了基于图的工作流，用来对多智能体的执行路径做显式控制。
• 状态管理：基于会话的状态管理，加上从Semantic Kernel继承过来的中间件、遥测和类型安全能力。
• 最适合谁用：已经在用微软技术栈的团队，想要用图工作流搭配Python和.NET运行时。

Google ADK

• 这是什么：谷歌的Agent Development Kit，专门为多模态和谷歌云原生的智能体技术栈打造。它最突出的能力是原生支持A2A协议，也就是智能体对智能体协议，这让一个ADK智能体能够通过标准化的任务接口，发现并调用一个用LangGraph或CrewAI搭建的智能体。这已经是把“图”的思维方式扩展到框架边界之外了，不再局限于单一框架内部。
• 编排模型：一套层级化的智能体树结构，根智能体向下委派任务给子智能体，子智能体还能继续往下委派。
• 状态管理：会话状态支持可插拔后端，与Vertex AI以及Gemini模型深度集成。
• 最适合谁用：谷歌云原生团队，以及任何需要不同框架搭建的智能体互相通信的系统。

CrewAI

• 这是什么：一个独立的多智能体编排框架，围绕基于角色的思维模型搭建，每个智能体都有明确的人设、一套工具、一项具体任务。从想法到能跑起来的多智能体原型，是这几个框架里最快的一条路，搭建时间以小时计，不是以天计。
• 编排模型：基于角色的团队协作，配置不同的流程类型来管理任务在智能体之间怎么传递，而不是画一张字面意义上的节点边图。底层逻辑其实是一样的：智能体是节点，流程走向是边，任务输出是共享状态，只是表现形式不一样。
• 状态管理：任务输出按顺序在智能体之间传递。
• 最适合谁用：想快速搭原型、想要基于角色的多智能体系统、想尽快拿出一个能跑的演示的团队。

LlamaIndex Workflows

• 这是什么：一个事件驱动的编排层，专门为文档密集型、数据密集型的流水线打造。在当前这轮智能体编排命名周期开始之前，它就已经专门为索引和检索工作流服务了。
• 编排模型：步骤根据前面发生了什么来条件触发，而不是遵循一个固定不变的顺序，这让它的“图”形状更多是由数据本身塑造的，而不是由一张预先画好的智能体组织架构图决定的。
• 状态管理：上下文随事件触发一路传递，适合检索密集型和RAG风格的流水线。
• 最适合谁用：数据为中心的应用场景，文档摄取、检索、转换这几个步骤需要条件路由的时候。

OpenAI Agents SDK

• 这是什么：OpenAI推出的生产级多智能体协调工具包，是那个实验性的Swarm框架的正式继任者。在OpenAI一家独大的智能体链条里，用起来干净又可预测，但是模型锁定得很死，不支持自带模型。
• 编排模型：显式交接。智能体A完成自己那部分，交接给智能体B，交接过程中把上下文一并传过去。这是一种比完整的图更轻量的边模型，更接近一条链，而不是一张网。
• 状态管理：上下文变量默认是临时性的，没有内置检查点机制，不太适合长时间运行的工作流。
• 最适合谁用：完全在OpenAI技术栈上、想要一种轻量交接模型而不是完整图结构的团队，同时也是一个很实用的提醒：不是每个多智能体系统都需要一整套图。

这对你的技术栈意味着什么

如果你已经在用上面这些框架里的任何一个，那你其实在“图工程”这个词流行之前，就已经在做那件现在被叫做“图工程”的事情了。标签换了，架构不会跟着变。这个新标签能带来的好处，是给你一套更清晰的语言，去跟团队解释你的架构，或者跟正在招人的公司说清楚这个岗位到底在干什么。

更值得琢磨的问题，不是要不要跟着采用这个最新的词，而是你的系统到底需不需要图能提供的那种协调能力：多个智能体，各自跑各自的循环，彼此之间存在真实的依赖关系，是单个智能体按顺序处理搞不定的那种依赖。如果答案是需要，上面这些框架已经花了好几年时间把难啃的部分磨得差不多了，直接拿来用就是了。如果答案是不需要，一个搭建得扎实的循环仍然是正确的工具，不管时间线接下来打算把它叫成什么新名字。

几个常被问到的问题

没有本质区别。“多智能体编排”是那个存在时间更久的说法，讲的是通过预定义的路由和共享状态来协调多个智能体。“图工程”用的是节点和边这套语言，来描述同样的实践，换了个说法而已。

只有当单个智能体的循环处理不了你任务里的依赖关系时，才需要考虑切换。大多数工作流其实用不上图。真正该用图的场景，是你手头有真正并行或者分支的工作，单个智能体按顺序跑会造成瓶颈的那种情况。

LangGraph是复杂的、有状态的Python工作流场景下最常见的默认选择。如果你想在一个下午之内搭出能跑的多智能体系统，CrewAI原型搭建速度更快。如果你需要不同框架搭建的智能体之间通过A2A互相通信，Google ADK是最强的选择。

在机制层面上，基本可以这么说。LangGraph自己的文档里描述的正是节点、边、状态这套模型，而“图工程”现在被用来描述的，恰恰就是这套东西。