Graph Engineering：AI Agent 从 Loop 到 Graph 的工程升级
当 Agent 开始接手真实业务，光会调模型、用工具、自我反思还不够。如何分工、交接、校验、回退，以及在哪里把决定权交还给人，决定了它能否从演示走进业务。
核心观点
-
Loop 让 Agent 动起来，但也藏起了复杂度：Agent 的”观察—决策—行动—反馈”循环（Loop）提供了灵活性，但当所有职责（搜索、分析、校验、发布）都塞进同一个上下文时，上下文臃肿、错误从前步流到后步。对需要分工、并行、审核和权限管理的任务，单一 Loop 开始吃力。
-
Graph Engineering 的核心是”显式化”：Graph 不是知识图谱，也不是多个 Agent 聊天。它把原本藏在 Prompt 和上下文中的职责、状态、路由、检查和退路，变成显式、可执行、可追踪的系统结构。以 LangGraph 的抽象为例：State（状态）、Node（节点）、Edge（流转规则），翻译成产品语言就是任务单、处理岗位、流转规则。
-
Loop 和 Graph 不是替代关系，而是组织升级：一张 Graph 里完全可以有 Loop（例如”查找官方信息”节点内部用 Agent 不断搜索直到停止条件），但完成后必须把结果写入结构化 State 交给下一个节点校验。概括：Loop 负责让一个角色把局部任务做完，Graph 负责让多个局部任务组成可交付的结果。
-
竞品周报的 Graph 改造案例：从”接收任务→自由搜索→自由分析→生成报告”的单一链路，拆成 6 个节点——任务定义、并行采集（官网/媒体/应用商店）、事实校验（检查时效性/来源一致性/事实与推测分离）、分析（仅用校验后的证据）、审阅（按明确标准检查，不合格退回对应节点而非整体重跑）、人工确认与发布（生成和发送分属不同风险等级）。
-
产品经理设计 Graph 的 7 个关键问题：① 什么才算任务完成（不是”生成报告”而是覆盖 N 个竞品、结论有来源、关键字段完整）；② State 里必须保存什么（结构化状态：任务目标、当前阶段、证据列表、冲突项、重试次数）；③ 每个节点只对什么结果负责（单一职责）；④ 什么条件下改变路径（路由决策表）；⑤ 每个节点如何验收（确定性规则优先，语义问题再用模型）；⑥ 哪些动作必须由人确认（按可逆性/影响范围/责任等级划三类边界）；⑦ 失败后如何续跑、运行过程如何追踪（节点级监控看板）。
-
升级到 Graph 的判断信号：① 路径根据中间结果变化；② 有多个可独立完成的专业任务；③ 需要长时间运行（分钟到天）；④ 需要多道质量检查；⑤ 涉及高风险动作。判断顺序：单次调用 → 固定 Workflow → Loop → Graph，每步升级都增加表达力但也增加时延、成本、调试和运维负担。
-
Graph Engineering 对 AI 产品经理的交付物升级：除 PRD 和原型外，新增任务状态表、节点定义卡、路由决策表、权限与确认清单、节点运行看板（成功率/耗时/重试率/人工接管率/单任务成本）。核心转变：产品的核心不再是让模型”看起来更聪明”，而是让整个系统”可以被管理”。
实操内容保留
Graph 改造案例：竞品周报的 6 节点设计
改造前（单一 Agent Loop）：
接收任务 → 自由搜索 → 自由分析 → 生成报告
改造后（Graph）：
| 节点 | 职责 | 关键约束 |
|---|---|---|
| 1. 任务定义节点 | 将”做竞品周报”翻译为可执行任务：竞品范围、时间区间、重点维度、读者、截止时间、输出格式、必须回答的问题 | 这一步未定义清楚，后面越快越偏 |
| 2. 并行采集节点 | 官网/公告、行业媒体、应用商店与用户反馈分别采集，每个内部可用 Loop，但必须输出统一字段：事件、时间、来源、原文链接、证据摘要、可信等级 | 不排长队，并行执行 |
| 3. 事实校验节点 | 不负责写观点，只检查：是否本周新事件、是否有可追溯原始来源、多来源口径是否一致、事实和推测是否已分开 | 冲突信息打”待确认”标签，进入补充采集或人工确认 |
| 4. 分析节点 | 只允许使用通过校验的证据，回答产品问题：竞品做了什么、想解决什么、对我们的影响、继续观察还是立即行动 | 不自己编造证据 |
| 5. 审阅节点 | 按明确标准检查：核心结论是否有证据、是否漏掉重要竞品、建议是否超出材料支持范围 | 不合格退回对应节点，不整体重跑 |
| 6. 人工确认与发布节点 | 生成和发送是不同风险等级动作，根据读者和内容级别决定是否需要人工确认 | 生成可自动，发送需确认 |
产品经理设计 Graph 的 7 个问题清单
- 什么才算任务完成？ — 报告覆盖多少个竞品？重要结论是否都有来源？哪些字段必须完整？出现多少条未确认信息时应该停止发布？
- 任务状态里必须保存什么？ — 结构化字段：任务目标、当前阶段、已完成节点、证据列表、冲突项、审阅结果、重试次数、待人工决策事项
- 每个节点只对什么结果负责？ — 采集不下结论，分析不编证据，审阅不重写全文
- 任务在什么条件下改变路径？ — 证据不足是补充搜索还是降低结论等级？超重试上限是结束还是转人工？
- 每个关键节点如何验收？ — 确定性规则优先（字段缺失、链接可访问、日期范围），语义问题再用模型
- 哪些动作必须由人确认？ — 按可逆性、影响范围和责任等级，划定自动执行/执行前确认/全程人工三类边界
- 失败以后如何续跑，运行过程如何追踪？ — 重试次数、局部失败是否影响全局、已完成结果是否保留、节点级监控看板
Loop → Graph 升级判断清单
| 信号 | 说明 |
|---|---|
| 路径根据中间结果变化 | 不同输入进入不同分支，可能返回前面节点 |
| 多个独立专业任务 | 可以分工或并行，有明确输入输出 |
| 需要长时间运行 | 跨分钟/小时/天，期间需暂停、恢复或等待外部信息 |
| 需要多道质量检查 | 单点错误会向后放大，不适合只在最终结果验收 |
| 涉及高风险动作 | 影响用户、资金、客户关系、业务数据或对外承诺 |
判断顺序：单次调用 → 固定 Workflow → Loop → Graph。每步升级增加表达力，也增加时延、成本、调试和运维负担。
AI 产品经理新增文档类型
- 任务状态表：系统需要记住什么，哪些字段可以被哪个节点更新
- 节点定义卡：每个节点的职责、输入、输出、工具、时限和验收标准
- 路由决策表：什么条件下继续、返回、重试、终止或转人工
- 权限与确认清单：哪些动作可以自动执行，哪些动作必须停下来
- 节点运行看板：每个节点的成功率、平均耗时、重试率、人工接管率和单任务成本
原文精彩摘录
演示时，它通常会给人留下很好的印象：没人告诉它每一步怎么做，它却能自己往前走。但真正把它放进业务，问题很快就来了——它反复打开同一个页面，谁来判断这是重试还是空转？官网和媒体的数据对不上，应该信谁？前面把一条旧闻当成了新消息，后面的结论是不是都要重做？报告可以自动生成，但能不能自动发给老板和客户？问题不在于模型不够聪明，而在于我们把一个需要多种职责、多条路径和多道检查的任务，塞进了一个单一循环里。
一张 Graph 里，完全可以有 Loop。例如，“查找官方信息”这个节点，内部可以由 Agent 不断搜索、阅读和补充资料，直到达到停止条件。但它完成后不能自由发挥，而是要把结果写入结构化状态，交给下一个节点校验。可以用一句话概括：Loop 负责让一个角色把局部任务做完；Graph 负责让多个局部任务组成可交付的结果。
当 Agent 只负责回答时，出错通常只是一次体验问题。当 Agent 开始发邮件、改库存、调价格、操作客户数据时，出错就变成了流程、权限和责任问题。模型能力越强，它能做的动作越多，系统越需要清晰的结构。从 Loop 到 Graph 不是为了追一个新名词，也不是为了把 Agent 架构画得更漂亮。它是 AI 产品从”能跑”走向”可交付”时，迟早要补上的一层工程能力。
关键概念
- Graph Engineering：将 Agent 系统的职责、状态、路由、检查和退路显式化为可执行的图结构
- Agent Loop：Agent 的”观察—决策—行动—反馈”核心循环
- 竞品周报 Graph 改造：从单一链路拆为 6 节点任务图的实操案例
- 产品经理 7 问：设计 Graph 时必须回答的 7 个产品问题
- LangGraph State/Node/Edge：Graph Engineering 的技术基础抽象
与其他素材的关联
- 与 Agent 运行治理 共同覆盖 Agent 可管理性，本文从 Graph 结构角度补充了”如何让 Agent 可追踪”
- 与 2026-06-23-agent-orchestration-review 的编排复杂度讨论呼应，本文给出了 Graph 视角下的解决方案
- 与 AI Agent 智能体 的设计原则（人在回路、渐进式自主）一致，本文用 Graph 给出了实现这些原则的工程结构
- 与 LangGraph 共享 State/Node/Edge 抽象，本文从产品设计角度补充了 PM 如何使用这些抽象
- 与 AI 工作流方法论 的编排体系讨论呼应，Graph Engineering 是图式编排的具象化和产品化
相关页面
- AI Agent 智能体
- LangGraph
- Agent 运行治理
- AI 工作流方法论
- AI产品经理工作流
- Agentic Workflow
- Workflow DSL