掌握在 LangChain 中将 Agent 转换成 Workflow 的技巧
目录
前言
一、为什么 Agent 会成为项目中的问题
问题1：执行路径不可预测
问题2：Token 消耗较高
问题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 每次都会重新思考。
例如：
第一次：
订单工具 ↓ 物流工具 ↓ 返回结果第二次：
物流工具 ↓ 订单工具 ↓ 返回结果第三次甚至可能：
订单工具 ↓ 订单工具 ↓ 物流工具对于开发人员来说：
难以复现 难以测试 难以排查问题2：Token 消耗较高
Agent 每执行一步都会进行推理。
例如：
Thought Action Observation循环多次。
典型流程：
思考 ↓ 调用工具 ↓ 观察 ↓ 再次思考 ↓ 再次调用工具产生大量 Token 消耗。
问题3：业务逻辑难以沉淀
例如：
订单查询 ↓ 物流查询 ↓ 退款查询实际上流程已经固定。
但 Agent 每次仍然需要重新推理。
这是一种资源浪费。
二、什么是 Workflow
Workflow 可以理解为：
提前设计好的执行流程例如：
用户提问 ↓ 查询订单 ↓ 查询物流 ↓ 整理结果 ↓ 返回用户这里没有自主决策。
而是固定执行。
对应架构如下：
相比 Agent：
Workflow 的优点非常明显。
三、如何判断应该使用 Agent 还是 Workflow
这是很多开发者最容易困惑的问题。
我的经验是：
适合 Workflow
如果业务流程明确：
查询订单 查询物流 查询退款 发送通知那么应该使用 Workflow。
因为：
执行稳定 成本低 可测试 可维护适合 Agent
如果业务流程未知：
例如：
帮我规划上海三日游模型需要决定：
查询天气 查询景点 查询酒店 规划路线此时才适合 Agent。
可以简单记忆：
确定流程 → Workflow 未知流程 → Agent四、Agent 转 Workflow 的核心思路
很多团队最初架构：
一个超级Agent 处理所有事情例如：
agent.invoke( "帮我查询订单并申请退款" )随着业务增长：
订单查询 物流查询 退款申请 发票开具 售后处理全部塞进一个 Agent。
最终会变成：
超级大脑 ↓ 超级混乱正确做法是拆分节点。
例如：
订单节点 物流节点 退款节点 通知节点形成工作流。
架构如下：
这就是典型的 Workflow 思维。
五、使用 LangGraph 构建 Workflow
LangGraph 的本质：
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 系统能否真正落地到生产环境，并长期稳定运行。