Graph Engineering：从Loop到Graph，以及 graph skill 的一次真实实践
内容提要
2026年7月出现“图工程”新词，指设计多个循环间的关系（先后、并行、依赖）。它不取代循环，而是编排循环的容器，本质是有限状态机。文章介绍goal-workflow的/graph技能，可将任务拆成DAG并分波并行执行，强调节点须有真实产物作锚点（如PR和测试），否则只是幻觉，并以pigo项目为例展示实践。
延伸解读
图工程不是取代循环，而是编排循环
文章指出，图工程并非新发明，而是为Agent编排中的老问题命名。循环是干活的最小单元，图则是协调多个循环的容器，决定谁先谁后、谁能并行。因此“循环还是图”是假问题，图里本就跑着循环。理解这一点，有助于避免被新词炒作带偏，把注意力放回任务拆分、依赖表达和状态管理等实际问题上。
现实锚点：防止图变成更漂亮的幻觉
文章强调，没有现实锚点的图只是“被项目管理包装得更漂亮的大型幻觉”。每个节点的完成必须由外部产物定义，如PR号、绿色测试或CI记录，而非agent自报。依赖边应升级为guard边，锚点未落地就不放行。状态落盘可复核，确保崩溃后能从真实状态恢复。这是图工程避免Goodhart定律的关键。
控制图与数据图：先分清再动手
文章提醒，图工程中的“图”有两种：数据图以数据为节点、数据关系为边；控制图以状态为节点、转移为边。本文讨论的/graph排的是控制图，即执行顺序和并行关系。多数Agent编排需要的是控制图，而非数据血缘。动手前分清这一点，可以避免概念混淆和工具误用。
从pigo实践看/graph的落地要点
文章以pigo项目为例，展示/graph将9个节点拆成5个波次，通过拓扑分层实现并行。每个子agent在独立git worktree中工作，完成后开PR，状态写入.graph_state。关键产物是“status: shipped, pr: 191”这样的真实锚点。这验证了理论：图工程需要持久化状态、worktree隔离和现实锚点，才能可靠运行。
Q&A
什么是图工程（graph engineering）？它和循环（loop）是什么关系？
图工程是2026年7月出现的新词，指设计多个过程（往往就是多个循环）之间的关系——谁在谁之前、谁能并行、谁的输出喂给谁。它不取代循环，而是编排循环的容器，本质是有限状态机。循环是干活的最小单元，图是装循环的容器，图里头本来就跑着循环。
为什么说“循环还是图”是一个假问题？
因为循环和图本质上都是有限状态机（FSM）。循环是FSM的一种退化形态，通常是一两个状态之间反复转移；图是FSM的完整展开，多个状态、多条边，天然支持分叉与汇合。正确的操作路径是：先有循环，再画出循环周围的先后和并行关系，画出来就是一张图。
图工程中“现实锚点（Reality Anchor）”是什么？为什么重要？
现实锚点是指每个节点的产出必须与真实世界挂钩，比如测试真跑了、PR真开了、CI真过了。没有锚点，图不过是一场被项目管理包装得更漂亮的大型幻觉。锚点的作用是给“完成”这个事件配一条真实的边，判断节点是否完成要看真实产物，而不是agent的自我报告。
goal-workflow 的 /graph skill 是什么？它如何执行任务？
/graph 是 goal-workflow 套件中用于并行执行任务的 skill。它把 issue 之间的依赖建成 DAG，通过拓扑分层分成波次（waves），同一波无依赖的节点可并行执行。执行流程包括：分解、建 DAG、拓扑分层、确认、逐波执行（每个子 agent 在独立 git worktree 中干活，完成后开 PR），状态实时写入 .graph_state，并生成 graph.html 可视化。
在 pigo 项目的实践中，/graph 是如何划分波次并并行执行的？
pigo 的 Provider 对齐任务被拆成 9 个节点（#182–#190），分成 5 个波次：Wave 0 是 #182（建 provider 注册表），Wave 1 是 #183 和 #184（并行），Wave 2 是 #185，Wave 3 是 #186、#187、#188（三路并行），Wave 4 是 #189 和 #190（并行）。每个并行节点在独立的 git worktree 中运行，完成后各自开 PR。
图工程中如何给一张图扎上现实锚点？
落到工程上就三件事：1. 节点的“完成”由外部产物定义，不由 agent 自报，每个节点退出时得留下一个能被独立验证的东西，比如 PR 号、绿色测试、CI 记录；2. 依赖边升级成 guard 边，下一个节点能否开工看上一个节点的锚点是否真的落地；3. 状态落盘、可复核，整张图的进度写进可读文件，agent 崩了也能从上一个真实状态接着跑。
