Loop Engineering 与 Graph Engineering 的关系：单任务循环如何进入多节点协作图

Loop 没有过时，而是变成 Graph 里的局部结构，用图组织多 Agent、工具和人工协作。

导语

AI Agent 工程有一个很明显的变化：讨论重心正在离模型越来越远。

一开始大家研究 prompt，后来研究 context，再后来研究 harness 和 tool use。等 Agent 能自己反复执行、验证、修正以后，Loop Engineering 成了新的工作单位。再往后，一个更大的问题出现了：单个循环能跑，但复杂工作不是一个循环能扛住的。

这就是 Graph Engineering 变热的原因。

它不是宣告 Loop 过时，也不是给 AI 工程换一个时髦名字。更准确地说，Loop 变成了 Graph 里的局部结构。一个节点内部可以是循环，多个节点之间需要图来组织。

图：单个执行循环变成多节点协作图中的局部结构
Loop 解决“单个 Agent 怎样持续工作”，Graph 解决“多个 Agent、工具和人类怎样协作成系统”。

Loop 是 Agent 的 Hello World

很多 Agent 系统的雏形，最后都会变成一个循环。

模型读取目标，生成计划，调用工具，观察结果，判断是否继续。如果没有达成目标，就再跑一轮。这个结构足够简单，也足够有效。修一个 bug、整理一份资料、清洗一批数据、补一个测试，通常都可以靠一个循环完成。

图：Loop 是 Agent 最小执行闭环

Loop Engineering 的进步在于，它把“变好”这件事变成可编程对象。

用户不再亲自一轮轮提示模型，而是设计一个会重试、会验证、会保存状态、会判断停止条件的系统。好的循环通常有几件事：

· 目标明确，不达成就继续。
· 状态外置，不把所有历史都塞进上下文。
· 每一轮都重新装配必要上下文，避免脏记忆滚雪球。
· 允许计划演化，但必须有停止条件。
· 验证器能告诉系统结果是否真的变好。

这就是为什么循环会流行。它便宜、直观、能快速搭出效果。对范围清楚的单目标任务，循环已经够用。

单循环为什么会翻车

问题出在任务变复杂的时候。

如果让一个 Agent 在同一个循环里既研究、又写作、又审稿、又发布，它会逐渐失去边界。研究材料混进结论，审稿意见和写作上下文互相污染，早期决策被后面的长上下文冲掉。最后看起来完整，实际一碰就碎。

这不是模型不会做单个任务，而是架构让一个 Agent 同时扮演了太多角色。

单循环常见的结构性问题有四类：

翻车模式	本质	表现
指标被玩坏	系统只优化可测指标，忘了指标背后的目标	工单解决率变高，用户问题却被快速关闭
向上失明	循环能逼近目标，却不会质疑目标是否正确	目标设错后，循环越努力越偏
循环冲突	多个局部循环各自优化，彼此看不见	一个追求速度，一个追求质量，结果互相抵消
测量衰减	验证信号失真后，循环仍继续运行	仪表盘是绿的，但指标已经不代表真实效果

循环最大的优点是容错：没想清楚也能先跑起来。

这同时也是它的缺点。很多结构性决策被延期了。谁负责研究，谁负责判断，哪些结果要复核，失败后退回哪里，状态怎么合并，都被塞进一个大循环里。

Graph Engineering 的价值，就是把这些被延期的决策提前显式化。

Graph 是组织方式

Graph Engineering 做的事情并不神秘：把一个“什么都干”的大循环，拆成多个专门化节点，再定义它们如何交接。

一家公司不会让同一个人同时做研究、写稿、审稿、法务和发布。它会设置角色、流程、交接和记录。Agent 图也是这个思路：专门化的角色、明确的边、共享的状态。

一张 Agent 图只有三个核心元素。

元素	含义	设计重点
节点	做事的单元，可以是 Agent、工具调用、判断器或人工确认点	每个节点只干一件事，有清晰输入输出
边	节点之间的路由和依赖关系	只有后一步消费前一步输出，边才成立
共享状态	沿边流动或被节点读写的对象	区分全局状态、节点私有状态和并行结果合并方式

一个最基础的研究写作图可以这样表示：

图：研究写作任务中的基础 Agent 图

这张图里，Loop 没有消失。写作节点内部可以有自己的草稿循环，审稿节点内部也可以反复检查。Graph 只是把多个循环之间的协作关系显式写出来。

五种基本图形

大多数 Agent 图，都是由几种基础模式组合出来的。

模式	适合什么	风险
顺序链	提取、转换、格式化等步骤固定的任务	前一步错了，后面会在错误上继续构建
路由分发	输入类型不同，需要送到不同专家节点	路由本身如果不稳定，会把任务送错地方
扇出 / 扇入	多个独立子任务可以并行处理	合并节点容易被低估，不能只是拼接字符串
钻石拓扑	先拆任务，再并行处理，最后归纳综合	拆分粒度和合并标准必须清楚
收敛循环	需要持续发现直到没有新增	必须有去重、预算和停止条件

钻石拓扑是很多严肃 Agent 系统的主力形状：

图：Graph 中常见的五种组织结构

它的好处不是“Agent 更多”，而是结构更清楚。每个子任务可以并行，归约节点负责去重和冲突处理，综合节点负责形成最终判断，验证节点负责拦截错误。

真正的杠杆在验证器上。

图允许你在关键边上放验证节点：正确性检查、安全检查、复现检查、成本检查、人工审批。单循环里这些判断容易被模型一笔带过；图会迫使你把它们建模成真实节点。

Prompt、Loop、Graph 的位置

AI 工程的抽象层在不断上移，但它们不是互相淘汰的关系。

层级	工程化对象	核心问题	你的角色
Prompt	单次请求	我问得是否清楚	操作者
Context	模型看到的信息	它是否拿到正确材料	编辑者
Harness	工具、记忆、权限、执行环境	它能否对外部世界采取行动	工具构建者
Loop	单个 Agent 的迭代周期	它何时继续，何时停止	系统设计者
Graph	多个节点之间的协调	谁做什么，按什么关系交接	组织设计者

这五层是累积的。

一个图里有很多节点，好的节点通常是一个设计良好的循环；好的循环离不开稳定的 harness；好的 harness 仍然需要准确的 context 和 prompt。跳过低层，直接画图，只会得到一个更复杂的失败系统。

如果节点本身很弱，把它们编进组织架构图，不会自动变强。弱节点组成的组织，还是弱组织。

Graph 为什么有价值

Graph Engineering 的价值，主要体现在五个方面。

第一，并行。独立节点可以同时跑，总耗时取决于最慢链路，而不是所有步骤相加。

第二，关注点分离。每个节点只带自己需要的上下文，减少角色混淆和上下文污染。

第三，可控。边是路由逻辑，可以用确定性代码表达；模型负责判断和生成，流程控制不必完全交给模型即兴发挥。

第四，可观测、可恢复。图天然记录节点、状态变化和跳转路径。配合检查点，可以暂停、恢复、回滚和人工确认。

第五，降本。不是每个节点都要用最贵模型。路由、格式转换、简单分类可以用小模型或确定性程序，关键判断再使用更强模型。

可以把这些能力汇成一张表：

能力	Loop 更擅长	Graph 更擅长
简单单目标任务	是	可能过重
多角色协作	容易混乱	清晰建模
并行处理	不自然	天然适配
审计追踪	依赖日志设计	节点和边天然可追踪
错误隔离	容易污染整个循环	可限定在局部节点
人工审批	能做但不够显式	可作为独立节点

什么时候该上图

图不是银弹。它会带来额外的 token、延迟和维护成本。

一个任务如果一次模型调用就能解决，就不要上图。一个 Agent 在统一上下文里能稳定完成的任务，用 Loop 就够了。强顺序依赖、无法并行的流程，也不一定适合多 Agent 图。

更适合上图的信号是：

· 任务天然有多个角色，例如研究、执行、审查、发布。
· 流程存在明确依赖，也存在部分可并行步骤。
· 需要人工确认、暂停恢复、断点续跑或审计轨迹。
· 单个 Agent 上下文越来越长，后面开始忘掉前面。
· 你需要在模型判断和确定性程序之间做清晰分工。
· 错误必须被隔离，不能让一个坏节点污染整条任务链。

一句话判断：先默认使用最简单的形状。只有当图能提高成功率、降低错误传播，并且额外成本值得时，再升级到 Graph。

复杂度必须用证据来换。

结语

Loop 没有死。

它只是从“整个系统的形状”，变成了“图里某个节点的内部机制”。当任务只有一个目标、一个角色、一个清晰停止条件时，Loop 仍然是最便宜、最有效的结构。

Graph 的出现，是因为复杂工作需要组织。

它迫使你回答以前被大循环掩盖的问题：谁负责什么，哪些结果要交接，哪些状态要共享，哪些边上要验证，失败后退回哪里，人工判断在哪个节点介入。

Prompt 让请求可编程，Loop 让行为可编程，Graph 让组织可编程。

AI Agent 工程的杠杆确实在上移，但每一层都依赖下面那层。真正成熟的系统，不是盲目追新词，而是知道什么时候一个循环够用，什么时候必须把多个循环组织成图。

AI小老六