月 日OpenClaw 作者 Peter Steinberger 在 X 上问了一句：大家还在聊 Loop，还是已经转向 Graph 了？

两天后Codez 写了一篇很长的教程，给出一条从基础开始学习 Graph Engineering 的 步路线。

我很多人的反应跟我一样：Loop 还没玩明白，怎么又开始画图了？

你是不是还在为 Loop 的细节纠结，却被突然涌来的 Graph 概念搞得晕头转向？

先补一句 Loop 是啥：Loop 是让单个 Agent 反复自我检查、自我修正。直到结果达标为止的机制——写完一遍、检查一遍，不行就重来做到合格为止。下文会反复拿它当对照，

至于图源。Codez 原文

这篇我不按 个名词逐一讲——那 步里出现的 Node、Edge、Schema、Router、Fan‑out/Fan‑in，后面都会用大白话覆盖到。我换成一个普通人能听懂的说法：

Graph Engineering。就是给一群 Agent 分工，规定工作怎么交接、哪里检查、什么时候停。

先把 Agent 想成一个新员工

假设你招了一个新员工，让他每天给你写一份 AI 新闻简报。

最简单的做法，是把所有事都交给他：找新闻、读原文、核对真假、挑主要、写文章、改错字。

这就是大家熟悉的单 Agent。

Prompt 相当于你给他的工作要求。Loop 相当于他写完检查，发现不对再重做，一直做到合格为止。

简单任务做起来没问题。但事情一多，这位员工就开始忙但是来了。说起来，他需要一边翻资料，一边记数字，还要考虑文章结构。能记住的上下文越来越满，前面看过的东西也忘得越来越快。

Graph Engineering 做了一件大家看上去应该都知道如何调整的事儿：别让一个人干这么多事儿了组个团队。

有人找资料。有人核对事实有人写稿，还有人负责挑错。分工明确，最终促成一篇成稿落地。

顺带澄清一个容易混淆的词：图里出现的 Graph Reasoning，和这篇文章讲的 Graph Engineering 不是一回事。Graph Reasoning 偏向模型内部的推理结构，Graph Engineering 偏向工程层面的多 Agent 编排。这篇文章讲的是后者，怎么说呢，

这张图看起来很复杂。其实下面那些小圆点、小方框，大多都可以理解成不同员工和不同工作。

Node 是员工，Edge 是交接单

Graph 里最关键的两个词是 Node 和 Edge。

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

Edge，也就是边缘。它表示工作从谁手里交到谁手里还有交过去什么东西。

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

比如我让 Agent 这份文件，接下来查一下北京天气。天气查询根本不需要等待结束后方可执行，而是两个任务可以同时开始。

很多 Agent 慢就慢在这里。所有工作被写成 A → B → C → D，前一个任务结束不了后一个任务绝不开始。

再举个更直观的例子：B 和 C 都只需要 A 提供的资料，C 并不需要 B 的结果。 那么 A 完成后就可以同时启动 B 和 C，没必要让 C 排在 B 后面干等。

所以Graph Engineering 最基础的能力。是看清任务之间真正的依赖关系：哪些任务需要等待，哪些任务可以同时开工。

任务可以并行以后问题就从谁等谁，变成了结果怎么交给下一个 Agent。

比如资料员 Agent 查完资料，只交回来一大段文字。负责写作的 Agent 既找不到原文链接。也分不清哪些是事实、哪些是结论，只能自己再猜一遍。

Oops. Let's correct that mistake: We'll continue correctly. We need to finish remaining sections accurately and maintain formatting. Let's rewrite from that point onward properly without errors. Continuing after paragraph about exchange format: ...

• A）找新闻；
• B）读原文；
• C）核对真假；
• D）挑主要；
• E）写文章；
• I）改错字。

• PROMPT 相当于你的工作要求；
• SLOOP 相当于他写完检查，不合格则重做直至合格。

为什么要拆团队？

问题： 任务增多→单Agent上下文溢出 记忆力下降→前面信息遗忘 效率瓶颈→持续卡住

方法： Graph Engineering → 多Agent协作 + 明确交接 + 检查点

• •有人找资料；
• •有人核实事实；
• •有人撰稿；
• •有人校对

常见误区澄清

• •“Graph Reasoning” ≠ “Graph Engineering”。前者关注模型内部推理结构；后者关注工程层面的多Agent编排。本篇聚焦后者，

• •Node=岗位/角色
• •Edge=工作流动方法+数据交付

依赖 vs 顺序

• A) “先文件，再查北京天气”。不过，两者**无依赖**——可并行。
• B) “B & C 均依赖 A 提供材料”。A 完成后 **B 与 C 可同步启动**。
• C) 常见错误：“所有任务强制串联 A→B→C→D”，导致资源空闲与低效。

主要能力 —— 看清真实依赖关系

⚡️ 哪些必须等待 哪些可并行启动

交付格式关键性

• *场景* ：资料员返回“一大段文字”，写作Agent不知道原始链接与事实区分。
• *方法* ：制定统一**Schema**，缺项即“不合格”。
• *作用* ：明确 Edge 内容。 使下游 Node 能直接消费，无二次猜测。

小结

• *Node* 决定 *谁* 做什么
• *Edge* 决定 *怎样* 把产出递交
• *Schema* 确保 *质量* 与 *可读性*
• *缺失规则* → 多Agent返工↑ → Token 消耗↑

最常用的图，就是“一颗菱形”

• *步骤概览*
  1. A) 多Agent 并行搜集素材
  2. B) 程序自动去重 & 分类
  3. C) 汇总至主要Agent 输出最终稿
  -> 即 Fan‑out + Fan‑in = 菱形结构

案例演示

• #1 三位独立Agent：
  a) 阅读 X 原文；
  1. b) 查询 Anthropic 官方文档；

#2 程序层面： 去重 → 分类 → 合并

#3 主要环节： Reviewer 验证来源可信度。Router 根据关键度决定走哪条审查方法，最终 DraftWriter 撰稿。

---