从 Loop 到 Graph：AI 智能体协作系统工程指南

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

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

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

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

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

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

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

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

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

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

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

Loop 可以概括为一个闭环：

text 复制代码

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

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

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

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

这个过程可以表示为：

flowchart LR A[读取任务与环境] --> B[规划下一步] B --> C[调用工具执行] C --> D[检查执行结果] D -->|未达到目标| B D -->|达到目标| E[输出结果]

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

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

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

flowchart LR A[任务入口] --> B[任务分类] B --> C[研究节点] B --> D[数据节点] C --> E[内容生成节点] D --> E E --> F[独立验证节点] F -->|不合格| E F -->|合格| G[人工审批] G --> H[发布]

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

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

因此，更准确的理解是：

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

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

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

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

层级	主要问题	典型内容
Prompt Engineering	这一次该怎样向模型表达任务	指令、示例、输出格式、角色设定
Context Engineering	这一步应该让模型看到哪些信息	检索资料、历史记录、记忆、工具说明
Harness Engineering	模型应当在什么工程环境中工作	工具、权限、规则、状态、日志、验证机制
Loop Engineering	一个智能体怎样自主持续执行	观察、规划、行动、反馈、停止条件
Graph Engineering	多个执行单元怎样分工与协作	节点、边、共享状态、路由、检查点、审批

这五层解决的问题不同：

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

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

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

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

1. 上下文不断污染

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

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

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

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

2. 工作天然串行

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

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

flowchart LR A[拆分任务] --> B[来源 A] A --> C[来源 B] A --> D[来源 C] B --> E[去重与合并] C --> E D --> E

3. 自我审查存在偏差

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

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

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

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

4. 故障恢复成本高

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

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

5. 过程难以观察和治理

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

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

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

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

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

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

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

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

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

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

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

1. 节点：谁来完成工作

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

常见节点包括：

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

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

2. 边：工作怎样流动

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

边可以表达：

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

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

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

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

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

json 复制代码

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

结构化状态有三个好处：

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

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

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

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

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

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

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

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

flowchart LR A[提取信息] --> B[结构化整理] B --> C[生成初稿] C --> D[格式校验] D --> E[发布]

典型场景：

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

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

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

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

典型场景：

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

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

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

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

flowchart TD A[编排者分析任务] --> B[研究工作者] A --> C[数据工作者] A --> D[风险工作者] B --> E[编排者汇总] C --> E D --> E E --> F[验证节点]

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

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

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

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

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

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

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

1. 让模型处理模糊判断

模型适合处理：

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

2. 让代码处理确定规则

普通程序适合处理：

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

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

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

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

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

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

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

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

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

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

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

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

1. 单 Loop 方案

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

优点：

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

缺点：

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

2. 小型 Graph 方案

将任务拆成以下节点：

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

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

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

json 复制代码

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

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

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

4. 这张图付出的代价

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

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

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

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

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

判断维度	更适合 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 则尝试把多个执行者、程序、工具和人组成一个可治理的系统。

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

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

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

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