有个小伙伴在后台留言：“什么是 Graph Engineering”。
我就知道 AI 工程界又火了一个词。
第一次看到 X 上 Graph Engineering 的争论时，我的第一反应是：这不是 LangGraph 之前玩的那套吗？节点、边、状态、分支、并行、工作流…这些东西一个都不新鲜，Agent 框架对它们的支持都迭代好几遍了。
Graph Engineering 当然并没有发明什么新的技术。真正变了的，可能是 Graph 今天组织的对象，以及所处的工程背景。
今天就来说说这个“新”的 Graph Engineering。
本文分为两篇。上篇先讲清楚 Graph Engineering 是什么、为什么是现在，以及什么时候真的需要它；下篇会讨论 Graph 怎么设计、怎么落地，以及它带来的新问题。
我们就先从 LangGraph 讲起。
01
LangGraph 早就有了，
为什么又来了个 Graph Engineering？
当时 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。只不过无法分支，无法回头，可以称之为链（Chain，LangGraph 正是 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 互相协作，只会越来越乱。
04
Prompt、Context、Harness、Loop、Graph
五个工程之间的关系
在理清 Loop Engineering 与 Graph Engineering 后，我们更进一步，看看这些熟悉的 Engineering：Prompt、Context、Harness、Loop，Graph之间到底是什么关系？
它们当然不是简单的五次技术迭代：Prompt 过时了，升级 Context；Context 不够了，升级 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。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
