图工程指南（2026）
图工程：从单 Agent 循环到多节点 Agent 图的 2026 年范式转变。本文将深入解析图工程的核心概念、循环与图的对比、主流框架，并带来一次坦诚的行业审视。
简单来说，图工程就是把多个专业化的 Agent 或步骤组织成一个“图”结构来协同工作。节点负责执行具体任务，边负责在节点之间传递数据，而共享状态就沿着这些边不断流动。当单个 Agent 运行一个循环已无法应对复杂场景时，图工程就该登场了。这个框架在 2026 年 7 月中旬突然引爆了 X 平台，被视为处于循环工程之上的一个抽象层。不过，任何诚实的指南在开头都得先泼盆冷水：绝大多数任务根本用不上它，那些嘲讽它是多余的人，其实说得不无道理。这一点，你最好从一开始就记在心里。
你可能会经历这样一个恍然大悟的时刻：你有一个 Agent 在愉快地循环运转——发现、规划、执行、验证、重复——一切正常，直到任务不再只是单一的工作。现在，它需要先调研，再撰写，然后让某个持怀疑态度的人撕碎初稿，最后决定是发布还是打回重做。你可以把所有这些都塞进一个 Agent 的循环里，然后看着它逐渐失去头绪。或者，你可以把每项工作分配给各自的节点，再把它们连接起来。第二种方式，就是图。
本指南是对图的一次平实、不炒作的解读：图究竟是什么，什么时候它真正优于循环（以及什么时候它只会带来让你后悔的复杂性），那些在流行词汇出现前一年就默默实现这一点的框架，以及对时间线上最响亮的问题——这难道只是过度炒作吗？——的清晰回答。
我们是如何从循环走向图的？
每年，AI 工程中的杠杆作用都会向外远离模型一层。同时看清整条线会很有帮助：
| 时代 | 层级 | 你所构建的内容 | 你的角色 |
|---|---|---|---|
| 2023-24 | Prompt | 你发送的请求 | 操作员 |
| 2024 | Context | 模型所能看到的内容 | 编辑器 |
| 2025 | Harness | 围绕模型构建的工具、记忆与支撑框架 | 工具制造者 |
| 2026 年初 | Loop | 智能体重复执行的循环，直至任务完成 | 系统设计师 |
| 2026 年中 | Graph | 多个 Agent/步骤之间的协作 | 架构设计师 |
在《Loop Engineering: Stop Writing Prompts, Start Writing Verifiers》和《From Prompts to Loops: The 4 Shifts》中，我们已经涵盖了前四个台阶。Graph 是最新的台阶——而且新得只是几天前的事。
这个词在 2026 年 7 月 18-19 日左右在 X 上逐渐成型。起因是一个问题。OpenClaw 的创建者 Peter Steinberger 通过 @sairahul1 转述了一句话：“我们还在讨论 Loop，还是已经转向 Graph 了？”这就是全部的起源：不是一次发布，不是一篇论文，而是一个构建者在大声质疑这个框架是否已经转移。
一天之内，时间线给出了答案。@svpino 用一种模拟悼词的方式表达：“Loop Engineering 已死。Graph Engineering 万岁！” @rohit4verse 给出了那个被广泛引用的框架：“Loop engineering 是最后的解锁。Graph engineering 是下一个。Agent 正在从 while 循环毕业到组织架构图。专业化节点并行运行，状态在它们之间流动。”而 @VaibhavSisinty 则在不用标签的情况下描述了这种底层变化：“AI Agent 的构建方式正在发生一个悄然的变化……过去一年，AI Agent 以循环方式工作。你给它一个任务。它计划。它行动。它检查。它修复。”
注意这里没有的东西：一个新的能力。没有人在 7 月 18 日发布任何你在 7 月 17 日就做不到的东西。变化的是人们对一个他们早已遇到的设计问题所贴的标签——一个循环不再是工作的正确形态。记住这一点。这是下面每一个客观分析的关键。
什么是 Agent 图？
去掉术语，Agent 图恰好有三个部分：
- Nodes（节点）——执行工作的单元。一个节点通常是一个专门的 Agent（"研究员"、"写作者"、"审核员"）或者一个简单的确定性步骤（一个函数、一次工具调用、一次数据获取）。每个节点只负责一项工作。
- Edges（边）——节点之间的路由。一条边指明：执行完这个节点后，下一步该去哪个节点。边可以是直连型（先 A 再 B）、条件型（若审核通过则发布，若不通过则循环回退）、扇出型（一个节点并行启动三个子节点），以及扇入型（三个结果汇聚成一个）。
- Shared state（共享状态）——沿着边传递的对象。它是每个节点都会读取和写入的东西：任务、当前草稿、备注、判定结果。状态是将一堆 Agent 转化为系统的关键，而非一个转眼就遗忘所有内容的群聊。
在 X 平台上引发热议的比喻是 @rohit4verse 提出的组织架构图。一家公司不会让同一个人不间断地完成研究、撰写和审核工作，而是将这些任务分配给不同角色，让工作在这些角色之间流转，最终汇总成果。Agent 图正是同样的理念：专业化分工、明确的交接机制、共享的工作记录。
以下是一个经典的起始图示例——研究者向撰写者提供内容，审核者检查草稿，条件边决定是发布还是退回：
┌──────────────┐ task ───────► │RESEARCHER│ gathers sources, writes notes └──────┬───────┘
│
state: {task, notes}
▼
┌──────────────┐
│WRITER│ turns notes into a draft
└──────┬───────┘
│
state: {task, notes, draft}
▼
┌──────────────┐
│ REVIEWER │ scores the draft against the bar
└──────┬───────┘
│
pass? ─┴─ no ──► back to WRITER (conditional edge / loop)
│
yes
▼
┌──────┐
│ SHIP │
└──────┘
三个节点，四条边——其中一条是条件边，一条是回到写作者的循环。状态随着流动而增长：研究者的笔记流向写作者，草稿流向审核者，而审核者的裁决决定下一条边。
现在，让整个体系不至于感觉像是一个全新宇宙的关键在于：循环本质上就是一条带有自环边的单节点图。你学过的所有关于循环设计（designing loops）的内容——发现/规划/执行/验证循环、终止条件、验证器——都位于这个节点的内部。图并不会取代循环。当你拥有多个需要互相衔接的循环时，图就是由此产生的结构。如果你想了解这些独立循环可能呈现的形态分类，我们在《Agentic 循环类型（The Types of Agentic Loops）》一文中已经进行了详细梳理。图工程正是决定这些循环如何连接的层面。
何时该使用图？
这个问题区分了真正的实用构建者和那些为了好玩在图上画方框的人。默认答案—我们想强调，这是贯穿本指南的核心主张—是：你很可能不需要。一个范围明确、带有清晰验证器的单一任务本身就是一个循环，在这种情况下使用图只会带来纯粹的额外开销。
以下是一份诚实的决策对照表：
| 工作中的信号 | 循环已足够 | 使用图 |
|---|---|---|
| 任务的形态 | 单一任务，终点明确 | 拆分为不同专业并相互交接 |
| 并行性 | 步骤顺序执行 | 你需要扇出（同时执行多个）然后汇合 |
| 每个步骤的工具/模型 | 全程使用相同的工具 | 每个步骤使用不同的模型或工具集 |
| 控制流 | 单个 Agent 可以安全地自由漫游 | 角色之间需要明确且可审计的路由 |
| 故障隔离 | 一个糟糕的步骤只会重试 | 你希望一个糟糕的节点失败，而不会影响其他节点 |
| 由谁来验证 | Agent 检查自身的循环输出 | 一个专门的审查节点检查另一个节点的工作 |
将这张表格视为一组触发条件，而非需要满足的检查清单。你不需要全部六条都满足。但如果大多数问题的诚实回答都落在左列，那么构建图就是将两小时的任务变成两天框架项目的方式。
过度设计 —— 你不需要的图
“总结这个 PDF。”你构建了一个五节点图：一个抓取器、一个分块器、一个摘要器、一个审查器和一个格式化器，配有条件边和一个共享状态对象。它能工作——但构建更慢、调试更难、运行成本更高，而它本应只是一个在循环中读取文件并写出摘要的 Agent。你用工程化的组织架构图去回复一封邮件。
规模适中 —— 值得维护的图
“每天早晨生成一份经过研究和事实核查的市场简报。”一个研究节点并行访问五个信息源；一个综合节点整合他们的发现；一个写作节点起草报告；一个持怀疑态度的评审节点——使用不同的模型、只读模式——对其进行评分，若未达标则循环反馈。每个节点都承担着单一循环无法完成的工作，而节点之间的交接才是核心所在。
判断标准在于：这个图是否完成了循环无法完成的工作。如果你能把五个节点压缩回一个 Agent 的循环中且毫无损失，那就应该这么做。关于具体决策——边界情况、成本计算和迁移路径——我们将在《Agent Graph vs Loop: When to Use Which》中深入探讨，并在《Graph Engineering vs Loop Engineering》中阐述这两种方法论之间的关系。一句话总结：先精通循环，只有当工作量迫使你出手时，才将其拆解为图。
这不就是 LangGraph 吗？
时间线上最犀利的回复大致是“恭喜你重新发明了 LangGraph”。这个问题值得正面回答，因为这种说法大体正确，而假装并非如此恰恰就是怀疑论者所批评的那种炒作。
将 Agent 系统构建为节点和边在共享状态上组成的图这一理念，早在“图工程”术语流行之前就已通过真实工具实现。以下是截至 2026 年 7 月官方文档所支持级别的诚实先例：
- LangGraph（来自 LangChain）根据其官方文档，是“用于构建、管理和部署长时间运行、有状态 Agent 的低层级编排框架与运行时”。实际操作中，你需要定义
StateGraph，添加节点，再添加它们之间的边——这正是上述节点/边/状态模型。如果你用过 LangGraph，你其实一直在做图工程，只是名称不同而已。(文档) - Microsoft AutoGen - GraphFlow 为 AutoGen 带来了基于图的多 Agent 编排能力：你可以描述一个 Agent 团队如何相互连接并交接任务，而非孤立运行单个 Agent。（此处按给定级别描述；具体 API 请查阅当前 AutoGen 文档，该 API 在 2026 年间持续更新中。）
- Google ADK（Agent 开发工具包）将图模型作为其核心功能亮点。其文档描述了如何“通过结构化的、基于图的架构编排复杂任务”，并内置了命名：顺序执行、并行执行和循环工作流 Agent，以及 Agent 路由——扇出/扇入和循环作为一等构建模块。（其 Go SDK 在 2026 年发布了 2.0 正式版；图模型也覆盖了 Python/TypeScript/Java/Kotlin SDK。） (文档)
- A2A (Agent2Agent) 是一种开放协议，允许 Agent 跨系统相互委托——即“由不同团队拥有的图之间的边”这一层。之所以值得提及，是因为它是最清晰的证据，表明多 Agent 概念在企业中拥有真实且早于流行术语的历史（更多内容见下文一位怀疑者的观点）。
那么：图工程只是 LangGraph 吗？从技术层面来说，基本上是的——LangGraph、GraphFlow 和 ADK 率先做到了这一点。2026 年中期真正的新东西更窄、更软：这些框架一直要求你做出的设计决策终于有了一个共同的名称（节点是什么、边是什么、状态里有什么），以及越来越多的人意识到这是一项值得教授的独立技能，而不是框架的细节。这是一件真实的事情。只是它比“新范式”要小得多，我们在《Is Graph Engineering Just LangGraph?》中直截了当地说了这一点。
AI 工程的 5 个层次是什么？
关于图工程最恰当的定位（不过度吹捧）来自 @sairahul1，他用一句话概括了整个技术栈：“提示词、上下文、工具、循环与图工程，清晰讲解！最优秀的 AI 工程师不再只是写提示词了。他们围绕模型设计整个系统。你可以把一个 AI 应用想象成五个层次。”
每个层次都在模型的基础上进一步设计系统：
| # | 层级 | 工程化内容 | 核心问题 |
|---|---|---|---|
| 1 | Prompt | 单个请求 | 我问得好吗？ |
| 2 | Context | 模型所看到的内容 | 它是否掌握了正确的信息？ |
| 3 | Harness | 工具、记忆、框架 | 它能真正行动并记住吗？ |
| 4 | Loop | 一个 Agent 运行的重复周期 | 它何时检查自己的工作并停止？ |
| 5 | Graph | 多个 Agent/步骤之间的协调 | 谁做什么、按什么顺序、共享什么状态？ |
这个栈的有用之处在于它是累积性的，而不是一个你爬上去就离开的梯子。一个图由众多节点构成；好的节点是一个设计精良的循环；好的循环需要真正的“harness”——六个组件（上下文、工具、编排、状态、评估、恢复）使 Agent 能够真正行动。跳过底层，上层的图只会以更复杂的方式失败。如果你的节点是薄弱的 Agent，把它们连接成组织结构图只会得到一个薄弱的组织。我们在《The 5 Layers of AI Engineering》中逐层分解了整个栈；简而言之，图工程是最外层，这也意味着它是你应该最后才触及的层次。
图工程只是垃圾吗？
是那些持怀疑态度的人会直接跳过的部分——他们完全有理由这么做，因为这个词几乎还没出现，反对声浪就已经到了。这和我们在循环指南里用的手法一样：把词语和变革分开，合理承认所有批评，最终落脚到一个你能站得住脚的位置。
这些批评者并非偏执狂。他们中有些人正是对这个领域最了解的人：
- @RhysSullivan 在这篇文章出现之前就预言道：“明天推特上会有一篇关于‘图工程’的万字废话文章。”然后，当那篇文章真的出现时，他干巴巴地补了一句：“一篇图工程文章上线了时间线。”这种嘲讽针对的是围绕这个术语兴起的内容农场淘金热——这很合理，因为那一周发布的大部分内容确实就是如此。
- @DavidKPiano, XState 的创建者——一位花费多年构建状态机工具的人——警告道：“在阅读关于‘Agent 图工程’的粗制滥造文章之前，请牢记这一点。” 当一位真正的状态机专家对“图”被当作新事物宣布时翻白眼，这并非守门行为，而是有人在指出：由状态和转换组成的有向图，是已有数十年历史的计算机科学。
- @PawelHuryn 追溯了整个发展脉络后表示：“我对图谱工程的说法不买账。循环工程已经够让人困惑的了……” 按照他自己的表述，他的替代方案是跳过机制命名，直接告诉 Agent 目标是什么、为什么重要、以及如何衡量成功。关键在于：命名一直在把机制（循环、图）误当作本质（目标和验证）。
- @NathanFlurry 将现有技术先例具体化：“有意思的是，这些‘图工程’的文章都没提到 A2A。” 在后续回复中他补充道：“领英 2025 年就在做这个了，IBM 的动作更快。” 他的观点是，多 Agent 委派的概念（A2A 及其衍生协议）已经拥有真实的企业级应用历史，所以在 2026 年 7 月为它造一个推特热词，不是超前，而是滞后。
承认这一切，因为这一切都是真实的。其底层机制并非新鲜事物：有向图、状态机、编排引擎以及 Agent 间协议，早在这些流行词出现之前就已存在多年。许多打着这个术语旗号的内容都是垃圾。而“图工程”这个说法也并非必要——你可以按照本指南构建所有系统，却从未使用过这个词。
现在将词语与转变分离开来。在喧嚣之下，一场真正的设计升级正在发生，这正是 @VaibhavSisinty 和 @rohit4verse 所描述的：在 2026 年初，那些擅长让一个 Agent 在循环中运行的团队，如今正撞上一堵墙——单个循环的形状已经不再适用，因此他们有意地将工作拆分为协调运作、状态在节点间流动的专业化节点。无论你是否称之为“图工程”，这场升级都是真实存在的，就像无论你是否喜欢“循环工程”这个词，它本身也是真实存在的一样。怀疑论者反驳的并非升级本身——他们反驳的是围绕这个名称产生的炒作，而这一点他们是对的。
以下是过滤器，与循环指南相同：
- 当工作需要时，团队是否真的从“单一循环中的单个 Agent”转向了“多个专业化 Agent 通过共享状态协调运作”？Yes.
- 这种协作是否是一种独特的设计技能——选择节点、边和状态——与设计单一循环截然不同？Yes.
- “图工程”这个词是否新颖、有分量、且不含杂质？No —— 其机制早已存在，而 2026 年 7 月的多数内容只是杂音。
这个标签可有可无。但从单一循环升级为协作图确实是真实的演进趋势。只是别在需要之前就贸然使用——对你本周正在构建的大多数项目而言，时机尚未成熟。
您的图工程启动清单
在将循环转为图之前，先用这个思路检验一下：
- 尽量使用循环。 一个范围明确的 Agent 配合良好的验证器能否完成这项任务？如果能，就此打住。你已经完成了。
- 仅当节点是真正的专业领域时才为其命名。 每个节点应承担单一循环确实无法容纳的工作——不同的模型、不同的工具集，或只读的审查角色。“可以内联的步骤”不构成节点。
- 在编码前先绘制边。 设计路由：哪些是顺序执行，哪些是扇出，哪些是扇入，以及唯一的条件/回环边位于何处。如果无法在餐巾纸上画出来，说明它过于复杂了。
- 显式设计共享状态对象。 确定哪些数据沿边流动，以及谁有权写入。状态漂移是图腐化的第一大原因。
- 给审查节点装上“牙齿”。 通常，单一最高价值节点是一个独立的、只读的验证器——一个与生成工作的 Agent 不同的 Agent。（这是循环指南中“不要让 Agent 自我验证”的原则，被提升为一个节点。）
- 隔离失败。 确保一个节点可以失败并重试，而不会破坏共享状态或污染下游节点。
- 选择一个框架，而不是手动构建。 LangGraph、AutoGen GraphFlow 或 Google ADK 已经为你提供了节点、边、状态、扇出/扇入和循环。重新发明运行时本身就是一种低效行为。
- 设置一个消费上限和一个硬性限制。 图中包含多个循环；一个弱的验证器现在会并行消耗 Token。限制它。
如果你这周构建一个图，成功的标准不是“它有最多的节点”，而是“每个节点都在做循环无法完成的工作，而且我仍然能一口气解释整个图的工作原理”。
相关内容
- Graph Engineering vs Loop Engineering—— 这两门学科的分界线、各自用途，以及为什么循环是你首先要掌握的东西。
- Agent Graph vs Loop: When to Use Which - 何时使用哪种——边界案例、成本计算，以及从单一循环迁移至图的诚实路径。
- Is Graph Engineering Just LangGraph?—— 全面回顾已有成果：LangGraph、AutoGen GraphFlow、Google ADK 和 A2A——以及哪些是真正的新事物，哪些只是换了个说法。
- The 5 Layers of AI Engineering—— 提示词、上下文、框架、循环、图——完整技术栈解析，以及为何每一层只有在其下层稳固时才能发挥作用。
- Loop Engineering: Stop Writing Prompts, Start Writing Verifiers - 这是直接位于其下的一个层级。一个节点就是一个循环；这便是设计它的方法。
- Harness: The 6 Components - 上下文、工具、编排、状态、评估、恢复。是什么让单个节点强大到足以接入图。
- The Types of Agentic Loops - 存在于节点内部的循环分类体系。
常见问题解答
什么是图工程（graph engineering）？
图工程是将多个专门的 Agent 或步骤编织成一个图（graph）的实践——节点（即 Agent/步骤）、边（即节点间的路由，包括分支、扇出/扇入和循环），以及沿边流动的共享状态——而非依赖单个 Agent 运行一个循环。这是 2026 年 7 月中旬在 X 平台上浮现的框架，位于循环工程（loop engineering）之上。单个循环是特例：一个节点带有指向自身的边。
图工程只是炒作吗？
部分是的。像@RhysSullivan、@DavidKPiano（XState 的创建者）、@PawelHuryn 和@NathanFlurry 这样的怀疑者是对的：其机制并非新事物——图编排（graph orchestration）、状态机（state machine）以及像 A2A 这样的 Agent 间协议，早在该术语出现前一年或更久就已存在。但请将这个词本身与背后的转变区分开：从单一循环升级为一组协作的专门节点，且节点间有状态流动，这是团队实际会采取的设计步骤。标签可有可无，但升级是真实存在的——只是别在真正需要它之前就过早采用。
什么是 Agent 组织架构图？
这是 @rohit4verse 对 Agent 图的一个比喻：Agent 从“while 循环”进化到“组织架构图”，其中“专业化节点并行运行，状态在它们之间流动”。就像公司的组织架构图一样，每个节点都有其职责，工作在角色之间流转，结果再向上汇总。这是一个有用的概念模型，但需要谨记一个警示：大多数工作仍然由单个人在循环中完成，而非整个组织。
