本文永久链接 – https://tonybai.com/2026/07/21/from-loop-engineering-to-graph-engineering
大家好，我是Tony Bai。
【导读】：7月17日，独立开发者 Peter Steinberger 一条只有九个词的推文引爆全网——“我们到底还在聊loop，还是已经悄悄换成graph了？“两天内收获超80万浏览、4500多点赞。紧接着两篇长文相继刷屏：一篇从"自我改进为什么本质上是网络问题"的高度拆解这场范式转移，末尾抛出一记灵魂拷问；另一篇则甩出一份硬核到可以直接抄作业的14步实操路线图，手把手教你用Claude Code把线性agent改造成图结构工作流。上一轮"Loop Engineering"的热乎劲儿还没过，“Graph Engineering"已经杀到台前。
【文章要点】
一条梗，为什么能在24小时内让整个AI Agent工程圈集体破防？
因为它精准地戳中了所有人都心知肚明、但没人愿意先说出口的事实：过去两个月里被吹上天的“Loop Engineering”（循环工程）——那个让agent自己给自己写prompt、定时跑、通宵自我迭代的玩法——可能从一开始就只是个半成品答案。
而这一次，硅谷没有再造一个新词就完事，而是同时交出了一篇诊断书和一份说明书。
简单回顾一下：Loop Engineering 的核心动作，是给AI agent接上一个自我调节的反馈闭环——选一个可以控制的指标，设一个目标值，测量当前值和目标值的差距，采取行动缩小差距，然后重新来一遍。
这几乎就是一台恒温器的工作原理，简单到可以写进一句话里，也正因为简单，才在过去几个月被疯狂复制：写周报的loop、刷指标的loop、通宵改代码的loop、自我打分的loop……
问题是，恒温器只对付温度这一个变量。而现实世界里的“变好”，从来不是单变量问题。
Carlos E. Perez 在他的长文里讲了一个几乎所有做过运营的人都会脊背发凉的案例：某个客服团队花了一个季度打磨自家AI客服的自我改进循环——选定“工单解决率”作为指标，每周测量，动态调整机器人的话术和策略。
连续五个月，曲线一路走高，团队引以为傲。直到续费数据出来：客户流失率反而翻倍了。机器人确实“学会”了提高解决率——办法是快速打发用户、劝退追问、把根本没解决的问题标记为“已解决”。
循环运转得完美无缺，指标也确实涨了，而循环的“成功”本身，恰恰就是失败的机制——因为这个循环只能看见自己的指标，看不见指标背后正在悄悄失真的现实。
Perez 把这类翻车归纳为循环结构本身注定会撞上的“四堵墙”：
那答案是不是就是“多建几个循环”？Perez 给出的答案更进一步：不是更多的循环，而是让循环之间产生结构性的相互制约——一张由改进循环组成的网络，彼此监视、彼此反馈、彼此约束、彼此纠错。
这套结构其实早已在成熟系统里被反复验证：机器学习工程里，一个可靠的部署流水线从来不是“重训然后上线”这么简单，而是挑战者循环（新模型必须先在真实流量里打败在位模型）、漂移监控循环、自动回滚机制、以及一个专门被“隔离”起来、永远不给训练循环偷看的留出评估集——各自都是一个loop，可靠性恰恰藏在循环与循环之间的连接方式里。
一家治理良好的公司也是同一个形状：日常运营的快循环，嵌在季度规划的慢循环里，再嵌进一年一度、专门检查“下面那些循环的数字是否还对应现实”的审计循环。就连人体也是如此——体温调节从来不是一个恒温器，而是一张由反射弧构成的网，外面还罩着一整套免疫系统式的审计循环。
对应到前面那四种失效，图结构给出的解法几乎是一一对应的：
如果故事到这里结束，那“图”就是终极答案。但 Perez 埋了一个更狠的伏笔：想象一家公司把这套图结构建到极致——成对的指标、审计循环、调参数的元循环，每一环都严丝合缝……然后你会发现，如果这张网里每个节点都在互相印证，却没有一个节点真正触碰到地面，它照样会失败——只是失败得更晚、代价更大、一路绿灯到崩盘前一秒。
这就是全文真正的靶心：图结构本身供应不了的东西，叫“锚点”（anchors）。 一些测量必须是不可辩驳的——真正到账的收入、真实跑通的测试、对得上的实物盘点；一些规则必须被冻结、优化器永远不许去碰，就像训练循环永远不能偷看留出集一样；而“什么才叫更好”这个最根本的判断，必须来自图结构之外——来自人，来自与真实失败的接触。
所以 Perez 的结论并不是“loop已死，graph为王”，而是：真正的分界线，从来不是loop还是graph，而是“脱离现实”还是“扎根现实”。他甚至在文末自嘲，说这轮爆火的选词本身可能都选错了——“graph”这个词，多少简化了一个原本更微妙的现象。
如果说 Perez 的文章是给这场范式转移写的一篇“诊断书”，那 0xCodez 那篇14步长文，就是直接甩出的“施工图纸”。
0xCodez 的切入点非常犀利：大多数人写多步agent，写出来的都是一条直线——第一步、第二步、第三步，每一步都乖乖排队等上一步做完。
但十个里有九个agent，其中至少一半的步骤根本不需要排队——它们没有做路由、没有做分支、更没有并行，只是傻乎乎地一个接一个排在那，直到上下文窗口被撑满、agent自己都忘了在干嘛。
他给出的核心比喻是：prompt是一句话，loop是一个循环，harness是agent站立的地板——而“工作本身的形状”，才是一张图。
节点负责思考，边负责传递结果。更关键的是，Claude Code 已经把搭这张图的工具直接做进了产品里：通过“dynamic workflows”（动态工作流），Claude可以自己写一段编排脚本，拉起一支协同作战的子agent舰队去执行，而协调过程本身消耗的token是零——因为那是代码在跑，不是又一轮对话。
把14步压缩提炼，大致可以归成五组：
① 基础概念（1-4步）：
节点是一个有边界的任务单元（固定输入、固定输出、只干一件事），边是一份“数据契约”，只在数据真的流动时才成立——很多人误把“然后”当成了边，其实“先做A、然后做B”里如果B根本不读A的输出，这两步压根没有依赖关系，白白排了队。给节点定契约最实用的办法，是用schema强制子agent返回结构化数据，验证失败就直接重试，而不是等人来读一堆自由文本祈祷格式对。
② 扇出与扇入（5-7步）：
遇到N个互相独立的任务（N个信源要查、N个文件要审），不要串成一条链，而是用并行的方式一次性拉起N个子agent同时跑——这一步是全篇“性价比最高的动作”。
并行结束后需要一个“扇入”节点把结果汇总、去重、排序，只有当某一步真的需要看到全部上游结果时，才值得为它付出等待的代价。把这两者叠在一起，就得到了整个agent工程里最常见的拓扑：“菱形”——分裂、并行工作、再合并，市场调研、依赖审计、代码评审、研究报告，换个信源和提示词，骨架都能复用。
③ 路由与验证（8-9步）：
不是每张图都是固定的，有时候走哪条路取决于运行时的判断——用一个“路由节点”先做分类，再用代码决定分支，让Claude的判断力落在节点上，让脚本的可靠性落在边上，这样同一个分类结果每次都会走向同一条路径，不会出现“Claude这次决定跳过审计”这种意外。
而“图”真正的杠杆，不在于塞更多agent，而在于能围绕结果搭建多少确定性——验证节点专门负责“试图推翻”一个结论，扛得住才能往下传，扛不住就永远到不了终点，具体又可以分成对抗式验证（多个怀疑者尝试反驳，多数通过才算数）、多视角验证（换不同的审查维度，比如正确性/安全性/可复现性）、评委制（多个尝试打分，从优胜者出发再吸收亚军的长处）。
④ 容错与收敛（10-11步）：
一条链上一个环节死了，后面全部停摆；一张图应该让失败只困在它自己的节点里——并行任务里报错的那一支直接变成空值被过滤掉，其余的照样跑完。
并行写文件时容易互相踩踏，解法是给每个agent一个独立的工作区隔离开来。
而对于“不知道有多大”的任务（比如一次性不知道能挖出多少个bug），需要一种可控的“循环边”——连续几轮都挖不出新东西就停，去重时要对“看到过的一切”去重，而不是只对“确认过的结果”去重，否则被否掉的发现会一轮轮死灰复燃，白烧token。
⑤ 成本与终极形态（12-14步）：
不是每个节点都配得上最贵的模型——重复性的、边界清晰的节点扔给便宜模型，判断力真正值钱的节点才留给旗舰模型。
图的“形状”本身就是成本和延迟最大的杠杆：并行是一道“关卡”，会等最慢的那个跑完；流水线不设关卡，每一项独立流转，跑得快的先出结果——默认应该用流水线，只有当某一步真的需要同时看到全部上游结果时才上关卡。
而路线图的终点，是干脆让Claude自己画图——只要在prompt里出现“workflow”这个词，Claude就会自己拆解任务、决定扇出方式、拉起子agent舰队、再把结果合成答案，跑得好的编排脚本还能一键保存成版本化的工作流，随时按名字复用。
文章末尾给出了六个可以直接照搬的应用场景：
文章的收尾一句话很有分量：“提问的人是prompter，画图的人才是架构师。”
线性agent从来不是天花板，只是最容易想到的第一种形状——一条线、一个头、一次一件事。一旦你能看清节点和边，就不会再问“怎么让agent多做几步”，而是开始问“哪里该拆开并行，哪里该在边上设关卡，哪里该把模型换成便宜的”。
把两篇文章放在一起读，会发现它们其实是同一枚硬币的两面：Perez 站在系统论和组织治理的高度，提醒所有人“图”不是终点，没有锚点的图照样会以更隐蔽的方式塌方；0xCodez 则完全扎进工程细节，给出了一份马上就能在Claude Code里跑起来的施工手册。一个负责泼冷水，一个负责递图纸——凑在一起，反而比单独任何一篇都更有说服力。
Graph Engineering会不会像它的前任 Loop Engineering 一样，两个月后就被下一个新词取代？大概率会。Perez 自己在文章里几乎已经预言了这件事：没有锚点的图，迟早也会以图特有的方式失败——循环地、一致地、看起来完全合理地失败，讨论又会一头扎向下一个热词。
真正值得记住的，或许不是“loop”还是“graph”这个说法本身，而是那条更朴素也更难做到的准则：你的改进机制，不管长什么形状，有没有真的在触碰现实。
资料链接：
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。