2026 年下半年，Agent 圈吵得最凶的一个词是 Graph Engineering（图工程）。背后是一个共识性判断：杠杆点正在从「一个智能体跑得多好」（Loop Engineering，打磨单个 Agent 的发现—规划—执行—验证循环），转向「多个智能体如何协同」。图工程把多智能体组织本身当成一张可编程的图来设计——谁是节点、允许哪些流转、运行时的任务图怎么生长。本教程不教你装某个具体工具，而是给你一套可套用的设计方法，把自己的 Agent 团队从「一堆各自为战的助手」升级成「一张能随任务生长的图」。
📐 本教程适合：已经玩过多智能体编排、但越搭越乱的开发者 / 架构者。它解决的是「怎么系统地设计协同」，而不是「怎么调通某一个节点」。
先搞懂：从 Loop 到 Graph 的范式转移
用一句话理解：Loop Engineering 关注「一个员工多能干」，Graph Engineering 关注「一支团队怎么配合」。两者不矛盾，但重心变了：
| 维度 | Loop Engineering | Graph Engineering |
|---|---|---|
| 优化对象 | 单个 Agent 的执行循环 | 多 Agent 的组织结构 |
| 核心问题 | 它做得对不对 | 谁该把活交给谁 |
| 运行时 | 固定流程 | 任务图可动态生长 |
| 瓶颈 | 单点能力见顶 | 协同与权限失控 |
别把图工程当成新瓶装旧酒就跳过。它真正的价值在两点：① 把「协作规则」显式画出来，而不是埋在提示词里靠运气；② 让任务图在运行时根据情况生长，而不是写死一条流水线。
Step 1：列出你的 Agent 团队节点（角色清单）
1 先把「有哪些角色」画成节点
拿一张纸 / 一个白板，列出你业务里需要的智能体角色：
· Researcher 调研：搜资料、读文档
· Writer 写作：出初稿、改文案
· Critic 审查：挑错、给改进
· Planner 规划：拆任务、排优先级
· Executor 执行：调工具、落地动作
每个角色 = 图里的一个节点（node）。💡 节点粒度别太细也别太粗。一个节点最好「只干一类事」，否则又退化成那个啥都扛的单 Agent。
Step 2：定义边——谁允许把任务交给谁
2 协同关系就是「边」
图的精髓在边（edge）。哪些流转是允许的，要显式声明：
Planner → Researcher （拆完任务派去调研）
Researcher → Writer （资料交给写作）
Writer → Critic （初稿交给审查）
Critic → Writer （修改意见回流重写，允许循环）
Writer → Executor （定稿后交执行）
不允许的边（写下来！）：
Executor 不能反向指挥 Planner（避免无限套娃）「不允许的边」和「允许的边」一样重要。不写禁边，多 Agent 很容易陷入互相委派、无限循环的死局。把红线画进图定义，是图工程的第一条纪律。
Step 3：定义运行时生长规则（任务图怎么扩）
3 让图能「按需长出新节点」
静态图只解决已知流程；真实任务常冒出意料外的子任务。
定义生长规则，例如：
· 当 Researcher 发现缺一类资料 → 临时长出「Expert-X」节点
· 当 Critic 判定风险高 → 长出「Human-Approve」节点等人工
· 子任务完成 → 临时节点自动回收，图缩回主干
规则要写在「什么条件下长、什么条件回收」。🔑 生长规则 = 图的弹性。没有它，你只能处理画布上预先画好的流程；有了它，Agent 团队能应对没见过的任务形状——这才是 Graph Engineering 比固定流水线强的地方。
Step 4：给边加权限与爆炸半径
4 每个交接都要算「失控成本」
协同越自由，风险越大。给每条边标注它能触达的「爆炸半径」：
· Writer → Executor 这条边，Executor 能调写接口
→ 必须限定：只读 / 限额 / 高危动作需 Human-Approve 节点
· Critic → Writer 是纯文本回流，爆炸半径≈0，可自由循环
· 任何「跨系统写操作」的边，默认接人工确认节点
原则：边越能造成真实损失，越要收口。图工程不等于放开手脚让 Agent 互调。恰恰相反，它要求你比单 Agent 更清楚每条协作路径的代价。可参考本中心《ActionRail 执行前护栏》给高危边加闸。
Step 5：用协调工程沉淀可复用资产
5 让协作经验「越用越好」
1. 每次跑通一条好的协作路径，把它存为「模板子图」
2. 把踩过的坑（坏边、死循环）记进「反模式库」
3. 新任务先匹配历史子图，匹配不上再临时生长
4. 团队共享这套图资产，而不是每人从零画🚀 这一步对应业界说的「协调工程（Coordination Engineering）」：把跑通的协作经验沉淀为可复用、会进化的资产。你的图不是一次性的流程图，而是会随使用变聪明的组织能力。
Step 6：结合 HOTS / HITS 做人机协同
6 人该站在图的什么位置
HOTS（Human On the Swarm）：人站在团队外指挥，派活、收结果
HITS（Human In the Swarm）：人走进团队内，和 Agent 一起干
在图里怎么落：
· 设一个「Human」节点，连到所有高危边之前
· HOTS：Human 节点只在起点 / 终点出现
· HITS：Human 节点嵌在某条协作边中间，实时参与人和图的边界要画清楚。哪些决策必须人拍板、哪些 Agent 可自主，直接决定这套系统敢不敢上生产。模糊的人机边界 = 责任不清 = 事故温床。
Step 7：落地检查清单
7 上线前用这张表过一遍
□ 每个角色是否职责单一、不重叠？
□ 允许的边是否显式声明？不允许的边是否也写了？
□ 是否有运行时生长规则（长 / 回收条件）？
□ 每条能造成损失的高危边是否收口 / 接人工？
□ 好的协作路径是否沉淀为可复用子图？
□ 人在图里的位置（HOTS / HITS）是否明确？🎉 恭喜！你已掌握 Graph Engineering 的设计骨架：节点 = 角色、边 = 协作、生长规则 = 弹性、权限 = 安全、资产沉淀 = 进化。把它和具体编排工具（Dify Agent、LangChain OAP、JiuwenSwarm 等）结合，你的多智能体团队就从「凑数的助手群」变成「一张可编程的图」。
常见问题速查
| 你遇到的现象 | 大概率原因 & 解决 |
|---|---|
| 多 Agent 陷入死循环 | 漏写「不允许的边」，补禁边与最大循环次数 |
| 遇到新任务就崩 | 缺运行时生长规则，补临时节点长 / 收条件 |
| Agent 互调造成误操作 | 高危边没收口，接人工确认或护栏 |
| 每次都从零搭 | 没沉淀子图资产，建模板库并共享 |