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

引言AI 能持续工作之后下一个问题是什么早期使用大模型时人们最关心的是“提示词怎么写”。后来模型能够读取资料、调用工具、修改代码和运行测试工程重点逐渐变成“怎样让一个智能体独立完成任务”。于是Agent Loop 成为常见工作方式智能体观察环境、制定计划、执行动作、检查结果然后不断重复直到达到目标。但真实任务往往不只需要一个执行者。例如一份高质量的行业研究报告可能同时需要从不同来源搜集资料。判断来源是否可靠。提取事实并消除重复信息。根据目标读者组织文章。独立核查关键结论。在发布前经过人工审批。如果把所有工作都交给同一个智能体并塞进一个不断增长的循环系统很快会遇到上下文混乱、串行效率低、自我审查失效、故障难以恢复等问题。Graph Engineering 关注的正是下一层问题如何把多个智能体、普通程序、外部工具和人组织成一个可执行、可检查、可恢复的协作系统。它不是简单地“多开几个 Agent”也不是给旧流程换一个新名字。它真正带来的变化是把 AI 工程从“设计一个执行者的行为”提升到“设计一组执行者之间的关系”。一、先用一句话理解 Loop 与 Graph1. Loop让一个智能体持续工作Loop 可以概括为一个闭环观察 - 思考与规划 - 执行 - 验证 - 决定是否继续它解决的核心问题是怎样让一个智能体不必等待人类逐步下指令也能围绕目标连续行动。例如让一个代码智能体修复 Bug阅读错误日志。搜索相关代码。推断问题原因。修改代码。运行测试。如果测试失败分析结果并继续修改。如果测试通过输出变更说明。这个过程可以表示为Loop 的价值是把人从“每一步的操作者”变成“目标和验收标准的制定者”。2. Graph让多个节点有序协作Graph 不再只关心一个智能体内部如何循环而是关心多个执行节点之间如何分工、传递状态、处理失败和共同完成目标。图中的节点不一定都是 AI。它们可以是一个负责分析需求的智能体。一段执行格式校验的普通代码。一个访问搜索引擎或数据库的工具。一个负责交叉核查的验证智能体。一个负责高风险审批的人。因此更准确的理解是Loop 设计“一个执行者怎样反复工作”Graph 设计“多个执行单元怎样形成组织”。Graph 可以包含 Loop。某个节点内部可以自主循环而整个系统依然按照图定义的边界运行。两者不是替代关系而是不同层级的工程结构。二、AI 工程为什么会从 Prompt 走到 GraphPrompt、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 可以把互不依赖的任务同时分发出去再统一合并结果。这种结构通常称为“扇出与扇入”。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 方案将任务拆成以下节点调度节点确定当天主题和来源。多个研究节点并行读取不同来源。代码节点完成去重、日期过滤和字段校验。写作节点只根据结构化笔记生成简报。验证节点在新上下文中核对事实和引用。发送节点在通过校验后投递邮件。3. 节点间只传递必要信息研究节点不直接写文章只返回统一结构{ 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 应用正在从“设计一个智能体如何工作”逐渐走向“设计一组智能节点如何可靠协作”。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。