LangGraph 23. 生产环境下智能体如何节约成本：多智能体拆分、提示缓存与查询路由

摘要Summary本文基于生产案例讨论单体LangGraph智能体在长系统提示约 2 万 token、大量工具与无缓存条件下导致的LLM 成本与延迟问题并归纳四类改造按任务域拆分多智能体、Prompt Caching约 5 分钟窗口、将轻量子任务下沉为调用小模型的工具、以及Query Router做上下文感知的查询路由使问候与轻追问不再进入重型智能体。案例报告成本约降70%–75%并补充「何时需要完整智能体、何时不必」的架构取舍。关键词KeywordsLangGraphAI 智能体LLM 成本优化多智能体提示缓存Prompt Caching查询路由Query Router任务分解工具调用模型分层Claude SonnetPostgreSQL checkpoint生产环境如果你的 AI 智能体已经上线生产下文可能帮你砍掉相当大一块成本。1 一些结论我们的目标是优化一个基于LangGraph构建的 AI 智能体的 LLM 成本。High level 信息如下。1.1 原始架构系统依赖单一AI 智能体系统提示词约2 万 token。智能体基于LangGraph构建底层模型为Claude Sonnet 4.5。挂载约30 个工具并使用基于PostgreSQL的checkpoint存储LangGraph 的状态持久化与恢复。1.2 核心问题整条链路绑在一个智能体上从问候、FAQ到任务 Alpha工具与推理密集、任务 Beta同样工具与推理密集全部由同一智能体处理。系统提示词臃肿必须把各类任务的指令都塞进同一份 prompt。没有缓存策略。简单任务例如条目结构生成也由Claude Sonnet承担。总体问题可以概括为用推土机堆沙堡——能力与成本严重错配。1.3 采取的优化通过下列相对基础到中等复杂度的改造单次操作总成本约节省70%拆分 Agent Alpha 与 Agent Gamma以及后续的 Delta 等见下文。实现提示缓存Prompt Caching采用5 分钟滚动窗口与供应商对「缓存命中」的时间窗策略一致具体计费以各云文档为准。将部分小任务下沉为工具tools工具内部改用更小、更便宜的模型例如Gemini 2.5 Flash完成。把系统改为多智能体 人工设计的查询路由manual query routing由一次有上下文感知的路由调用决定应调用哪个智能体。「Hi」这类用户输入不再进入带着2 万 token 系统提示的重型智能体后续不需要强推理的追问也由更便宜的模型侧智能体处理。4. 可量化结果LLM 成本平均下降约70%–75%。本应更快的查询比预期更快。5. 最终架构最终形态为路由层 → 多个专用智能体不同模型与 prompt 体量→ 按需工具与小模型。具体拓扑见原文中的Final Architecture示意图。2 深入细节2,1 问题单体智能体如何成为瓶颈当系统要服务多种流程却仍用一个智能体包揽一切时这在生产里几乎是红旗信号。下面用我们当时的系统说明。每条用户查询都走同一个Agent 循环。智能体必须带巨大的系统提示词因为要覆盖多种任务类型。只说「Hi」的消息和「请执行下列任务」的消息被送进同一个Agent——在生产系统里这本不该发生。分析后发现智能体效果不差但花的钱远超合理范围。优化分阶段如下。1按任务域拆分智能体智能体同时在做Task Alpha与Task Beta二者几乎无关、无重叠却导致执行 Task Alpha 时Task Beta 的指令与工具仍被加载进上下文被 LLM无谓地处理。解法拆成两个智能体分别只服务 Task Alpha 与 Task Beta对外可分别暴露或通过路由统一入口。改完后每条路径上的 prompt 与工具集更窄固定开销显著下降。2提示缓存Prompt Caching拆分后 token 用量仍然偏高下一步是Prompt Caching。这是简单但非常有效的「省油」手段多数 LLM 供应商支持在一定时间窗内对已处理过的前缀 token收取更低的费用——例如2 万 token的系统提示在5 分钟内走了100 次通常只有首次或按文档规则按全价计其余命中缓存时单价大幅下降。官方参考Anthropic Claude Prompt Caching。改完后拓扑可不变但账单会明显下降。工程上需关注缓存键、可缓存块的位置一般把稳定长前缀放在前部、以及TTL/滚动窗口与业务会话长度是否匹配。3任务分解 小模型进工具进一步分析发现部分子任务不需要 Sonnet 4.5 级别的推理能力。做法是把这些步骤拆成工具工具实现里调用更小模型完成任务例如结构化生成、格式转换、轻量分类等。补充工程视角「工具内用小模型」本质是能力分层编排仍可由强模型或规则完成但高吞吐、低认知负荷的步骤固定到便宜模型避免在 ReAct 循环里每一步都烧最贵档位。4再拆问候 / FAQ / 支持与「任务后追问」仍有问题问候、用户支持、或 Alpha/Beta 完成后的简单追问若仍进入 Agent Alpha 或 Betatoken 与单价依然偏高。进一步拆分Agent Gamma专门处理问候、FAQ、用户支持。Agent Delta专门处理Task Alpha 完成后的后续追问轻量、跟随型对话。拆智能体本身不难难在由谁决定在何时调用哪一个智能体——不可能给每个智能体各做一个独立用户界面。解法实现Query Router查询路由器——一次单轮single-shot、有上下文感知的 LLM 调用唯一职责是理解当前请求意图并决定应路由到哪个下游智能体。Gamma 与 Delta不需要复杂图编排可以选择用类似Pydantic AI搭建这类轻量智能体。将单体改为手工编排的多智能体系统后单次请求成本约再降75%–80%相对优化前与全文「约 70%」为不同口径下的表述均以原文为准整体是可观的改进。补充与 LangGraph 的关系LangGraph 适合有环、有状态、多步工具调用的复杂工作流对单轮分类/路由 少量结构化输出轻量框架往往更省事。生产上常见做法是「图编排重任务 轻量 handler轻任务」混合架构而不是「所有盒子都用同一种图引擎」。3 什么时候该用 AI 智能体什么时候不该智能体很强但也贵、复杂、且常被滥用。最大的架构误区之一是把每一个AI 需求都当成「智能体问题」。在动手前要先想清楚智能体到底是什么。3.1 智能体 ≠ 单次 LLM 调用智能体通常指一套能对任务进行推理决定采取哪些动作使用工具维护上下文或状态执行多步工作流的系统。正是这种自主性带来能力也带来成本。并非每个问题都需要这一整包能力。3.2 什么时候你不需要AI 智能体许多事可以用更简单、更便宜的方式解决。单步变换输入 → 输出一步搞定、无需分支与工具编排时一次 LLM 调用往往足够。不需要路由、不需要编排、不需要「智能体壳子」——硬套只会增加开销。确定性工作流若执行步骤事先完全确定用传统代码或固定 DAG 即可不必让模型在每一步「再发明一遍流程」。结构化操作对已知 schema的数据做确定性格式处理传统代码往往更稳、更便宜不需要「开放式推理」时不必上智能体。高频、低复杂度请求智能体单次请求 overhead更高。问候、FAQ 等应优先轻量方案或更小模型全程走「满配智能体」会急剧放大 token 与费用。3.3 什么时候你需要AI 智能体当任务涉及推理、决策与动态执行时智能体更有价值。多步且相互依赖的工作流需要规划与动态调整顺序时智能体更合适。工具使用与编排要与多个 API、外部系统交互并需按需选工具、处理失败与重试时智能体提供编排能力。需要推理链的任务无法靠单次 prompt 直接得到可靠答案时推理循环有助于提高正确率需在成本与延迟上设上限。输入高度不可预测用户意图与所需步骤无法预先穷举时智能体比固定流程更灵活。3.4 权衡能力 vs 成本智能体带来灵活性也带来更高的token 用量更高的延迟更复杂的架构与运维更难调试与回归因此架构选择至关重要。目标不是「到处都用智能体」而是只在真正需要自主推理与动态编排的地方使用智能体。