固定开销每次都在付
系统提示、工具定义与输出格式说明会随每次请求重复计费。为什么容易被忽略：它们写在代码里，不体现在单次对话长度上。做法是把这部分单独统计，能缓存就缓存，能精简就精简，改动前先备份版本。
检索注入的边际成本
检索片段数量与切片长度直接决定输入规模。怎么压：先降片段数量，再降单片长度，最后才考虑改写；边界是压缩会改变召回，必须用带标准答案的样本对比，确认关键信息没有被切掉。
多轮历史会累积
同一会话里，历史消息通常整体重发，轮次越多输入越长。做法是保留最近若干轮原文、更早的做摘要，并明确哪些信息不能丢（金额、编号、承诺条款）；边界是摘要本身也消耗 token，要算净收益。
输出长度与结构化
结构化输出中的字段名、括号与转义都会计入 token，截断后的重试更会翻倍。怎么改：精简字段名、避免冗余嵌套、设置合理最大长度；边界是压缩格式要与下游解析保持一致，改完要跑一遍解析测试。
适用与不适用
适合谁
- 以问答与摘要类应用为主的业务与产品团队
- 检索片段多、上下文偏长的问答系统
- 正在做提示词工程与上下文治理的研发团队
不适合谁
- 只做离线批处理、调用量很小的项目组
- 无法修改提示词与检索配置的封闭系统
典型场景
一家保险经纪的条款问答上线后成本偏高。团队统计发现系统提示与工具定义占了近四成输入，检索片段又叠加了整章条款。先把工具定义精简并改为可缓存前缀，再把条款切片到条款级，最后用样本验证召回未下降。
可执行步骤
- 单独统计系统提示与工具定义占输入的比例，形成可对比的基线与口径
- 按接口统计检索片段数量与切片长度，找出过长的主要来源并排优先级
- 检查多轮会话的历史策略，确认金额与编号等信息保留原文不丢关键字段
- 精简结构化输出的字段与嵌套，避免多余的转义与重复键名并测解析耗时
- 每轮压缩后跑同一组样本，确认召回与格式解析都没有退步再合并上线
常见坑
- 系统提示越写越长，规则互相冲突，token 花了不少，效果反而变差，还难以维护。
- 检索片段越多越安心，实际把关键条款淹没，模型答错却找不出原因，排查成本很高，效率很低。
- 历史摘要丢掉了金额与编号，后续追问答非所问，只能让用户重述，返工也随之增加。
- 结构化输出字段名冗长，一次返回多出大量 token，解析反而更慢，得不偿失，维护也麻烦。
自检与验收清单
- 系统提示与工具定义占比是否单独统计
- 检索片段数量与长度是否有明确上限并有人守
- 多轮历史策略是否写明保留规则与例外
- 结构化输出是否精简并测过解析兼容
- 每轮压缩是否都有样本对照与记录
常见问题
系统提示能精简到什么程度
看任务复杂度。规则型任务可以压到很短，多步骤任务需要保留判断依据与例外处理。建议先合并重复规则、删除从未触发的条款，再用样本验证；精简后若错误类型集中出现，说明删掉了必要约束。
检索片段多少合适
没有固定数字，取决于知识密度与切片方式。片段过多会稀释注意力并推高成本，过少则召回不足。做法是先看召回评测，再逐步减少片段数量，找到召回开始下降的临界点，留一点余量。
多轮摘要会不会丢信息
会，所以要先定保留清单：金额、编号、时间、承诺条款必须留原文，其余可以摘要。摘要由模型生成时还可能引入偏差，关键字段建议用规则抽取后原样保留，再交给模型组织语言。