“图工程” 从今往后咱们分成两个吧，这里有个提议（元核查结果）

知识图工程 vs 智能体图工程——我觉得这样区分更好，于是整理了一些理由。如果同意，转发一下，免得别人下次也搞混。

• 知识图工程：传统数据领域，用本体、RDF、OWL 来结构化和存储知识——GraphRAG 的血脉 • 智能体图工程：编排方法，把智能体拆成节点来设计流程——LangGraph 和 AutoGen GraphFlow 的血脉

• 2026 年 7 月中旬，后一种含义在 X 上突然火爆（需要核实起源，但近期社区反响似乎对得上）

1. 同名不同源：把知识存储成图 vs 把智能体执行序列设计成图。几乎毫无交集。却都被叫做“图工程”，所以很可能聊天中的人脑子里想的是完全不同的东西

2. 但说实话，这也不是全新的概念（反转来了）：把智能体拆成多个节点——因为单个节点循环有局限——这个想法早在 2024 年就以编排者-工作者模式被勾勒出来了，2026 年初也有人叫它“流程工程”。所以到头来，它更像是重新包装，而不是新发现。

3. 那我们该怎么办？为了避免混淆，直接拆分：知识图工程、智能体图工程。尤其对团队文档或职位描述很有用（想象一下招知识图岗位却要求 LangGraph 经验——双方都尴尬）。

一个术语霸占两个含义的有趣案例。反过来想，几个月后它可能又换另一个名字，所以现在划清界限可能最终没意义。术语一直在变，但概念不会变——这才是关键收获

#그래프엔지니어링 #에이전트오케스트레이션 #지식그래프

不必全信我的话，自己去查证吧。 参考资料： •“智能体编排含义在 2026 年 7 月中旬在 X 上激增” — https://aibuilderclub.com/blog/graph-engineering-guide-2026… •“知识图工程术语冲突，之前流程工程等概念总结” —

图工程指南 (2026)

来源：https://www.aibuilderclub.com/blog/graph-engineering-guide-2026 首页 (https://www.aibuilderclub.com/) / 博客 (https://www.aibuilderclub.com/blog) / 图工程指南 (2026) #ai-agents #graph-engineering #orchestration #multi-agent #advanced

图工程：2026 年从单一智能体循环向多节点智能体图的转变。它是什么，循环 vs 图，框架，以及诚实的炒作审视。

2026 年 7 月 20 日 · 15 分钟阅读

课程大纲 · 构建 AI 智能体 (4.15) 图工程是将多个专用智能体或步骤连接成图的做法——节点负责工作，边负责在节点之间路由，共享状态沿这些边流动——适用于单个智能体运行一个循环已经不够用的情况。 这是 2026 年 7 月中旬在 X 上引爆的说法，被视为“循环工程”之上的层级。而任何诚实指南首先必须告诉你的是：大多数任务永远用不到它，那些嘲笑它是垃圾的人说的有道理，你整篇都得记着这一点。

许多人豁然开朗的时刻是这样的：你有一个智能体愉快地在一个循环里运转——发现、规划、执行、验证、重复——一切正常，直到任务不再是一个工作。现在变成了“先研究这个，然后写出来，再让一个挑剔的家伙把草稿批得体无完肤，最后决定是发布还是打回去”。你可以把所有这些塞进一个智能体的循环里，然后看着它迷失方向。或者你可以把每个工作都交给它自己的节点，再把它们连接起来。第二个做法就是图。

本指南是平实、不炒作的解读：图到底是什么，什么时候确实比循环强（以及什么时候只是你事后会后悔的复杂），那些在炒作词出现一年前就默默在做这件事的框架，以及对时间线上最响亮的问题——“这不就是垃圾吗？”——的清醒回答。

我们是如何从循环走向图的？

每年，AI 工程中的杠杆作用都向外模型移动一层。一口气看清整条线会有帮助：

我们在《循环工程：停止写提示，开始写验证器》(https://www.aibuilderclub.com/blog/loop-engineering-guide-2026) 中详细介绍了前四个台阶，并在《从提示到循环：四次转变》(https://www.aibuilderclub.com/blog/prompt-context-harness-evolution) 中追溯了整个攀登过程。图是最新的台阶，而且就几天前才最新。

这个词大约在 2026 年 7 月 18-19 日 在 X 上定形。种子是一个问题。Peter Steinberger——OpenClaw 的创建者——通过 @sairahul1 转述问道：“我们还在谈循环，还是已经转向图了？” 这就是全部起源：不是发布，不是论文，而是一个构建者好奇框架是否已经移动了。

一天之内，时间线给出了答案。@svpino 把它写成了一段伪悼词：“循环工程已死。图工程万岁！” @rohit4verse 给出了那个被广泛引用的框架：“循环工程是最后一项解锁。图工程是下一项。智能体正在从 while 循环毕业到组织架构图。专用节点并行运行，状态在它们之间流动。” 而 @VaibhavSisinty 没有使用标签就描述了背后的动向：“AI 智能体的构建方式正在发生一场静默的转变……过去一年里，AI 智能体以循环方式工作。你给它一个任务。它规划。它行动。它检查。它修复。”

请注意这里 没有 什么：没有新的能力。7 月 18 日没有人发布了你在 7 月 17 日做不到的事情。改变的是人们对一个已经遇到的设计问题所起的名称——即单个循环不再适合工作的形状。记住这一点。这是下面所有诚实看法的关键。

智能体图到底是什么？

去掉术语，一个智能体图恰好有三个部分：

• 节点 —— 执行工作的单元。一个节点通常是一个专用智能体（“研究者”、“写作者”、“审查者”）或一个简单的确定性步骤（函数、工具调用、数据获取）。每个节点负责一项工作。
• 边 —— 节点之间的路由。边说明“在此节点之后，前往那个节点”。边可以是直的（A 然后 B），条件式（如果审查通过则发布；如果不通过则循环回去），扇出（一个节点同时启动三个），以及扇入（三个结果合并回一个）。
• 共享状态 —— 沿着边流动的对象。它是每个节点读取和写入的内容：任务、截至目前草稿、笔记、裁决。状态是把一堆智能体变成一个 系统，而不是一个什么都记不住的群聊。

在 X 上被广泛引用的比喻是 @rohit4verse 的 组织架构图。一家公司不会让一个人不间断地完成研究、写作和审查。它把这些交给不同的角色，在他们之间路由工作，然后让结果向上汇总。智能体图也是同样的思路：专用角色、定义好的交接、共享记录。

下面是标准的入门图——研究者把信息传给写作者，审查者检查草稿，条件边决定是发布还是打回去：

三个节点，四条边——其中一条是条件边，一条是回到写作者的循环边。状态随着流动而增长：研究者的笔记跟着去写作者，草稿跟着去审查者，审查者的裁决决定下一条边。

现在，不让整件事感觉像全新宇宙的那一部分：循环就是一个只有单个节点且有一条边指向自身的图。 你学到的关于设计循环的一切（发现/规划/执行/验证循环、停止条件、验证器）——都是 一个节点内部 的内容。图并不取代循环。它是在你有几个需要相互交接的循环时得到的东西。如果你想了解那些单个循环可能是什么样子的分类，我们在《智能体循环的类型》(https://www.aibuilderclub.com/blog/types-of-agentic-loops) 中做了映射。图工程是决定它们如何连接的层次。

什么时候应该使用图？

这个问题把有用的构建者和那些只是为了好玩才往图上添框的人区分开。默认答案——我们真的是说这是整篇文章的核心主张——是：你很可能不需要。 一个范围明确、有清晰验证器的任务就是一个循环，这种情况下使用图纯粹是额外开销。

下面是诚实的决策表：

把那表看作一组 触发器 而不是需要满足的清单。你不需要全部六项。但如果诚实答案通常都在左列，那么构建图就是把一个两小时的任务变成两天框架项目的方法。

过度工程化——你不需要的图

“总结这个 PDF。” 你构建了一个五节点图：获取器、分块器、总结器、审查器、格式化器，带条件边和共享状态对象。它工作了——但构建更慢、调试更难、运行更贵，而它本应该只是一个在循环中读取文件并写出摘要的智能体。你为了回复一封邮件而设计了一个组织架构图。

规模恰当——值得的图

“每天早上制作一份经过研究、事实核查的市场简报。” 一个研究者节点同时向五个来源扇出；一个综合器合并它们的结果；一个写作者起草；一个怀疑论审查者节点——不同模型，只读——给它打分，失败时循环回去。每个节点都承担单一循环无法容纳的工作，交接正是重点。

判断依据是图是否在执行 循环无法完成的工作。如果你能把五个节点折叠回一个智能体的循环且毫无损失，那就应该这么做。我们在《智能体图 vs 循环：何时使用哪种》(https://www.aibuilderclub.com/blog/agent-graph-vs-loop-when-to-use) 中深入探讨了具体判断——边界情况、成本计算和迁移路径，并在《图工程 vs 循环工程》(https://www.aibuilderclub.com/blog/graph-engineering-vs-loop-engineering) 中讨论了这两个学科的关系。一句话版本：先精通循环，只有当工作迫使你时，再把它拆成图。

免费 AI 构建者通讯

每周关于 AI 工具和构建者策略的指南。

这不就是 LangGraph 吗？

时间线上最尖锐的回复是类似“恭喜，你重新发明了 LangGraph”的说法。这值得一个直接回答，因为基本正确，而假装不是正是怀疑论者所指出的炒作。

将智能体系统构建为 共享状态之上的节点和边的图 的想法，早在这个术语“图工程”流行之前就已经在实际工具中实现了。以下是诚实的先前成果，只描述到官方文档支持的程度（截至 2026 年 7 月）：

• LangGraph（来自 LangChain），根据其官方文档，是 “一个用于构建、管理和部署长时间运行、有状态智能体的底层编排框架和运行时。” 实际使用中，你定义 StateGraph，添加节点，添加它们之间的边——正是上述节点/边/状态模型。如果你用过 LangGraph，那你一直在做图工程，只是名字不同。(文档 (https://docs.langchain.com/oss/python/langgraph/overview))
• Microsoft AutoGen - GraphFlow 将基于图的多智能体编排引入 AutoGen：你描述一组智能体如何连接和交接，而不是孤立地运行一个智能体。(此处按给定级别描述；请查看当前 AutoGen 文档以获取确切 API，该 API 在 2026 年期间一直在变动。)
• Google ADK（智能体开发工具包）将图模型作为主打功能。其文档描述了通过 “结构化、基于图的架构” 编排 “复杂任务”，并提供了名为 顺序、并行和循环工作流智能体 的组件，以及智能体路由——扇出/扇入和循环作为一等构建块。（其 Go SDK 在 2026 年达到 2.0 GA；图模型也覆盖了 Python/TypeScript/Java/Kotlin SDK。）(文档 (https://adk.dev/))
• A2A（智能体对智能体） 是一个开放协议，让智能体跨系统相互委派任务——即“不同团队拥有的图之间的边”这一层。值得提及，因为它最清晰地证明了多智能体想法在企业中有真实、先于炒作的历史（下面怀疑论者会更多谈到这一点）。

那么：图工程就只是 LangGraph 吗？技术上，很大程度上是的——LangGraph、GraphFlow 和 ADK 先做到了。2026 年中期真正新的东西更狭窄、更柔和：一个 共享的名称，用于这些框架一直要求你做的设计决策（节点是什么、边是什么、状态里有什么），以及一种越来越强烈的感受，即这是一项值得教授的不同技能，而不是一个框架细节。那是真实的事情。但它比“一个新范式”要小得多，我们在《图工程就只是 LangGraph 吗？》(https://www.aibuilderclub.com/blog/is-graph-engineering-just-langgraph) 中明确这么说了。

AI 工程的 5 层是什么？

在不夸大图工程的情况下定位它的最清晰方式来自 @sairahul1，他用一句话概括了整个栈：“提示、上下文、工具套件、循环和图工程，清晰解释！最好的 AI 工程师不再只是写提示。他们围绕模型对整个系统进行工程化。你可以将 AI 应用看作五层。”

每一层都在离模型一步之外进行工程化：

这个栈的有用之处在于它是累积的，而不是一个你 远离 的梯子。一个图里全是节点；一个好的节点就是一个设计良好的循环；一个好的循环需要一个真正的工具套件（六个组件：上下文、工具、编排、状态、评估、恢复），让智能体能够行动。跳过低层，上层的图只会以更精致的方式失败。如果你的节点是弱智能体，把它们连接成组织架构图只能得到一个弱的组织。我们在《AI 工程的 5 层》(https://www.aibuilderclub.com/blog/five-layers-ai-engineering) 中逐层拆解了整个栈；简版是图工程是 最外层，这也让它成为你应该最后才考虑的那一层。

图工程就是垃圾吗？

是时候进入怀疑论者会直接滚动到的部分了——他们有这个资格，因为