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

一条推文引爆"图工程"概念

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

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

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

过去十八个月里，让AI系统表现得更可靠这件事，被反反复复重新命名了四次：先是提示工程，然后是上下文工程，接着是脚手架工程，再然后是循环工程，现在轮到图工程。

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

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

提示工程

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

上下文工程

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

脚手架工程

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

循环工程

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

图工程

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

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

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

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

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

本质上还是同一套节点和边的思维方式，只不过这次用在了检索场景，而不是编排场景。只要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技术栈上、想要一种轻量交接模型而不是完整图结构的团队，同时也是一个很实用的提醒：不是每个多智能体系统都需要一整套图。

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

如果你已经在用上面这些框架里的任何一个，那你其实这个月之前就已经在做那件现在被叫做"图工程"的事情了。标签换了，架构不会跟着变。

这个新标签能带来的好处，是给你一套更清晰的语言，去跟团队解释你的架构，或者跟正在招人的公司说清楚这个岗位到底在干什么。

更值得琢磨的问题，不是要不要跟着采用这个最新的词，而是你的系统到底需不需要图能提供的那种协调能力：多个智能体，各自跑各自的循环，彼此之间存在真实的依赖关系，是单个智能体按顺序处理搞不定的那种依赖。

如果答案是需要，上面这些框架已经花了好几年时间把难啃的部分磨得差不多了，直接拿来用就是了。如果答案是不需要，一个搭建得扎实的循环仍然是正确的工具，不管时间线接下来打算把它叫成什么新名字。

几个常被问到的问题

图工程和多智能体编排是一回事吗？

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

需不需要从循环切换到图？

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

应该从哪个框架开始入手？

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

这是不是LangGraph换了个新名字而已？

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

JOTO 企业落地观察

• 图工程不是新范式，而是企业智能体系统演进到多节点协同阶段的必然表达。JOTO 在为金融客户部署 RAG+智能体联合系统时，已将 LangGraph 的 StateGraph 作为标准编排层，其检查点机制直接支撑监管审计所需的可追溯性。
• 当客户提出“能否让不同部门的智能体互调”，我们不再推荐定制 API 对接，而是引导其采用 Google ADK 的 A2A 协议——这标志着企业知识工程正从单点 RAG 向跨域图谱协同升级，JOTO 的 FDE 驻场共创团队需提前储备 A2A 接口治理经验。
• 多数制造业客户仍停留在单循环智能体阶段，强行引入图结构反而增加运维复杂度。JOTO 的智能体工程方法论坚持“循环优先、图按需”，在交付中用 LlamaIndex Workflows 实现文档路由决策，避免过早陷入图拓扑设计。
• 图工程对 AI 安全治理提出新要求：节点间状态共享需明确权限边界与数据血缘。JOTO 已将图结构自动解析能力嵌入安全审查模块，可识别 LangGraph 中未加访问控制的共享状态变量，并生成合规加固建议。

JOTO 企业落地观察

• 图工程对企业部署意味着：不必等待新范式成熟，已有框架如LangGraph、LlamaIndex Workflows已提供稳定图结构能力；关键在于识别业务中真实存在的多节点依赖，而非被动适配术语更新。
• 这类系统的取舍在于：是否引入图结构取决于智能体间是否存在不可简化为线性流程的并行或反馈依赖；若仅需顺序交接，OpenAI Agents SDK的轻量交接模型反而降低运维负担。
• 对RAG知识工程而言，图思维已内生于多跳检索场景；当企业从单文档RAG转向跨系统知识协同时，图工程实质是将既有知识图谱能力迁移至智能体编排层，而非另起炉灶。
• AI安全治理需同步升级：图结构放大了节点间状态共享的风险面，企业必须在设计阶段就定义各节点对共享状态的读写权限与血缘追踪能力，不能依赖事后补丁。