全网爆火的Graph Engineering到底是什么？-尧图网络科技

一、Graph Engineering怎么火起来的？

2026年7月18日，OpenClaw作者Peter Steinberger在X上发了一条只有12个单词的推文：

“Are we still talking loops or did we shift to graphs yet?”

翻译过来就是：“我们还在聊循环，还是已经转向图了？”

就这么一句话，48小时内获得了260万浏览。

两天后，有人发了一篇标题更狠的文章——《Loop Engineering Is Dead. Enter Graph Engineering》。

Graph Engineering这个词就这么被喊响了。

但奇怪的是，发那条推文的人没有给任何技术定义，没有写一行代码，没有画一张架构图。

它就像一块空白的看板，每个人都能把自己的理解塞进去。

所以，Graph Engineering到底是什么？

不同的人给出了不同的答案：

LangChain讲的是执行图：节点做事，边决定下一步
X上最流行的解释是组织图：不同节点承担不同岗位，边表达分工和交接
还有人讲的是治理图：多个Loop彼此监督，防止一个Loop把错误指标越优化越漂亮

但不管怎么定义，核心指向同一个方向：从“一个循环怎么跑”到“多个工作单元之间怎么协作”。

二、先搞清楚Loop Engineering是啥

在聊Graph之前，你得先明白Loop Engineering是啥。

简单说，Loop Engineering就是让单个Agent反复自我检查、自我修正，直到结果达标为止。

2025年，工程师Geoffrey Huntley提出了一个叫“Ralph”的方法——用一个简单的Bash循环，让Claude反复执行任务，直到目标达成：

while :; do cat PROMPT.md | claude-code ; done

这个思路迅速火遍全球，Karpathy等大佬纷纷站台。

Codex、Claude Code等工具也相继推出了/goal命令。

Loop Engineering解决了什么问题？

它解决的是“AI不能处理长上下文”的问题——每次循环都从全新的上下文开始，避免上下文腐化。

但Loop Engineering也有明显的天花板。

一个复杂系统不是靠重复就能完成的，而是需要多个组件之间的协调和通信。

循环可以让你反复执行任务，但它解决不了“谁负责什么”、“数据怎么流转”、“状态怎么同步”这些问题。

这就是Graph Engineering要解决的问题。

三、Graph Engineering到底长什么样？

剥掉所有技术术语，Graph Engineering的本质非常简单：把一个“什么都要做”的大循环，拆分成多个“只做一件事”的专门化小循环，然后定义它们之间如何交接。

3.1 核心三要素

Graph Engineering的核心架构由三个组件构成：

① 节点（Node）

每个节点是一个干具体活的单元。它可以是一个有专门职责的智能体——一个“研究员”、一个“写手”、一个“审稿人”——也可以是一段确定性的代码，比如一次函数调用、一次工具请求。

关键在于：每个节点只干一件事。

② 边（Edge）

边定义了节点之间怎么走。边可以是：

直的：A干完交给B
有条件的：审稿通过就发布，不通过就退回去重写
一分多的：一个节点同时点燃三个节点并行去跑
多合一的：三份结果汇回到一处

③ 共享状态（Shared State）

它是那个顺着边一路流动的对象，装着任务本身、目前写到哪儿了、有哪些笔记、审出了什么结论。每个节点都从它这里读，也往它这里写。

有了这份共享记录，一堆各干各的智能体才算真正连成了一个系统。

3.2 一个形象的比喻

有个比喻特别贴切：

Graph Engineering就是给智能体画一张“组织架构图”。

一家公司不会让同一个人把调研、写作、审核一口气全包了，而是拆成不同岗位，让活儿在岗位之间流转。

智能体的图，走的是同一个道理——专门的角色，说好的交接，一份共享的档案。

3.3 Loop vs Graph核心差异

对比维度	Loop Engineering	Graph Engineering
核心单元	单个Agent反复循环	多个节点（Agent/代码）协作
解决的问题	AI不能处理长上下文	多AI协同时如何组织
结构	线性、循环	网络、多维度、分支
并行能力	无（串行执行）	有（并行执行）
状态管理	每次循环重置	共享状态贯穿全流程
定位	AI编程1.0时代	AI编程2.0时代

关键理解：Loop并没有被淘汰，它只是从主角变成了基础单元。一个Loop适合解决“同一个目标反复逼近”的问题，而Graph Engineering把多个这样的Loop组织成一张协作网络。

四、Graph是怎么“跑”起来的？

有些小伙伴可能会问：“图结构我懂了，但具体是怎么执行的？”

4.1 DAG是基础

Graph Engineering最核心的底层数据结构是有向无环图（DAG）。

图中的节点代表工作单元，边代表数据流或依赖关系。

整个系统通过DAG来调度任务的执行顺序。

4.2 并行执行的秘密

Graph Engineering最基础的能力，是看清任务之间真正的依赖关系：哪些任务需要等待，哪些任务可以同时开工。

比如，“总结这个文件，然后查一下天气”——这两个步骤在自然语言层面是连续的，但它们之间没有数据依赖。天气查询不需要文件总结的结果。

如果按照线性脚本设计，天气查询就会被迫等待一个与自己无关的任务完成。

执行顺序被误认为数据依赖，这是很多Agent工作流慢的根本原因。

图片

4.3 节点设计原则

要把一个节点放进Agent图中，它得有清晰的职责边界。一个可自由组合的节点得定义清楚三件事：

输入是什么
输出是什么格式
下游如何使用这个结果

有了明确的约定之后，节点才更像一个标准的软件组件，可以被移动、替换和复用。

五、一个真实的Graph

下面我们用LangGraph的伪代码来演示一个典型的多Agent协作图。

5.1 场景：知识库问答系统

假设我们要构建一个系统，用户提问后，系统需要：

分析用户意图
根据意图选择不同的知识来源搜索
综合搜索结果生成答案

from langgraph.graph import StateGraph, END from typing import TypedDict, List # 1. 定义共享状态 class AgentState(TypedDict): question: str intent: str search_results: List[str] answer: str # 2. 定义节点（每个节点干一件事） def classify_intent(state: AgentState) -> AgentState: """节点1：分析意图""" # 调用LLM判断用户问的是代码、文档还是通用问题 state["intent"] = "code" # 示例 return state def search_github(state: AgentState) -> AgentState: """节点2a：搜索GitHub""" state["search_results"].append("GitHub结果1") return state def search_notion(state: AgentState) -> AgentState: """节点2b：搜索Notion""" state["search_results"].append("Notion结果1") return state def search_slack(state: AgentState) -> AgentState: """节点2c：搜索Slack""" state["search_results"].append("Slack结果1") return state def synthesize(state: AgentState) -> AgentState: """节点3：综合生成答案""" state["answer"] = "根据GitHub、Notion和Slack的结果..." return state # 3. 构建图 graph = StateGraph(AgentState) # 添加节点 graph.add_node("classify", classify_intent) graph.add_node("github", search_github) graph.add_node("notion", search_notion) graph.add_node("slack", search_slack) graph.add_node("synthesize", synthesize) # 定义边 graph.set_entry_point("classify") # 条件边：根据意图决定走哪条路 graph.add_conditional_edges( "classify", lambda state: state["intent"], { "code": "github", "doc": "notion", "general": "slack" } ) # 并行执行后汇聚 graph.add_edge("github", "synthesize") graph.add_edge("notion", "synthesize") graph.add_edge("slack", "synthesize") graph.add_edge("synthesize", END) # 4. 执行 app = graph.compile() result = app.invoke({"question": "如何用Spring Boot写一个REST API？"}) print(result["answer"])

代码拆解：

State是共享的：所有节点读写同一个State对象
节点是专注的：每个节点只干一件事，输入输出明确
边是灵活的：条件边让系统可以根据运行时状态选择路径
并行是自然的：三个搜索节点互不依赖，可以并行执行

这种图结构的好处是：你把“应该怎么走”的规则编码进了图里，而不是指望LLM每次都做对决策。

七、你已经在用Graph了

有些小伙伴可能觉得Graph Engineering是“理论概念”，离实际开发还远。

但实际上，你每天用的AI编程工具，背后已经是Graph在驱动了。

7.1 Claude Code：Subagent本身就是Graph

Claude Code的子Agent（Subagent）机制，本质上就是把一个复杂任务分解成多个节点，让它们并行或者按依赖顺序执行。

每个子Agent是一个独立的工作节点，主Agent通过Task工具调度它们。

任务完成后再把结果汇总回来。

图片

你每次在Claude Code里说“帮我分析这个项目的依赖”时，背后可能已经触发了3-5个子Agent并行工作——只是你没有感知到而已。

这就是Graph思想在工具层面的落地。

7.2 Cursor：Composer的多文件编辑

Cursor的Composer功能背后同样是Graph思想。

它把“修改多个文件”这个任务拆成一个个独立的编辑任务，并行执行，最后汇总成一个diff。

7.3 OpenClaw：从Loop到Graph的主动迁移

OpenClaw团队发现一个关键问题：随着任务复杂度增加，单Loop模式会出现“上下文腐化”——Agent越往后越容易偏离目标，而且很难回到正确轨道。

他们的应对方案是：把一个“巨大的Loop”拆成“多个小Loop + 一个协调层”。

协调层负责创建和维护多个子任务，每个子任务独立运行在各自的Loop中，最后统一收集结果。

OpenClaw的实践：用户发出“帮我重构这个项目”的指令后，主Agent创建一个“分析图”和一个“实施图”。

分析图里有多个节点并行分析不同模块，每个节点在自己的Loop里运行；实施图同样拆分成多个并行任务。

每个节点完成任务后返回结果，最终汇总给用户。

这套方案带来的效果：主Agent的上下文不再被单个任务的执行过程污染，Agent可以稳定运行。

用户反馈“执行大型重构项目时更加可靠”。

八、用LangGraph构建代码审查Agent

光说理论不够，我们来看一个完整的、可运行的实战案例——用LangGraph构建一个多Agent代码审查系统。

8.1 场景描述

用户提交一个PR，系统需要：

拉取代码变更
三个Agent并行审查：安全Agent、性能Agent、规范Agent
汇总三个Agent的审查结果
生成综合报告

8.2 实现代码

from langgraph.graph import StateGraph, END from typing import TypedDict, List import asyncio # 定义状态 class PRState(TypedDict): pr_url: str changed_files: List[str] security_review: str performance_review: str style_review: str final_report: str status: str # 节点1：拉取PR变更 def fetch_pr_changes(state: PRState) -> PRState: # 模拟：通过GitHub API拉取变更文件列表 state["changed_files"] = ["user_service.py", "order_service.py"] state["status"] = "fetched" return state # 节点2：安全审查 def security_agent(state: PRState) -> PRState: # 模拟：检查SQL注入、XSS、密钥泄露等安全问题 time.sleep(2) # 模拟耗时 state["security_review"] = "✅ 未发现安全问题" return state # 节点3：性能审查 def performance_agent(state: PRState) -> PRState: # 模拟：检查N+1查询、循环优化等性能问题 time.sleep(1.5) state["performance_review"] = "⚠️ 发现一处潜在性能瓶颈" return state # 节点4：代码规范审查 def style_agent(state: PRState) -> PRState: # 模拟：检查命名规范、代码格式化等问题 time.sleep(1) state["style_review"] = "✅ 代码规范通过" return state # 节点5：汇总并生成报告 def generate_report(state: PRState) -> PRState: report = f""" # PR代码审查报告 ## 安全审查 {state['security_review']} ## 性能审查 {state['performance_review']} ## 规范审查 {state['style_review']} ## 结论 """ state["final_report"] = report state["status"] = "completed" return state # 构建图 builder = StateGraph(PRState) builder.add_node("fetch", fetch_pr_changes) builder.add_node("security", security_agent) builder.add_node("performance", performance_agent) builder.add_node("style", style_agent) builder.add_node("report", generate_report) # 定义流程 builder.set_entry_point("fetch") # 三个审查Agent并行执行（通过边指向同一个目标） builder.add_edge("fetch", "security") builder.add_edge("fetch", "performance") builder.add_edge("fetch", "style") # 三个Agent完成后汇聚到report builder.add_edge("security", "report") builder.add_edge("performance", "report") builder.add_edge("style", "report") builder.add_edge("report", END) app = builder.compile() # 执行 result = app.invoke({ "pr_url": "https://github.com/example/repo/pull/123", "changed_files": [], "status": "init" }) print(result["final_report"])

8.3 这个案例的价值

并行执行：三个审查Agent同时运行，总耗时≈最慢的那个（2秒），而不是三者之和（4.5秒）。

状态共享：所有Agent读写同一个State对象，数据自然流转，不需要额外做数据传递。

可扩展性：想加一个新的审查维度（比如“兼容性审查”）？只需要加一个节点、加一条边，不影响现有逻辑。

故障隔离：一个审查Agent失败了，不影响其他两个。报告节点可以基于已有的审查结果生成部分报告。

九、如果我想用Graph，该做什么？

有些小伙伴可能会问：“概念我懂了，但具体怎么开始？需要学什么？”

9.1 三个入门路径

路径一：工具优先——直接用LangGraph

如果你想快速上手，LangGraph是最成熟的工具。

从安装到跑通第一个Agent图，不需要改现有代码，可以先在自己的机器上跑一跑。

pip install langgraph

然后照着LangGraph官方文档的Quickstart跑一遍，20分钟就能体验“节点+边+状态”的基本流程。

路径二：框架优先——用现有框架的Graph能力

如果你已经在用特定的Agent框架，可以先用它的Graph能力：

框架	Graph能力	入门参考
LangGraph	DAG + 循环 + 状态管理	官方Quickstart
Microsoft AutoGen	多Agent协作图	官方示例
Google ADK	任务编排图	官方文档
Claude Code	Subagent并行	内置，用Task工具
OpenClaw	多Loop图	社区示例

路径三：思想优先——重构现有代码

如果暂时不想引入新框架，也可以先调整思路：

把一个大任务拆成多个独立子任务
定义每个子任务明确的输入输出
让多个子任务并行执行
最后汇总结果

这个思路在代码层面实现起来并不复杂，关键是改变你对任务组织方式的思考。

9.2 什么时候需要认真考虑引入Graph？

我用几个信号来判断：

任务可以拆成多个独立执行的子任务（并且并行执行能显著提速）
多个Agent需要分阶段协作（A做完给B，B做完给C，还要有条件分支）
同一个任务类型需要在多个Agent之间流转，且流转规则相对固定
你的Loop已经变得非常庞大，难以维护

满足上面任意一条，Graph就值得你花时间研究了。

9.3 一个实战建议

有些小伙伴可能已经忍不住想上手了。

我的建议是：先别急着写代码，先把你的任务画成一张图。

拿一张纸，把你要做的事情拆成节点。

问自己三个问题：

问题一：这个任务能拆成几个独立步骤？

把每个步骤写在纸上，用圆圈框起来。步骤越细越好——比如“查数据库”是一个节点，“调外部API”是另一个节点，“生成回复”是第三个节点。

问题二：这些步骤之间有什么依赖关系？

在步骤之间画箭头。A做完才能做B？还是A和B可以同时做？箭头表示数据流向。

问题三：哪些步骤可以并行？

找出那些没有箭头的节点——它们之间没有依赖关系，可以同时开工。把它们用虚线圈出来，这就是你优化的第一个目标。

把这张图贴在屏幕旁边，然后在脑子里或文档里跑一遍：数据从第一个节点流到最后一个节点，每个节点拿到输入、产出输出。

确认流程没问题之后，再对照这张图去写代码——你用代码复现你手画的图，每一个节点就是一段函数代码，每一条边就是一个流程控制逻辑。

这张手绘图，比任何现成的框架都更有指导意义。

十、优缺点

优点

1. 并行执行，效率大幅提升图结构天然支持并行——互不依赖的任务可以同时执行。原来串行要等10秒的任务，并行可能3秒就完成了。

2. 职责清晰，易于维护每个节点只干一件事，就像代码里的单一职责原则。改一个节点不影响其他节点。

3. 可复用、可组合节点定义清晰的输入输出约定后，可以被移动到不同的图中复用。

4. 可控性强你把“应该怎么走”的规则编码进了图里，而不是指望LLM每次都做对决策。需要Agent走特定路径时，图能帮你严格控制行为。

5. 状态可追溯共享状态贯穿全流程，每一步都有记录。出问题可以回溯到具体节点。

6. 故障隔离一个节点失败了，不影响其他独立节点。

7. 已有成熟工具支持LangGraph、微软AutoGen、Google ADK等框架早就把节点、边、扇出扇入做成了现成积木。LangGraph目前月下载量已超过6500万次。

缺点

1. 学习曲线陡峭从线性思维切换到图思维需要时间。节点、边、状态、条件路由、扇入扇出……概念不少。

2. 过度设计的风险简单任务杀鸡用牛刀——一个单Agent循环就能搞定的事，硬画一张图反而更复杂。

3. 调试复杂度增加多个节点并行执行，出问题时的排查难度比线性流程高。

4. 不是银弹图是组织多Agent协作的工具，不是解决所有AI工程问题的万能药。

5. 概念仍在演进中Graph Engineering的定义还在快速变化中。今天学的东西，可能过两周又变了。

十一、适用场景

场景	推荐程度	理由
多Agent协作系统	强烈推荐	天然适合分工协作
复杂工作流编排	强烈推荐	条件分支、并行执行、循环控制
知识库问答（多源检索）	强烈推荐	并行搜索多个数据源后聚合
代码审查系统	强烈推荐	同时检查安全、性能、规范
电商订单处理	强烈推荐	订单→库存→支付→物流多节点协作
简单单Agent任务	❌ 不推荐	杀鸡用牛刀
纯确定性流程	⚠️ 需评估	用普通工作流引擎可能更简单