你可能已经学会了让 AI 按步骤干活——先理解任务，再执行，再检查，再修正。
这叫 Loop Engineering。
但最近，AI 圈有人说：Loop 死了。
不是说 Loop 没用了。
而是说，当任务复杂到一定程度，一个 Loop 撑不住了。
你需要的是一群 Loop 协作。
这就是 Graph Engineering。
你可以把它理解成：
不再让一个 AI 循环干活，而是设计一张任务流程图，让多个 AI 各管一段，按顺序交接。
一、为什么你需要理解 Graph Engineering
2026 年 7 月 18 日凌晨，Peter Steinberger在 X 上发了一条推：
https://x.com/steipete/status/2078277297791189132
就这一句，九个词，被浏览了 300万次。
对，就是那个前阵子还在说Loop的那个人。
4 个半小时后，AI 评测领域的大佬 Hamel Husain 跟了一篇长文，标题只有两句话：
https://x.com/HamelHusain/status/2078346425621237935
有意思的是，Loop Engineering 这个词从被命名到被宣告死亡，只隔了 41 天。
你可能会觉得：又是 AI 圈在造词。
但这次不太一样。
因为问题是真的——当你的 AI 任务从"写一篇文章"变成"做一个产品"，一个 Loop 确实不够用了。
Loop Engineering 解决的是：一个 AI 怎么持续干活。
Graph Engineering 解决的是：一群 AI 怎么协作干活。
二、Graph Engineering 到底是什么
Graph，中文是"图"。但不是图片的图，是流程图的图。
Engineering，是工程化。
Graph Engineering，就是把一个复杂任务拆成多个节点，用流程图的方式定义它们之间的关系。
你可以把它想成一个后厨。
Loop 是一个厨师自己包揽一切
——切菜、炒菜、调味、装盘，做完一步回头检查一下，不行就重来。
Graph 是一整个后厨团队
——有切配、有炒锅、有打荷、有出菜，每个岗位只干一件事，按流程传菜。
一张 Graph 就三样东西：
节点（Nodes）——一个干活的单元。可以是一个 AI、一次工具调用，甚至一个点头的人。
边（Edges）——决定下一步跑什么。可以是顺序、可以并行，也可以按上一步的结果走不同分支。
状态（State）——在节点之间流动的信息。每个节点都读它，也都写它。
听起来抽象？看个具体例子。
你要让 AI 写一篇深度文章，用 Graph 的思路是这样的：
- 第一个节点：研究——搜索资料、整理要点
- 第二个节点：写作——基于研究结果写正文
- 第三个节点：审阅——检查质量，不合格就退回
三个节点，两条边，一个共享状态。
这就是最小的 Graph。
Loop 是一个人转圈，Graph 是一群人接力。
三、Loop 为什么不够用了
不是所有任务都需要 Graph。
如果你只是让 AI 翻译一句话、写 10 个标题、解释一个概念——一个 Loop 足够了。
但当任务出现这三种情况，Loop 就开始撑不住了。
1. 需要不同角色
比如做一期播客内容。
研究资料的人、写脚本的人、审稿的人、做封面的人——这些角色用的提示词不同，关注的重点不同，甚至该用不同的模型。
全塞进一个 Loop，AI 会角色混乱。一会儿在研究，一会儿在写稿，一会儿又回头检查，越跑越糊涂。
2. 需要条件分支
比如写代码。
测试通过就进入下一步，测试失败就要回去修。有时候修一处会影响别的地方，需要重新评估。
这种"如果 A 就走 B，如果 C 就走 D"的逻辑，在 Loop 里写起来特别拧巴。但在 Graph 里，它就是一条条件边的事。
3. 需要并行
比如做一份行业调研。
你要同时搜索 5 个方向的信息，等全部回来再汇总。
Loop 是串行的——一件一件来。Graph 可以让 5 个节点同时跑，跑完汇总。
判断标准很简单：当一个 Loop 跑到第三轮还搞不定的事，就该考虑 Graph 了。
四、Loop 和 Graph 到底什么关系
这是整篇文章最重要的一句话：
Loop 其实就是 Graph 的特例。
什么意思？
你之前写的那个循环：
AI 思考 → 执行 → 检查 → 不合格就再来
用图来表示，就是一个节点，加一条指回自己的边。
1[AI 干活]2 ↑ ↓3 └────┘ （自环边）
所以 Loop 没有死。Loop 只是变成了 Graph 里的一个基础结构。
Graph Engineering 做的不是取代 Loop，而是：
- 把一个个 Loop 连起来
- 管住它们之间的协调
你可以这么理解：
- Loop 解决了"一个 AI 怎么干活"
- Graph 解决了"一群 AI 怎么协作"
这就像从"个人贡献者"升级到"团队管理"。
单兵作战的能力没消失，但你还需要学会怎么排兵布阵。
五、真正变的不是图，是图里的节点
你可能会说：流程图、状态机、任务调度——这些不是计算机科学里几十年的老东西吗？
没错。
Airflow 画了十年的任务图。Anthropic 2024 年那篇《Building Effective Agents》也画过所有模式。
那为什么现在又重新炒？
因为真正变的，不是图的结构，是图里的节点。
过去的图，节点是机器。 你写好规则，它就这么跑。输入什么，输出什么，完全确定。
现在的图，节点是 AI。 你给它一个任务，它自己理解、自己判断、自己执行。理解对了就好，理解偏了，后面的节点全跟着偏。
这个变化带来了三个全新的问题：
- 状态会腐烂——AI 写错一笔，下游全跟着错
- 路由会漂移——同一个任务，跑两次走两条路
- 验证会失灵——AI 审 AI，互相点头
这才是 Graph Engineering 真正在讨论的事。
不是怎么画图，是怎么管住一群会自己思考的节点。
六、Graph Engineering 的 4 个核心模块
1. 节点模块：每个节点凭什么存在
最常见的错误，是把简单任务拆成一堆节点。
"总结一份 PDF"你做了五个节点：抓取、切块、总结、审阅、排版。结果除了浪费 token，什么协同都没产生。
一个节点配得上位置，前提是它代表一种真正的专长：
- 换了模型（用 GPT-5 做研究，用 Claude 做审阅）
- 换了工具集（一个能搜网页，一个能跑代码）
- 确实是另一个角色（一个只读的审阅者）
检验标准：两个节点能合并成一个却什么也不损失，那它们本来就不该是两个。
2. 状态模块：信息怎么在节点间流动
在 Loop 里，失败叫"上下文腐烂"。到了 Graph 里，同一种病搬进了共享状态。
第二个节点写错的一笔，会成为第五个节点的输入。错误沿着边向下游传染，而且你很难发现是从哪一步开始错的。
几个工程上的做法：
- 给状态定一个明确的数据结构——别让字符串混进该是列表的地方
- 规定每个节点只能写自己负责的字段
- 在节点之间打检查点——好让你能重放一次运行，看清在哪步走歪的
没有状态管理的 Graph，就像没有账本的团队。每个人都在改数据，没人知道改了什么。
3. 路由模块：下一步走哪条路
每一条边都是一个决定。问题是，这个决定由谁来做。
让 AI 决定路线，灵活和不稳定会一起来。同一份输入，跑两次走不同的路，出了问题你根本复现不了。
Google 给 ADK 2.0 定的规则最干净：
- 条件清晰的地方，用代码路由（if/else）
- 真正需要判断的地方，才让 AI 决定
原则：能写死的地方就写死，AI 只花在需要解读的地方。
4. 审阅模块：怎么防止 AI 互相点头
这是个特别阴险的问题。
多个同源 AI，读着同一份有问题的上下文，会非常愉快地互相同意——AI 也偏爱自己的输出。结果就是结构漂亮，答案是错的。
怎么破：
- 审阅节点换一个不同的模型——别让一个家族的 AI 互相包庇
- 给它全新的上下文——而不是整段对话历史，让它真的独立思考
- 把结论锚定到外部证据——比如真的跑通的测试、真的编译过的代码
Cognition跑了一年之后得出的结论是：
多个 AI 可以读、可以发表意见，但任何时候只有一个 AI 被允许动手改东西。
读可以并行，因为一个糟糕的意见在没人照做之前不花一分钱。
写才是出事的地方，所以把它收在一处。
七、3 个小白可以直接照抄的 Graph 模板
1. 写文章 Graph
适合：深度长文、公众号、Newsletter
1任务：写一篇【主题】的深度文章23节点 1：研究4- 搜索相关资料5- 整理 5 个关键要点6- 输出：研究摘要78节点 2：写作9- 基于研究摘要写正文10- 输出：文章初稿1112节点 3：审阅13- 检查：开头有没有具体例子14- 检查：有没有空话和长段落15- 检查：读者看完知不知道下一步做什么16- 不合格则退回节点 2，最多退 2 次17- 合格则输出最终版1819路由规则：20- 研究完成 → 写作21- 写作完成 → 审阅22- 审阅不通过 → 写作（标记问题）23- 审阅通过 → 结束
2. 写代码 Graph
适合：功能开发、Bug 修复
1任务：完成【功能描述】23节点 1：理解4- 阅读现有项目结构5- 找到相关文件6- 输出：修改方案78节点 2：执行9- 按方案修改代码10- 输出：修改后的代码1112节点 3：测试13- 运行测试或检查功能14- 如果失败，读取报错原因15- 输出：测试结果1617节点 4：修复（条件节点）18- 根据报错修复19- 回到节点 3 重新测试20- 最多重试 3 次2122路由规则：23- 理解 → 执行 → 测试24- 测试通过 → 结束25- 测试失败 → 修复 → 测试26- 重试 3 次仍失败 → 输出卡住原因
3. 做调研 Graph
适合：行业分析、竞品分析、选题调研
1任务：调研【主题】23节点 1-5：并行搜索（5 个方向同时跑）4- 方向 A：市场规模5- 方向 B：主要玩家6- 方向 C：用户痛点7- 方向 D：技术趋势8- 方向 E：机会缺口910节点 6：汇总11- 把 5 份结果合并12- 去重、归类13- 输出：调研报告1415节点 7：事实核查16- 检查关键数据有没有来源17- 标记存疑的信息18- 输出：最终报告1920路由规则：21- 5 个搜索节点同时启动22- 全部完成 → 汇总23- 汇总完成 → 事实核查24- 事实核查完成 → 结束
八、从新手到进阶的学习路径
第一阶段：先把一个 Loop 练好
时间：1-3 天。
别急着画图。先把我上一篇的 Loop 模板用熟。
要有刹车（停止条件），要有验收标准，要有检查动作。
一堆弱 Loop 组成的 Graph，只是把失败分布式了。
检验标准：你能不用模板，也能写出一个带检查和停止条件的 Loop。
第二阶段：先在纸上画图
时间：3-7 天。
拿一个你手上的真实任务，在纸上画出流程图。
逼着每个节点为自己的存在辩护一次：你为什么是独立节点？你和其他节点有什么不同？
画完看一遍，你会发现很多节点根本不该存在。
检验标准：你画的图能在一张餐巾纸上放下。
第三阶段：定义状态结构
时间：7-14 天。
开始动手前，先把共享状态的数据结构定好。
比如写文章的 Graph，状态可以是：
- 主题：字符串
- 研究摘要：列表
- 文章初稿：字符串
- 审阅结果：通过 / 不通过
- 修改次数：数字
每个节点只能写自己负责的字段。
检验标准：你能在不运行的情况下，说清每个节点读什么、写什么。
第四阶段：组合多个 Graph
时间：14-30 天。
当你熟练以后，可以把大任务拆成多个子 Graph。
比如做一个知识付费小课：
- 第一个 Graph：选题调研
- 第二个 Graph：课程大纲
- 第三个 Graph：单节课脚本
- 第四个 Graph：营销文案
每个 Graph 只负责一个阶段，Graph 之间用状态传递结果。
复杂任务的秘密，不是一个超级 Graph，而是一串小 Graph。
九、新手最容易踩的 5 个坑
坑 1：为了图而图
"总结一份 PDF"做成五个节点。除了看起来高级，没有任何好处。
判断标准：如果一个 Loop 就能搞定，别做 Graph。
坑 2：状态不定义
节点之间传什么、写什么，全靠默契。
结果是第二个节点写了个字符串，第五个节点当列表用，直接崩了。
正确做法：先把状态结构定死，再开始跑。
坑 3：路由全交给 AI
"让 AI 自己决定下一步做什么"听起来很智能。
但同一个任务跑两次走了两条路，出了 bug 你根本复现不了。
正确做法：条件清晰的地方用代码写死，AI 只负责真正需要判断的步骤。
坑 4：审阅节点和执行节点用同一个模型
用 GPT-5 写的，再用 GPT-5 审。AI 偏爱自己的输出，审阅变成走过场。
正确做法：审阅节点换个不同底座的模型，给它全新上下文，让它真的独立思考。
坑 5：没有预算上限
Graph 是一堆节点在并行烧钱。一个弱节点反复重试，账单会吓到你。
正确做法：每个节点设最大重试次数和 token 上限。跑超了就停，告诉你卡在哪。
Graph 能帮你协调复杂任务，但账单和判断责任还是你的。
十、你今天就能开始的练习
别先学理论，今天就做一个最小练习。
选一个你手上的真实任务，比如：
- 写一篇深度文章
- 做一份竞品调研
- 开发一个小功能
- 策划一期内容
然后拿出一张纸，画一张图：
11、写下任务名称232、画出节点：4 节点 1：【做什么】用什么模型/工具5 节点 2：【做什么】用什么模型/工具6 节点 3：【做什么】用什么模型/工具783、画出边：9 节点 1 → 节点 210 节点 2 → 节点 311 节点 3 不合格 → 节点 2（最多 N 次）12134、定义状态：14 哪些信息在节点间流动15 每个节点读什么、写什么16175、定义停止条件：18 什么时候整个图结束
你只要能把这张图画出来，就已经入门了。
Graph Engineering 的核心就一句话：
把"我希望 AI 自己搞定"，改成"我告诉一群 AI 怎么分工、怎么交接、怎么收尾"。
从今天开始，不要只设计一个 Loop。
- 想清楚有哪些角色
- 想清楚它们怎么传递信息
- 想清楚谁来做决定
- 再想清楚什么时候停
这就是你从 Loop Engineer，变成 Graph Engineer 的第一步。
关于作者
Punk｜中科大 MBA｜HerName 首席设计师｜Stanley 商学院执行院长｜
｜AI提示词｜3个月赚了8位数｜Learn in Public｜@AdrianPunk115
