Loop Engineering 没死，Graph Engineering 也没有上位

2026 年，AI 圈制造新概念的速度，已经快过很多团队消化旧概念的速度。

6 月 7 日，Addy Osmani 发布《Loop Engineering》，系统梳理了一种正在流行的 AI 编程方式：开发者不再逐轮给 Agent 输入提示词，而是设计一个能够自动发现任务、执行任务、验证结果并继续工作的循环系统。

到了 7 月 18 日，Peter Steinberger 在 X 上问了一句：

我们还在讨论循环，还是已经转向图了？

同一天，社区里出现了“Loop Engineering 已死，Graph Engineering 万岁”的说法。一个刚流行不到六周的概念，似乎就被宣布过时了。

但如果抛开社交媒体上的戏剧化表达，就会发现：

Loop Engineering 没有被 Graph Engineering 取代。

两者解决的根本不是同一个层面的问题。

一、Loop Engineering 到底是什么？

Loop Engineering 经常被简单概括为：

计划 → 执行 → 观察 → 修正 → 再执行

但这容易产生一个误解：它似乎只是给 AI 套了一个普通的 while 循环。

实际上，Loop Engineering 真正强调的不是“重复执行”，而是把原本由人完成的持续协调工作，变成一个可运行、可验证、可终止的系统。

过去使用 AI 编程工具时，常见流程是：

1. 人输入一个提示词；

2. AI 修改代码；

3. 人检查结果；

4. 人告诉 AI 哪里有问题；

5. AI 再修改一次。

在这个过程中，人本身就是循环控制器。

而在 Loop Engineering 中，开发者需要提前设计：

• 什么事件会触发任务；

• Agent 的目标是什么；

• Agent 可以使用哪些工具；

• 中间状态保存在哪里；

• 如何判断结果是否正确；

• 失败后如何修复；

• 在什么条件下停止；

• 哪些操作必须由人审批。

于是，人的角色从“不断提示 Agent”，转变成了“设计一个能够提示、约束和验证 Agent 的系统”。

Addy Osmani 提出的实践组件包括自动化任务、独立工作区、Skills、插件与连接器、子 Agent，以及能够跨任务保存进度的外部记忆。

OpenAI 对 Codex 的技术拆解也把 Agent Loop 描述为连接用户、模型和工具的核心执行逻辑：模型提出动作，系统执行工具，再把执行结果返回给模型，直到任务结束。

因此，更准确地说：

Agent Loop 是 Agent 的执行机制，而 Loop Engineering 是围绕这个执行机制设计目标、环境、验证和停止规则。

二、Loop Engineering 并不是突然出现的新技术

“Loop Engineering”这个名字很新，但循环式 Agent 并不新。

• 2022 年提出的ReAct，已经让语言模型在推理、行动和环境观察之间反复切换；

• 2023 年的Reflexion让 Agent 根据失败反馈进行反思，并把经验保存到记忆中；

•Self-Refine则让模型通过“生成—反馈—修改”的方式持续优化结果。

这些研究实际上已经具备循环结构。

2026 年的变化，不是人们第一次发现 Agent 可以循环，而是随着 Claude Code、Codex 等编程 Agent 的能力提升，这种循环开始从研究方法和框架内部机制，变成开发者可以直接设计、组合和长期运行的工程对象。

换句话说：

Loop Engineering 的新意更多在于工程化和产品化，而不是算法本身。

以前我们讨论模型如何在循环中工作，现在开始讨论：

• 循环由什么触发；

• 如何跨会话保存状态；

• 如何控制权限；

• 如何进行独立验收；

• 如何限制预算；

• 如何从失败位置恢复；

• 如何让多个循环并行运行。

这才是 Loop Engineering 真正值得关注的地方。

三、Graph Engineering 又是什么？

如果 Loop Engineering 关注的是“一个任务如何持续迭代”，那么 Graph Engineering 关注的就是：

多个步骤、多个 Agent 和多个循环，应该如何连接成一个完整系统？

一个典型的 Agent Graph 通常包括三个基本元素。

1. 节点

节点代表一个可以执行的单元，例如：

• 需求分析 Agent；

• 编码 Agent；

• 测试 Agent；

• 安全审查 Agent；

• 一个普通函数；

• 一次数据库查询；

• 一个外部工具调用；

• 一个人工审批步骤。

图里的节点不一定都是循环。

有些节点可能包含完整的 Agent Loop，有些节点只是一次确定性的程序执行，还有些节点只是等待人工确认。

2. 边

边决定任务如何流转，例如：

• 测试通过后进入代码审查；

• 测试失败后返回编码节点；

• 高风险变更转交人工审批；

• 多个研究 Agent 并行执行；

• 多个结果汇总后交给评审 Agent。

3. 状态

状态是节点之间传递的数据，例如：

• 当前任务目标；

• 已修改的文件；

• 测试结果；

• 错误信息；

• 风险等级；

• 已消耗的 Token；

• 当前重试次数；

• 人工审批结果。

因此，Graph Engineering 的核心并不只是“使用多个 Agent”，而是设计：节点、路由、共享状态、并发关系和恢复机制。

四、Graph Engineering 这个名字很新，但图编排早已存在

Graph Engineering 在 2026 年 7 月突然成为热词，但图结构的 Agent 编排并不是新发明。

•LangGraph在 2024 年发布时，就明确提出使用“可循环图”构建 Agent Runtime，并把节点、边和共享状态作为核心抽象。目前的 LangGraph 仍将自己定位为长时间运行、有状态 Agent 的底层编排框架，可以在同一张图中同时组合确定性程序和由模型驱动的 Agent 步骤。

•Microsoft Agent Framework使用基于图的 Workflow，在节点之间进行类型化的数据路由，并支持分支、并行、检查点和人工参与。

•Google ADK也已经提供顺序、并行、循环和图工作流。其图工作流可以同时编排 Agent 和普通执行节点，并通过边控制执行路径。

这说明所谓 Graph Engineering，更像是给一类已经存在多年的 Agent 编排实践补上了一个统一名称。

甚至已经出现尝试为“Prompt Graph Engineering”建立更严格的定义，提出显式结构、提示内容与结构分离、可执行语义，以及把图作为一等工程产物等条件，不过当前这仍不能代表行业已经形成正式标准。

所以，当前更稳妥的判断是：

Graph Engineering 是一个正在形成的工程术语，而不是一种刚刚被发明的技术架构。

五、Loop 和 Graph 不是替代关系

把 Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering 和 Graph Engineering 排成一条替代链，其实并不准确。

它们更像是系统中的不同层次。

•Prompt Engineering：定义一次模型调用应该如何理解和完成任务。

•Context Engineering：决定模型在当前步骤能够看到哪些信息，包括文档、记忆、工具结果和历史状态。

•Harness Engineering：为模型提供工具、文件系统、沙箱、权限、记忆、日志和执行环境。

•Loop Engineering：定义任务如何反复执行、验证、修复以及停止。

•Graph Engineering：定义多个 Agent、循环、程序节点和人工节点之间如何协作。

这些层次不会互相消灭。

一个 Graph 节点内部仍然需要 Prompt，一个 Agent 仍然需要 Context，一个 Loop 仍然运行在 Harness 中，而整个系统可能又被组织成一张 Graph。

所以更合理的关系是：

Prompt 决定一次调用怎么做，Context 决定它知道什么，Harness 决定它能做什么，Loop 决定它如何持续改进，Graph 决定多个执行单元如何协作。

六、真正的工程分水岭不是“循环还是图”，而是验证

无论使用 Loop 还是 Graph，最容易被忽略的问题都是：

Agent 凭什么认为任务已经完成？

很多 Agent 系统的停止条件，本质上仍然是模型输出一句“任务已完成”。

但模型的陈述并不等于事实。

• 一个编码 Agent 说“测试已经通过”，不代表测试真的执行了；

• 一个订单 Agent 说“退款已经成功”，不代表数据库里真的存在退款记录；

• 一个安全审查 Agent 说“没有发现风险”，也不代表代码不存在漏洞。

因此，可靠的 Loop 必须有独立于模型自我判断的验证器，例如：

• 自动化测试结果；

• 编译状态；

• 静态代码检查；

• 数据库真实状态；

• 接口返回值；

• 页面截图对比；

• 安全扫描结果；

• 明确的人工审批记录。

Addy Osmani 在后续文章中把这一点概括为：Agent 负责调查、实现和验证，而是否进入下一生命周期阶段，应由外部证据和边界上的决策者控制。

近期的Proof-or-Stop预印本进一步提出“基于证据门禁的生命周期控制”：reviewed、tested 和 DONE 等状态不能只由 Agent 声明，而必须由可追踪、可机械验证的证据支持。作者同时也承认，其实验仍局限于特定模型和任务范围。

这对测试人员尤其重要。

未来 Agent 系统中，测试的重点可能不只是检查最终代码，而是定义：

• 什么证据代表任务完成；

• 哪些状态允许流转；

• 失败后回到哪个节点；

• 哪些测试不能由生成代码的 Agent 自己执行；

• 哪些高风险操作必须由人确认。

从这个角度看，测试不再只是 Graph 末尾的一个节点，而是控制整个 Agent 系统能否继续运行的门禁。

七、什么时候用 Loop，什么时候用 Graph？

可以用一个简单原则判断。

适合 Loop 的场景：

• 修改一个明确的 Bug；

• 持续运行测试并修复失败；

• 根据检查结果反复优化文档；

• 定期扫描仓库并处理简单问题。

适合 Graph 的场景：

• 需求分析、开发、测试、安全审查组成的完整流水线；

• 多个研究 Agent 并行搜索，再统一汇总；

• 根据风险等级进入不同审批路径；

• 多个 Agent 使用不同权限和独立上下文；

• 任务需要中断恢复、人工介入和状态追踪。

还有一个经常被忽略的选项：既不用 Loop，也不用 Graph。

当任务规则完全明确、结果可以由普通程序计算时，一个普通函数、定时任务或固定工作流，往往比 Agent 更便宜、更稳定，也更容易测试。

八、Graph 并不天然比 Loop 更高级

Loop 的主要风险：

• 无限重试；

• Token 消耗失控；

• 模型不断重复同一种错误；

• 使用过期状态；

• 自己生成、自己验收；

• 停止条件模糊。

Graph 在此基础上还会增加新的问题：

• 节点之间状态不一致；

• 路由条件错误；

• 上下文在节点传递时丢失；

• 并行节点修改同一资源；

• 某个节点失败导致整条链路阻塞；

• 调试时难以还原完整执行路径；

• 延迟和调用成本迅速上升。

所以 Graph Engineering 并不是 Loop Engineering 的“高级版本”。

它只是用更高的系统复杂度，换取角色隔离、并行执行、显式控制流和更精细的治理能力。

当一个循环已经能够稳定解决问题时，强行拆成多个 Agent，并不会让系统自动变好。

很多时候，它只会把一个容易理解的失败，变成一张图里难以定位的失败。

九、不要把 Graph Engineering 和 GraphRAG 混为一谈

这两个概念虽然都包含 Graph，但解决的问题完全不同。

•Graph Engineering中的 Graph 是控制流图，描述任务先执行什么、后执行什么、在哪里分支、如何并行以及失败后返回哪里。

•GraphRAG中的 Graph 通常是知识图谱，用于从文档中提取实体和关系，并利用这些结构改进检索与回答。

简单来说：

• Graph Engineering 管的是 Agent 怎么工作；

• GraphRAG 管的是 Agent 从哪里检索知识。

一个 Agent Graph 可以调用 GraphRAG，但它们不是同一种技术。

“Loop Engineering 已死，Graph Engineering 上位”更像是一场社交媒体制造出来的概念接力。

•Loop Engineering真正解决的是：如何让一个 Agent 在明确目标、工具、验证器和停止条件的约束下持续工作。

•Graph Engineering真正解决的是：如何把多个 Agent、程序步骤、人工节点和循环组织成一个可控制、可恢复、可观察的系统。

它们不是前后两代技术，而是两个不同尺度的设计问题：

Loop 设计局部执行机制，Graph 设计全局协作拓扑。

未来较为可靠的 Agent 系统，很可能呈现这样的结构：

外层是确定、可观察的工作流图，内层是受到预算和停止条件约束的 Agent 循环，节点边界则由测试、证据和人工审批控制。

真正值得工程团队投入时间的，也不是追逐下一个新名词，而是回答几个更具体的问题：

• 系统的成功标准能否被执行和验证？

• Agent 失败后能否从正确位置恢复？

• 状态是否明确、可追踪、可审计？

• 每个节点获得的权限是否最小化？

• 增加一个 Agent，带来的收益是否大于复杂度和成本？

Loop Engineering 没死。

Graph Engineering 也没有突然登基。

真正发生的变化，是 AI Agent 开始从一个“能够自己调用工具的模型”，逐渐变成一个需要状态管理、验证门禁、权限控制、故障恢复和系统编排的软件系统。

而这一次，工程的重点终于从“怎样写一句更好的提示词”，转向了“怎样设计一个可以被信任的控制系统”。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】