大家好，我是杯子，最近天天和 LLM 打交道的开发者。

最近我被 OpenAI 的账单狠狠“教育”了一次：一个月光 LangChain Agent 的 Token 费用就要到四位数了。我翻着日志一看——全是重复调用。每次用户问个简单问题，Agent 都要先想、再查、再总结……LLM 被反复唤醒，上下文越滚越大，Token 像不要钱一样往外烧。

直到我把 Agent 全部重构成了 LangGraph后，同样的业务，Token 消耗直接腰斩。今天把核心的两个省 Token 逻辑讲透，让大家少走我踩过的坑。

一、LangChain Agent：全自动浪费的“完美”流程

用 LangChain 写带工具的 Agent 时，框架帮你把一切都“自动化”了，听起来很香，但实际上是自动烧钱：

1. 第一次 LLM 调用：把用户问题 + 系统 Prompt + 工具描述塞进上下文，让 LLM 决定「要不要用工具」。
2. 执行工具：调用工具，拿到结果。
3. 第二次 LLM 调用：把工具返回结果再塞回上下文，让 LLM 做最终总结并输出答案。

关键问题来了：
这两次 LLM 调用是强制绑定的。即使工具返回的结果已经足够清晰（比如查到了精确答案），框架还是会再调用一次 LLM 去“润色”。

我测过一个最简单的“查询天气” Agent：

• LangChain 平均每次请求 2 次 LLM 调用
• Token 消耗 ≈ 1200 tokens（含上下文膨胀）

这还没算上多工具、多轮对话时上下文越滚越大的情况。LangChain 就像一台全自动洗衣机，你只能选“标准模式”，想省水省电？门都没有。

二、LangGraph：你手动省油，想省就省

LangGraph 把 Agent 拆成一张状态图（StateGraph），每一步你自己决定怎么走。核心省钱逻辑就两点：

1. 工具调用后，你可以直接跳过第二次 LLM 调用

# LangGraph 伪代码（超级简洁）
def route_after_tool(state):
    if tool_result_is_enough(state["messages"]):  # 你自己判断
        return "END"          # 直接结束！不走第二次 LLM
    else:
        return "llm"          # 需要 LLM 再总结才走

graph = StateGraph(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 账单支配的恐惧中