当Agent开始承担复杂工作，产品经理需要设计的不仅是任务流转，还有判断权与质疑机制。本文通过Codex对照实验，对比单Agent与Graph Engineering在分析Notion Agents时的表现，揭示Graph的真正价值并非让模型更聪明，而是让结论更经得起推敲。

我准备写Graph Engineering时，在Codex里做了两轮对照实验。

题目并不复杂：分析Notion Agents的产品定位、核心用户、关键场景、商业价值与风险，并判断它是否代表下一代办公产品。第一轮，我先让一个Agent独立完成，再把同一道题拆给用户与场景、商业与竞争、证据与风险三个节点。第二轮，我固定了13项资料和输出要求，又让增强单Agent与Graph各自独立运行三次。

六次匿名成对判定中，Graph被选中了五次。

但这不是一场碾压。其中一次复测，两名评审给出了相反答案；增强单Agent的行动建议也多次更直接。Graph没有稳定写出更多信息。反复出现的差异是：它更容易提出会推翻自身结论的反方观点，也更少把推断包装成事实。

这让问题变得更有意思：如果Graph没有让模型明显变聪明，反而增加了调用次数和编排成本，我们为什么还要使用它？

至少在这次实验里，答案不是“Agent越多越好”。更值得讨论的是：当Agent开始承担复杂工作，产品经理需要设计的不只包括任务怎么流转，还包括谁负责判断、谁有权质疑，以及什么条件下结果才允许交付。

不过，在讨论实验之前，需要先把Graph Engineering这个最近突然流行起来的词说清楚。

一、Graph Engineering到底是什么？

1. 新的是名字，不是图式工作流

“Graph Engineering”在2026年7月中旬突然进入Agent圈的讨论。LangChain随后专门写了一篇回应：这个词确实带有新一轮行业黑话的味道，但它对应的问题并不虚构——当模型开始承担真实工作，系统不能把所有路径、检查和交付都寄托在模型临场判断上。

但图式工作流本身并不新。LangChain也明确承认，他们已经用LangGraph做了三年。所谓新变化，不是人类终于发明了节点和连线，而是今天放进节点里的不再只是代码或一次模型调用，也可以是一个能够独立规划、调用工具并完成任务的Agent。

所以，Graph Engineering目前更适合被看作一个新兴标签，而不是已经形成统一定义的标准技术名词。

2. 它不是知识图谱，也不是多开几个聊天窗口

这里说的Graph，不是知识图谱，也不是GraphRAG，更不是同时打开三个聊天窗口，让三个Agent各写一份答案。

一个执行图至少包含三样东西：

1. 节点：谁负责完成哪一部分工作；
2. 边：一个节点完成后，任务被交给谁，什么条件下回退或转向；
3. 状态：各节点共同依赖的事实、当前结论和未解决问题。

在LangGraph的定义里，节点负责执行工作，边决定下一步运行哪个节点，共享状态保存系统当前的快照。节点既可以是一段确定性代码，也可以是工具调用、一次模型调用，甚至一个内部还有自己循环的完整Agent。

这一区别很重要。把三份结果复制到同一个文档里，只能叫并行生成。只有当一个节点的结果会改变另一个节点的行动，质疑可以触发修改，失败可以回退，某些结论还必须经过审批，系统才具有“图”的约束意义。

3. Loop和Graph不是替代关系

很多讨论把Loop和Graph描述成两个时代：过去做循环，现在做图。这个说法适合传播，但技术上并不准确。

循环本身就是一种最简单的有向图。生产中的Agent Graph也往往包含循环：工具调用失败后重试、证据不足时继续搜索、评审不通过时退回修改，或者暂停等待人工确认。LangChain的总结也很直接：Loop不是Graph的反面，而是Graph的简单形态。

如果一定用产品经理能理解的一句话区分：

Loop主要解决一个Agent如何继续行动和自我修正；Graph更关心多个角色如何分工、交接、检查、回退和停止。

Codex的子任务机制提供了一个可以直接观察的例子：主任务能够启动多个专业子任务并汇总结果，用户也可以查看各子任务的活动；代价是每个子任务都要独立进行模型与工具调用，因此通常比单Agent消耗更多token。

我们这次搭建的，是一个最小版本：三个专业节点先独立分析，再互相质疑，最后由主节点综合。它还没有动态路由、检查点和故障恢复，不能称为完整的生产级Graph。但它已经足以检验一个更具体的问题：当“提出观点”和“反对观点”不再由同一个Agent同时负责，最终结论会不会发生变化？

先看第一轮发生了什么。

二、第一轮实验：答案变得更谨慎了

我给Codex的测试题是：

分析Notion Agents（重点参考Notion 3.6）的产品定位、核心用户、关键场景、商业价值与主要风险，并判断它是否代表下一代办公产品的演进方向。

单Agent第一次给出的答案，其实已经相当完整。它覆盖了个人Agent与团队Custom Agents的区别，分析了产品运营、客户支持、项目管理等用户，也讨论了credits计费、MCP连接、提示注入和竞品压力。最后的判断是：

Notion Agents代表下一代办公产品的重要演进方向。

这份答案没有明显硬伤。如果把它作为一份普通的竞品分析交出去，多数人不会立刻发现问题。

但它有一个结构性缺陷：提出观点、寻找证据、审核推断和批准交付的，是同一个Agent。它当然可以在Prompt里被要求“请主动反思”，可反思是否真的发生，仍然取决于它在同一条推理链里是否愿意推翻自己。

于是我没有继续给Prompt加要求，而是把任务拆成三个节点：

• 用户与场景节点：只回答核心用户、JTBD、采用前提和场景优先级；
• 商业与竞争节点：只回答计费、商业价值、替代方案和采购阻力；
• 证据与风险节点：只检查事实边界、安全风险，并提出最强反方观点。

图注：三个节点不是同时写三篇完整分析，而是分别承担限定责任。截图保留了节点从1/3、2/3到全部完成的真实进度。

节点完成并不意味着把三份文字拼在一起。我又让它们互相质疑，只保留会改变最终结论的问题。

会改变结论的质疑有三条。

第一，功能可用不等于用户会采用。一个团队即使有大量重复工作，只要知识源陈旧、流程没有负责人，Agent只会更快地复制混乱。

第二，高频、规则明确不等于应该使用Agent。字段同步、固定提醒和简单路由，传统规则自动化可能更便宜、更稳定。Agent只有在任务涉及非结构化输入、跨工具信息和语义判断时，才更可能体现价值。

第三，功能集成不能直接推出ROI或护城河。Notion 3.6加入Office文件读写、Outlook邮件与日历以及新的MCP连接，只能证明执行边界扩大，不能证明客户已经节省工时、提高留存，或者愿意把关键流程长期交给它。

图注：交叉质疑没有简单追加一个“风险章节”，而是直接改变了场景选择、可回滚边界和商业结论。

经过交叉质疑后，主节点把结论改成了：

Notion Agents具备下一代办公控制层的候选形态，但现有资料不能证明它已经带来可靠、经济且可规模化的生产率提升。

它没有否定Notion Agents的方向性，却把“已经代表下一代”降级为“候选形态”，同时补上了可靠性、单位经济和可规模化三个验证条件。

不过，结论更谨慎，不代表Graph就一定更好。它也可能只是因为用了更多Agent、更多调用和更详细的节点提示词。

三、第一轮只能算案例，不能算证明

如果文章写到这里就宣布Graph获胜，其实是在用一个不公平的实验支持自己想要的观点。

第一轮至少有五个问题。

第一，计算投入不相等。Graph用了三个节点、交叉质疑和主节点综合，单Agent只有一次完整生成。

第二，提示词不相等。三个节点的职责被写得很具体，而普通单Agent拿到的是一个相对宽泛的分析任务。

第三，只有一道题、一次运行，无法排除模型输出的随机性。

第四，实验设计者同时负责判断结果，容易偏爱更符合自己预期的版本。

第五，我们搭建的是固定分发、质疑和汇总结构，还没有动态路由、检查点、自动恢复和人工审批。严格地说，它只是一个最小Graph实验，不是生产级Agent Graph。

所以第一轮最多能说明：改变任务结构后，结论发生了变化。它不能说明变化一定来自Graph，更不能说明Graph普遍优于单Agent。

为了排除最直接的一种解释——“Graph看起来更好，只是因为Prompt写得更详细”——我补做了第二轮受控实验。

四、第二轮：增强单Agent对比最小Graph

第二轮保持五个条件一致：同一道测试题、同一组13项固定资料、相同的六个内容维度、相近的正文篇幅，以及事先确定的评价标准。

对照组也不再是普通单Agent，而是增强单Agent。它被明确要求依次检查用户、场景、商业、竞争、证据和风险，并主动提出最强反方观点。换句话说，能够通过一个好Prompt补上的要求，尽量都补给它。

Graph组仍然由三个节点分工，但每个节点只能处理自己的责任范围。三个节点完成后互相质疑，再由主节点综合。两份稿件统一匿名，不向评审暴露生成架构；两名模型评审分别按A→B和B→A的顺序阅读，以缓解模型评审中已知的位置偏差。反转顺序只能减少一种干扰，不能消除模型评审本身的噪声。

图注：Graph与增强单Agent稿件先匿名为A/B，两名模型评审采用相反阅读顺序，提示中不暴露生成方式。

第一次受控运行中，两名评审都选择了Graph。但这仍然可能只是一次偶然结果，所以我沿用相同条件，让增强单Agent与Graph各增加两次独立运行。加上原受控实验，每种架构共得到三份候选稿，每一轮接受两次匿名成对判定。

结果如下：

• 原受控实验：匿名评审A选择Graph，匿名评审B选择Graph；
• 稳定性复测2：匿名评审A选择Graph，匿名评审B选择增强单Agent；
• 稳定性复测3：匿名评审A选择Graph，匿名评审B选择Graph。

六次匿名成对判定中，Graph获得五次偏好，增强单Agent获得一次。

这里最值得保留的不是“五比一”，而是第二次复测中的分歧。一名评审认为Graph更擅长提出替代解释，另一名评审则认为增强单Agent对事实、推断和作者判断的标签更完整，试点指标也更直接。

这说明Graph没有获得稳定的全维度优势。样本也远远不足以把五比一解释成胜率，更谈不上统计显著性。它只能支持一个很窄的表述：在这项产品分析任务的重复运行中，Graph更经常被模型评审偏好。

五、Graph赢在哪里，又没有赢在哪里？

把总偏好拆开看，结果比“Graph更强”复杂得多。

首先，Graph没有稳定扩大信息覆盖。两种方案基本都能谈到用户、场景、商业、竞争、安全和治理。只要Prompt足够完整，单Agent已经可以覆盖产品分析的大部分标准框架。

其次，增强单Agent的可执行性并不弱。它多次给出了更整齐的试点方案，例如运行四周、记录准确率和返工率、设置额度预算、指定负责人和停用开关。这些建议对产品经理而言甚至更容易直接复制。

Graph最稳定复现的差异，是反方能力。

三次Graph运行都把“也许根本不该使用Agent”带入了最终结论。这个反方不是在文章末尾补一句“也要注意风险”，而是实际改变了产品选择：低歧义流程优先考虑规则自动化；高风险外部写入保留人工审批；功能集成只能写成待验证假设，不能直接推导ROI和护城河。

另一个反复出现的特征是证据边界更克制。Graph版本更频繁地区分四件容易混淆的事：厂商宣称与已验证成效、Notion内部版本记录与外部动作回滚、功能存在与商业优势、Custom Agent与外部Agent的数据和权限承诺。

我最终保留的结论是：

Graph Engineering没有让每个Agent更聪明，它只是让任何一个Agent都不能独自拥有最后解释权。

如果一个Agent既负责提出商业假设，又负责证明假设成立，还负责决定答案是否可以交付，那么Prompt里的“请反思”只是道德要求。Graph做的，是把反对者和验收者写进系统结构。

当然，这种结构有成本。Graph使用了更多模型调用，也产生了更多中间结果和协调工作。如果任务低风险、低复杂度，增加的治理成本可能大于它带来的质量收益。

六、产品经理要设计的不只是图，还有责任

很多产品经理看到Graph，第一反应是画流程图：这里分支，那里合并，失败后回退。

流程图当然需要，但它还不够。只画任务怎么走，很容易把Graph做成一条更复杂的流水线。决定结果质量的，是每个节点拥有什么责任和权限。

1. 谁负责判断

节点不能只是按部门或内容目录拆分，而要按独立判断责任拆分。

例如，商业节点可以提出“用量计费可能提高客单价”，但不能同时负责证明这一判断已经成立。证据节点必须有权把它降级为待验证假设，并指出资料中缺少收入、留存和真实使用成本。

2. 谁有权质疑

质疑节点的任务不是润色，也不是让答案看起来更平衡。它应该寻找能够改变结论的问题：有没有更便宜的替代方案？风险能否被内部回滚？数据是否只来自厂商？如果反方成立，系统需要修改哪一段结论？

如果质疑不会触发修改，它只是装饰性评审。

3. 各节点依据什么事实协作

多个Agent共享的不能只是不断复制的聊天记录。产品经理需要定义共享状态：哪些事实已经核验、哪些是假设、当前结论是什么、还有哪些分歧没有解决、成本和风险是否超过阈值。

共享状态越模糊，节点越容易重复工作，或者在不同事实版本上得出互相冲突的答案。

4. 什么条件下结果允许交付

“Agent说完成了”不等于系统应该结束。交付条件至少要回答：必需证据是否齐全？关键反方是否得到回应？高风险动作是否经过人工确认？失败后回到哪个节点？超过多少时间、调用次数或费用后必须停止？

这也是Agent产品与普通聊天产品的根本差异。聊天产品可以把一段回答交给用户自行判断；一旦Agent开始发送邮件、修改外部数据、创建日程或分配任务，产品必须提前设计谁有权批准，以及错误发生后如何追责和补救。

七、不是每个任务都应该做成Graph

Graph Engineering很容易成为新的过度设计理由。一个任务能拆成多个角色，不代表它就值得多Agent化。

以下任务通常更适合先用单Agent或普通工作流：

• 目标单一，几步之内可以完成；
• 输出容易由用户立即检查；
• 错误影响低，而且能够轻易重做；
• 不涉及多种权限、外部写入或独立审批；
• 任务路径高度开放，预先规定节点反而限制探索。

LangChain也给出了类似反例：通用深度研究需要动态规划、搜索和综合，过早把路径写死，可能不如让Agent在一个更自由的循环中自主决定下一步。

产品经理可以先问四个问题：

1. 这个任务是否存在相互独立的责任，而不只是内容分段？
2. 某个判断出错时，是否需要另一个角色拥有否决权？
3. 任务是否包含不同权限、不可逆动作或必须留痕的交接？
4. Graph增加的成本，能否通过质量、稳定性或风险降低得到回报？

如果四个问题大多是否定答案，一个经过良好提示的单Agent通常更合适。

八、产品经理可以直接使用的最小Graph清单

如果任务确实需要Graph，不必一开始就搭建十几个Agent。可以先回答下面十个问题，定义最小结构：

1. 任务目标：系统最终要交付什么业务结果？
2. 节点责任：每个节点独立判断什么，又明确不负责什么？
3. 输入契约：节点能读取哪些事实、数据和上游结果？
4. 输出契约：节点必须返回哪些字段、证据和状态？
5. 质疑权：谁可以否定、退回或要求补充证据？
6. 共享状态：哪些事实、假设、分歧和成本对所有节点可见？
7. 验收条件：满足什么条件才允许进入下一步或交付？
8. 人工升级：哪些风险、金额或外部动作必须由人确认？
9. 回退路径：失败后回到哪里，如何避免重复执行副作用？
10. 停止与预算：最多允许多少时间、模型调用和费用？

这份清单不是为了让产品经理变成Agent工程师。它的用途是把过去隐藏在“模型应该会自己判断”里的要求，转换为团队能够讨论和验收的产品规则。

回到最初的问题：Graph Engineering真的比单Agent更好吗？

这次实验不能给出普遍答案。它只有一种产品分析任务、每种架构三次运行，评审仍然是模型评审，而且Graph消耗了更多调用。五比一不是统计胜率，更不能代表生产环境。

但它给了我一个更具体的判断：完整Prompt已经能让单Agent覆盖大部分内容。Graph值得承担额外编排成本的情况，不是需要多生成几个观点，而是需要把责任分开，让反方有权修改结论，让证据不足能够阻止交付。

产品经理过去用流程图定义功能怎么走。当Agent开始执行工作，我们还需要用责任图定义谁判断、谁质疑、谁批准，以及失败后回到哪里。