这 TM 谁又来炫技了？Loop 还没玩明白，这 Graph Engineer 又是啥破玩意？
7 月 18 日OpenClaw 作者 Peter Steinberger 在 X 上问了一句大家还在聊 Loop还是已经转向 Graph 了两天后Codez 写了一篇很长的教程给出一条从零开始学习 Graph Engineering 的 14 步路线。我相信很多人的反应跟我一样Loop 还没玩明白怎么又开始画图了先补一句 Loop 是啥Loop 是让单个 Agent 反复自我检查、自我修正直到结果达标为止的机制——写完一遍、检查一遍不行就重来做到合格为止。下文会反复拿它当对照。图源Codez 原文所以这篇我不按 14 个名词逐一讲——那 14 步里出现的 Node、Edge、Schema、Router、Fan-out/Fan-in后面都会用大白话覆盖到。我换成一个普通人能听懂的说法Graph Engineering就是给一群 Agent 分工规定工作怎么交接、哪里检查、什么时候停。先记住这句话后面的图就没那么吓人了。先把 Agent 想成一个新员工假设你招了一个新员工让他每天给你写一份 AI 新闻简报。最简单的做法是把所有事都交给他找新闻、读原文、核对真假、挑重点、写文章、改错字。这就是大家熟悉的单 Agent。Prompt 相当于你给他的工作要求。Loop 相当于他写完检查发现不对再重做一直做到合格为止。简单任务做起来没问题但事情一多这位员工就开始忙不过来了。他需要一边翻资料一边记数字还要考虑文章结构能记住的上下文越来越满前面看过的东西也忘得越来越快。Graph Engineering 做了一件大家看上去应该都知道如何优化的事儿别让一个人干这么多事儿了组个团队。有人找资料有人核对事实有人写稿还有人负责挑错。分工明确最终促成一篇成稿落地。顺带澄清一个容易混淆的词图里出现的 Graph Reasoning和本文讲的 Graph Engineering 不是一回事。Graph Reasoning 偏向模型内部的推理结构Graph Engineering 偏向工程层面的多 Agent 编排。这篇文章讲的是后者。这张图看起来很复杂。其实下面那些小圆点、小方框大多都可以理解成不同员工和不同工作。Node 是员工Edge 是交接单Graph 里最重要的两个词是 Node 和 Edge。Node也就是节点。你可以把它理解成一个岗位资料员、翻译、事实核对员、作者、审稿人。Edge也就是边缘。它表示工作从谁手里交到谁手里以及交过去什么东西。这里有个特别容易踩的坑做事有先后顺序但不代表它们存在依赖关系。比如我让 Agent 总结这份文件然后查一下北京天气。天气查询根本不需要等待总结结束后方可执行而是两个任务可以同时开始。很多 Agent 慢就慢在这里。所有工作被写成 A → B → C → D前一个任务结束不了后一个任务绝不开始。再举个更直观的例子B 和 C 都只需要 A 提供的资料C 并不需要 B 的结果。那么 A 完成后就可以同时启动 B 和 C没必要让 C 排在 B 后面干等。所以Graph Engineering 最基础的能力是看清任务之间真正的依赖关系哪些任务需要等待哪些任务可以同时开工。任务可以并行以后问题就从谁等谁变成了结果怎么交给下一个 Agent。比如资料员 Agent 查完资料只交回来一大段文字。负责写作的 Agent 既找不到原文链接也分不清哪些是事实、哪些是结论只能自己再猜一遍。解决方法是给每次交接规定一个固定格式。比如资料员必须返回三项内容标题、原文链接、重要程度。少一项这次交接就不合格全部齐全之后写作 Agent 才继续工作。技术上这份格式规则叫作Schema。你可以把它理解成一张统一的交接单。现在再看 Node 和 Edge 就容易理解了Node 规定这个 Agent 负责什么Edge 规定它要把哪些数据交给谁。交接格式越清楚下一个 Agent 就越容易理解。所以多 Agent 真正难的是提前写清楚每一步的交付物、如何检查、出错后怎么办。如果这些规则没定好那么 Agent 数量越多造成的返工反而越多。最常用的图其实就是一颗菱形最常见的 Graph 形状并不复杂。先把任务拆分让几个人同时做做完之后再把结果收回来去重、筛选最后交给一个人统一出结果。就拿写这篇文章来举例子。一个 Agent 读 X 原文一个 Agent 查 Anthropic 官方文档另一个 Agent 看最近大家怎么讨论 Graph Engineering。三边可以同时开始。资料回来后先去掉重复内容再交给最终的拟稿人和审核人也就是我。所以我不用背着十几个网页工作我只需要拿到整理好的结果就行了。这就是 Fan-out 和 Fan-in。Fan-out 是把工作分出去Fan-in 是把结果收回来。两个动作连在一起就构成了下面这颗菱形形态。放到写文章这件事里就很好理解了先让几个 Agent 同时查资料再让程序自动去重、分类最后把整理好的材料交给一个 Agent由它形成最终结论。前面几个 Agent 已经同时找完资料程序也完成了去重和分类。但这些材料还不能直接拿来写文章因为它们可能引用了过期消息也可能把别人的转述当成官方结论。所以最后一个 Agent 拿到材料后需要先做一轮验收判断链接能不能打开数字和日期能不能对上不同来源有没有互相矛盾判断之后才能开始写。技术上这个负责挑错的角色叫Reviewer或Verifier。它的工作不是再写一份答案而是检查前面的答案能不能相信。但检查这件事并不是一个固定的动作力度也得看事情轻重。一个普通的观点让一个 Agent 快速核对就够了涉及重要数据、安全问题或产品结论时就要安排几个 Agent 从不同角度交叉检查。决定这件事该走哪条检查流程的角色叫Router。它像一个分诊台根据重要程度把任务引向不同的边。如果负责查资料的 Agent 说官方已经确认验证 Agent 就要找到官方原文如果只能找到媒体转述这条结论就要降级甚至退回去重新查。只有经得住检查的内容才会进入到文章中。如果 Agent 执行的不是查资料而是修改代码还要多做一步隔离给每个 Agent 一份独立的工作区。否则两个人同时改同一个文件后面保存的人可能直接盖掉前一个人的成果。如果检查发现问题后需要退回前面的 Agent 补资料的阶段然后再检查一次。这样就形成了一个循环。但是循环必须规定什么时候结束。比如连续两轮没有发现新问题就停止否则就像老板一直喊再查一遍Agent 会不停工作token 也会一直烧。整套流程说白了就是有人找资料有人整理资料还有人专门检查资料。检查不通过就退回重做通过之后才下最终结论。前面一直在说把任务分给多个 Agent但有件事不能忽略每启动一个 Agent它都要单独读取材料、思考并输出答案这些操作都会消耗 token。比如为了写一篇文章同时叫来十个最强模型查资料确实可能比一个模型查得更全面但也相当于花了十倍价钱请了十位专家。并行能节省等待时间却不会让这十个人免费工作。省钱的办法是别让所有工作都交给最贵的模型。提取标题、整理格式、简单分类可以让便宜的模型完成判断消息真假、处理冲突、形成最终结论再交给能力更强的模型。这就像一个编辑部整理资料不必总编辑亲自上真正需要拍板时再找他。除了选什么模型任务怎么排也会影响速度。比如十份资料要放在一起去重那就必须等十个 Agent 全部回来后再开始像开会一样人到齐了才能进入下一步。但如果每份资料可以单独处理就不用等所有人。第一份回来就先检查第一份第二份回来再处理第二份像流水线一样。所以设计一张 Agent Graph本质上还要算清三笔账启动多少个 Agent、每个 Agent 使用什么模型、哪些步骤必须互相等待。Graph 设计得好是用更少的钱更快地完成任务设计得不好只是让更多模型一起更快地烧 token。讲到这里你可能已经发现了一个问题Graph 确实能让多个 Agent 一起工作但这张图本身还是要有人设计。谁去查资料谁负责验证哪些任务可以同时开始哪一步必须等待最后由谁下结论——以前这些规则通常要开发者提前写好。Claude Code 的 Dynamic Workflows 想做的就是把这部分工作也交给 Claude。关于 Claude Dynamic Workflows 你可以阅读这篇文章。你只需要告诉它最终目标。Claude 会先分析任务再生成一段 JavaScript 编排脚本。还是以写文章为例它可以安排几个 Agent 分头查找原文、官方文档和外部讨论等资料回来后让程序去重再叫验证 Agent 检查来源最后交给写作 Agent 输出文章。在 Claude Code 里你可以直接要求它使用 Workflow也可以运行/deep-research。打开ultracode后Claude 还会先判断当前任务够不够复杂是否真的值得启动一组 Agent。图源Anthropic Dynamic Workflows 官方介绍这里有个很容易误解的说法编排脚本可以做到零模型 token。它真正的意思是分发任务、等待结果和合并数据这些管理动作由普通 JavaScript 完成不需要再调用一次模型。但真正出去干活的每个 Agent仍然会正常消耗 token。说白了排班表不拿工资不代表排班表里的员工也不用拿工资。截至 2026 年 7 月Claude 官方文档给出的上限是同时运行 16 个 Agent单次 Workflow 最多启动 1,000 个 Agent见 Claude Code Docs。这代表系统能承载多大的任务并不代表普通任务也应该把人数拉满。下面这张图就是原文最后组装出来的一套完整流程。第一眼看上去密密麻麻拆开后仍然是前面讲过的几件事先确定任务范围再分头查资料用固定格式交接用程序整理安排 Agent 验证最后形成结论整个过程还要控制停止条件和成本。Claude 现在可以自动生成这套流程但仍然要检查三个问题任务拆得是否合理该验证的地方有没有验证启动这么多 Agent 是否值得。也就是说我们不一定要亲手画出每个节点但仍然要判断 Claude 安排的这套分工能不能真正完成任务。看到这里小白不需要马上安装一个 Graph 框架更不用给每个任务都安排十几个 Agent。如果只是总结一份 PDF、修改一个标题交给一个 Agent 从头做到尾通常更快也更便宜。为了显得高级硬拆成一张图只会增加等待、交接和出错的机会。当任务开始出现下面这些情况时Graph 才真正有用有几块工作可以同时进行一个 Agent 已经看不过来结果必须经过独立检查整个过程会反复执行很多次。真要动手也可以从最简单的一步开始。先让一个 Agent 完成整个任务找到最慢或者最容易出错的环节再拆出一个可以并行的分支确实担心答案不可靠时再加一个验证 Agent。等流程稳定之后最后才考虑框架和自动编排。说到底Loop 解决的是一个 Agent 如何反复工作直到把事情做完Graph 解决的是多个 Agent 如何分工、交接、检查以及如何避免把 token 白白烧掉。Graph 不是重点Graph 里每一条箭头为什么存在才是 Graph Engineering 真正要解决的问题。学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%免费】
