写在前面

AI 工程这几年换词很快：Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering，现在又轮到 Graph Engineering。很多团队第一反应会是疲惫：是不是又一个包装出来的概念？

如果只看名字，确实容易误判。但 Graph Engineering 真正指向的问题很具体：当一个 Agent 的循环已经扛不住复杂企业任务时，多个 Agent、多个工具、多个审批点、多个失败分支，应该怎么组织成一个可并行、可审计、可回滚的系统。

换句话说，它不是让某个模型“更聪明”，而是让一群模型、工具和人能像团队一样协作。企业 AI 走到生产环境后，真正缺的往往不是单点智能，而是组织结构。

从 Prompt 到 Graph，AI 工程在补五层能力

过去几年 AI 工程的演进可以拆成五层，它们不是互相替代，而是叠在一起。

Prompt Engineering 解决的是单次指令质量。你怎么问，模型怎么答，这是最早被大众熟悉的能力。

Context Engineering 解决的是模型能看到什么。上下文窗口里放什么材料、放多少、按什么顺序放，直接决定回答是否稳定。Andrej Karpathy 在 2025 年把这件事说得很直白：AI 工程师的工作正在从写提示词转向整理上下文。

Harness Engineering 给模型装上外壳，包括工具调用、权限控制、错误处理、监控、防护栏。Anthropic 在 Building Effective Agents 里把这个问题讲得很清楚：Agent 不是裸模型，而是模型加一整套运行环境。

Loop Engineering 让单个 Agent 能持续推进任务。典型循环是推理、行动、观察、再推理。写代码 Agent 写完后跑测试，失败就改，再跑，这就是 Loop 在起作用。

Graph Engineering 则站在更上一层：多个 Loop、多个 Agent、多个确定性函数、多个人工审批点，谁先做，谁并行，谁审核，失败回到哪里，状态怎么传递。

一个简单类比：Prompt 是给员工写任务说明；Context 是给员工准备资料；Harness 是办公系统、权限和工具；Loop 是让员工做完自查返工；Graph 是公司的组织架构、协作流程和审批制度。

企业任务一复杂，最后拼的不是单个员工多努力，而是流程设计是否清楚。

单 Agent Loop 会撞上的四堵墙

单个 Agent 的 Loop 很适合目标明确、可反复迭代、失败可重来的任务。比如修一个测试、生成一个脚本、整理一份资料。它的问题会在任务变长后集中爆发。

第一堵墙是上下文溢出。一个 Agent 同时负责调研、规划、实现、安全、测试、复盘，上下文窗口迟早被塞满。模型不一定是“变笨”，而是早期信息被挤掉，推理质量自然下降。

第二堵墙是串行低效。很多子任务之间没有依赖，本来可以同时跑，却被单 Agent 排成队，一个做完再做下一个。多源检索、多模块编码、多维风险评估，这类任务尤其浪费时间。

第三堵墙是失败代价高。一个跑了 40 分钟的任务，第 35 分钟某一步失败，如果系统只能整体重来，时间和 token 都会被一起烧掉。

第四堵墙是职责边界模糊。模型到底做了哪个判断、哪个步骤引入了错误、哪一步应该人工确认，在一个巨大 Loop 里很难追溯。金融、医疗、制造、合规场景里，这不是体验问题，是上线门槛。

Graph Engineering 就是为这些问题准备的。它把复杂任务拆成节点，用边定义依赖和流转，用共享状态保存中间产物。失败可以只重跑某个分支，审核节点可以使用干净上下文，关键节点可以停下来等人审批。

图结构真正带来的不是炫技，而是治理能力

一张可用的 Agent 图，通常由三类元素组成。

节点负责执行具体工作，可以是研究 Agent、编码 Agent、审核 Agent、确定性函数、工具调用，也可以是人工审批点。

边负责控制流，决定顺序交接、条件分支、并行扇出、结果汇聚、失败回退、循环重试。

共享状态负责在节点之间流动，保存任务进度、中间产物、预算、验证结果、权限凭证和人工意见。

这套结构的价值不只是“更复杂”，而是让系统可控。

无依赖节点可以并行执行；失败节点可以局部重试；审核节点能独立验证前序输出；每一步输入输出都能被记录；高风险节点能显式插入 Human-in-the-Loop。企业真正需要的不是让 Agent 完全自动，而是让它在可控边界内自动。

这也是为什么 LangGraph 这类框架会增长很快。LangGraph 月下载量已经超过 6500 万，Uber、Klarna、LinkedIn 等企业都在生产环境里用图结构组织 Agent。Klarna 把客户问题解决时间减少了 80%，Uber 节省约 21000 个开发者工时，这些收益来自流程并行、职责拆分和局部容错，不是简单换了一个模型。

什么时候该上 Graph，什么时候 Loop 就够

Graph Engineering 不是所有 AI 项目的默认答案。过早上图，只会让系统多一层复杂度。

可以用四个信号判断是否值得上图：

1. 任务天然可以拆成多个并行子任务。
2. 需要独立验证，不能让同一个 Agent 既生产又审核。
3. 关键步骤必须有人类审批。
4. 失败代价高，不能接受整段重跑。

满足两个以上，就值得认真考虑图结构。比如软件研发流水线、客户服务分流、KYC/AML 审查、研究报告生成、IT 变更管理、企业知识问答，这些场景都天然适合图。

反过来，如果任务目标单一、流程很短、失败重试成本低，一个设计良好的 Loop 更直接。工程不是堆概念，能用小系统解决，就不要把小问题做成平台。

工具选型：先选生产稳定性，再选概念漂亮度

Graph Engineering 是方法论，LangGraph、AutoGen GraphFlow、Google ADK、CrewAI 是不同落地工具。

LangGraph 的核心抽象就是节点、边、共享状态，和图工程理念最贴近。它适合复杂状态管理、持久执行、断点续跑、流式输出和人工介入，目前企业案例也最多。

AutoGen GraphFlow 更适合已经深度使用微软技术栈的团队；Google ADK 更适合 Google Cloud 生态；CrewAI 上手比较快，适合角色分工明确的原型验证。

工具选型可以先问三个问题：

• 你要不要持久执行和断点恢复？
• 你有没有强制人工审批节点？
• 你是否需要记录每个节点的输入、输出、耗时、token、模型版本？

如果答案都是“要”，就不要只看 demo 是否漂亮。生产系统最重要的是状态、审计、可观测和成本控制。

这里还有一个现实问题：Multi-Agent 系统的 token 消耗可能显著高于普通 Chat，复杂工作流甚至会到十几倍量级。图结构反而提供了降本空间：分类、路由、格式转换用小模型或确定性代码；复杂推理节点再用强模型；高风险节点交给人。

企业落地别先画大图，先梳理业务流程

很多团队做 Agent 项目失败，不是框架没选对，而是业务流程没梳理清楚。Graph Engineering 的前提是你知道真实工作流怎么跑。

建议先画两张图。

第一张是 Org Graph，描述长期稳定的角色和权限：谁负责数据，谁负责安全，谁负责发布，哪个节点能访问哪些工具，预算怎么控。

第二张是 Work Graph，描述具体任务的执行路径：这个任务先做什么，哪些分支能并行，哪个节点负责审核，失败回到哪里，哪里必须人工确认。

稳定组织和动态任务不要混在一张图里。混在一起，系统一扩展就会乱。

实践上，从 3 到 5 个节点的小图开始最稳。比如一个代码变更流程可以先做成：需求理解、实现、测试、审查、人工合并。跑通后再拆出安全扫描、性能检查、文档更新、回滚方案。每个节点单一职责、可独立测试，整张图才有维护价值。

共享状态也要谨慎设计。不要把所有东西塞进一个大 JSON 传来传去。每个节点应该明确需要什么输入、产出什么结果、哪些内容继续传给下游、哪些内容只在本节点内部消费。

常见问题

Graph Engineering 和知识图谱是一回事吗？
不是。这里的 Graph 指 Agent 执行拓扑和控制流；知识图谱关注实体关系建模。两者可以结合，比如执行图中的检索节点调用 GraphRAG，但概念不能混用。

节点越多是不是越智能？
不是。节点越多，接口越多，状态越复杂，维护成本越高。能用 3 个节点解决的，就不要画 5 个。

Graph 会替代 Loop 吗？
不会。Graph 通常包含多个 Loop。Loop 解决单个节点的反复迭代，Graph 解决多个节点之间的分工、并行和治理。

开发团队最该先学框架还是先梳理流程？
先梳理流程。框架可以后补，业务流程如果说不清楚，图结构只会把混乱自动化。

什么时候需要人工介入节点？
涉及钱、权限、客户数据、合规结论、生产发布、不可逆操作时，都应该默认设置人工确认点。

Graph Engineering 最值得记住的一句话是：Loop 让 AI 学会把一件事反复做好，Graph 让 AI 学会和一群人协作。企业真正需要的，通常是后者。