被Token坑惨后我悟了：LangGraph比LangChain省一半成本，原因就这两点

大家好我是杯子最近天天和 LLM 打交道的开发者。最近我被 OpenAI 的账单狠狠“教育”了一次一个月光 LangChain Agent 的 Token 费用就要到四位数了。我翻着日志一看——全是重复调用。每次用户问个简单问题Agent 都要先想、再查、再总结……LLM 被反复唤醒上下文越滚越大Token 像不要钱一样往外烧。直到我把 Agent 全部重构成了LangGraph后同样的业务Token 消耗直接腰斩。今天把核心的两个省 Token 逻辑讲透让大家少走我踩过的坑。一、LangChain Agent全自动浪费的“完美”流程用 LangChain 写带工具的 Agent 时框架帮你把一切都“自动化”了听起来很香但实际上是自动烧钱第一次 LLM 调用把用户问题 系统 Prompt 工具描述塞进上下文让 LLM 决定「要不要用工具」。执行工具调用工具拿到结果。第二次 LLM 调用把工具返回结果再塞回上下文让 LLM 做最终总结并输出答案。关键问题来了这两次 LLM 调用是强制绑定的。即使工具返回的结果已经足够清晰比如查到了精确答案框架还是会再调用一次 LLM 去“润色”。我测过一个最简单的“查询天气” AgentLangChain 平均每次请求2 次 LLM 调用Token 消耗 ≈ 1200 tokens含上下文膨胀这还没算上多工具、多轮对话时上下文越滚越大的情况。LangChain 就像一台全自动洗衣机你只能选“标准模式”想省水省电门都没有。二、LangGraph你手动省油想省就省LangGraph 把 Agent 拆成一张状态图StateGraph每一步你自己决定怎么走。核心省钱逻辑就两点1. 工具调用后你可以直接跳过第二次 LLM 调用# LangGraph 伪代码超级简洁defroute_after_tool(state):iftool_result_is_enough(state[messages]):# 你自己判断returnEND# 直接结束不走第二次 LLMelse:returnllm# 需要 LLM 再总结才走graphStateGraph(AgentState)graph.add_node(tools,tool_node)graph.add_node(llm,llm_node)graph.add_conditional_edges(tools,route_after_tool)效果调用工具拿到结果后可以直接返回给用户不再进 LLM只有需要自然语言润色时才走第二次 LLM。很多场景下查询类、计算类、简单事实类工具返回结果就是最终答案。Token 直接少一半。我把 70% 的查询 Agent 都改成了这种“工具直出”模式Token 消耗从 1200 掉到 550 左右实测砍掉 50%左右。2. 通过 State 精准控制每次 LLM 的上下文LangChain Agent 的消息列表是全局共享、不断累积的越聊上下文越长。LangGraph 的 State 是你自己定义的你可以每次调用 LLM 前只把真正需要的消息塞进去历史总结、关键事实、当前工具结果把不重要的闲聊、旧工具结果直接丢掉或压缩甚至针对不同节点规划节点、工具节点、总结节点加载不同的 LLM 不同的上下文结果就是每一次 LLM 调用Prompt 都保持在最小必要长度。Token 不再偷偷膨胀。我最后想说LangChain 适合快速原型它把一切都自动化了但自动化 自动浪费。LangGraph 把控制权交还给你它不帮你省你就继续烧你想省它就能帮你精准省到骨子里。我现在看到账单不再心慌反而有点小窃喜——因为我知道每一次调用我都亲自把过关没有一次多余的 Token。点赞 收藏下次写复杂 Agent 的时候记得回来再看一遍省的钱够请我喝好几杯咖啡了 —— 链上杯子2026.3 写于被 Token 账单支配的恐惧中