一、引言：从Loop到Graph
2026年7月，OpenClaw创始人在X上抛出一个问题：
“我们还在聊loop，还是已经切到graph了？”
没过多久，有人跟帖喊出：“Loop Engineering已死，Graph Engineering永生”。
这句话有些夸张，但指向了一个真实趋势：当任务复杂到需要多个Agent协作、多条路径并行、失败后自动切换路线时，单个Loop就不够用了。
Graph Engineering就是把多个Loop组织成一张有向图。
二、从Prompt到Graph的演进
2.1 单次Prompt（2022-2024）
`
用户 → Prompt → AI → 结果
`
一次交互，人类全程参与。
2.2 Loop Engineering（2025-2026初）
`
输入 → [评估 → 改进 → 评估 → …] → 输出
`
Agent自我迭代，人类只设计循环规则。
2.3 Graph Engineering（2026-）
`
输入 → [A,B,C并行] → [D合并] → [E,F条件路由] → 输出
`
多个Loop组成一张图，节点是工作单元，边是数据依赖。
| 阶段 | 核心思想 | 人类角色 |
|---|
|——|———-|———-|
| Prompt | 怎么说清楚 | 提示词工程师 |
|---|---|---|
| Loop | 怎么做对一件事 | 循环设计师 |
| Graph | 怎么让多个Loop协作 | 图架构师 |
三、Graph vs Loop vs Chain
`
Chain: A → B → C → D （线性，最简单）
Loop: A → B → C → A → B → C （循环，自我改进）
Graph: A → [B,C,D] → E （分支+汇合，并行协作）
↘ F ↗（条件路由）
`
关键区别：
| 维度 | Chain | Loop | Graph |
|---|
|——|——-|——|——-|
| 执行路径 | 固定 | 固定+循环 | 动态路由 |
|---|---|---|---|
| 并行能力 | ❌ | ❌ | ✅ |
| 失败处理 | 停止 | 重试 | 路由到备用节点 |
| 适用场景 | 简单流程 | 单任务迭代 | 多角色协作 |
四、什么时候需要Graph？
四个判断条件
条件一：任务能拆成不同角色吗？
拆不出清晰的”谁负责什么”，那就还是一个Loop。加节点只是加成本。
条件二：有真正能并行的子任务吗？
没有独立并行的活，图比循环贵，却不比循环快。
条件三：单个Agent的上下文装得下全部背景吗？
装得下就别急着拆。拆分是为了腾出上下文，不是为了好看。
条件四：失败之后，负担得起跳转分支的成本吗？
没想清楚重试耗尽后去哪，图会在你看不见的地方卡死或乱跑。
全部满足 → 建图。任一不满足 → 继续用Loop。
五、Graph Engineering的核心价值
5.1 并行加速
9个信源同时搜索，而不是串行等待。时间从9T降到T。
5.2 上下文隔离
每个Agent只处理自己那部分，不会把整个会话淹没。
5.3 失败隔离
一个节点失败，不影响其他节点。.filter(Boolean)就是防线。
5.4 模型分层
重复性工作用便宜模型，判断力工作用强模型。省token。
5.5 动态路由
运行时根据结果决定走哪条路，而不是提前写死。
六、真实案例
案例1：知识库文件处理
`
文件监听 → [扇出] Magika识别 + 去重检测
↓
[并行] 内容提取 / 实体识别 / 关系构建
↓
[汇入] 去重 + 合并
↓
[存储] SQLite + 向量索引
`
案例2：深度研究
`
定范围 → [并行搜索] 9个信源 → [抓取] → [对抗验证] → [合成报告]
`
案例3：代码审查
`
代码变更 → [分类] → 高风险: [并行审计] → 合并
→ 低风险: 快速评审
`
七、总结
`
Loop Engineering: 一个Agent怎么反复做对一件事
Graph Engineering: 多个Loop怎么组织成一张能自己路由的图
`
Graph不是Loop的升级版，是Loop的组织方式。
它烧的token比单个Loop更多，协调开销也更高。但当你需要并行、需要角色分工、需要失败路由时，它是唯一的选择。
下一章预告：Graph的四个核心构件——Nodes、Edges、Shared State、Failure Routing。
发表回复