我们之前就说过：AI 是出了名的喜欢炒冷饭行业，包括下述词汇：

Prompt Engineering、RAG、Context Engineering、ReAct、Agent、MCP、Skills、Harness…

都可以说是针对于某个概念的再包装、再进化，比如其中的提示词工程到上下文工程再到 Harness，都可以理解为为 AI 提供更适合的执行环境。

所以，无论多高大上的词、多新的概念，都不能保证自己能够活过三个月，于是业内才有了：只要我学得足够慢，那么就什么都不用学了的笑谈。

这次落寞最快的应该是 Agent Loop，因为我上个月还在聊这东西，结果 7 月 18 日，OpenClaw 作者 Peter Steinberger 在 X 上问了一句：大家还在聊 Loop，还是已经转向 Graph 了？

只能说，这些瘪犊子可真会玩！

那么 Graph Engineering 又是个什么东西呢，我们先简单回顾下 Loop，再聊聊什么是 Graph：

Agent Loop

按照我们之前文章的讨论：Loop Engineering 是设计一套外部系统，让 Agent 在无人持续干预的情况下，自动完成【接收任务→执行→检查→决策下一步】的完整闭环：

过去我们用 AI，是人写提示词 → AI 给结果 → 人再写下一轮提示词。

Loop Engineering 要改变的就是这个模式：你丢一个目标进去，剩下的全由系统自动跑起来，它自己发现该干什么，自己调用工具去干，自己检查结果对不对，自己决定下一步是继续、停下来等人、还是把结果发出去。

拿一个实际场景举例：客服在群里反馈了一个 BUG，传统流程是等人看到、等人判断、等人修。

Loop Engineering 的做法是：Agent 自动监听群消息，识别到“报错”、“点击不动”等关键词后自动创建任务，然后自己去查日志、定位代码、评估风险；

低风险的直接改完上线，高风险的改完发给程序员确认，说不清楚的自动转人工，整条链路从触发到执行到验收，全部自动化流转，这就是循环工程。

当时有个博主还提出了一套自己关于 Loop Engineering 的方法论：Automations、Connectors、Worktrees……

我这边当时就对他这个结构不以为然，因为这东西的本质就是一次 AI 原生组织的实践，Loop Engineering 也算不上是什么新技术，他是我们常用的一套把隐性流程显性化为代码的工程方法。

传统团队里什么情况自动处理、什么情况转人工、谁确认、怎么交接这些规则，原本在人的脑子里，靠经验和默契运转；

Loop Engineering 要做的，就是把它们一条条写出来，变成 Agent 能执行的规则，再配上连接、隔离、分工和记忆机制，最终形成一套可持续运行的自动化系统。

综上，Loop Engineering 是关于 AI 原生组织实践的方法论，这东西按理说是不应该被淘汰的，那这里新推出的  Graph Engineering 又是个什么鬼呢？

Graph Engineering

从实际业务运作的角度来说，Loop Engineering 严格来说更多是管理层面的工作；

他关注的是一个 Agent 如何自我驱动、闭环决策。他需要将链条上所有的员工守则和 SOP全部准备好，然后才用工程技术的手法教 Ai 如何做好这个链路上的员工。

而 Graph Engineering 开始回归了，他属于系统架构或者说工程架构层面的事情，他关注的是多个实体（他们的说法是节点 Node）之间的数据流、依赖关系和容错机制，他类似一张流水线设计图，教系统怎么有条不紊、高效率的作业：

接下来，我们来说下这张流水线设计图如何画的问题：Node、Edge。

Graph 里最重要的两个词是 Node（节点） 和 Edge（边）：

节点，就是一个干活的单元。你可以把它理解成一个岗位：资料员、翻译、事实核对员、作者、审稿人。

一个节点可以是一个 Agent，也可以是一段确定性的代码，比如一次函数调用、一次数据读取。关键在于，每个节点只干一件事。

边，就是数据流动的通道。它表示某个节点产生的结果被谁使用。这里的关键是信息流，需要回答清楚：什么东西从 A 流到了 B。

这里有个特别容易踩的坑：做事有先后顺序，不代表它们之间存在依赖关系。

比如你让 Agent 总结这个文件，然后查一下北京天气。

在自然语言层面，这两个步骤是连续的，但天气查询根本不需要等文件总结完，两者之间没有数据流动，也就不存在边。如果你强行写成 A→B，天气查询就得干等一个跟自己无关的任务完成。

执行顺序不等于数据依赖。代码里的先后顺序只代表什么时候执行，图里的边代表谁需要谁的结果。

一个线性的 Agent 流程：A → B → C → D，本质上是一张退化了的图，只有单一路径，它的问题在于：只要有一个节点卡住，后面全得等着。

而 Graph Engineering 最基础的能力，就是看清任务之间真正的依赖关系：哪些必须等，哪些可以同时干：

综上：

• Loop Engineering 解决的是让一个 Agent 反复干到合格为止的问题；
• Graph Engineering 解决的是多个执行单元怎么分工、交接、验证的问题。

这是组织和工程两个层面的问题，不应该是替代关系，所以现在市面上不停鼓吹 Graph 打压 Loop 也不知道他们是在干嘛…

这里再举个例子：

拿写一份 AI 资讯日报来说。最简单的做法是让一个 Agent 从头干到尾：找新闻、读原文、核对真假、挑重点、写文章、改错字。

这就是 Loop 的思路：一个 Agent 包揽所有事，反复打磨直到出稿。

但事情一多，这个 Agent 就开始忙不过来了：一边翻资料一边记数字还要考虑文章结构，上下文越来越满，前面看过的东西忘得越来越快。

Graph 的做法是：别让一个人干这么多事儿了，组个团队。

有人专门找资料，有人专门核对事实，有人专门写稿，还有人专门挑错，分工明确，各司其职：

Graph 的局限性

如前所述，我们自己就在协助几家公司做 AI 原生组织的落地，所以对于 Agent Loop 这套方法论更多的是认可；

但实际在落地过程中是比较困难的，甚至于初期只要能就某几个小场景做闭环都要付出不小的管理成本。

所以，对于 Graph 这里更细化的深入，我个人认为现阶段是没有太大价值的，因为这东西并不是组织实践的方法论，他是工程实践的某种探索，这种被淘汰概率是挺大的。

另一方面，每启动一个 Agent，都要单独消耗 token，至于他有没有效不好使，但整体的复杂度一定是挺高的，所以我暂时的建议是没必要深入这个东西。

比如，画一张 Graph，你得明确定义：

• 节点：具体谁干什么？
• 边：数据格式是什么？
• 路由：什么条件走哪条路？
• 隔离：并行时会不会互相覆盖文件？

这种是将一些隐藏的复杂度直接摆在面上了，有可能会有适得其反的效果。如果非要用这东西，可考虑以下场景：

1. 单个上下文塞不下全部信息；
2. 不同节点需要不同模型、工具或权限；
3. 某个步骤失败后，希望只重跑局部；
4. …

最后说一句，AI 这圈子就是这样，上个月还在聊 Loop，这个月就开始鼓吹 Graph，下个月可能又冒出个什么新词。

但炒归炒，底层的问题从来没变过：怎么让 AI 系统稳定、可控、高效地干活。

Loop 也好，Graph 也罢，本质都是对同一个问题的不同回答，两者不矛盾，也不存在谁替代谁，技术是手段，解决问题才是目的。