Graph Engineering（图工程）完全指南

什么是 Graph Engineering？

Graph Engineering（图工程）是把一个多 Agent 系统设计成一张显式的图：节点（Agent 或确定性步骤，每个只负责一件事）、边（节点之间的路由——顺序、条件或并行）、以及共享状态（沿着边流动的对象，每个节点读取并修改它）。

如果说 Loop Engineering 让单个 Agent 的行为变得可编程——目标、检查命令、退出条件、重试——那么 Graph Engineering 让 Agent 的组织方式变得可编程。Loop 回答的是"这个 Agent 怎么持续工作直到完成？" Graph 回答的是"存在哪些 Agent、谁交接给谁、某个分支失败了怎么办？"

一个有用的退化情形：只有一个节点的图就是一个 loop。所以这两门学科是叠加而不是竞争——每张像样的图都是一张 loop 组成的图。

这个词为什么现在火

这个词在 2026 年 7 月 18 日左右在 X 上定型，Peter Steinberger（也是带火 Loop Engineering 的同一个人）发问："Are we still talking loops or did we shift to graphs yet?"（我们还在聊 loop，还是已经转向 graph 了？）一天之内，builder 们开始用"Agent 正在从 while 循环毕业，升入组织架构图"来描述这个转变。

值得注意的是，那一周并没有任何新能力发布。这个转变是概念性的：到 2026 年中，单个调教良好的 loop 已经足够可靠，团队开始同时跑好几个——research loop 喂给 builder loop 再喂给 reviewer loop——然后发现难题转移到了接线上：路由、交接契约、故障隔离、Agent 之间的状态一致性。Graph Engineering 就是"有意识地设计这套接线，而不是在生产环境里被动发现它"的名字。

技术栈：从 Prompt 到 Graph

这几层在网上经常被混用。从最内层到最外层：

• Prompt Engineering（提示词工程） ——优化发给模型的单条指令，一次一轮。
• Context Engineering（上下文工程） ——决定 Agent 在响应之前能看到什么信息（文件、记忆、检索到的文档）。
• Harness Engineering（执行框架工程） ——设计单个 Agent 运行于其中的系统：工具、护栏、权限、可观测性。Agent = 模型 + Harness。
• Loop Engineering（循环工程） ——把 Harness 工程应用到"重试-验证"循环上：目标、检查命令、退出条件、最大迭代次数。完整指南 →
• Graph Engineering（图工程） ——把多个 loop 接成一个组织：节点、边、共享状态，以及它们之间的路由逻辑。本文讲的就是这一层。

一张图的解剖结构

每张合格的 Agent 图都要回答四个问题——动手接线之前先写下来：

• 节点（Nodes） ——工作单元是什么？每个节点是否只负责一件事、有自己的"完成"定义？不能独立失败的节点不是节点，是隐藏依赖。
• 边（Edges） ——对每个节点，什么触发下一个节点？顺序（总是执行）、条件（检查通过才执行），还是并行（fan-out 到多个，再 fan-in 汇合）？
• 共享状态（Shared State） ——沿着边传递的对象是什么？下游节点需要的每个字段都必须由上游节点写入——图会逼你承认工作流里还有多少东西你根本没建模。
• 失败路由（Failure Routing） ——某个节点的 loop 重试耗尽后，控制权去哪？回退一步、走 fallback 节点，还是上报给人？没有失败边的图只是一张示意图，不是一个系统。

组织图与工作图

原始讨论串里流传最广的一个框架：成熟系统实际上同时运行两张图。

• **组织图（Org Graph）**稳定而长寿——各自拥有一个领域的专职 Agent（审查者、研究员、部署 Agent），保有持久上下文，跨任务存在。类比：组织架构图。
• **工作图（Work Graph）**动态而短命——为单个任务生成的 DAG，节点根据工作实际需要出现、展开、合并、消失。类比：项目计划。

早期最常见的错误就是混淆两者：把今天这个任务的分解方式（工作图）硬编码进常设 Agent 编制（组织图），然后奇怪为什么每个新任务都在和结构对抗。

命名的图模式

有几种形状反复出现：

• 流水线（顺序交接） ——研究员 → 写作者 → 审查者。最简单的图；每个节点的输出是下一个节点的输入。
• Fan-out / Fan-in ——一个节点派生多个并行 worker（按文件、按测试失败、按数据源各一个），一个汇合节点合并结果。处理可并行任务的主力模式。
• Orchestrator–Workers（编排者-工人） ——用更强模型的规划节点分解任务，把子任务路由给更便宜的 worker 节点，最后整合。"想得慢、做得快"的多 Agent 版本。
• 评审团 / 裁判组（Council / Judge Panel） ——多个节点独立尝试或评估同一任务，由裁判节点（或多数投票）选出胜者。用冗余换可靠性。
• 节点内嵌循环（Loops-within-Nodes） ——任何节点内部都可以包含完整的"重试-验证"循环——比如 Ralph 式循环、test-until-green 循环——对图的其余部分不可见。正是这条组合规则让整个技术栈成立。

你真的需要一张图吗？

诚实且泼冷水的回答：通常还不需要。单个 loop 仍然够用的信号——一个有良好上下文的 Agent 能装下整个任务；失败后从头重试很便宜；没有真正的并行可挖。已经超出单 loop 的信号——阶段之间的交接总在一条长上下文里丢失；不同阶段需要不同的模型或权限；一个慢子任务把一切串行化；第 7 步失败就得从第 1 步重来。

务实的路径是渐进式的：先把一个 loop 做可靠，再用显式交接接上第二个 loop，只有当接线本身成为 bug 来源时才引入框架。

框架

图编排早于这个词。LangGraph 是最直接的实现——定义一个 StateGraph、添加节点、添加边，运行时负责状态持久化、条件路由和回滚。微软 AutoGen 的 GraphFlow、Google 的 Agent Development Kit（ADK）、CrewAI 用不同的取舍覆盖同一块领域。Agent 原生运行时也在向同一形状收敛：Claude Code 内置的循环原语正好可以组合成这些流水线和 fan-out。如果你用过其中任何一个，你早就在做 Graph Engineering 了，只是叫法不同。

上手指南

图由能跑通的 loop 组成，所以从杠杆最大的地方开始：先做出一个可靠的 loop，再往外接线。

• 从 MCP.so 的 Loops 目录选一个经过验证的单 Agent loop——比如 Test Until Green 或 Ship PR Until Green——跑到无聊为止。
• 加一次交接：第二个 loop 通过显式状态文件或 PR 消费第一个 loop 的输出，带自己的检查命令。
• 然后才形式化：把接线迁移到 LangGraph 或你所用运行时的原生工作流支持里，保持每个节点的 loop 契约（目标、检查、退出、重试）不变。

Loop 是肌肉，Graph 是骨架。完整的即用型 loop 集合见 MCP.so Loops——每一个都带图节点所需的启动提示词、检查命令和退出条件。