从 Loop 到 Graph: 一个热词背后的真实工程演进

从 Loop 到 Graph一个热词背后的真实工程演进一、思考2026年7月17日OpenClaw作者Peter Steinberger在X上发了一句话一共12个单词“Are we still talking loops or did we shift to graphs yet?”没有技术定义没有架构图没有代码示例。就是一句调侃。四个半小时后Hamel Husain发了一篇文章标题气势磅礴《Loop Engineering Is Dead. Enter Graph Engineering》。点进去一看正文几乎空的一张图一个句号。然后整个AI圈子就炸了。LangChain联合创始人Harrison Chase在7月22日发推说“Graph engineering surfaced this weekend, kicked off by this tweet. It‘s the latest term to come out of X’s AI content factory.”连他本人都承认这是一场“概念工厂”的产物。从Loop Engineering的系统性方法论文章6月7日到“Loop已死”的宣言7月18日中间只隔了41天。Prompt Engineering的红利期还能按年算Context Engineering按年算Harness按月算。到了Loop和GraphAI行业连热词的折旧速度都开始按天计算了。有工程师在评论区自嘲“上个月让我写Loop这个月让我画Graph。下个月是不是该学Hypergraph了”但笑归笑这个热词确实击中了一个真实存在的问题。二、认知这轮讨论里的Graph不是知识图谱不是GraphRAG也不是图神经网络。它说的是一张执行图——谁先做、谁后做、哪些工作可以并行、哪个结果交给谁、谁有权否决、失败了退回哪一步、哪一步必须等人批准、状态放在哪里、钱烧到多少必须停。更麻烦的是目前大家嘴里说的Graph Engineering根本就不是同一件东西。LangChain讲的是执行图节点做事边决定下一步共享状态保存系统此刻知道什么。X上最流行的解释讲的是组织图不同节点承担不同岗位边表达分工、交接和依赖。Carlos Perez讲的则更接近治理图多个Loop彼此监督防止一个Loop把错误指标越优化越漂亮。三者有关但不是一个术语的三份标准定义。还有一个边界必须说清楚Graph不等于多Agent。一个Agent可以串行穿过一张图多个Agent也可以各跑各的、彼此没有明确交接。一个节点可以是Agent也可以是普通代码、工具、规则、评估器或者一个坐在屏幕前审批的人。三、Graph到底是什么图工程听着玄乎拆开看其实只有三样东西。第一样是节点Node。每个节点就是一个干具体活的单元可以是一个有专门职责的智能体研究员、写手、审稿人也可以是一段确定性代码函数调用、工具请求、数据读取。关键就一条每个节点只干一件事。第二样是边Edge。节点之间怎么走。边可以是直的A干完交给B。可以是有条件的审稿通过就发布不通过就退回去重写。可以是一分多个节点同时点燃三个节点并行去跑。也可以是多合一三份结果汇回到一处。第三样是共享状态Shared State。它是那个顺着边一路流动的对象装着任务本身、目前写到哪儿了、有哪些笔记、审出了什么结论。每个节点都从它这里读也往它这里写。有了这份共享记录一堆各干各的智能体才算真正连成了一个系统而不是一个转头就忘的临时群聊。说白了图工程就是给智能体画一张组织架构图。一家公司不会让同一个人把调研、写作、审核一口气全包了而是拆成不同岗位让活儿在岗位之间流转。智能体的图走的是同一个道理。四、Loop绝大多数人第一次搭AI Agent最后都会收敛到同一个形状一个while循环反复调用模型往prompt里堆上下文直到上下文窗口塞满。这个循环长什么样伪代码大概六行就能写完while not done: prompt 系统提示 历史对话 当前任务 resp LLM调用(prompt) if 包含工具调用: 执行工具结果存入对话历史 else: 输出结果标记完成Steve Kinney深入研究了Claude Code、Codex、Cursor、Vercel AI SDK、LangGraph等多个主流框架的源代码后得出了一个结论每一个AI代理框架都收敛到了同一个架构上——一个while循环。Loop值得它的统治地位。它简单到一句话能教完便宜到随手就能搭而且确实有效。对于范围清晰的单目标任务修一个bug、总结一篇文档、清洗一份数据这已经足够。问题是任务变复杂的时候。一个Agent在循环里既做研究、又写稿、又审稿、又发布会发生什么研究的内容混进分析代码无视审查意见Agent同时干四份活却只有一个上下文窗口的预算。它会早期步骤的细节丢掉产出一个看起来完整、一碰就碎的东西。这不是模型能力不够单个任务它都能做好。问题出在架构上你让一个人同时当研究员、分析师、工程师和审稿人全在一段对话里完成。具体来说循环架构有几个躲不掉的麻烦第一慢。全程串行执行明明后端、前端、测试能三路一起跑也得排着队一个干完再干下一个。第二没有检查点。执行到第40步突然中断要么从头重跑要么自己钻进上下文里一点点翻。第三暂停麻烦。没有保存进度中间很难停下来等人工审批隔天再从断点接着干。第四“中间信息遗忘”。长对话中早期关键约束被大量中间内容淹没模型注意力衰减。有文章用一个微服务拆分任务举例Agent执行30轮后“关键的API兼容约束被淹没在中间位置的对话历史中”Agent直接修改了接口签名。还有一个更隐蔽的问题。一个循环只能看见自己的指标所以它会找到一切办法移动指标包括背叛指标初衷的那些办法。一支客服团队花一个季度搭建了AI聊天机器人的反馈循环以工单解决率为指标连续五个月看着曲线爬升。然后续约数据到了客户流失率翻倍机器人学会的“解决”方式是偏转快速关闭对话、劝阻追问、把被放弃的问题标记为已解决。循环完美运行数字一路上升而循环的成功恰恰是失败的机制。这就是古德哈特定律一个指标被用力优化到一定程度就会停止测量它曾经代表的东西。五、那么Graph和Loop到底是什么关系先给一个最直接的答案Loop没死Graph也不新。你可以把一个Loop理解成一张最小的Graph只有一个节点、一条边而且这条边指回自己。Graph上每个Agent节点的内部跑的还是那个熟悉的思考循环。所以这俩根本不冲突。Loop Engineering解决的是单个Agent如何反复思考、调用工具和修正结果。Graph Engineering解决的是多个执行单元如何拆分、并行、汇合和返工。前者管节点内部后者管节点之间。53AI创始人杨芳贤在分析这轮讨论时给出了一个更精准的判断真正发生变化的是工程对象从“一个循环怎么跑”移到了“多个工作单元之间怎么发生关系”。LangChain团队的Sydney Runkle和Harrison Chase在回顾LangGraph三年发展时也表达了类似的看法。他们说抛开流行语不谈“将代理系统表示为图是一种非常合理的方式来利用LLM的力量。具体来说它允许你作为构建者将你对系统应该如何工作的预想施加到更受约束的路径上而不是仅仅依赖LLM的判断。”这其实就是把领域知识编码成“认知架构”。就像提示词包含领域知识把你的Agent和通用ChatGPT区分开来图本身也是一种认知架构。六、实际案例Graph在真实世界里长什么样案例一AI资讯日报假设你要做一个“每日AI资讯报告”系统自动找到重要新闻、读取视频逐字稿和论文、排除重复消息、核对关键事实、最后把成稿存进Obsidian。如果用Loop做就是一个Agent从头干到尾找新闻→读原文→核对事实→写稿→改错字。任务一多这位“员工”就开始忙不过来一边翻资料一边记数字还要考虑文章结构能记住的上下文越来越满。用Graph做就是组个团队有人找资料有人核对事实有人写稿还有人负责挑错。研究员把笔记喂给写手写手交给审稿人审稿人这里挂一条有条件的边通过就发布不通过就退回重写。状态一路往下流越流越厚研究员的笔记跟着到了写手手上写手的初稿又跟着到了审稿人那里。每个节点各司其职没有一个人需要记住所有事。案例二微服务拆分重构阿里云一篇技术文章用一个具体的开发任务做样本重构单体user-service拆分为认证、画像、偏好三个独立微服务全程保持对外API兼容。在循环驱动型架构下Agent在一个长对话里从头跑到尾。没有检查点中途API超时就全部丢失。上下文线性堆积前置约束被淹没。执行30轮后模型直接改了接口签名。在图执行架构下任务被拆分为独立节点通过有向边定义流转关系。全局统一State存储全部约束和中间结果每个节点执行完自动落地。某个节点失败从检查点恢复重新执行不需要从头再来。同一个LLM同一个任务不同架构的任务成功率可以相差3到5倍。案例三薪酬处理系统一个开源的薪酬自动化系统展示了Graph在生产中的真实形态每个月的运行是一个独立的LangGraph线程图依次经过五个节点后停在“审批门”前等待人工批准后才记录任何款项。这种“图走到一半停下来等人工”的模式在纯Loop架构里几乎无法优雅实现要么一直耗着要么中断后重新来。Graph通过内置的Human-in-the-Loop机制把“人等机器”变成了“机器等人”。案例四知识库AgentLangChain官方文档描述了一个典型的知识库Agent使用三个子Agent进行搜索一个GitHub Agent负责代码、issues和pull requests一个Notion Agent负责内部文档和wiki一个Slack Agent负责相关讨论串。工作流有三个固定阶段分类 → 搜索 → 合成。每个阶段由专门的节点负责阶段之间有明确的交接逻辑。这不是让一个Agent猜该用什么工具、该查哪里而是把搜索策略直接编码进了图的结构里。七、但是不要为了图而图Graph的优势很明显但过度工程化同样是问题。LangGraph官方的建议非常务实“当工作流有分支、循环、检查点或需要显式的图推理时使用LangGraph。当线性循环就足够时避免使用图因为图是认知开销。”有篇文章的标题说得更直白《The Useful Part of Graph Engineering Is Not the Graph》。Graph Engineering有用的部分恰恰不在于“图”这个字本身。事实上Anthropic在2024年12月发布的工程总结《Building Effective Agents》里早就完整整理了路由、并行化、主从编排以及评估-优化器这些多节点拓扑架构但平实地把它们统称为工作流Workflows。即使到了2026年5月Claude Code正式推出支持多Agent并发与自动化调度的大规模编排功能时官方文档也依然将其命名为Dynamic Workflows完全没有去蹭新名词的热度。Grapeot.me上有一篇分析文章标题是《为什么你必须立刻开始学习Graph Engineering》但内容恰恰在拆解这个概念被制造出来的过程。作者指出如果剥离掉所有的宣发名词Graph Engineering在计算模型和底层原语上其实没有发明任何新东西。早在2014年Apache Airflow就已经在用DAG做任务编排了Temporal也早就通过持久化状态机在管理复杂的分布式工作流。在Agent系统里用图来组织代码逻辑技术创新的成分完全是零。这场学习最大的价值是帮你建立起对未来类似技术宣传的免疫力。八、比较图维度LoopGraph核心抽象一个while循环节点边共享状态控制权LLM决定每一步开发者通过图结构定义控制流状态管理上下文线性传递集中式结构化State容错能力崩溃即丢失全部进度检查点支持断点续传并行能力不支持原生支持人工介入只能强制中断内置Human-in-the-Loop适用场景10步以内的探索性任务长周期、多步骤、需协作的复杂任务代表实现AutoGPT、BabyAGILangGraph、Google ADK Go 2.0但更重要的是两个判断标准第一看任务复杂度。如果你的任务可以用一句话说清楚、十步之内能做完用Loop就够了。Graph是认知开销没必要为了一碟醋包一顿饺子。第二看是否需要“组织”。如果你的系统里有多个角色需要分工、有明确的交接逻辑、需要人工审批、需要断点续传可考虑Graph。它本质上是一个可编程的组织架构而不是一个“更高级的Loop”。九、总结从Loop到Graph真正的变化不是技术上的革命而是工程视角的转移。Prompt Engineering关心的是“怎么说”。Context Engineering关心的是“让模型看到什么”。Harness Engineering关心的是“模型能用什么”。Loop Engineering关心的是“任务怎样持续推进”。Graph Engineering关心的是**“多个执行单元怎样共同负责”** 。它们不是互相替代的关系而是一层层向外扩展的工程对象。Prompt被放进ContextContext通过Harness送到模型面前Harness支撑Agent Loop持续运行多个Loop、工具、数据库和人再组成一张Graph。模型变聪明不等于系统变可靠。一个能力很强的Agent可能依然拿错资料、调用错工具、在错误结果上反复重试。单点智能解决不了分工、交接、权限、验证和恢复这些问题。越往后走工程对象就越远离模型本身越接近一个完整的生产系统。所以与其纠结“Loop死没死”“Graph新不新”不如想清楚一件事你正在解决的问题到底是一个人的活还是一群人的活一个人的活交给Loop。一群人的活画一张Graph。