彻底告别Loop Engineering：一文读懂 Graph Engineering

Prompt 是一句指令，Loop 是一个反馈循环，而 Graph 决定整个任务怎样展开

大多数人第一次设计多步骤 Agent，最后都会得到一条很长的流水线：

理解需求 → 搜集资料 → 分析问题 → 生成方案 → 检查结果 → 修改方案 → 输出答案

看起来步骤很多，也很“智能”。

但仔细观察会发现，这些步骤只是一个接一个地排队。前一步没有结束，后一步就不能开始；所有信息都被塞进同一个上下文；同一个 Agent 既负责做事，又负责检查自己做得对不对。

任务简单时，这种方式当然可以工作。

可一旦任务涉及几十个文件、多个信息来源、不同专业视角，或者需要反复验证，线性流程就会迅速变得笨重。

它会越来越慢，越来越贵，也越来越容易在中途丢失重点。

这正是 Graph Engineering 开始受到关注的原因。

Graph Engineering 真正改变的，不是模型本身。

它改变的是工作的形状。

一、从 Prompt、Loop 到 Graph

要理解 Graph Engineering，可以先回顾 AI Agent 工程经历的几次变化。

第一阶段：Prompt

最早，我们关心的是怎样写好一条指令。

请分析这份报告，并给出三个主要结论。

这时，模型接收输入，完成一次思考，然后给出结果。

Prompt Engineering 解决的问题是：

怎样把一件事情说清楚，让模型一次做对？

它非常重要，但它主要面对的是单次调用。

第二阶段：Loop

后来，模型开始使用工具，也开始根据工具结果继续行动。

分析任务 → 调用工具 → 查看结果 → 发现问题 → 调整方案 → 再次执行

这就是 Loop，也就是循环。

例如，一个代码 Agent 可以先修改代码，然后运行测试。如果测试失败，它读取错误信息，再继续修改，直到测试通过。

Loop 让 Agent 不再只是“回答问题”，而是能够持续行动。

但 Loop 仍然有一个明显特征：

整个任务通常由一个 Agent 从头管到尾。

它既要拆解任务，也要调用工具；既要保存中间信息，也要判断下一步做什么；既负责执行，又负责验收。

当任务越来越复杂，一个循环就不够用了。

第三阶段：Graph

Graph Engineering 进一步提出：

不要让一个 Agent 承担全部工作，而要先看清任务本身由哪些部分组成，以及这些部分之间是什么关系。

有些任务必须排队完成。

有些任务可以同时进行。

有些结果需要统一汇总。

有些结果必须经过验证，才能继续向下传递。

有些任务失败后应该重试，有些可以跳过，还有些必须立即停止。

于是，一条线开始变成一张图。

┌→ 信息来源 A ─┐ ├→ 信息来源 B ─┤ 问题拆解 → 并行调查 ┼→ 信息来源 C ─┼→ 汇总 → 验证 → 输出 └→ 信息来源 D ─┘

这就是 Graph Engineering 最直观的样子。

它不是让 Agent “多做几步”，而是重新安排这些步骤之间的关系。

二、Graph Engineering 到底是什么

“Graph”很容易让人联想到数学、图论或者知识图谱。

但在这里，没有必要把它理解得那么复杂。

可以把一项复杂任务想象成一个项目组。

项目组里有人负责查资料，有人负责分析数据，有人负责写作，有人负责检查事实，还有人负责最后拍板。

Graph Engineering 关心的是：

每个人具体负责什么；
谁需要等待谁；
哪些工作可以同时开始；
工作成果怎样交给下一个人；
什么情况下需要返工；
某个人失败后，其他人是否还能继续；
最终结果由谁确认。

在这张图里，每一项具体工作都可以看作一个“节点”。

例如：

搜集资料提取事实判断风险生成方案运行测试检查引用人工审批

节点之间的连接，可以看作“边”。

边表示的不是简单的先后顺序，而是真正的依赖关系。

例如：

事实提取 → 报告写作

报告写作需要读取事实提取的结果，所以这两步之间存在依赖。

但下面两项工作未必需要排队：

调查竞争对手的产品调查用户对产品的评价

如果它们互不依赖，就可以同时进行。

所以，Graph Engineering 的核心问题不是：

第一步是什么，第二步是什么？

而是：

哪些任务真的依赖前面的结果，哪些任务只是被习惯性地排在了后面？

这两种问题看似接近，实际差别很大。

三、很多 Agent 的问题，不是模型不够聪明

假设我们要做一份竞品研究。

最常见的流程是：

先研究竞品 A 再研究竞品 B 再研究竞品 C 然后比较三个产品最后写成报告

这个流程没有错。

但前三项研究彼此独立，完全可以同时进行。

┌→ 研究竞品 A ─┐ 任务拆解 ───────┼→ 研究竞品 B ─┼→ 对比分析 → 写作 └→ 研究竞品 C ─┘

同样的事情也会发生在代码审查中。

一个大型代码变更，可能需要同时检查：

正确性安全性性能兼容性测试覆盖

这些检查不一定需要一个做完再做下一个。

很多线性 Agent 之所以慢，并不是模型思考速度不够快，而是任务结构根本没有被展开。

原文有一个很重要的判断：

很多所谓的多步骤 Agent，只是一张退化成直线的图。

它本来可以分叉，可以并行，可以有不同路径，但最终被写成了一条队伍。

四、为什么单个 Agent 越做越容易失控

线性 Agent 最大的问题，不只是慢。

更麻烦的是，规划、执行、记忆和验证都混在了一起。

可以并行的任务被迫排队

当十个文件都需要检查时，一个 Agent 可能会逐个读取、逐个分析。

这不仅耗时，也容易让后面的文件受到前面内容的干扰。

Graph 的思路是把文件分开处理，再统一汇总。

同一个 Agent 负责检查自己

一个 Agent 提出方案后，再让它判断自己的方案是否合理，很容易得到一个“前后一致”的结果。

但前后一致不等于正确。

模型可能在生成方案时忽略了一个问题，在复查时仍然忽略同一个问题。

这就像让作者自己担任唯一的审稿人。

上下文越来越拥挤

长任务会不断产生中间结果：

搜索内容文件片段工具输出分析笔记失败记录修改历史验证结果

如果这些信息都进入同一个对话上下文，Agent 很快就会面对大量历史内容。

此时，即便模型仍然能够继续工作，也可能忘记最初的要求，忽略早期限制，或者反复处理已经处理过的问题。

一个环节失败，后面全部停住

在线性流程里，中间节点一旦失败，后面的工作往往无法继续。

A 成功 → B 成功 → C 失败 → D 和 E 全部停止

但真实任务中，C 的失败未必意味着 D 和 E 没有价值。

如果不同工作互不依赖，更合理的方式是：

分支 A：成功分支 B：失败分支 C：成功 ↓ 保留成功结果，同时标记缺失部分

Graph Engineering 的一个重要价值，就是把失败限制在局部。

五、把线性 Agent 改造成 Graph，需要做对七件事

原文给出了一条 14 步路线。把它压缩之后，可以归纳为七个最重要的动作。(Tony Bai)

1. 每个节点只负责一件明确的事

一个节点不应该同时承担太多职责。

例如，不要让一个 Agent 同时负责：

查资料判断真假生成观点撰写全文检查引用

更清晰的拆法是：

节点 A：搜集资料节点 B：提取事实节点 C：检查事实节点 D：组织观点节点 E：完成写作节点 F：检查引用

这样做的好处不是节点越多越好，而是每一步都有清楚的边界。

一个好的节点，至少应该说清楚四件事：

它接收什么它要完成什么它输出什么什么情况算完成

如果一个节点的职责无法用一两句话说清楚，它往往还需要继续拆分。

2. 没有依赖的任务，就不要排队

这是 Graph Engineering 中最容易获得收益的一步。

例如，一份行业研究需要同时调查：

市场规模政策变化技术趋势主要玩家用户反馈

这些方向大多可以独立推进。

它们没有必要一个接一个地做。

┌→ 市场研究 ──┐ ├→ 政策研究 ──┤ 研究范围确定 ─────┼→ 技术研究 ──┼→ 统一整理 ├→ 竞争研究 ──┤ └→ 用户研究 ──┘

这种先分开、后汇合的结构，是 Agent Graph 中最常见的形状。

它适用于：

逐文件检查多来源研究多角度评审批量内容处理大规模代码迁移多方案生成

但要注意，并行主要节省的是等待时间。

它不一定更省钱，因为每个分支仍然需要运行，最后还可能增加一次汇总。

3. 只有真正需要时，才等待所有分支

并行之后，通常需要一个汇总节点。

但不是所有工作都必须等待全部结果完成。

例如，十个文件需要分别迁移。

如果每个文件迁移后都可以单独测试，那么一个文件完成后，就可以马上进入测试，不必等待另外九个文件。

文件 A：迁移完成 → 立即测试文件 B：迁移完成 → 立即测试文件 C：仍在迁移

只有当下一步必须看到全部结果时，才需要统一等待。

例如：

比较所有竞品选出最优方案对全部问题进行排序统一删除重复结论

设计 Graph 时，应当不断追问：

这一步真的需要等待所有上游结果吗？

很多不必要的等待，就是这样被发现的。

4. 不同问题，走不同的路径

并不是所有输入都应该进入同一套流程。

例如，代码变更可以先按风险分类：

小型文档修改 → 简单检查普通功能修改 → 常规代码审查认证与支付修改 → 深度安全审查数据库迁移 → 迁移检查 + 回滚检查

这就是路由。

路由节点先判断任务属于哪一类，再由程序决定它进入哪条分支。

┌→ 低风险路径风险分类 ───────┼→ 普通路径 └→ 高风险路径

这种设计比让 Agent 每次临场决定是否跳过某项检查更可靠。

模型可以负责判断“这是不是高风险变更”。

但一旦被判定为高风险，后面必须执行哪些检查，最好由明确规则决定。

这正是 Graph Engineering 中很重要的一条分工原则：

需要理解和判断的事情交给模型，需要稳定执行的事情交给代码。

5. 不要只增加 Agent，要增加验证关卡

很多人设计多 Agent 系统时，第一反应是增加更多角色：

一个负责分析一个负责批评一个负责打分一个负责总结

但 Agent 数量增加，并不代表结果一定更可靠。

多个 Agent 可能使用相同模型、读取相同资料，也可能拥有相似的盲区。

它们一致同意一件事，只能说明结论得到了多次支持，不能证明结论一定是真的。

真正可靠的 Graph，需要在关键位置设置“硬关卡”。

例如：

代码修改 → 编译检查 → 自动测试 → 安全扫描

或者：

研究结论 → 原始来源检查 → 日期检查 → 引用检查

再比如：

付款指令 → 金额检查 → 权限检查 → 人工确认

一个好的验证节点，不是继续夸奖上游结果，而是尽力推翻它。

只有经得起检查的结果，才有资格继续向下游传递。

Anthropic 在 Agent 工作流中也把“生成者—评估者”“并行处理”“条件路由”和“编排者—工作者”视为不同的基础模式。关键不在于套用多少模式，而在于是否存在清晰的评价标准。(Anthropic)

6. 让失败停留在它应该停留的位置

不是所有节点都应该拥有相同的失败处理方式。

有些节点必须成功。

例如：

权限检查关键数据读取支付确认发布前测试

这些节点失败后，整个任务应当停止。

有些节点可以降级。

例如，主要信息源无法访问时，可以使用缓存或备用来源，但要明确标注信息可能不完整。

还有些节点只是附加能力。

例如，额外生成一个标题方案失败了，不应该影响正文交付。

所以，设计一张图时，需要提前说明：

这个节点失败后，是重试、跳过、降级，还是终止？

如果不做区分，系统很容易出现两个问题：

一个无关紧要的失败拖垮整个任务；

或者，一个关键检查失败了，系统仍然若无其事地输出结果。

7. 给循环设置明确的停止条件

Graph 中可以存在循环。

例如：

发现问题 → 修复问题 → 再次检查 → 仍有问题 → 继续修复

问题在于，Agent 很容易陷入“再试一次”。

如果没有停止条件，它可能不断修改、不断检查、不断消耗 token，却没有真正取得进展。

一个可靠的循环至少应该知道：

什么情况代表成功最多运行多少轮多久没有进展就停止预算用到多少必须停止什么时候转交人工

例如：

测试全部通过 → 停止连续两轮没有减少错误 → 停止已经修改五轮 → 停止出现架构级冲突 → 转人工

停止不是失败。

对于无法继续改善的任务，及时停止并说明原因，本身就是系统可靠性的一部分。

六、真正难设计的不是节点，而是节点之间的交接

很多人把主要精力放在节点上：

这个 Agent 应该用什么 Prompt？要不要换更强的模型？需要给它什么角色？

这些问题当然重要。

但决定一张图能不能长期运行的，往往是节点之间怎样传递信息。

假设安全审查节点返回一句话：

这个接口可能存在认证问题，建议进一步检查。

人类大致能看懂。

但下游系统很难知道：

问题在哪个文件？具体是哪几行？风险有多高？依据是什么？是否已经验证？下一步应该做什么？

更好的交接结果应该包含：

文件位置问题描述相关证据风险等级判断信心验证状态建议动作

这就像项目协作中的交接单。

上游不是简单说“我做完了”，而是把下游真正需要的信息准备好。

因此，一条边不只是“把 A 的回答交给 B”。

它更像是一份约定：

A 必须以什么形式交付，B 才可以开始工作。

节点可以更换模型，也可以重新写 Prompt。

只要交接标准保持稳定，整张图就不会因为一个节点的变化而彻底失控。

这也是为什么，成熟的 Graph Engineering 往往更关注数据结构、验证状态和失败信息，而不是追求每个节点都写出漂亮的长篇回答。

七、一张图必须有能够接触现实的节点

Graph Engineering 最容易出现的误区，是把所有问题都交给更多 Agent 解决。

一个 Agent 给出结论。

三个 Agent 检查它。

另一个 Agent 统计投票。

最后一个 Agent 汇总共识。

整张图非常复杂，每个节点也都工作正常。

但如果它们使用相同的错误资料，或者共享同一种盲区，整个系统仍然可能一致地得出错误结论。

因此，一张图不能只在模型内部循环。

它必须在某些位置接触现实。

这些位置可以是：

真实运行的测试编译器结果数据库状态权威原始资料真实用户反馈实际业务数据人工审批

例如，Agent 声称代码已经修复，不算完成。

测试真正通过，才算完成。

Agent 声称某项操作已经执行，也不算完成。

真实系统中确实出现对应结果，才算完成。

Claude Code 的 Hooks 也体现了类似思路：对于必须发生的行为，可以用确定性的命令在特定阶段自动执行，而不是完全依赖模型临时决定是否执行。(Claude Platform Docs)

一个好的 Graph，不是所有节点彼此同意。

而是关键结论必须通过那些无法被语言说服的检查。

八、Claude Code 的 Dynamic Workflows，正是一种 Graph Engineering

Graph Engineering 最近受到关注，一个重要原因是，它不再只是架构图上的概念。

Claude Code 已经提供了相当直接的实现方式：Dynamic Workflows。

简单来说，Claude 可以先根据任务生成一段 JavaScript 编排脚本，再由运行时执行这段脚本，启动多个子 Agent，处理并行、分支、循环和汇总。

这与普通 Subagent 有一个很大的区别。

普通方式下，Claude 通常逐轮决定下一步做什么：

先启动 Agent A 读取 A 的结果再决定是否启动 Agent B 读取 B 的结果再决定下一步

Dynamic Workflow 则是先把计划写进代码：

发现任务 → 并行启动多个 Agent → 收集结果 → 过滤失败项 → 进入验证 → 汇总输出

随后，下一步执行什么，主要由脚本控制。

中间结果保存在脚本变量中，而不是全部进入主对话上下文。生成后的工作流还可以保存下来，作为可重复运行的项目命令。Claude Code 目前也可以通过 ultracode 请求工作流，或在相应努力级别下让 Claude 判断哪些实质性任务值得使用工作流。(Claude)

它与 Graph Engineering 中的概念可以这样对应：

Graph 中的概念Dynamic Workflows 中的实现节点子 Agent并行分支pipeline()数据交接JavaScript 变量条件路由if、过滤和分支循环重复执行与停止条件汇总节点负责去重、排序和整合的 Agent图的执行者Workflow Runtime图的生成者Claude

这也是 Dynamic Workflows 最值得注意的地方：

人不一定要从零手写整张图，Claude 可以根据自然语言先生成一份编排方案。

例如，可以要求它：

对这个 PR 中的每个变更文件分别进行审查，将高风险文件送入额外安全检查，最后合并并删除重复发现。

Claude 可以据此生成一张类似下面的图：

读取变更文件 ↓ 按文件并行审查 ↓ 风险分类 ┌───┴────┐ 普通问题高风险问题 │ ↓ │ 深度验证 └────┬─────┘ ↓ 汇总、去重、排序 ↓ 运行测试 ↓ 输出报告

不过，需要纠正一个容易产生的误解。

代码负责调度，不等于整张图免费。

脚本中的循环、分支和变量处理不需要额外依靠模型思考，但每一个子 Agent 仍然会消耗 token。Claude Code 官方文档也明确提醒，工作流因为会生成多个 Agent，单次运行可能比普通对话使用更多 token，因此适合先从一个目录、少量文件或较窄的问题开始。(Claude)

Dynamic Workflows 是一种 Graph Engineering 工具。

但用了工具，不代表图就一定设计得好。

九、用一份行业研究报告，看懂完整的 Graph

假设任务是：

写一份关于某个新兴行业的深度研究报告。

最简单的方式，是让一个 Agent 从头做到尾：

搜索资料 → 阅读资料 → 整理观点 → 写成报告 → 检查报告

如果采用 Graph Engineering，可以这样设计。

第一步：确定研究范围

第一个节点只负责澄清：

研究对象是什么时间范围是什么面向什么读者需要回答哪些核心问题

它不需要立刻开始写报告。

第二步：拆成独立研究方向

例如：

市场规模政策环境关键技术主要公司商业模式主要风险

这些方向可以同时研究。

┌→ 市场研究 ──┐ ├→ 政策研究 ──┤ 研究范围确定 ──────┼→ 技术研究 ──┼→ 初步资料池 ├→ 公司研究 ──┤ └→ 风险研究 ──┘

第三步：规定统一的交接格式

每个研究节点不能只返回一篇自由发挥的长文。

它们需要提供：

核心发现支持来源信息日期原始证据仍有疑问的地方对结论的信心

这样，后面的节点才能比较和验证。

第四步：设置事实检查

事实检查节点重点检查：

数字是否来自原始来源日期是否过时引用是否真的支持结论不同来源是否互相矛盾预测是否被写成了事实

无法验证的内容，可以保留，但必须明确标记。

第五步：把冲突送入单独路径

假设两个来源对市场规模的估计相差很大。

系统不应该直接选一个看起来更顺眼的数字。

它可以把冲突送入新的分析节点：

检查统计口径检查覆盖地区检查时间范围检查是否包含上下游市场

很多“资料冲突”，并不是谁对谁错，而是统计范围不同。

第六步：按章节写作

验证过的材料可以按章节分配：

行业概况发展驱动力竞争格局商业机会主要风险未来判断

不同章节可以分别起草，再由总编辑节点统一语气、删除重复内容、补上前后衔接。

第七步：最后检查现实锚点

报告完成前，至少应检查：

关键数字能否找到来源重要结论是否区分事实与判断所有引用是否仍然有效结论是否超出了证据范围是否遗漏明显的反方证据

对于投资、法律、医疗等高影响主题，最后还需要相应专业人员审阅。

这样得到的，不只是“一篇由多个 Agent 写成的报告”。

它是一套能够解释结论从哪里来、经过了哪些检查、哪些部分仍然存在不确定性的研究流程。

这才是 Graph Engineering 的价值。

十、什么时候值得使用 Graph

并不是所有任务都需要一张复杂的图。

当任务出现以下特征时，Graph 通常值得考虑：

存在多个可以独立处理的子任务需要从许多文件或来源中搜集信息不同输入需要进入不同处理路径关键结论需要多层验证某个分支失败后，其他分支仍应继续任务规模在开始时无法确定同一套流程需要重复运行需要观察成本、耗时和失败位置

例如：

大型代码审查批量文件迁移深度研究报告多来源事实核查周期性市场监测复杂数据分析大规模内容审核

这些任务天然具有分支、汇合、验证和循环。

十一、什么时候不应该使用 Graph

如果一件事情用一次模型调用就能稳定完成，没有必要把它设计成一个系统。

例如：

简单改写短文本摘要固定格式提取普通分类单一问题回答

如果任务只有两三个步骤，而且后一步确实需要完整读取前一步结果，线性流程通常更简单。

另外，如果你连“什么叫做成功”都没有定义清楚，那么增加更多评审 Agent 也不会自动解决问题。

它们只会产生更多意见。

Graph 本身也有成本：

需要设计节点需要维护交接格式需要处理失败需要记录状态需要控制并发需要管理模型成本需要调试整条路径

所以，Graph Engineering 不是“能画多复杂，就画多复杂”。

真正成熟的做法是：

用最简单的结构，解决当前真实存在的问题。

十二、怎样开始设计第一张 Agent Graph

不需要先学习复杂框架。

拿到一个任务后，先回答五个问题。

第一，最终要得到什么？

不要只写“完成研究”或者“检查代码”。

要说清楚最终结果：

一份带来源的研究报告一组通过测试的代码修改一份按风险排序的问题清单一批已经验证过的数据记录

第二，哪些工作可以独立进行？

把真正没有依赖的部分找出来。

它们通常适合并行。

第三，每一步要交给下一步什么？

不要只传递一段自由文本。

至少说清楚：

结论证据状态风险未解决问题

第四，哪些地方必须设置硬检查？

问自己：

这项结论怎样才能被真正证明？

可能的答案是测试、数据、原始来源，也可能是人工批准。

第五，失败和停止怎么处理？

提前决定：

失败后重试几次是否可以跳过是否允许返回部分结果什么情况必须终止什么时候需要人工介入

回答完这五个问题，一张基础的 Agent Graph 就已经出现了。

结语

Prompt Engineering 关注的是：

怎样让模型更好地完成一次任务？

Loop Engineering 关注的是：

怎样让模型根据反馈持续行动？

Graph Engineering 进一步关注的是：

当任务需要多个模型、多个工具和多轮检查共同完成时，怎样安排它们之间的分工、协作和制约？

它把设计重点从一个 Agent 的“思考过程”，转移到了整个系统的“工作结构”。

以后再面对复杂 Agent 任务，我们需要问的可能不再只是：

Prompt 应该怎么写？ Agent 还要再做几轮？

而是：

哪里应该拆开？哪里可以并行？哪里必须汇总？哪里需要验证？哪个失败可以忽略？哪个失败必须阻断？什么时候应该停止？

会提问的人，可以让 AI 完成一项工作。

会画图的人，开始决定整套工作怎样运行。

而一个真正成熟的 Agent 系统，并不是保证每个节点永远不犯错。

它真正要做到的是：

即使某个节点犯了错，错误也不会轻易穿过整张图。