Graph Engineering 是新范式，还是 AI 圈的又一个新词？
最近，AI 圈又出现了一个新概念：Graph Engineering。
起因是 OpenClaw 创作者 Peter Steinberger 在 X 上抛出一句话：
Are we still talking loops or did we shift to graphs yet?
我们还在讨论 Loop，还是已经转向 Graph 了？
随后，关于"Loop Engineering 已经过时""Graph Engineering 正在接棒"的讨论迅速增多。
从 Prompt Engineering、Context Engineering，到 Loop Engineering、Harness Engineering，现在又来了 Graph Engineering。它究竟代表了一次真实的工程范式变化，还是 AI 圈又给一个老问题换了新名字？
我的判断是：
Graph Engineering 不是全新的技术范式，但它准确描述了 Agent 工程正在发生的一次重心迁移：从让单个 Agent 持续工作，转向让多个 Agent 可靠协作。
这个判断并非只来自概念分析，也来自我做过的一个多 Agent 项目。
一个看起来成功、实际没有形成协作的多 Agent 系统
前段时间，我希望把自己处理复杂方案的工作方式做成一个 Web 系统。
平时遇到复杂需求，我会让两个不同模型分别思考，再让它们交叉评审。一个模型提出方案，另一个模型检查架构、风险和遗漏；然后把评审意见送回原模型继续修订。中间产物和最终结论会保存在同一个文件夹的 Markdown 文档中。
我希望把这套人工工作流变成一个多 Agent 聊天室：
- 用户提出需求。
- 多个 Agent 分别分析并提出方案。
- Agent 阅读和审核彼此的结论。
- 针对分歧继续讨论。
- 达成一致后生成最终方案。
- 用户进行最后确认。
当时，我只给了 Codex 一句话需求。借助长时间执行能力，它连续运行了十几个小时，最终做出了一个可以启动、也能够使用的 Web 页面。
如果验收标准只是"页面能打开、两个模型能回复"，项目已经完成。
但真正使用后，我发现两个模型的工作过程几乎完全割裂：
- 它们没有稳定的共享任务状态。
- 一个模型看不到另一个模型完整的推理背景与证据。
- 所谓评审，更像是把一段输出转发给另一个模型。
- 系统没有明确记录已解决和未解决的分歧。
- 没有可靠的长期记忆、上下文恢复和进度状态。
- 缓存命中与重复上下文成本也没有得到有效控制。
- 最终仍然需要我决定谁先说、转交什么、相信谁，以及怎样合并结论。
页面看起来像一个多 Agent 聊天室，底层却只是两个独立会话。
我得到的是两个 Agent Loop，却不是一个真正的 Agent Graph。
Prompt、Context、Loop、Graph、Harness 到底是什么关系？
最近这些概念经常被写成一条不断升级的路线：
Prompt → Context → Loop → Harness → Graph
但它们不是简单的版本替代关系，而是在解决不同层次的问题。
| 工程概念 | 主要问题 | 典型工程对象 |
|---|---|---|
| Prompt Engineering | 怎样向模型表达任务 | 指令、示例、输出约束 |
| Context Engineering | 模型执行时能看到什么 | 历史信息、知识、工具结果、状态 |
| Loop Engineering | 一个 Agent 如何持续执行与纠错 | 计划、行动、验证、重试、停止 |
| Graph Engineering | 多个 Agent 或流程如何协作 | 节点、边、路由、分歧、共识 |
| Harness Engineering | 整个 Agent 系统如何可靠运行 | 工具、记忆、权限、评测、追踪、恢复 |
一个更准确的理解是：
- Loop 是时间结构：一个 Agent 如何持续推进任务。
- Graph 是组织结构：多个 Agent 如何分工、交接、审核和收敛。
- Harness 是运行系统：怎样让 Loop 和 Graph 在真实环境中可靠运行。
Graph 不会让 Loop 消失。Graph 中的一个节点，本身就可能是一个带有计划、工具和验证能力的完整 Agent Loop。
Graph 也不会取代 Harness。共享状态、长期记忆、权限控制、执行环境、追踪、评测和故障恢复，仍然需要 Harness 提供。
Loop 解决持续执行，Graph 解决可靠协作
一个典型的单 Agent Loop 可以表示为：
它要解决的问题是：
- Agent 如何知道下一步做什么？
- 工具执行失败后是否重试？
- 测试不通过时怎样修正？
- 什么条件下可以停止？
但多 Agent 系统增加了另一组问题：
- 谁负责提出方案，谁负责审核？
- Agent 是否应该独立思考，还是共享全部上下文？
- 发生分歧时，任务流向哪个节点？
- 谁能驳回结果？
- 什么叫"已经达成共识"？
- 哪些决策必须由人确认？
- 某个节点失败后，是局部恢复还是全局重跑？
这些不是单个 Agent 内部的执行问题，而是多个执行单元之间的协作协议问题。
真正的 Graph 不只是把多个头像放进聊天室
如果重新设计前面的多 Agent 方案评审系统，它至少需要下面这张执行图：
这张图真正有价值的部分不是节点数量，而是边所承载的协议。
比如"交叉评审"这条边，不能只是把一大段自然语言转发过去。它应该明确规定：
- 评审者必须看到哪些上下文？
- 输入方案采用什么结构？
- 输出必须包含哪些字段？
- 需要区分事实错误、架构风险、实现成本还是产品取舍吗？
- 被评审方是否必须逐项回应？
- 哪些意见构成阻断问题？
- 最多允许多少轮修订？
Graph Engineering 的门槛不是画出一张图，而是把 Agent 之间的关系变成可执行、可恢复、可观测、可评测的协议。
边上需要传递什么？
很多多 Agent 系统把"完整聊天记录"当作共享状态。这种方式很容易实现，但会迅速产生三个问题：
- 上下文越来越长，成本持续增加。
- 关键决策被淹没在大量对话中。
- 不同模型难以知道哪些内容已经确认、哪些仍有争议。
更合理的做法，是让边传递结构化产物，而不是无差别转发全部对话。
例如，一次方案评审可以使用类似下面的协议：
json
{
"proposal_id": "architecture-v2",
"reviewer": "agent-b",
"accepted_points": [
"采用事件日志保存聊天室历史"
],
"blocking_issues": [
{
"id": "memory-001",
"problem": "两个 Agent 没有共享任务状态",
"evidence": "评审节点只能看到上一轮文本",
"required_change": "增加共享状态存储与检查点"
}
],
"non_blocking_suggestions": [
"为不同模型分别优化稳定 Prompt 前缀"
],
"verdict": "revise"
}系统还需要维护一份独立于聊天记录的共享状态：
- 当前目标和验收标准
- 已确认的设计决策
- 未解决的争议
- 每个节点的输入、输出和状态
- 失败记录与重试次数
- Token、时间和工具调用预算
- 人工审批结果
- 最终方案对应的证据链
这也是"共享记忆"和"Prompt Cache"必须分开的原因。
- 共享记忆由应用和 Harness 管理，用于让不同 Agent 理解共同任务状态。
- Prompt Cache通常属于具体模型供应商，用于降低重复前缀的成本和延迟。
一个模型的缓存不能直接变成另一个模型的记忆。缓存命中率高，也不代表多个 Agent 真正共享了工作状态。
Graph 与 Harness 的边界
Graph 和 Harness 经常被混为一谈。
可以用下面的方式区分：
| 问题 | 更偏 Graph | 更偏 Harness |
|---|---|---|
| 谁先工作、谁后工作 | ✓ | |
| 分歧后返回哪个节点 | ✓ | |
| 谁拥有审核和否决权 | ✓ | ✓ |
| 共享状态怎样持久化 | ✓ | |
| 工具和文件权限如何控制 | ✓ | |
| 失败后从检查点恢复 | ✓ | ✓ |
| 怎样追踪完整执行轨迹 | ✓ | |
| 怎样评估质量、成本和延迟 | ✓ | |
| 人工确认放在哪个阶段 | ✓ | ✓ |
Graph 描述的是协作拓扑和状态转移；Harness 负责让这张图能够在真实环境中长期、可靠、受控地运行。
因此，一个系统可能有清晰的 Graph，却没有可靠的 Harness：流程图画得很完整，但任务失败后只能全部重跑，状态无法恢复，权限也无法审计。
反过来，一个强大的单 Agent Harness 也可能没有复杂 Graph：它只有一个动态 Agent Loop，却具备工具、文件系统、长期状态、检查点和人工审批。
为什么说"名字是新的，技术并不新"？
节点、边、状态与路由并不是新概念。
工作流引擎、状态机、DAG、Actor System 和业务流程编排，早就在处理这些问题。LangChain 也明确表示，他们围绕 LangGraph 已经实践多年。
LangGraph 对图的描述非常直接：
- 节点负责执行工作。
- 边决定下一步发生什么。
- 状态在图中流动。
- 转移可以是确定性的，也可以根据节点结果或外部信号动态决定。
真正的新变化是：现在可以放进节点里的东西变了。
过去，一个节点通常是一段确定性代码、一次 API 调用或者一个简单的 LLM 请求。现在，一个节点可以是拥有上下文、工具、记忆和内部循环的完整 Agent。
我们编排的不再只是函数，而是具有一定自主性的执行者。
这使 Graph 中的边必须处理更多不确定性：
- Agent 可能误解任务。
- Agent 可能给出结构正确但事实错误的结果。
- Agent 可能反复讨论却无法收敛。
- Agent 可能为了证明自己正确而忽略反方证据。
- Agent 的运行成本和时间难以提前预测。
所以，状态、预算、否决、恢复、评测和人工确认必须成为图中的一等公民。
什么时候不应该使用 Graph？
Graph Engineering 很容易变成另一种过度设计。
如果一个强 Agent 已经可以稳定完成任务，就没有必要为了"多 Agent"而额外创建研究员、架构师、评审员、主管和仲裁员。
下面这些情况通常不适合复杂 Graph：
- 任务路径高度开放，无法提前定义关键阶段。
- 不同角色之间没有清晰、稳定的职责边界。
- 多 Agent 讨论没有带来可测量的质量提升。
- 协调成本超过了并行或专业分工的收益。
- 任务本来可以由一个 Agent 加工具和验证闭环完成。
- 固定路由限制了 Agent 的探索和动态规划。
LangChain 在讨论 Graph Engineering 时也指出，部分深度研究系统后来从预定义的多 Agent Graph 转向更动态的 Agent Harness。原因是开放式研究很难预先写死完整路径。
因此，Graph 的价值必须通过结果证明，而不是通过节点数量证明。
如何判断一个 Agent Graph 是否值得存在？
可以用下面这份检查清单评估：
1. 职责是否真的不同？
- 每个节点是否承担独立、必要的职责？
- 删除某个 Agent 后，系统质量是否明显下降？
- 角色差异是否体现在上下文、工具、权限或评测标准上？
2. 交接协议是否清晰？
- 每条边传递什么数据？
- 输入输出是否有稳定结构？
- 驳回、重试、升级和退出条件是否明确？
3. 是否有共享状态？
- Agent 是否知道已完成和未完成事项？
- 分歧、证据和决策是否独立保存？
- 中断后是否可以恢复，而不是重新播放全部对话？
4. 是否可以观测和评测？
- 能否看到每个节点的输入、输出和耗时？
- 能否统计 Token、成本、成功率和重试次数？
- 能否判断多 Agent 比单 Agent 好在哪里？
5. 人类是否拥有最终控制权？
- 哪些动作需要人工确认？
- 人能否驳回结果并回到具体节点？
- 系统能否解释最终方案是怎样形成的？
最终的比较对象不应该是"没有 Agent 的传统流程"，而应该是一个设计良好的单 Agent Loop。
只有当 Graph 相比单 Agent Loop 明确改善了质量、成本、延迟、专业分工或失败恢复能力，它才值得存在。
Graph Engineering 到底是不是新范式？
我的结论是：
名字是新的，问题早就存在；底层技术并不新，但工程重心确实发生了变化。
当单个 Agent 还不能可靠执行任务时，我们主要讨论 Prompt、Context、工具和 Loop。
现在，Coding Agent 已经可以连续完成越来越复杂的工作。新的瓶颈自然从"怎样让一个 Agent 工作"，转向"怎样让多个 Agent 可靠协作"。
Graph Engineering 给这个变化起了一个容易传播的名字。它有明显的 Buzzword 成分，但它描述的工程问题是真实的。
它不会让 Loop Engineering 消失，因为一个 Loop 本身就是带环的图，Graph 中的一个 Agent 节点也可能运行自己的 Loop。
它也不会取代 Harness Engineering，因为记忆、权限、工具、评测、追踪和恢复，仍然需要 Harness 提供。
Graph Engineering 真正代表的，是 Agent 工程开始从"个人能力"走向"组织能力"。
回头看我做过的那个多 Agent 系统，它没有完全实现我想要的协作方式，但它让我看清了一个问题：
把两个模型放在一起并不难。真正困难的，是设计它们之间的关系。
这可能才是 Graph Engineering 最值得我们认真讨论的地方。