当 Agent 开始接手真实业务，光会调模型、用工具、自我反思还不够。如何分工、交接、校验、回退，以及在哪里把决定权交还给人，决定了它能否从演示走进业务。

如果让一个Agent完成一份竞品周报，它大概会这样工作：

先搜索信息，再打开网页，读完后提取重点，判断资料够不够。不够就继续搜，够了就开始写，写完后再检查一遍。

这是一个很典型的Agent Loop。

演示时，它通常会给人留下很好的印象：没人告诉它每一步怎么做，它却能自己往前走。

但真正把它放进业务，问题很快就来了：

• 它反复打开同一个页面，谁来判断这是重试还是空转？
• 官网和媒体的数据对不上，应该信谁？
• 前面把一条旧闻当成了新消息，后面的结论是不是都要重做？
• 报告可以自动生成，但能不能自动发给老板和客户？

问题不在于模型不够聪明，而在于我们把一个需要多种职责、多条路径和多道检查的任务，塞进了一个单一循环里。

这也是 Graph Engineering 开始受到关注的原因。

一、Loop让Agent动起来，也把复杂度藏了起来

Agent和普通的大模型问答，最直观的区别是它不只输出一次答案。

它会观察当前状态，判断下一步，调用工具，读取结果，再继续判断。这个“观察—决策—行动—反馈”的循环，就是Loop。

Loop的价值很明确。

它不需要产品经理穷举所有步骤，面对路径不固定的任务，模型可以边做边调整。查资料、改代码、排查故障这类任务，往往很难事先写出一条固定路径，Loop正好能提供这种灵活性。

问题是，不少初版实现会把所有事都放进同一份上下文里。

搜索到的原始素材、工具返回的日志、中间推理、失败的尝试、用户的补充要求，都在一条链路里累积。当任务越来越长，上下文会越来越臃，错误也容易从前一步流到下一步。

对于一个人能独立做完的任务，这不一定是问题。

对于需要分工、并行、审核和权限管理的任务，只有Loop就开始吃力了。

二、Graph不是把流程图画得更复杂

这里说的Graph，首先不是知识图谱。

知识图谱关心的是实体、关系和知识结构；GraphRAG关心的是如何利用图结构组织和检索信息。本文的Graph关心的则是：一项任务应该经过哪些节点，节点之间如何交接，在什么条件下分支、重试、终止或转人工。

它也不等于“多个Agent在一起聊天”。

在一张可执行的任务图里，一个节点可以是大模型，也可以是一段确定性代码、一个API、一条规则，或者一次人工审批。

以LangGraph的抽象为例，一张图的核心由三部分构成：

1. State：任务当前处于什么状态，已经拿到了哪些信息。
2. Node：某一步具体做什么工作。
3. Edge：完成当前工作后，下一步去哪里。

翻译成产品语言，State是任务单，Node是处理岗位，Edge是流转规则。

所谓Graph Engineering，可以理解为：把Agent系统里原本藏在Prompt和上下文中的职责、状态、路由、检查和退路，变成显式、可执行、可追踪的系统结构。

重点不是“图”，而是“显式”。

三、从Loop到Graph，不是替换，而是组织升级

很多新概念都喜欢以“取代旧概念”的方式出场，Graph 和 Loop 其实不是这种关系。

一张 Graph 里，完全可以有 Loop。

例如，“查找官方信息”这个节点，内部可以由 Agent 不断搜索、阅读和补充资料，直到达到停止条件。但它完成后不能自由发挥，而是要把结果写入结构化状态，交给下一个节点校验。

可以用一句话概括：

Loop 负责让一个角色把局部任务做完；Graph 负责让多个局部任务组成可交付的结果。

四、把“竞品周报 Agent”改造成一张 Graph

回到开头的竞品周报。

如果把所有事都交给一个 Agent，流程是：

接收任务 → 自由搜索 → 自由分析 → 生成报告

这条路径很短，但每一步里都藏着大量未定义的判断。

换成 Graph 后，它可以被拆成下面这组节点：

1. 任务定义节点

先把“做竞品周报”翻译成可执行的任务：竞品范围、时间区间、重点维度、读者、截止时间、输出格式和必须回答的问题。

这一步没定义清楚，后面做得越快，只会偏得越远。

2. 并行采集节点

官网和公告、行业媒体、应用商店与用户反馈，可以分别采集，没必要排成一条长队。

每个采集节点可以使用自己的 Loop，但必须输出相同的字段：事件、时间、来源、原文链接、证据摘要和可信等级。

3. 事实校验节点

这个节点不负责写观点，只负责检查：

• 是否为本周新发生的事件；
• 是否存在可追溯的原始来源；
• 多个来源的口径是否一致；
• 事实和推测是否已经分开。

存在冲突的信息不直接删除，而是打上“待确认”标签，进入补充采集或人工确认路径。

4. 分析节点

只允许使用通过校验的证据。

这里才开始回答产品问题：竞品做了什么，可能想解决什么，对我们有什么影响，需要继续观察还是立即行动。

5. 审阅节点

审阅节点不是笼统地问“写得好不好”，而是按明确标准检查：核心结论是否有证据，是否漏掉重要竞品，建议是否超出材料支持的范围。

如果只有某条证据不合格，就把任务退回对应采集节点，而不是让整份报告从头重跑。

6. 人工确认与发布节点

生成报告和对外发送，是两个不同风险等级的动作。

Agent 可以生成待审核版，真正的发送动作则要根据读者和内容级别，决定是否需要人工确认。

经过这次拆分，竞品周报不再是一段连续对话，而是一条可检查、可回退、可暂停的任务链路。

这才是 Graph 带来的变化。

五、产品经理设计 Graph，要先回答七个问题

Graph 的技术实现可以交给工程团队，但这张图如何拆，要由产品和业务共同回答。

一名 AI 产品经理至少要把下面七件事说清楚。

1. 什么才算任务完成？

“生成一份报告”不是完成标准，只是输出形式。

报告覆盖多少个竞品？重要结论是否都有来源？哪些字段必须完整？出现多少条未确认信息时应该停止发布？

没有完成标准，Agent 就只能靠“感觉差不多了”来停止。

2. 任务状态里必须保存什么？

不要把 State 简单理解为全部对话记录。

真正有用的状态是结构化的：任务目标、当前阶段、已完成节点、证据列表、冲突项、审阅结果、重试次数、待人工决策事项。

只有状态可见，任务才能暂停、恢复和追责。

3. 每个节点只对什么结果负责？

一个节点最好只承担一种清晰职责。

采集节点不急着下结论，分析节点不自己编造证据，审阅节点不一边评分一边重写全文。

节点职责越混乱，出错时越难定位。

4. 任务在什么条件下改变路径？

产品经理不必决定每一步的代码，但必须定义关键分支。

证据不足是补充搜索，还是降低结论等级？超过重试上限是结束任务，还是转给人工？多个节点可以同时执行，还是存在严格依赖？

这些都是 Edge 和 Router 背后的产品规则。

5. 每个关键节点如何验收？

不是每个输出都适合再让另一个模型打分。

能用确定性规则的，就先用规则。例如字段是否缺失、链接是否可访问、日期是否在范围内。只有语义完整性、逻辑一致性等问题，才需要模型参与判断。

验收标准要跟节点绑定，不要等到最终输出时才做一次总检查。

6. 哪些动作必须由人确认？

查询、摘要和起草，与发送、删除、付款、更改业务状态，风险完全不同。

产品经理需要按动作的可逆性、影响范围和责任等级，划定自动执行、执行前确认和全程人工三类边界。

人工节点不是系统不够高级的表现，而是系统责任清晰的表现。

7. 失败以后如何续跑，运行过程如何追踪？

图不只要设计成功路径，也要设计失败路径。

调用超时后重试几次？局部节点失败是否影响全局？已完成的结果是否需要保留？某一版 Prompt 上线后，到底是哪个节点的通过率下降了？

如果系统只记录最终答案，产品团队就只能看到“这次又不对”，却不知道错在哪里。

六、什么时候值得从 Loop 升级到 Graph？

Graph 不是 Agent 项目的标准答案。

当一项任务出现下面几个信号时，再考虑图式编排更合适：

1. 路径会根据中间结果变化。 不同输入会进入不同分支，也可能返回前面的节点。
2. 有多个可以独立完成的专业任务。 它们可以分工或并行，且有明确的输入输出。
3. 需要长时间运行。 任务可能跨越几分钟、几小时甚至几天，期间要暂停、恢复或等待外部信息。
4. 需要多道质量检查。 单点错误会向后放大，不适合只在最终结果上验收。
5. 涉及高风险动作。 任务会影响用户、资金、客户关系、业务数据或对外承诺，必须有权限和人工关口。

但如果任务只是固定顺序的三四个步骤，普通 Workflow 就足够了。

如果任务只有一个核心角色，但需要根据环境反馈反复尝试，使用 Loop 更直接。

如果任务需要多角色分工、动态路由、并行执行、中途校验和人工介入，Graph 才开始显示价值。

一个实用的判断顺序是：

先看单次调用能不能解决，再看固定 Workflow，然后是 Loop，最后才是 Graph。

每向后走一步，系统获得了更强的表达能力，也增加了时延、成本、调试和运维负担。

如果一条业务流程本身就没人说得清楚，把它改成 Graph，只会让混乱沿更多条边流转。

七、Graph Engineering 对 AI 产品经理意味着什么？

过去设计一个 AI 功能，产品经理常常把重点放在两件事上：用户怎么提问，模型怎么回答。

当 Agent 开始操作工具、改变数据和推进任务，产品设计的单位就不再只是页面、功能和对话，而是一项能够被追踪、验收和交付的任务。

这会直接改变产品经理的交付物。

除了原型和 PRD，AI 产品经理还需要逐步建立几类新文档：

• 任务状态表：系统需要记住什么，哪些字段可以被哪个节点更新。
• 节点定义卡：每个节点的职责、输入、输出、工具、时限和验收标准。
• 路由决策表：什么条件下继续、返回、重试、终止或转人工。
• 权限与确认清单：哪些动作可以自动执行，哪些动作必须停下来。
• 节点运行看板：每个节点的成功率、平均耗时、重试率、人工接管率和单任务成本。

产品经理不必亲自写出每个节点的实现代码，但必须能说清楚为什么这样分工，结果怎么验收，出错以后怎么处理。

因为到了 Graph 阶段，产品的核心不再是让模型“看起来更聪明”，而是让整个系统“可以被管理”。

八、新词会过去，系统问题不会

Graph Engineering 目前更像一组正在被重新命名和归纳的工程实践，它还不是一套边界统一的标准。

但它指向的问题很具体。

当 Agent 只负责回答时，出错通常只是一次体验问题。当 Agent 开始发邮件、改库存、调价格、操作客户数据时，出错就变成了流程、权限和责任问题。

模型能力越强，它能做的动作越多，系统越需要清晰的结构。

所以，从 Loop 到 Graph 不是为了追一个新名词，也不是为了把 Agent 架构画得更漂亮。

它是 AI 产品从“能跑”走向“可交付”时，迟早要补上的一层工程能力。

Loop 让 Agent 开始行动，Graph 让它在真实业务里走对路。

参考资料

1. LangGraph：Graph API overview
2. Anthropic：Building effective agents
3. Microsoft GraphRAG Documentation