主题
图工程(Graph Engineering)
图工程是面向 AI Agent 工业化落地的第五代大模型工程范式,核心是用图(Graph)结构统一管理包含条件分支、状态恢复、循环控制、节点复用、异常处理、并发执行等能力的复杂 AI 工作流。
核心不是再优化某一次循环,而是用"图"把若干个 Loop、Workflow、Knowledge 组织成一张可控、可观测、可恢复的网。
一句话定义(行业共识):Graph Engineering 是用节点、边和状态设计复杂系统,常用于多智能体协作、知识图谱及工作流编排,强调可控、可观测与可扩展。 —— 数据呼吸Lex,腾讯云开发者社区
为什么需要 Graph Engineering
前四代工程范式都解决了当时最痛的问题,但都留下了新瓶颈:
第 1 代 Prompt Engineering:如何与大模型沟通(指令、角色、上下文)
→ 痛点:一次推理,无状态、无工具、知识截止
第 2 代 Prompt Chain:把单次思考拆成多步,组织多个 Prompt
→ 痛点:单向流水线,无回头(失败不会重查)
第 3 代 Vector RAG & Workflow:让模型拥有外部知识并连接世界
→ 痛点:仍无反馈(检索失败不会重查)
第 4 代 Agentic / Multi-Agent(含 Loop Engineering):让模型自主决策
→ 痛点:ReAct 循环能力指数增长,但易失控——
无限循环、上下文爆炸、状态不可恢复、过程不可观测、出错无法回退当 Agent 系统从"玩具"走向"生产",真正的诉求变成:
稳定、可恢复、可监控、可观测、可审计、可暂停、可恢复的系统。
Workflow 只能表达 A → B → C(一条线),而 Graph 可以表达一张网。所以:
Graph 是管理 Loop 的最佳数据结构。五代演进总览
| 代次 | 名称 | 解决的核心问题 | 类比传统软件 |
|---|---|---|---|
| 第 1 代 | Prompt Engineering | 如何与大模型沟通 | 函数 |
| 第 2 代 | Advanced Prompt / Chain | 把单次思考拆成多步 | 模块 |
| 第 3 代 | Vector RAG & Workflow | 让模型拥有外部知识、连接世界 | 服务 |
| 第 4 代 | Agentic RAG / Multi-Agent | 让模型自主决策(引入 Loop、自我修正) | 微服务 |
| 第 5 代 | Graph Engineering | 管理越来越复杂的 Agent 与 Loop | 云原生 |
抽象主线:
Prompt → Prompt Chain → Workflow → Loop → Graph
对应系统进化:输入 → 流程 → 状态 → 反馈 → 自治逐级解决上一代瓶颈,而非相互替代。
与已有工程层的关系
把本站已经梳理的四层工程视角,和 Graph Engineering 放在同一张图里看:
Graph Engineering(图工程)
↑ 用图结构编排、约束、观测多个 Loop / Workflow / Agent
Loop Engineering(循环工程)
↑ 多步反馈循环、终止条件
Harness Engineering(承载管控工程)
↑ 执行、验证、安全边界
Context Engineering(上下文工程)
↑ 信息输入、上下文管理
Prompt Engineering(提示工程)
↑ 单次输入优化Graph Engineering 是 Context/Harness/Loop 之上的一层"结构编排":
- 它是 Context Engineering 向图谱的深化(纵向知识图谱组织实体与关系,用于检索、事实验证与约束检查);
- 它是 Harness Engineering 中"控制层"与"记忆层"的技术内核(横向工作流图记录 Agent 处于多步骤流程的哪一环、允许哪些状态转移)。
核心要素
Graph Engineering 不是一个"流程图",而是能表达以下能力的运行时:
| 要素 | 说明 |
|---|---|
| 节点(Node) | 一个执行单元:LLM 调用、工具调用、人工审核、条件判断 |
| 边(Edge) | 节点间的流转路径,可带条件(如"测试失败 → 回到编码节点") |
| 共享状态(State) | 贯穿整个图的上下文,所有节点可读写 |
| Checkpoint | 每一步落盘,失败时从最近检查点恢复 |
| Memory | 短期(会话内)+ 长期(跨会话/跨用户)记忆 |
| Human in the Loop | 关键节点挂起,等待人工审批后再继续 |
| Supervisor / Planner | 调度节点,决定下一步走哪条边 |
| 并发执行 | 多个无依赖节点并行运行 |
| 异常处理 | 节点失败时的回退、重试、兜底策略 |
工作流图 vs 知识图谱(两个维度)
Graph Engineering 同时包含横向与纵向两种图:
横向 —— 工作流图(Workflow Graph)
记录 Agent 处于多步骤流程的哪一环,以及允许哪些状态转移
Planner → Coder → Tester → Reviewer
↑____ 失败回退 ____↓
纵向 —— 知识图谱(Knowledge Graph)
组织实体与关系,用于检索增强、事实验证、约束检查
用户 -[属于]-> 组织 -[拥有]-> 权限当节点及流转路径主要由代码预先规定时,系统属于"图式工作流";当部分节点能根据环境反馈自主选择行动并调整策略时,系统才具有明显的 Agent 特征。
代表框架
行业整体正在走向 "Graph First":
- LangGraph:节点、边、共享状态、持久化执行(Checkpoint)、Human-in-the-Loop
- Google ADK
- CrewAI Flow
- OpenAI Responses API
- Anthropic Agent SDK
python
# LangGraph 示意:失败回退的编码-测试-审查闭环
from langgraph.graph import StateGraph, END
def build_graph():
g = StateGraph(State)
g.add_node("planner", plan)
g.add_node("coder", write_code)
g.add_node("tester", run_test)
g.add_node("reviewer", review)
g.add_edge("planner", "coder")
g.add_edge("coder", "tester")
# 测试失败 → 回到编码节点(Graph 才能优雅表达这种回退)
g.add_conditional_edges(
"tester",
lambda s: "coder" if s.test_failed else "reviewer"
)
g.add_edge("reviewer", END)
return g.compile(checkpointer=...)实际案例
Case 1:自动编程 Agent 闭环
Planner → 拆解任务:给项目加用户认证
↓
Coder → 写认证中间件
↓
Tester → 跑测试(失败:密码未加密)
↑________ 回退 ________↓ ← Workflow(A→B→C) 表达不了,Graph 可以
Coder → 修复(加入 BCrypt)
↓
Reviewer → 审查通过
↓
ENDCase 2:多 Agent 协作(Supervisor 调度)
Supervisor(调度节点)
├── Researcher → 检索资料
├── Coder → 实现功能(并发)
├── Tester → 验证(等待 Coder 完成)
└── Reviewer → 审批(Human in the Loop 挂起点)设计原则
- 图是结构,不是银弹:先用 Workflow / Loop 能解决的,不要过度上 Graph。
- 状态要可恢复:必须有 Checkpoint,否则生产环境一次故障就丢全部进度。
- 流转要可观测:每条边、每个节点都应有日志与指标,便于审计与调试。
- 关键节点人工介入:高风险操作(删数据、上生产、付费 API)挂起审批。
- 失败要有回退路径:节点失败不能卡死,需定义回退 / 重试 / 兜底。
- 避免无限网格:用 Supervisor + 终止条件约束,防止状态爆炸。
与前几代的关系小结
Workflow 只能表达 A→B→C(一条线)
Graph 可以表达一张网(含回退、并发、条件、人工)
Graph 包容前述所有结构:
Prompt ⊂ Chain ⊂ Workflow ⊂ Loop ⊂ GraphGraph Engineering 是当前 AI 工程工业化落地的主流形态,但并非终点。文中提及的演进方向包括:Self-Evolving Graph、Dynamic Graph、Runtime Graph Generation(AI 自己生成 Graph,进入自治系统时代)。
相关资源
- AI Engineering 五代演进史:Prompt、RAG、Agent 到 Graph - shengjk1,CSDN
- Graph Engineering 一文看懂!智能体新范式 - 数据呼吸Lex,腾讯云开发者社区
- Loop Engineering 是什么? - 程序猿DD
- LangGraph 文档