1. 基本认知一般来说Token 总成本可概括为总消耗 ≈ API 调用次数 × 单次上下文规模 × 模型单价优化需同时作用于调用次数、上下文体积和模型选型三者缺一不可。仅精简 Prompt 措辞收益有限。2. 架构层2.1 选用与任务复杂度匹配的架构架构层级越高Token 消耗通常呈倍数增长。应遵循「最小够用」原则任务类型推荐架构应尽量避免分类、摘要、翻译单次 LLM 调用ReAct / 多 Agent固定业务流程工作流图少量 LLM 节点开放式 Agent 循环需调用工具但步骤有限单轮或少量 Tool Call长链 ReAct知识问答传统 RAG1–2 次调用Agentic 多轮检索开放复杂任务ReAct设步数上限多 Agent 协作核心判断在引入 Agent 之前先确认单次调用或固定工作流是否足以完成任务。2.2 多 Agent 改单 Agent 多工具多 Agent 架构中各角色往往携带独立 System Prompt并在 Agent 间传递完整中间结果导致上下文在多套 Prompt 间重复计费。在多数业务场景下单Agent配合语义化工具集即可满足需求。多 Agent 仅适用于必须并行执行或上下文必须严格隔离的场景。2.3 规则与小模型前置强模型后置在请求进入主链路前通过规则引擎、关键词匹配或小模型完成意图识别、任务分流、是否需检索等判断。简单任务直接走模板或小模型复杂任务再进入 Agent 或强模型。该分级路由将高单价模型的调用集中在真正需要推理的环节。2.4 合并步骤减少循环轮次在 ReAct 等循环架构中每多一轮历史轨迹都会进入后续上下文。应将可在工具内部完成的操作搜索 阅读 摘要合并为单一工具调用或通过 API 聚合减少往返次数。减少一步循环往往比压缩数百 Token 的 Observation 更具成本效益。3. Prompt 与上下文3.1 精简并稳定 System Prompt删除冗余说明、重复示例和过长 Few-shot将稳定内容置于 Prompt 前端以利于缓存对Prompt做版本管理避免无意义变动导致缓存失效。稳定、精简的 System Prompt 既降低单次成本也提升缓存命中率。3.2 抑制冗长的推理输出在 Agent 场景中应约束模型保持简短思考禁止复述 Observation 或重复用户已提供的信息。冗长的 Chain-of-Thought 会在多轮循环中被反复带入上下文造成显著膨胀。3.3 采用结构化输出工具调用与中间决策宜使用 JSON 等结构化格式替代叙述性推理文本。结构化输出 Token 更少解析更可靠也有利于后续自动化处理。3.4 动态注入避免全量上下文每轮仅注入与当前意图相关的规则、知识和状态而非完整用户画像或全量业务文档。结合Scratchpad一般指给大模型 / 智能体用的临时工作区中已知结论避免在消息历史中重复堆叠相同信息。4. 工具与 API 层4.1 动态加载工具子集工具定义Schema在每轮请求中都会占用上下文。应按意图分类后每次仅暴露 3–5 个相关工具而非一次性暴露全部工具集。4.2 精简 Tool Schema工具描述应简洁明确功能相近的工具宜合并去掉模型不需要的可选参数对外暴露语义化接口内部再对接 GraphQL、REST 等复杂 API。4.3 Observation 摘要化原文存入Scratchpad工具返回的大体积数据如完整 JSON、日志、文档不应全文进入消息历史。应提取 200–500 Token 的结构化摘要进入 Observation完整数据存入 Scratchpad 或外部存储按需再取。这是 ReAct 类架构中最重要的单项优化之一Observation会出现在后续每一轮的上下文中。4.4 API 返回最小必要字段在REST中使用字段过滤或专用摘要接口在 GraphQL中使用固定模板查询避免模型自由构造贪婪查询在SQL中只查询必要列并设置LIMIT。4.5 批处理替代循环调用将多次单条查询合并为一次批量请求如get_users(ids[...])减少工具调用次数及相应的 Thought-Action-Observation轨迹。5. 上下文与记忆管理5.1 滑动窗口与早期摘要当 Agent步数较多时对早期历史做压缩摘要仅保留最近若干步的完整轨迹。摘要本身可用小模型生成以控制成本。5.2 Scratchpad 替代历史堆砌用结构化工作区记录已确认的事实用户 ID、订单号、查询结论等替代在消息历史中反复携带相同信息。模型只需引用 Scratchpad无需重复阅读冗长历史。5.3 固定置顶用户目标在多轮交互中将原始用户意图固定在上下文前端既减少任务漂移也避免模型在推理中反复复述任务描述。6. RAG 专项6.1 少而准的检索策略Top-K建议3–5配合 RerankChunk大小建议256–512Token检索轮数以 1 次为主最多2次。盲目增大K值或Chunk会线性推高输入成本。6.2 两阶段检索先召回标题或摘要层低成本再对Top结果做全文精读高成本避免一次性注入大量完整Chunk。6.3 上下文压缩检索到Chunk后用小模型或规则抽取与问题直接相关的句子再注入生成 Prompt剔除无关段落。6.4 离线构建层级索引对知识库预建摘要层如 RAPTOR、LLM Wiki在线查询时先读摘要按需下钻详情避免一次塞入过多Chunk。7. 护栏与成本工程7.1 设置硬性上限对Agent循环、单次输出、Observation长度、单任务Token预算设置明确上限如max_steps5–8防止失控循环。7.2 重复调用与无进展检测对相同工具与参数的重复调用、连续多步Scratchpad 无变化等情况做检测及时终止或转人工避免无效循环。7.3 模型分级路由分类、摘要、压缩等步骤使用小模型工具选择与ReAct循环使用中等模型最终回答与复杂推理使用强模型。7.4 Prompt Caching 与响应缓存将稳定的 System Prompt、工具定义、政策文档等置于 Prompt 前端并保持版本一致以利用各厂商的前缀缓存降价。对高频、确定性查询在应用层做响应缓存实现零LLM调用。8. 核心原则AI 场景中节省 Token可归纳为5条少调用能不用Agent就不用能合并步骤就合并能批处理就不循环。少体积摘要Observation,精简Prompt与Schema, API只返回必要字段。少重复用 Scratchpad 和缓存替代上下文中反复出现的内容。少滥用简单任务交给规则与小模型强模型只用于关键推理。可度量按步骤记录Token消耗优先优化Observation最大、步数最多的任务类型。Token 优化不是一次性调整 Prompt而是架构选型、工具设计、上下文工程与成本工程的系统工程。架构与信息组织方式对成本的影响通常远大于对措辞的局部修改。 如果本文对你有帮助欢迎点赞、收藏、关注我会持续分享更多技术干货
如何节省AI Token成本
1. 基本认知一般来说Token 总成本可概括为总消耗 ≈ API 调用次数 × 单次上下文规模 × 模型单价优化需同时作用于调用次数、上下文体积和模型选型三者缺一不可。仅精简 Prompt 措辞收益有限。2. 架构层2.1 选用与任务复杂度匹配的架构架构层级越高Token 消耗通常呈倍数增长。应遵循「最小够用」原则任务类型推荐架构应尽量避免分类、摘要、翻译单次 LLM 调用ReAct / 多 Agent固定业务流程工作流图少量 LLM 节点开放式 Agent 循环需调用工具但步骤有限单轮或少量 Tool Call长链 ReAct知识问答传统 RAG1–2 次调用Agentic 多轮检索开放复杂任务ReAct设步数上限多 Agent 协作核心判断在引入 Agent 之前先确认单次调用或固定工作流是否足以完成任务。2.2 多 Agent 改单 Agent 多工具多 Agent 架构中各角色往往携带独立 System Prompt并在 Agent 间传递完整中间结果导致上下文在多套 Prompt 间重复计费。在多数业务场景下单Agent配合语义化工具集即可满足需求。多 Agent 仅适用于必须并行执行或上下文必须严格隔离的场景。2.3 规则与小模型前置强模型后置在请求进入主链路前通过规则引擎、关键词匹配或小模型完成意图识别、任务分流、是否需检索等判断。简单任务直接走模板或小模型复杂任务再进入 Agent 或强模型。该分级路由将高单价模型的调用集中在真正需要推理的环节。2.4 合并步骤减少循环轮次在 ReAct 等循环架构中每多一轮历史轨迹都会进入后续上下文。应将可在工具内部完成的操作搜索 阅读 摘要合并为单一工具调用或通过 API 聚合减少往返次数。减少一步循环往往比压缩数百 Token 的 Observation 更具成本效益。3. Prompt 与上下文3.1 精简并稳定 System Prompt删除冗余说明、重复示例和过长 Few-shot将稳定内容置于 Prompt 前端以利于缓存对Prompt做版本管理避免无意义变动导致缓存失效。稳定、精简的 System Prompt 既降低单次成本也提升缓存命中率。3.2 抑制冗长的推理输出在 Agent 场景中应约束模型保持简短思考禁止复述 Observation 或重复用户已提供的信息。冗长的 Chain-of-Thought 会在多轮循环中被反复带入上下文造成显著膨胀。3.3 采用结构化输出工具调用与中间决策宜使用 JSON 等结构化格式替代叙述性推理文本。结构化输出 Token 更少解析更可靠也有利于后续自动化处理。3.4 动态注入避免全量上下文每轮仅注入与当前意图相关的规则、知识和状态而非完整用户画像或全量业务文档。结合Scratchpad一般指给大模型 / 智能体用的临时工作区中已知结论避免在消息历史中重复堆叠相同信息。4. 工具与 API 层4.1 动态加载工具子集工具定义Schema在每轮请求中都会占用上下文。应按意图分类后每次仅暴露 3–5 个相关工具而非一次性暴露全部工具集。4.2 精简 Tool Schema工具描述应简洁明确功能相近的工具宜合并去掉模型不需要的可选参数对外暴露语义化接口内部再对接 GraphQL、REST 等复杂 API。4.3 Observation 摘要化原文存入Scratchpad工具返回的大体积数据如完整 JSON、日志、文档不应全文进入消息历史。应提取 200–500 Token 的结构化摘要进入 Observation完整数据存入 Scratchpad 或外部存储按需再取。这是 ReAct 类架构中最重要的单项优化之一Observation会出现在后续每一轮的上下文中。4.4 API 返回最小必要字段在REST中使用字段过滤或专用摘要接口在 GraphQL中使用固定模板查询避免模型自由构造贪婪查询在SQL中只查询必要列并设置LIMIT。4.5 批处理替代循环调用将多次单条查询合并为一次批量请求如get_users(ids[...])减少工具调用次数及相应的 Thought-Action-Observation轨迹。5. 上下文与记忆管理5.1 滑动窗口与早期摘要当 Agent步数较多时对早期历史做压缩摘要仅保留最近若干步的完整轨迹。摘要本身可用小模型生成以控制成本。5.2 Scratchpad 替代历史堆砌用结构化工作区记录已确认的事实用户 ID、订单号、查询结论等替代在消息历史中反复携带相同信息。模型只需引用 Scratchpad无需重复阅读冗长历史。5.3 固定置顶用户目标在多轮交互中将原始用户意图固定在上下文前端既减少任务漂移也避免模型在推理中反复复述任务描述。6. RAG 专项6.1 少而准的检索策略Top-K建议3–5配合 RerankChunk大小建议256–512Token检索轮数以 1 次为主最多2次。盲目增大K值或Chunk会线性推高输入成本。6.2 两阶段检索先召回标题或摘要层低成本再对Top结果做全文精读高成本避免一次性注入大量完整Chunk。6.3 上下文压缩检索到Chunk后用小模型或规则抽取与问题直接相关的句子再注入生成 Prompt剔除无关段落。6.4 离线构建层级索引对知识库预建摘要层如 RAPTOR、LLM Wiki在线查询时先读摘要按需下钻详情避免一次塞入过多Chunk。7. 护栏与成本工程7.1 设置硬性上限对Agent循环、单次输出、Observation长度、单任务Token预算设置明确上限如max_steps5–8防止失控循环。7.2 重复调用与无进展检测对相同工具与参数的重复调用、连续多步Scratchpad 无变化等情况做检测及时终止或转人工避免无效循环。7.3 模型分级路由分类、摘要、压缩等步骤使用小模型工具选择与ReAct循环使用中等模型最终回答与复杂推理使用强模型。7.4 Prompt Caching 与响应缓存将稳定的 System Prompt、工具定义、政策文档等置于 Prompt 前端并保持版本一致以利用各厂商的前缀缓存降价。对高频、确定性查询在应用层做响应缓存实现零LLM调用。8. 核心原则AI 场景中节省 Token可归纳为5条少调用能不用Agent就不用能合并步骤就合并能批处理就不循环。少体积摘要Observation,精简Prompt与Schema, API只返回必要字段。少重复用 Scratchpad 和缓存替代上下文中反复出现的内容。少滥用简单任务交给规则与小模型强模型只用于关键推理。可度量按步骤记录Token消耗优先优化Observation最大、步数最多的任务类型。Token 优化不是一次性调整 Prompt而是架构选型、工具设计、上下文工程与成本工程的系统工程。架构与信息组织方式对成本的影响通常远大于对措辞的局部修改。 如果本文对你有帮助欢迎点赞、收藏、关注我会持续分享更多技术干货
