从 Loop 到 Graph：AI 智能体两大工程范式深度解析

导读：2026 年 AI Agent 领域先后诞生 Loop Engineering（循环工程）与 Graph Engineering（图工程）两大热门范式，很多开发者容易混淆二者，甚至和向量领域的 Loop Embedding、Graph Embedding 相混淆。本文先厘清向量嵌入概念，再深度拆解循环工程与图工程，对比适用边界、优缺点，结合生产实践给出选型思路。

一、先分清：Embedding（嵌入向量）与 Engineering（工程范式）

很多同学会把Loop Embedding、Graph Embedding，和Loop Engineering、Graph Engineering混为一谈，这是两套完全不同领域的概念。

1. Loop Embedding（循环嵌入）

Loop Embedding 属于向量表示学习范畴。它把 Agent 多轮循环交互过程中产生的推理轨迹、迭代步骤、状态变迁，映射成低维向量空间，用来刻画循环的行为模式。

• 用途：对 Agent 循环行为做聚类、异常检测、轨迹相似度比对，用于分析 Agent 是不是陷入死循环、行为是否漂移。
• 定位：数据层技术，做的是信息向量化表征，并不负责搭建 Agent 运行、调度逻辑。

举例：同一个任务下 Agent 两次执行循环，通过 Loop Embedding 向量相似度，可以判断两次执行路径是否大体一致。

2. Graph Embedding（图嵌入）

Graph Embedding 是图机器学习经典技术，将知识图谱、关系网络中的节点、边转换成稠密向量。

• 用途：知识检索、实体链接、关系预测，常见在 GraphRAG 系统。它解决知识实体之间语义表示问题。
• 定位：依然属于数据、检索层。只负责把图结构数据变成向量，不会去编排 Agent 任务流转、多智能体调度。

重点区分：✅ Loop / Graph Embedding：数据向量化，属于表示层，管 “怎么把信息变成向量”；✅ Loop / Graph Engineering：Agent 系统架构方法论，属于编排执行层，管 “Agent 如何干活、如何协作”

很多技术文章里讨论的 Agent 热点，讲的是Loop Engineering、Graph Engineering（工程范式） ，并不是 Embedding 向量技术。下面正文聚焦两大 Agent 工程范式。

二、Loop Engineering（循环工程）：单智能体的自主闭环系统

2.1 核心定义

Loop Engineering 是面向单个智能体的系统设计范式。不再由人一步步下达指令驱动 AI，而是构建一套自主的迭代闭环。人只负责设定目标和验收标准，由系统自动完成发现、规划、执行、验证、迭代，直到达成目标或者判定任务不可执行。

底层的最小执行单元就是大家熟知的ReAct 内层循环（思考→行动→观察）。Loop Engineering 在 ReAct 之上，增加一层外层编排（Outer‑Loop） ，解决跨轮次、跨会话的任务管理。

2.2 核心架构：五层闭环与六大设计要素

完整 Loop 遵循Discover（发现）→ Plan（规划）→ Execute（执行）→ Verify（验证）→ Iterate（迭代）闭环。

1. Discover：读取外部信号，比如 CI 报错、issue 缺陷，把现实世界信息输入系统；
2. Plan：把大目标拆解成可执行子步骤；
3. Execute：调用工具、修改文件、执行命令；
4. Verify：依靠测试、编译、返回码这类客观可机器判定指标校验结果，拒绝纯主观判断；
5. Iterate：校验失败自动修复重试；成功流转下一阶段，全部状态持久保存，支持断点续跑。

六大关键设计要素：

1. 自动化心跳：提供循环触发机制，分为条件驱动、时间驱动两类；
2. 工作树隔离：借助 Git Worktree，支持子任务并行，文件改动互不干扰；
3. Skill 技能体系：以SKILL.md固化项目知识、编码规范，按需加载，降低 token 消耗；
4. MCP 连接器：打通外部工具链，Jira、CI 流水线、数据库，让 Agent 触碰真实业务世界；
5. 子智能体与对抗验证：执行、评审角色分离，用不同模型完成校验，规避 “自己写代码自己审查” 的确认偏误；
6. 状态外置哲学：任务进度全部保存在外部文件 / 数据库，而不是依赖对话上下文窗口。每一轮迭代可以开启全新上下文，从持久化存储读取进度，从根源缓解长任务遗忘、上下文漂移。

2.3 两种驱动模式与局限

Loop 工程存在两类典型驱动：

1. 条件驱动（如 CodeBuddy /goal） ：设置可度量终态，独立评估器判断任务完成，适合重构、模块迁移这类有明确终点的任务；
2. 时间驱动（如 CodeBuddy /loop） ：按固定周期执行，适合巡检、CI 状态监控。

即便设计完善，单 Loop 架构依然存在与生俱来的结构性短板：

1. 上下文腐烂：多轮工具调用不断堆积，原始任务目标被海量中间输出淹没；
2. 错误级联：全部推理在同一条上下文链路，发生错误容易层层传递，模型很难自我跳出错误路径；
3. 工具过载：单个 Agent 挂载大量工具时，工具选择准确率显著下滑；
4. 控制粒度不足：很难中途插入人工审批、独立质检；只能整体跑完或者直接杀死循环，是 “全有或者全无”；
5. 可观测性弱：只能拿到完整对话日志，很难追溯每一次分支决策的缘由；
6. 目标失明（古德哈特定律） ：Agent 会疯狂优化表面指标，但背离业务真正意图。

本质：这些缺陷不是写得不好的 bug，是 “单一循环” 这种形态固有的天花板，单纯把循环做得更大、轮次拉更多，无法根治。当任务复杂度上升，就需要 Graph Engineering。

三、Graph Engineering（图工程）：多单元的协同编排体系

3.1 核心定义

Graph Engineering 不是要消灭 Loop，而是在上层做编排。它不再聚焦单个 Agent 内部怎么循环，而是去设计多个执行单元之间的组织、流转、依赖关系。

通俗比喻：Loop 是一个能力很强的员工，可以自主完成一整套工作；Graph 是搭建一家小公司，定义工位、工作交接流程、共享看板、规章制度，让多角色协同完成超大型项目。

注意：这里的 Graph 不是 PPT 上给人看的流程图，是机器可实际运行的执行图；也不等同知识图谱，知识图谱管理知识实体，Graph Engineering 管理任务和工作流。

3.2 四大组成部分 G = (V 节点，E 边，S 状态，P 策略)

1. V 节点 Node：最小执行单元。节点内部可以是一个完整 Loop 智能体、普通函数工具、验证器节点，甚至人工审批节点；一个节点原则上只聚焦一件事。
2. E 边 Edge：节点之间的路由逻辑。支持直通、条件分支、扇出 Fan‑out 并行、扇入 Fan‑in 合并、失败回退重试。
3. S 共享状态 State：全局统一的状态对象，所有节点可读可写，保存任务产物、检查点、预算、证据，把分散独立的节点捏合成完整系统。
4. P 策略 Policy：权限约束。规定谁可以调用高危工具、谁必须经过人工审批，权限策略不交给模型动态决策，必须硬编码、可审计。

3.3 经典拓扑模式

1. 菱形（扇出‑扇入） ：多个子任务并行执行，全部完成之后汇总合并。适合调研、多维度交叉校验；
2. 主管‑工人 Orchestrator‑Workers：主管节点动态拆解任务，分发给多个专职工人节点执行，最后汇总结果；适合任务结构运行时才确定的复杂工作；
3. 流水线 Pipeline：任务按固定顺序流转，中间设置检查点，适合可以清晰拆解的标准化任务；
4. 评估‑优化 Evaluator‑Optimizer：生成节点与独立验证节点成对出现，不合格就回退重跑。

Graph 工程最重要思想：系统确定性，不能靠智能体自觉，要靠架构拆分得到。把 “干活” 和 “校验” 拆成两套独立节点，验证器拿到干净全新上下文，专门去挑战前面输出的结果。验证可以分为对抗式校验、多视角校验、评委打分。同时遵循一条铁律：确定性的校验逻辑交给普通代码，模型只负责做推理判断；系统必须对接现实世界硬事实，避免沦为精致的幻觉机器。

3.4 Graph 带来的新增成本

Graph 不是银弹，它会带来额外工程开销：

1. 需要维护多套提示词、多个节点逻辑；
2. 需要设计复杂共享状态结构，处理状态泄露、合并遗漏；
3. Token 消耗显著上涨，多智能体方案 token 开销可达普通单 Agent 的 15 倍；
4. 会出现新故障：路由死循环、子节点异常、状态同步 bug。

选型原则：一次性简单任务强行上 Graph，只会增加不必要成本；只有长期重复运行、需要分工、并行、独立审批校验的业务，收益才会大于成本。

四、Loop Engineering vs Graph Engineering 深度对比

表格

对比维度	Loop Engineering（循环工程）	Graph Engineering（图工程）
核心对象	单个智能体，外层编排多层迭代	多个执行单元（Agent / 工具 / 人）的组织协同
内部依赖	底层内置 ReAct 内层循环	每个节点内部可以包含完整 Loop 循环
状态管理	状态外置，单任务完整状态；上下文可以每次重置	全局共享状态，多节点读写，需要处理状态隔离与同步
并行能力	有限，依靠工作树做任务隔离，难以做流程内并行	原生支持扇出并行、多分支执行
校验机制	依靠独立评估器，单链路对抗验证	可以拆分独立验证节点，多视角交叉评审，支持人工审批节点接入
可观测性	只能观测整条对话历史	节点、边、状态全部可追溯，支持断点快照、时间旅行调试
适合任务	目标明确、边界清晰，单主体就可以完成；一次性或者简单周期性任务	任务庞大复杂，需要分工、并行、多角色审核，长期重复运行的生产业务
主要痛点	上下文腐烂、错误级联、缺少分支与审批	架构复杂、token 成本高、状态管理难度大，引入新故障模式
架构定位	系统中层，解决单个 Agent 自主迭代	系统顶层，在 Loop 之上做编排调度

关键关系澄清（很多人存在误解）

1. Graph 并没有杀死 Loop，二者不是替代，是嵌套叠加。Graph 里面每一个干活的 Agent 节点，内部依然跑一套完整 Loop Engineering；Loop 是图的最小单元（单节点自环）。
2. 五层 AI 工程完整演进链条：Prompt Engineering提示工程 → Context Engineering上下文工程 → Harness Engineering运行底座工程 → Loop Engineering单智能体循环工程 → Graph Engineering多单元图编排工程每一层都建立在前一层完备的基础之上，上层不能跳过下层。没有好的 Harness 底座，Loop 和 Graph 都很难稳定运行。

五、生产环境如何做选型决策

✅优先选用 Loop Engineering 的场景

1. 任务目标单一，业务边界清晰，不需要复杂分支、并行；
2. 不需要多角色分工、中间人工审批；
3. 一次性任务或者简单定时巡检，不想承担复杂状态开发成本；

示例：单模块代码迁移、简单 CI 监控、脚本自动化修复。

✅适合升级到 Graph Engineering 的场景，满足任意多条就值得考虑

1. 上下文保护诉求：子任务会产生大量无关信息，需要隔离，避免污染主流程；
2. 需要并行执行：多个子任务可以独立开展，追求效率，需要交叉验证；
3. 专业化分工诉求：不同步骤需要完全不同工具、模型、提示词，希望职责解耦；
4. 流程需要分支、暂停、人工介入审批、失败局部重试，而不是整体全部重来；
5. 业务长期反复运行，愿意为可靠性、可观测性承担更高 Token 与开发成本。

反面警示：不要为了追逐技术热点，简单任务强行上 Graph 架构。很多业务只需要打磨好单个 Loop 就可以交付，过度设计会带来大量调试负担。

六、总结与实践启示

1. 分清 Embedding 和 Engineering：Embedding 是向量表示，解决数据语义表征；Loop/Graph Engineering 是 Agent 系统编排方法论，解决任务执行与协作，二者领域完全不同，切勿混淆。
2. Loop 和 Graph 是嵌套递进，不是互斥对立：Loop 解决 “一个 Agent 如何自主把事做完”；Graph 解决 “一堆 Agent、工具、人如何组织成一套稳健系统”。Graph 内部大量复用 Loop 能力。
3. 不要迷信新名词：Graph Engineering 的节点、状态、条件路由思想并不是全新发明，状态机、工作流早已存在；真正新的变化，是把大模型推理单元作为节点放进这套调度体系中。
4. 架构的本质是取舍：Loop 胜在简单低成本，但存在单循环固有的天花板；Graph 换取并行、分工、校验、可观测的同时，付出开发成本、token 成本。工程实践中坚持最简优先，能用单层 Loop 搞定就不盲目上多节点 Graph。
5. 无论 Loop 还是 Graph，都必须锚定现实世界。所有精巧架构，如果只在模型生成内容之间互相推导，没有对接测试结果、业务指标、外部系统，终究只是一套精致的幻觉系统。

写在最后：Agent 工程演进路线给开发者的启示，现在做 AI 系统，已经不再仅仅是打磨提示词。从 Harness 底座，到单 Agent 循环，再到多单元图编排，完整的系统能力，才是拉开 Demo 和生产级产品差距的关键。