Token 消耗问题

从个人 Web 聊天工具出发，溯源至 Agent 记忆架构的本质矛盾

---

一、起因：我想做一个本地 AI 聊天页面

出发点很简单——搭建一个精美的个人 Web 前端，通过配置各家大模型 API 进行对话，聊天记录保存在浏览器 localStorage 中。

这个方案的底层逻辑是：

用户发送第 N 条消息时：
历史消息 [1, 2, 3, ... N-1] + 新消息 [N]
        ↓ 全部打包
    发送给 API
        ↓
    获得回复

看起来合理，但这里埋下了第一个隐患。

---

二、问题显现：全量发送带来的三个真实槽点

2.1 上下文窗口会被撑爆

每个模型都有 token 上限（如 GPT-4o 为 128K）。随着对话增长，历史消息会逐渐逼近上限。超出后要么 API 报错，要么框架静默截断前面的消息——模型"失忆"，但你毫不知情。

2.2 费用随对话长度线性增长

对话轮次	每次实际发送的 token 量
第 1 条	~100 tokens
第 10 条	~1,000 tokens
第 50 条	~5,000 tokens
第 100 条	~10,000 tokens

每一轮对话，你都在为所有历史记录重复付费。

2.3 幻觉没有减少，反而更危险

本地存储只是让你看到了历史，但模型本身无任何跨会话记忆。长对话中，模型会开始"发明"之前说过的内容，或前后矛盾——这是基础大模型架构决定的，与存储方案无关。

---

三、延伸：OpenClaw 等 Agent 框架解决了什么？

面对上述问题，以 OpenClaw 为代表的 Agent 框架提出了"养虾"的概念——让 AI 拥有持久记忆、自主执行能力、感知时间与习惯。

其底层记忆架构如下：

传统聊天方案（全量发送）：
  历史消息全部 → 塞进 Context → 发给 API

OpenClaw 的记忆方案（RAG 式检索）：
  历史消息全部 → 向量化 → 存入外部数据库
                              ↓
  新消息到来 → 检索最相关的 N 条记忆
                              ↓
              只发这 N 条 + 当前消息 → API

核心改进：从「全量重发」变为「按需检索」，token 消耗从线性增长趋向近似恒定。

---

四、本质矛盾：记忆从未真正存在于模型中

这是整个问题链条的核心结论：

OpenClaw 解决的不是「记忆要重发」的问题，
而是把「重发所有记忆」优化成了「重发相关记忆」。
模型本身仍然是无状态的，每次都在向一个失忆的大脑重新描述它的过去。

无论包多少层 Agent 框架，底层永远是 Claude / GPT / Gemini，而它们：

• ❌ 没有跨对话的原生记忆
• ❌ 不知道"昨天"发生了什么
• ❌ 每次推理都是全新的开始

所谓"记忆"，只是外部数据库检索后注入 Context 的文本片段，模型只是在"阅读笔记"，而非"真正记得"。

---

五、OpenClaw 记忆机制的新增成本与风险

解决了旧问题，但引入了新的隐患：

5.1 记忆是有损压缩的

向量检索返回的是「相似度最高」的片段，不是「最重要」的片段。三个月的对话中，模型真正能"看到"的可能只有 20%，其余永久性地沉默。

5.2 检索本身会出错，产生更危险的幻觉

普通幻觉：模型凭空捏造。
检索幻觉：模型基于错误检索到的"历史记录"，言之凿凿地给出错误回答。

后者更难被发现，危害更大。

5.3 完整的 Token 成本结构

每次对话的实际费用 =
  检索到的历史记忆 tokens
  + 当前对话 tokens
  + 工具调用 tokens（执行任务时）
  + 记忆写入 tokens（对话结束后提炼存储，又是一次 API 调用）

比全量发送聪明，但远没有宣传的那么"轻"。

5.4 真实的失控风险

OpenClaw 拥有系统最高权限时，一旦指令理解偏差，后果不可逆。
（已有案例：Meta AI 安全总监的 200 封邮件被 OpenClaw 误删。）

---

六、结论与启示

结论总结

维度	本地 Web 聊天方案	OpenClaw Agent 方案
记忆机制	全量历史塞入 Context	向量检索注入 Context
Token 增长曲线	线性增长	近似恒定（但有基础损耗）
幻觉风险	存在，普通幻觉	存在，检索幻觉更隐蔽
数据安全	localStorage，有丢失风险	依赖外部存储，有权限风险
本质局限	模型无记忆，框架无法改变	模型无记忆，框架无法改变

对 AI 应用工程师方向的启示

Token 消耗、记忆管理、上下文压缩，是当前 Agent 工程里最没有被完美解决的问题，也是最有技术含量的研究方向：

• 记忆分层：哪些记忆值得长期保存？哪些可以压缩？哪些可以丢弃？
• 上下文压缩算法：如何在不损失关键信息的前提下缩减 token 用量？
• 检索质量评估：如何量化和提升记忆检索的准确性（RAGAs 等框架）？

理解这些底层矛盾，是从"会调 API"走向"真正懂 Agent 工程"的分水岭。