过去两年Agent 的单步能力明显变强了。它可以读代码、查资料、调用工具、修改文件也能在失败后重试。可当任务从十分钟延长到十小时从一次模型调用变成几十个步骤新的问题出现了规划已经完成执行到一半却忘了最初的验收标准三个 Agent 并行修改代码结果写入同一份状态时互相覆盖测试失败后整个流程从头再跑已经正确的步骤也被重复执行人工审批等待了一晚第二天无法从断点继续模型把“测试不通过”错误地路由到部署节点工具调用成功但进程超时重试以后重复创建了两条生产记录最终结果失败却无法判断是哪个节点、哪条路径或哪个状态出了问题。这些问题不再属于 Prompt Engineering。模型知道“下一步大概做什么”不代表系统知道当前走到了哪里哪些步骤可以并行谁可以修改哪些状态失败后应该重试、回退还是补偿什么时候必须停下来找人流程升级以后旧任务怎样继续Graph Engineering 讨论的就是这一层如何把复杂任务设计成可执行、可暂停、可恢复、可观察和可评测的状态图。核心判断模型越强单个节点可以承担的任务越复杂但整个系统的自由度也随之增大。Graph Engineering 不是限制模型能力而是把模型能力放在清晰的状态、路径和责任边界中。一、Graph Engineering 是新名字问题并不新1.1 它不是知识图谱这里的 Graph 指工作流图或控制流图Node完成一次明确工作的节点Edge决定状态接下来流向哪里State在整个任务中持续保存的结构化状态Checkpoint可以恢复执行的状态快照Subgraph拥有独立职责和状态边界的子流程。它与知识图谱、GraphRAG 的区别是概念图中的节点图中的边主要目的知识图谱人、组织、应用、知识等实体属于、依赖、引用等关系表达事实和语义GraphRAG实体、社区、文档和摘要语义与引用关系提高知识检索与回答Graph Engineering任务步骤、Agent、工具或人工审批执行顺序和条件路由编排任务执行三者可以组合使用但不能混为一谈。一个故障处理 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 不是互相替代而是在管理不同对象。工程方法主要设计对象典型问题Prompt Engineering指令与输出约束怎样让模型理解任务Context Engineering进入上下文的信息模型此刻应该看到什么Harness Engineering工具、记忆、权限和运行环境模型怎样安全地做事Loop Engineering观察、反馈、重试和停止单个 Agent 怎样自我修正Graph Engineering节点、路径、共享状态和恢复多个执行单元怎样完成复杂流程可以用一句话区分 Loop 与 GraphLoop 管节点内部的反馈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-metric7 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:0008: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 类型例子推荐实现固定边计划完成后进入审批代码条件边测试通过进入回放否则返工代码读取结构化结果语义路由工单应该交给支付还是订单 Agent分类器或 LLM动态分发根据受影响模块生成多个并行任务程序加模型循环边验证失败后返回修复有预算的 Loop设计 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:0008: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 画成图真正的变化包括Chain 思维Graph 思维关注组件怎样连接关注状态怎样流动调用失败后重新执行链路从 Checkpoint 恢复相关节点中间结果多为临时变量中间结果进入结构化 State人工介入是外部流程人工审批是可恢复节点Agent 循环藏在执行器内部Loop、路径和停止条件显式化主要测试最终输出同时测试节点、路由、状态和整图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_cost7.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%免费】
Graph Engineering 全面解析
过去两年Agent 的单步能力明显变强了。它可以读代码、查资料、调用工具、修改文件也能在失败后重试。可当任务从十分钟延长到十小时从一次模型调用变成几十个步骤新的问题出现了规划已经完成执行到一半却忘了最初的验收标准三个 Agent 并行修改代码结果写入同一份状态时互相覆盖测试失败后整个流程从头再跑已经正确的步骤也被重复执行人工审批等待了一晚第二天无法从断点继续模型把“测试不通过”错误地路由到部署节点工具调用成功但进程超时重试以后重复创建了两条生产记录最终结果失败却无法判断是哪个节点、哪条路径或哪个状态出了问题。这些问题不再属于 Prompt Engineering。模型知道“下一步大概做什么”不代表系统知道当前走到了哪里哪些步骤可以并行谁可以修改哪些状态失败后应该重试、回退还是补偿什么时候必须停下来找人流程升级以后旧任务怎样继续Graph Engineering 讨论的就是这一层如何把复杂任务设计成可执行、可暂停、可恢复、可观察和可评测的状态图。核心判断模型越强单个节点可以承担的任务越复杂但整个系统的自由度也随之增大。Graph Engineering 不是限制模型能力而是把模型能力放在清晰的状态、路径和责任边界中。一、Graph Engineering 是新名字问题并不新1.1 它不是知识图谱这里的 Graph 指工作流图或控制流图Node完成一次明确工作的节点Edge决定状态接下来流向哪里State在整个任务中持续保存的结构化状态Checkpoint可以恢复执行的状态快照Subgraph拥有独立职责和状态边界的子流程。它与知识图谱、GraphRAG 的区别是概念图中的节点图中的边主要目的知识图谱人、组织、应用、知识等实体属于、依赖、引用等关系表达事实和语义GraphRAG实体、社区、文档和摘要语义与引用关系提高知识检索与回答Graph Engineering任务步骤、Agent、工具或人工审批执行顺序和条件路由编排任务执行三者可以组合使用但不能混为一谈。一个故障处理 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 不是互相替代而是在管理不同对象。工程方法主要设计对象典型问题Prompt Engineering指令与输出约束怎样让模型理解任务Context Engineering进入上下文的信息模型此刻应该看到什么Harness Engineering工具、记忆、权限和运行环境模型怎样安全地做事Loop Engineering观察、反馈、重试和停止单个 Agent 怎样自我修正Graph Engineering节点、路径、共享状态和恢复多个执行单元怎样完成复杂流程可以用一句话区分 Loop 与 GraphLoop 管节点内部的反馈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-metric7 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:0008: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 类型例子推荐实现固定边计划完成后进入审批代码条件边测试通过进入回放否则返工代码读取结构化结果语义路由工单应该交给支付还是订单 Agent分类器或 LLM动态分发根据受影响模块生成多个并行任务程序加模型循环边验证失败后返回修复有预算的 Loop设计 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:0008: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 画成图真正的变化包括Chain 思维Graph 思维关注组件怎样连接关注状态怎样流动调用失败后重新执行链路从 Checkpoint 恢复相关节点中间结果多为临时变量中间结果进入结构化 State人工介入是外部流程人工审批是可恢复节点Agent 循环藏在执行器内部Loop、路径和停止条件显式化主要测试最终输出同时测试节点、路由、状态和整图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_cost7.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%免费】
