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

摘要：一条推文引爆"图工程"概念，成为继提示工程、上下文工程、脚手架工程、循环工程后的第五个热词。但LangGraph、Google ADK等框架早已用节点和边构建智能体两年有余，新词换汤不换药。

一条推文，又一个新词

七月十七号，OpenClaw的开发者Peter Steinberger发了一条推文，问题不长，但是杀伤力不小："我们现在还在聊循环，还是已经转向图了？"

就是这么一句话，不到一天时间收获了上千条回复，"图工程"这个说法迅速在社交网络上流传开来，被当成"循环工程"的接班人。而循环工程这个词自己也才火了没多久，从今年六月才算真正站稳脚跟。

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

如果你觉得这个节奏似曾相识，那说明你抓对了规律。过去十八个月里，让AI系统表现得更可靠这件事，被反反复复重新命名了四次：先是提示工程，然后是上下文工程，接着是脚手架工程，再然后是循环工程，现在轮到图工程。

这五个词里面，有些确实在描述不同的问题，有些只是换了个角度讲同一件事。在跟风采用第五个新词之前，先把这些概念理清楚，可能更划算。

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

图片[2]-别再追新词了，你早就在做"图工程"了 - AI资源导航站-AI资源导航站

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

提示工程

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

上下文工程

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

脚手架工程

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

循环工程

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

图工程

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

把这五个概念摆在一起看，画面就清晰多了。提示工程、上下文工程、脚手架工程，描述的其实是同一个单智能体问题的三个不同层面：你说了什么，它知道什么，它被允许做什么。这三者是互补关系，不是替代关系。

而循环工程和图工程这两者，站得就近得多。说白了，图就是当单个循环不够用、需要好几个循环互相协作时自然会得到的东西。图不是循环的对立面，而是循环的扩展形态。

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

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

本质上还是同一套节点和边的思维方式，只不过这次用在了检索场景，而不是编排场景。只要AI系统需要表示一个问题的多条路径，总会有人想到用图来解决。

智能体编排现在才追上这个思路，只能算是意料之中，谈不上有多新颖。

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

图片[3]-别再追新词了，你早就在做"图工程"了 - AI资源导航站-AI资源导航站

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

LangGraph

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

微软Agent Framework

这是什么：AutoGen和Semantic Kernel的统一继任者，二零二六年四月正式进入通用可用阶段。
编排模型：把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技术栈上、想要一种轻量交接模型而不是完整图结构的团队，同时也是一个很实用的提醒：不是每个多智能体系统都需要一整套图。