其实，

Token 预算管理：长对话不崩溃的秘密

使用者痛点概述

痛点一：长对话中 Token 消耗迅速累积。导致 API 报错或模型“忘记”早期信息，回复质量骤降。

痛点二：每轮工具调用返回的大段文本占用大量 Token，手动裁剪会丢失关键上下文。

痛点三：不同模型大小不一致，开发者难以统一管理预算。

从问题来看，多轮推理的 Token 雪崩

ReAct 架构的主要是“推理‑行动‑观察”循环。每一比如轮循环，AI 调用工具。还有拿到结果，再有把结果追加到消息历史中。一个复杂任务可能跑十几轮甚至几十轮，每轮的工具结果动辄几千 tokens。

因为轮次增加。消息历史不断膨胀，总 Token 量逼近模型的上限。一旦超限，要么 API 直接报错。要么模型开始“遗忘”早期的对话内容——质量断崖式下跌。

AI Helper 用一套 Token 预算管理程序来解决这个问题。其实，

预算模型

得搞清楚“还有多少 Token 可以用”。AI Helper 的计算方式：

消息预算 = - 程序提示词 - 工具定义 - 输出预留 - 安全余量

实际代码中。程序提示词和工具定义的 Token 数是实时计算的，而非用固定值估算：

const actualSystemTokens = estimateTokens;const actualToolDefTokens = estimateTokens(
JSON.stringify(
tools.map(t => {
const { id,...clean } = t;return clean;})
)
)，const contextWindow = getContextWindow;reactTokenBudget =
contextWindow -
actualSystemTokens -
actualToolDefTokens -
// 输出预留
// 安全余量

预留 N tokens 给模型输出回答，再留 M tokens 安全余量。怎么说呢，剩下的才是消息历史可以用的预算。这个预算大致相当于的 %——所以也可以理解为“总预算 = × X”。

三级压力监测

每次 API 调用前，程序会估算当前消息的总 Token 数，与对比。得出压力等级：

export function assessContextPressure {
const ratio = usedTokens / budget;怎么说呢，if return { level: 'safe'。ratio }，// 安全
if return { level: 'warning',ratio };// 警告
return { level: 'critical',ratio };// 危险
}

• safe正常执行，无需干预。
• warning记录日志，准备压缩。
• critical或总预估超过 Z%立即触发动态裁剪，把消息裁到预算的 P%。

const pressure = assessContextPressure;if (
pressure.level === 'critical' ||
totalEstimate> contextWindow * CRITICAL_RATIO
) {
const targetBudget = Math.floor;const trimmed = trimMessagesByBudget(
currentMessages,Math.max
);// 执行裁剪
}

从压缩策略来看，不直接丢弃。先摘要

直接删除旧消息是最简单的做法，但会丢失上下文信息——AI 会忘记之前做了什么。AI Helper 的压缩策略是分阶段的：

策略一的观点是，引用内容自动压缩

User 在对话中引用网页内容、选中文本时这些片段往往非常肥大。AI Helper 限制引用内容最大 Token 数为 K

const MAX_QUOTED_CONTEXT_TOKENS = K;export function compressQuotedContext {
const tokens = estimateTokens;if {
return { compressed: ctx,wasCompressed: false };}
const truncated = truncateByTokens;return { compressed: truncated,wasCompressed: true };}

从策略二来看，增量摘要

当 Token 超标时程序会定位最旧的一轮“完整对话轮次”。调用轻量 API 将其压缩为一句话摘要：

// context-summarizer.js
export async function summarizeRound {
// 提取工具名称 + 主要参数 + 简要结果
const toolCallInfos = assistantMsg.tool_calls.map => {
const name = tc.function?.name || 'unknown';const argsStr = extractKeyParams;const resultSnippet = resultStr.substring;
return `Tool: ${name}
Result的观点是，${resultSnippet}`;})，说起来，const summaryPrompt = `Summarize execution of following tool calls in one sentence。extracting key findings:
${toolCallInfos.join}
No more than ${MAX_SUMMARY_CHARS} characters.`;// 调用轻量模型，仅返回 max_tokens=SUMMARIZE_MAX_TOKENS
}

摘要生成后用一条注入摘要的 user 消息替换原来的 assistant+tool 消息。信息没有彻底消失，只是被浓缩。话说回来，单次裁剪最多摘要 N 轮，以免耗时过长。

再看策略三，Token 级截断

针对单个工具结果过大时使用 truncateByTokens 保留头部 % 与尾部 %：

export function truncateByTokens {
const headTokens = Math.floor;其实，const tailTokens = maxTokens - headTokens;const headChars = tokenToChar;const tailChars = tokenToChar;const head = content.slice;const tail = content.slice;return `${head}
... ...
${tail}`;}

`truncateContentSmart` 根据内容类型智能选择保留策略：HTML 优先保留 ` `；JSON 保留顶层键结构；代码/文本采用头尾混合，

说到策略四，兜底权重裁剪

If 摘要后仍然超标。则进入权重裁剪阶段——按关键度删除消息：

// 消息权重示例
const getWeight = => {
if ) return WEIGHT_SUMMARY;if return WEIGHT_TOOL;老实说，if return WEIGHT_TOOLCALL;return WEIGHT_NORMAL;}，

从旧到新逐条移除高权重消息，直到 Token 总量回落至预算范围内。老实说，

The library avoids heavyweight tokenizers like tiktoken and instead estimates based on character counts for Chinese and English separately:

const CHINESE_CHAR_REGEX = //g;const CHARS_PER_TOKEN_CN = CN_CHARS_PER_TOKEN;// e.g.,≈2.5 chars/token
const CHARS_PER_TOKEN_EN = EN_CHARS_PER_TOKEN;// e.g.,≈4 chars/token
export function estimateTokens {
const chineseChars =
text.match?老实说，.length || 0;const orChars =
text.length - chineseChars;return Math.ceil(
chineseChars / CHARS_PER_TOKEN_CN +
orChars / CHARS_PER_TOKEN_EN
);}

The system also estimates image tokens by tile count instead of raw Base64 length.

实时校准机制

The first few API responses provide real prompt_tokens. AI Helper uses an Exponential Weighted Moving Average to adjust estimation factor:

let calibrationFactor = INITIALFACTOR;const CALIBRATIONMINSAMPLES = MINSAMPLE_COUNT;

export function updateCalibration { const ratio = actual / estimated;老实说，if return;// 异常过滤

calibrationFactor = calibrationFactor * + ratio * ALPHA;

}

This makes estimator increasingly accurate even for non‑standard tokenizer models.

Differing models have different context windows. AI Helper maintains a built‑in mapping while allowing user overrides:

export const MODELCONTEXTWINDOWS= {
'deepseek-v4-pro': WINDOWA。'deepseek-chat': WINDOWB,'gpt-4o': WINDOWC,'gpt-': WINDOWD,'claude--sonnet': WINDOWE,default: DEFAULTWINDOW,};

export function getContextWindow{ if)return customModelMap.get;ifreturn userConfiguredWindow;按理说，return MODELCONTEXTWINDOWS||MODELCONTEXTWINDOWS.default;}

• 接入自定义模型？不过，只需在配置里写明大小，无需改代码。

至于关键设计，保护 tool_calls/tool 配对

OpenAI 格式要求 assistant 的 tool_calls 与随后出现 的 tool 必须配对。怎么说呢，如果裁剪时只删了其中之一，会导致 API 报错。

javascript
// 删除 assistant 时同步删除后续对应 tool
if {
while{
trimmedMessages.push);}
}

`filterApiMessages` 在发送前遍历整个数组，对每个 `tool_calls` 检查是否存在对应 `tool` 响应；缺失者被清除，从而保证请求合法性。老实说，

• 主要思路 ： 按 Token 而非消息条数管理上下文
• 实时估算 + 多级压力监测 + 增量摘要 + 智能截断 + 配对保护
• “先摘要后删除” 防止关键信息丢失。让长对话在多轮推理循环中保持稳定，不因超限而崩溃

项目地址：

• GitHub : https://github.com/xiweicheng/…
• Gitee : https://gitee.com/xiweicheng/…

---