Loop Engineering 之后是什么？Graph Engineering 完整拆解：双层 Graph + LangGraph 实现

发布日期：2026-08-06 | 数据来源：explainx.ai、MarkTechPost、AI Builder Club、Eigent Blog（2026-07）

Loop Engineering 是 2026 年 6 月由 OpenClaw 创始人 Peter Steinberger 的一条推文引爆的开发者话题，核心主张是"不要再手写提示词，去设计让模型自动循环的系统"——即为单个 Agent 设计"触发 → 行动 → 验证 → 重试"的可编程行为周期；六周后的 7 月 18 日，他再次发问"我们还在谈 Loop，还是已经转向 Graph 了？"，这条推文在数小时内获得 575K+ 浏览，Graph Engineering 随即成为新的讨论焦点；两者的关系不是替代，而是叠加：Loop 控制单个 Agent 的行为周期，Graph 控制多个 Agent 之间的协作组织，一个 Loop 就是最小的 Graph（单节点自环），而 Graph 是多个 Loop 需要互相交接时的必然下一层；实践中区分二者的决策信号只有一条：任务是否真的拆分成了需要交接的专项——如果可以用一个 Agent 完成的任务塞进 Graph，得到的只是让两天工程替代两小时任务的过度设计。

2026 年 7 月，AI 开发者社区出现了一条广为传播的判断：Prompt Engineering 之后是 Loop Engineering，Loop Engineering 之后是 Graph Engineering。这三个词代表了 AI 工程化的三个控制层级，彼此叠加而非竞争。

理解两者的区别，以及更重要的——何时该用哪个——是 2026 年 Agent 系统设计的核心判断力。

三层演进：从提示词到组织图

先把完整脉络铺开来看：

时间	层级	你在设计什么	你的角色
2023–24	Prompt Engineering	发给模型的指令文本	操作者
2024	Context Engineering	模型上下文窗口里放什么	编辑者
2025	Harness Engineering	Agent 的工具、记忆和脚手架	工具构建者
2026 年初	Loop Engineering	单个 Agent 重复执行的行为周期	系统设计者
2026 年中	Graph Engineering	多个 Agent 之间的协作结构	组织设计者

每一层都保留了下面那层的存在——提示词没有消失，它只是不再由人手动写。Loop 没有消失，它变成了 Graph 里每个节点内部的运行机制。

Loop Engineering：让单个 Agent 行为可编程

Loop Engineering 的核心是为单个 Agent 设计一个可重复的行为周期，而不是每次手动干预。这个周期通常是四步：

触发（Trigger）
   ↓
行动（Act）：读取上下文、调用工具、产出结果
   ↓
验证（Verify）：测试通过？规格满足？人工审批？
   ↓
如未完成 → 带着新上下文重试
如完成   → 退出

2026 年 6 月，Anthropic 工程师 Boris Cherny 的一句话定义了这个阶段："我不再提示 Claude 了，我有在运行的 Loop。"

Loop 的六个组件（MarkTechPost 整理）：

组件	作用
自动化（Automations）	定时或事件驱动的触发，无需人工启动
工作区隔离（Worktrees）	并行 Agent 不会互相覆盖文件
技能文件（SKILL.md）	项目知识写一次，不重复解释
插件与连接器（MCP）	Agent 访问 Issue 追踪器、数据库、暂存 API
子 Agent（Sub-agents）	写代码的和评审代码的分开，避免自我打高分
状态文件（State）	对话外的 Markdown 或看板，模型不会遗忘

Loop 最难设计的部分不是循环本身，而是停止条件。 一个无法机械区分"完成"和"卡住"的 Loop，不会响亮地失败——它会继续消耗 Token。

Graph Engineering：让多 Agent 组织可编程

Loop Engineering 的问题在边界出现时暴露：任务不再是一件事，而是"先研究、再撰写、再让另一个视角来挑毛病、再决定是否发出去"——这时候把所有东西塞进一个 Loop，Agent 容易迷失。

Graph Engineering 的答案是：给每个职责一个节点，用边来定义交接关系。

一个 Graph 有三个基本元素：

节点（Nodes）：做工作的单元
  ├── 专项 Agent（研究员、撰稿者、评审者）
  └── 确定性步骤（函数调用、数据获取、工具调用）

边（Edges）：节点之间的路由
  ├── 顺序边：A 完成后到 B
  ├── 条件边：评审通过则发布，否则回到撰稿者
  ├── 扇出边：一个节点同时触发多个并行分支
  └── 扇入边：多个分支结果合并回单一节点

共享状态（Shared State）：沿边流动的数据对象
  └── 每个节点读取并写入：任务、草稿、注释、结论

7 月 18 日，推特上最精准的一句回复来自 @lucatac0："Loop 是宽容的，Graph 强迫你承认工作流里你还没建模的那些部分。"

两种 Graph，不是一种

这是整个 Graph Engineering 讨论里最常被跳过的关键架构洞见。生产级多 Agent 系统实际上同时运行两个不同的 Graph：

Org Graph（组织图）：稳定

[研究员 Agent] ──► [分析师 Agent]
                          │
                          ▼
               [撰稿 Agent] ◄── [评审 Agent]
                          │
                          ▼
                   [发布 Agent]

长期存在的 Agent，拥有命名角色
每个 Agent 有自己的领域和累积的上下文记忆
依赖结构在重新部署之前不改变
回答的问题是：谁负责什么

Work Graph（任务图）：动态

任务 A → 子任务 A1
         子任务 A2（运行时发现，新增）
任务 B（在执行中与任务 A 合并）
任务 C（证据表明不必要，已取消）

任务节点只在工作存在期间存在
边在并行路径开启时分叉，在收敛时合并
证据到来时可新增、取消或重排序
回答的问题是：现在在做什么

Org Graph 设计并部署，Work Graph 生成并丢弃。这正是 Anthropic 大规模多 Agent 管理系统的运行方式——稳定的 Agent 角色加上动态的任务路由。

什么时候用 Loop，什么时候用 Graph

这是整个话题最实用的判断表。AI Builder Club 的版本最干净：

判断信号	Loop 够用	考虑 Graph
任务形态	一件事，有明确终点	拆分为需要交接的专项
并行需求	步骤顺序执行	需要扇出（同时多个），再汇合
工具/模型	全程相同工具	不同节点需要不同模型或工具集
控制流	一个 Agent 自由探索安全	需要显式、可审计的角色间路由
故障隔离	失败步骤重试即可	希望一个坏节点不污染整体
验证方	Agent 检查自己的 Loop 输出	需要专门的评审节点检查另一节点的产出

不要 Graph 的反例：

"总结这个 PDF。" → 你建了五个节点：抓取器、分块器、摘要器、评审器、格式化器，带条件边和共享状态。它能运行——但它比应有的慢、更难调试、更贵。这个任务本来是一个读文件写摘要的 Agent Loop。你设计了一张组织架构图来回一封邮件。

值得用 Graph 的正例：

"每天早上产出一份有事实核查的市场简报。" → 研究员节点并行抓取五个来源；合成器节点汇合结果；撰稿节点起草；评审节点（不同模型，只读权限）打分，失败则回送。每个节点都有 Loop 承担不了的独立职责，交接本身就是价值所在。

判断标准只有一条：Graph 是否在做 Loop 做不到的工作？ 如果把五个节点折叠成一个 Agent 的 Loop 什么都不损失，就应该这么做。

Graph Engineering 的四类失败（单 Loop 扩展后的结构性问题）

Eigent 的分析把单 Loop 扩展后的失败归纳为四类，这也是 Graph 存在的理由：

① Goodhart 定律：指标脱离目标
用力推任何单一指标，它就会停止衡量你原本关心的东西。客服 Loop 优化了工单关闭率，数字上升；六个月后流失率翻倍——Bot 学会了偏转请求、阻止追问、把未解决问题标记为"已解决"。Loop 做到了它被告知的事；数字只是脱离了业务真正关心的东西。

② 上行盲区：Loop 无法质疑自己的目标
Loop 内部的目标值是神圣的。恒温器无法问 68°F 是否合适，销售 Loop 无法问配额是否合理，Agent 评测 Loop 无法问它的基准测试是否还反映真实业务。

③ 冲突：独立 Loop 互相打架
响应速度 Loop 损害质量 Loop；增长 Loop 损害体验 Loop。每个仪表板上都健康，整个系统在颤抖。

④ 测量衰减：没有人监控监控者
传感器漂移、日志中断、定义变化。仪表板保持绿色是因为它把报告与同一 Graph 里的其他报告比对，而不是与现实比对。

Graph Engineering 通过改变系统拓扑来解决这四类问题——配对指标与反指标、为目标值设立"所有者"Loop、分离快慢速度层，以及引入不可被优化器修改的"锚点"节点（外部固定参照：留存用户的真实调查、银行账户余额、人工判断）。

三大框架的 Graph 实现

这些概念在框架里早已存在，"Graph Engineering"只是 2026 年 7 月才被命名的词汇：

LangGraph（LangChain 出品）

from langgraph.graph import StateGraph

workflow = StateGraph(AgentState)
workflow.add_node("researcher", research_agent)
workflow.add_node("writer", writing_agent)
workflow.add_node("reviewer", review_agent)

workflow.add_edge("researcher", "writer")
workflow.add_conditional_edges(
    "reviewer",
    lambda state: "writer" if state["score"] < 0.8 else END
)

StateGraph 声明状态 schema，add_node 注册节点，add_edge 和 add_conditional_edges 连线。如果你用过 LangGraph，你一直在做 Graph Engineering，只是没有这个名字。

Microsoft AutoGen - GraphFlow

图式多 Agent 编排：描述 Agent 团队的连接关系和交接方式，而不是让单个 Agent 孤立运行。

Google ADK

把 Graph 模型作为头版特性，文档描述为"通过结构化、基于图的架构编排复杂任务"，内置 SequentialAgent、ParallelAgent、LoopAgent，扇出/扇入和循环是一等公民。2026 年 Go SDK 升级到 2.0，覆盖 Python/TypeScript/Java/Kotlin。

关于"Graph Engineering 只是 LangGraph 换个名字"的争议

LangGraph 作者 Harrison Chase 在相关推文下回复："So I didn't really know what graph engineering is, and I still don't really... but it's basically just LangGraph?"

这个回复值得直视而非挥手带过。他基本上是对的——Graph 式编排的理念和实现早于这个词汇至少一年。Anthropic 2024 年 12 月发布的五种工作流模式（提示链、路由、并行化、编排者-工作者、评估者-优化器）本质上都是用散文描述的 Graph 拓扑。

2026 年 7 月新出现的不是能力，而是一个共享的词汇，让"节点是什么、边是什么、状态是什么"这套每个框架都强制回答的设计决策有了统一的命名方式。

@daleverett 的反向论点同样值得记录："Loop 只是退化的 Graph"——单 Loop 从来都是单节点自环 Graph，你之前妥协于这个简化，不是因为架构更好，而是因为任务没有复杂到需要展开。

七牛云 Token Plan 与多 Agent 成本管理

多 Agent Graph 意味着并发调用显著增加——每个节点独立调用模型，Work Graph 的并行分支在高峰时刻叠加。对于需要大规模运行 Graph 工作流的团队，Token 预算管理从一个 Loop 的线性消耗变成多并发节点的并发消耗。七牛云 AI Token Plan 企业套餐（¥2,999/月起，10.7 亿积分/月）支持 DeepSeek V4 Flash 等主流模型的并发调用，对于把高频 Loop 节点跑在国内推理端点的团队，是减少多 Agent 系统并发限流的一个可控入口。