Graph Engineering 是真正的范式革新，还是 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 聊天室：
- 用户提出需求。
- 多个 Agent 分别分析并提出方案。
- Agent 阅读并审核彼此的结论。
- 针对分歧继续讨论。
- 达成一致后生成最终方案。
- 用户进行最终确认。
当时只给了 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 系统把“完整聊天记录”当作共享状态。这种方式很容易实现，但会迅速产生三个问题：
- 上下文越来越长，成本持续增加。
- 关键决策被淹没在大量对话中。
- 不同模型难以知道哪些内容已经确认、哪些仍有争议。
更合理的做法，是让边传递结构化产物，而不是无差别地转发全部对话。
例如，一次方案评审可以使用类似下面的协议：
{
"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
