从 Loop 到 Graph：AI Agent 架构的下一站
2026 年 7 月，OpenClaw 创始人 Peter Steinberger 在 X 上发了一条不到十个字的帖子：「我们还在讨论 Loop，还是已经转向 Graph 了？」短短三天，这条推文被浏览了超过 270 万次。
而就在六周前，正是同一个人，用一句「不要再亲自提示 Agent，而要设计能够提示它的循环」带火了 Loop Engineering。
六周，一个概念从爆火到「被宣告过时」——行业认知的半衰期正在以指数级缩短。但这真的是一次技术范式的更替吗？
什么是 Loop Engineering？
回想最早怎么用 AI：你发一句，它回一句；你说不对，它改；你让它跑测试，它跑完就停下等你。看起来是 AI 在工作，但真正驱动每一步的其实是人——你才是那个 for 循环。
Loop Engineering 做的事，就是把「驱动循环」这个动作交给 AI 自己。一个 Agent 在一个「执行 → 验证 → 反馈 → 决策」的闭环里自己跑，直到达成目标。Boris Cherny 有句被反复引用的话：「我现在已经不提示 Claude 了，我运行的是一些循环，由这些循环去提示 Claude。」
在代码层面，Loop 就是一个 while not done 的循环：拼接系统提示和历史对话，调用 LLM，识别并执行工具调用，将结果追加到上下文中，循环往复。
为什么需要 Graph？
当一个 Agent 的任务从「写一篇摘要」变成「研究一个行业 → 写一份报告 → 让另一个 Agent 审阅 → 决定是否交付或退回重做」时，单 Agent 循环的局限性就开始暴露。
学术研究也指出了 Agent Loop 的三个结构性缺陷：
- 步骤间依赖隐式难追溯：所有逻辑都藏在不断膨胀的上下文里
- 错误恢复可能无限循环：一旦跑偏，可能永远回不来
- 执行历史动态可变：调试困难，无法稳定复现
一个 Loop 只有一条主要路径，但复杂任务需要分工、并行、回退和交接。研究需求的 Agent、写代码的 Agent、做测试的 Agent，谁先开始？哪些工作可以同时进行？测试失败后应该回到哪里？
这些问题，Loop 解决不了。
Graph Engineering 是什么？
Graph Engineering 就是把多个专门化的 Agent 或步骤连成一张「图」——节点（干活的人/步骤）、边（它们之间的路由，包括分支、并行和回退），以及沿着边流动的共享状态。
一个 Graph 通常包含四样东西：
- 节点：承担职责的工作单元，可以是一段代码、一次模型调用、一个工具，也可以是一个会自行循环的完整 Agent
- 边：节点之间的交接方式——顺序、并行、条件分支、失败回退
- 共享状态：像项目的公共工作台，保存需求、中间结果和结论
- 路由规则：决定下一步去哪——「测试通过就交付，测试失败就回到实现节点」
如果你做过后端开发，这套东西其实并不陌生——工作流引擎（Activiti、Camunda）、DAG 任务调度（Airflow）、微服务编排（Saga），本质都是「用图来编排多个执行单元」。只不过现在执行单元从「一段代码」换成了「一个 Agent」。
Loop 和 Graph 的本质区别
「区别在于谁来决定路径——Agent 还是你。」
在 Loop 中，你设定目标和验收标准，Agent 自己找路走到终点。Agent 的自由度高，可以自主规划执行路径。
在 Graph 中，你声明所有合法路径和检查点——先走这个节点、再走那个，如果审查失败就退回。Agent 的自由度被限制在每一个节点的内部，而不是横跨整个任务。
| 维度 | Loop Engineering | Graph Engineering |
|---|---|---|
| 控制粒度 | 任务级（设目标） | 节点级（定义每一步） |
| Agent 自由度 | 高，自主规划路径 | 中，节点内自由，节点间由开发者控制 |
| 适用场景 | 单目标单工具任务 | 多步骤多角色协作任务 |
| 错误传播 | 一步错可能整链跑偏 | 错误被隔离在单个节点内 |
| 资源消耗 | 低 | 高（多 Agent/节点各自消耗 Token） |
Loop 没死，它只是换了个位置
这是整件事最关键的一点。
Graph 并没有消灭 Loop，而是把原本隐藏在单个 Agent 上下文里的职责、依赖和控制逻辑，提升成一套显式的执行结构。
一个循环，就是一个单节点的图，带一条指向自己的边。你在循环工程里学到的所有东西——发现、规划、执行、验证——都是一个节点的内部。图没有取代循环，它是当你有好几个循环需要互相交接时得到的东西。
反过来说，图工程的地基是循环工程。一个图里全是节点，一个好的节点就是一个设计良好的循环。如果你的节点是弱 Agent，把它们连成组织架构图，你只会得到一个弱组织。
什么时候该用哪个？
Loop 适合：10 步以内的简短探索性任务、原型快速验证。Cursor 的 Router 功能靠一个灵活的 Loop 就帮开发者省了 36%-60% 的 API 费用。
Graph 适合：任务能够独立拆分、存在分支或回退、中间状态值得保存、协作收益高于协调成本。比如客服系统——需要先分类、再搜索知识库、再让质检 Agent 审核、再决定是否人工介入——没有 Graph，就得在一个 Loop 里塞入全部判断逻辑。
从 Prompt 到 Graph：五层演进
过去一年多，「让 AI 系统稳定工作」这件事被换了五个名字：
- Prompt Engineering：管一次对话里这句话怎么说
- Context Engineering：管这一步往模型脑子里塞哪些信息
- Harness Engineering：管它周围的结构——工具、护栏、跨会话状态
- Loop Engineering：管一个 Agent 如何自己反复地执行、验证
- Graph Engineering：管多个执行节点之间的组织关系
它们不是互相取代，而是一层一层往外叠。Graph 是目前最外面的一层，但它建立在前四层都做好的前提上。
写在最后
Graph Engineering 不是什么颠覆性新发明——它是把「用图来编排多个执行单元」这套老思路，套到了 AI Agent 协作上。但词是不是新的，和这个转变是不是真的，是两码事。从「编排一个智能体」到「编排一群智能体」的工程重心迁移，是真实发生的。
黄仁勋在 Startup School 2026 大会上表达过一个类似的观点：当底层实现越来越多地被 Agent 自动化，人类的核心价值将从「亲手完成每个步骤」转向「设计系统、明确约束、组织信息流」。
先掌握循环，再谈图。