《Claude Code 工程化实践》加课6-Graph Engineering：Claude Code 工程化之路上的一个驿站，远非终点
2026年7月，AI工程圈又沸腾了。
六周前，OpenClaw（小龙虾）创始人 Peter Steinberger 一句"Are we still talking loops？"让 Loop Engineering 收割了800万浏览。六周后的今天，他换了个词：“Are we still talking loops or did we shift to graphs yet？”——三天270万浏览。
从 Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering → Graph Engineering，不到两年时间，AI圈已经造出了五个"X Engineering"。每一次都以"XX已死，拥抱XX"的姿态登场，每一次都在公众号和短视频里掀起一轮新的内容狂欢。
但如果我们剥开流量营销的糖衣，冷静审视这条演进脉络，会发现一个更有意思的故事——这不仅是概念的更替，更是Claude Code工程化进程中，控制权从"执行端"不断向"判断端"上移的真实写照。
一、五个Engineering到底在讲什么？
让我们先把这五个名词拉平来看：
| 概念 | 管控粒度 | 人的角色 |
|---|---|---|
| Prompt Engineering | 管一次对话 | 你写每条指令 |
| Context Engineering | 管一个会话的环境 | 你搭上下文 |
| Harness Engineering | 管Agent运行的基础设施 | 你给Agent装缰绳 |
| Loop Engineering | 管整件事如何无人值守跑完 | 让Agent自己完成一个完整任务 |
| Graph Engineering | 管多条循环如何协作制衡 | 设计多个Loop组成的网络 |
本质上，人在离具体执行越来越远，离"定义什么是好"越来越近。
这五个词的演变，是同一个趋势在不同抽象层级上的投影。Prompt让Claude写好一个函数，Loop让Claude自己迭代完一个项目，Graph让多个Claude舰队协同完成一个大型工程。 每一层抽象都比上一层更高，控制点在从"执行端"不断往"判断端"上移。
Claude Code 的创造者 Boris Cherny 有句话精辟地概括了这种跃迁：
“我现在已经不再提示Claude了，我运行的是一些循环，由这些循环去提示Claude。”
套用这个句式，Graph Engineering 的宣言可以是：
“我现在已经不再跑单个循环了，我设计的是多个循环组成的图，由这张图去编排所有的循环。”
二、Graph Engineering 不只是"workflow那套老东西"
很多人看到 Graph Engineering 的第一反应是：这不就是workflow/DAG那套东西吗？Airflow十年前就在干了。
没错，从结构上看，Graph Engineering 的节点+边+依赖+并行+条件路由，确实是标准workflow的定义。绕了一圈，从workflow里挣脱出来（让Agent自主跑），又绕回去把自主Agent重新塞进了DAG。
但如果你只看到这一点，就错过了真正的创新。
真正的不同在哪里？
第一，节点的非确定性。 传统workflow的节点是确定性函数——同样输入永远同样输出。LLM节点是概率性的——同样输入可能不同输出。传统workflow的失败是"异常"，需要retry；LLM节点的"失败"是常态（质量不达标），需要的是loop+judge，而不是简单重试。
第二，路由的动态性。 传统workflow的条件路由是写死的规则（if x then branch B）。Graph里的conditional edge是LLM现场读上下文决定的。图的结构在运行时是半动态的，不是完全静态的。
第三，节点的语义粒度。 传统workflow的节点是"调用一个API"、“跑一个查询”。Agent节点是"完成一个子目标"，粒度粗、语义开放，内部可能展开成子图。
第四，治理需求的本质不同。 正因为节点非确定，才需要对抗式验证、多视角验证、裁判组等治理机制。这些在传统workflow里不是核心需求，因为确定性节点不会"指标自欺"。
Graph Engineering 不是在workflow的旧瓶里装新酒，而是把workflow的结构搬到了LLM时代的新场景里，解决的是LLM节点带来的新问题。
三、从Loop到Graph：Agent的一次组织架构升级
如果用一个比喻来理解Loop Engineering和Graph Engineering的关系，最贴切的是公司组织架构的演变。
-
Loop Engineering 就像一个全能手工作坊：一个老师傅从头做到尾，一个人当好几个角色。优点是沟通成本低，缺点是规模上不去，随着任务变复杂，师傅的脑子越来越乱（上下文溢出），效率反而下降。
-
Graph Engineering 则像一家现代化公司：把不同职能拆成独立部门（节点），每个部门有明确的输入输出（契约），部门之间有清晰的协作流程（边），全员共享一块信息白板（状态）。CEO（编排层）不再参与每个部门的日常工作，而是定义谁做什么、信息怎么流、如何保证质量。
可以用一个形象的类比来理解。想象你在搬家，需要拆书架、装箱、搬上车、叫货车、办物业放行条。你肯定不会让全家人排成一列：一个人拆书架 → 拆完了传给下一个人装箱 → 装完了传给再下一个人搬上车。你会让三个人各干各的，同时派一个人去楼下叫车，再派一个人去物业办手续。几个人同时干活、各自有明确任务、干完了往同一个地方汇总——这就是一张图。
| Loop Engineering | Graph Engineering | |
|---|---|---|
| 核心问题 | 如何让单个Agent持续工作 | 如何把多个Agent组织成系统 |
| 架构形态 | 单条循环 | 多节点有向图 |
| 扩展性 | 受限于单Agent上下文 | 可水平扩展 |
| 容错性 | 失败级联 | 故障隔离 |
| 人的角色 | 设计循环条件 | 设计图拓扑和治理规则 |
Loop Engineering解决的是"如何让单个Agent持续工作"的问题，而Graph Engineering解决的是"如何把多个Agent（以及工具、人类）组织成一个可观测、可恢复、可扩展的系统"的问题。
这是Agent从"单兵作战"到"集团军作战"的组织架构升级。
四、Graph Engineering 在 Claude Code 中的实践
在 Claude Code 中，Graph Engineering体现为一套完整的动态工作流体系，由JavaScript编排脚本调度子Agent舰队，零额外Token开销实现并行执行。
最核心的实操要点
1. 节点与边的基础定义
节点是有明确边界的任务单元，边是真实的数据依赖。一个常见的错误是把"然后"当成边——“总结这个文件，然后告诉我天气”，两者之间没有数据流动，就不是边。边只有在数据真正流过时才存在。对每个"然后"问一句：下一步是否读了上一步的输出？如果没有，就没有边，等待是浪费。
2. 钻石拓扑：扇出→reduce→综合
这是每个严肃Agent图的主力拓扑。一个节点拆分任务（扇出），多个节点并行干活，一个节点合并结果（扇入）。扇出取广度，用纯代码reduce压缩，用最终Agent综合写答案。看到钻石后，你不再问"怎么让Agent多做几步"，而是问"在哪拆、在哪合"——这才是真正能scale的问题。
3. 给每个节点一个契约
用JSON Schema强制约束节点的输入输出格式，让下游Agent无需猜测就能直接消费结构化结果。在workflow里，给 agent() 一个JSON schema，spawn出的subagent被迫返回校验过的结构化数据——mismatch时Claude自动重试，而不是甩给你一段需要"解析并祈祷"的自由文本。
4. 验证节点与对抗校验
设置独立的验证节点，让多个Agent从不同角度尝试推翻当前结论。一个发现 spawn N 个独立怀疑者去反驳，多数存活才保留。这才是Graph Engineering真正的杠杆——不是更多的Agent，而是Agent周围包裹的用于产生信心的结构。
5. 故障隔离与错误包容
链式结构里失败会级联——C死、D不跑、整体停摆。图结构里，parallel() 抛错的节点解析为 null，好的Agent照常返回，坏的那个掉队。.filter(Boolean) 就是隔离。失败被限制在它自己的节点内。
6. 拓扑即成本与延迟
图的形状不是装饰——它是wall-clock时间最大的杠杆。默认用 pipeline() 避免barrier延迟，仅在某阶段真的需要全部前序结果时才用barrier。更微妙的是模型分级调度：不同复杂度的节点匹配不同能力等级的模型，简单任务用轻量模型降本，复杂验证任务用高性能模型保障效果。
7. 让Claude自己画图——自路由
对没法预先规划的任务，别再手画图。在Claude Code中，用动态工作流（dynamic workflows）描述目标，Claude自己写编排脚本——分解任务、选扇出、spawn协调舰队、综合结果。你得到为这次run量身定制的图，而非你祈祷能用的固定图。
五、预言：X Engineering 的下一站是什么？
回顾这两年AI工程化的演进，我们看到一个清晰的节奏：
| 时间 | 概念 | 核心关注 |
|---|---|---|
| 2023-2024 | Prompt Engineering | 所有人都在学习如何写好一个prompt |
| 2024-2025 | Context Engineering | 关注上下文管理和RAG |
| 2025-2026初 | Harness Engineering | 搭建Agent运行的基础设施 |
| 2026年6月 | Loop Engineering | 让Agent自主完成全流程 |
| 2026年7月 | Graph Engineering | 让多个Agent舰队协同作战 |
平均每个"X Engineering"的统治周期正在缩短——从两年压缩到一个月。这既是流量驱动的结果，也折射出一个更深层的现实：我们正在以极快的速度逼近AI工程化的终极形态。
基于这个趋势，不妨做几个大胆的预测：
预测一：Ecosystem Engineering（生态工程）
当Graph Engineering成熟后，Agent之间将形成标准化的通信协议和协作契约。下一阶段将不是设计一张图，而是设计和治理Agent之间自发生成的"图之图"——一个Agent生态系统。届时，焦点将从"如何画图"转向"如何培育、治理和演化一个Agent生态"。
预测二：Goal Engineering（目标工程）
如果Graph Engineering是让Agent知道自己"怎么走"，那么终极形态一定是让Agent自己知道自己"往哪走"。Goal Engineering让用户只描述终极目标，Agent自主分解、动态规划、不断调整路线，全程无需人类定义流程。 到了这一步，人甚至连"图"都不用画了。用户说"我要一个能自动完成代码审查的Agent系统"，Goal Engineer就自动分解出"理解代码结构→运行测试→检查安全漏洞→生成审查报告"的图结构，并交给Graph Engine去执行。
预测三：Trust Engineering（信任工程）
随着Agent系统从单循环走向多图、从辅助工具走向自主决策，信任将成为核心瓶颈。Trust Engineering将专注于Agent行为的可解释性、审计可追溯性、决策一致性，以及人类对Agent系统的信任建立机制。这不是一个附加功能，而是Agent系统能否大规模落地的先决条件。
六、新瓶装老酒还是范式跃迁？
当然，我们也需要保持冷静。
老刘说NLP在他的文章中说得很犀利：“底层还是’agent编排+状态管理+流程治理’那套老活儿。6月喊Loop、7月喊Graph，中间隔一个月，这不是范式跃迁，是流量制造。”
诚然，"X已死"的话术几乎总是错的：Loop没杀死Prompt，Graph没杀死Loop。它们是嵌套叠加，不是替代。这种术语通胀的叙事只会稀释含义，让人追名字而不是解决问题。
但另一方面，如果我们把视线从营销节奏上移开，聚焦技术本身，会发现 每一层抽象都在解决真实的问题，都在让人离"定义什么是好"更近一步，都在让AI系统的能力边界向外扩展一圈。
正如一位观察者所言，“整个技术的发展都是螺旋上升的，兜兜转转，互相缠绕”。
Graph Engineering不是终点，它只是Claude Code工程化之路上的一个驿站。
写在最后
作为一名跟进Claude Code工程化进程的观察者和实践者，我最大的感受是：
我们正在目睹一场从"手工作坊"到"工业体系"的巨变。
写Prompt → 管上下文 → 搭Harness → 设计Loop → 编排Graph → 未来的Ecosystem/Constitution/Goal/Trust Engineering……
这个链条的每一次推进，都意味着人类离"亲手执行"越来越远，离"定义方向和标准"越来越近。这不是术语通胀的造词游戏，而是AI能力演进的自然结果。
重要的是，不要追名字，要解决问题。
下一个"X Engineering"还会来。当它来的时候，不要问"XX是不是已死"，而要问"这个新概念帮我解决了什么之前解决不了的问题"。
因为，所有的X Engineering，最终都是Human Engineering——它们共同反映的是人类在AI时代如何重新定义自己的角色：从执行者，变为定义者。
而未来的工程范式，也必将层出不穷。Graph Engineering不会是终点，它只是通往更宏大AI工程图景的一块基石。 十年后回看今天，我们或许会感慨：原来2026年，我们才刚刚开始学会让AI Agent协同工作。
参考来源：
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
2
0- 0
已为社区贡献21条内容
所有评论(0)