Graph Engineering
将 Agent 系统的职责分工、状态管理、路由决策、质量检查和退路机制，从 Prompt 和上下文中提取出来，变成显式、可执行、可追踪的图结构。是 AI Agent 从”能跑”走向”可交付”的关键工程能力。
定义
Graph Engineering 是一组正在形成的工程实践，核心思想是：不要把所有逻辑藏在 Prompt 和对话上下文中，而是把它们变成一张可检查、可回退、可暂停的任务图。
与容易混淆的概念的区别：
| 概念 | 关注点 | Graph Engineering 的差异 |
|---|---|---|
| 知识图谱 | 实体、关系、知识结构 | Graph Engineering 关注的是任务节点和执行路径 |
| GraphRAG | 用图结构组织和检索信息 | Graph Engineering 关注的是任务如何分工和流转 |
| 多 Agent 聊天 | 多个 Agent 之间的对话 | Graph Engineering 中节点可以是大模型、确定性代码、API、规则或人工审批 |
核心抽象（基于 LangGraph）
| 概念 | 技术含义 | 产品语言翻译 |
|---|---|---|
| State | 任务当前状态、已获取的信息 | 任务单 |
| Node | 某一步具体做什么工作 | 处理岗位 |
| Edge | 完成后下一步去哪里 | 流转规则 |
Graph Engineering 的重点不是”图”这种形式，而是”显式”——把隐式的 Agent 行为变成可追踪的系统结构。
Loop 与 Graph 的关系
不是替代关系，而是组织升级。
- Loop：Agent 在单一职责范围内的”观察—决策—行动—反馈”循环。让 Agent 灵活处理路径不固定的任务。
- Graph：多个 Loop 和其他节点（确定性代码、API、规则、人工审批）组成的任务链路。让多个局部任务组成可交付的结果。
一张 Graph 里完全可以有 Loop。例如”查找官方信息”节点内部用 Agent 不断搜索直到达到停止条件，但完成后必须把结果写入结构化 State，交给下一个节点校验——不能自由发挥。
竞品周报的 Graph 改造案例
改造前（单一 Agent Loop）：
接收任务 → 自由搜索 → 自由分析 → 生成报告
改造后（6 节点 Graph）：
| 节点 | 职责 | 关键规则 |
|---|---|---|
| 1. 任务定义 | 翻译为可执行任务：范围、时间、维度、读者、输出格式 | 未定义清后面越做越偏 |
| 2. 并行采集 | 官网/媒体/应用商店分别采集，输出统一字段 | 可并行，每路内部可用 Loop |
| 3. 事实校验 | 检查时效性、来源可追溯性、多源一致性、事实与推测分离 | 冲突信息打”待确认”标签 |
| 4. 分析 | 仅用校验后的证据回答产品问题 | 不自己编造证据 |
| 5. 审阅 | 按明确标准检查，不合格退回对应节点 | 不整体重跑，只退回问题节点 |
| 6. 人工确认与发布 | 生成可自动，发送需根据风险等级确认 | 生成和发送是不同风险等级 |
产品经理设计 Graph 的 7 个问题
- 什么才算任务完成？ — 不是”生成报告”，而是覆盖 N 个竞品、结论有来源、字段完整、未确认信息不超过 N 条
- State 里必须保存什么？ — 结构化字段：任务目标、当前阶段、已完成节点、证据列表、冲突项、重试次数、待人工决策
- 每个节点只对什么结果负责？ — 单一职责：采集不下结论，分析不编证据，审阅不重写全文
- 什么条件下改变路径？ — 证据不足补搜还是降级？超重试结束还是转人工？能否并行？
- 每个节点如何验收？ — 确定性规则优先（字段缺失、链接、日期），语义问题再用模型。验收标准绑定节点，不堆到最终输出
- 哪些动作必须由人确认？ — 按可逆性、影响范围、责任等级划三类：自动执行 / 执行前确认 / 全程人工
- 失败后如何续跑，如何追踪？ — 重试上限、局部失败对全局的影响、已完成结果保留策略、节点级监控看板
Loop → Graph 升级判断
判断顺序（从简到繁）：
单次 LLM 调用 → 固定 Workflow → Loop → Graph
每步升级增加表达力，也增加时延、成本、调试和运维负担。
升级信号（出现以下信号时考虑 Graph）：
- 路径根据中间结果变化（不同输入进入不同分支）
- 有多个可独立完成的专业任务（可分工或并行）
- 需要长时间运行（跨分钟/小时/天，需暂停/恢复）
- 需要多道质量检查（单点错误会向后放大）
- 涉及高风险动作（影响用户、资金、客户关系）
重要警示：如果一条业务流程本身就没人说得清楚，改成 Graph 只会让混乱沿更多条边流转。先理清业务逻辑，再考虑图式编排。
对 AI 产品经理的交付物影响
除 PRD 和原型外，需新增以下文档类型：
| 文档 | 内容 |
|---|---|
| 任务状态表 | 系统需要记住什么，哪些字段可被哪个节点更新 |
| 节点定义卡 | 职责、输入、输出、工具、时限、验收标准 |
| 路由决策表 | 继续/返回/重试/终止/转人工的条件 |
| 权限与确认清单 | 自动执行 vs 执行前确认 vs 全程人工 |
| 节点运行看板 | 成功率、平均耗时、重试率、人工接管率、单任务成本 |
核心转变：产品经理不必写每个节点的代码，但必须能说清楚为什么这样分工、结果怎么验收、出错后怎么处理。产品的核心不再是让模型”看起来更聪明”，而是让整个系统”可以被管理”。
不同素材中的观点
知序（2026-07-29）：Graph Engineering 目前更像一组正在被重新命名和归纳的工程实践，还不是一套边界统一的标准。但它指向的问题很具体——当 Agent 开始发邮件、改库存、调价格、操作客户数据时，出错就变成了流程、权限和责任问题。模型能力越强，系统越需要清晰的结构。Graph Engineering 是 AI 产品从”能跑”走向”可交付”时，迟早要补上的一层工程能力。2026-07-30-graph-engineering-ai-agent-loop-to-graph
相关页面
- AI Agent 智能体
- LangGraph
- Agent 运行治理
- Agentic Workflow
- AI 工作流方法论
- Workflow DSL
- AI产品经理工作流