Token 经济是上下文治理的财务管理

2024 年秋，一家 AI 初创公司的 CTO 收到了一份令人窒息的月度账单：他们的 AI 客服智能体仅在一个地区就烧掉了 $8,200 的 API 费用，而其中近 40% 的开销并非用于解决实际问题，而是消耗在重复检索同一批历史对话、向模型塞入未压缩的冗长摘要，以及对永远不会被再次访问的对话生成 embeddings。当技术团队开始拆解 token 消耗日志时，他们发现了一个残酷的事实：智能体的“记忆”本身，已然成为系统中最昂贵的一个组件。

这就触及了上下文治理中最少被讨论、却最直接影响商业可持续性的维度：Token 经济。所谓 Token 经济，不是去学习 LLM 的定价表那么简单，而是把每一次记忆操作（写入、检索、摘要、压缩、注入上下文）都视为一笔在有限预算约束下的财务决策。你需要回答三个问题：这笔记忆操作会消耗多少 token？它的边际收益是否配得上这笔开销？有没有更便宜的替代方案？

本章将为你建立起一套可落地的记忆成本核算与优化框架。我们将从计算每种记忆层的边际成本开始，然后设计一个动态上下文预算分配器，最后引入缓存、批处理与投机解码等高级节省策略。你读完之后，应该能精算出每一次 Retrieval-Augmented Generation（RAG）、每一段对话摘要的 token 开销，并能在记忆质量与财务健康之间找到系统性的最优解。

计算每种记忆层的边际成本

智能体的记忆不是一个单一块，而是由分层结构构成：即时历史（Working Memory）、摘要记忆（Summary Memory）、检索记忆（Retrieval Memory）和外部知识库（External Knowledge）。在财务管理视角下，每一层都有明确的获取和维护成本，而且这些成本会随着时间、对话长度、检索频率呈非线性增长。

首先要建立一个核心认知：LLM 的定价是非对称的。截至当前调研资料，OpenAI GPT-4o 的输入 token 定价为 $0.0025/1K tokens，而输出 token 是 $0.0100/1K tokens——输出比输入贵了 4 倍。这意味着“让模型自己写一份摘要”这项看似简洁的操作，实际上比“把原始对话直接塞进上下文”（仅消耗输入 token）要昂贵得多。摘要的记忆价值必须能覆盖这 4 倍的溢价。

以下是四种典型记忆操作的边际成本拆解：

这些数据并非固定不变。根据 OpenAI 的定价说明，不同模型之间的定价差异极大：一个更先进的模型在长上下文任务上可能表现更好，但其单 token 成本可能是基础模型的 2 倍。因此，上述成本估算必须对应到你实际使用的模型上，并在每次模型升级或切换时重新校准。

边际成本的累积效应

一个容易被忽视的事实是：记忆操作的成本不是线性叠加的，而是在每一次 LLM 推理中被“重复计费”的。例如，你为某次对话生成了一份 200 token 的摘要，这份摘要会在后续 10 轮对话中一直被注入上下文。那么这份摘要的真实成本 = 生成成本（包含输入+输出） + 10 次 × 200 token 的推理输入成本。如果这 10 次推理中只有 2 次真正用到了摘要中的信息，那么这份记忆的 ROI 就非常低。

因此，在量化记忆成本时，必须引入一个复用系数（Reuse Factor）指标：

记忆操作的真实成本 = 获取成本 + （复用次数 × 单次注入成本）

只有当复用次数足够高，或者单次注入成本足够低时，一份记忆才是经济上合理的。这也就引出了下一个关键组件：如何动态决定“这份记忆值不值得携带”。

动态上下文预算分配器

在实际运行中，智能体的上下文窗口（Context Window）既是记忆的载体，也是 token 预算的硬边界。GPT-4o 的 128K 上下文窗口看起来很大，但如果你同时注入：系统提示（1,000 tokens）、最近 20 轮对话（8,000 tokens）、3 份检索文档片段（4,500 tokens）、一份摘要（200 tokens）、工具调用结果（2,000 tokens）——你会发现可用空间已经所剩无几。而且请注意：所有这些内容都是按输入 token 全额计费的，即使模型在推理时并未“关注”其中的某些部分。

动态上下文预算分配器的设计目标非常明确：在每一次 LLM 推理前，根据任务类型和剩余 token 预算，自动调整各个记忆模块的注入量。它是一个调度器，而不是一个硬编码的规则集。

分配器的工作流程

以下是一个可落地的分配器逻辑，可以用 30 行以内的 middleware 代码实现：

1. 任务类型分类：

   • 闲聊/简单问答：记忆需求低，摘要+少量检索即可
   • 深度推理：需要完整历史+多源检索
   • 工具调用：需要当前上下文+工具参数，历史记忆非必要

2. 预算上限设定：例如，设定单次推理的上下文输入上限为 8,000 tokens（而非窗口上限 128K），留出空间给模型输出和未知变量。

3. 优先级队列（按重要性从高到低）：

   • 系统提示：固定分配，不可裁剪
   • 当前任务输入：用户最新消息 + 工具结果
   • 即时历史：最近 3–5 轮对话（截断而非全量）
   • 检索记忆：按相关性排序后，限制最多 2 条
   • 摘要记忆：仅当检测到主题切换或关键信息缺失时才注入
   • 外部知识：仅在任务类型判定为“知识密集型”时触发

4. Token 计数与裁剪：

   • 每次组装上下文前，使用 tiktoken 或模型原生 tokenizer 统计当前总 token 数
   • 如果超出预算，从优先级最低的模块开始逐条裁剪
   • 裁剪时记录日志，供后续评估记忆策略的有效性

预算分配决策示例

上述估算基于研究材料中的换算关系：1 token ≈ 4 个英文字符，1 页文字 ≈ 1,000 tokens。在实际代码中，你需要通过 response.usage.prompt_tokens 来获取精确值，但这个估算法则能帮助你在设计阶段快速评估。

这个分配器的核心思维是 “None” 是一个合法的内存释放操作。很多时候，最经济的选择就是不注入任何记忆——模型仅凭系统提示和当前用户输入就能完成任务。每一条被省略的记忆，都是被节省下来的真金白银。

缓存、批处理与投机解码带来的节省

在前两节中，我们着眼于通过减少 token 消耗来控制成本。但还有另一条路径：让已经消耗过的 token 不再重复计费，或者让相同的 token 消耗带来更高的吞吐量。这就是缓存、批处理和投机解码发挥作用的地方。

1. LLM 缓存：不要让重复的记忆操作二次付费

如果你的智能体在处理用户消息时，每次都会重新检索相同的 top-k 文档片段，或者每次都为同一段对话生成一份完全相同的 summary，那么你就是在为完全相同的 token 反复付款。

语义缓存是目前最有效的策略之一。实现思路是：

• 对于检索操作，对 query 做哈希或对 embedding 做相似度匹配，如果检测到请求的 query 与近期已缓存 query 的相似度超过阈值（如 0.95），直接返回缓存的检索结果，绕过 embedding 生成和向量检索步骤。
• 对于摘要生成，缓存 (对话片段 hash → 摘要) 的键值对。当对话片段的增量变化小于 5% 时，复用旧摘要而非重新生成。

在 LangChain 生态中，这可以通过自定义 BaseCache 子类来实现，拦截 LLM 调用并在命中缓存时返回预设的 Generation 对象。即使你用的是其他框架，这个模式同样适用：在 LLM 调用的最外层加一个缓存层，记忆操作的成本是存储成本（便宜）而非推理成本（昂贵）。

以下是一份缓存策略的效果对比：

作者提醒：缓存的代价是内存与一致性。你必须设置过期策略（如 1 小时 TTL），并在对话发生实质性变化时主动失效缓存。一个脏缓存会直接导致记忆错误，而这种错误的排查成本远高于缓存省下的钱——这又回到了上一章的核心结论。

2. 批处理：用规模化摊薄固定开销

当你的智能体系统需要处理大量独立任务时（例如，为 1,000 个客户生成月度交互摘要），单条处理的 token 开销是相似的，但你可以通过批处理来节省连接开销、并发等待时间和潜在的批处理计费优惠。

许多 LLM 提供商在批处理模式下提供 原价 50% 的折扣。对于记忆操作而言，这意味着：

• 设置一个摘要任务队列，当累积到 50 个待生成摘要时，作为一批提交
• 对向量库的批量 embedding 操作使用异步批量 API（如 OpenAI 的 embeddings.create 支持传入数组）
• 将同一推理步骤中的多个独立检索请求合并为一次 multi-query 检索，减少 API 调用次数

3. 投机解码与 token 梯度利用

投机解码（Speculative Decoding）是一种在 LLM 推理层面节省时间而非 token 的技术，但它对记忆系统有间接的经济收益：更快的推理意味着在相同的时间窗口内可以完成更多轮记忆更新和检索，从而提高了记忆系统的吞吐量，摊薄了固定资源成本。

不过，在当前调研资料范围内，投机解码的 token 消耗与传统解码相同（因为模型仍然生成相同数量的输出 token），因此它不能直接减少计费 token 数，但可以在实时性要求高的场景下减少因延迟而引入的额外重试开销。

综合结论与落地步骤

从上述分析可以得出一个核心结论：记忆操作的成本并非一成不变，而是取决于你选择在什么时候、以何种方式、携带多少信息进入 LLM 的上下文。Token 经济提供了衡量这个“何时/何种/多少”的通用货币。

以下是三种常见的记忆财务策略对比：

落地清单（由简到繁，建议依次实施）：

1. 打开 token 追踪：在每次 LLM 调用后记录 usage 对象，按任务类型分组统计。你无法管理你看不见的东西。
2. 实施上下文 token 上限：在 assembler 函数中加入总 token 计数器，设定硬性预算上限（如 8,000 tokens），超出即截断。
3. 引入复用系数的概念：对每一条注入上下文的记忆对象（摘要、检索片段），评估它的真实复用次数，淘汰低效携带。
4. 部署缓存层：优先对 embedding 和摘要生成加缓存，这两个环节的命中率最高、实现成本最低。
5. 用 tiktoken 做精确计量：不要依赖“估算”，在代码中用 tiktoken 在每次注入前精确计数，这比依赖 API 返回的截断错误更可靠。

下一章，我们将把视角从“记忆花了多少钱”转向“记忆能跑多快”。

当你的记忆系统从单体实例扩展到数十万智能体并行运行时，成本控制只是基础，你还会面临检索延迟的抖动、向量索引的写入瓶颈和跨节点的记忆一致性问题。在《大规模记忆系统的性能调优》中，我们将进入索引优化、分片策略和流水线设计的世界，让记忆系统在保持经济性的同时，也能支撑起生产级的吞吐量。