用于长对话历史的客户支持机器人 Token 计数

客户支持机器人很少会因为某条客户消息过长而失败。它们失败通常是因为请求悄悄累积了系统提示、政策规则、客户档案数据、工具定义、检索到的帮助中心段落，以及前面几十轮对话。

用于长对话历史的客户支持机器人 token 计数可以在这些内容导致错误、回答被截断或请求成本过高之前，让这种增长变得可见。更重要的是，它能帮助你在不删除下一次回复仍然需要的事实的前提下缩短对话。

实际目标不是保留每一个词，而是保留支持状态：客户想要什么、已经尝试过什么、公司承诺过什么、哪些标识符重要，以及此案例是否必须升级处理。

为什么长时间的支持对话风险特别高

通用聊天机器人通常可以通过开启一个新线程来恢复。但支持机器人并不总能安全地这样做。对话中可能包含：

• 订单、工单、订阅或设备标识符；
• 客户已验证的账户状态；
• 已经完成的故障排查步骤；
• 同意或身份验证状态；
• 退款、换货或后续跟进承诺；
• 升级处理决定以及分配的队列；
• 来自政策或地区规则的限制；
• 客户偏好的语言和渠道。

如果你只是删除最旧的消息，机器人可能会重复已经失败的故障排查，要求客户已经提供过的信息，和之前的承诺相矛盾，或者错过升级处理触发条件。

这就是为什么用于长对话历史的客户支持机器人 token 计数，应当与状态提取配合使用，而不是盲目截断。

哪些内容计入请求预算

可见的对话只是组装后请求的一部分。一个有用的规划公式是：

working_context
= protected_instructions
+ tool_schemas
+ customer_state
+ retrieved_knowledge
+ conversation_history
+ current_message
+ reserved_output
+ safety_margin

当前的提供商文档遵循同样的操作模式：在发送前测量完整输入，然后在生成后检查实际使用量。OpenAI 记录了对结构化输入进行 token 计数的方法，并指出输出使用量可能包含超出可见回答范围的 token。Google 记录了预检的 countTokens 方法和运行时使用元数据。Anthropic 的上下文窗口指南也将累积消息视为活动上下文的一部分，而不是免费的存储空间。

具体的分词器和计费字段取决于模型和端点。不要把通用的词到 token 估算当作生产环境控制。请统计与你实际发送的相同组装负载形状。

支持场景下安全的 token 预算

对于运营团队来说，只有当每个请求组件都有明确的保留规则时，用于长对话历史的客户支持机器人 token 计数才最有效。

首先为每个请求组件分配一个状态。

组件	处理方式	示例
受保护内容	逐字保留	安全规则、授权边界、退款政策限制
结构化状态	紧凑保留	订单 ID、套餐、设备、验证、情绪、升级状态
最近轮次	逐字保留	最新的问题描述、澄清说明，以及承诺的下一步
较早历史	总结	已解决的问题、重复的解释、已完成的故障排查
可检索证据	移除并按需获取	帮助中心文章、政策段落、旧案例记录
输出预留	发送前保护	为回答、引用、工具调用和交接说明预留空间

然后强制执行如下阈值：

usable_input_budget
= model_context_capacity
- reserved_output
- safety_margin

if assembled_input > usable_input_budget:
    compact_history()
    recount()

不要把博客文章里的上下文容量数值直接照搬到生产环境中。请使用你所部署的具体模型和路由的最新文档与 API 行为。

最佳历史策略：三层结构

对于大多数客户支持机器人来说，三层记忆设计比重放整段对话记录更容易控制。

这也是为什么，用于长对话历史的客户支持机器人 token 计数，最终会变成一个记忆架构决策，而不是临近收尾时的删减任务。

1. 不可变支持规则

保留定义机器人可以做什么、何时必须升级处理，以及哪些声明需要工具验证的指令。这些规则不应被对话总结器重写。

2. 结构化案例状态

将持久事实存储在自然语言对话记录之外。一个紧凑的记录可能如下所示：

{
  "customer_goal": "replace damaged item",
  "order_id": "ORD-48291",
  "identity_verified": true,
  "steps_completed": [
    "photo received",
    "shipping address confirmed"
  ],
  "company_commitment": "replacement review within 24 hours",
  "escalation_status": "specialist_queue",
  "next_action": "check replacement approval"
}

这通常比让模型从 40 轮对话中重新发现相同事实更节省 token，也更不容易产生歧义。

3. 滚动式对话窗口

逐字保留最近轮次，因为措辞、语气、修正内容以及直接引用仍然很重要。将较早的轮次总结为简明的案例历史，并且只有在当前任务需要其中证据时才检索原始记录。

其结果并不是“记忆丢失”。而是把指令、持久状态、最近对话和归档证据进行有意区分。

何时总结对话历史

不要等到出现硬性的上下文错误。只要满足以下任一条件，就应触发压缩：

1. 组装后的输入超过了可用输入预算的某个百分比。
2. 机器人已经完成了一个明确的支持阶段，例如身份验证或诊断。
3. 若干轮对话重复了同一问题，却没有增加新的事实。
4. 检索或工具 schema 会扩展并减少回答余量。
5. 语言切换会实质性地改变 token 数量。

一个实用的系统会使用两个阈值。第一个阈值用于创建或刷新摘要。第二个阈值会阻止请求，直到历史记录被压缩并重新计数。

阈值使面向长对话历史的客户支持机器人 token 计数在短工单、多日调查以及升级案例中都更可预测。

可直接粘贴的对话压缩提示词

将以下提示词与一段示例对话一起粘贴到 TokenTest 中，以比较原始历史记录与压缩后的版本：

You are compressing a customer support conversation for the next assistant turn.

Preserve exactly:
- customer goal and current blocker
- order, ticket, account, product, and device identifiers
- identity or consent status
- troubleshooting steps already attempted and their outcomes
- policy constraints already confirmed
- promises, deadlines, refunds, replacements, or credits discussed
- escalation status, owner, and next action
- customer corrections, preferences, and unresolved questions

Remove:
- greetings and acknowledgements
- repeated explanations
- abandoned hypotheses
- wording that does not change the case state

Return JSON with these keys:
customer_goal, identifiers, verified_facts, completed_steps,
commitments, constraints, escalation, unresolved_questions,
next_action, recent_turns_to_keep_verbatim.

Do not invent missing facts. Mark uncertainty explicitly.

分别统计原始转录、压缩提示词以及返回状态。只有当完整的下一次请求更小，同时仍保留正确响应所需的事实时，摘要才有价值。

生产支持机器人中的 token 计数工作流

使用以下工作流，使面向长对话历史的客户支持机器人 token 计数在开发和生产环境中都可重复。

步骤 1：组装真实请求

包含实际的系统指令、工具 schema、检索内容、结构化状态、最近轮次以及当前客户消息。统计一个简化的纯文本样本会低估生产中的实际用量。

步骤 2：按组件计数

记录每个主要部分的 token 数，而不仅仅是总数。这样可以看出增长来自历史记录、检索、工具还是指令。

步骤 3：保护响应容量

在决定历史记录能容纳多少之前，先预留输出空间。一次支持回复可能需要解释决定、请求证据、调用工具，并生成交接说明。

步骤 4：按固定顺序压缩

先移除重复的检索段落，然后总结已解决的阶段，再缩减滚动窗口。不要仅仅因为安全指令较旧，就缩短它们或删除未解决的承诺。

步骤 5：重新统计完整载荷

面向长对话历史的客户支持机器人 token 计数是一个反馈循环。每一次摘要、检索变更或工具更新都会改变请求，并且必须再次测量。

步骤 6：验证线上端点

预检计数回答“这个是否装得下？”运行时用量回答“这个路由实际上报告了什么？”TokenTest 现行产品手册将其 D4 评估描述为检查用量完整性，包括在可用时验证输入、输出、总量、缓存以及与推理相关的证据。这使它适合测试具有代表性的支持载荷，并比较各个 OpenAI 兼容路由上报告的行为。

分别测试多语言支持历史

不要假设一段英文对话及其中文本地化具有相同的 token 预算。分词会因语言、措辞、标点、标识符和模型分词器而异。

对于具有长对话历史的客户支持机器人来说，多语言验证是 token 计数的必要组成部分，因为同一个案例在本地化后可能占用不同的预算。

对于双语支持机器人，至少测试以下四种载荷：

1. 英文系统指令配英文历史。
2. 中文系统指令配中文历史。
3. 英文指令配中文客户轮次。
4. 对话中途切换语言。

在每次测试中使用相同的案例事实和输出预留。目标不是证明某一种语言总是更长，而是为每个已部署载荷找出真实预算。

值得记录的指标

跟踪的不应只有总 token 数。实用的运行字段包括：

• 按组件划分的输入 token；
• 预留和实际输出 token；
• 保留的逐字轮次数量；
• 案例摘要的时间和 token 大小；
• 检索 token 和文档数量；
• 每次对话的压缩事件；
• 缺失状态或重复问题事件；
• 压缩后的升级处理准确性；
• 端点报告的用量和结束原因。

这些指标将 token 节省与支持质量联系起来。如果更小的提示会增加重复提问、承诺失效或错误升级，那它就不是改进。

常见错误

只计算最新的客户消息

最新消息可能很短，而隐藏指令、工具、检索和历史会主导请求。

在没有 schema 的情况下进行摘要

自由形式摘要经常会遗漏标识符、承诺或不确定性。支持状态 schema 能让遗漏更容易被发现。

“以防万一”保留每一轮

这会把设计决策拖到上下文窗口替你做决定为止。

删除旧承诺

时间久远并不会让承诺变得无关。应保留它，直到它被履行、取消或被新的内容取代。

对每种语言和路由都使用同一个预算

分词器和端点行为各不相同。应验证每一种生产配置。

运行规则

对于具有长对话历史的客户支持机器人，token 计数最安全的规则很简单：

保留策略、案例状态、未解决的承诺和最近对话；总结已解决的历史；仅在需要时检索旧证据；预留回答；然后再次计算完整请求。

在上线前使用 TokenTest 运行具有代表性的支持请求载荷。关于相邻的规划问题，请参阅当消息超过最大上下文长度时该怎么做以及生产环境上下文窗口规划指南。

常见问题

客户支持机器人应该保留完整的对话历史吗？

通常不应在每次请求中都保留。请维护一份持久的工单状态记录、已解决较早阶段的摘要，以及最近轮次的逐字窗口。将完整转录存档以便检索和审计。

对话历史应该多久进行一次摘要？

应在支持阶段边界处进行摘要，或当组装后的请求超过定义的预算阈值时进行摘要。每次压缩后重新核算。

在压缩过程中绝不能丢失哪些事实？

保留标识符、验证或同意状态、已完成的故障排查、已确认的政策限制、公司承诺、升级状态、未解决的问题以及下一步操作。

基于字符数或词数的 token 估算是否足够？

这对于粗略规划有用，但不足以用于生产环境执行。请使用与已部署模型和载荷格式相匹配的 tokenizer 或提供方方法进行计数。

TokenTest 可以替代提供方的使用日志吗？

没有任何单一的预检工具可以替代运行时证据。请使用 TokenTest 进行可重复的载荷和路由评估，然后将结果与提供方报告的使用量、结束原因以及您的应用日志进行比较。

来源

• TokenTest 主页
• TokenTest 产品手册
• OpenAI token 计数指南
• Google Gemini token 指南
• Anthropic 上下文窗口指南