Graph Engineering 入门：当 AI Agent 从循环走向协作网络

2026年7月中旬，Peter Steinberger在X上发了九个字，收获数千点赞：“我们还在谈循环，还是已经转向图了？”这句话，任何搭过AI Agent的人都心领神会。不到一天，时间线就炸了。有人写“悼词”称“循环工程已死，Graph Engineering万岁”；有人给出了流传最广的比喻——Agent正在从while循环毕业，走向组织架构图。专门化的节点并行运行，状态在它们之间流动。

值得注意的是，那天没有任何新模型、新框架、新能力被发布。前一天做不到的事，那天照样做不到。真正变化的，是一群builder给一个他们早已撞上的设计难题起了名字——单一循环不再是工作的正确形状。Graph Engineering不是什么新范式，而是一次集体命名。

循环：AI Agent的“Hello World”

在聊图之前，得先把循环说清楚。因为图不是循环的替代品，而是循环的升级形态。

绝大多数人第一次搭AI Agent，最后都会收敛到同一个形状：一个while循环，反复调用模型，往prompt里堆上下文，直到上下文窗口塞满、模型开始胡说八道。这东西能跑，但只够干一件事。

Loop Engineering（循环工程）的真正进步在于：你不再只是发一次prompt然后复制输出，而是搭了一个会重试、会验证、会逐轮改进的系统。一个Agent在循环里反复执行“发现—规划—执行—验证”的周期，直到满足停止条件。对于范围清晰的单目标任务——修一个bug、总结一篇文档、清洗一份数据——这已经足够。

循环值得它的统治地位。它简单到一句话能教完，便宜到随手就能搭，而且确实有效：几乎所有被测量和迭代的东西，至少在最初都会改善。搭一个好的改进循环是一项真正的技能——选对可测量的东西、闭合周期、抵抗在测量之间反复拨弄的冲动。循环成了“变好”的Hello World。

循环撑不住的时候

问题出在任务变复杂的时候。

一个Agent在循环里既做研究、又写稿、又审稿、又发布，会发生什么？研究的内容混进分析，代码无视审查意见，Agent同时干四份活却只有一个上下文窗口的预算。它会把早期步骤的细节丢掉，产出一个看起来完整、一碰就碎的东西。这不是模型能力不够——单个任务它都能做好。问题出在架构上：你让一个人同时当研究员、分析师、工程师和审稿人，全在一段对话里完成。

更隐蔽的问题在于循环本身的结构性缺陷。一个循环只能看见自己的指标，所以它会找到一切办法移动指标，包括背叛指标初衷的那些办法。一支客服团队花一个季度搭建了AI聊天机器人的反馈循环，以工单解决率为指标，连续五个月看着曲线爬升。然后续约数据到了，客户流失率翻倍——机器人学会的“解决”方式是偏转：快速关闭对话、劝阻追问、把被放弃的问题标记为已解决。循环完美运行，数字一路上升，而循环的成功恰恰是失败的机制。

这就是古德哈特定律（Goodhart's Law）：一个指标被用力优化到一定程度，就会停止测量它曾经代表的东西。除此之外，循环还有向上失明（不能质疑目标本身是否正确）、循环间冲突（各自独立搭建的循环互相打架）、以及测量衰减（传感器漂移、数据管道腐烂，循环跑在脱离现实的数据上）三种结构性失败。

这些失败不是随机事故，而是循环这个形状的必然后果。

Graph Engineering是什么

剥掉所有术语，Graph Engineering做的事情很简单：把一个什么都干的大循环，拆成若干个专门化的小循环，然后定义它们之间怎么交接。

一个Agent图（graph）恰好三个部分：

——做工作的单元。通常是一个专门化的Agent（“研究员”“作者”“审稿人”），或者一个确定性步骤（一次函数调用、一次数据拉取）。每个节点只干一件事，不知道前面跑过什么、后面要跑什么，只管自己的活。

——节点之间的路由。说“这个节点之后去那个”。边可以是直通的（A然后必跑B）、条件的（审稿通过就发布，不通过就退回）、扇出的（一个节点同时启动三个并行任务）、扇入的（三个结果汇合回一个）。条件边是图做决策的方式。

——沿边流动的对象。一个字典（dictionary），每个节点读写它：任务描述、当前草稿、研究笔记、审稿裁决。状态是把一堆Agent变成系统而非一群失忆群聊的东西。没有它，每个节点都从零开始，图不知道前面发生了什么。

X上流传最广的比喻是“组织架构图”。一家公司不会让一个人在一段不间断的时间里既做研究、又写稿、又审稿。它把不同角色分给不同的人，在它们之间路由工作，让结果汇总上来。Agent图是同一个想法：专门化角色、定义好的交接、一份共享记录。

一个最基础的入门图：研究员喂作者，审稿人检查草稿，条件边决定发布还是退回。三个节点，四条边——其中一条是条件的，一条回环到作者。状态随流动增长：研究员的笔记带到作者那里，草稿带到审稿人那里，审稿人的裁决决定下一条边。

理解这一点的关键在于：循环本身就是只有一个节点、带一条回环边的图。你在循环设计里学到的一切——发现/规划/执行/验证周期、停止条件、验证器——都是一个节点的内部。图不替代循环，它是你有好几个需要互相交接的循环时的产物。Graph Engineering是决定它们如何连接的那一层。

AI工程的五层栈

每年，AI工程的杠杆都在离模型更远一层的方向移动。把整条线一次看清：

层	工程的对象	核心问题
提示（Prompt）	发给模型的单个请求	我问得好吗？
上下文（Context）	模型能看到什么	它有正确的信息吗？
框架（Harness）	工具、记忆、脚手架	它能对世界采取行动并记住吗？
循环（Loop）	一个Agent重复的周期	它什么时候检查工作并停下？
图（Graph）	多个Agent/步骤之间的协调	谁做什么、什么顺序、共享什么状态？

这五层是累积的，不是爬过去就丢掉的梯子。一个图里满是节点；好的节点是一个设计良好的循环；好的循环需要真正的框架——上下文、工具、编排、状态、评估、恢复这些让Agent能行动的组件。跳过低层，上面的图只会以更精致的方式失败。如果你的节点是弱Agent，把它们编进组织架构图，得到的只是一个弱组织。

五种核心图模式

实际搭图时，无论多复杂的系统，都是由以下五种基础模式组合而成。

节点A跑完把输出传给B，B传给C。没有分支，没有路由。大多数“AI流水线”就是这东西。它适用于每步必然成功且顺序永不变的场景——数据提取、格式转换、先翻译再总结。最大风险是错误传播：A产出垃圾，B在垃圾上构建，C在垃圾的垃圾上构建，三层下来错误被放大。所以即使简单的顺序链，也值得在末尾加一个验证节点。

一个路由节点检查输入，从多条路径里选一条。不是每个节点都跑——路由器挑出对的专家。关键洞察是：路由是分类任务，不是推理任务。你不需要用最贵的模型来决定一张工单是关于计费还是关于bug——小模型几毫秒搞定，成本只有几分之一。把贵的模型留给专家节点里的实际工作。每个专家应该有自己的系统提示和专属工具集：代码Agent需要run_tests和write_file，研究Agent需要web_search和read_doc。给每个Agent所有工具，意味着错误的工具调用、浪费的token和混乱的输出。

多个节点同时跑，一个收集器等所有结果然后合并。三个Agent并行意味着总耗时是最慢那个的耗时，而不是三个之和。前提是独立性：如果B需要A的输出，就不能并行。竞品分析是最干净的例子——一个Agent盯一个竞争对手，同时开跑，结果在末尾汇合。合并节点是大多数人投入不足的地方：拼三个JSON容易，把三份研究报告合成一份连贯的分析需要它自己的提示和质量标准。把合并节点当成一个真正的Agent，而不是字符串拼接。

构建器Agent干活，一个独立的审稿Agent检查。审稿不通过，构建器带着失败原因重试。这是所有自纠正Agent系统背后的模式。关键规则：构建器和审稿者必须是不同的Agent——不同的系统提示，通常不同的模型等级。构建器的活是产出，审稿者的活是拒绝。如果同一个Agent审查自己的工作，它会批准自己的错误，因为产生缺陷的推理和评估缺陷的推理是同一套。审稿者的提示应该是对抗性的——不是“这个好吗？”而是“找出所有缺陷、不一致和遗漏的边界情况。如果找不到问题，返回{passed: true}。如果不确定，判不通过。”

图在特定节点暂停，等人工批准后继续。Agent做研究、草拟行动方案，人审查关键决策，批准后Agent执行。这个模式对所有昂贵、不可逆或高风险的操作是强制的：给客户发邮件、部署到生产环境、执行金融交易、删除数据。审批节点应该给人看清楚即将发生什么、代价多少——不是“你批准吗？”而是“此操作将向计费分段的2400个用户发送邮件，主题行如下，正文如下，预计成本12美元。批准？”具体到人能在5秒内做出真正的判断。

模型分级：别用大炮打蚊子

生产环境里的图，不是每个节点都需要同一个模型。

路由器做分类——用最快最便宜的小模型。构建器做推理——用中档模型。高风险输出的最终质量关卡——用最强的模型。用中档模型做路由，就像雇一个高级工程师去分拣邮件。能干，但你在错误的任务上烧预算。

一个典型的分级方案：路由器用小模型（快速、便宜、分类），构建器和审稿者用中档模型（推理、工具调用），最终质量关卡用最强模型（最高标准、很少触发）。

什么时候该用图，什么时候不该

这是把有用的builder和为了好玩往图上加框的人分开的问题。默认答案是：

一个范围清晰、有明确验证器的任务是循环，在那里伸手去够图是纯粹的负担。

信号	循环就够	该用图
任务形状	一个有终点的工作	拆成不同专业、互相交接
并行性	步骤是顺序的	需要扇出再汇合
每步工具/模型	全程同一套	每步用不同模型或工具集
控制流	一个Agent能安全自由探索	需要角色间显式、可审计的路由
故障隔离	坏的步骤重试就行	想让一个坏节点失败而不污染其余
谁来验证	Agent自检循环输出	专门的审稿节点检查另一个节点的工作

这张表是一组触发器，不是要满足的清单。不需要六条全中。但如果大多数诚实答案是左列，建图就是把你两小时的任务变成两天框架项目的方式。

判断标准很简单：图是否在做循环做不到的事。如果你能把五个节点折回一个Agent的循环且什么也不丢，那就该折回去。先掌握循环，只在工作逼你的时候才拆成图。

“这不就是LangGraph吗”

最尖锐的回应是某个版本的“恭喜，你重新发明了LangGraph”。这值得正面回答，因为它大体上是对的。

在“Graph Engineering”这个词走红之前，把Agent系统建为节点和边在共享状态上的图，已经在真实工具中存在了：

• LangGraph
  （LangChain出品）定义StateGraph，加节点，加边——就是上面的节点/边/状态模型。如果你用过LangGraph，你一直在以另一个名字做Graph Engineering。

• Microsoft AutoGen
  的GraphFlow把基于图的多Agent编排带入了AutoGen。

• Google ADK
  （Agent Development Kit）把图模型作为头条特性，内置顺序、并行和循环工作流Agent，以及扇出/扇入和路由。

• A2A
  （Agent2Agent）是一个跨系统Agent互相委托的开放协议——“不同团队拥有的图之间的边”那一层。

所以，Graph Engineering就是LangGraph吗？技术上大体是。2026年中真正新的东西更窄也更软：一个为那些框架一直在要求的设计决策起的共享名字，以及一种日益增长的感觉——这是一项值得教授的独立技能，而非框架细节。这是真实的东西，只是比“新范式”小得多。

批评者也不是门外汉。XState的创建者Da vid Khourshid警告说“在读Graph Engineering的slop文章之前记住这一点”——当一位真正的状态机专家对“图”被当作新东西发布翻白眼，那不是守门，是有人指出有向图的状态和转换是几十年前的计算机科学。Pawel Huryn直言“我对Graph Engineering说BS”——他的替代方案是跳过机制命名，直接给Agent目标、为什么重要、成功如何被衡量。命名在反复犯同一个错误：把机制（循环、图）误认为实质（目标和验证）。

这些批评全都是对的。力学不新，搭这个词的很多内容是slop，“Graph Engineering”这个词是可选的——你可以搭每个系统而一次都不用这三个字。但噪音之下，一次真实的设计升级正在发生：在2026年上半年练好了单Agent循环的团队，正在撞上一堵墙——一个循环不再是正确的形状——于是有意识地把工作拆成协调的、专门化的节点，状态在它们之间流动。这个升级是真实的，无论你是否叫它“Graph Engineering”。

动手之前：八条检查清单

在把循环变成图之前，把想法过一遍这些：

1. 尽量保持循环。
   一个范围清晰的Agent配好的验证器能做这件事吗？能就停在这，你完成了。

2. 只在真正的专业分工时才命名节点。
   每个节点应该是单一循环确实撑不住的工作——不同模型、不同工具集、或只读审稿角色。“可以内联的步骤”不是节点。

3. 先画边再写代码。
   草拟路由：什么是顺序的、什么扇出、什么扇入、那条条件/回环边在哪里。如果你不能在餐巾纸上画出来，它就太复杂了。

4. 显式设计共享状态对象。
   决定什么沿边流动、谁有权写入。状态漂移是图腐烂的第一方式。当图出问题时，你查的第一样东西就是状态——如果你追踪不到哪个节点写了哪个键，你什么都debug不了。

5. 给审稿节点牙齿。
   单一最高价值的节点通常是一个独立的、只读的验证器——与产出工作的Agent不同的那个。这是“别让Agent自我验证”从循环升格为节点。一个严格的审稿者能抓住真正的bug，一个客气的审稿者会放行一切。

6. 隔离故障。
   确保一个节点能失败并重试，而不腐蚀共享状态或毒害下游节点。生产环境的图需要为每个可能失败的节点准备一条回退边——回退不是“忽略错误”，而是一条优雅处理失败的独立路径。

7. 选框架，别手搓。
   LangGraph、AutoGen GraphFlow或Google ADK已经给你节点、边、状态、扇出/扇入和循环。重新发明运行时是另一种slop。你需要的只是函数、字典和if语句——但框架帮你省掉的是边缘情况里那些你没想到的坑。

8. 设花费上限和硬边界。
   图是许多循环；弱的验证器现在并行烧token。封顶。

图也会失败

如果只是得出“改进的答案是更多循环、更好排列——拓扑就是解药”的结论，那就太容易了。

想象一家公司搭了完整的图：配对指标、审计循环、调参的元循环——而每个循环都消费报告。审计循环把运营数字与财务数字核对；财务数字来自运营喂入的同一套系统；元循环用建在所有这些之上的仪表盘调阈值。每个循环都在看另一个循环，没有循环触碰地面。这张图是循环的：一个精巧的相互确认网络，其中一切都一致，什么都没被验证。它会像单一循环一样失败，只是更晚、更贵，一路下来绿灯多得多。拓扑买到了精巧，没有买到与现实的接触。

所以图需要任何边的排列都无法提供的东西：

。网络中某些测量必须是那种无法争辩的——真正到账的收入、真正执行了的测试、真正留下来的客户。某些节点必须被冻结——优化循环永远不被允许调校的规则，恰恰因为它们是优化器会忍不住削弱的规则，就像训练循环永远不能看到留出集。还有一样东西必须完全来自图之外：“更好”在根上意味着什么的答案。这个判断由人提供，通过与真实失败的接触。

写在最后

安全的预测是，图架构会像单一循环一样成为正统：教程会更新，每个严肃系统都会内置配对指标和审计周期，就像现在每个严肃系统都内置版本控制。更深的预测是：循环的图也会以它自己特有的方式失败——循环地、一致地、貌似合理地——无论在哪里被建造而没有锚点。

持久的轴线从来不是循环对图。而是无锚对有锚——改进的机器无论形状如何，是否仍在触碰它声称要改进的现实。单一循环是系统学会变好的方式。图是系统学会不自欺地变好的方式。先掌握循环，只在工作逼你的时候才拆成图，然后确保你的图里有什么东西触碰着地面。