当AI从回答问题转向替用户做事，评测逻辑正在被彻底颠覆。Graph Engineering的提出，直指Agent产品从Demo到稳定上线的核心痛点：如何让一堆不稳定的智能节点在系统中可靠协作？本文从评测工程师和产品PM的双重视角，拆解这一新概念背后的真实挑战。

最近 AI 圈又冒出来一个词：Graph Engineering。

起因是 Peter Steinberger，也就是“龙虾之父”，提了一句大意差不多的话：

我们还在聊 loops，还是已经转向 graphs 了？

看到这句话的时候，第一反应大概率是：啊？老板会议上又要给我布置新课题方向了？ hahaha ~

这两年 AI 圈确实有点这样。

刚把 Prompt Engineering 讲明白，大家开始讲 Context Engineering。Context 还没完全消化，Agent Engineering、Loop Engineering 又来了。现在好了，又多了一个 Graph Engineering。

如果只看名字，很容易把它当成又一个包装出来的新黑话。

但站在模型评测工程师 + AI 产品 PM 的角度看，这个词其实值得看一眼。

尤其是最近K3出来，K3 Agent Cluster最近让这么多人惊艳的时间节点上，这个词提出来的很及时。

因为它背后说的，不是“模型又聪明了一点”。

它碰到的是一个更现实的问题：

当 AI 不再只是回答问题，而是开始替用户做事之后，怎么评估它、控制它、把它做成一个稳定产品？

以前测模型，很多时候是在测它答得对不对。

现在到了 Agent 阶段，它不只是回答一句话。它会查资料、调用工具、读文件、改代码、写报告、走审批，甚至在多个步骤之间自己做判断。

这时候再问“这个模型能力怎么样”，其实已经不够了。

更准确的问题应该是：

这套 AI 工作系统，能不能稳定把事情做完？

01 Graph Engineering 不是知识图谱，是任务执行图

先把概念讲白。

Graph Engineering 里的 graph，不要直接理解成知识图谱，也不必马上联想到 GraphRAG。

这里的 graph，更接近一张任务执行图。

图里有节点，也有边。

把 AI 做事的过程，从“一个 Agent 自己循环”，改成“多个节点按规则协作”。

听起来像工作流，对吧。

但它比普通工作流麻烦得多。

传统工作流里的节点，通常比较确定。一个接口成功就是成功，一个脚本失败就是失败，一个审批通过就是通过。

AI 节点不一样。

• 它可能表面上完成了任务，但里面有幻觉。
• 它可能工具调用成功了，但调用目标错了。
• 它可能报告写得很顺，但根本没解决用户的问题。
• 它可能评测分数不错，但真实用户还是不敢用。
• 这就是 Graph Engineering 真正难的地方。

难点不是画一张漂亮的图。

难点是：

怎么让一堆不稳定的智能节点，在一个相对稳定的产品系统里协作。

02 从模型评测看：不能只考智商了

模型评测工程师以前最熟悉的工作，是做 benchmark。

• 给一个输入。
• 看一个输出。
• 对一个标准答案。

这套方法在 Chatbot 阶段很好用。

问事实、问数学、问代码、问摘要质量，都可以做题库。模型答对多少，分数是多少，版本之间有没有回归。

但 Agent 产品不是这样。

Agent 做任务的时候，中间有很多步。每一步都可能影响最后结果。

比如一个 AI 报告生成产品，用户说：

帮我生成一份本季度竞品分析报告。

如果是 Chatbot，它可能直接写一篇报告。

如果是 Agent，它可能会查资料、读内部文档、提取数据、生成结构、写正文、做事实核查。

如果是 Graph Engineering，系统会更像这样：

1. 先确认报告对象、用途和时间范围。
2. 再检索内部资料和外部信息。
3. 再判断来源可信度。
4. 再抽取关键数据。
5. 再生成分析结论。
6. 再写报告。
7. 再做事实核查和合规检查。
8. 最后让用户确认并导出。

你看，这里面没有哪一步特别玄。

但每一步都要评测。

所以到了 Graph 阶段，评测会从模型输出评测，变成系统行为评测。

要测的不只是最后那篇报告好不好。

还要测：

• 任务成功率：用户交代的事情，最后有没有真的完成。
• 节点通过率：每个节点自己的职责有没有完成。
• 工具调用准确率：该不该调用工具，调用哪个工具，参数有没有填对。
• 路由准确率：失败以后有没有回到正确节点，而不是从头乱跑一遍。
• 状态一致性：前一个节点的推测，有没有被后一个节点误当成事实。
• 人工介入率：哪些地方必须让人确认，哪些地方其实可以自动完成。
• 成本和延迟：一个任务跑完花多少钱、多久，用户到底等不等得起。

这里才是 Graph Engineering 真正有意思的地方。

它逼着我们承认一件事：

Agent 上线以后，评测就不能只考智商了，还要考它会不会按流程干活。

一个模型很聪明，不代表这套产品稳定。

一个节点表现不错，也不代表整条链路可靠。

最后产品能不能用，往往卡在那些很琐碎的地方：状态传错了、工具调早了、风险没拦住、用户不知道 AI 做到哪了。

这些问题不性感。

但上线以后，天天打脸的就是这些问题。

03 从产品看：Graph 是把业务拆成 AI 能执行的结构

站在产品 PM 视角，Graph Engineering 也不是单纯的技术架构。

它更像是在做一件老产品经理很熟的事：

把真实业务流程，拆成系统可以执行、可以检查、可以兜底的结构。

只不过这次，系统里多了 AI。

这件事比写 prompt 难多了。

因为真实业务流程通常很脏。

• 用户说不清需求。
• 数据源不干净。
• 判断标准不统一。
• 责任边界有点糊。
• 异常情况一堆。

很多环节以前靠人脑硬撑过去。

比如客服场景。

用户问：“我这个订单怎么还没到？”

一个简单 Agent 可能查一下物流，然后回复用户。

但真正做成产品时，会发现它不是一个问答问题。

它至少涉及：

• 识别用户身份
• 判断订单状态
• 查询物流信息
• 判断是否超时
• 判断是否符合赔付规则
• 判断是否需要转人工
• 生成用户能接受的解释
• 记录处理结果

任何一步错了，体验都会出问题。

所以 PM 要设计的，不只是“AI 怎么回复”。

更重要的是：

AI 在什么时候做什么，做到哪一步需要停，什么情况必须让人接管。

这就是 Graph 的产品意义。

它不是为了把系统画复杂。

它是为了把复杂性拆开，让每个节点都有自己的边界。

这些东西定义不清楚，Agent demo 看起来会很智能，但上线会很痛苦。

因为 demo 只要跑通一次，就很惊艳。

产品要面对真实用户、真实数据、真实异常。

这也是为什么很多 Agent 产品会卡在从 0 到 1 之后。

不是模型不会做。

是产品没有把它做事的过程设计清楚。

用户看不到 AI 做到哪一步。

系统不知道失败发生在哪里。

模型升级以后，旧流程突然变差。

工具权限一放开，风险跟着上来。

出了问题，没人知道该回滚哪一段。

所以 Graph Engineering 到最后，会变成一堆很产品的问题。

不是“要不要多 Agent”。

而是：

• 任务怎么拆。
• 状态怎么管。
• 权限怎么控。
• 失败怎么退。
• 用户怎么接管。
• 结果怎么验收。

这其实已经很像在设计一个小型组织的运转方式了。

只不过这个组织里，有些成员是模型，有些是工具，有些是真人。

04 最佳实践：K3 Agent Cluster 把 Graph 做成了产品入口

如果只讲 Graph Engineering，很容易显得像概念。

但实际体验下来， Kimi K3 的 Agent Cluster / Agent Swarm，其实已经把这套东西做成了一个用户能直接选择的产品入口，其实给我们提供了一个很好的工程实践案例。

Kimi 官方对模式选择的描述很清楚：

K3 适合复杂对话、文档生成、PPT、表格和多步骤任务；K3 Cluster 适合大规模搜索、批处理和一次性完成高容量任务。

它的 Agent Swarm 思路也很直白：

不是让一个 Agent 从头跑到尾，而是让主 Agent 先拆任务，再协调多个 sub-agent 并行工作。官方帮助里提到，Agent Swarm 可以协调最多 300 个 sub-agents，支持 4000+ 次工具调用，适合大规模搜索、长文写作、批处理这类任务。

这就是一个很典型的 Graph Engineering 产品形态。

只不过它不是让用户手动画图，而是把 graph 藏在产品后面。

用户看到的是：

• K3。
• K3 Cluster。
• Agent。
• Agent Swarm。

但系统背后做的事情，更像是：

• 目标理解。
• 任务拆解。
• 子任务分发。
• 并行执行。
• 工具调用。
• 结果汇总。
• 冲突处理。
• 最终交付。

这和单 Agent 的体验不一样。

单 Agent 更像一个人在那里从头做到尾。

K3 Cluster 更像临时拉起一个项目组，让不同子 Agent 同时开工。

比如让它做一份很长的行业研究：

• 一个子 Agent 去查政策。
• 一个子 Agent 去看竞品。
• 一个子 Agent 去找投融资信息。
• 一个子 Agent 去整理用户需求。
• 一个子 Agent 去做技术趋势。
• 最后主 Agent 把这些结果合成一份报告。

这就是 Graph Engineering 最容易被用户感知的地方：

任务不再是线性执行，而是被拆成一张协作网络。

这里有一个产品上很聪明的地方。

K3 没有把“节点、边、状态机、路由规则”这些工程概念直接甩给用户。

它把底层复杂度折叠成一个更容易理解的选择：

普通复杂任务，用 K3。

大规模任务，用 K3 Cluster。

需要端到端交付，用 Agent。

这其实是 AI 产品化里很关键的一步。

Graph Engineering 如果永远停留在开发者框架里，它就是工程能力。

但当它被包装成一个普通用户能理解的任务模式，它才开始变成产品能力。

所以，如果说 LangGraph 代表了 Graph Engineering 的工程侧实践。

那 K3 Agent Cluster 更像是它的产品侧实践：

把 graph 藏起来，把交付露出来。

当然，这里也要说句实在的。

K3 Cluster 很像 Graph Engineering，但它不是 Graph Engineering 的全部。

它更偏 Swarm，也就是横向扩展：更多 sub-agent、更并行、更多工具调用、更快覆盖更多信息。

而 Graph Engineering 还要继续问后面那些不太好看的问题：

• 这些 sub-agent 的输出怎么验？
• 互相冲突的结论怎么处理？
• 哪个节点出了错，能不能定位？
• 大规模并行会不会放大幻觉？
• 工具调用多了以后，权限怎么控？
• 用户怎么知道系统为什么得出这个结论？
• 模型升级以后，整条链路会不会回归？

所以 K3 给我们的最佳实践，不是“Agent 越多越好”。

它真正有参考价值的地方是：

把多 Agent 协作，从开发者框架做成了用户可感知的产品能力。

05 Loop 和 Graph 的区别，不是复杂度，是控制权

很多人会问：Loop 不也是循环、检查、返工吗？那 Graph 到底多了什么？

可以这么看：

Loop 更像一个人自己改稿。

• 写一版。
• 检查一下。
• 不满意再改。

Graph 更像一个小团队协作。

• 有人负责资料。
• 有人负责分析。
• 有人负责写作。
• 有人负责质检。
• 有人负责合规。
• 有人负责最后确认。

这两者没有谁彻底替代谁。

很多 Graph 里面也会有 Loop。

比如事实核查节点发现引用不可靠，会回到资料检索节点；写作节点发现结构不清楚，会回到大纲节点。

真正的区别在于：

Loop 是让 AI 自己反复试。Graph 是先把任务结构设计出来，再让 AI 在结构里行动。

从产品落地看，这个区别很重要。

因为用户不是只想看 AI 忙。

用户要的是结果可控。

06 为什么它会走向 Organization 能力

把 Graph Engineering 放到 AI 能力分层里看，它的位置会更清楚。

2024 年，Bloomberg 报道过 OpenAI 内部的五级 AI 能力框架：

Graph Engineering 很像是 L3 到 L5 中间的工程语言。

L3 解决的是：

一个 AI 能不能替用户做事。

Graph 解决的是：

多个 AI、工具、规则和人，怎么协作做事。

L5 想象的是：

一套 AI 系统能不能承接组织级别的工作。

所以这次所谓“叕进化了”，重点不只是模型能力进化。

更准确地说，是 AI 产品形态在进化。

从 Chatbot 到 Agent，是从对话走向行动。

从 Agent 到 Graph，是从个人执行走向组织协作。

再往后，才可能靠近所谓 Organization。

这里有一个很现实的判断：

未来的 AI 产品，不会只拼模型聪明程度，而会拼组织能力。

谁能把模型、工具、数据、权限、评测、审批、交付这些东西组织好，谁的产品就更接近可用。

从模型评测角度看，eval 也要跟着升级。

• 不能只做单点题库。
• 要做任务级评测。
• 要做链路级评测。
• 要做工具调用评测。
• 要做失败恢复评测。
• 要做多轮状态评测。
• 要做用户接管评测。

说得直白一点：

如果 Agent 是 AI 员工，Graph 就是它所在的组织流程。

模型评测工程师要做的，也不再只是考这个员工会不会答题。

还要看这个组织能不能正常运转。

07 最后说句实在的

Graph Engineering 当然有 buzzword 的成分。

AI 圈每隔一阵子，就会把一些已有实践重新命名一次。这事大家也都熟。

状态机、DAG、工作流编排、多 Agent 协作，这些东西都不是今天才有。

但这个词为什么还能被讨论？

因为它碰到了一个真实痛点：

Agent demo 很容易，Agent 产品化很难。

demo 阶段，跑通一次就够惊艳。

产品化阶段，要回答的问题就烦多了：

• 成功率是多少？
• 失败怎么发现？
• 错了怎么回滚？
• 用户怎么接管？
• 成本能不能接受？
• 日志能不能审计？
• 权限有没有越界？
• 模型升级后会不会回归？
• 某个节点换模型以后，整条链路会不会变差？

这些问题都不太适合做发布会金句。

但它们决定 AI 能不能真的进业务。

所以我理解的 Graph Engineering，不是“又来一个新概念”。

它更像是 AI 工程走到现在，必须补上的一层：

把 Agent 的能力，放进一个可评测、可观测、可控制、可交付的产品结构里。

从这个角度看，模型评测工程师和产品 PM 的工作会越来越交叉。

评测工程师不能只看模型分数。

产品 PM 也不能只看聊天体验。

两边最后都会撞到同一个问题：

这套 AI 系统，到底能不能稳定把用户的事情办成？

Graph Engineering 说到底，就是这件事。

不是让 AI 更像一个天才。

而是让一群不完美的 AI，在设计好的流程里，尽量稳定地交付结果。

参考节点

2024-01：LangGraph 发布。

Agent 的循环、状态和图式控制流开始被更清楚地工程化。参考：LangGraph。

2024-07：OpenAI 五级能力框架被报道。

L3 Agents 和 L5 Organizations 这条线，让“AI 从个人执行走向组织能力”的讨论更明确。参考：Bloomberg。

2025-03：Agent 工具链开始平台化。

Responses API、Agents SDK、tracing 等能力出现，行业重点转向编排、工具和可观测性。参考：OpenAI。

2026-07：Kimi K3 发布，并把 K3 Cluster / Agent Swarm 做成产品入口。

K3 Cluster 把多 Agent 并行、大规模工具调用和任务交付包装成用户可选择的模式。参考：Kimi Agent Overview、Kimi 模式选择说明。

2026：Graph Engineering 被重新拿出来讨论。

它不是全新技术，更像是过去两年 Agent 工程化问题的一次命名：多节点、状态、路由、回退、审批、评测和组织化执行。