本文来自微信公众号： 叶小钗 ，作者：叶小钗
我们之前就说过：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，你得明确定义：
节点：具体谁干什么？
边：数据格式是什么？
路由：什么条件走哪条路？
隔离：并行时会不会互相覆盖文件？
这种是将一些隐藏的复杂度直接摆在面上了，有可能会有适得其反的效果。如果非要用这东西，可考虑以下场景：
单个上下文塞不下全部信息；
不同节点需要不同模型、工具或权限；
某个步骤失败后，希望只重跑局部；
...
最后说一句，AI这圈子就是这样，上个月还在聊Loop，这个月就开始鼓吹Graph，下个月可能又冒出个什么新词。
但炒归炒，底层的问题从来没变过：怎么让AI系统稳定、可控、高效地干活。
Loop也好，Graph也罢，本质都是对同一个问题的不同回答，两者不矛盾，也不存在谁替代谁，技术是手段，解决问题才是目的。