夜雨聆风一个让很多团队悄悄停用AI Agent的问题
这个季度，很多构建者悄悄停用了自己的AI Agent。原因只有一个：API账单失控。
一部分人换了更便宜的模型，输出质量变差，用户流失。少数人意识到，账单从来都不是模型问题，是工程问题。
2026年的token成本，重点不在你选了哪个模型。重点在于——有没有给系统接可观测性，有没有正确启用缓存，有没有把合适的模型路由到合适的任务，有没有压缩模型不需要的上下文，有没有限制重试循环，有没有验证缓存命中率，有没有用告警把省下来的钱锁住。
举个近在眼前的例子。Claude Code Opus档位，十个人的团队一年烧掉45,000美元。多数团队有三四款工具，多数团队根本没算过这笔账。账单增长得比价值更快，这就是大多数团队的现状。
好消息是，账单可以修。不需要换模型，不需要自己写runtime，不需要迁移框架。只需要按正确顺序做七件事。
下面是一套精确的7天行动手册。目标：一周内把每月4,800美元的账单降到每月620美元。
Day 1：审计你的token到底花在哪里
大多数团队回答不了一个问题：代码库里哪个函数最贵？哪个用户占了最大比例的账单？哪条路由每个session烧掉的token最多？
如果回答不了这些问题，就无法优化。
你需要先有可观测性，然后才谈得上优化。三个工具：
Helicone。代理网关，一行代码把LLM调用路由到它们的服务，捕获每个请求、每个响应、每个token计数、每一美元花费。免费档每月覆盖1万次请求。
Langfuse。开源，可自托管，被ClickHouse收购前每月有2600万次SDK安装。最适合需要把数据留在自家基础设施上的团队。
Portkey。能路由到250多个provider的网关，强项是fallback、负载均衡，以及内置的成本优化功能。
接进去，然后看仪表盘。你要找的是前五大花费项。按总成本降序排序，看函数、用户、路由、session。
几乎每个团队都会出现同一种模式：两个函数吃掉60%的预算。有时是两个用户。有时是一个没人记得自己写过的失控cron job。
一个具体例子。一支团队在周一审计了他们的栈，发现47%的账单来自一个本该在六个月前废弃的单个函数。没人检查过。这个函数仍然被一个每15分钟运行一次的遗留cron job调用。他们当天下午关掉了这个cron，账单在其他事情还没开始做之前就下降了47%。
Day 1结束时，你应该拿到这些数据：月度总成本、前五个最贵函数、前五个最贵用户、平均cost per session，以及两三个明显需要调查的异常。
这些数据是地基。没有它，后面六天都是瞎猜。
Day 2：在所有有效位置打开Prompt Caching
这是整个7天课程里最大的杠杆。
Anthropic对cache read给出90%折扣。每个缓存输入token的价格是基础输入价格的0.1倍。读缓存，就能省下每一美元里的90美分。
关键在于写入成本。Anthropic对初始写入收取基础价格的1.25倍，TTL 5分钟；对1小时TTL收取基础价格的2倍。也就是说第一次写入更贵，之后每次读取便宜很多。
盈亏平衡来得非常快。使用5分钟缓存时，只要命中一次缓存就能回本。第一次命中之后都是纯节省。
要缓存什么：系统prompt、工具定义、会跨调用复用的大型参考文档、few-shot示例、对整个session稳定的RAG检索结果。任何在第N次调用和第N+1次调用中完全相同的内容。
不要缓存什么：用户当前输入、针对这次查询新检索的数据、agent不断演化的scratchpad。
代码实现如下：
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
system=[
{
"type": "text",
"text": LARGE_SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"},
}
],
messages=[{"role": "user", "content": user_input}],
)这个cache_control标签就是全部集成。把它加到你想缓存的content block上。每次访问后，缓存会保持5分钟热度。后续每个命中相同前缀的调用，对那一部分只付0.1倍价格。
如果你的系统prompt是8,000 token，用户输入是200 token，你过去每次调用都为8,200个输入token付费。缓存后，你先为8,200个token付一次费。之后每次调用只为0.1倍的8,000加200付费。输入成本下降88%。
团队常犯的错误，是缓存了错误部分。缓存易变内容，命中率就是零。缓存只对相同前缀有效。如果你的系统prompt顶部插入了当前日期或用户名，每个用户的缓存都会被打断。
把易变内容移动到末尾。把不变内容放在开头。不变前缀越长，命中率越高。
Day 3：压缩上下文
Day 3的目标，是不要把模型不需要的东西发给模型。
先看一组让我清醒过来的数字。
一个典型生产agent大致会发送每轮850个token的上下文开销（工具定义300+telemetry摘要300+状态记忆150+压缩检索上下文100）。
而压缩之前，同一个agent发送的是14,500个token——工具定义3,200+ telemetry 5,800+状态记忆2,400+检索上下文3,100。
这是94%的削减。同一个agent，同一个任务，同一个模型。在50个样例的eval set上，输出质量和未压缩基线相比保持在2%以内。
具体做法如下。
带文件引用的工具结果截断。不要把一个50KB的日志文件当作tool result传回去。把日志存到磁盘，只传回路径和前500个字符，模型需要更多时再读路径。
def truncate_tool_result(result: str, path: str, max_chars: int = 500) -> dict:
if len(result) <= max_chars:
return {"content": result, "truncated": False}
Path(path).write_text(result)
return {
"content": result[:max_chars] + "...[truncated]",
"file_path": path,
"full_length": len(result),
"truncated": True,
}总结后的scratchpad状态。模型不需要看到过去30轮的每次tool call。它需要看到一段200词的摘要，说明尝试过什么，以及当前状态的新鲜视图。
Microcompact：每轮都运行，把重复调用用相同输入的结果替换成一个缓存引用。对反复调用grep的agent，可以省下数千token。
Snip compact：丢弃最旧消息，同时保留最近几轮作为受保护尾部。
Auto compact：当token使用量超过阈值时运行总结，用摘要替换旧消息。
核心概念，是每轮预算。多数agent发送的内容比实际需要多10倍，因为没人设预算。对大多数任务来说，每轮4,000 token的上下文开销是合理的，8,000很宽裕。超过这个数，就是泄漏。
Day 4：按任务路由模型
不是每个任务都需要Opus。
这一天，大多数团队会发现自己一直在用Opus的价格处理Haiku的任务。判断用户意图的分类器不需要每百万token 15美元的模型。把结构化请求转换成自然语言的transform也不需要。
下面这套三层路由策略，能稳定帮生产团队省下50%到80%：
- • Haiku 4.5处理底部60%的任务：分类、检索、简单转换、JSON提取、单轮查找。价格约为每百万输入token 1美元。
- • Sonnet 4.6处理中间30%：中等复杂度推理、多步工具使用、非架构级代码生成。价格约为每百万输入token 3美元。它是大多数生产workload的性价比甜点。
- • Opus 4.6处理顶部10%：最难的问题、架构决策、新颖推理。价格约为每百万输入token 15美元。
决策树大约12行代码：
def select_model(task_type: str, complexity: str) -> str:
if task_type in {"classify", "retrieve", "extract", "transform"}:
return "claude-haiku-4-5"
if task_type in {"draft", "analyze", "reason"} and complexity != "high":
return "claude-sonnet-4-6"
return "claude-opus-4-6"advisor pattern值得多聊几句。思路是：每一轮都用Sonnet或Haiku当worker。每隔N轮，或者遇到特定条件时，比如破坏性动作、最终输出、模糊tool result，就升级到Opus做review。Opus读worker的产出，提修正意见，再交还给worker。
在重推理集中于少数几轮的workload上，实际节省更接近30%到50%。
Day 5：在重试循环烧钱前阻止它
4月，Anthropic发布了三个harness改动，合起来把API重试率推高了80倍。社区产出的分析揭示了这个模式：6,852个session，17,871个thinking block，234,760次tool call。这种重试循环一直发生在生产agent代码库里，而多数团队完全不知道。
症状：每个session的API调用数暴涨，正常8次调用完成的session现在要23次；任务完成率下降；平均响应延迟增长；每个session成本上升，而每个session的价值持平或下降。
原因几乎总是以下四种之一：模型持续调用一个坏掉的工具；harness吞掉工具错误只返回泛泛的"tool failed, please try again"；agent进入循环不断生成同一输出的变体；上游模型行为变化导致agent把正常响应解释成未完成。
修法：
MAX_STEPS上限：每个循环都有硬上限，agent达到上限时循环抛出typed exception。对多数agent来说，10是不错的起点。
结构化错误结果：工具失败时返回带有status、error type和message的结构化结果，模型可以读取并推理，而不是盲目重试。
无进展则abort：追踪agent本轮产出了哪些artifact，如果3轮过去没有创建新artifact，终止session并把trace记录下来供调查。
这三项组合可以抓住大多数重试循环。实施过的团队报告，成本分布尾部下降30%到60%。
Day 6：验证缓存真的在工作
Day 2你打开了缓存。Day 6你要验证它真的有效。
多数团队会跳过这一步。他们启用缓存，看到账单下降，宣布胜利，然后继续往前。三周后，有人加了一个功能，把动态值放到系统prompt开头附近，缓存命中率悄悄从78%掉到12%。账单慢慢回升。没人把这两件事联系起来。
要追踪的指标，是按路由分组的cache hit rate。别只看总缓存命中率，要逐条路由看。因为一条本应90%缓存的路由，即使命中率塌到30%，在平均值上也可能看起来没问题。
目标：对拥有稳定不变前缀的路由（系统prompt、工具定义），目标是70%到90%的缓存命中率。对部分稳定前缀的路由（比如用户session状态），目标是30%到50%。
如果解释不了一条路由的命中率为什么是当前这个数字，那就还没验证。你只是看了一张图，然后感觉良好。
每周跑一次审计。缓存命中率是领先指标。它下降时，账单就要上来了。
Day 7：设置告警，锁住节省
你已经完成了工作。账单降下来了。现在要让它保持低位。
没有告警，节省会漂移。团队每发布一个新功能，就会引入新的prompt。每条新代码路径，都是一次有人把50KB文档复制进系统prompt的机会。
告警项：
- • 每日总花费超过预算：选一个阈值，如果平时每天花30美元，把告警设在50美元
- • 每个session成本超过工作流阈值：比如support agent的session平均应该是0.40美元，如果单个session超过5美元，就有问题
- • 缓存命中率跌破底线：如果某条路由通常是80%，并连续三个小时掉到50%，说明prompt结构或流量模式发生了变化
分级路由效果最好：成本告警达到正常阈值的1倍到2倍时发到Slack channel，在下一个工作小时内调查；成本尖峰超过正常值5倍时发PagerDuty，立刻打断某个人；每周成本摘要发邮件给engineering manager和finance team。
合起来会是什么样子
阅读本文之前，你的状态是：
- • 每月API花费4,800美元
- • 缓存命中率27%
- • 永远全Opus
- • 没有模型路由
- • 重试静默吞掉预算
- • 没有告警
- • 成本每月增长8%
这个课程之后，你的状态是：
- • 每月API花费620美元，下降87%
- • 缓存命中率78%
- • Haiku、Sonnet、Opus按任务路由
- • 有上限的循环和结构化错误
- • 成本告警接入Slack
- • 每年大约省下50,000美元
另一个变化，是团队和账单的关系。课程之前，账单是一件发生在你身上的事。课程之后，账单是你可以掌控的东西。
这个模式会复利。团队构建的每个新功能都会继承这些纪律。六个月后，会有一个新的初级工程师问你「为什么我们又要做这个缓存？」你会给他们讲七天的故事。他们二十分钟就会内化。
毁掉这些节省的常见错误
1. 缓存prompt的易变部分。 缓存只对相同前缀有效。如果prompt顶部附近插入了timestamp或session ID，命中率就是零。把易变内容移到末尾。
2. 按模型名路由，而不是按任务复杂度路由。 模型应该是任务属性，不是团队属性。先分类任务，再选择模型。
3. 先优化，后观测。 你无法优化无法测量的东西。试图在没有instrumentation的情况下砍成本的团队，总会砍错地方。
4. 信任免费档，但不设限制。 免费档没有硬上限。在你的代码或网关里设置自己的硬上限。
5. 压缩了模型需要的上下文。 如果压缩后agent的eval分数下降，说明压缩过猛。优化目标是成本和质量的Pareto frontier，不只是成本。
6. MAX_STEPS设得太低。 这个上限是为了拦截失控循环，不是为了限制正常工作。10是合理起点。
7. 安装社区skills前不审计。 skill-security-audit会对任意skill package做23类模式检查，在安装前发现危险shell命令、凭证外传、prompt injection等问题。
说句实话
多数团队会读完这篇文章，然后继续付账单。然后他们在API成本上花的钱，比请一个工程师来做完这件事还多。
认真对待这件事的窗口就是现在。价格战正在放缓。Anthropic和OpenAI都在2026年初发布了价格更新，下一轮不太可能带来10倍折扣。
今年建立成本纪律的团队，才是会在API价格停止下降后仍然盈利的团队。
你的token账单不是模型问题。它是工程问题。工程问题会被愿意做工程的人解决。
七天。六张图。一次审计。一个降低87%的账单。现在，去跑审计。
