大家好，我是程序员天天困。
上个月我才刚写完一篇 Loop Engineering 实战，讲怎么用 /goal 让 AI 自己循环干活。结果这个月一打开 X，好家伙，AI 圈又在喊"Loop Engineering 已死，Graph Engineering 永生"。
我第一反应是：我文章刚发一个月不到，你就给我判死刑？
更离谱的是，这次带头造词的还是同一个人——OpenClaw 创始人 Peter Steinberger。上个月他喊 Loop，这个月他在 X 上发问：我们还在讨论循环结构的问题吗？还是已经转向了图论领域了呢？
评论区马上就炸出那句经典台词"Loop Engineering 已死，Graph Engineering 永生"。前后不到一个月，造词速度比我写稿还快。
说实话，看到 Graph 这个词的时候，我脑子里蹦出来的不是什么 AI 新范式，而是一句话——这玩意儿，我好像在哪里见过。
一、"已死"是 AI 圈的标准开场白，先别急着焦虑
先给结论：Graph Engineering 不是什么颠覆性新发明，它是把"用图来编排多个执行单元"这套老思路，套到了 AI Agent 协作上。Loop 也没死，它只是被收编成了图里的一个节点。
Graph Engineering（图工程）：一种用"节点 + 边 + 状态"来编排多个 AI Agent 协作的方法论。节点负责干活，边决定下一步走哪个节点，状态记录整个流程的进度和产物。你可以把它理解为"给一群 Agent 装上调度中心"。
Loop Engineering（循环工程）：上个月刚火的那个，让单个 Agent 在一个"执行 → 验证 → 反馈 → 决策"的闭环里自己跑，直到达成目标。我上篇文章讲的 /goal 就是这个路子。
我为什么说"见过"？因为如果你是做后端的，这套东西你八成早就玩过了。
二、作为后端，我为什么说"这玩意儿我见过"
Graph Engineering 干的事，本质就是后端老炮儿用了十来年的工作流编排，只不过执行单元从"一段代码 / 一个服务"换成了"一个 Agent"。
我列几个你大概率熟悉的例子：
- 工作流引擎：Activiti、Flowable、Camunda，画的那张 BPMN 流程图，就是 graph——节点是审批环节或服务调用，边是流转条件，状态是流程实例的上下文。一套审批流跑下来，串行、并行、会签、回退，全在图里。
- DAG 任务调度：Airflow、DolphinScheduler，你定义任务依赖，A 跑完才能跑 B，B 和 C 可以并行，这就是典型的有向无环图。Fan-out（一个任务分出多个并行子任务）和 Fan-in（多个子任务汇合）这两个词，调度系统里用了不知道多少年。
- 微服务编排：Saga 长事务、状态机（Spring StateMachine）、甚至 Kubernetes 里编排 Pod 的 Operator，思路都是一样的——把复杂流程拆成节点，用边控制走向。
所以当 LangChain 官方跳出来发了一篇《3 Years of Graph Engineering with LangGraph》，说"这东西我们三年前就在做了"——我一点都不意外。三年前他们做的，本质上就是把工作流编排那套，搬到了 LLM 调用上。
LangChain 官方这篇《3 Years of Graph Engineering with LangGraph》值得一看，标题就点明了"用图来建模 Agent"这条路他们走了三年。
LangGraph：LangChain 开源的 Agent 编排框架，用节点、边、状态三件套把多个 LLM 调用串成一张可执行的图。它是目前落地 Graph Engineering 最成熟的实现之一，但不是唯一选择。
三、Loop 真的死了吗？它只是换了个位置
Loop 没死，它从"整个系统"缩小成了"图里的一个节点内部"。
这是我觉得整个讨论里最容易被带偏的地方。"已死"这种话听听就得了。实际上两者的分工很清楚：
| 维度 | Loop Engineering | Graph Engineering |
|---|---|---|
| 管辖范围 | 单个 Agent 内部 | 多个执行单元之间 |
| 解决问题 | 怎么让一个 Agent 反复思考、自检、修正 | 怎么拆任务、谁先做谁后做、怎么并行汇合 |
| 典型形态 | /goal 跑到目标达成为止 |
后端+前端+测试三路并行，跑完合并验收 |
| 类比 | 一个工位上的老师傅自己琢磨 | 整条流水线的调度员 |
你完全可以把一个 Loop 看作 Graph 的极简版本--就一个节点，边往自己身上拐。反过来，Graph 里那些 agent 节点内部，跑的还是同一个思考循环那一套。
上个月我写 Loop 的时候说，它是"给 AI 装自动驾驶"。现在 Graph 干的事，是给一队装了自动驾驶的 AI 配一个调度中心。一个是单兵，一个是编队，不是替代关系。
四、那为什么还要搞 Graph？Loop 单干不行吗
单个 Agent 在一段长对话里从头跑到尾，任务一放大就会撞上四个墙——慢、易断、难暂停、表达不了分工。
这跟 Loop 的坑不一样。Loop 的坑是"一个 Agent 自己跑飞了怎么办"，Graph 要补的是"一群 Agent 怎么不打架"。
我自己踩过这个场景：上个月用 /goal 让一个 Agent 从零搭项目，它一个人把后端接口、前端页面、测试用例全包了。问题是——这三块本来可以并行，它非要串着干，后端写完才写前端，前端写完才补测试。十一分钟是跑通了，但要是项目再大点，光排队就够喝一壶。
更关键的是，之前我刷推看到有个开发者在 X 上点出了 Loop 的硬伤：一个 Agent 干活，又自己给自己打分，没人挑错。Graph 的解法是加一个独立的审查节点——干活的归干活，验收的归验收，职责切开。
可能有人会问：那我是不是该赶紧把 Loop 扔了，全切 Graph？
别。你手上大部分任务，一个 Loop 串到底就够了。写个脚本、修个 bug、做个小调研，强行上 Graph 编排，等于一个人一下午能干完的活儿，你非要开个项目启动会。Graph 是给"任务能拆、需要并行、中间要人工卡点、跑断了要能续"这些场景准备的。
五、什么场景才值得上 Graph（Java 后端视角）
只有当任务满足"可拆分 + 有依赖关系 + 需要并行或人工卡点"这三条里的至少两条，才值得动用 Graph 编排，否则就是过度设计。
给你一个我自己的判断清单：
| 场景特征 | 用 Loop | 用 Graph |
|---|---|---|
| 任务线性、步骤明确 | ✓ | 过度设计 |
| 能拆成互相独立的子任务，要压总耗时 | ✗ | ✓ |
| 不同环节要不同模型/工具/权限 | ✗ | ✓（干活节点可写、审查节点只读） |
| 中间必须人工审批才能继续 | 勉强 | ✓ |
| 跑断了要能从断点续跑、单独返工某一路 | 难 | ✓（靠状态存档） |
举个后端会更熟悉的例子。你要做一个实时风控规则引擎：后端写规则执行接口，前端做规则配置页，测试补命中用例。只要先约定好同一份规则契约，三块就能并行。串行跑就是后端→前端→测试排队；用 Graph 编排，就是规划节点拆任务 → 三个开发节点并行 → 汇合跑全量测试 → 失败的那一路单独返工 → 通过后人工确认合入。
这不就是工作流引擎里"并行网关 + 回退"的标准玩法吗？一点新东西都没有。
六、怎么落地：不用 LangGraph 也行
Graph Engineering 是设计方法，不是某个框架的专利，你手里有什么工具就能用什么工具落地。
LangGraph 是目前最熟的实现，但不是唯一选择。AutoGen、Google ADK，甚至 Claude Code 的 subagent + workflow 都能干。你要是后端老炮儿，甚至可以拿工作流引擎的思路自己撸一段调度代码——只要你在按"节点、边、状态"组织多个执行单元，本质上就是在做 Graph Engineering。
我自己更关心的其实是 Claude Code 这条路。它内置的 subagent 可以充当节点，hook 能在特定时机强制跑检查，workflow 能拆任务派 agent。你不用学 LangGraph 的 API，一句话把目标讲清楚就行，比如：
用 workflow 帮我把这堆历史接口补单测，按模块拆成五路并行写测试，写完合并跑覆盖率，到 80% 叫我确认。
它接到后会自己拆任务、约定接口契约、派多路 subagent 并行，跑完叫你验收。这不就是 Graph 编排该干的事吗——只不过调度脚本是它帮你写的。
七、最后
聊聊我的判断：Graph Engineering 这个名字是新的，但它背后那套"节点 + 边 + 状态 + 并行 + 回退"的编排思想，后端圈用了十来年，LangGraph 也实践了三年。AI 圈这次不过是把执行单元从代码换成了 Agent，重新讨论了一遍。以这波热度看，名字可能再过俩月又变，但编排思想不会消失。
Loop 也没死，它从主角降级成了图里的一个节点——单兵变编队的一员而已。真正值得关注的不是造词，而是它指向的那个真问题：Agent 能干的活越来越复杂，单打独斗的 Loop 已经不够用了，怎么让一群 Agent 稳定协作，才是接下来要啃的硬骨头。
按 AI 圈这个造词速度，我估计再过一两个月，又会冒出一个更唬人的新词。到时候我再来追（真的快追不动了……）。
我是程序员天天困，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你团队的多 Agent 协作，现在是用 Loop 单干，还是已经上 Graph 编排了？
