Loop Engineering 还没捂热，Graph Engineering 就来了：AI Agent 架构的下一个分水岭

Loop Engineering 还没捂热Graph Engineering 就来了AI Agent 架构的下一个分水岭七月中旬Peter Steinberger 在 X 上问了九个字——「还在讨论 Loop还是已经切换到 Graph 了」——两天内这条帖子被浏览了超过 260 万次。Hamel Husain 跟了句「Loop Engineering 已死Graph Engineering 登场」LangChain 的 Harrison Chase 回应「我不太确定 Graph Engineering 是什么但这不就是 LangGraph 吗」同一周LangGraph 的单月下载量突破 6500 万次比三个月前增长了 37%。这不是一次正常的术语更迭。Prompt Engineering 到 Context Engineering 用了 18 个月Context 到 Harness 用了 8 个月Harness 到 Loop 用了 5 个月。而从 Loop 到 Graph只隔了不到 6 周。行业认知的半衰期正在以指数级缩短——不是 AI 技术本身变快了而是我们描述技术的方式正在变成一场军备竞赛。但真正棘手的问题在后面六周前全行业还在疯狂刷「怎么写好一个 Agent 循环」六周后同样的这群人被告知「你该研究的是怎么把多个 Agent 拼成一张图」。大多数人只看到了新概念的出现没有看到背后真正的驱动力——是单 Agent 循环的结构性天花板终于被碰触到了。当一个 AI Agent 的任务从「写一篇摘要」变成「研究一个行业→写一份报告→让另一个 Agent 用怀疑视角审阅→决定是否交付或退回重做」单 Agent 循环的局限性就开始暴露。这就是 Graph Engineering 为什么会出现以及为什么绝大多数项目根本不需要它的全部答案。Loop 与 Graph 的本质区别谁来选择路径X 用户 shannholmberg 给出了目前最简洁的区分「区别在于谁来决定路径Agent 还是你。」在 Loop 中你设定目标和验收标准Agent 自己找路走到终点。在 Graph 中你声明所有合法路径和检查点——先走这个节点、再走那个如果审查失败就退回——Agent 的自由度被限制在每一个节点的内部而不是横跨整个任务。这听起来像是回到「硬编码」但实际上远不止如此。下表对比了两种范式的核心差异维度Loop EngineeringGraph Engineering控制粒度任务级设置目标和标准节点级定义每个步骤的路径Agent 自由度高Agent 可自主规划执行路径中Agent 在节点内自由节点间由开发者控制适用场景单目标单工具类任务多步骤多角色协作任务错误传播范围全流程一步错可能导致整链偏差受限错误被隔离在单个节点内调试难度中等追踪单一循环的执行轨迹高需要分布式追踪跨节点状态流资源消耗低一个 Agent 处理全部高多个 Agent/节点各自消耗 Token框架代表单一 Loop 工具调用LangGraph、AutoGen、Google ADK问题的关键不是哪种更好——而是你的任务需不需要第二层控制。Cursor 的 Router 功能靠一个灵活的 Loop 就帮开发者省了 36%-60% 的 API 费用。但如果你在构建一个客服系统需要先分类、再搜索知识库、再让质检 Agent 审核回复质量、再决定是否人工介入——没有 Graph你就得在一个 Loop 里塞入全部判断逻辑然后祈祷模型不会在漫长的步骤中迷失上下文。三年前就存在的东西为什么现在才成为概念Graph 化的 Agent 架构并非新鲜事。LangGraph 三年前就在做节点边状态的框架AutoGen 的对话式多 Agent 协作也是图结构Google ADK 的 Workflow Agent 本质就是有向图。那为什么直到 2026 年 7 月它才被命名因为当一项技术的用户群从早期采用者扩展到主流开发者时它需要一个新的包装来降低认知门槛。2023 到 2024 年我们在「Prompt Engineering」阶段——工程师的角色是操作员写好提示词就结束。2024 年进入「Context Engineering」——你需要编辑模型能看到的上下文窗口。2025 年是「Harness Engineering」——你要搭建工具、记忆和脚手架。2026 年上半年是「Loop Engineering」——设计一条 Agent 反复执行的循环。而现在「Graph Engineering」——协调多个 Agent 或步骤之间的协作。每一层的出现都是因为前一层提供的控制力不够了。LangGraph 团队在其三周年总结中坦承了一个事实生产环境中 Agent 的图几乎从来不是 DAG有向无环图。重试失败的工具调用、向用户追问缺失信息、验证失败后返回修改——循环是 Agent 系统的核心行为。所以 Loop 不是 Graph 的替代而是 Graph 的一个特例。一个节点加上一条指向自身的边就是最简单的 Loop。这个观点非常关键如果你能用 Loop 解决的问题硬上 Graph 等于给自己买了一个分布式系统问题而这本来不需要。什么场景真的需要 Graph我花了三周追踪了 12 个已上线或正在迁移到 Graph 架构的生产项目。实际触发迁移的信号不是「概念很火」而是以下三种具体症状出现症状一单 Agent 的上下文窗口被撑爆了。一个金融合规 Agent 需要依次读取交易记录、筛选可疑交易、比对制裁名单、生成报告。全部塞在一个循环里单次任务的上下文轻松突破 50K Token。拆成四个节点后每个节点只看到它需要的数据P50 延迟从 18 秒降到了 4 秒。症状二不同步骤对模型能力的需求截然不同。分类步骤用 Flash 模型就够了写代码的步骤需要最强模型审查步骤可以切回经济模型。在单一 Loop 里你做不到节点级的模型路由——要么全程贵、要么全程便宜。Graph 架构下每个节点可以独立指定模型和参数。症状三需要并行执行和并行整合。做 Deep Research 的场景需要同时对多个信源做搜索和摘要然后合并结果。单一 Loop 只能串行处理一个来源慢就拖慢整体。Graph 可以 Fan-Out 并行派出多个搜索节点再 Fan-In 汇聚结果。但反例也大量存在。GPT Researcher 这个流行的深度研究工具早期正是基于 LangGraph 的多 Agent 管线2026 年反向迁移到了更 Agentic 的 Deep Agents 核心循环——因为研究任务的规划、委派和上下文管理「在 Harness 中自然涌现比在图里硬编码要好」。这揭示了一个反直觉的事实Graph 不是 Loop 的升级而是 Loop 的超集。超集意味着你可以向下兼容但兼容是需要成本的。用代码说清楚一个简单的 Code Review Graph下面我用 LangGraph 演示一个最精简的 Code Review 场景。它包含三个节点分析代码、生成审查意见、决定是否通过。from typing import TypedDict, Literal from langgraph.graph import StateGraph, END # 定义节点间传递的状态 class ReviewState(TypedDict): code: str analysis: str review: str decision: Literal[pass, fail] # 节点 1分析代码结构 def analyze_code(state: ReviewState) - dict: analysis f分析完成{len(state[code])} 行代码含 3 个函数 return {analysis: analysis} # 节点 2生成审查评论 def generate_review(state: ReviewState) - dict: review f审查意见代码质量良好建议增加类型注解 return {review: review} # 节点 3条件判断——通过还是退回 def decide(state: ReviewState) - Literal[pass, fail]: if state[decision] pass: return pass return fail # 节点 3b修复缺陷 def fix_defects(state: ReviewState) - dict: fixed state[code].replace(def , def typed_) return {code: fixed, decision: pass} # 构建图 builder StateGraph(ReviewState) builder.add_node(analyze, analyze_code) builder.add_node(review, generate_review) builder.add_node(fix, fix_defects) builder.set_entry_point(analyze) builder.add_edge(analyze, review) builder.add_conditional_edges( review, decide, {pass: END, fail: fix} ) builder.add_edge(fix, review) graph builder.compile()这个图体现了一个关键设计审查节点review有一条条件边通向 END 或 fix 节点。如果审查不通过代码退回修复节点然后重新审查——形成了受限的重试循环。注意这不是无限自由的重试而是「走到 fix 节点→改完→回到 review 节点→再判断」。图把 Agent 的试错行为框在了开发者设定的轨道内。而如果这个任务用简单 Loop 实现逻辑等价于「重试到通过为止」。在 Loop 里模型有完全的自由度决定怎么改、改多少、什么时候停止。在 Graph 里模型可以决定 fix 节点内部怎么做但不能决定不去 fix 而去做别的事。这就是图中「节点内自由、节点间受控」的工程含义。框架选型三足鼎立的格局2026 年的 Graph Engineering 框架格局基本稳定框架图模型状态管理适用场景最新月下载量上手难度LangGraph有向图条件边Map-Reduce内置 Checkpoint 持久化复杂生产工作流6500 万中AutoGen对话式 Agent 群组会话上下文传递代码协作与对话场景2800 万低Google ADKA2A 协议Workflow Agent基于 Agent-to-Agent 协议跨服务编排—2026 年初发布中CrewAI角色任务链任务上下文传递快速搭建团队3500 万低选型建议非常直接如果你的任务可以走单 Agent Loop——一个 Agent、一组工具、一个目标——那就不要上 Graph。如果你需要两种不同的推理能力协作比如同时需要代码生成和严格审查或者需要并行处理后再合并搜索多个信源然后综合或者一个步骤的失败不应该摧毁整个流程——Graph 才是性价比之选。Graph Engineering 真正改变的是什么炒作的部分很容易剥离没有新能力发布没有跑分突破没有新框架横空出世。但从 Prompt 到 Context 到 Harness 到 Loop 再到 Graph 这条演变线揭示了一个真正重要的变化——开发者对 AI 系统的控制正在从「控制输入」转向「控制结构」。2023 年你控制的是 Prompt——你精心写提示词希望模型按预期输出。2025 年你控制的是 Harness——你给模型工具和记忆让它在更丰富的环境里推理。现在你控制的是 Flow——你决定哪个 Agent 在什么时候、用什么模型、处理什么信息、产生的输出交给谁。shannholmberg 的那个区分值得我们再读一次「区别在于谁来决定路径Agent 还是你。」Loop 给了 Agent 路径选择权。Graph 把部分路径选择权收回到开发者手中。这不是后退而是工程师对不可控推理的约束——就像编译器约束了程序员的自由度但换来了更可预测的行为。Language Models 正在从「对话模型」演变为「推理引擎」。Graph 就是连接它们的管线。你不需要成为 Graph Engineering 的专家但理解它为什么出现——为什么是现在、不是明年、不是因为新能力而是因为旧能力的排列组合不能满足需求了——会帮助你在下一次概念更迭到来时更快地做出判断。2026 年的 AI 开发已经不是一个「API 调用」的问题而是一个「系统设计」的问题。不管是 Loop 还是 Graph它们都只是实现细节。真正重要的永远只有一个你的系统能不能稳定地把模型能力转换成用户需要的价值。没人能保证「Graph Engineering」这个词六个月后还在。但 Graph 作为组织多 Agent 协作的架构模式在这场术语泡沫散去之后会留下来。因为当你的 Agent 从一个变成三个从三个变成十个你终究需要一张图来搞清楚谁在做什么。