用 LangGraph 搭一个会查数据库的 Agent，踩坑记录

张张老师2024/12/18583 阅读

同事的需求很简单：让 AI 能查公司数据库回答数据问题。比如"上个月销售额多少"。听起来简单，但模型自己不会连数据库，得让它会调用工具。我选了 LangGraph，因为它对 Agent 的控制力比裸 LangChain 强太多。

核心概念：StateGraph。把流程定义成图，节点就是一步操作，边决定下一步去哪。我的 Agent 有四个节点：判断意图 → 生成 SQL → 执行 SQL → 生成回答。其中生成 SQL 和执行 SQL 之间，如果 SQL 有错，要回到生成节点重试。

代码骨架：

Python

from langgraph.graph import StateGraph

g = StateGraph(AgentState)
g.add_node("plan", plan_sql)        # 生成 SQL
g.add_node("execute", run_sql)      # 执行 SQL
g.add_node("answer", gen_answer)    # 总结回答
g.add_edge("plan", "execute")
g.add_conditional_edges("execute", decide_retry, {"retry": "plan", "ok": "answer"})
g.set_entry_point("plan")
g.set_finish_point("answer")

踩过的坑：

第一个是状态设计。StateGraph 的 state 要放所有节点共享的数据，比如 SQL、执行结果、错误信息。我一开始只放 messages，结果节点之间传数据全靠工具返回，绕了一圈。后来把 sql、error 都加进 state，清爽多了。

第二个是重试循环。生成 SQL 很容易错，特别是表名写错。我在执行节点里捕获错误，把错误信息拼进下一次的 prompt 里让模型修正。限制最多重试 3 次，防止死循环。

第三个是工具返回太长。查询结果可能几千行，全塞进 context 模型直接懵。我做了截断和摘要，只把前 20 行 + 总数给模型。

第四个坑：LangGraph 的版本差异很大。0.x 和 0.2 的 API 不一样，网上教程大多是旧的，照着抄很容易报错。建议直接看官方文档对应的版本。

最后说下效果：现在这个 Agent 已经跑了一个多月，数据问答的准确率在 80% 左右，剩下的主要靠补充表结构描述和别名来提升。

如果你想更深入，可以研究下 Human-in-the-loop 的 interrupt 机制，让敏感操作先人工确认再执行。

还没有评论，来抢沙发～

评论0