一、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 EngineeringGraph 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 CodeSubagent本身就是GraphClaude Code的子AgentSubagent机制本质上就是把一个复杂任务分解成多个节点让它们并行或者按依赖顺序执行。每个子Agent是一个独立的工作节点主Agent通过Task工具调度它们。任务完成后再把结果汇总回来。图片你每次在Claude Code里说“帮我分析这个项目的依赖”时背后可能已经触发了3-5个子Agent并行工作——只是你没有感知到而已。这就是Graph思想在工具层面的落地。7.2 CursorComposer的多文件编辑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: # 模拟检查N1查询、循环优化等性能问题 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能力入门参考LangGraphDAG 循环 状态管理官方QuickstartMicrosoft AutoGen多Agent协作图官方示例Google ADK任务编排图官方文档Claude CodeSubagent并行内置用Task工具OpenClaw多Loop图社区示例路径三思想优先——重构现有代码如果暂时不想引入新框架也可以先调整思路把一个大任务拆成多个独立子任务定义每个子任务明确的输入输出让多个子任务并行执行最后汇总结果这个思路在代码层面实现起来并不复杂关键是改变你对任务组织方式的思考。9.2 什么时候需要认真考虑引入Graph我用几个信号来判断任务可以拆成多个独立执行的子任务并且并行执行能显著提速多个Agent需要分阶段协作A做完给BB做完给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任务❌ 不推荐杀鸡用牛刀纯确定性流程⚠️ 需评估用普通工作流引擎可能更简单判断标准如果你的任务天然包含多个可独立执行的子任务或者需要在多个专业Agent之间流转Graph Engineering就是合适的方案。如果只是一个Agent反复做同一件事Loop Engineering就够了。八、写在最后回到最初的问题Graph Engineering到底是什么它不是什么惊天动地的技术创新。Apache Airflow在2014年就已经在用DAG做任务编排了。LangGraph也做了三年月下载量6500万。但Graph Engineering代表了一种思维方式的转变从“让一个Agent从头干到尾”变成“拆给多个各有专长的Agent协同”从“线性串行”变成“并行协作”从“Loop是主角”变成“Loop是基础单元Graph是组织方式”要不要学我的建议是先把核心概念搞清楚——节点、边、共享状态、条件路由、并行执行。然后在实际项目中遇到“多个Agent需要协作”的场景时再考虑引入图结构。Graph Engineering的本质其实一句话就能说清楚把一个“什么都要做”的大循环拆成多个“只做一件事”的小循环然后定义好它们之间怎么交接。这就是Graph Engineering。没那么玄乎但确实很有用。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。
