Loop 不够用了？AI 工程下一站叫 Graph
最近 AI 圈又冒出一个新词：Graph Engineering。
Prompt 还没学明白，Context、Harness、Loop 已经轮番刷屏，现在又来 Graph。说实话，我第一反应也是烦：这是不是又一次换皮炒概念？
但我把几篇一手讨论和工程实践对完之后，判断变了。
这一次，变化的不是 Agent 数量，而是工程对象从"单次回答"，转向了"多个执行单元之间的关系"。
Prompt 管的是怎么说；Graph 管的是：研究、检索、写作、核查、审批分别由谁做，信息怎么交接，谁能否决谁，失败后从哪恢复。
如果你已经读过 Harness Engineering 系列，会发现 Graph 不是来取代 Harness 的——它是 Harness / Loop 再往外扩一层。
先把五层**摆清楚
我现在习惯用五层来看 AI 工程，而不是把它们当成互相淘汰的五个流派：
- Prompt Engineering：怎么说清楚任务
- Context Engineering：让模型在这一步看到什么
- Harness Engineering：模型能用什么工具、权限、运行时
- Loop Engineering：任务怎样持续推进、何时停止、失败怎么重试
- Graph Engineering：多个执行单元怎样共同负责
它们是嵌套关系：Prompt 放进 Context，Context 经 Harness 送到模型，Harness 支撑 Loop 跑起来，多个 Loop、工具、数据库和人再组成一张 Graph。
一句话：
模型变聪明，不等于系统变可靠。 单点智能解决不了分工、交接、权限、验证和恢复。
用一份「AI 资讯日报」把 Graph 讲透
抽象定义没感觉，换个具体任务：每天自动产出一份 AI 资讯日报。
要找当天重要新闻，读视频逐字稿和论文，去重，核对关键事实，最后存进笔记库。
如果这是一家小公司：
▸Prompt 是任务说明▸Context 是员工手里的资料▸Harness 是电脑、账号、工具台▸Loop 是日常工作制度▸Graph 是组织架构、信息流和责任链
早期你可能只丢一句："帮我整理今天最重要的 AI 新闻。" 这属于 Prompt 层——但"重要"没定义、时区没定义、要不要排除传闻也没定义。
然后你发现模型根本不知道今天发生了什么，于是上 Context：新闻源、论文、字幕、历史报告、术语表，而且不能一股脑塞，得按步骤选、压、排。
再往后，它得能搜网页、读字幕、写文件、碰权限边界——这是 Harness。
再往后，一次回答不够，得"执行—观察—判断—修正—再执行"，有停止条件和检查规则——这是 Loop。
到这里，一个设计良好的单 Loop 其实已经能独立交差。那为什么还要 Graph？
因为任务一长，单 Loop 会撞上三类结构性问题：
▸上下文越来越脏（context rot）▸同一个执行者很难真正独立检查自己▸所有活串行，时间都耗在等待上
于是你把大任务拆开：视频研究、论文研究、新闻研究可以并行；综合节点负责合并冲突；事实核查可以否决成稿；人类只在高风险节点介入。
Graph Engineering 关心的不是再堆几个 Agent，而是把这些关系设计清楚。
Graph 到底在工程什么？
我给自己用的定义是：
Graph Engineering = 设计和治理多个执行单元之间的关系，让节点有边界、边有契约、状态可恢复、结果可验证。
一张 Graph 至少有三样东西：
节点：执行单元。可以是 Agent，也可以是普通代码、搜索工具、数据库、规则引擎，甚至是人。格式转换、数字校验、去重，确定性代码能干，就别硬塞给模型。
边：不只是"下一步"箭头。边上应该回答：上游必须交哪些字段？传的是原始资料还是结构化结论？谁能读、改、否决？哪种状态走正常路径，哪种触发重试或升级？下游发现问题退回谁？
状态：系统已经抓了哪些来源、哪些结论过了核查、哪步在等人工、当前结果对应哪个版本。没有状态，复杂工作流只是更难查的黑箱；有了状态，才能暂停、恢复、回放和局部重做。
所以 Graph Engineer 不是画图的人，而是为关系负责的人。
别把两张 Graph 混成一张
社区里常把两种 Graph 糊在一起，我觉得这是最大误区之一。
控制 Graph：谁在什么时候做什么。三个研究节点可否并行？至少两类来源返回后综合才能开始？核查发现关键数字没来源时退回哪个研究节点？
知识 Graph：我们知道什么，以及它们怎样关联。哪家公司发了哪个模型，哪位研究者参与了哪篇论文，某条说法引用了哪项实验。
控制 Graph 记录决策怎样发生；知识 Graph 提供决策依据的语义关系。最好再用"决策轨迹"把两张图连起来：核查节点为什么驳回？读了哪些证据？用的哪个版本？
什么时候才该上 Graph？
Graph 不是成熟勋章，是用额外协调成本换可靠性和并行能力的架构。
只有这三种瓶颈出现时，我才认真考虑上 Graph：
- Context rot：单个 Agent 越做越糊涂，有效信息被噪声稀释
- 自我复核无效：让同一个 loop "再检查一遍"，经常只是顺着原推理路径打补丁
- 串行等待：本来独立的研究/抓取任务被硬串成一条慢链路
反过来，任务短、步骤紧耦合、数据量小、连结果好坏都没有评估标准，上 Graph 通常是在提前购买复杂度。
一个简单 loop 能稳定完成的事，不必拆成六个节点。
先证明单 loop 为什么失败，再决定哪一条关系值得被工程化。
怎么判断一张 Graph 是不是花架子
别看屏幕上闪了多少个 Agent 节点，只追问四件事：
- 结果是否更可靠：故意塞错误来源，核查能不能抓到；工具超时，系统会不会换路径
- 过程是否可追踪：最终文章里的一个数字，能不能回到原始来源、抽取节点、验证结果和版本
- 失败是否可恢复：某个视频字幕挂了，不该逼所有研究重跑
- 净收益是否为正：质量涨了多少、时延省了多少、多花了多少调用和维护
好的 Graph，不是让系统看起来更复杂，而是让复杂任务变得可控。
聊聊我的理解
Graph Engineering 底层零件并不新：状态机、工作流、DAG、检查点、知识图谱、LangGraph 这些早就在了。
但它有价值的地方，是把工程注意力从"把单个 Agent 调更聪明"，挪到了"把关系做对"。
多 Agent 描述你有几个 Agent；Graph Engineering 讨论它们为什么连接、怎样连接、连接失败怎么办。
如果你今天就想动手，我建议别先画一张宏大总图。
先做一个能跑的单 loop，记下它最常翻车的地方。是上下文脏？是自我检查假？还是独立任务被串死了？找到一个真瓶颈，再加一个节点和一条边，写清职责、输入、输出、失败条件和评估指标。验证净收益后，再扩下一段关系。
Graph 应该从故障中生长，而不是从架构图中生长。
Prompt 教会一个 Agent 做事；Graph 设计一群执行单元如何共同负责。
从一个聪明员工到一家可靠公司，中间差的不是智力，而是组织。
原文链接：https://mp.weixin.qq.com/s/w4YFYVgzkgB0NPeM4yeVzw
浙公网安备 33010602011771号