AI AGENT 工程范式进化史 • 第六站 • GRAPH ENGINEERING
分支、返工、人审和恢复一多，流程就不再是一条线。
19:42，晚高峰。12 号桌的番茄炒蛋正在第三轮返工；8 号桌刚下单，凉菜、热菜和汤要同时开工；3 号桌有过敏备注，必须先等经理确认；偏偏蒸箱又在这时报警。
每个局部流程都能讲清楚：订单怎么写、工序怎么接、信息怎么送、动作怎么执行、失败怎么重来。可它们一旦同时发生，后厨就出现了一个新问题：谁先做、谁等谁、哪里能并行、哪里必须暂停，故障后又从哪里继续？
这已经不是再加一条 Workflow 能解决的事。餐馆需要的，是一张能随着现场状态改变路径的全店交通图。
01 / 接住第五站
一个 Loop 能改一道菜，多个 Loop 会挤满整间后厨。
第五站让单个任务学会了根据反馈回炉：观察结果、指出差异、改变动作，达标后停止。但当热菜在返工、凉菜在复核、顾客在等待确认时，每个 Loop 都会争用同一批灶台、传菜口和审批时间。
Graph 接住的不是"如何再试一轮"，而是所有任务和循环此刻应该怎样共同前进。它把局部能力放进一张全局可执行的网络里。
当下一步由实时状态决定，同一任务可能走不同路径，而且路径之间还会等待、回退和恢复时，Graph 才真正开始有价值。
02 / 先纠正名字带来的误会
Graph 不是 Loop 的高级皮肤，也不等于 DAG。
2024 年 1 月 17 日，LangChain 发布 LangGraph 时，核心动机就是给 Agent 运行时引入循环图。2026 年 7 月 22 日，Sydney Runkle 与 Harrison Chase 用"Graph Engineering"重新总结这类实践，同时明确指出：生产 Agent 需要重试、补充信息、人工暂停和恢复，因此通常不是只能向前走的 DAG。
这里的 Graph 也不是知识图谱。它描述的是执行关系：哪些节点负责做事，哪些边允许跳转，什么状态贯穿全程，系统在哪里保存检查点。
json
{
"table_id": "T12",
"active_node": "quality_gate",
"completed": ["void_bill_item", "refire_dish"],
"pending": ["runner_delivery"],
"retry_count": 2,
"requires_human": false
}节点可以是确定性代码、一次模型调用、一个工具，甚至一个内部自带 Loop 的 Agent。边可以固定，也可以根据当前状态选择。状态则像后厨一直流转的电子工单：它告诉每个节点已经发生了什么、还缺什么、下一步允许走哪里。
03 / 把六站真正拼在一起
Graph 没有替代前五站，它只是终于能调度它们。
-
Prompt： 每个节点怎样理解自己的任务和输出要求； -
Chain： 节点内部那些顺序稳定、适合固定下来的工序； -
Context： 这一节点此刻应该拿到哪些订单、备注和状态； -
Harness： 节点在哪个环境里、用什么工具和权限执行； -
Loop： 节点失败后怎样获得反馈、修正并停止； -
Graph： 这些节点、局部流程和循环怎样在全店范围内协同。
所以演进不是"学了 Graph，前面都可以丢掉"。恰恰相反，节点里的 Prompt 不清、Context 混乱或 Harness 越权，Graph 只会更快地把问题传到更多地方。
Graph 管的是全局路径；每个节点能不能做好自己的事，仍然依赖前五站的工程。
04 / 把晚高峰放进图里
线性工序留在节点里，复杂协调才交给 Graph。
8 号桌的普通订单经过风险识别后，凉菜、热菜和汤可以并行；传菜口负责汇合，菜齐才整桌上菜。3 号桌命中过敏风险，图会暂停在经理确认节点，而不是让模型自己猜。12 号桌的质检失败，则进入返工 Loop，并只回到出错的热菜档。
蒸箱故障时也不需要推倒整张图。设备状态改变后，依赖蒸箱的菜会走改菜、延时告知或人工处理分支；不受影响的凉菜仍可继续。图让局部故障保持局部，而不是把整个后厨一起卡死。
05 / 边必须说得出理由
"接下来去哪"不能只靠模型临场发挥。
一条真正有用的条件边，不是图上的装饰箭头，而是一条可以测试的路由规则。例如：过敏字段为真时必须进入人审；必填信息缺失时回到补充信息；风险检查通过后才允许下厨。
模型可以在边界内处理模糊判断，但付款、过敏、权限和数据一致性等硬约束，更适合由代码确定。Graph 的价值正在于：把哪里允许模型判断、哪里必须确定执行，清楚地分开。
06 / 并行之后必须会合
三道菜一起做，不代表随时都能上桌。
并行能缩短等待，但也引入新的状态：哪道菜完成了、哪道正在返工、哪道超时、是否允许先上部分菜。传菜口不是一个普通节点，而是一个汇合点。
如果热菜返工，汇合节点要同步更新整桌等待时间，必要时触发服务员解释或调整出餐策略。没有共享状态，并行只会让三条支线各自宣布成功，却没人知道这一桌到底能不能上菜。
07 / 图要能暂停，也要能醒来
人工卡点和崩溃恢复，本质上都在保存现场。
人工审批不应该把流程踢出系统。图在过敏确认、整桌免单或其他高风险动作前暂停，保存当前节点和完整状态；经理给出决定后，再从原处继续。
同样，系统进程崩溃或机器重启后，也不该从"接收订单"重新执行一遍。持久化检查点记录了已完成节点、待执行节点和共享状态，使任务能够从上一个可靠位置恢复。LangGraph 的 Persistence 与 Interrupts 文档正是用检查点支持故障恢复、人工暂停和继续执行。
没有状态保存的 Graph 只是一张流程图；能暂停、恢复并保持事实一致，它才开始成为运行时。
08 / 多 Agent 不是人海战术
真正需要设计的是责任边界和交接。
餐馆可以让前厅 Agent 负责点单与顾客沟通，后厨 Agent 负责档口调度，质检 Agent 负责验收与反馈，店务 Agent 负责库存、损耗和设备。每个 Agent 只处理自己擅长的子图。
关键不在于 Agent 越多越好，而在于谁拥有哪段状态、谁可以写入、交接时必须带上什么。对同一账单，最好只有明确的写入者；其他 Agent 提建议或提交动作请求，避免多人同时修改造成冲突。
09 / 先问值不值得
不是所有 Workflow，都应该升级成 Graph。
| 现场特征 | 更合适的选择 | 原因 |
|---|---|---|
| 步骤稳定、异常少、只需顺序执行 | Workflow | 路径更直观，测试和维护成本更低 |
| 有一处明确的反馈重试 | Workflow + 局部 Loop | 不必为了一个回路搭整张图 |
| 运行时分支、并行汇合、人审和恢复同时增加 | Graph | 全局状态与允许路径需要显式管理 |
| 任务高度开放，路径几乎无法预先描述 | Agent Harness + 少量边界 | 强行固定成图可能压掉必要的自主性 |
2026 年 LangChain 的文章也给出了反例：某些开放式深度研究任务很难提前钉死路径，过度图化反而不合适。Graph 不是成熟度勋章；能用一条清楚的线解决，就不要先修一座立交桥。
10 / 图也需要工程纪律
别让全店交通图变成一团意大利面。
随着节点和边增加，Graph 很容易从"终于看得见"变成"谁也看不懂"。每个节点都改共享状态、每条边都藏一段临时判断，最后只是把复杂度从代码搬到了画布上。
- 让一个节点只承担一类责任，并定义清楚输入和输出；
- 给状态字段明确归属，限制随意写入；
- 把路由条件做成可以单独测试的规则；
- 用子图封装客诉、返工等局部复杂度；
- 给关键路径设置时延、成本、重试和人工接管预算；
- 测试的不只是节点结果，还包括允许路径、禁止路径和恢复路径。
Graph Engineering 的难点不是把圆圈和箭头画出来，而是让整张图长期可读、可测、可恢复、可演进。
11 / Graph 不是终点
当一张餐馆图连上外部世界，边界还会继续外扩。
这家餐馆的 Graph 已经能调度前厅、后厨、库存、质检和经理。但它迟早会接上供应商、支付平台、配送网络、监管规则，甚至其他公司的 Agent。那时，新问题又会出现在当前边界之外。
下面不是已经确立的行业站名，而是沿着本系列逻辑做的三点推算：
Protocol / Trust： 当图跨越公司与平台，工程重点会转向身份、授权、结算、证据和责任边界；Organization： 当 Agent 节点可以临时组队、替换和竞争资源，系统需要设计动态分工与协调机制；Evolution / Governance： 当系统依据长期效果修改自己的路由、工具和规则，版本、评测、审计与回滚会成为新的核心。
也许未来不会使用这些名字，但方向已经可以看见：我们优化的对象，会从一个模型、一次调用、一条流程，继续外扩成跨系统、跨组织、能够受控演进的智能基础设施。
第六站只带走一句：
Graph 不是把系统画复杂，而是把真实世界早已存在的复杂关系，变成可以控制、验证和恢复的执行结构。至于"+还会有的..."，这张图本来就不应该画上句号。
这张图还没有画完 Graph 之后， 工程边界仍会继续向外扩。 未来的新站，应该从新的真实问题里长出来，而不是为了追逐一个新名词。关于这个系列
《AI Agent 工程范式进化史》------跟着同一家餐馆连续升级，一站一站讲透 AI Agent 工程的演进：
Prompt → Chain → Context → Harness → Loop → Graph → 还会有的...
本篇是第六站，但不是终点。
参考来源 ：
1 The LangChain Team, LangGraph, 2024-01-17。正文用它说明 LangGraph 最初围绕 Agent 运行时中的循环图展开，而非把 Agent 图限定为 DAG。
2 Sydney Runkle & Harrison Chase, 3 Years of Graph Engineering with LangGraph, 2026-07-22。正文用它说明节点、条件边、状态机、循环、动态转换，以及"Graph Engineering"标签在 2026 年 7 月进入集中讨论；该日期不是图式编排的发明日。
3 LangChain, Persistence 与 Interrupts 文档。正文用它们说明检查点、故障恢复、人工暂停与恢复执行。
口径说明 ：
本文用餐馆晚高峰构造 Graph 教学案例，桌号、菜品、设备故障、路由规则和状态 JSON 均为原创示意，不对应真实门店。文末 Protocol / Trust、Organization、Evolution / Governance 是基于"工程边界继续外扩"的作者推算，不是已经确立的行业范式或时间表。