上下文越堆越长，账单跟着失控
某 SaaS 公司在 6 月底对账时发现，单个客服 Agent 上个月的多模态调用账单比模型本身的 API 标价高出了 4 倍。排查下来，问题不在模型贵，而在于每轮对话拼进去的历史上下文越攒越多，Token 计费的雪球越滚越大。
据腾讯云开发者社区 2026 年 5 月的观察，「大模型不值钱了，最贵的是你的上下文」已经成了 Agent 团队排第一的成本痛点（来源：cloud.tencent.com/developer/article/2672112）。雨水多的夏季，企业客服、知识库问答和巡检类 Agent 调用量普遍上涨 30%–60%，一本「上下文越长、Token 越贵」的糊涂账几乎每家都在重演。
本文选了三个 2025–2026 年新公开、仍在维护的开源脚本，从「抓得到、看得清、砍得下」三个动作，给你一套能在本地服务器就跑起来的计费监控方案。
为什么 Token 账单先从上下文失控
在看脚本之前，先把账是怎么乱掉的拆开。
Coding Agent 通常会做三件事来「省」Token，结果却常常反向：把上一轮的对话原文整段塞进下一轮的 prompt；把工具返回的 JSON、报错日志整块塞回来；把系统提示词的模板段无限追加。知乎上 2026 年 6 月一篇分析把这些现象总结成 coding agent 的「隐性 token 浪费」（来源：zhuanlan.zhihu.com/p/2039345340223075334）。一篇对比测试显示，最激进的多上下文工程方案与最克制的方案之间，单次任务成本相差接近 1000 倍。
更隐蔽的是：
- 多模态输入把一张 1080p 截图解析出的文本 token 数，往往是视觉 token 的 5–8 倍，且容易反复出现；
- 失败重试链里，前一次的失败栈被原封不动带入下一次，结果越补越长；
- 上下文缓存命中率低时，每轮都要重新计费的成本，会长期高于「模型本体」。
理解了这些，再去看监控脚本才有针对性。它们要解决的，是「抓 Token 流向、看冗余在哪里、强制在送出去之前砍一刀」。
顺手放一张运行逻辑图，下面三个脚本分别落在不同的位置：
请求进入 → [脚本1:代理层拦截] → 上下文压缩/截断 → [脚本2:Token 计量] → 模型 API
↓
[脚本3:账本与告警]
脚本一：TELOS SDK——在代理层把多轮对话压下来
TELOS SDK 是 GitCode 在 2025 年底公开的一套上下文缓存与压缩方案，主打「极致 Token 效率」。它的卖点很直接：在多轮对话里把重复的上下文段缓存命中，对新增内容做结构化压缩。
官方宣称在 6 轮真实对话中，能比基线节省 92.3% 的成本，48 次连续请求的 P95 延迟稳定在一个相当低的水平（来源：gitcode.csdn.net/6a15c96110ee7a33f275616f.html）。这套数字在 2026 年 7 月仍然是 GitCode 主页上挂着的最新结果。
它在三个位置最适合部署：
- 中小型 SaaS 的多轮客服，不需要换底层框架，直接挂在 OpenAI 兼容代理前；
- 内部知识库问答，原本的 prompt 模板本身偏长，缓存命中率容易做高；
- 用户授权读屏或多模态问答，重复的图像描述能直接命中历史缓存。
部署步骤压缩到三步：
第一步，装包并起一个本地代理。 pip install telos-sdk 后跑 telos-proxy --port 9000，它会监听 9000 端口并伪装成 OpenAI 兼容接口，业务侧只需要改一行 base_url。
第二步，把基线模型先跑一遍 dummy 流量。 这一步是为了让缓存里有「冷数据」，第一次真实请求命中率通常能上去到 60% 左右。
第三步，配截断阈值。 关键参数是 max_context_tokens 和 cache_ttl。建议先设成模型官方上下文窗口的 40%，观察两天后再往下压。
坑：截断阈值压到 15% 以下时，回答质量的体感下降会非常明显。这种项目往往是「省钱省到体验崩」的典型拐点，最好结合金标回归集一起调。
脚本二：AgentMemory——让 coding Agent 自己管记忆
如果说 TELOS 解决的是通用对话，那 GitHub 上 2026 年初更新的 memory_agent_hub（来源：github.com/1850298154/memory_agent_hub）要解决的是 coding agent 的记忆管理。它会自动捕获会话里的操作、决策和上下文，把「有用的」持久化，把「临时的」及时丢掉。
知乎上 2026 年 5 月一篇关于「腾讯云 Agent Memory 节省 61% Token、提升 52% 成功率」的方案（来源：zhuanlan.zhihu.com/p/2041180811769144431），其实和 memory_agent_hub 的思路同源：把完整信息卸载到外部文件系统，再只把一张「可导航」的结构化图压回上下文，相当于每次只把目录送进去，不把正文送进去。
这套方案对以下场景最划算：
- 跨任务、长流程的代码重构 Agent，一次会话跑几十分钟那种；
- 工具链复杂、需要反复调用 IDE、终端、测试用例的工程类 Agent；
- 团队里多 Agent 协作，每个 Agent 自己管一份记忆，避免互相「串味」把上下文撑爆。
集成时建议这样安排：
- 把 memory_agent_hub 作为独立服务起来，挂在 Agent 框架（LangGraph、AutoGen 或 Dify 工作流都行）的记忆层；
- 给每个项目建一个独立 namespace，别让多个项目共享同一份上下文内存；
- 持久化的内容要走结构化 JSON，而不是把 Markdown 直接 dump 进 prompt，否则会比不压缩还糟。
脚本三：自建 Token 计量与告警——把账本看得见
开源脚本能省 Token，但更重要的是把账本摆到看得见的位置。2026 年大部分事故复盘里，最常被吐槽的不是「我们不知道贵」，而是「我们等到账单寄到才知道」。
这里推荐在本地起一个最小可用的 Token 计量服务。逻辑不复杂：用 LiteLLM 或 OpenAI 兼容的代理层把每一次出站请求拆成子段，分别记录 system、history、tools、new_user 四类的 token 数，按项目、按 Agent、按天聚合到本地 SQLite，再通过 Grafana 或简单的 Webhook 告警。
部署的关键点不在脚本本身，而在三件事：
- 打标：每个 Agent 在请求头里塞
X-Agent-Name和X-Project，方便事后按业务线拆分。不能只在网关侧打，业务侧的标签一定要带出去。 - 冗余率指标：系统段出现次数、工具返回段出现次数、平均重复率，建议单独建一张表。冗余率超过 40% 就要有人介入查 prompt 模板。
- 每日对账线：每天下班前自动跑一遍，把当天的 token 总量 × 单价，和模型厂商后台的账单做一次对账。偏差超过 5% 立刻停掉某个 Agent 排查。
预算失控的中小企业，往常是从自动重试、长上下文、闲置实例三件套同时叠加开始的（参见站内《中小企业部署 AI Agent，先把账单和 ROI 算明白》一文）。把上面的抓取加进 Agent 路由层后，至少能保证「再贵也贵得明白」，而不是月底突然发现一二十万已经烧光。
三套脚本怎么搭在一起
单独跑任一个都有效，但要真正扛住夏季调用峰值，建议把它们按顺序串起来：
- 入口侧：TELOS SDK 做上下文压缩与缓存，覆盖多轮对话；
- 业务侧：memory_agent_hub 给 coding Agent 配持久记忆，工具返回的内容只留摘要；
- 出口侧：自建 Token 计量代理做打标与告警，三套数据每天对一次账。
三套都开源、都支持本地部署，不强制绑定特定模型厂商，业务侧只需要改一行 base_url 就能切过去。
临门一脚的几个判断
最后说几个不会写进 README、但真实在生产里决定成败的判断：
- 截断阈值别压到 15% 以下。省小钱、丢大单是 Agent 项目 2026 年最常见的死法。
- 多模态 Agent 的图像描述一定要进缓存结构。同一张图被反复解析，是夏季账单里最隐蔽的「大头」。
- 计量代理不要塞太多业务逻辑。计量就是计量，复杂了反而拖慢首 token 延迟，影响主链路。要做策略，去专门的 Agent 路由层做（参见站内《Agent 选型别押一家，三模型路由怎么搭》一文）。
- 计费接口本身也存在合规缝隙。光省 Token 没用，把订阅、续费、退款这条链路同时管住，才不会从另一边烧钱（参见站内《Agent 自动续费陷阱背后：计费接口的合规缝隙》一文）。
把账本看得见、把上下文管得住、把告警挂在账单前面——这三件事做到位，2026 年夏天就不用再对着 Agent 的账单发呆了。