Graph Engineering：换了名字的动态工作流？

Graph Engineering 把 Agent 系统设计成显式图而不是隐式循环由能力节点、类型化边和按边存档的结构化状态组成。最近 AI 圈又出现了一个新词Graph Engineering。有人甚至喊出了“Loop Engineering 已死Graph Engineering 永生”。如果你刚看过 Claude Code 的动态工作流很容易产生一个直接的疑问这不就是动态工作流吗在 Agent 编排的实践语境里二者说的基本是同一件事。它们都在解决如何把复杂任务拆成多个执行单元如何根据依赖关系安排串行、并行、分支和返工如何保存进度以及如何让不同 Agent、普通代码和人工审批共同完成一条长流程。区别主要不在“做什么”而在“站在哪一层说”Graph Engineering 是对这类工作的抽象命名动态工作流是 Claude Code 给出的一种具体实现而且强调执行图由模型针对当前任务动态生成。换句话说如果只讨论 Claude Code完全可以把动态工作流理解为 Graph Engineering 的产品化版本如果把视野扩展到 LangGraph、Temporal、Prefect 或自研调度器Graph Engineering 的范围才会显得更大。它不仅包括动态生成的多 Agent 流程也包括工程师提前写好的静态状态图甚至节点并不是 Agent、而是普通代码、数据库查询或人工操作的流程。从 Loop 到 Graph真正变化的是什么Loop Engineering 关注的是一个 Agent 怎样不断读取任务、调用工具、观察结果、修正错误直到满足停止条件。它解决的是单个执行单元内部的可靠性。Graph Engineering 关注的则是当任务已经大到无法由一个 Agent 从头做到尾时多个执行单元应该如何协作。因此Loop 并没有被 Graph 淘汰。一个 Loop 本身就是一张最简单的图一个节点加上一条指回自己的边。真实系统中Graph 的每个 Agent 节点内部通常仍然运行着这样的 Loop。更准确的关系是Loop 管节点内部Graph 管节点之间。之所以现在开始强调 Graph是因为模型的单步能力逐渐可用以后新的瓶颈变成了任务调度。一个 Agent 在长对话里串行完成所有事情小任务没有问题任务一大就会暴露出结构性缺陷后端、前端和测试明明可以同时推进却只能排队中间执行失败全部状态埋在聊天记录里很难只恢复出错的部分流程想暂停等待审批也没有自然的挂起点如果想表达“一个规划者、三个并行执行者、一个独立审查者”单一 Loop 只能靠越来越复杂的 Prompt 勉强模拟。Graph Engineering 做的事情其实很朴素把隐含在长对话里的任务结构显式画出来。节点负责工作边负责调度状态负责保存进度和产物。没有依赖的节点并行有依赖的节点按顺序执行多个分支完成后在汇合点集中处理验证失败时只把问题分支送回返工涉及上线、付款或高权限操作时让流程停在人工节点等待确认。这套思路并不新。工作流引擎、状态机和 DAG 调度器早就在使用节点、边和状态。新的地方是今天节点里可以放一个能力相当强的 Agent。过去节点通常是一段确定性代码现在一个节点可能自己读代码、调用工具、反复尝试并返回结构化结果。于是工程重点从“如何编排若干 API 调用”上移到了“如何编排若干具备自主执行能力的 Agent”。真正的并行而不是 Agent 嘴上说 “同时进行”一个大 Loop 通常仍然是在一个上下文中依次决定下一步。Graph 则可以明确表达规划 ├─ 后端 ├─ 前端 └─ 测试 ↓ 汇合调度器看到三条独立边后可以真实启动三个 worker再等待它们汇合。Graph 提供的是fan-out和fan-in的调度语义。把 “必须遵守” 从提示词变成执行规则例如测试不通过禁止部署对外发送前必须人工审批审查节点只有读权限花费超过预算停止继续分支三个搜索节点全部结束才能开始综合。如果只写在 Prompt 里这是希望模型记得遵守写成边、权限和状态条件后则是调度器强制执行。LangChain 将 Graph 的主要价值概括为把系统应当遵守的结构、合法路径及确定性步骤直接编码进去而不是所有决定都依赖模型临场判断。上下文隔离后端节点只需要 API 契约和后端代码测试节点只需要验收标准和接口定义。它们不必共享所有聊天记录。这样做的价值不是 “多个 Agent 比一个 Agent 更聪明”而是每个上下文更干净不相关的工具输出不会互相干扰每个节点可以使用不同模型、工具和权限汇合时只传递结构化产物而不是全部中间过程。可以看清到底坏在哪里一个大 Loop 最容易观测的是 “最终答案好不好”Graph 还可以观测哪个节点最常失败哪条路由经常判断错误哪个节点消耗最多重试发生在哪里人工审批卡了多久最终成功走的是哪条路径。也就是说Graph 把 Agent 从一个黑盒调用变成多个可以分别测试、替换和评价的故障域。Josh 因此主张不仅评价输出还要评价执行轨迹。为什么它看起来就是动态工作流把 Claude Code 动态工作流放到这个模型里几乎可以一一对应。动态工作流中的agent()调用就是节点。这个节点可以负责实现、审查、检索或验证也可以使用不同模型、不同工具和独立 worktree。JavaScript 的顺序、条件和循环构成边parallel()表达并行扇出和屏障汇合pipeline()表达每个条目独立流过多个阶段。JavaScript 变量、任务列表和 Agent 的结构化返回值构成状态JSON Schema 则是节点之间的接口契约。运行时保存的执行进度承担了 checkpoint 的作用使中断后的工作流能够复用已经完成的结果。如果把它翻译成 Graph Engineering 的语言大概就是Graph EngineeringClaude Code 动态工作流Nodeagent()、普通 JavaScript、验证者或人工确认Edge顺序、条件、循环、parallel()和pipeline()StateJavaScript 变量、任务列表、Schema 化结果和执行进度Fan-out / Fan-in并行启动多个 Agent再等待必要结果汇总Checkpoint保存工作流进度中断后恢复并复用已完成结果权限与隔离独立上下文、不同模型与工具、可选 worktreeHuman-in-the-loop启动确认、权限确认和最终人工验收Claude Code 的六种动态工作流模式——分类并行动、扇出并综合、对抗式验证、生成并筛选、淘汰赛、循环直到完成——本质上就是六种常见的 Agent Graph 拓扑。所谓 Graph Engineering只是把这些模式统一放回节点、边和状态的语言里讨论。真正值得区分的只有“图由谁来设计”。传统 LangGraph 通常由工程师提前声明节点、边和 State Schema图的拓扑相对稳定Claude Code 动态工作流则让用户给出目标、约束和验收条件再由 Claude 为当前任务即时生成一段 JavaScript harness。任务拆法、节点数量、并行方式和验证步骤都可以随输入变化生成之后再由独立运行时执行。因此可以把两者的关系压缩成一句话Graph Engineering 是方法论动态工作流是自动生成 Graph 的运行机制。就 Agent 编排的实际工作而言它们高度重合。一张 Graph 怎样跑起来假设要给一个系统增加数据导出功能。后端要写导出接口前端要增加按钮和进度条测试要补对应的用例。如果交给一个 Agent 串行执行它会先写后端再写前端最后补测试。这个过程能跑但没有利用三项任务之间的独立性。换成 Graph第一步仍然是一个规划节点。它把需求拆成后端、前端和测试三份任务同时确定一份共同的 API 契约并把契约写入状态。然后图从规划节点扇出三条边三个开发节点在独立 worktree 中同时工作。每个节点内部依然运行普通编码 Loop理解任务、修改代码、自测、修正、提交。三条分支完成后在集成节点汇合。集成节点合并修改并运行全量测试。接下来是一条条件边测试通过就进入人工确认测试失败就根据测试结果找出出错模块把相应任务标记为返工再交回那个开发节点。因为其他分支的产物和状态已经保存所以没有必要全部重跑。返工完成后重新进入集成节点直到测试通过。最后流程停在人类节点等待开发者检查 diff 并确认是否合入主干。规划 ├── 后端开发 ──┐ ├── 前端开发 ──┼── 集成测试 ── 通过 ── 人工确认 ── END └── 测试开发 ──┘ │ 失败 ↓ 问题分支返工 │ └────────→ 重新集成这套流程既可以由开发者用 LangGraph 明确写出来也可以由 Claude Code 根据一句需求描述生成动态工作流。二者最后执行出来的结构可能非常接近差别只是前者由人预先编码后者由模型在任务到来后生成。状态在这里不是可有可无的记录而是整个系统能够返工和恢复的基础。它至少会保存共同契约、每个分支的状态、产物路径、测试结果、预算和 token 使用量。例如{api_contract:docs/api/export.md,backend:{status:done,artifact:api/export.js},frontend:{status:running},tests:{status:pending},test_result:null,tokens_used:12000}图本身并不会自动带来存档。LangGraph 需要配置 checkpointer其他框架也需要数据库、日志或持久化执行引擎。Claude Code 动态工作流则由其运行时维护执行进度恢复对应会话时复用已经完成的 Agent 结果。无论使用哪种实现核心都一样状态必须从聊天记录里抽出来变成程序可以读取和验证的对象。Graph Engineering 不只是“多派几个 Agent”如果把 Graph Engineering 理解成“多开几个 Agent 并行干活”很容易做出昂贵但不可靠的系统。真正的工程工作不在 Agent 数量而在节点边界、依赖、权限和验证。首先不是每一步都应该交给模型。测试是否通过、金额是否超过阈值、文件是否存在这类判断应该由确定性代码完成。模型适合处理语义分类、任务拆解和开放式分析确定性规则适合控制高风险分支。能写死的边尽量写死把模型判断留给确实需要理解语义的地方。其次边必须代表真实依赖而不是文本中的先后顺序。“总结这份文件然后查天气”虽然用了“然后”两项工作却没有数据依赖应该并行。大量所谓 Agent Graph 只是把串行清单画成流程图没有得到任何调度收益。再次评审 Agent 并不会自动提供独立证据。多个 Agent 使用相同模型、读取相同上下文时可能规模化地产生一致但错误的结论。真正有效的验证应尽量来自系统外部编译器、真实测试、权威信源、生产指标或者人工评审。独立 Agent 可以帮助发现问题但不能取代客观验证器。最后节点应该拥有最小权限。读取不可信网页内容的 Agent 不应同时拥有发布、付款或修改生产系统的能力。更安全的做法是让第一个节点只负责分析并输出结构化建议再由受控节点根据明确规则执行高权限动作。Graph 的一个实际价值就是把过去集中在同一个 Agent 身上的工具权限拆开。Bun 重写典型案例Bun 从 Zig 到 Rust 的重写既是动态工作流案例也是非常典型的 Graph Engineering 案例。Jarred Sumner 使用约 50 个 Claude Code 动态工作流连续运行 11 天处理 535,496 行 Zig 源代码最终形成约 75 万至 78 万行 Rust 代码。公开数据还包括 5.9B uncached input tokens、690M output tokens、72B cached input reads按 API 价格估算约 16.5 万美元。现有测试套件约 99.8% 通过并且没有通过删除或跳过测试来达成这一结果。但这个案例的关键不是“同时开了很多 Claude”而是它把工作组织成了一张明确的图。迁移开始前工作流先生成PORTING.md和LIFETIMES.tsv建立所有节点共同遵守的迁移契约随后把 1,448 个.zig文件分配给实现 Agent每个实现再交给两个独立的对抗式评审者之后由修复节点处理反馈。进入编译阶段后错误按 crate 分组并行修复测试阶段则形成循环持续处理失败直到满足停止条件。项目一开始也暴露了 Graph 设计不当的问题。大量 Agent 共享同一工作区时有的执行git stash有的执行stash pop还有的执行reset彼此覆盖。后来流程被改成四个 workflow shard每个 shard 使用独立 worktree并限制 Git 和高资源命令。这件事说明并行不是简单地把 Agent 数量调大资源隔离和写入冲突本身就是 Graph Engineering 的一部分。Bun 案例证明了动态 Graph 可以显著扩大实现吞吐却没有证明大量 AI 生成代码天然可靠。旧测试没有覆盖的问题新实现同样可能逃过测试。因此迁移完成后仍需要 fuzzing、rollout 和人工监督。动态工作流放大的是执行能力可信度仍来自迁移契约、编译器、测试、独立审查和人。什么时候值得使用Graph 并不是任务越小越好。写一个脚本、修一个范围明确的 bug、做一次简单查询单个 Agent 顺序执行通常最省时间。只有当任务能切成真正独立的分支并行能显著缩短耗时或者流程需要独立验证、权限隔离、人工确认、长期运行和断点恢复时Graph 才能抵消额外的协调成本。另一个关键前提是存在可检查的验收标准。编译是否通过、测试是否全绿、每条结论是否有来源、全部文件是否处理完成这些都能构成可靠停止条件。如果任务没有客观验证器只是让多个同类 Agent 互相评价图可能只是更昂贵的自我确认机制。实际使用动态工作流时最重要的不是把拓扑画得多复杂而是把四件事说清楚最终目标是什么满足什么条件才算完成结果怎样被独立验证预算和权限边界在哪里。任务拆分和 Agent 数量可以动态生成但目标、验收和安全边界不应该动态漂移。最后的判断Graph Engineering 确实像是给动态工作流换了一个更大的名字。至少在 Claude Code 的上下文里两者几乎指向同一套实践把长任务拆成多个节点用程序化控制流组织并行、流水线、条件分支和循环用结构化状态连接各阶段再用外部验证器与人工节点保证结果。这个新词仍有一点价值它提醒我们不要把注意力只放在某个产品的 workflow 功能上。动态工作流是 Claude Code 的实现LangGraph 是另一种实现Temporal、Prefect 或自研调度器也可以实现同样的方法。Graph Engineering 抽出来的是这些实现背后的共同工程问题节点怎样划分边怎样路由状态怎样保存失败怎样恢复权限和预算怎样控制。所以比“Loop Engineering 已死”更准确的说法是Loop 仍然负责把一个节点做好Graph 开始负责让一群节点把一件大事做完。动态工作流就是把这张 Graph 按任务即时生成并运行起来。参考资料We Are Entering the Graph Engineering Phase3 Years of Graph Engineering with LangGraphLoops vs. graphs — PrefectLangGraph Graph DefinitionsIntroducing dynamic workflows in Claude CodeA harness for every task: dynamic workflows in Claude CodeRewriting Bun in RustMy Thoughts on the Bun Rust RewriteClaude Code in Bun in Rust