Graph Engineering 是新范式，还是 AI 圈的又一个新词？

Graph Engineering 是新范式，还是 AI 圈的又一个新词？

AI圈最近又冒出来一个新概念——Graph Engineering。

起因是OpenClaw的创作者Peter Steinberger在X上提了一嘴，说“Loop Engineering已经过时，Graph Engineering正在接棒”。这一下子，讨论就炸开了锅。

从Prompt Engineering、Context Engineering，到Loop Engineering、Harness Engineering，现在又来了Graph Engineering。这玩意儿到底代表了一次真实的工程范式转变，还是说，AI圈又给一个老问题换了个新名字？

结论很明确：

这个判断不是凭空来的，背后有一个真实的多Agent项目可以佐证。

一个看起来成功、实际没有形成协作的多Agent系统

之前有个想法，想把自己处理复杂方案的工作方式做成一个Web系统。

日常工作中，面对复杂需求，常见的做法是让两个不同模型分别思考，再让它们交叉评审。一个模型提方案，另一个模型检查架构、风险和遗漏；然后把评审意见送回原模型继续修订。中间产物和最终结论，都保存在同一个文件夹的Markdown文档里。

目标是把这套人工工作流变成一个多Agent聊天室：

1. 用户提出需求。
2. 多个Agent分别分析并提出方案。
3. Agent阅读和审核彼此的结论。
4. 针对分歧继续讨论。
5. 达成一致后生成最终方案。
6. 用户进行最后确认。

当时只给了Codex一句话需求，靠着长时间执行能力，它连续跑了十几个小时，最终做出了一个能启动、也能用的Web页面。

如果验收标准只是“页面能打开、两个模型能回复”，那项目已经算完成了。

但真正用起来，问题就暴露了——两个模型的工作过程几乎完全割裂：

• 它们没有稳定的共享任务状态。
• 一个模型看不到另一个模型完整的推理背景与证据。
• 所谓的评审，更像是把一段输出转发给另一个模型。
• 系统没有明确记录已解决和未解决的分歧。
• 没有可靠的长期记忆、上下文恢复和进度状态。
• 缓存命中与重复上下文成本也没有得到有效控制。
• 最终仍然需要人来决定谁先说、转交什么、相信谁，以及怎样合并结论。

页面看起来像一个多Agent聊天室，底层却只是两个独立会话。

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可以表示为：

flowchart LRA[理解目标] --> B[规划]B --> C[执行]C --> D[验证]D -->|未完成| BD -->|已完成| E[输出结果]

它要解决的问题是：

• Agent如何知道下一步做什么？
• 工具执行失败后是否重试？
• 测试不通过时怎样修正？
• 什么条件下可以停止？

但多Agent系统增加了另一组问题：

• 谁负责提出方案，谁负责审核？
• Agent是否应该独立思考，还是共享全部上下文？
• 发生分歧时，任务流向哪个节点？
• 谁能驳回结果？
• 什么叫“已经达成共识”？
• 哪些决策必须由人确认？
• 某个节点失败后，是局部恢复还是全局重跑？

这些不是单个Agent内部的执行问题，而是多个执行单元之间的协作协议问题。

真正的Graph不只是把多个头像放进聊天室

如果重新设计前面的多Agent方案评审系统，它至少需要下面这张执行图：

flowchart TDU[用户提出需求] --> S[结构化需求、约束与验收标准]S --> A[Agent A 独立提出方案]S --> B[Agent B 独立提出方案]A --> RA[Agent B 审核方案 A]B --> RB[Agent A 审核方案 B]RA --> D[分歧提取与合并]RB --> DD --> C{是否达到共识条件}C -->|否| R[生成待解决争议与修订任务]R --> AR --> BC -->|是| F[生成共识方案]F --> H{人工确认}H -->|驳回| RH -->|通过| O[输出最终方案与决策记录]

这张图真正有价值的部分不是节点数量，而是边所承载的协议。

比如“交叉评审”这条边，不能只是把一大段自然语言转发过去。它应该明确规定：

• 评审者必须看到哪些上下文？
• 输入方案采用什么结构？
• 输出必须包含哪些字段？
• 需要区分事实错误、架构风险、实现成本还是产品取舍吗？
• 被评审方是否必须逐项回应？
• 哪些意见构成阻断问题？
• 最多允许多少轮修订？

边上需要传递什么？

很多多Agent系统把“完整聊天记录”当作共享状态。这种方式很容易实现，但会迅速产生三个问题：

1. 上下文越来越长，成本持续增加。
2. 关键决策被淹没在大量对话中。
3. 不同模型难以知道哪些内容已经确认、哪些仍有争议。

更合理的做法，是让边传递结构化产物，而不是无差别转发全部对话。

例如，一次方案评审可以使用类似下面的协议：

{
  "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 Engineering到底是不是新范式？

结论是：

当单个Agent还不能可靠执行任务时，我们主要讨论Prompt、Context、工具和Loop。

现在，Coding Agent已经可以连续完成越来越复杂的工作。新的瓶颈自然从“怎样让一个Agent工作”，转向“怎样让多个Agent可靠协作”。

Graph Engineering给这个变化起了一个容易传播的名字。它有明显的Buzzword成分，但它描述的工程问题是真实的。

它不会让Loop Engineering消失，因为一个Loop本身就是带环的图，Graph中的一个Agent节点也可能运行自己的Loop。

它也不会取代Harness Engineering，因为记忆、权限、工具、评测、追踪和恢复，仍然需要Harness提供。

回头再看那个多Agent系统，它没有完全实现想要的协作方式，但它让人看清了一个问题：

这可能才是Graph Engineering最值得我们认真讨论的地方。

参考资料

• LangChain：3 Years of Graph Engineering with LangGraph
• LangChain：Building LangGraph: Designing an Agent Runtime from First Principles