有个小伙伴在后台留言“什么是 Graph Engineering”。我就知道 AI 工程界又火了一个词。第一次看到 X 上 Graph Engineering 的争论时我的第一反应是这不是 LangGraph 之前玩的那套吗节点、边、状态、分支、并行、工作流…这些东西一个都不新鲜Agent 框架对它们的支持都迭代好几遍了。Graph Engineering 当然并没有发明什么新的技术。真正变了的可能是 Graph 今天组织的对象以及所处的工程背景。今天就来说说这个“新”的 Graph Engineering。我们就先从 LangGraph 讲起。01 LangGraph 早就有了为什么又来了个 Graph Engineering先把时间拨回到 2024 年初LangChain 发布了 LangGraph小编的第一篇 LangGraph 文章就写于 2024 年 3 月。当时 Agent 已经出现但远没有今天这么能干。典型的 Agent 就是一个 ReAct 范式的 Agent Loop思考 → 调工具 → 看结果 → 再思考 → ...周而复始这个范式把大量决定都交给了当时还不够强大的 LLM 。单一的 ReAct Agent 无法满足复杂任务的需要工具调错了怎么办任务跑了几步开始偏怎么办中途需要人工确认怎么办我想强制“必须先查数据库再做判断”又怎么办早期的 LangChain 即使这样一个改进 RAG 流也无法支持这些问题在很多企业场景都是存在的。所以这阶段 LangGraph 的核心诉求之一是编排复杂任务的工作流用显式的流程和状态把不确定性约束在可控范围内且不牺牲局部的 AI 自主性。这给 Agent 的自由加上一些“轨道”。其背后的方法是用 State 保存任务状态信息用 Node 拆分步骤用 Edge 决定下一步可以循环、分支、并行可以用代码/人而不是 LLM 决定下一步往哪里走。有意思的是现在的 Graph 又火了。但这一次背景并不太一样。今天的 Agent 已经可以在适当的环境与约束下Harness独立工作很长时间自己拆任务、找资料、改代码、跑验证...甚至自我循环直到目标达成Loop Engineering。我们面对的核心问题开始从“怎么管住一个不太靠谱的 Agent”变成“怎么组织一群越来越能干的 Agent 们”以前Graph 更多是在 Agent 内部建立秩序现在Graph Engineering 则更关注的是如何在 Agent 之间建立秩序 — 谁负责什么、哪些任务并行、状态怎样共享、各自工作的上下文、谁来验收、失败后谁接管以及哪些决定必须留给确定的代码或人。所以所谓的 Graph Engineering 没有出现新技术Graph、状态机、工作流都早就存在。但 Graph 连接的东西有变化过去连接的更多是 Step比如一次工具调用现在更多连接的是能够自主完成一段工作的 Agent。这里说的只是相对的重心变化而非技术能力的绝对分界。比如LangGraph 很早就可以编排多 Agent今天的 Graph Engineering 也绝不只连接 Agent节点可以是 Agent、工具、函数甚至人。02 Graph Engineering 到底是什么从计算机科学的基本定义看Graph 没什么神秘的一组节点Node加上一组连接节点的边Edge。具体到某个任务的处理过程如果这个任务只需要一路向前这也是一种简单的Graph。只不过无法分支无法回头可以称之为链ChainLangGraph 正是 LangChain 公司推出。假设现在这个任务变复杂了开始出现分支和并行这通常可以表示成 DAG有向无环图一些开发框架早期只支持 DAG 的工作流编排有方向但还是不能“回头”。在如今更复杂的 Agent 系统中比如 Claude Code 这样的 Coding Agent 系统往往还需要另一种循环能力这很好理解失败了我可以返工、结果不如人意再优化、直到满足条件 — 一旦允许流程“回头”就不再是 DAG而是更通用的有向 Graph。这也是为什么 Graph 适合用来“组织” Agent 们的工作今天的问题已经不只是怎么管住一个 Agent而是怎么组织一群越来越能干的 Agent 来干更复杂的活。而 Graph Engineering 就是把这些 Agent 以及它们之间的协作关系用一张真正可以运行的图来表示并运行起来。尽管 Graph Engineering 通常用来构建 Multi-Agent 系统但不代表节点都是 Agent也可以是某个代码逻辑、外部服务或者人类审核。一张 Agent Graph有最基本的三个东西相比之前没有变化Node节点。专业 Agent 或步骤可以有自己的 LLM、工具和任务。Edge连接节点代表接下来去哪。可以是条件分支、并行分支、循环。State节点之间的共享状态 — 一个节点处理的信息可供下个节点使用。看一个编写研究报告的 Agent Graph 例子Researcher Agent 负责找资料Writer Agent 负责写稿Reviewer Agent负责审查。如果通过就发布如果不通过就带着反馈回到 Writer 继续修改。看起来只是几个方框和箭头。但重要的是在这个 Graph 中谁负责什么、什么情况下往哪里走、状态传递了什么、什么时候结束都不再由某个 Agent 自己决定而是成为 Agent 系统的一部分。这也是 Graph Engineering 要工程化的部分。03 Graph 里明明有 Loop为什么它不是 Loop Engineering上节的例子里Reviewer 这个节点不通过流程会重新回到 Writer。这明明就是一个 Loop循环那它和之前讲的Loop Engineering有什么区别两者的关键不在于“有没有 Loop ”而在于两者关注与解决的问题不一样。比如这是一个典型的 Loop Engineering在这个过程中Agent 自己根据测试验证的结果不断行动直到测试通过、达到目标或者触发停止条件如最大迭代次数。它关心的是如何让这个 Coding Agent 不需要人类介入就能自己验证结果修复代码持续推进直到完成目标。但 Graph Engineering 的关注视角需要更上一层。比如在上面的研究报告例子中Graph 关心的是Researcher 做完以后交给谁Writer 写完谁来审核审核失败回到哪里返工哪些任务可以并行如何让 writer 知道 Reviewer 的审查结果什么时候必须让人介入你看同样都有 Loop但两者关注的层次不同Loop Engineering 关注的是一个Agent 如何持续推进工作Loop 是必须的机制。Graph Engineering 关注的是多个 Agent 如何协同运行而 Loop 只是其中一种模式。你甚至可以把两者“套”在一起。比如一个全栈开发任务在这个例子中Graph 负责高层的组织关系Loop 负责 Coding Agent 节点内部的行动 — 两者完全可以共存。所以也能理解为什么 Agent 强大之后Graph 的价值才开始炒作涌现当 Agent 的自主能力越来越强 它们之间的秩序设计才更有意义。毕竟去组织一些尚“无法自理”的 Agent 互相协作只会越来越乱。04Prompt、Context、Harness、Loop、Graph 五个工程之间的关系在理清 Loop Engineering 与 Graph Engineering 后我们更进一步看看这些熟悉的 EngineeringPrompt、Context、Harness、LoopGraph之间到底是什么关系它们当然不是简单的五次技术迭代Prompt 过时了升级 ContextContext 不够了升级 Harness...最后一路升级到 Graph。它们更适合理解成Agent 工程不断向外扩大的五个控制圈。Prompt Engineering关注一次模型调用这一轮对话中怎么把任务和要求说清楚Context Engineering再往外一步这一轮模型做决定时应该看到什么历史对话、领域知识、工具定义、Memory 等哪里获取哪些应该被压缩等等。Harness Engineering关注 Agent 如何运行、行动和约束理论上Agent 除了模型外的部分都属于 Harness行动范式、怎么用工具、怎么用 Skill、权限怎么控制、用不用沙箱等等。Loop Engineering 更进一步一个 Agent 怎样持续自主的推进直至达到任务目标。Graph Engineering又把镜头拉远了一层多个 Agent、程序、工具和人应该怎样协同运行。把它们简单总结成大白话就是Prompt Engineering 管如何对模型说话ContextEngineering管让模型看到什么HarnessEngineering管 Agent 如何做事LoopEngineering管 Agent 怎样持续推进做事GraphEngineering管一群 Agent 怎样一起做事如果把一个 Agent 比作一个越来越能干的员工Prompt 是要会和他沟通Context 是给他资料Harness 是给他电脑、工具、权限、办公室Loop 是让他自己把事情持续做完。而 Graph 是当公司里有多个能干的员工时怎么让他们真正成为一个组织。所以这些 Engineering 不是替代关系也不是严格的上下级关系一个 Graph 节点内部完全可以运行自己的 Loop一个 Graph 里的每个 Agent仍然需要好的 Harness好的 Harness 自然也少不了好的 Context 与 Prompt 设计Agent 系统越复杂前面这些能力越需要同时存在。05什么时候我真的需要 Graph Engineering理解了 Graph并不意味着所有 Agent 工程都应该被画成一张 Graph。想象下你的实际任务很多都是目标清晰的单一任务有明确的验收标准修复一个程序 Bug、处理邮件收件箱、撰写一个分析报告它们大部分都不需要 Graph一个好的 Agent 或者 Loop 已经足够。什么时候 Graph 真正开始有价值不能简单的用“任务复杂”来概括而是从一些关键的信号开始事实上这些信号与多 Agent 系统、Workflow 的适用场景很一致。一个 Agent 已经不适合对整个任务负责当任务内不同步骤的专业方向与职责有较大差异时 这时候把所有事情塞给一个超级 Agent反而会更难控制输出质量下降。比如一个决策型研究任务搜集分析、撰稿、审稿本来就是不同的角色它们需要看到的上下文、承担的责任也不同。如果让一个 Agent 不断切换身份和思考模式不同角色的 Prompt、Context、目标等就会混在一起。更自然的方式是把它们拆成 Graph 中的多个 Agent 节点并通过状态传递完成协作。任务中开始出现真正的并行与依赖比如需要同时抓取分析10个竞品网站的数据简单的 Loop 只能串行等待而 Graph 可以直接分发给 10 个节点 Agent 并行处理最后再聚合结果。再比如在 Claude Code 中通过动态工作流开展并行的代码开发或重构。Loop Engineering 擅长表达下一步做什么而 Graph 则擅长表达哪些步骤可以同时进行哪些步骤又需要等待结果在哪里汇合等这些复杂拓扑。不同步骤需要不同的模型、工具和权限在任务的不同阶段并非总是需要相同的执行能力。比如简单分类你可能使用免费的模型但复杂推理就用强大的模型搜索时需要互联网工具但提交时则需要用严格权限控制的生产访问工具。如果所有步骤都交给同一个 Agent一方面会造成资源浪费另一方面也会增加安全风险。Graph 则可以允许你在不同节点拥有不同的配置模型、工具、技能、权限、人工审核等。需要高确定性、可审计的控制流正如开头所说Graph 最初的一大意义是用更确定的工作流来约束模型的自我发挥。这个优势依然存在在很多高确定性要求的领域你需要的不仅是一个任务结果还需要过程的可控 — 哪些是 Agent 控制、哪些需要用确定的代码和人来控制。这种可控性有助于在金融、医疗、通讯等领域了解 Agent 执行过程中遵循了什么规则、经历了哪些审批、调用了什么工具、失败后什么走向等。这时候显式的 Graph 要比几百万 token 的 LLM 聊天轨迹更容易审计。某种意义上AI Coding 领域的 Vibe Coding 与 SDD规范驱动开发的定位与此类似牺牲一定的灵活性与自主性换取可控性与确定性。任务的执行与验证必须独立在一些场景中执行者本身并不适合作为验证者。有两种可能的需求希望用独立的验证节点让验证结果更加“公正”而不是让运动员当裁判。比如用其他模型驱动的 Agent 来审核当前 Agent 的输出质量。防范验证器“过载”。即单个验证器承担了过多的职责比如“代码是否正确、安全是否达标、风格是否规范”这会导致遗漏。此时可以用多个验证节点来让职责更加专注。独立的验证节点应该拥有不同的上下文、工具、只读权限和审查依据。任务中途涉及暂停和恢复需要持久化很多企业 Agent 在中途需要等待人工批准、回调发生、补充输入等。只靠一个在线 Agent 会话维持状态有时候就会变得脆弱比如超时。Graph 由于有着清晰的步骤和状态借助于持久机制落磁盘或者数据库可以保存状态快照并用于 HITL、故障恢复、记忆等实现“断点续跑”。总的来说当你的任务呈现出职责分化、分支并行、权限隔离、独立验证、长流程恢复等信号时可以考虑 Graph Engineering而目标单一、可以被验证器闭环、没并行必要的任务大多并不需要 Graph。