AIClaw 3.7.13：上下文估算与供应商用量分离

长时间运行的 Agent 会话会不断累积文本、工具调用结果和决策记录。上下文计量表能帮助开发者理解这种增长，但一个孤立的百分比往往容易被误读——它到底是当前历史的估算值、供应商最后一次报告的输入计数，还是累计计费总额？AIClaw 在 3.7.13 版本中通过将这三个数值显式分离，给出了一个更清晰的答案。

三种含义不同的读数

v3.7.12 首次引入了上下文检查面板，v3.7.13 则将其入口移至底部工具栏、紧邻模型选择器。面板将以下三个值分开呈现：

• 当前文本与工具估算：对会话当前消息和可用工具定义量的近似值。
• 配置的上下文窗口与预估剩余空间：由模型配置提供的容量，剩余空间基于估算值计算。
• 供应商最新报告输入 token：运行时最近一次输入用量读数，与估算值分开显示。

估算器会统计消息文本、每条消息的少量额度、工具调用名称与参数，以及序列化后的工具 schema。图像字节被排除在外，状态中会单独提示是否存在图像。它使用的是既有的字符启发式规则——约每 4 个 ASCII 字符对应一个 token，每个非 ASCII 字符对应一个 token，这并非所选模型的真实分词器。因此估算值可能与供应商用量存在偏差，也不包含视觉 token。

举例说明：若配置窗口为 100,000 token，估算值为 40,000 token，则剩余空间约为 60,000 token。供应商报告的 38,000 不会替代该估算值，而这些数字中任何一个都不是累计账单。

什么是 token？ token 是大语言模型处理文本的基本单位，既不是字符也不是单词，而是介于两者之间的子词片段。不同模型使用不同的分词器（tokenizer），同一段文本在不同模型下可能产生不同数量的 token。例如英文中 "unbelievable" 可能被拆成 "un"+"believ"+"able" 三个 token，而常见词如 "the" 通常只占一个。中文通常每个汉字占一至两个 token。因此，文章提到的"每 4 个 ASCII 字符约等于 1 个 token"只是一种粗略的字符启发式估算，与任何特定模型的真实分词结果都存在系统性偏差。这也是为什么面板要把估算值与供应商报告的实际 token 数分开呈现——后者是该模型分词器处理后的精确读数，前者只是用于快速判断上下文压力的近似值。

未知容量保持未知

当配置窗口为正数时，面板才会计算百分比。缺少该配置时，它会显示未知状态，并省略剩余空间计算和进度条。状态请求失败时，界面显示数据不可用，而不是编造用量。

供应商用量也有自己的缺失数据状态。成功压缩后会重置此前的输入读数，避免将旧请求显示为新压缩历史后的输入大小。面板是检查辅助工具，而非下一次请求一定放得下的保证。

压缩记录保留有界历史

当成功的非空摘要替换历史后，运行时会尝试保存压缩前后的时间戳和文本估算值。若请求失败或摘要为空，则该记录不会推进。若元数据保存失败，运行时会给出提示；成功摘要不代表其记录一定被保存。

持久化历史保留累计计数和最近 50 条记录，这些条目在会话恢复后仍可访问。记录从 v3.7.12 引入该功能时开始，更早的压缩不会被猜测性重建。压缩前后的对比描述的是估算的上下文大小，并不衡量摘要质量、不能证明所有事实都被保留，也不报告生成摘要所计费的 token。

上下文压缩（compaction） 是长会话 Agent 的常见机制：当累积的对话历史接近模型上下文窗口上限时，运行时调用模型对早期消息生成摘要，用这段摘要替换原始文本，从而释放空间。压缩是有损的——原始的工具调用细节、中间推理步骤和措辞都会丢失，只保留摘要所捕获的要点。因此压缩前后的"文本估算值对比"仅反映上下文大小的缩减，并不代表信息被无损保留。这也是 AIClaw 强调记录"不衡量摘要质量"的原因：一个压缩后估算值大幅下降的会话，可能恰恰是摘要丢失关键细节的信号，而面板本身无法判断这一点，需要开发者自行审查摘要内容。

元数据跨越接口，而非对话内容

session/context 处理器要求存在已恢复的会话，并返回上下文状态结构。响应包含模型、用量字段以及压缩元数据，而非消息正文、提示词文本或工具载荷。渲染器在会话信息变化时及相关完成事件后重新加载状态，其请求代际和会话检查可防止来自其他聊天的延迟响应替换当前显示。

v3.7.13 用 24px 圆环取代了文本区域上方的独立行。悬停可显示估算百分比或未知状态，点击可在工具栏上方展开详情。刷新、关闭和键盘访问功能均保留，压缩控件也带有无障碍标签。

session/context 处理器与请求代际：在 Electron 等桌面应用中，渲染进程（界面）与主进程（运行时）通过 IPC 通道通信。session/context 处理器是主进程暴露的一个接口，只返回元数据（模型名、用量字段、压缩记录），不返回消息正文或提示词，这既是隐私边界也是性能考量——元数据体量远小于完整对话。"请求代际"（request generation）是一种竞态防护模式：每次状态请求携带一个递增的序号，当响应返回时，渲染器检查其序号是否仍是当前最新的；若不是（说明用户已切换到其他会话并发起了新请求），则丢弃该响应，防止旧数据覆盖新界面。这在多会话快速切换时尤为重要。

测试验证了什么

上下文测试覆盖了估算与供应商用量的分离、图像字节排除、未知值、压缩成功与失败的区分，以及 55 条记录后持久化保留 50 条的行为。桌面冒烟测试使用真实 Vue/preload 界面配合固定装置响应，检查项包括压缩控件、工具提示、未知窗口行为、记录显示以及模型切换后的刷新。

v3.7.13 发布说明报告了 267 项渲染器/辅助测试和 133 项工作接口检查通过，这些是套件总数而非仅上下文测试。发布工作流成功完成。发布说明同时指出，本次布局变更未重新运行实时模型场景；固定装置检查并不能确立分词器准确性或摘要质量。

实践意义

这一改进的核心价值在于：开发者能够在检查上下文压力和近期压缩记录的同时，清楚看到每个数字的来源与局限。将估算值、配置容量和供应商报告用量分开展示，避免了将三种不同性质的读数混为一谈。对于依赖长会话 Agent 的团队而言，这种透明度有助于更准确地判断何时需要压缩、何时需要调整模型配置，以及何时该关注实际的计费数据。