1. 基本认知

一般来说Token 总成本可概括为：

总消耗 ≈ API 调用次数 × 单次上下文规模 × 模型单价

优化需同时作用于调用次数、上下文体积和模型选型，三者缺一不可。仅精简 Prompt 措辞，收益有限。

2. 架构层

2.1 选用与任务复杂度匹配的架构

架构层级越高，Token 消耗通常呈倍数增长。应遵循「最小够用」原则：

任务类型	推荐架构	应尽量避免
分类、摘要、翻译	单次 LLM 调用	ReAct / 多 Agent
固定业务流程	工作流图（少量 LLM 节点）	开放式 Agent 循环
需调用工具但步骤有限	单轮或少量 Tool Call	长链 ReAct
知识问答	传统 RAG（1–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（配合 Rerank）；Chunk大小建议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_steps=5–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，而是架构选型、工具设计、上下文工程与成本工程的系统工程。架构与信息组织方式对成本的影响，通常远大于对措辞的局部修改。