摘要Agent 每跑一轮账单都在涨——但钱具体花在哪系统提示、工具定义、历史消息、检索注入、模型输出每一部分都占多少本文给出上下文成本的拆分口径、监控指标与优化手段缓存、压缩、裁剪并说明怎么用每轮对话成本看板让成本可见、可控。做过 Agent 的人都有体会模型输出可能只占账单的一小部分真正的大头是每次请求都要重算的上下文。多轮对话里历史消息不断累积工具调用把一堆返回结果塞回上下文检索系统再注入几段文档——一轮比一轮贵。而很多团队直到月底看账单才发现成本翻了几倍。结论上下文成本 输入令牌系统提示 工具定义 历史消息 检索注入 输出令牌 缓存读写。其中历史消息累积是最容易被忽视、增长最快的部分。监控闭环四步记录每轮令牌消耗 → 拆分成本构成 → 缓存复用 → 压缩裁剪。官方数据表明提示缓存命中后缓存读取价格仅为正常输入价的 0.1 倍省约 90%是立竿见影的降本手段。一、成本构成钱到底花在哪上下文成本构成构成特点成本趋势系统提示与工具定义每次请求都带几乎不变固定但占比随轮次稀释历史消息累积每轮新增全部回传随对话轮次线性膨胀占比最大检索注入文档按需注入可能重复与检索策略强相关模型输出唯一产生价值的部分通常占比最小为什么历史消息是膨胀元凶大多数实现把每轮对话的完整消息数组原样回传10 轮对话后历史可能占输入令牌的 80% 以上其中大量是已过时、已总结、已无用的内容。二、监控指标先让成本可见在请求日志里为每次调用记录以下字段成本即可量化指标口径关注点输入令牌数每次请求的输入总量按会话轮次画曲线看膨胀速率输出令牌数模型生成量异常高输出排查循环生成构成拆分提示/历史/检索/工具各占多少定位增长源头缓存命中率命中缓存前缀的比例命中率低说明前缀不稳定单轮成本令牌 × 单价折算按用户/会话维度聚合找成本大户三、优化三板斧缓存、压缩、裁剪1. 缓存复用见效最快。Anthropic 官方 Prompt Caching 文档与公告显示缓存命中时缓存读取价格仅为正常输入价格的 0.1 倍即省约 90%长提示的延迟可降低约 85%。代价是写入缓存更贵5 分钟 TTL 为 1.25 倍、1 小时 TTL 为 2.0 倍输入价因此适合前缀稳定、复用频繁的场景——系统提示、工具定义、固定知识库正是典型。2. 历史压缩。对话超过 N 轮后把早期消息用摘要 关键事实替换保留最近 M 轮原文检索结果做去重与截断只保留相关段落。3. 裁剪与分层。工具返回结果按需截断不活跃会话过期清理按是否影响下一轮决策决定哪些历史必须保留。四、监控闭环让成本持续可控成本监控闭环记录每次调用落日志带会话 ID、令牌构成、模型与单价拆分按构成维度聚合生成每轮对话花在哪报表优化缓存命中率低的先做前缀固化历史膨胀快的做压缩看板与告警单会话成本、单用户成本、日均成本超阈值告警复盘周度看成本趋势与功能迭代挂钩避免功能上线、成本失控。踩坑记录现象——上线缓存后账单不降反升。根因——缓存写入费1.25 倍被反复支付对话前缀每次都在变动态日期、随机指令缓存几乎不命中却每次都按写入价计费。排查证据——缓存命中率日志显示不足 10%而前缀内容对比发现 80% 的请求前缀不一致。修复方式——把动态内容时间、随机参数移到缓存断点之后固定前缀系统提示、工具定义、固定知识保持在断点之前命中率提升到 60% 以上成本下降约 50%。经验缓存省钱的前提是前缀稳定先做前缀固化再做缓存顺序不能反。FAQQ1上下文成本占 Agent 总成本多少A视场景而定多轮对话型 Agent 的输入令牌通常占 70% 以上其中历史消息是最大头单次问答型 Agent 输入占比低输出占比高。Q2缓存命中率多少算健康A前缀稳定的场景固定系统提示 知识库应做到 50% 以上低于 30% 说明前缀不稳定先固化前缀再谈缓存。Q3历史压缩会不会掉效果A会有一点点但有研究支持关键信息放在上下文开头/结尾更利于模型利用压缩时把关键事实放开头通常损失可控、收益显著。Q4工具返回结果要不要全量回传A不要。工具返回往往冗余只回传后续决策需要的字段并截断长度可大幅降低注入令牌。Q5小团队有必要做成本监控吗A有必要且成本很低——在日志里加三个字段会话 ID、输入/输出令牌、构成标记即可起步先跑一个月看账单结构再决定优化优先级。总结上下文成本不是模型贵而是重复计算贵同一份系统提示、工具定义、历史消息每轮都被完整重算。监控的第一步是拆分——记录每轮令牌构成让花在哪可见优化的第一步是缓存——把稳定前缀固化命中后省约 90%再配合压缩与裁剪控制历史膨胀。四步闭环走通Agent 的成本就从月底惊吓变成周度可控。参考资料Anthropic 官方公告《Prompt caching with Claude》2024-08与官方文档《Prompt caching》36 氪关于 Claude Code 提示缓存的报道2026-08社区关于提示缓存命中率与成本折算的实践资料。