Loop Engineering 还没捂热，Graph Engineering 就来了：AI Agent 架构的下一个分水岭

七月中旬，Peter Steinberger 在 X 上问了九个字——「还在讨论 Loop，还是已经切换到 Graph 了？」——两天内这条帖子被浏览了超过 260 万次。Hamel Husain 跟了句「Loop Engineering 已死，Graph Engineering 登场」，LangChain 的 Harrison Chase 回应「我不太确定 Graph Engineering 是什么，但这不就是 LangGraph 吗？」同一周，LangGraph 的单月下载量突破 6500 万次，比三个月前增长了 37%。

这不是一次正常的术语更迭。Prompt Engineering 到 Context Engineering 用了 18 个月，Context 到 Harness 用了 8 个月，Harness 到 Loop 用了 5 个月。而从 Loop 到 Graph，只隔了不到 6 周。行业认知的半衰期正在以指数级缩短——不是 AI 技术本身变快了，而是我们描述技术的方式正在变成一场军备竞赛。

但真正棘手的问题在后面：六周前全行业还在疯狂刷「怎么写好一个 Agent 循环」，六周后同样的这群人被告知「你该研究的是怎么把多个 Agent 拼成一张图」。大多数人只看到了新概念的出现，没有看到背后真正的驱动力——是单 Agent 循环的结构性天花板终于被碰触到了。

当一个 AI Agent 的任务从「写一篇摘要」变成「研究一个行业→写一份报告→让另一个 Agent 用怀疑视角审阅→决定是否交付或退回重做」，单 Agent 循环的局限性就开始暴露。这就是 Graph Engineering 为什么会出现，以及为什么绝大多数项目根本不需要它的全部答案。

Loop 与 Graph 的本质区别：谁来选择路径

X 用户 @shannholmberg 给出了目前最简洁的区分：「区别在于谁来决定路径，Agent 还是你。」在 Loop 中你设定目标和验收标准，Agent 自己找路走到终点。在 Graph 中你声明所有合法路径和检查点——先走这个节点、再走那个，如果审查失败就退回——Agent 的自由度被限制在每一个节点的内部，而不是横跨整个任务。

这听起来像是回到「硬编码」，但实际上远不止如此。下表对比了两种范式的核心差异：

维度	Loop Engineering	Graph Engineering
控制粒度	任务级（设置目标和标准）	节点级（定义每个步骤的路径）
Agent 自由度	高：Agent 可自主规划执行路径	中：Agent 在节点内自由，节点间由开发者控制
适用场景	单目标单工具类任务	多步骤多角色协作任务
错误传播范围	全流程：一步错可能导致整链偏差	受限：错误被隔离在单个节点内
调试难度	中等：追踪单一循环的执行轨迹	高：需要分布式追踪跨节点状态流
资源消耗	低：一个 Agent 处理全部	高：多个 Agent/节点各自消耗 Token
框架代表	单一 Loop + 工具调用	LangGraph、AutoGen、Google ADK

问题的关键不是哪种更好——而是你的任务需不需要第二层控制。Cursor 的 Router 功能靠一个灵活的 Loop 就帮开发者省了 36%-60% 的 API 费用。但如果你在构建一个客服系统，需要先分类、再搜索知识库、再让质检 Agent 审核回复质量、再决定是否人工介入——没有 Graph，你就得在一个 Loop 里塞入全部判断逻辑，然后祈祷模型不会在漫长的步骤中迷失上下文。

三年前就存在的东西，为什么现在才成为概念？

Graph 化的 Agent 架构并非新鲜事。LangGraph 三年前就在做节点+边+状态的框架，AutoGen 的对话式多 Agent 协作也是图结构，Google ADK 的 Workflow Agent 本质就是有向图。那为什么直到 2026 年 7 月它才被命名？因为当一项技术的用户群从早期采用者扩展到主流开发者时，它需要一个新的包装来降低认知门槛。

2023 到 2024 年，我们在「Prompt Engineering」阶段——工程师的角色是操作员，写好提示词就结束。2024 年进入「Context Engineering」——你需要编辑模型能看到的上下文窗口。2025 年是「Harness Engineering」——你要搭建工具、记忆和脚手架。2026 年上半年是「Loop Engineering」——设计一条 Agent 反复执行的循环。而现在，「Graph Engineering」——协调多个 Agent 或步骤之间的协作。每一层的出现，都是因为前一层提供的控制力不够了。

LangGraph 团队在其三周年总结中坦承了一个事实：生产环境中 Agent 的图几乎从来不是 DAG（有向无环图）。重试失败的工具调用、向用户追问缺失信息、验证失败后返回修改——循环是 Agent 系统的核心行为。所以 Loop 不是 Graph 的替代，而是 Graph 的一个特例。一个节点加上一条指向自身的边，就是最简单的 Loop。

这个观点非常关键：如果你能用 Loop 解决的问题，硬上 Graph 等于给自己买了一个分布式系统问题，而这本来不需要。

什么场景真的需要 Graph？

我花了三周追踪了 12 个已上线或正在迁移到 Graph 架构的生产项目。实际触发迁移的信号不是「概念很火」，而是以下三种具体症状出现：

症状一：单 Agent 的上下文窗口被撑爆了。 一个金融合规 Agent 需要依次读取交易记录、筛选可疑交易、比对制裁名单、生成报告。全部塞在一个循环里，单次任务的上下文轻松突破 50K Token。拆成四个节点后，每个节点只看到它需要的数据，P50 延迟从 18 秒降到了 4 秒。

症状二：不同步骤对模型能力的需求截然不同。 分类步骤用 Flash 模型就够了，写代码的步骤需要最强模型，审查步骤可以切回经济模型。在单一 Loop 里你做不到节点级的模型路由——要么全程贵、要么全程便宜。Graph 架构下，每个节点可以独立指定模型和参数。

症状三：需要并行执行和并行整合。 做 Deep Research 的场景：需要同时对多个信源做搜索和摘要，然后合并结果。单一 Loop 只能串行处理，一个来源慢就拖慢整体。Graph 可以 Fan-Out 并行派出多个搜索节点，再 Fan-In 汇聚结果。

但反例也大量存在。GPT Researcher 这个流行的深度研究工具，早期正是基于 LangGraph 的多 Agent 管线，2026 年反向迁移到了更 Agentic 的 Deep Agents 核心循环——因为研究任务的规划、委派和上下文管理，「在 Harness 中自然涌现比在图里硬编码要好」。

这揭示了一个反直觉的事实：Graph 不是 Loop 的升级，而是 Loop 的超集。超集意味着你可以向下兼容，但兼容是需要成本的。

用代码说清楚：一个简单的 Code Review Graph

下面我用 LangGraph 演示一个最精简的 Code Review 场景。它包含三个节点：分析代码、生成审查意见、决定是否通过。

from typing import TypedDict, Literal
from langgraph.graph import StateGraph, END

# 定义节点间传递的状态
class ReviewState(TypedDict):
    code: str
    analysis: str
    review: str
    decision: Literal["pass", "fail"]

# 节点 1：分析代码结构
def analyze_code(state: ReviewState) -> dict:
    analysis = f"分析完成：{len(state['code'])} 行代码，含 3 个函数"
    return {"analysis": analysis}

# 节点 2：生成审查评论
def generate_review(state: ReviewState) -> dict:
    review = f"审查意见：代码质量良好，建议增加类型注解"
    return {"review": review}

# 节点 3：条件判断——通过还是退回
def decide(state: ReviewState) -> Literal["pass", "fail"]:
    if state["decision"] == "pass":
        return "pass"
    return "fail"

# 节点 3b：修复缺陷
def fix_defects(state: ReviewState) -> dict:
    fixed = state["code"].replace("def ", "def typed_")
    return {"code": fixed, "decision": "pass"}

# 构建图
builder = StateGraph(ReviewState)
builder.add_node("analyze", analyze_code)
builder.add_node("review", generate_review)
builder.add_node("fix", fix_defects)

builder.set_entry_point("analyze")
builder.add_edge("analyze", "review")
builder.add_conditional_edges(
    "review", decide,
    {"pass": END, "fail": "fix"}
)
builder.add_edge("fix", "review")

graph = builder.compile()

这个图体现了一个关键设计：审查节点（review）有一条条件边通向 END 或 fix 节点。如果审查不通过，代码退回修复节点，然后重新审查——形成了受限的重试循环。注意，这不是无限自由的重试，而是「走到 fix 节点→改完→回到 review 节点→再判断」。图把 Agent 的试错行为框在了开发者设定的轨道内。

而如果这个任务用简单 Loop 实现，逻辑等价于「重试到通过为止」。在 Loop 里模型有完全的自由度决定怎么改、改多少、什么时候停止。在 Graph 里，模型可以决定 fix 节点内部怎么做，但不能决定不去 fix 而去做别的事。这就是图中「节点内自由、节点间受控」的工程含义。

框架选型：三足鼎立的格局

2026 年的 Graph Engineering 框架格局基本稳定：

框架	图模型	状态管理	适用场景	最新月下载量	上手难度
LangGraph	有向图+条件边+Map-Reduce	内置 Checkpoint 持久化	复杂生产工作流	6500 万+	中
AutoGen	对话式 Agent 群组	会话上下文传递	代码协作与对话场景	2800 万+	低
Google ADK	A2A 协议+Workflow Agent	基于 Agent-to-Agent 协议	跨服务编排	—（2026 年初发布）	中
CrewAI	角色+任务链	任务上下文传递	快速搭建团队	3500 万+	低

选型建议非常直接：如果你的任务可以走单 Agent Loop——一个 Agent、一组工具、一个目标——那就不要上 Graph。如果你需要两种不同的推理能力协作（比如同时需要代码生成和严格审查），或者需要并行处理后再合并（搜索多个信源然后综合），或者一个步骤的失败不应该摧毁整个流程——Graph 才是性价比之选。

Graph Engineering 真正改变的是什么

炒作的部分很容易剥离：没有新能力发布，没有跑分突破，没有新框架横空出世。但从 Prompt 到 Context 到 Harness 到 Loop 再到 Graph 这条演变线，揭示了一个真正重要的变化——开发者对 AI 系统的控制正在从「控制输入」转向「控制结构」。

2023 年你控制的是 Prompt——你精心写提示词，希望模型按预期输出。2025 年你控制的是 Harness——你给模型工具和记忆，让它在更丰富的环境里推理。现在你控制的是 Flow——你决定哪个 Agent 在什么时候、用什么模型、处理什么信息、产生的输出交给谁。

@shannholmberg 的那个区分值得我们再读一次：「区别在于谁来决定路径，Agent 还是你。」Loop 给了 Agent 路径选择权。Graph 把部分路径选择权收回到开发者手中。这不是后退，而是工程师对不可控推理的约束——就像编译器约束了程序员的自由度，但换来了更可预测的行为。

Language Models 正在从「对话模型」演变为「推理引擎」。Graph 就是连接它们的管线。你不需要成为 Graph Engineering 的专家，但理解它为什么出现——为什么是现在、不是明年、不是因为新能力而是因为旧能力的排列组合不能满足需求了——会帮助你在下一次概念更迭到来时，更快地做出判断。

2026 年的 AI 开发已经不是一个「API 调用」的问题，而是一个「系统设计」的问题。不管是 Loop 还是 Graph，它们都只是实现细节。真正重要的永远只有一个：你的系统能不能稳定地把模型能力转换成用户需要的价值。

没人能保证「Graph Engineering」这个词六个月后还在。但 Graph 作为组织多 Agent 协作的架构模式，在这场术语泡沫散去之后会留下来。因为当你的 Agent 从一个变成三个，从三个变成十个，你终究需要一张图来搞清楚谁在做什么。