“图工程”成新热词？实则换汤不换药，LangGraph等框架两年前已用节点边构建智能体，新词不过是概念迭代老套路。
核心内容：
1. “图工程”的诞生：推文引发，话题先于产品
2. 五个工程概念的定义与关系：提示、上下文等工程的区别与互补
3. 新词本质：换汤不换药，框架早存，概念迭代老套路

摘要：一条推文引爆"图工程"概念，成为继提示工程、上下文工程、脚手架工程、循环工程后的第五个热词。但LangGraph、Google ADK等框架早已用节点和边构建智能体两年有余，新词换汤不换药。01一条推文，又一个新词七月十七号，OpenClaw的开发者Peter Steinberger发了一条推文，问题不长，但是杀伤力不小："我们现在还在聊循环，还是已经转向图了？"就是这么一句话，不到一天时间收获了上千条回复，"图工程"这个说法迅速在社交网络上流传开来，被当成"循环工程"的接班人。而循环工程这个词自己也才火了没多久，从今年六月才算真正站稳脚跟。值得注意的是，这条推文发出来的时候，没有任何新框架发布，没有任何新模型上线，没有任何新能力落地。整个"图工程"这个概念的诞生，完全是推文底下的讨论催生出来的，属于典型的"话题先于产品"。如果你觉得这个节奏似曾相识，那说明你抓对了规律。过去十八个月里，让AI系统表现得更可靠这件事，被反反复复重新命名了四次：先是提示工程，然后是上下文工程，接着是脚手架工程，再然后是循环工程，现在轮到图工程。这五个词里面，有些确实在描述不同的问题，有些只是换了个角度讲同一件事。在跟风采用第五个新词之前，先把这些概念理清楚，可能更划算。02五个词，五种定义，先掰扯清楚想搞明白这些概念之间的真实距离有多远，最靠谱的办法不是听谁站台，而是把每个词的实际定义摆在桌面上自己判断。

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

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

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

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

图工程再往后就是图工程，被描述成把多个各自运行自己循环的智能体，通过节点、边、共享状态连接起来，而不是指望一个智能体从头到尾把所有事情按顺序处理完。把这五个概念摆在一起看，画面就清晰多了。提示工程、上下文工程、脚手架工程，描述的其实是同一个单智能体问题的三个不同层面：你说了什么，它知道什么，它被允许做什么。这三者是互补关系，不是替代关系。而循环工程和图工程这两者，站得就近得多。说白了，图就是当单个循环不够用、需要好几个循环互相协作时自然会得到的东西。图不是循环的对立面，而是循环的扩展形态。03图这种东西，其实一直都在把AI系统建模成图而不是单一的顺序流程，这个思路不是2026年七月才冒出来的新鲜事，甚至都不是智能体编排这个领域独有的。图谱增强检索早就在用知识图谱，也就是代表实体和实体关系的结构化节点和边，来实现多跳推理，这是纯文本检索做不到的。图谱增强检索用这套思路的时间，比它前面那波循环工程周期还要长。本质上还是同一套节点和边的思维方式，只不过这次用在了检索场景，而不是编排场景。只要AI系统需要表示一个问题的多条路径，总会有人想到用图来解决。智能体编排现在才追上这个思路，只能算是意料之中，谈不上有多新颖。04那些早就在做图工程的框架，一个一个盘如果"图工程"描述的是智能体作为节点、通过边连接、共享状态的这套东西，那下面这几个框架已经在生产环境里跑了不短的时间了。

LangGraph

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

微软Agent Framework

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

Google ADK

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

CrewAI

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

LlamaIndex Workflows

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

OpenAI Agents SDK

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

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

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

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

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

往期推荐

三层本体&图谱驱动的医药企业级新一代AI知识平台

Palantir的真正秘密武器——本体论（Ontology）

本体论、知识图谱与大模型融合技术研讨会圆满落幕：产学研共探AI融合新路径

本体论Ontology：让企业级AI大模型真正有效运作的隐藏层

大语言模型时代，本体论还有用吗？

本体论神经符号架构如何破解企业AI幻觉难题？——构建可信赖的智能体Agent系统

超越通用大模型，动态本体重新定义企业知识工程 - Stardog

本体论：让AI真正听懂你的业务语言

ONTOKG- 知识图谱构建新范式：本体导向与内在-关系路由机制

Elsevier旗下SciBite的本体论赋能制药研发：AI与科学专业知识Ontology的完美协同

用LLM打造会自我进化的下一代个人AI知识库及本体价值 - OpenAI联创Karpathy

本体论与3DI：从解释现实到证明真实

AI时代的医药研发专家的一天：本体论驱动的知识引擎如何重塑医药行业超级个体和前沿组织形态

大模型时代本体论Ontology驱动的AI知识引擎助力企业智能决策系统的未来进化-一篇献给企业董事会和CIO的深度思考(第一篇)

智能体AI究竟是什么？本体论能否为其赋能？以生物医药研发为例详细解析

诺华Data42平台：利用Palantir本体论驱动的AIP重塑药物发现的未来

诺和诺德数字化转型之路：本体论Ontology驱动的数据管理革新

AI Agent的认知架构：为什么AI智能体需要本体论和知识图谱

Palantir 会是下一个 Oracle 吗？Ontology本体论重塑制药行业的AI催化剂

我的AI智能体需要本体论Ontology吗？

Palantir “本体论”：是跨时代的AI架构，还是精心包装的“建表”骗局？

Palantir 本体论与知识图谱深度分析及实现路径

微软企业级本体大模型Fabric IQ平台深度解析:从企业数据平台到智能平台的范式转变

将复杂性转化为意识：探索本体论与Palantir的操作性本体模型

AI智能体为何需要本体与图谱存储：构建可靠的长时记忆架构

解锁企业知识图谱的“黑匣子”：OntoEKG重塑本体构建范式，AI赋能数据价值释放

Palantir本体构建指南：Ontology Building – 打造组织的运营层与数字孪生

人工智能本体论：大模型辅助构建AI概念层级体系

知识图谱与大模型的结合：Stardog的本体论和符号化知识蒸馏技术解析

Palantir官方深度解析本体 Ontology系统及知识图谱、大模型：企业自主决策的核心AI引擎

11份深度报告拆解 Palantir：从“本体政&治”到 AI 操作系统，揭秘全球最神秘巨头的真相

统治数据的“先知”：Palantir 16 份官方白皮书首度解密，从本体论到战场决策的进化路径

大模型环境下的企业级语境图谱Context Graphs：Palantir 本体论之争的误区，一场价值万亿美元的对话

知识图谱和Prolog在大模型时代的角色对比：逻辑与本体的完美融合

大模型重塑本体工程和知识图谱构建综述：从静态规则驱动到动态生成范式的革命性演进

本体论与知识图谱：揭示语义技术的核心差异

企业级实用本体论及构建指南(4/4)：通过Foundry Actions激活数据生态系统

企业级实用本体论与构建指南（3/4）：Palantir Foundry中的对象、事件与时间序列

企业级实用本体论的实践指南(2/4)：Palantir Foundry如何将组织数据映射到本体概念及关键设计考量

企业级实用本体论及构建指南系列(1/4)：Palantir 数据建模的哲学与实践

OntoMetric：破解ESG报告难题的“大模型+本体知识图谱”新范式，准确率提升10倍

零噪声知识图谱提取革命：构建自适应本体驱动GraphRAG系统

Palantir的"本体论"(Ontology)究竟是什么？这个晦涩的哲学术语是其AI业务的核心秘密

工业标准文档的本体知识图谱框架：通过层次化和命题结构实现智能解析

从人类专家到机器：大模型支持的人机协同本体与知识图谱自动构建

本体论：大模型时代企业数据治理的关键基础设施及企业级大模型规模化落地的真正瓶颈

Palantir本体论及AI数字孪生深度解析：构建组织智能的语义操作系统

颠覆认知的知识引擎：Palantir 公司的本体论及其对未来的启示

本体论的力量：为大模型智能体提供可靠的框架，减少不确定性并提高输出质量 - 海外知识图谱公司Stardog的大模型演进

从RAG到GraphRAG：知识图谱、本体论与更智能的AI

70+美国巨头齐聚Palantir AIPCon 8，核能竞赛、制药革命与灾难响应的智能升级。如何用AIP&本体重塑行业未来？

Palantir AIP 深度解析（一）：超越 RAG，用本体增强生成（OAG）重塑企业决策

"本体+数据"的魔法力量：Palantir如何从反恐前线到企业级AI的领军者的高速增长故事

Palantir本体论是否在中国可行？颠覆数据建模范式兼论Kimball星型模型。

Palantir CTO重磅解读：将你的业务编译成代码，“本体论”才是数字时代的终极武器

Palantir的“数据操作系统”革命 - 本体Ontology系统

Palantir发布的“本体驱动的智能体”，是AI迈向自主决策的终极形态？

Palantir官方揭秘：如何在商业、国防领域运用本体论和AI基础设施

Palantir揭秘：为什么说“本体”是AI时代的真正护城河？

突破企业级GenAI落地的关键：知识图谱与大模型驱动的本体

解锁知识的力量：深入探究Palantir的本体论与知识图谱

从知识图谱到企业数字孪生：Palantir本体驱动企业级AI应用创新路径

精准人工智能：Timbr的语义本体如何让大模型更智能

什么是“本体论”？——LLM驱动的自动本体生成、数据建模新范式与AI语义层全解

登录查看剩余 70% 内容