Graph Engineering 精读：Agent 的计划如何进入代码
从 Prompt、Loop 与 Workflow 到 Graph，这篇精读解释 Node、Edge、State、Dynamic Workflow、Execution/Control Graph，以及 Agent 的计划、恢复、验证和权限为何需要进入显式系统。
Towards AI 在 2026 年 7 月 20 日发布的《what the hell is graph engineering really》中，试图回答一个正在变得具体的问题：当 Agent 系统不再只有一个执行者，而是同时出现并行任务、review、重试、人工批准和外部事件时，谁来保存计划，谁来记住状态，失败后又该回到哪里？
Graph Engineering更像一张工程地图：Loop 负责局部改进，Graph 负责多个过程的连接、触发、状态和权限。
核心 Insight
- Graph 由
Node与Edge构成。Node是执行或判断单元；Edge描述 Node 之间的连接关系，承载数据流、依赖、条件、触发、返回或权限。Loop 是 Edge 把流程送回已有 Node 的局部 cycle；Graph 则是整个系统的可能路径地图，也可以是一张只向前运行的 DAG。 - Dynamic Workflow 的关键变化是
plan in code。循环、分支和中间结果由 JavaScript 与 runtime 持有，模型上下文不必逐轮承担全部调度和状态管理。 - 长任务真正要迁出的，是 control plane。Context 继续承载模型理解任务所需的信息，但计划、持久状态、恢复点、预算和权限关系需要变成可检查的外部结构。
- 执行正确不等于方向正确。Execution side 安排下一步，control side 检查指标、证据、否决权和人工判断；多个 Agent 若共享同一错误上下文与 metric，只会更有组织地重复错误。
- 最小 Graph 应从失败模式生长。先做好一个带外部 verifier、持久 state 和硬停止条件的 Loop，再为已经出现的并行、审计、回滚和触发需求增加对应的 Node 与 Edge。
图 1｜Towards AI 原文封面：Graph Engineering explained, simply
*图 1｜原文封面。文章讨论如何把多 Agent 系统里的关系显式化；图算法本身并非新发明。来源：Towards AI。*
01
命名越来越多，系统问题却是同一个
Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering——过去几年，Agent 相关工程名称不断向模型外部扩展。Peter Steinberger 在 7 月 18 日发帖问：大家还在谈 loops，还是已经转向 graphs？
图 2｜Peter Steinberger 追问：讨论是否已经从 Loop 转向 Graph
*图 2｜Peter Steinberger 的公开帖成为原文的讨论入口。它说明问题正在被提出，不等于行业已经完成统一迁移。来源：原文截图。*
Towards AI 先澄清两件事。第一，没有突然出现一个名为 Graph 的新产品。第二，Loop 没有被淘汰。
真正发生的变化，是系统规模。过去的问题是“怎样让一个 Agent 持续完成任务”；现在的问题是“怎样让多个 Agent、确定性工具、检查步骤、重试路径和人工决策协同工作”。单个过程仍然可以是 Loop，但多个过程连接起来以后，需要更大的结构来描述。
Graph Engineering 这个名字的价值，暂时不在命名权。它把工程对象从一个 Agent 的行为，扩大到多个过程之间的关系。
02
Prompt 执行一次，Loop 对结果负责
Prompt 的结构很短：给模型一个输入，模型执行一次，返回结果。
Loop 多了反馈与返回。系统获得目标，执行一次，接受检查；如果失败，就带着失败信息重新行动，直到通过或者触发停止条件。
图 3｜Prompt 与 Loop：一次执行和带检查的重复过程
*图 3｜Loop 的关键不是重复次数，而是每一轮都接收可判定的反馈，并且能够退出。来源：Towards AI。*
原文把可用 Loop 的最低条件归纳为三项。
一是外部 verifier。它可以是测试、构建、schema 校验或明确状态检查，负责给出通过或失败。生成结果的 Agent 自己说“看起来不错”，不构成外部验证。
二是对话之外的 persistent state。系统要保存已经尝试过什么、为什么失败、哪些工件被修改，以及下一轮可以复用哪些结果。否则每一轮都可能只是带着更长的上下文重新猜。
三是明确出口。成功是一个出口，次数、预算、时间和无进展阈值也是出口。没有硬停止条件，把流程送回前序 Node 的 Edge 会变成无限消耗。
Hanako 在相关文章中也强调 verifier、persistent state 和 stop condition。原文借用这组结构说明：Loop Engineering 让重复过程拥有反馈、记忆与终点；单纯让 Agent 忙得更久并不够。
03
Graph 是“接下来谁做什么”的完整地图
当过程不止一个，系统开始出现 Node 和 Edge。
Node（节点）是执行或判断单元。它可以是 Agent、测试套件、reviewer、人工审批、存储工件，也可以是一段完全确定性的脚本。Edge（连接关系）定义 Node 之间怎样发生联系。它可以传递数据、表达依赖、选择条件、响应外部事件，也可以规定失败返回，以及哪个 Node 有权批准或否决下一步。
图 4｜Graph 中的 Node 与 Edge
*图 4｜Node 承担工作或判断，Edge 规定数据流、依赖、条件、触发和下一步。来源：Towards AI。*
原文用代码审查给出一个具体例子。一条新 Pull Request 到来后，可以同时触发安全、性能和代码风格审计。各路结果汇入 verifier；确认的问题交给 fixer；修复后运行测试。测试失败，返回 fixer；测试通过，才发布审查结果。
图 5｜代码审查系统：并行审计、验证、修复与测试
*图 5｜一条 PR 可以启动多个并行分支，汇合后再进入修复和测试。来源：Towards AI。*
如果只盯着 fixer 和 test，会看到一个 Loop。如果把 PR、并行审计、汇合、修复、测试和发布全部画出来，得到的是一张 Graph。
图 6｜一张 Graph 可以包含局部 Loop
*图 6｜Fix 与 test 之间的 retry 是 Graph 内部的一段 cycle。Loop 没有消失，它只是成为整张图的一部分。来源：Towards AI。*
这个例子解决了文章最容易被误读的地方：Loop 与 Graph 不是两代互斥架构。Loop 描述局部返回路径，Graph 描述整个系统。
04
Graph Engineering 没有否定 Workflow Engineering
Anthropic 在 2024 年发布的《Building effective agents》中，将 workflow 和 agent 区分为两类 agentic system。Workflow 通过预先编码的路径编排 LLM 和工具；Agent 则由模型动态决定过程与工具使用。
同一篇文章列出五类常见 workflow pattern：prompt chaining、routing、parallelization、orchestrator-workers 和 evaluator-optimizer。它们都包含承担工作的 Node 和规定流向的 Edge，因此都可以画成图。
Towards AI 据此把 Graph Engineering 理解为观察尺度的扩大。Workflow Engineering 研究一个 process 怎样运行；Graph Engineering 继续追问，不同 process 怎样连接，由什么事件触发，信息怎样流动，发生冲突时谁做决定。
图 7｜从单个 Workflow 到多个共享 State 的连接过程
*图 7｜Graph 关注多个过程之间的关系；state 说明系统现在位于哪条路径，并保存此前发生过什么。来源：Towards AI。*
Graph 与 state 在这里必须分开理解。Graph 是可能路径的地图。State 是运行中的事实：哪些任务已经完成，各 Agent 产出了什么，哪些检查失败，是否获得人工批准，以及失败后从哪里恢复。
这也是 Graph Engineering 与“多画几个框”之间的区别。没有 state、权限和恢复语义的图，只能展示结构，不能运行系统。
05
为什么现在需要把关系显式化
工作流、DAG、状态机和分布式系统都不是新发明。变化发生在 Node 内部：越来越多 Node 运行的是概率性、上下文依赖的 Agent，而不是只执行固定规则的程序。
固定程序在同样输入下通常沿着可预期路径执行。Agent 会解释任务、选择工具、决定下一步，也会受上下文污染、遗漏和不确定输出影响。系统一旦扩展到数百个文件、多个代码库、多种数据源或数小时执行，一个聊天上下文就很容易承担过多职责。
原文给出的描述很直接：巨大的 context window 同时充当数据库、调度器、日志和项目经理。沿着这条逻辑继续推，质量判断和权限控制也会被塞进同一处。
结果是，Agent 可能忘记某条分支为什么存在，review 结果可能污染后续步骤，失败任务没有干净恢复点，重启后也很难判断哪些状态可信。
Graph 的作用，是迫使系统回答具体问题：哪些任务能并行，哪些 state 可以跨 Node 存活，什么算证据，谁能拒绝结果，哪些失败应该重试，重启后保留什么，人工批准放在哪条 Edge 上，以及预算何时停止。
新变化不在图。新变化在 Node 的不确定性，以及系统为此必须显式承担的控制责任。
06
Claude Code Dynamic Workflows：计划进入代码
Claude Code 的 dynamic workflows 是原文最具体的产品例子。按当前官方文档，Claude 会根据任务编写一个 JavaScript workflow，后台 runtime 负责执行。脚本可以编排 subagents、并行任务、review 与 retry，中间结果保留在脚本变量中，而不是全部回到 Claude 的上下文。
官方把这一步概括为：A workflow moves the plan into code.
图 8｜普通 Subagents 与 Dynamic Workflow 的差别
*图 8｜普通模式中，结果逐轮回到 Claude context 决定下一步；dynamic workflow 由代码和 runtime 持有循环、分支及中间结果。来源：Towards AI 对官方机制的解释图。*
这句话不能扩展成“Claude 退出规划”。Claude 仍然编写 workflow，Agent Node 也继续处理开放式任务。变化在运行期：分支、循环、中间结果和恢复路径由可执行脚本持有，不再全部依赖模型在每一轮对话中重新维持。
Mario Zechner 将 dynamic workflows 解读成 directed graph，并进一步追问：能否由外部事件触发不同 subgraph？
图 9｜Mario Zechner 对 Directed Graph 与外部触发的解读
*图 9｜Mario 的帖子把 dynamic workflow 解释为有向图，并把问题推向 external event → subgraph。它是工程解读，不是官方产品定义。来源：原文截图。*
如果 Pull Request、webhook 或定时事件能够启动子图，多段 workflow 就可以连接成更大的长期系统。这是 Graph 视角自然提出的下一步，但原文与 Mario 的延伸不能写成 Claude Code 已经承诺完整 external-event graph platform。
07
DAG 与 Cycle：有没有返回 Edge，代价不同
DAG 是有向无环图，只向前运行，不回到已有 Node。带 cycle 的 Graph 则允许验证失败后沿某条 Edge 返回此前步骤。
一项研究任务可以先拆成多个并行分支，各自搜集材料，再交叉检查并生成报告。只要整个过程向前汇合，它就是 DAG。如果 verifier 发现某个 claim 缺乏支持，并把任务退回 research，系统就出现 cycle。
图 10｜研究 Workflow 中的 DAG 与 Cycle
*图 10｜左侧任务只向前汇合；右侧在 unsupported claim 出现时返回 research，因此形成 cycle。来源：Towards AI。*
一条返回 Edge 会新增三类问题。哪些旧结果仍然可信，可以复用？哪些分支必须重跑？连续失败多少次后停止？
这说明 Cycle 不只是“更智能的自我改进”。它同时购买了额外计算、状态一致性和终止治理。Graph 可以有 Loop，但每一条返回 Edge 都应该说明恢复语义和成本边界。
08
Execution 让系统运行，Control 检查方向
Towards AI 在后半段把 Graph 分成两个相互连接的职责。
Execution side 回答“接下来运行什么”。它处理分支、并行、review、retry 和 handoff。
Control side 回答“系统是否仍朝正确目标前进”。它检查 metric、audit、authority 与 human veto。这里的 execution graph、control graph 和 reality anchor 属于 Towards AI 与 Carlos E. Perez 的来源综合，不是 Anthropic 官方架构字段。
图 11｜Execution Graph、Control Graph 与 Reality Anchor
*图 11｜执行关系安排工作，控制关系通过审计、指标、权限和现实结果检查方向。来源：Towards AI。*
原文用客户支持解释 Goodhart 问题。系统如果只优化结单速度，Agent 可以通过提前结束困难对话得到更好的局部指标。每个 Loop 都完成了任务，客户却可能再次打开问题，甚至直接流失。
控制关系要把局部指标连接到更外部的结果：reopen、retention、真实到账的收入、实际执行的测试、物理系统测量，以及人类对“什么叫更好”的判断。Reality anchor 不提供绝对无偏真值。它的作用是阻止系统只在自己生成的报告与指标中循环确认。
这也解释了多个 Agent 为什么不自动提高可靠性。相同模型读取相同错误上下文，使用相同坏 metric，可以规模化地互相同意。一个 Agent 写报告，另一个 Agent 用同源材料审报告，第三个 Agent 再看同一 dashboard；所有 Node 都一致，证据仍然没有触及现实。
原文称这种状态为高度组织化的错误。Graph 的结构越漂亮，并不能替代独立证据。
09
Graph Engineer 设计的是边界、状态与权限
按照原文的定义，这项工作与分布式系统和 workflow engineering 高度连续。它并不要求一个全新的基础学科，而是把几类设计责任集中起来。
第一类是 Node 边界。什么适合交给概率性 Agent，什么应该保持为确定性代码；worker 之间传递原始材料、结构化 state，还是压缩后的结论。
第二类是失败语义。Retry 是否局部发生，timeout 与 budget 怎样设置，哪些工件可以复用，哪些失败必须清空上下文重来。
第三类是检查分离。Maker 和 checker 是否使用不同证据，reviewer 有没有阻止部署的权限，优化 Agent 能否修改自己的测试。
第四类是触发与授权。Subgraph 能不能调用另一个 subgraph，哪些外部事件可信，哪些操作必须取得人工批准，系统何时必须主动唤醒人类。
Prompt Engineering 负责向模型表达意图。Loop Engineering 让一个过程持续追求意图。Graph Engineering 设计多个过程之间的关系。名称可能是新的，困难本身并不新。
思考
Context 应该退出 Control Plane
读完整篇以后，我对 Graph Engineering 的理解发生了一个变化。最值得保留的是职责迁移，Graph这个词反而在其次。
Context window 很适合承载模型需要理解的局部世界：任务说明、相关文件、最近观察和当前假设。它不适合长期独自承担数据库、调度器、日志、恢复机制、预算管理和权限系统。后面这些职责需要显式状态、确定性规则和可审计的 Edge。
这并不意味着一切都要写成静态流程。相反，Graph 的价值恰好来自混合：开放问题交给 Agent，确定性动作交给代码，检查接触外部结果，关键权限留给人或不可被优化器改写的规则。
因此，Agent 系统的架构单位正在从“模型能做什么”转向“模型被放在哪种关系里”。Node 的能力决定上限，Edge 承载的证据与 authority 决定系统能否长期保持诚实。
决策工具
什么时候需要从 Loop 进入 Graph
不必用 Agent 数量作为门槛。可以按五个问题检查：
任务是否出现两个以上互不依赖、值得并行的分支？
如果没有，一条清晰 Loop 可能更容易维护。
失败后是否需要局部恢复，而不是整体重跑？
如果需要，就要显式记录 checkpoint、依赖和返回 Edge。
中间 state 是否必须跨会话、跨 Agent 或跨事件存活？
如果需要，state 应离开聊天上下文。
执行者、检查者和授权者是否应当分离？
涉及部署、支付、删除、外部通信等动作时，承载 authority 的 Edge 必须提前设计。
当前 verifier 是否接触外部结果？
如果所有检查都来自同一模型和同一材料，先增加 reality anchor，不要先增加更多 Agent。
五个问题里只有一个成立，先为那个问题加一条 Edge。不要把完整 Graph 当成默认起点。
结语
让复杂度从失败中长出来。
Towards AI 最后的建议很克制：不要一开始搭建一张 40-Agent Graph。选择一个重复任务，为它接入真实 verifier，把 state 放在可检查的位置，设置硬停止条件，然后观察它怎样失败。
只有当问题真实出现，才增加第二个 reviewer、并行分支、安全否决、局部重跑、Pull Request、webhook 或定时触发。Graph 到这里自然形成。Loop 没有被丢弃，只是获得了邻居、监督、记忆，以及一个能够如实报告失败的位置。
读完整篇，我更关心的不是 Graph Engineering 会不会成为固定叫法，而是 Agent 工程正在出现一个清晰分界：模型可以继续负责开放式判断，系统不能再把调度、记忆、验证和授权全部交给模型临场维持。Loop 仍是局部改进的最小单元，Graph 则把多个 loop、确定性工具和人的否决权组织成一个可检查、可恢复的控制平面。实践上应从一个带外部验证、持久状态和硬停止条件的 loop 开始，等真实失败暴露，再为它增加邻居和监督。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～