Loop Engineering 这次“死”得有点快哦。6 月 7 日Addy Osmani 发布了一篇系统介绍 Loop Engineering 的文章不要再由人一轮轮提示 Agent而是设计一个能够发现任务、分发任务、检查结果、记录状态并决定下一步的系统。7 月 18 日Peter Steinberger 在 X 上问了一句“我们还在讨论 Loop还是已经转向 Graph 了”几个小时后Hamel Husain 直接发出了“讣告”“Loop Engineering Is Dead. Enter Graph Engineering.”随后一两天课程、路线图、工具栈和解释文章就都冒出来了。从 Addy 的文章发布到 Loop Engineering 被宣告“死亡”一共 41 天距离整六周只差一天。这个速度放在传统软件工程里可能连一个版本的灰度周期都走不完。来扯个犊子Loop Engineering 还没死Graph Engineering 也不是突然被发明出来的新大陆。它只是说明 AI Agent 的工程关注点又从一个闭环扩展到了多个闭环之间的协作而已。Loop 解决局部任务如何持续收敛Graph 解决多个任务、多个 Agent、多个验证器之间如何分工、并行、交接和回退。图里本来就可以有环。所以 Graph 不是把 Loop 拍死在沙滩上而是把它放进了更大的协作结构里。一、这场“Loop 已死”的舆论到底在说什么咱首先得把大佬的传播话术和真实技术变化分开。“Loop Engineering Is Dead”是一个有很强传播性的标题。Peter 和 Hamel 的原帖更像两个行业梗后续讨论才迅速把 Graph Engineering 包装成一套新说法。它抓住了 AI 圈一个典型的命名节奏Prompt Engineering 还没学明白Context Engineering 来了Context 还没治理好Harness Engineering 来了Harness 刚开始落地Loop Engineering 又来了Loop 才热了六周Graph Engineering 已经站在门口敲钟了。但这次舆论背后也确实有一个真实问题单个 Agent 的长任务能力在变强。我们已经能让它读取上下文、调用工具、修改代码、运行测试根据失败结果继续修直到成功或者触发停止条件。这就是一个 Loop。可一旦我们同时跑多个 Agent问题马上变了•谁负责规划谁负责实现谁负责验证•哪些任务可以并行哪些任务存在前后依赖•一个 Agent 的输出以什么格式交给下一个 Agent•安全审查和代码审查意见冲突时听谁的•一个分支失败是局部重试、整体回滚还是转人工•多条执行路径什么时候汇合谁来判断全局目标已经完成人虽然退出了局部执行循环却又变成了多个 Loop 之间的“人工路由器”开三个窗口、复制三份上下文、搬运结果、判断下一步、处理冲突。工作自动了协调其实还没有自动。Graph Engineering 的热度真正击中的就是这个新瓶颈。二、Graph Engineering 到底是什么目前这个词还没有一个公认的正式定义。有人把它理解为“多 Agent 工作流”有人强调“多个反馈闭环组成的网络”也有人把任务依赖图、评测图、权限图和人工审批都算进去。但有一说一把这些说法取一个最大公约数大概就是这样Graph Engineering 是把多个 Agent、确定性程序、工具、验证器和人工节点组织成一张显式的工作图并设计它们之间的状态传递、路由规则、并行关系、质量门和失败恢复。一张最小的 Agent 工作图应该有以下几类东西1.节点真正干活的单元。它可以是一个 Agent也可以是一段确定性代码、一次测试、一个审批人甚至是内部还带着 Loop 的完整子流程。2.边工作怎么流动。它不只是“把一段聊天转给下一个 Agent”还应该包含触发条件、输入输出契约和权限边界。3.状态系统当前知道什么、完成了什么、失败在哪里。状态必须存在于单次对话之外能够持久化、恢复和审计。4.路由根据结果决定下一步。通过就向前失败就回到局部节点高风险就转人工不确定就补充上下文。5.并行与汇合能拆开的任务同时做但在进入下一阶段前需要有明确的汇合条件和冲突处理规则。6.局部验证与全局目标每个节点要证明自己的输出合格整张图还要证明最终业务目标已经完成。7.预算和停止条件限制时间、token、重试次数、工具调用和影响范围防止一张图把“自动干活”变成“自动烧钱和自动制造事故”。举个软件研发中的简化例子。一个需求通过评审后规划 Agent 先把任务拆分。接口实现、前端适配、测试用例和安全分析可以部分并行。各自完成后集成节点汇总变更验证节点运行测试并核对验收标准。如果安全审查失败只把相关分支退回如果接口契约发生变化则重新触发受影响的上下游节点最后由人完成高风险发布审批。这里每个开发或审查 Agent 内部仍然可能运行自己的 Loop。Graph 负责的不是替代它而是决定这些小 Loop 如何连接。PS. Graph Engineering 不是 GraphRAG。GraphRAG 主要解决知识如何按实体和关系组织、检索与推理这里的 Graph 主要描述工作如何流动。三、Graph 不是新发明新的是节点开始变得不确定如果稍微看一下历史就会发现 Graph Engineering 的很多“新概念”软件行业早就在用了。构建系统用依赖图决定编译顺序CI/CD 用 DAG 编排任务工作流引擎用状态机处理分支和回退数据平台用有向图调度计算分布式系统用消息在节点之间传递状态。连 AI Agent 领域也不是 2026 年 7 月才开始画图。Anthropic 在 2024 年底介绍 Agent 系统时就已经把 prompt chaining、routing、parallelization、orchestrator-workers、evaluator-optimizer 画成了不同的工作流结构。LangGraph 更是直接用 State、Node 和 Edge 来表达长时间运行的 Agent 工作流。OpenAI 的 Agents SDK 也已经把 manager、agents as tools、handoff以及由代码或 LLM 负责 orchestration 做成基础模式。2025 年Anthropic 公开过其多 Agent Research 系统主 Agent 负责规划多个子 Agent 并行搜索最后再汇总和补充引用。在该内部 Research 评测中多 Agent 系统的表现比单 Agent 高 90.2%但与此同时多 Agent 系统消耗的 token 大约是普通聊天的 15 倍而且高度依赖共享上下文、难以并行的任务并不适合这种架构。Codex 增强的并行任务、subagent、worktree 和 automationClaude Code 通过 subagent、实验性的 agent team、worktree 等机制加强并行协作。OpenAI Agents SDK 中的 handoff 与 agents as tools则把跨 Agent 的委派和路由变成了基础模式。这些能力名称不同本质上都在把这种结构产品化。所以新的并不是“图”。真正的新变化是过去图中的节点大多是确定性程序现在越来越多节点变成了会推理、会调用工具、会改变计划、也会犯错的 Agent。这会带来三种传统工作流里没那么尖锐的问题。第一节点的输出不稳定。同样的输入两次执行可能走向不同结果。第二边的语义不再天然可靠。一个 Agent 说“已经完成”只是一个主张不是证据。第三图本身可能动态变化。规划 Agent 会临时拆出新任务、增加子 Agent、调整路线静态 DAG 不一定提前画得出来。因此 Graph Engineering 真正值得研究的不是怎么画一张更漂亮的图而是怎么让这张由不确定节点组成的图仍然可观察、可验证、可恢复、可接管。节点变聪明之后系统工程会变得更重要。——老登福音。四、从顺序控制、任务图到分布式协作来猜猜下一个会不会是 Protocol Engineering换一个更准确的观察角度从顺序控制流到任务依赖图再到分布式协作从单 Agent 到多 Agent从 Loop 到 Graph。后者从来不是把前者替换掉数组、链表、树、图解决的是不同形状的问题顺序、分支、循环、并行也一直同时存在。DAG 调度也没有让while循环消失。真正的发展是计算系统复杂度不断外扩的必经之路•单机顺序程序重点是下一条指令执行什么•复杂数据结构和计算图重点是谁依赖谁•并发与分布式系统重点变成多个节点如何在延迟、失败和状态不一致的情况下协作•大规模社会技术系统还要处理权限、信任、治理、成本和责任。所以沿着这条线推演让我来猜猜下一个“XXX Engineering”会不会是Protocol Engineering。市场传播上也许会再次把 Swarm Engineering 推到台前强调大量 Agent 动态组队、自主协作。但当大家真把它放进生产环境后最难的不会是再多加几个节点而是给节点之间建立协议这其实也是 Swarm 的核心。Graph 只告诉我们谁和谁相连。Protocol 才要解决•Agent 如何声明自己的能力、身份和权限•一个任务通过什么契约委派交付物必须带哪些证据•多个 Agent 对同一事实判断冲突时如何仲裁•消息重复、超时、乱序、丢失时如何保证幂等和恢复•一个节点失败后是重试、补偿、降级还是熔断•谁可以修改整张图谁只能在局部范围行动•token、时间和工具调用预算如何分配•哪些决策必须由人批准出了问题由谁解释和负责这和分布式系统的发展很像。当机器只有一台时我们主要关心算法。机器连成网络后拓扑当然重要但真正让互联网、数据库集群和微服务能够工作的是 TCP/IP、共识算法、消息协议、事务语义、超时重试、幂等和故障恢复。同样当 Agent 从一个变成一群图只是骨架协议才是神经和规则。所以我对下一阶段的推测不是“大家会开始画更大的图”而是大家会开始为 Agent 之间的协作定义可执行的契约并把权限、验证、冲突、成本和责任写进协议。名字未必真叫 Protocol Engineering。也可能叫 Policy Engineering、Governance Engineering 或 Agent Organization Engineering。名字嘛叫什么无所谓方向大概率不会错。五、Prompt、Context、Harness、Loop、Graph到底在递进什么那么再来温习下之前文章的内容Prompt Engineering控制一次表达解决“这次要对模型说什么”。它定义目标、约束、格式和判断标准。Context Engineering控制一次认知解决“模型这次能看到什么”。代码、PRD、日志、接口契约、历史决策、样例和失败记录都属于上下文。Harness Engineering控制一次行动解决“Agent 在什么环境里干活”。工具、权限、沙箱、Skill、hook、测试、文件系统、MCP、审批和观测都在这一层。Loop Engineering控制一段时间解决“Agent 如何根据反馈持续推进”。触发、执行、验证、重试、记忆、停止和人工升级组成一个局部闭环。Graph Engineering控制一个组织解决“多个工作单元如何形成结构”。分工、依赖、并行、路由、交接、汇合、局部回退和全局完成条件都属于图。Protocol Engineering控制协作秩序解决“这些节点如何在不完全可信、可能失败、动态变化的情况下共同工作”。契约、身份、权限、冲突、成本、审计和责任会成为重点。这几个概念不是一茬一茬替代而是一层一层向外扩。Prompt 和 Context 是 Harness 管理的输入Harness 支撑每一次 Loop多个 Loop 和确定性节点被组织成 GraphProtocol 与治理则约束这些结构如何跨 Agent、跨系统长期协作。它们递进的本质只有一句话我们控制的对象正在从模型的一次回答扩展为一个能够持续交付结果的复杂系统。每出现一个新词本质上都是因为上一个层次跑起来以后新的失控变量暴露了。Prompt 解决表达失控。Context 解决信息失控。Harness 解决行动失控。Loop 解决时间和反馈失控。Graph 解决依赖和协作失控。接下来就轮到权限、冲突、成本和责任失控了。六、怎样快速适应 AI 时代层出不穷的新名词新名词只会越来越多。模型厂商要讲差异工具公司要定义品类培训机构要卖路线图一个实践刚有点苗头很快就会被包装成一门新学科。还有大佬们要收学费。我们没必要排斥新词毕竟我们也可以拿着这些词去忽悠、去要资源。但别真把自己忽悠进去。看到新词我一般只做三步。1. 先找它在解决什么问题找原始文章、产品文档和真实案例不要从二手“全景路线图”开始。一个词如果说不清对应的失败场景大概率只是旧概念换了包装。2. 再翻译回成熟的软件工程Graph 可以翻译成工作流、状态机、DAG、消息传递和多 Agent 编排Loop 可以翻译成反馈控制、重试、评测和停止条件。翻译完再看它新增了哪个控制变量指令、上下文、工具、状态、反馈、依赖、权限还是成本没有新增量就没必要另立一门“学科”。最近不少新词本质上是成熟工程领域软件工程、机械工程、控制工程等的实践经验向 AI 场景迁移后的重新命名。所以去温习下以前经验、理论对我们理解AI的新概念很有帮助。3. 最后跑一个小场景自己有时间就跑没时间就看别人跑的效果和结果。最后的最后Loop Engineering 还没死。它只是从整套系统的主角变成了 Graph 里的局部结构。Graph Engineering 也不是 AI 时代突然发现了图算法而是当多个 Agent 真正开始并行工作后我们终于不得不正视协调、状态、交接和全局验证。再往下走市场可能会重新喊热 Swarm Engineering也可能把下一阶段叫作 Protocol Engineering 等新的“XXX Engineering”。叫什么并不重要。真正重要的是它是否暴露并解决了一个此前没有被控制住的 AI 工程问题。大炮也经历过从狂轰滥炸到精确制导。AI 系统从“能干活”走向“可控地交付结果”经历这段过程很正常。判断一个新词有没有价值不看名字有多新只看它有没有让 AI 交付变得更稳定、更可控。学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%免费】