掌握在 LangChain 中将 Agent 转换成 Workflow 的技巧

目录前言一、为什么 Agent 会成为项目中的问题问题1执行路径不可预测问题2Token 消耗较高问题3业务逻辑难以沉淀二、什么是 Workflow三、如何判断应该使用 Agent 还是 Workflow适合 Workflow适合 Agent四、Agent 转 Workflow 的核心思路五、使用 LangGraph 构建 Workflow第一步定义状态第二步定义节点第三步构建工作流六、条件路由Workflow 的进阶玩法七、Workflow 与 Agent 混合架构八、生产环境最佳实践原则一优先 Workflow原则二Agent 只负责决策原则三节点单一职责原则四状态统一管理总结在很多开发者刚接触 LangChain 时往往会被 Agent 的强大能力所吸引。例如用户 帮我查询订单状态Agent 会自动思考 ↓ 选择工具 ↓ 调用接口 ↓ 分析结果 ↓ 返回答案这种自主决策能力确实非常强大。但是随着项目规模扩大很多团队逐渐发现Agent 的执行过程不可控调试困难流程不透明响应结果不稳定生产环境难以维护因此在 LangChain 1.x 时代官方越来越推荐能 Workflow 的场景尽量 Workflow只有需要自主决策时才使用 Agent。而 LangGraph 的出现也让 Agent 到 Workflow 的转换变得更加容易。本文将结合实际案例讲解如何将 Agent 思维转换成 Workflow 思维。一、为什么 Agent 会成为项目中的问题假设我们有一个客服 Agent。用户输入帮我查询订单并告诉我物流状态传统 Agent 的执行过程如下看起来非常智能。但实际上存在几个问题。问题1执行路径不可预测Agent 每次都会重新思考。例如第一次订单工具 ↓ 物流工具 ↓ 返回结果第二次物流工具 ↓ 订单工具 ↓ 返回结果第三次甚至可能订单工具 ↓ 订单工具 ↓ 物流工具对于开发人员来说难以复现 难以测试 难以排查问题2Token 消耗较高Agent 每执行一步都会进行推理。例如Thought Action Observation循环多次。典型流程思考 ↓ 调用工具 ↓ 观察 ↓ 再次思考 ↓ 再次调用工具产生大量 Token 消耗。问题3业务逻辑难以沉淀例如订单查询 ↓ 物流查询 ↓ 退款查询实际上流程已经固定。但 Agent 每次仍然需要重新推理。这是一种资源浪费。二、什么是 WorkflowWorkflow 可以理解为提前设计好的执行流程例如用户提问 ↓ 查询订单 ↓ 查询物流 ↓ 整理结果 ↓ 返回用户这里没有自主决策。而是固定执行。对应架构如下相比 AgentWorkflow 的优点非常明显。三、如何判断应该使用 Agent 还是 Workflow这是很多开发者最容易困惑的问题。我的经验是适合 Workflow如果业务流程明确查询订单 查询物流 查询退款 发送通知那么应该使用 Workflow。因为执行稳定 成本低 可测试 可维护适合 Agent如果业务流程未知例如帮我规划上海三日游模型需要决定查询天气 查询景点 查询酒店 规划路线此时才适合 Agent。可以简单记忆确定流程 → Workflow 未知流程 → Agent四、Agent 转 Workflow 的核心思路很多团队最初架构一个超级Agent 处理所有事情例如agent.invoke( 帮我查询订单并申请退款 )随着业务增长订单查询 物流查询 退款申请 发票开具 售后处理全部塞进一个 Agent。最终会变成超级大脑 ↓ 超级混乱正确做法是拆分节点。例如订单节点 物流节点 退款节点 通知节点形成工作流。架构如下这就是典型的 Workflow 思维。五、使用 LangGraph 构建 WorkflowLangGraph 的本质State Node Edge即状态 节点 流程边第一步定义状态from typing import TypedDict class State(TypedDict): question: str order_info: str logistics_info: str状态负责在节点之间传递数据。第二步定义节点订单节点def query_order(state): state[order_info] ( 订单已支付 ) return state物流节点def query_logistics(state): state[logistics_info] ( 运输中 ) return state第三步构建工作流from langgraph.graph import StateGraph builder StateGraph(State) builder.add_node( order, query_order ) builder.add_node( logistics, query_logistics )连接流程builder.add_edge( order, logistics )编译graph builder.compile()执行graph.invoke( { question: 查询订单状态 } )这样就完成了 Workflow。六、条件路由Workflow 的进阶玩法实际业务中并不是所有流程都固定。例如用户查询订单走订单流程。用户申请退款走退款流程。此时可以使用条件路由。示例def route(state): if 退款 in state[question]: return refund return order添加条件边builder.add_conditional_edges( router, route )这样 Workflow 就拥有了部分 Agent 的灵活性。七、Workflow 与 Agent 混合架构很多企业最终采用Workflow Agent混合方案。原因很简单并非所有场景都适合 Workflow。例如固定流程 ↓ Workflow开放性决策 ↓ Agent示例用户问题 ↓ Workflow路由 ↓ 知识库查询 ↓ Agent分析 ↓ 结果返回这种模式目前非常流行。示例代码def rag_node(state): docs retriever.invoke( state[question] ) state[docs] docs return stateAgent 节点def agent_node(state): result agent.invoke( state[question] ) state[answer] result return state这样既保证了流程可控。又保留了 Agent 的智能能力。八、生产环境最佳实践经过多个项目实践后我总结出以下经验。原则一优先 Workflow如果流程明确不要直接上Agent先设计 Workflow。原则二Agent 只负责决策不要让 Agent查订单 查物流 查库存 查退款全部处理。应该Workflow负责执行 Agent负责决策原则三节点单一职责每个节点只做一件事。例如订单节点 物流节点 退款节点不要订单物流退款写在同一个节点中。原则四状态统一管理所有中间结果state[order] state[logistics] state[refund]统一存储。不要在节点之间直接传参。总结在 LangChain 早期很多开发者喜欢使用 Agent 解决所有问题。但随着项目规模扩大大家逐渐发现Agent ≠ 最优解真正稳定的生产系统往往采用Workflow Agent的组合架构。其中Workflow 负责可控流程Agent 负责智能决策而 LangGraph 的出现正好提供了从 Agent 向 Workflow 演进的最佳实践。对于企业级项目而言掌握 Agent 转 Workflow 的设计思路比单纯学会调用 Agent 更重要。因为它决定了你的 AI 系统能否真正落地到生产环境并长期稳定运行。