Graph Engineering：Agent 执行图工程的旧内核新名字与建模边界

Graph Engineering：Agent 执行图工程的旧内核、新名字与建模边界

• source_url: null
• source_type: article
• platform: manual
• author: gracker
• original_date: 2026-07-21
• added_date: 2026-07-21
• category: agents
• local_path: DeepResearch/2026-07-21-Graph-Engineering-Agent执行图工程/2026-07-21-Graph-Engineering-Agent执行图工程-深度调研.md

Obsidian evidence

日终简报将该报告列为今日两份高完成度 DeepResearch 之一：完成术语溯源、框架边界和十项工程协议检查表，质量报告通过。

Fetched / archived source

title: "Graph Engineering：Agent 执行图工程的旧内核、新名字与建模边界" date: 2026-07-21 tags:

• "deep-research"
• "graph-engineering"
• "ai-agent"
• "workflow"
• AI-Agent
• Graph-Engineering
• Workflow
• Multi-Agent

Graph Engineering：Agent 执行图工程的旧内核、新名字与建模边界

执行摘要

这份调研处理一个刚在 2026 年 7 月升温的说法：graph engineering 到底增加了什么，又把哪些老概念装进了新名字。它值得看，因为一张“多个 Agent 用箭头连起来”的图，可能分别代表工作流、通信网络或状态机，三者的实现与正确性条件差别很大。读完可以带走一套术语校准、一张模型选择表，以及一个能直接用于复杂任务的执行图检查表。

• 工作区报告：research/2026-07-21-Graph-Engineering-Agent执行图工程-深度调研.md
• 研究包：research/2026-07-21-graph-engineering-研究材料/
• Obsidian 归档：DeepResearch/2026-07-21-Graph-Engineering-Agent执行图工程/
• 发现一：近期热度来自一次命名与传播事件；有环工作流、状态图、多 Agent 路由和耐久执行都已有成熟前身。
• 发现二：graph engineering 目前适合作为 graph-based orchestration 的非标准标签，证据不足以把它放在 harness 之上，成为一层新的基础学科。
• 发现三：原图对“复杂协作需要图”的方向判断成立；“多 Agent 所以不是 DAG”“Agent 节点更像 FSM 状态”需要改写。
• 可操作结论：节点类型、边语义、状态、汇合、恢复、终止和权限一起被定义时，图才成为工程系统。
• 限制：框架结论来自 2026-07-21 的官方资料审计，没有安装各框架做故障注入；X 的实时浏览量无法稳定核验，因此不报告精确热度数字。

先把名字写对：Graph，不是 Gragh

配图与原文多次写成 gragh engineering、Directed Gragh。标准拼写是 graph engineering、directed graph。下文采用 Graph Engineering（Agent 执行图工程） 作为工作名，用来避开它与知识图谱工程、图数据库工程的同名冲突。

这个名字近期变热，可以追到一条很短的传播路径。Peter 帖子的 X status ID 按 Snowflake 规则解码为 2026 年 7 月 18 日 00:34:54.975 UTC，再用跨来源传播记录复核；原帖问：“Are we still talking loops or did we shift to graphs yet?” 约 4 小时 35 分后，Hamel Husain 发布《Loop Engineering Is Dead. Enter Graph Engineering》，随后出现多语种解释与反驳。[1][4]

这条时间线说明 Peter 是本轮传播的催化者，还不能支持“首创者”的归属。本次检索找到的 agent 语境同名公开用例至少可追到 Anthony Alcaraz 在 2025 年 5 月 11 日的帖子；Josh C. Simmons 在 2026 年 7 月 4 日已经把它写成一门关于节点、类型化边和 checkpointed state 的 discipline。[2][3] Josh 页面日期没有独立网页存档佐证，所以它能证明“7 月 18 日之前已有完整表述”，不能单独证明全球首发。

时间线更适合被称为一次命名事件。LangGraph 在 2024 年就已把 state、node 和 edge 做成 Agent 工作流原语；Anthropic 同年已经系统描述 prompt chaining、routing、parallelization、orchestrator-workers 和 evaluator-optimizer。[12][15] 新的是讨论中心和共同标签，底层计算模型没有在那一天突然出现。

五个 Engineering 不是一条升级阶梯

原图把 prompt、context、harness、loop、graph 排成连续演进。这个排法易懂，却会把包含关系和控制关系画成互相替代。

| 名称 | 它稳定回答的问题 | 主要工程对象 | |---|---|---| | Prompt engineering | 模型被要求做什么，怎样输出 | instruction、example、output contract、eval | | Context engineering | 这一次推理让模型看到什么 | retrieval、history、tool schema/result、compaction、排序与裁剪 | | Harness engineering | 模型如何获得工具、状态、权限、反馈与恢复能力 | tool dispatch、sandbox、state store、middleware、tracing、constraints | | Loop engineering | 何时再运行一次，带什么状态，何时停 | trigger、feedback、retry、verifier、stop、budget、resume | | Graph-based orchestration | 哪个节点何时运行，结果去哪，分支怎样汇合 | node、typed edge、route、fan-out/fan-in、checkpoint |

OpenAI 的 prompt engineering 文档强调有效指令、稳定输出和 eval；Anthropic 把 context 定义成每次推理时进入模型的全部 token，包括指令、工具、MCP、外部数据与消息历史。[8][7] 因而 prompt 是 context 的组成部分。Context engineering 还要决定检索、压缩、删除和隔离什么，目标是小而高信号的工作集，并非把资料尽量塞满窗口。

Harness 的边界没有行业统一口径。LangChain 采用 Agent = Model + Harness 的宽定义，把 prompt、context policy、工具、沙箱、状态、编排和可观测性都纳入其中；Anthropic 的 managed-agent 架构则拆分 session、harness、sandbox，其中 harness 专指调用模型并路由工具的循环。[10][11] 所以“给模型套一个运行环境”只描述了部分能力，沙箱甚至可能在另一个架构部件里。OpenAI 的 Codex 案例同样把 repo 结构、工具、文档、约束、反馈和可观测性列为模型外工程对象。[9]

Loop engineering 也不等于父 while 套子 while。Claude Code 团队把 loop 定义为 agent 重复一个工作周期，直到满足停止条件；Addy Osmani 的版本还包含自动触发、worktree、skill、connector、sub-agent 和外部状态。[6][5] 嵌套循环是一种实现。一个只迭代三次的 evaluator-optimizer 仍是 loop；一个持续数天却没有 verifier 和硬停止条件的进程，只是昂贵的失控执行。

Loop 与 graph 更像控制流的两个坐标：loop 描述时间上的重复和反馈，graph 描述结构上的拓扑和路由。一个图可以包含多个反馈环；一个节点内部也可以运行自己的 tool-use loop；外层 scheduler 还可以反复生成新的任务图。

“图”至少有四种，箭头必须有类型

近期文章使用同一个 graph 单词，却不总在讨论同一种对象。Carlos Perez 所说的 graph 更偏向 optimizer、checker、audit loop 的组合；一些传播文说的是 Agent 的组织和授权关系；LangGraph 说的是带共享 state 的执行图。[14][15]

可把常见对象拆成四类：

• Workflow/control graph：节点是任务、Agent、工具、验证器、人类审批或普通函数；边表示控制依赖与路由。原图中的“需求分析—信息检索—方案生成—评审—返工”最接近这一类。
• Organization/communication graph：节点是有身份的 Agent 或团队；边表示谁能委托谁、向谁发消息、访问哪些权限。运行顺序可能不在这张图里。
• State-transition graph：节点是系统完整控制状态；边是 event/input 与 guard 触发的 transition。它具备 FSM 或 statechart 语义。
• Run/trace graph：记录某一次真实执行展开了哪些节点、重试、分支和副作用。它是运行实例，不等于设计时定义图。

“A 的结果交给 B”只能说明存在一条有向关系。那条边可能传数据、消息、控制权或状态迁移；同一对节点之间还可能同时存在多种边。生产设计至少要写出 edge type、payload schema、guard、delivery semantics 和 permission，不能让箭头颜色承担全部语义。

这一拆分也揭示了 context engineering 仍然独立存在。AutoGen GraphFlow 的官方文档明确区分 execution graph 与 message graph：执行边决定谁何时运行，默认消息可见性却不会自动按执行边隔离，开发者还要配置消息过滤。[17] 把 Agent 连成图，并不会自动让每个 Agent 只看到正确上下文。

Directed Graph、DAG 与 FSM：原图哪里对，哪里要收紧

多 Agent 依赖可以是 DAG

Directed graph 允许有环，也允许无环；DAG 只是其中不含有向环的一类。A 分析需求、B 和 C 并行检索、D 汇总、E 审批，这个多 Agent 系统完全可以是 DAG。只有定义图存在显式回边，例如 review_failed → revise → review，它才是有环图。

真实流程允许返工，所以“有时需要 cyclic directed graph”成立。它不等于“真实多 Agent 流程都不是 DAG”。工程上常把 evaluator-optimizer 封装成一个节点，让外层工作流继续保持 DAG；也可以由 scheduler 创建下一次 run，或用节点级 retry 处理暂时错误。三种做法的审计、缓存和恢复语义不同。

静态结构无环，也能产生长期重复行为。Behavior tree 可以通过周期 tick 和 retry decorator 反复运行；一个 DAG 模板也可以被多次实例化。因此，“运行中发生循环”与“定义图上必须画回边”是两个判断。

Agent 节点通常不是 FSM 状态

FSM 的节点应是足以决定后续演化的有限全局状态，边由输入或事件触发。检索中、待评审、返工中、完成可以成为状态；“检索 Agent”“评审 Agent”更像进入状态后调用的 action 或 service。Agent 被替换后，流程状态协议仍可以保持不变。

配图右下角把 S0 待启动 → S1 需求理解 → S2 方案设计 画成互斥阶段，这一部分可以解释成有限状态机。左侧的 A 需求分析 → B 信息检索 → C 方案生成 把活动或角色作为节点，更接近 workflow graph。两张图不能用同一套节点语义描述。

并行是朴素 FSM 最快暴露局限的地方。若检索、安全检查和成本评估同时活跃，经典 FSM 需要枚举它们的组合状态。Harel statechart 用层级和正交区域表达并发；W3C SCXML 进一步规定 event、guard、parallel state 和 active configuration 的执行语义。[21][22]

当 AND-split、AND-join、资源竞争和同步比“当前处于哪个阶段”更重要，Petri net 或 workflow net 更贴切。系统状态是 token 的分布，任务完成会消费和产生 token。van der Aalst 的 WF-net soundness 还要求任一可达状态仍能正确到达终点，完成后无残留 token，并且不存在永远不会执行的任务。[23] 图上画一个 Done 节点，远没有这些条件严格。

主流框架早已能画环，差别在运行保证

| 框架 | 已有图能力 | 状态与恢复 | 仍需自行承担的部分 | |---|---|---|---| | LangGraph v1.x | StateGraph、条件边、并行 super-step、回边、END | 配置 checkpointer 后逐步保存，支持 interrupt/resume | state reducer、并发写冲突、副作用幂等、有效终止 | | AutoGen GraphFlow | sequential、parallel、conditional、loop | 团队 state 可 save/load | 功能仍标 experimental；消息可见性需另配 | | CrewAI Flows | 事件依赖、route、revision loop、HITL | @persist 与 resume | 没有证据表明它提供完整事件历史重放或 exactly-once 副作用 | | Google ADK 2.0 | Graph Runtime、route、back-edge、join、human input | resumability 需显式启用 | 自定义节点恢复协议、join 缺输出等边界 | | OpenAI Agents SDK | handoff、agent-as-tool、代码条件/并行/loop | RunState 可序列化，长时耐久依赖外部集成 | 没有一等 graph DSL，也没有图级 scheduler | | Temporal | 命令式 durable workflow、wait、signal、retry | event history 与 deterministic replay | 它解决耐久执行，不提供 Agent graph DSL |

LangGraph 的例子最接近原图：conditional edge 可以在评审失败时回到生成节点，recursion_limit 提供失控保护；checkpointer 为故障恢复、time travel 和人工暂停提供基础。[15][16] 但 recursion limit 只会在超限时失败，不证明业务已经收敛。Checkpoint 也不会自动让外部写操作具备幂等性。

AutoGen、CrewAI、Google ADK 都能表达反馈回路。[17][18][19] 它们对持久化的保证强度不同：保存业务 state、保存每一步 checkpoint、以事件历史重放，是三种不同能力。Temporal 揭示了最容易被新术语省略的一半：拓扑表达与耐久运行是两条轴。[20]

OpenAI Agents SDK 提供另一条反证。官方编排文档用 manager、handoff、普通 Python 条件、asyncio.gather 和 evaluator loop 组合多 Agent，并未要求先建立显式图 DSL。[25] 拓扑很小、代码所有权集中、恢复要求不高时，普通代码可能更直接。多人维护、分支繁多、需要可视化审计或跨故障恢复时，显式图才开始抵消自身复杂度。

图只负责拓扑，工程工作还要补十份协议

一个可用的工作定义是：

Graph Engineering（Agent 执行图工程）是把 Agent 系统的执行拓扑与运行语义显式建模、实现和验证的工程工作。它定义节点类型、边的控制/数据/消息语义、共享状态、分支与汇合、反馈回边、失败与恢复、权限边界、终止谓词、预算和观测方式。图可以是 DAG，也可以含环；Agent 只是可能的节点类型之一。

这是一套分析约定，不代表已经形成行业标准。若团队准备把一段 while 升级为图，至少要补齐下面十项：

1. Node contract：节点是 Agent、确定性函数、工具、router、人类审批还是 transaction；输入、输出和错误类型是什么。 2. Edge contract：边传 control、data、message 还是 transition；guard 读取哪些字段，路由理由能否审计。 3. State contract：全局 state schema、字段所有权、并行写入的 reducer/merge/conflict policy。 4. Context contract：每个节点可看哪些消息、工件和秘密；execution graph 与 visibility graph 分开配置。 5. Join contract：fan-in 等待 all、any、quorum 还是带超时的部分结果；慢分支与孤儿任务怎样处理。 6. Retry contract：节点级技术重试与业务返工回边分开计数；外部副作用使用 idempotency key、去重或 compensation。 7. Durability contract：恢复依赖 state snapshot、checkpoint 还是 event history；进程崩溃后会重跑哪些步骤。 8. Termination contract：每个环都有 progress measure、max iteration、time/token/cost budget 和 no-progress 检测。 9. Safety contract：节点按最小权限访问工具与数据；取消、超时、失败和人工升级都是明确终态。 10. Observability contract：区分定义图、执行实例与 trace，记录 latency、cost、retry、route reason、state diff 和外部副作用。

Agentproof 预印本把部分结构问题做成静态检查，例如不可达节点、缺失终点和循环风险。[24] 它使用作者构造的 18 个工作流，适合证明“图结构可以被检查”，不能外推成行业缺陷率，也不能证明 LLM 输出语义正确。Graph-level eval 仍要用真实任务、失败注入和外部完成谓词。

复杂任务怎样建模，才能让评审退回重做

原文提到的大任务可以保留 FSM 直觉，但要把“全局状态”和“执行 Agent”分开。一个较稳的骨架如下：

READY
  -> ANALYZING
  -> COLLECTING {parallel workers}
  -> SYNTHESIZING
  -> REVIEWING
       pass  -> EXECUTING -> VERIFYING -> COMPLETED
       fail  -> REVISING  -> REVIEWING
       unsafe/blocked -> HUMAN_REVIEW

这段结构用状态回答“整个 case 走到哪一步”，用活动回答“谁来做”。COLLECTING 内部可以 fan-out 多个研究 Agent，再以 all/quorum/timeout 规则汇合；REVIEWING ↔ REVISING 是有预算、有进度量的反馈环；外部写操作前增加独立审批或 transaction 节点。状态里保存路由所需的工件引用、判定和计数器，完整上下文按节点重新组装。

完成条件也要离开图形装饰，成为可执行 predicate。例如：测试全部通过、审批签名存在、目标环境返回指定版本、成本未超预算。失败后应进入 FAILED、TIMED_OUT、CANCELLED 或 ESCALATED，而非无限回到过去。

这个新名字该不该用

可以用，但首次出现时应限定为 Agent execution/workflow graph engineering。它把原先藏在 prompt、代码和人工协调中的关系显式化，特别适合讨论分支、并行、汇合、回退和跨节点治理。对图数据库、知识图谱团队，单说 graph engineering 会产生直接歧义。

它暂时还没有独有的形式模型、统一 API、统一质量指标或跨厂商规范。现有内容大都可以在 workflow orchestration、state machine、distributed systems、multi-agent coordination 与 durable execution 中找到前身。这个判断并不削弱它的传播价值：一个新标签可以促使团队把隐含控制流拿出来审查，只是不能把“画出一张有环图”当成系统已经可靠。

选型可以保持克制：单次调用能完成，先做 prompt 与 eval；一个 Agent 的 tool loop 能完成，先把 verifier、stop 和 budget 写清；固定分支、并行、审批与返工开始增多，再引入显式 workflow graph；跨小时、跨进程或跨故障运行，则增加 durable workflow runtime。[12][13][20]

原图末尾那句话可以留下半句：工程实践确实走到了需要显式描述复杂协作关系的阶段。补上的半句是：先说明画的是哪一种图，再证明它能结束、能恢复、能约束副作用。

参考资料

1. Peter Steinberger, X post, 2026-07-18 — [一手：传播原帖] 2. Anthony Alcaraz, LinkedIn post, 2025-05-11 — [一手：较早同名用例] 3. Josh C. Simmons, We Are Entering the Graph Engineering Phase — [一手：传播前完整定义] 4. SmartScope, Graph Engineering vs Loop Engineering — [二手：传播链交叉核对] 5. Addy Osmani, Loop Engineering — [一手：实践者定义] 6. Claude, Getting started with loops — [一手：产品团队定义] 7. Anthropic, Effective context engineering for AI agents — [一手] 8. OpenAI, Prompt engineering — [一手] 9. OpenAI, Harness engineering — [一手：工程案例] 10. LangChain, The Anatomy of an Agent Harness — [一手：厂商定义] 11. Anthropic, Scaling managed agents — [一手] 12. Anthropic, Building effective agents — [一手] 13. OpenAI, A practical guide to building agents — [一手] 14. Carlos E. Perez, From Loop Engineering to Graph Engineering — [一手：近期观点] 15. LangGraph, Graph API — [一手：官方文档] 16. LangGraph, Persistence — [一手：官方文档] 17. Microsoft AutoGen, GraphFlow — [一手：官方文档] 18. Google ADK, Graph workflows — [一手：官方文档] 19. CrewAI, Flows — [一手：官方文档] 20. Temporal, What is Temporal? — [一手：官方文档] 21. David Harel, Statecharts: A Visual Formalism for Complex Systems — [一手：经典论文] 22. W3C, State Chart XML 1.0 — [一手：正式标准] 23. W. M. P. van der Aalst, Verification of Workflow Nets — [一手：经典论文] 24. Agentproof: Static Verification of Agent Workflow Graphs — [一手：预印本] 25. OpenAI Agents SDK, Multi-agent orchestration — [一手：官方文档]

本地资料

• 本地：Loop Engineering 综合总结，原路径 Obsidian/技术文章/Loop Engineering/00-三源综合总结.md
• 本地：Agentic Harness Engineering 调研，原路径 Obsidian/DeepResearch/AHE-Agentic-Harness-Engineering/AHE-公众号文章.md
• 本地：Claude Code 架构笔记，原路径 ClaudeCode/2026-04-19-Dive-into-Claude-Code/docs/architecture.md