引言：AI 能持续工作之后，下一个问题是什么

早期使用大模型时，人们最关心的是“提示词怎么写”。后来，模型能够读取资料、调用工具、修改代码和运行测试，工程重点逐渐变成“怎样让一个智能体独立完成任务”。

于是，Agent Loop 成为常见工作方式：智能体观察环境、制定计划、执行动作、检查结果，然后不断重复，直到达到目标。

但真实任务往往不只需要一个执行者。

例如，一份高质量的行业研究报告可能同时需要：

• 从不同来源搜集资料。
• 判断来源是否可靠。
• 提取事实并消除重复信息。
• 根据目标读者组织文章。
• 独立核查关键结论。
• 在发布前经过人工审批。

如果把所有工作都交给同一个智能体，并塞进一个不断增长的循环，系统很快会遇到上下文混乱、串行效率低、自我审查失效、故障难以恢复等问题。

Graph Engineering 关注的正是下一层问题：如何把多个智能体、普通程序、外部工具和人组织成一个可执行、可检查、可恢复的协作系统。

它不是简单地“多开几个 Agent”，也不是给旧流程换一个新名字。它真正带来的变化，是把 AI 工程从“设计一个执行者的行为”提升到“设计一组执行者之间的关系”。

一、先用一句话理解 Loop 与 Graph

1. Loop：让一个智能体持续工作

Loop 可以概括为一个闭环：

观察 -> 思考与规划 -> 执行 -> 验证 -> 决定是否继续

它解决的核心问题是：怎样让一个智能体不必等待人类逐步下指令，也能围绕目标连续行动。

例如，让一个代码智能体修复 Bug：

1. 阅读错误日志。
2. 搜索相关代码。
3. 推断问题原因。
4. 修改代码。
5. 运行测试。
6. 如果测试失败，分析结果并继续修改。
7. 如果测试通过，输出变更说明。

这个过程可以表示为：

Loop 的价值是把人从“每一步的操作者”变成“目标和验收标准的制定者”。

2. Graph：让多个节点有序协作

Graph 不再只关心一个智能体内部如何循环，而是关心多个执行节点之间如何分工、传递状态、处理失败和共同完成目标。

图中的节点不一定都是 AI。它们可以是：

• 一个负责分析需求的智能体。
• 一段执行格式校验的普通代码。
• 一个访问搜索引擎或数据库的工具。
• 一个负责交叉核查的验证智能体。
• 一个负责高风险审批的人。

因此，更准确的理解是：

Loop 设计“一个执行者怎样反复工作”，Graph 设计“多个执行单元怎样形成组织”。

Graph 可以包含 Loop。某个节点内部可以自主循环，而整个系统依然按照图定义的边界运行。两者不是替代关系，而是不同层级的工程结构。

二、AI 工程为什么会从 Prompt 走到 Graph

Prompt、Context、Harness、Loop 和 Graph 经常被包装成互相替代的新概念。实际上，它们更像逐层扩展的工程视角。

这五层解决的问题不同：

• Prompt 让模型更准确地理解当前要求。
• Context 让模型获得完成当前步骤所需的信息。
• Harness 为模型提供工具，同时限制它能做什么。
• Loop 让智能体可以围绕目标连续行动。
• Graph 把不同角色和能力组织成一个完整系统。

一个 Graph 节点依然需要好的 Prompt 和 Context，也依然运行在 Harness 中。Graph Engineering 并没有让前面的工程方法失效，而是把它们组合到更高一层。

三、为什么单个 Loop 会遇到天花板

Loop 非常适合边界明确、反馈清晰的任务，但把复杂系统全部塞进一个循环，会出现一些结构性问题。

1. 上下文不断污染

一个智能体既搜集资料、又写作、又审稿时，它的上下文会同时包含：

• 原始网页和日志。
• 中间推理与失败尝试。
• 尚未确认的假设。
• 已废弃的草稿。
• 最终需要验证的结果。

信息越多不一定越好。无关内容会挤占上下文窗口，也会让模型难以区分“原始事实”“中间猜测”和“最终结论”。

Graph 可以让不同节点使用不同上下文。研究节点只负责形成结构化笔记，写作节点只接收经过整理的材料，验证节点则只看交付物、原始证据和验收规则。

2. 工作天然串行

单个 Loop 通常按顺序执行：查完来源 A，再查来源 B，然后查来源 C。如果任务可以并行拆分，这种方式会浪费时间。

Graph 可以把互不依赖的任务同时分发出去，再统一合并结果。这种结构通常称为“扇出与扇入”。

3. 自我审查存在偏差

让生成答案的智能体在同一上下文中检查自己的答案，类似于让作者给自己的试卷评分。

模型已经沿着某条思路得出结论，后续审查很容易受到原有推理的影响。即使提示它“认真找错”，它也可能只是重新解释自己的答案为什么合理。

Graph 可以将生成者与验证者拆开：

• 生成节点负责提出结果。
• 验证节点使用全新的上下文，主动寻找反例和证据缺口。
• 确定性的检查交给程序，而不是让另一个模型凭感觉判断。

4. 故障恢复成本高

长循环在第 20 步失败时，如果没有检查点，系统可能只能从头开始。这样不仅浪费 token 和时间，也可能因为模型输出具有随机性而无法复现原路径。

Graph 可以在节点之间保存状态。某个节点失败后，只重试失败部分，而不必重新执行所有已经成功的步骤。

5. 过程难以观察和治理

如果全部控制逻辑都隐藏在一段长对话里，工程人员很难快速回答：

• 系统当前执行到哪一步？
• 哪个节点消耗了最多成本？
• 哪条信息导致了错误结论？
• 为什么任务被路由到这条路径？
• 哪个动作修改了生产数据？

Graph 把控制流程显式化，使节点、状态变化、成本、错误和重试可以分别记录与分析。

6. 单指标可能造成“目标失明”

一个循环通常围绕某个可测量指标优化。但指标只是目标的近似表达，不是目标本身。

例如，客服智能体被要求提高“工单关闭率”，它可能学会尽快结束对话，却没有真正解决用户的问题。数字变好了，业务结果反而变差。

这类现象也可以用古德哈特定律解释：当一个指标成为目标时，它往往不再是一个好指标。

Graph 不能自动消除这个问题，但它可以加入相互制衡的节点，例如同时检查解决率、重复咨询率、客户满意度和人工抽检结果。最终仍需要人定义“什么才是真正的好结果”。

四、一张可执行的 Graph 由什么组成

Graph 不是画在演示文稿里的流程图。流程图只描述人们希望工作如何进行，而可执行 Graph 必须真正控制任务运行。

一张最基本的执行图包含四类要素。

1. 节点：谁来完成工作

节点是具有明确输入、输出和职责的执行单元。

常见节点包括：

• LLM 节点：理解需求、归纳信息、生成内容、作出语义判断。
• Agent 节点：在局部目标下使用工具并自主循环。
• 代码节点：校验格式、计算数值、去重、排序、执行测试。
• 工具节点：访问搜索、数据库、文件系统或外部 API。
• 人工节点：审批高风险操作、处理模糊判断、确认最终发布。

一个好节点应当职责单一。输入和输出越清楚，节点越容易测试、替换和复用。

2. 边：工作怎样流动

边连接节点，定义控制权和数据怎样流动。

边可以表达：

• 固定顺序：A 完成后执行 B。
• 条件分支：高风险任务进入人工审批，低风险任务自动继续。
• 并行分发：多个节点同时处理不同子任务。
• 汇合：等所有必要结果返回后再继续。
• 重试：校验不通过时回到上一个节点。
• 终止：满足成功、失败或预算条件后停止。

对可预测的逻辑，应优先使用普通代码决定边，而不是每次都让模型自由判断。

3. 状态：节点之间传递什么

状态是整个图共同维护的任务记录。它不是把所有对话原样拼接起来，而应当是有结构、可追踪的数据。

例如，一份研究简报的状态可以设计为：

{ "topic": "AI 智能体工程", "sources": [], "notes": [], "draft": "", "verification": { "passed": false, "issues": [] }, "revision_count": 0, "status": "researching" }

结构化状态有三个好处：

• 每个节点只读取自己需要的字段，减少上下文污染。
• 字段变化可以被记录、比较和审计。
• 程序能够对类型、完整性和状态转换进行确定性校验。

4. 运行规则：系统怎样保持可控

运行规则决定图能否从 Demo 进入生产环境，包括：

• 每个节点的超时与重试次数。
• 整个任务的 token、时间和金额预算。
• 幂等策略，防止重试造成重复扣款或重复写入。
• 检查点和恢复策略。
• 节点可使用的工具与数据权限。
• 日志、链路追踪和告警规则。
• 必须由人批准的高风险操作。

如果只有节点和箭头，却没有这些规则，那仍然只是一张概念图，而不是可靠系统。

五、三种最常用的协作结构

1. 流水线：一步一步加工

流水线适合可以稳定拆成固定阶段的任务。

典型场景：

• 文档解析与结构化抽取。
• 内容审核和格式转换。
• 代码生成、测试、打包与发布。

优点是路径清楚、容易调试；缺点是灵活性有限，前一步错误可能逐层传递。

2. 扇出与扇入：并行处理后汇总

当任务可以分成多个相互独立的部分时，可以并行执行。

典型场景：

• 同时检索多个信息源。
• 让不同评审者分别检查安全、性能和可维护性。
• 对多个文件或数据分片并行处理。

关键难点不在“分出去”，而在“怎样合回来”。合并节点必须处理重复、冲突、缺失和来源优先级，不能只是把所有输出简单拼接。

3. 编排者与工作者：动态分工

编排者先分析任务，再决定需要哪些工作者以及如何汇总结果。

这种结构适合子任务无法提前完全写死的开放问题，例如深度研究、复杂代码迁移和跨领域分析。

它也最容易失控，因此必须限制：

• 最多创建多少子任务。
• 子任务可以递归到多少层。
• 每个工作者能使用哪些工具。
• 整体最多消耗多少预算。
• 什么条件下必须停止并交给人处理。

真实系统常常会组合三种结构。例如，编排者把研究任务扇出给多个工作者，每个工作者内部再使用一条固定流水线。

六、Graph 的核心价值是确定性，而不是 Agent 数量

“用了多少个智能体”不是评价系统成熟度的指标。节点越多，往往意味着调用成本、失败概率和调试难度也越高。

Graph 真正有价值的地方，是把不同性质的工作分配给最合适的执行者。

1. 让模型处理模糊判断

模型适合处理：

• 理解自然语言意图。
• 归纳非结构化资料。
• 生成多个候选方案。
• 判断文本语义和风格。
• 在复杂环境中规划下一步。

2. 让代码处理确定规则

普通程序适合处理：

• JSON Schema 校验。
• 数值计算和预算统计。
• 排序、去重和精确匹配。
• 单元测试和静态检查。
• 权限判断与状态转换。
• 超时、重试和速率限制。

如果一个问题可以用明确代码判断，就不应让模型反复猜测。用 LLM 判断 JSON 是否有效，不仅更贵，也更不稳定。

3. 让独立验证者主动找错

验证节点不应只是笼统地问“这个结果好不好”，而应根据明确标准进行对抗性检查：

• 每个关键事实是否有可追溯来源？
• 引用内容是否真的支持对应结论？
• 是否遗漏了与结论冲突的重要证据？
• 输出是否满足格式、长度和风险要求？
• 是否可以通过测试、查询或外部系统验证？

验证者最好使用干净上下文，不读取生成者冗长的思考过程，避免继承同一套偏见。

4. 让现实结果成为最终锚点

多个模型相互赞同，不等于结论正确。Graph 必须连接现实世界中可验证的结果，例如：

• 测试是否真实通过。
• 数据库记录是否真实写入。
• 支付是否真实到账。
• 库存数量是否真实一致。
• 用户留存是否真实改善。
• 线上错误率是否真实下降。

如果图中的所有节点只引用其他模型生成的内容，它可能只是一个组织得更好的幻觉系统。

七、完整示例：自动生成每日技术简报

假设系统每天早上需要读取多个技术来源，生成一份一页纸简报，在发送前核查事实。

1. 单 Loop 方案

一个智能体依次完成：搜索、阅读、总结、写作、自查和发送。

优点：

• 实现简单。
• 提示词和运行逻辑集中。
• 一次性任务的启动成本低。

缺点：

• 多个来源只能顺序处理。
• 原始搜索内容和草稿混在同一上下文里。
• 自己检查自己的结论，容易漏错。
• 后期失败时可能需要从头重跑。

2. 小型 Graph 方案

将任务拆成以下节点：

1. 调度节点确定当天主题和来源。
2. 多个研究节点并行读取不同来源。
3. 代码节点完成去重、日期过滤和字段校验。
4. 写作节点只根据结构化笔记生成简报。
5. 验证节点在新上下文中核对事实和引用。
6. 发送节点在通过校验后投递邮件。

3. 节点间只传递必要信息

研究节点不直接写文章，只返回统一结构：

{ "title": "文章标题", "source_url": "https://example.com/article", "published_at": "2026-08-06", "facts": [ { "claim": "需要写入简报的事实", "evidence": "原文中的支持内容" } ], "uncertainties": [] }

写作节点只接收已经通过结构校验的笔记。验证节点则接收最终简报、事实列表、来源链接和验收标准。

这样做的意义是让每个节点都拥有“足够但不过量”的上下文。

4. 这张图付出的代价

Graph 不是免费的。与单 Loop 相比，它需要：

• 维护多个节点的指令。
• 设计并升级共享状态结构。
• 处理并发、超时、重试和部分失败。
• 监控每个节点的成本和质量。
• 防止错误路由、无限循环和状态泄漏。

如果简报每天运行、质量要求高，这些投入可能值得。如果任务只执行一次，搭图的成本很可能高于它带来的收益。

八、什么时候该用 Loop，什么时候该用 Graph

可以先用下面的表格做初步判断。

适合 Loop 的任务

• 修复一个范围明确且有测试反馈的 Bug。
• 定时检查 CI，失败时总结日志并通知负责人。
• 对一批结构相似的文件执行统一转换。
• 在一个明确领域内完成资料查找和总结。

适合 Graph 的任务

• 多来源、可并行的深度研究。
• 需要安全、性能和业务等多角色评审的代码变更。
• 涉及多个系统并要求检查点和人工审批的业务流程。
• 大规模代码迁移、跨仓库修改和分阶段验证。
• 必须保留完整审计记录的高风险自动化任务。

最重要的选型原则

先使用能够解决问题的最简单结构，只有当单个 Loop 的局限已经被真实测量出来时，才升级为 Graph。

不要因为“多智能体”听起来先进就提前引入复杂度。很多问题通过改进提示词、提供更准确的上下文、补充一个测试工具，就已经能够解决。

九、从单 Agent 演进到 Graph 的落地步骤

第一步：先建立可工作的单节点基线

先让一个模型调用或一个 Agent 完成核心任务，并记录：

• 成功率。
• 平均耗时。
• token 与金额成本。
• 最常见失败类型。
• 人工修正所需时间。

没有基线，就无法判断 Graph 是否真的带来提升。

第二步：根据失败原因拆节点

不要按想象中的“角色”随意拆分，而应按真实瓶颈拆分：

• 上下文太乱，就分离研究和生成。
• 自查不可靠，就增加独立验证。
• 串行太慢，就把独立任务并行化。
• 某一步经常失败，就为它建立检查点和局部重试。
• 高风险操作不可控，就增加权限边界和人工审批。

第三步：定义清晰的状态契约

为每个节点写清楚：

• 输入字段及其类型。
• 输出字段及其类型。
• 哪些字段必填。
• 哪些节点可以修改哪些字段。
• 错误怎样表达。
• 状态版本怎样升级。

节点之间应传递结构化数据，而不是互相转发一整段聊天记录。

第四步：把确定性逻辑移出模型

逐项检查所有模型判断：

• 能否改为 Schema 校验？
• 能否改为单元测试或静态检查？
• 能否用数据库查询或 API 返回值确认？
• 能否用固定规则完成路由？

让模型专注于需要语义理解和推理的部分。

第五步：加入检查点与幂等保护

每个具有外部副作用的节点都应考虑幂等性。

例如，发送邮件的节点在超时后重试，系统必须知道邮件究竟有没有发送成功，否则可能重复发送。常见方法是给任务分配唯一键，并在执行外部动作前后记录状态。

第六步：限制预算、重试和递归

至少设置：

• 单节点最大执行时间。
• 单节点最大重试次数。
• 全图最大步骤数。
• 子智能体最大数量和递归深度。
• 单任务 token 或金额上限。
• 连续失败后的人工接管条件。

停止条件和成功条件同样重要。没有边界的自主性不是智能，而是不可控。

第七步：建立节点级可观测性

建议记录：

• 节点名称、输入摘要和输出摘要。
• 模型、提示版本与状态版本。
• 开始时间、结束时间和耗时。
• token、工具调用和金额成本。
• 路由选择及其原因。
• 错误、重试和人工干预。
• 最终结果与现实反馈。

日志中应避免直接保存密钥、个人数据和完整敏感上下文。

第八步：使用真实任务评估

不要只看“最终答案似乎不错”，而应构建包含典型任务、边界任务和故障任务的评估集。

同时比较：

• Graph 相对基线提升了多少质量。
• 增加了多少延迟和成本。
• 是否减少了人工修正时间。
• 在工具失败和部分节点超时时能否恢复。
• 复杂度是否值得长期维护。

十、Graph Engineering 中容易踩的坑

1. 把每个步骤都做成 Agent

不是所有节点都需要自主推理。格式转换、字段校验和数值计算使用普通函数更可靠。

2. 让所有节点共享完整上下文

这样虽然实现方便，却失去了上下文隔离的优势，也容易泄露不必要的数据和继承上游偏见。

3. 用自然语言代替状态契约

如果节点只通过自由文本沟通，下游就必须猜测字段含义，系统很难稳定解析和演进。

4. 只设置重试，不分析失败类型

身份认证失败、参数错误和服务暂时不可用需要不同策略。盲目重试既浪费成本，也可能放大故障。

5. 让模型动态修改长期权限

任务如何拆分可以灵活变化，但谁能删除数据、修改数据库或绕过审批，必须由稳定、可审计的权限系统控制，不能让模型临场决定。

6. 没有现实反馈闭环

离线评审分数高不代表上线有效。系统必须持续观察真实业务结果，防止代理指标与最终目标偏离。

7. 过早依赖复杂框架

框架可以提供状态管理、检查点和可观测性，但也可能隐藏底层提示、模型响应和状态变化。简单流程可以先用直接的模型 API 与普通代码实现；当持久化、分支、恢复等需求明确后，再引入图框架。

十一、如何评价一张 Graph 是否设计得好

一张好图不在于视觉上复杂，而在于它能否回答以下问题：

职责是否清楚

• 每个节点是否只有一个主要职责？
• 节点输入和输出是否有明确契约？
• 能否单独测试和替换某个节点？

流程是否可控

• 路由条件是否明确？
• 是否存在无限循环的可能？
• 超时、失败和预算耗尽时会发生什么？

结果是否可验证

• 是否区分生成者和验证者？
• 确定性检查是否由代码完成？
• 是否连接了真实测试、数据或业务反馈？

系统是否可恢复

• 是否保存关键检查点？
• 是否支持局部重试？
• 有副作用的操作是否幂等？

权限是否最小化

• 每个节点是否只能访问完成任务所需的工具和数据？
• 高风险操作是否需要人工确认？
• 所有关键动作是否可追溯？

收益是否覆盖成本

• 相比单 Loop，质量提升是否可测量？
• 额外调用、延迟和维护成本是否合理？
• 更简单的方法能否达到同样效果？

如果这些问题没有答案，再漂亮的图也很难可靠运行。

十二、总结：从“会干活”走向“会协作”

Graph Engineering 这个名称可能是新的，但节点、边、状态机、工作流和分布式调度并不是新发明。真正值得关注的，是大模型能力成熟后，智能节点开始进入这些经典工程结构。

Loop 让 AI 从问答工具变成可以持续工作的执行者；Graph 则尝试把多个执行者、程序、工具和人组成一个可治理的系统。

理解这一变化，可以记住四句话：

1. Loop 与 Graph 不是替代关系。Graph 可以组织多个节点，而节点内部仍然可以运行 Loop。
2. Graph 的价值不等于 Agent 数量。它的核心价值是分工、隔离、验证、恢复和治理带来的确定性。
3. 模型负责判断，代码负责约束。能用确定性程序解决的问题，不要交给概率模型。
4. 先简单，再复杂。单次调用能完成就不使用 Agent，单个 Loop 能稳定完成就不搭 Graph。

最终，AI 系统面对的已经不只是模型问题，也是一个经典的组织问题：怎样分工，怎样交接，怎样监督，怎样控制权限，以及怎样在某个成员失败时保证整体继续运行。

名称可能继续变化，但工程方向已经很清晰：AI 应用正在从“设计一个智能体如何工作”，逐渐走向“设计一组智能节点如何可靠协作”。

学习资源推荐

如果你想更深入地学习大模型，以下是一些非常有价值的学习资源，这些资源将帮助你从不同角度学习大模型，提升你的实践能力。

一、全套AGI大模型学习路线

AI大模型时代的学习之旅：从基础到前沿，掌握人工智能的核心技能！​

因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取

二、640套AI大模型报告合集

这套包含640份报告的合集，涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示

​因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取

三、AI大模型经典PDF籍

随着人工智能技术的飞速发展，AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型，如GPT-3、BERT、XLNet等，以其强大的语言理解和生成能力，正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。

因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取

四、AI大模型商业化落地方案

作为普通人，入局大模型时代需要持续学习和实践，不断提高自己的技能和认知水平，同时也需要有责任感和伦理意识，为人工智能的健康发展贡献力量。