自去年年底起，我们的技术团队在生产环境中采用广受关注的 LangGraph 进行 Agent 开发，至今已稳定运行三个月。本着客观与坦诚的态度，本文分享这段实战经历的真实体验与深度思考。
为什么选择 LangGraph
我们对市面上主流的 Agent 框架进行了逐一比较，包括 AutoGen、CrewAI 等，经过仔细评估后最终锁定了 LangGraph。并非因为它在所有维度上都完美，而是因为它与我们当前的业务需求最为匹配。
LangGraph 的核心优势非常清晰：具备状态管理能力、支持流程编排，并能够通过可视化方式处理复杂逻辑。在我们业务中有一个典型场景：用户下单后需执行一系列校验步骤，状态的流转必须稳定且可靠，不能出现任何差错。
python
from typing import TypedDict, Annotated
from langchain_core.messages import BaseMessage
import operator
class OrderState(TypedDict):
order_id: str
user_id: str
messages: Annotated[list[BaseMessage], operator.add]
validation_results: dict
current_step: str
如果业务需求仅限于简单的问答交互，那么使用 LangGraph 确实有些大材小用，显得过于笨重。因此，在选用框架前务必评估自身场景的复杂度。
实战案例：一个客服 Agent 的完整链路
我们构建的客服 Agent，大致流程如下所示：
text
用户下单 → 验证库存 → 检查地址 → 计算运费 → 更新库存 → 发送通知
每一个环节都可能出现异常，一旦出错就需要回滚到上一步。利用 LangGraph 来表达这种逻辑，显得非常自然：
python
def validate_inventory(state: OrderState) -> OrderState:
"""检查库存"""
order_id = state["order_id"]
stock = check_stock(order_id)
if stock < state["quantity"]:
return {**state,
"current_step": "insufficient_stock",
"validation_results": {"inventory": False}}
return {**state,
"validation_results": {"inventory": True},
"current_step": "check_address"}
def handle_insufficient_stock(state: OrderState) -> OrderState:
"""处理库存不足，回滚并通知用户"""
notify_user(state["user_id"], "库存不足")
return {**state,
"messages": state["messages"] + [AIMessage(content="很抱歉，库存不足，请减少购买数量")]}
流程图直观呈现如下：
text
[validate_inventory] → [check_address] → [calc_shipping]
↓ ↓
[handle_insufficient_stock] ← [rollback]
借助有向图来管理流程，远比堆积大量 if-else 语句要清晰直观。这正是 LangGraph 最打动我们的地方。
工具调用的经验与教训
工具调用方面我们投入了最多心血，也踩了不少坑。例如：
python
from langchain_community.tools import DuckDuckGoSearchRun
search = DuckDuckGoSearchRun()
一个常见问题是 AI 会反复调用同一个工具。为此我们增加了去重逻辑：
python
def deduplicate_tools(tools_called: list[str]) -> list[str]:
seen = set()
result = []
for tool in tools_called:
if tool not in seen:
seen.add(tool)
result.append(tool)
return result
另一个关键教训是：工具描述（tool description）必须写得足够清晰准确。如果描述含糊不清，AI 很容易混淆工具、随意调用。这需要在 Prompt 上多加打磨，才能有效调教。
生产环境踩过的三个坑
长对话导致内存持续上涨
运行几天后，发现内存占用一直攀升，排查后确认是 messages 列表未做截断所致。解决方案很简单，添加了一个长度限制：python
def trim_messages(messages: list[BaseMessage], max_len: int = 20) -> list[BaseMessage]:
if len(messages) > max_len:
return messages[-max_len:]
return messages并行执行几乎导致系统崩溃
有一次，让 AI 同时调用5个工具，结果两个超时、两个报错。AI 开始反复重试，差点把系统拖垮。此后，我们对所有工具调用都限制了最大重试次数，防止无限循环。K8s 多 Pod 间状态丢失
在 Kubernetes 上运行后，不同 Pod 之间状态不共享，如果某个请求的后续调用被调度到另一个 Pod，状态会直接丢失。后来改用 Redis 进行状态持久化，才彻底解决：python
from redis import Redis
import json
redis_client = Redis(host='redis', port=6379)
def sa ve_state(session_id: str, state: OrderState):
redis_client.setex(f"order_state:{session_id}",
3600, # 1 小时过期
json.dumps(state))
生产环境的三个建议
从三个月的实战经验中，提炼出三条最重要的心得：
1. 务必部署监控
LangGraph 本身没有内置监控，必须自行补充。我们引入了 Prometheus 指标：
python
from prometheus_client import Counter, Histogram
tool_calls = Counter('agent_tool_calls_total', 'Total tool calls', ['tool_name'])
execution_time = Histogram('agent_execution_seconds', 'Agent execution time')
2. 异常兜底要全面
千万不要认为 AI 一定会按照你设计的流程运行，必须提前准备后路：
python
try:
result = graph.invoke(state)
except Exception as e:
logger.error(f"Graph execution failed: {e}")
route_to_human(state) # 降级为人工处理
3. 日志要足够细致
AI 的行为天然难以排查，如果日志不够详细，线上出现问题只能干着急。多打日志，关键时刻能救命。
到底适不适合你？
并非所有场景都需要 LangGraph。可以根据复杂度对号入座：
- 简单场景：对话机器人、FAQ 问答 → 使用 RAG 即可满足
- 中等复杂度：多步骤执行、需要状态管理 → LangGraph 非常合适
- 高复杂度：多 Agent 协作、复杂回滚逻辑 → 可以考虑 AutoGen 或自研方案
我们的场景恰好处于中等复杂度，LangGraph 用起来刚刚好。如果你也在类似的业务中摸索，它值得你尝试。
