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

[小蓝]

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

[今天也没睡醒]

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

[rootless]

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

[小吴]

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

[葡萄冰]

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

[阿远]

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

[普通网友A]

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

[nora]

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

[橘子汽水]

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

[林小北]

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