大家好，我是程序员天天困。

上个月我才刚写完一篇 [Loop Engineering 实战](https://mp.weixin.qq.com/s/DT_z1yQ5DHVPGOiXvbqr9g)，讲怎么用 `/goal` 让 AI 自己循环干活。结果这个月一打开 X，好家伙，AI 圈又在喊"Loop Engineering 已死，Graph Engineering 永生"。

我第一反应是：我文章刚发一个月不到，你就给我判死刑？

![表情:问号1](https://developer.qcloudimg.com/http-save/yehe-11608098/1fe12c9417704840dadac22e53fa340e.webp)

更离谱的是，这次带头造词的还是同一个人——OpenClaw 创始人 Peter Steinberger。上个月他喊 Loop，这个月他在 X 上发问：我们还在讨论循环结构的问题吗？还是已经转向了图论领域了呢？

![](https://developer.qcloudimg.com/http-save/yehe-11608098/b8fecba0d593c09219c18bc7354e7313.png)

评论区马上就炸出那句经典台词"Loop Engineering 已死，Graph Engineering 永生"。前后不到一个月，造词速度比我写稿还快。

![](https://developer.qcloudimg.com/http-save/yehe-11608098/e6a5fbfa13c1828296bef26efa362bff.png)

说实话，看到 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"这条路他们走了三年。

![LangChain 官方博客，回应 graph engineering 热度](https://developer.qcloudimg.com/http-save/yehe-11608098/2edad3068f0731b4b1fcdf5a91eeda1b.png)

![](https://developer.qcloudimg.com/http-save/yehe-11608098/3474a5d03c84e1585e3a30448927fbe5.png)

**LangGraph**：LangChain 开源的 Agent 编排框架，用节点、边、状态三件套把多个 LLM 调用串成一张可执行的图。它是目前落地 Graph Engineering 最成熟的实现之一，但不是唯一选择。

## 三、Loop 真的死了吗？它只是换了个位置

Loop 没死，它从"整个系统"缩小成了"图里的一个节点内部"。

这是我觉得整个讨论里最容易被带偏的地方。"已死"这种话听听就得了。实际上两者的分工很清楚：

| 维度     | Loop Engineering                      | Graph Engineering                      |
| -------- | ------------------------------------- | -------------------------------------- |
| 管辖范围 | 单个 Agent 内部                       | 多个执行单元之间                       |
| 解决问题 | 怎么让一个 Agent 反复思考、自检、修正 | 怎么拆任务、谁先做谁后做、怎么并行汇合 |
| 典型形态 | `/goal` 跑到目标达成为止              | 后端+前端+测试三路并行，跑完合并验收   |
| 类比     | 一个工位上的老师傅自己琢磨            | 整条流水线的调度员                     |

你完全可以把一个 Loop 看作 Graph 的极简版本--就一个节点，边往自己身上拐。反过来，Graph 里那些 agent 节点内部，跑的还是同一个思考循环那一套。

上个月我写 Loop 的时候说，它是"给 AI 装自动驾驶"。现在 Graph 干的事，是给一队装了自动驾驶的 AI 配一个调度中心。一个是单兵，一个是编队，不是替代关系。

![](https://developer.qcloudimg.com/http-save/yehe-11608098/c81963615d60fe01e1353201b1dc3b57.png)

## 四、那为什么还要搞 Graph？Loop 单干不行吗

单个 Agent 在一段长对话里从头跑到尾，任务一放大就会撞上四个墙——慢、易断、难暂停、表达不了分工。

这跟 Loop 的坑不一样。Loop 的坑是"一个 Agent 自己跑飞了怎么办"，Graph 要补的是"一群 Agent 怎么不打架"。

我自己踩过这个场景：上个月用 `/goal` 让一个 Agent 从零搭项目，它一个人把后端接口、前端页面、测试用例全包了。问题是——这三块本来可以并行，它非要串着干，后端写完才写前端，前端写完才补测试。十一分钟是跑通了，但要是项目再大点，光排队就够喝一壶。

更关键的是，之前我刷推看到有个开发者在 X 上点出了 Loop 的硬伤：一个 Agent 干活，又自己给自己打分，没人挑错。Graph 的解法是加一个独立的审查节点——干活的归干活，验收的归验收，职责切开。

![](https://developer.qcloudimg.com/http-save/yehe-11608098/cb7c68c35ad82c9f9a89d2117910b0e4.png)

> **可能有人会问：那我是不是该赶紧把 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 圈这个造词速度，我估计再过一两个月，又会冒出一个更唬人的新词。到时候我再来追（真的快追不动了……）。

![](https://developer.qcloudimg.com/http-save/yehe-11608098/c673cb06f168c44f3a5ce919c622cd36.png)

---

我是程序员天天困，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你团队的多 Agent 协作，现在是用 Loop 单干，还是已经上 Graph 编排了？

上个月我才刚写完一篇 Loop Engineering 实战，讲怎么用 /goal 让 AI 自己循环干活。结果这个月一打开 X，好家伙，AI 圈又在喊"Loop Engineering 已死，Graph Engineering 永生"。

Loop Engineering 已死？Graph Engineering 是什么？我好像在哪里见过

Graph Engineering 刷屏，后端第一反应是这不工作流引擎吗？本文聊它到底是什么、Loop 真死了吗、什么场景才值得上

编程语言

人工智能

后端

"GraphEngineering并非AI新范式，而是将传统工作流编排应用于AIAgent协作。LoopEngineering并未消亡，而是成为Graph中的节点。Graph适合多Agent并行任务，Loop适合线性任务。后端开发者熟悉的BPMN、Airflow等工具早已实现类似功能。AI圈新词频出，但核心是解决多Agent协作问题。"

自动驾驶

Kubernetes

OpenClaw

Agent

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

"GraphEngineering并非AI新范式，而是将传统工作流编排应用于AIAgent协作。LoopEngineering并未消亡，而是成为Graph中的节点。Graph适合多Agent并行任务，Loop适合线性任务。后端开发者熟悉的BPMN、Airflow等工具早已实现类似功能。AI圈新词频出，但核心是解决多Ag...

Loop Engineering 已死？Graph Engineering 是什么？我好像在哪里见过-腾讯云开发者社区-腾讯云

Loop Engineering 已死？Graph Engineering 是什么？我好像在哪里见过

Loop Engineering 已死？Graph Engineering 是什么？我好像在哪里见过

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐