7.8
深览指数
科技人人都是产品经理·冲量AI··AI 生成
Graph Engineering 到底是什么？一口气讲清楚。
文章提出 Graph Engineering 并非炒作概念,而是 AI 工程从管理单次回答转向管理多个执行单元关系的必然阶段。作者以“AI 资讯日报”为例,串联了 Prompt、Context、Harness、Loop 和 Graph 五层能力阶梯,并清晰区分了控制 Graph 与知识 Graph 两类图。核心贡献在于明确指出了 Graph 的适用条件(如上下文腐败、无法独立复核、串行瓶颈)和评估标准(可靠、可追踪、可恢复、净收益为正),反对盲目跟风,强调应从故障中生长 Graph。适合已经搭建过简单 Agent 系统、正在寻找下一步架构方向的工程师阅读。原文 ↗
核心观点
- ▍Graph Engineering 不是给多 Agent 换名字,而是 AI 工程从管理单次回答,走向管理多个执行单元之间的关系。
- ▍Graph Engineering 的适用条件是出现了三种瓶颈：上下文腐败(context rot)、单节点无法提供真正独立的复核、以及任务串行导致效率低下。
- 01Prompt Engineering 管理“怎么说”,Context Engineering 管理“让模型看到什么”,Harness Engineering 管理“模型能用什么”,Loop Engineering 管理“任务怎样持续推进”,Graph Engineering 管理“多个执行单元怎样共同负责”。
- 02Graph 由三类要素构成：节点(执行单元,可以是 Agent、代码、工具或人)、边(定义了输入输出契约、路由条件、权限边界、失败语义)和状态(让系统可暂停、恢复、回放和局部重做)。
- 03文章区分了两种 Graph：控制 Graph 描述任务如何流动(“现在该轮到谁？满足什么条件才往下走？”),知识 Graph 描述信息之间的关系(“这些事实、人物、证据之间是什么关系？”)。
- 04一个好 Graph 的评估标准是：结果更可靠、过程可追踪、失败可恢复、净收益为正。
反方 / 局限
- — 作者承认 Graph Engineering 的底层技术(工作流、状态机、DAG、知识图谱)并不新,新的是“工程注意力从单点能力迁移到了关系质量”。
- — 多节点工作流有显著成本：更多模型调用带来延迟和费用,节点越多维护越复杂,边的格式变化可能造成连锁故障,知识关系会过期,并行结果可能冲突需要仲裁。
- — 如果任务只需一次回答、步骤高度耦合、数据量很小、或者系统连结果好坏都没有评估标准,那么上 Graph 通常是在提前购买复杂度。
Graph EngineeringPrompt EngineeringContext EngineeringHarness EngineeringLoop EngineeringContext Rot控制 Graph知识 Graph冲量AI
18 分钟 · 5 卡片 · 10 资料
读原文 →