Graph Engineering 全面解析

过去两年，Agent 的单步能力明显变强了。

它可以读代码、查资料、调用工具、修改文件，也能在失败后重试。可当任务从十分钟延长到十小时，从一次模型调用变成几十个步骤，新的问题出现了：

• 规划已经完成，执行到一半却忘了最初的验收标准；
• 三个 Agent 并行修改代码，结果写入同一份状态时互相覆盖；
• 测试失败后整个流程从头再跑，已经正确的步骤也被重复执行；
• 人工审批等待了一晚，第二天无法从断点继续；
• 模型把“测试不通过”错误地路由到部署节点；
• 工具调用成功但进程超时，重试以后重复创建了两条生产记录；
• 最终结果失败，却无法判断是哪个节点、哪条路径或哪个状态出了问题。

这些问题不再属于 Prompt Engineering。

模型知道“下一步大概做什么”，不代表系统知道：

当前走到了哪里？哪些步骤可以并行？谁可以修改哪些状态？失败后应该重试、回退还是补偿？什么时候必须停下来找人？流程升级以后，旧任务怎样继续？

Graph Engineering 讨论的就是这一层：如何把复杂任务设计成可执行、可暂停、可恢复、可观察和可评测的状态图。

💡核心判断：模型越强，单个节点可以承担的任务越复杂；但整个系统的自由度也随之增大。Graph Engineering 不是限制模型能力，而是把模型能力放在清晰的状态、路径和责任边界中。

一、Graph Engineering 是新名字，问题并不新

1.1 它不是知识图谱

这里的 Graph 指工作流图或控制流图：

• Node：完成一次明确工作的节点；
• Edge：决定状态接下来流向哪里；
• State：在整个任务中持续保存的结构化状态；
• Checkpoint：可以恢复执行的状态快照；
• Subgraph：拥有独立职责和状态边界的子流程。

它与知识图谱、GraphRAG 的区别是：

三者可以组合使用，但不能混为一谈。一个故障处理 Graph 可以在某个节点中查询知识图谱；这不代表两个 Graph 是同一种东西。

1.2 它也不是 LangGraph 的别名

Graph Engineering 是设计方法，LangGraph 是实现这种方法的一种运行框架。

LangChain 对 Graph Engineering 的回顾提到，一个值得注意的变化是：早期 Graph 中的节点通常是一段确定性代码或一次 LLM 调用；现在，一个节点本身可以运行完整 Agent。工程重点因此从“编排模型调用”转向“编排多个拥有工具和循环的 Agent”。

LangGraph 提供状态、持久化、流式输出、人工介入和长任务执行等能力，但 Graph Engineering 并不强制使用它。只要系统明确设计了节点、状态、路径、恢复和验证，就可以使用其他框架，甚至自己实现调度器。

1.3 为什么现在突然受到关注

模型能力较弱时，团队更关心一个节点能否把事情做对。模型能力变强以后，一条复杂流程可能包含：

• 一个规划 Agent；
• 多个并行执行 Agent；
• 数据库和外部 API；
• 一组确定性验证脚本；
• 一次人工审批；
• 一个发布与回滚流程。

此时真正困难的，不再只是“模型会不会写代码”，而是“几十个执行单元如何保持一致”。

二、从 Prompt 到 Graph，工程对象发生了什么变化

这几种 Engineering 不是互相替代，而是在管理不同对象。

可以用一句话区分 Loop 与 Graph：

Loop 管节点内部的反馈，Graph 管节点之间的拓扑。

一个“代码实现”节点内部可以运行完整 Coding Loop：读取任务、修改代码、运行测试、观察错误、再次修改。Graph 则决定它什么时候启动、和谁并行、完成后进入哪里、失败后由谁接手。

2.1 模型能力增强后，Graph 也在变化

Graph 的演进可以粗略分为四个阶段：

固定工作流：普通代码节点按固定顺序执行LLM增强工作流：部分节点使用模型理解或生成内容Agent工作流：节点内部运行带工具的 Agent LoopGraph of Agents：多个拥有不同上下文、权限和目标的 Agent 通过状态图协作

模型越强，确定性流程并不会消失。恰恰相反，团队更需要决定：

• 哪些判断可以交给模型；
• 哪些规则必须写死；
• 哪些高风险步骤需要人工确认；
• 哪些产出必须由独立系统验证。

三、Graph Engineering 真正需要设计的六个对象

只画出几个方框和箭头，并不等于完成 Graph Engineering。生产系统至少需要设计六个对象。

3.1 State：先定义状态，再定义节点

很多团队先画流程图，最后才考虑数据如何流动。结果是每个节点都输出一段自然语言，下游节点只能重新理解，任务越长，语义漂移越严重。

更好的顺序是先定义状态：

dev_state: task: change_id: AI-CHANGE-20260726-018 goal: 更新支付成功率口径及相关代码 acceptance_criteria: - 新旧口径可以按时间正确查询 - 历史流量回放无高风险回归 - 文档、代码和监控配置保持一致 knowledge: wiki_revision: payment-metric@7 affected_entities: [] evidence_refs: [] plan: tasks: [] frozen_contracts: [] approved: false branches: backend: status: pending artifact_ref: null monitoring: status: pending artifact_ref: null tests: status: pending artifact_ref: null verification: unit_tests: null integration_tests: null replay_result: null risk_findings: [] execution: current_node: planning retry_budget: 3 token_used: 0 started_at: 2026-07-26T09:00:00+08:00

好的 State 有三个特点：

结构明确：关键字段是可校验的数据，不是无法计算的一大段聊天记录。

责任明确：每个节点只能修改自己负责的字段。

证据外置：大文件、Trace 和完整日志只保存引用，不反复塞入共享状态。

3.2 Node：节点是一项可验收工作

一个节点可以是：

• 确定性函数；
• 一次数据库查询；
• 一个完整 Agent；
• 一组测试脚本；
• 人工审批；
• 外部系统回调。

节点的边界不应该按“模型能一次做多少”来划分，而应该按“能否独立验收和恢复”来划分。

node_contract: name: analyze_impact reads: - task.goal - knowledge.wiki_revision writes: - knowledge.affected_entities - knowledge.evidence_refs side_effects: none timeout: 10m retry: max_attempts: 2 retry_on: - transient_tool_error success: - affected_entities不为空 - 每个影响结论存在证据引用

如果一个节点同时负责需求分析、写代码、测试、发布和总结，它实际上只是被重新命名的大 Loop，仍然难以定位和恢复。

3.3 Edge：路由不仅是“下一步做什么”

Edge 决定状态如何流动。常见类型包括：

设计 Edge 的原则是：

能由确定性条件判断的，不交给模型；只有确实需要理解语义时，才使用模型路由。

“测试退出码为 0”无需 LLM 判断。“这条需求属于支付还是结算领域”才可能需要语义分类。

3.4 Reducer：并行结果如何合并

并行不是画三条分支就结束了。多个节点同时修改状态时，需要定义合并规则。

假设三个 Agent 并行发现受影响文件：

backend: affected_files: - service/payment_metric.gomonitoring: affected_files: - config/payment_dashboard.yamltests: affected_files: - tests/payment_metric_test.go

汇合时可以做集合并集。但如果两个节点同时修改api_contract，系统应该：

• 采用最后写入；
• 按优先级选择；
• 判定冲突并暂停；
• 交给专门的整合节点；
• 要求重新执行依赖分支。

不同字段需要不同 Reducer。没有显式合并策略，并行执行很容易产生静默覆盖。

3.5 Checkpoint：保存什么，什么时候保存

LangGraph 的持久化机制会在执行过程中保存状态，使流程能够恢复、检查和进行人工介入。

生产设计还需要回答：

• 每个节点前保存，还是节点后保存；
• 保存完整状态还是增量事件；
• Checkpoint 保留多久；
• 状态是否包含敏感信息；
• 外部副作用是否已经完成；
• Graph 升级后旧状态能否迁移。

长任务不应该只依赖一段仍然活着的进程。进程退出、机器重启或人工等待都不应让整个任务失忆。

3.6 Command 与 Interrupt：控制流也是业务数据

当流程需要人工确认时，不应通过“暂停当前线程一直等待”来实现。

LangGraph Interrupt的思路是保存当前状态，向外部返回待处理信息，等审批结果到达后再从 Checkpoint 恢复。

人工节点需要展示：

approval_request: change_id: AI-CHANGE-20260726-018 decision_needed: 是否进入1%灰度 evidence: - diff://change/018 - test://change/018/integration - replay://change/018/baseline risks: - 旧口径历史查询需要重点观察 options: - approve - reject - request_changes

人工不是 Graph 之外的异常，而是一个有输入、输出和审计记录的节点。

四、一张可靠的 Graph 应该怎样设计

4.1 第一步：从最终验收结果倒推

不要先问“需要几个 Agent”，先问：

• 最终交付物是什么；
• 怎样证明任务完成；
• 哪些失败不可接受；
• 哪些证据必须保存；
• 哪些决策需要人负责。

如果验收标准不清楚，Graph 只会更高效地制造中间产物。

4.2 第二步：区分判断、执行和验证

一个任务通常包含三类节点：

判断节点：理解需求、分类、规划、归因执行节点：写代码、查询数据、生成文档、调用系统验证节点：测试、规则校验、回放、评测、人工审批

不要让执行节点自己宣布成功。写代码的 Agent 和验证代码的节点需要拥有不同的目标、上下文和权限。

4.3 第三步：让节点幂等

节点重试时，重复执行不应该制造额外副作用。

读取知识、分析代码等纯读取节点天然容易重试。发布、发消息、写数据库等节点需要：

• Idempotency Key；
• 操作前检查当前状态；
• 外部事务 ID；
• 写前 Checkpoint；
• 成功后的确认记录；
• 失败时的补偿动作。

例如发布接口已经成功，但 Agent 在收到响应前超时。没有幂等键时，重试可能创建第二次发布。

4.4 第四步：给循环设置预算

Graph 中的循环必须有退出条件：

loop_budget: max_iterations: 3 max_wall_time: 30m max_tokens: 50000 no_progress_limit: 2 stop_on: - repeated_same_error - high_risk_finding - missing_permission

除了次数，还要识别“没有进展”。如果连续两轮错误类型、修改文件和测试结果都没有变化，继续调用模型通常不会带来新结果。

4.5 第五步：把上下文和状态分开

State 保存任务事实和结构化进度，Context 是某个节点本次运行需要看到的信息。

规划节点可能需要需求、架构和历史决策；测试节点只需要接口契约、变更 Diff 和验收条件。所有节点共享同一份完整上下文，不仅浪费 Token，还会让无关信息影响判断。

4.6 第六步：为版本升级设计迁移

长任务运行期间，Graph 定义可能已经更新。需要明确：

• 正在运行的任务继续使用旧 Graph，还是迁移；
• 新增状态字段如何填充；
• 删除节点后旧 Checkpoint 如何恢复；
• 路由规则变化是否影响已完成步骤；
• 哪个 Graph 版本产生了最终结果。

Graph 本身也应该版本化：

graph_runtime: graph_name: ai_change_delivery graph_version: 3.4.1 state_schema_version: 2 policy_version: risk-policy-202607

五、用一条 AI Coding 任务跑完整张 Graph

这次不使用“做一个新页面”作为演示，而是处理一个更接近企业真实情况的需求：

支付成功率指标从“成功请求 / 全部请求”调整为“成功请求 / 有效请求”，需要同时更新后端计算、监控看板、知识文档和历史查询兼容逻辑。

它涉及多个仓库、多种验证和一次高风险口径变更，适合使用 Graph。

5.1 先定义执行图

5.2 规划节点不直接生成代码

规划节点首先读取：

• 当前 LLM Wiki 中的指标定义；
• 指标依赖的应用、接口和看板；
• 历史代码变更；
• 现有测试与回放数据；
• 用户给出的验收要求。

它输出影响清单和冻结契约：

frozen_contract: metric_id: payment_success_rate new_formula: success / valid_request valid_from: 2026-08-01T00:00:00+08:00 backward_compatibility: historical_query: use_formula_by_event_time acceptance: - 新时间范围使用新口径 - 历史时间范围保持旧口径 - 看板、告警和Wiki使用同一版本

这一步必须由人确认。因为指标口径不是纯技术细节，它会影响经营判断。

5.3 并行分支只共享冻结后的契约

契约通过后，四个分支可以并行：

• 后端 Agent 修改计算和历史兼容；
• 监控 Agent 更新看板和告警；
• 测试 Agent生成边界用例与历史流量集；
• 文档 Agent 更新知识对象和迁移说明。

每个分支在独立工作区执行，只向共享 State 返回：

• 产物引用；
• 修改摘要；
• 测试结果；
• 风险与未解决问题。

大量工具输出和中间推理留在分支自己的 Trace 中。

5.4 集成节点负责发现跨分支冲突

集成不只是合并代码，还需要检查：

• 代码中的公式是否与 Wiki 一致；
• 看板生效时间是否与后端一致；
• 测试是否同时覆盖新旧口径；
• 文档引用的 API 和字段是否真实存在；
• 四个分支是否修改了同一配置。

发现冲突后，系统根据责任字段将任务退回对应分支，而不是让所有分支重新执行。

5.5 验证失败要先归因，再返工

verification_failure: stage: historical_replay symptom: 7月历史查询结果发生变化 classification: backward_compatibility owner_branch: backend evidence: replay://change/018/case-77 unaffected_branches: - monitoring - documentation action: rework_backend_only

“失败以后回到开发节点”过于粗糙。真正可靠的 Graph 需要知道失败属于哪个分支、哪些成果可以保留、返工后哪些验证必须重跑。

六、LangChain 到 LangGraph，到底演进了什么

6.1 Chain 擅长组合，Graph 强调运行状态

早期 LangChain 的核心价值，是把 Prompt、模型、解析器、检索器和工具组合成一条调用链。对于输入到输出相对明确的任务，这种抽象很自然。

复杂 Agent 出现以后，流程开始包含：

• 条件分支；
• 多轮工具调用；
• 循环；
• 并行节点；
• 长时间等待；
• 人工介入；
• 失败恢复。

这些能力如果全部隐藏在一个 Agent Executor 或长函数中，运行状态就很难检查。

LangGraph 官方文档将自身定位为面向长时间、状态化 Agent 的编排运行时，并强调 Durable Execution、Streaming、Human-in-the-loop 和 Persistence。它也可以不依赖 LangChain 的高层组件单独使用。

6.2 演进的核心不是把 Chain 画成图

真正的变化包括：

Graph 并不要求所有流程都高度动态。相反，它允许确定性代码、Agent 和人工节点处于同一张图中。

6.3 LangGraph 也不会替你完成设计

使用框架以后，团队仍然要自己决定：

• State Schema；
• 节点职责；
• 并发合并规则；
• 幂等策略；
• Checkpoint 存储；
• 错误分类与补偿；
• 人工审批条件；
• 评测与上线标准。

框架提供运行能力，不会自动把一条不清晰的业务流程变可靠。

七、Graph 应该怎样评测

7.1 只看最终任务成功率不够

最终结果失败时，需要知道失败发生在哪一层。

graph_metrics: node: - node_success_rate - latency - token_cost - retry_rate - evidence_completeness routing: - route_accuracy - unsafe_route_rate - unnecessary_llm_route_rate state: - schema_violation_rate - missing_required_field_rate - merge_conflict_rate - invariant_violation_rate recovery: - checkpoint_resume_success_rate - duplicate_side_effect_rate - targeted_rework_rate - compensation_success_rate graph: - end_to_end_success_rate - wall_clock_time - human_intervention_rate - high_risk_failure_rate - total_cost

7.2 路由评测需要单独的数据集

模型路由节点应该有自己的分类样本：

routing_case: input: test_status: failed failure_type: contract_mismatch affected_branch: monitoring expected: next_node: monitoring_rework forbidden: - deploy - backend_rework

高风险错误不能被总体准确率掩盖。即使路由准确率达到 99%，只要剩余 1% 会把未通过测试的代码送去发布，这个节点仍然不能准出。

7.3 State 需要属性测试

除了用示例测试节点，还可以验证状态不变量：

• 未完成验证时，release.approved永远不能为 true；
• 进入部署前必须存在确定的 Commit 和制品哈希；
• 任一并行分支失败时，集成状态不能标记为 completed；
• 已失效知识不能进入当前版本的执行上下文；
• Token 和重试预算不能小于零。

这些规则适合由确定性代码检查，不需要 LLM Judge。

7.4 用故障注入验证恢复

在测试环境主动制造：

• 模型调用超时；
• Checkpoint 写入失败；
• 一个并行节点长期无响应；
• 工具已经执行但响应丢失；
• 人工审批等待数小时；
• Graph 运行中版本升级；
• 返回结果缺少必填字段。

如果没有故障注入，团队通常只验证了“正常路径能跑”，没有验证 Graph Engineering 最重要的恢复能力。

八、什么时候不要做 Graph Engineering

下面这些任务通常不需要复杂 Graph：

• 修改一个明确的小函数；
• 一次简单知识查询；
• 只包含两三个固定步骤的脚本；
• 没有并行、分支、等待和恢复需求；
• 单次执行失败后直接重跑成本很低。

引入 Graph 会增加：

• 状态 Schema 的维护成本；
• 节点和版本数量；
• Checkpoint 存储；
• 路由与并发测试；
• 运维和可观测复杂度。

可以用一个简单判断：

use_graph_when: - 有三个以上相对独立的执行单元 - 存在并行汇合或条件分支 - 任务持续时间长，需要暂停恢复 - 不同节点需要不同权限和上下文 - 失败后只希望重做部分步骤 - 有人工审批或外部事件等待

只满足一项时，普通函数、队列或单 Agent Loop 可能更简单。

九、最常见的七个设计错误

错误一：先画 Graph，再定义验收标准。
节点很多，最终却没人知道什么叫完成。

错误二：State 只是聊天记录。
无法计算、合并、校验和迁移的状态，不能支撑可靠编排。

错误三：所有 Edge 都让 LLM 决定。
确定性条件交给模型，只会增加成本和不稳定性。

错误四：并行节点可以随意写共享字段。
没有 Reducer 和冲突策略，并行只是更快地产生不一致。

错误五：重试等于重新调用。
有副作用的节点必须设计幂等键和补偿。

错误六：执行 Agent 自己负责验收。
执行和验证的目标不同，需要独立节点和证据。

错误七：只监控模型，不监控 Graph。
单次模型调用都成功，整条路径仍然可能选择错误、状态丢失或成本失控。

十、企业落地路线

10.1 第一阶段：把现有流程显式化

先选择一条已经存在、人工步骤明确的流程：

• 画出当前节点和条件；
• 定义统一 State；
• 将固定判断改成代码；
• 保留一个 Agent 节点处理语义任务；
• 记录每个节点的输入、输出和耗时。

10.2 第二阶段：增加持久化和独立验证

• 节点后写 Checkpoint；
• 支持失败后从指定节点恢复；
• 将执行和验证拆开；
• 对外部写操作增加幂等；
• 建立节点和路由评测集。

10.3 第三阶段：并行、子图和多 Agent

只有单节点稳定以后，再引入：

• Fan-out / Fan-in；
• 动态任务分发；
• 专业 Agent 子图；
• 独立上下文和权限；
• 失败归因与定向返工；
• Graph 版本迁移。

💡先证明节点可靠，再讨论多个 Agent 怎样并行。Graph 放大的是节点能力，也会放大节点缺陷。

十一、最后

Graph Engineering 最容易被误解成“把 Agent 流程画得更复杂”。

它真正做的事情恰好相反：把原来隐藏在长 Prompt、聊天历史和 Agent 自主判断里的流程，变成可以被人和程序共同理解的状态、路径和契约。

模型负责需要理解和判断的部分；代码负责确定性规则；验证系统负责证明结果；人负责目标、标准和高风险决策。

随着模型能力继续增强，一个节点可能完成过去一个团队才能完成的工作。但节点越强，系统越需要回答：

它为什么被启动？可以看到什么？可以修改什么？完成的证据是什么？失败以后谁来接手？整个流程是否仍然处于可控边界？

这就是 Graph Engineering 的价值。

Loop 不会消失，Harness 不会消失，Prompt 和 Context 也不会消失。它们只是被放进更大的工程结构中：

Prompt 决定怎样表达，Context 决定模型看到什么，Harness 决定怎样运行，Loop 决定怎样修正，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时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】