Token 预算怎么拆，别让系统提示被业务内容挤掉

[橘子汽水]

大家做多轮问答时 token 预算怎么拆？我们现在就是超了就从最早消息开始删，感觉偶尔会丢关键约束。

[林小北]

“从最早开始删”是最低配，能跑但容易错。预算要分区：系统指令、工具协议、当前问题、证据、历史状态、可丢闲聊。

[小马过河]

我们做了固定比例，系统 10%，资料 60%，历史 20%，输出 10%。结果资料短的时候浪费，资料长的时候还是爆。

[陈小舟]

比例不如优先级。系统和工具协议不可删，当前用户消息不可删，证据按相关度删，历史要先摘要再删。

[latte404]

输出预算也别忘。很多人只算输入，结果模型回答到一半被截断，用户看到半句 SQL。

[小蓝]

我们客服场景设了最大输出 700 字，复杂问题让模型先问澄清，不允许一次写长篇。

[今天也没睡醒]

token 预算还影响成本预估。一个“继续”按钮可能把完整历史再发一遍，账单翻倍。

[rootless]

能用 prompt caching 的静态部分就拆出来。系统提示、工具说明、固定政策，这些别每次都当新内容烧。

[小吴]

预算表要不要暴露到前端？比如告诉用户“内容太长已压缩”。

[葡萄冰]

面向用户别说 token。可以说“我会基于当前问题和关键记录回答”。内部日志再记压缩比例。

[阿远]

历史消息我建议存结构化状态：用户身份、已确认事实、未解决问题、风险边界。聊天原文只在需要追溯时检索。

[普通网友A]

但摘要会不会丢情绪？客服投诉里情绪很重要。

[nora]

摘要里可以有“情绪状态=强烈不满，已道歉一次，不要重复解释政策”。不是只存事实。

[橘子汽水]

我打算把上下文分成必保、可压缩、可丢三档。日志里记录每次删了什么，不在用户界面显示。

[林小北]

对，先能解释每次预算决策，再谈优化。