
AI AGENT 工程范式进化史 • 第六站 • GRAPH ENGINEERING分支、返工、人审和恢复一多流程就不再是一条线。19:42晚高峰。12 号桌的番茄炒蛋正在第三轮返工8 号桌刚下单凉菜、热菜和汤要同时开工3 号桌有过敏备注必须先等经理确认偏偏蒸箱又在这时报警。每个局部流程都能讲清楚订单怎么写、工序怎么接、信息怎么送、动作怎么执行、失败怎么重来。可它们一旦同时发生后厨就出现了一个新问题谁先做、谁等谁、哪里能并行、哪里必须暂停故障后又从哪里继续这已经不是再加一条 Workflow 能解决的事。餐馆需要的是一张能随着现场状态改变路径的全店交通图。Graph 的起点不是“想画一张复杂图”而是现实中的下一步已经不再固定。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 也不是知识图谱。它描述的是执行关系哪些节点负责做事哪些边允许跳转什么状态贯穿全程系统在哪里保存检查点。{ 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 是基于“工程边界继续外扩”的作者推算不是已经确立的行业范式或时间表。