发布时间2026-07-12标签AI AgentLLMWorkflowLangGraphDAG工程实现系列导航上一篇AI Agent 工程实践10Memory 不只是聊天记录——长期记忆架构设计下一篇AI Agent 工程实践12为什么很多 Multi-Agent 项目最后都失败了本文是 [AI Agent 工程实践] 系列的第 11 篇第二季 · 工程实现。单步 Agent 能做的事早就不是问题了。帮我写个排序函数——秒出。审查这段代码——秒出。解释一下 async/await——秒出。可我第一次让它从头做完一个需求时问题全来了规划到一半忘了后半截、执行出错不知道怎么回退、跑到第三步时第一步的上下文已经丢了。我突然意识到Agent 的智商在模型执行力在 Workflow。模型决定单步质量Workflow 决定能不能把多步串成一次完整交付。第 08 篇讲了什么时候该用 Workflow这一篇讲Workflow 本身怎么落地——从规划到执行到审查一条链路串到底。本文你将学到✓ 为什么单步 Agent 做不了复杂任务——三个不可逾越的限制✓ Workflow 的核心链路User → Planner → Execute → Review → Finish✓ 四种实现范式Pipeline / DAG / State Machine / LangGraph各自适用场景✓ 用 LangGraph 落地一个真实 Workflow 的完整代码适合阅读✓ 做过单步 Agent、想让它能独立跑完项目的人✓ 在选型 Workflow 框架LangGraph / Temporal / Prefect的开发者✓ 想理解 DAG / State Machine / Pipeline 在 Agent 里怎么用的工程师问题背景单步 Agent一问一答的能力边界非常清晰。它做不了复杂任务原因不是模型差是三个结构性问题上下文溢出。一个需求从规划到上线可能涉及 10 步。全塞进一个 prompt模型对中间步骤的遵循率断崖式下降——又是 Lost in the Middle。步间信息丢失。第三步的输出是第四步的输入但第三步跑完上下文被新的 prompt 覆盖第一步的关键约束早被冲走了。Agent 走着走着忘了在干什么。错误无回退。第五步执行失败要回到第三步重新来——但没 Workflow 的 Agent 不知道回退是什么意思它只会继续往下跑或者直接报一个无上下文的错。一句话模型能做任何单步但做不了任何多步。Workflow 就是那根把单步串成多步的骨架。错误尝试第一次超长 prompt把所有步骤写进去设计一个 3000 字的 system prompt你先做 A然后根据 A 的结果做 B如果 B 失败就做 C……结果前十步还像样子后面开始丢步骤。模型并不按你的 prompt 所列的顺序严格执行——它只是在续写文本不是在执行流程。把 prompt 当流程引擎是把水彩画当蓝图。第二次手动接力——我做编排Agent 跑完一步我人工检查输出手动传给下一步。流程是跑通了但我成了 Workflow 引擎。结果一个需求来回人工接 5 次力和直接手写代码差不多累。而且人会忘——漏传一个中间输出的概率和忘记手动指定 task_type 一样高第 05 篇的老问题。人当编排器不可靠、不可持续。两次尝试指向同一个结论复杂任务必须有一个独立于人和模型的编排器——它负责步骤顺序、状态传递、异常回退、条件分支。这个编排器就是 Workflow。关键观察我把Agent 成功完成的复杂任务和失败的做了对比差异不在模型在编排方式任务特征无 Workflow有 Workflow步骤 ≤2能完成能完成步骤 3-5 且线性偶尔能看运气稳定完成步骤 ≥5 或有分支几乎必失败稳定完成某步需要重试不知道回退自动回退到上一步pie title 复杂任务失败原因 上下文溢出 · 丢步骤 : 35 步间信息丢失 : 30 错误无回退机制 : 25 其他 : 10Agent 的智商在模型执行力在 Workflow。模型再好没有编排也是每次从头教它怎么做项目。Workflow 把怎么做固化成骨架模型只负责每步里的做多好。问题不是模型不够强而是步骤之间的连接没有固化。正确做法是把编排逻辑从 prompt 里抽出来交给一个独立引擎——Workflow 管步骤顺序和状态模型只负责每步的生成。最终方案Workflow 链路 四种实现范式核心链路User → Planner → Execute → Review → Finish这就是你给的链路——一个通用 Workflow 的最简骨架每个节点职责清晰Planner把用户需求拆成可执行的步骤清单不是模型自由发挥而是产出结构化 planExecute按步骤清单逐条执行产出中间结果Review检查执行结果——不通过就回到 Execute回退就是 Workflow 的价值Finish汇总通过审查的结果交付用户Planner-Execute-Review 不是三个 Agent08 篇讲过是 Workflow 的三个节点同一个 Agent 换 skill 执行。Workflow 管的是节点怎么串、状态怎么传、失败怎么回。四种实现范式同样的链路不同复杂度用不同实现方式范式适合什么本质Agent 场景举例Pipeline固定步骤、无分支线性串联翻译 → 润色 → 输出DAG有分支/并行有向无环图同时研究方案A和B → 合并 → 决策State Machine需要回退/重试/异常状态 事件驱动Planner→Execute→Review失败回 ExecuteLangGraph以上三者的工程落地Graph State 条件边任意复杂 Workflow 的生产实现选型原则步骤固定且 2 步 → Pipeline / 有分支并行 → DAG / 需要回退重试 → State Machine / 真正写代码落地 → 用 LangGraph 表达前三种的任一种。stateDiagram-v2 [*] -- Pipeline: 步骤固定线性 Pipeline -- DAG: 出现分支/并行需求 DAG -- StateMachine: 需要回退/重试 StateMachine -- LangGraph: 需要工程化落地四种不是互斥的——LangGraph 是前三种的工程实现载体不是第四种范式。实际收益指标超长 Prompt手动接力Workflow 编排步骤完成率~40%常丢~80%人漏传~95%错误恢复无靠人自动回退重试人参与度低但质量低高累低自动化架构图 / 流程图带有回退的完整 WorkflowState Machine 视角关键fail · 需重新规划这条回退边是 Workflow 区别于 Pipeline 的核心——Pipeline 只能往前Workflow 能回头。代码或配置示例Planner-Execute-Review WorkflowLangGraph 实现from langgraph.graph import StateGraph, END # 1. 定义状态Workflow 的通行证随节点流转 class WorkflowState(TypedDict): task: str # 用户需求 plan: list[str] # Planner 产出的步骤清单 results: list[str] # 每步的执行结果 step_index: int # 当前执行到第几步 review_pass: bool # Review 是否通过 # 2. 定义节点Planner / Execute / Review def planner(state: WorkflowState) - WorkflowState: state[plan] agent.run(state[task], skillplanning) state[step_index] 0 return state def executor(state: WorkflowState) - WorkflowState: step state[plan][state[step_index]] result agent.run(step, contextstate[results]) state[results].append(result) state[step_index] 1 return state def reviewer(state: WorkflowState) - WorkflowState: state[review_pass] agent.run(state[results], skillreview) return state # 3. Workflow 定义节点 边 条件 wf StateGraph(WorkflowState) wf.add_node(planner, planner) wf.add_node(executor, executor) wf.add_node(reviewer, reviewer) wf.set_entry_point(planner) wf.add_edge(planner, executor) # 关键条件边——Review 决定往前走还是回头 wf.add_conditional_edges(reviewer, lambda s: pass if s[review_pass] and s[step_index] len(s[plan]) else (execute if s[step_index] len(s[plan]) else executor)) wf.add_edge(executor, reviewer) # 4. 编译运行 app wf.compile() result app.invoke({task: 实现用户登录模块})代码不长但 Workflow 的全部核心都在里面状态在节点间传递、条件边决定去向、同一 Agent 换了三个 Skill 跑 Planner/Execute/Review。这就是第 05 篇 Router 和第 07 篇 Skills 在 Workflow 里的交汇点。设计权衡候选方案优点缺点不选的原因超长 Prompt 硬塞多步零工程成本丢步骤、无回退prompt 不是流程引擎手动接力灵活人不可靠、不可持续等于没自动化Pipeline纯线性简单可靠无分支、无回退复杂任务必有分支和重试State Machine Workflow有回退、有分支、有状态需工程化选择理由唯一能处理出错后怎么办的编排方式Workflow 不是越复杂越好。两步以内的任务不需要 Workflow和第 08 篇同一条原则——不要为两句话的事上编排引擎。Workflow 的价值在步骤 ≥3 或有分支/回退需求时才体现。总结✅ 单步 Agent 的三个天花板上下文溢出、步间信息丢失、无回退——Workflow 逐一破解。✅ 核心链路User → Planner拆任务→ Execute逐步执行→ Review质量检查回退决策→ Finish交付。✅ 四种实现范式Pipeline线性/ DAG分支并行/ State Machine回退重试/ LangGraph工程落地。✅ 状态是 Workflow 的灵魂——没有状态传递节点之间就是孤岛。✅ Workflow 的价值在步骤 ≥3 或有分支/回退时体现两步任务别上。参考资料LangGraph 官方文档 — StateGraph Conditional Edges→ Workflow 工程实现的直接依据本文代码示例的技术来源Temporal / Prefect 文档→ 传统 Workflow 引擎的故障恢复与回退机制参考第 08 篇Workflow / Multi-Agent→ 什么时候该用 Workflow本文的前置决策篇第 05 篇Rule Router→ Router 在 Workflow 节点间如何动态选择 Skill第 07 篇Skills vs Prompt→ Planner/Execute/Review 各节点调用的 Skill 定义系列导航上一篇AI Agent 工程实践10Memory 不只是聊天记录——长期记忆架构设计下一篇AI Agent 工程实践12为什么很多 Multi-Agent 项目最后都失败了本文是 [AI Agent 工程实践] 系列的第 11 篇第二季 · 工程实现。