导读本文是一篇详细的 AI agent 成本优化指南指出 2026 年 token 费用失控主要源于工程问题而非模型选择提供7天实战计划通过审计花费、开启提示缓存、压缩上下文、按任务路由模型等措施可将月账单从 4800 美元降至 620 美元节省 87%。作者推荐先用 Helicone、Langfuse 或 Portkey 等工具建立可观测性找出高耗函数和异常然后实施提示缓存Anthropic 可达 90% 折扣、上下文预算控制和重试循环限制强调“怀疑调试”纪律以避免优化反弹。作者Himanshu (nothiingf4)是一位专注构建 AI Agent 的开发者与实践者。他热衷于快速交付高价值项目擅长通过工程优化如提示缓存、上下文压缩、模型路由和可观测性大幅降低 LLM token 成本帮助团队实现高效、可持续的 Agent 开发。Vibe Coding这个季度很多构建者悄悄停用了自己的 AI Agent因为 API 账单失控。文末有福利三个开源 Claude skills。其中一些人换了更便宜的模型输出质量变差用户流失。少数人意识到账单从来都不是模型问题是工程问题。2026 年的 token 成本重点不在你选了哪个模型。重点在于你有没有给系统接可观测性有没有正确启用缓存有没有把合适的模型路由到合适的任务有没有压缩模型不需要的上下文有没有限制重试循环有没有验证缓存命中率有没有用告警把省下来的钱锁住、不让它悄悄回弹。举个近在眼前的例子。Claude Code Opus 档位十个人的团队一年烧掉 45,000 美元。多数团队有三四款工具多数团队根本没算过这笔账。账单增长得比价值更快这就是大多数团队的现状。好消息是账单可以修。你不需要换模型不需要自己写 runtime不需要迁移框架。你只需要按正确顺序做七件事。下面是一套精确的 7 天行动手册。不是理论是具体的审计项、具体的模式、具体的代码改动。目标一周内把每月 4,800 美元的账单降到每月 620 美元。dashboard这是真实数据。两个函数五位数成本。运行这个仪表盘的团队在接入观测之前根本不知道哪些函数正在吞掉预算。这就是第一课。Day 1审计你的 token 到底花在哪里大多数团队回答不了一个问题代码库里哪个函数最贵哪个用户占了最大比例的账单哪条路由每个 session 烧掉的 token 最多如果回答不了这些问题就无法优化。这就是 Day 1。你需要先有可观测性然后才谈得上优化。2026 年真正重要的三个工具如下。[Helicone](https://www.helicone.ai/[1])。代理网关。一行代码把你的 LLM 调用路由到他们的服务。捕获每个请求、每个响应、每个 token 计数、每一美元花费。免费档每月覆盖 1 万次请求。付费计划从每席 20 美元起。适合想要零 SDK 集成开销的团队。Langfuse。开源可在 MIT 许可证下自托管。2026 年 1 月被 ClickHouse 收购。收购前每月有 2,600 万次 SDK 安装。最适合需要把数据留在自家基础设施上的团队。github - https://github.com/langfuse/langfuse[2]Portkey。一个能路由到 250 多个 provider 的网关。强项是 fallback、负载均衡以及内置的成本优化功能。如果你在多个模型 provider 之间做路由并且需要自动故障转移选它。github - https://github.com/Portkey-AI/gateway[3]lmnr。在同一个工具里追踪和评估 agent 行为。开源。如果你想把可观测性和评估 harness 绑在一起选它。Day 4 做模型路由时你会想测更便宜模型的输出是否真的撑住了质量。github - https://github.com/lmnr-ai/lmnr[4]选一个。接进去。Helicone 集成最快把它们的代理 URL 加到你现有的 LLM client 里不需要其他改动。几分钟内数据就会开始流入。然后看仪表盘。bill你要找的是前五大花费项。按总成本降序排序。看函数、用户、路由、session。几乎每个团队都会出现同一种模式两个函数吃掉 60% 的预算。有时是两个用户。有时是一个没人记得自己写过的失控 cron job。第一次做这个练习时你会觉得尴尬。会有一个每月消耗 4,000 美元的函数而团队认为它的价值只有 40 美元。会有一个用户账号花了 1,200 美元因为三个月前有人把一个脚本留在终端里持续运行。会有上周某个 tool call 出现 1.2 万次失败重试产生了零有用输出。没关系。Day 1 就是为此存在的。找出来记下来。接下来的六天会逐类修掉它们。一个具体例子。一支我合作过的团队在周一审计了他们的栈发现 47% 的账单来自一个本该在六个月前废弃的单个函数。没人检查过。这个函数仍然被一个每 15 分钟运行一次的遗留 cron job 调用。他们当天下午关掉了这个 cron账单在其他事情还没开始做之前就下降了 47%。配合这项工作的纪律我称之为 skeptical debugging。原则是当你发现一个昂贵函数时不要只删调用然后宣布胜利。你要复现成本假设根因修复它然后重新跑原始、未修改的 workload确认修复真的站住了。大多数团队做的是反面。看到昂贵函数把 prompt 砍掉 20%下张发票成本降了就翻篇了。三周后同一个函数又回到费用榜首因为他们修的是症状不是原因。有一个社区 skill 叫 skeptical-debugger把这套纪律固化成了工具。如果有时间开始审计前先装上。从 Day 1 开始我希望你追踪的指标是 cost per session。别只看月度总成本也别只看每请求成本要看每个 session 的成本。因为这才是用户真正关心的单位。如果一个 session 能给你的业务带来 10 美元价值而运行成本是 0.50 美元你是健康的。如果它要花 4.20 美元你就不健康。这个数字会告诉你自己站在线的哪一侧。Day 1 结束时你应该拿到这些数据月度总成本、前五个最贵函数、前五个最贵用户、平均 cost per session以及两三个明显需要调查的异常。这些数据是地基。没有它后面六天都是瞎猜。Day 2在所有有效位置打开 prompt caching这是整个 7 天课程里最大的杠杆。Anthropic 对 cache read 给出 90% 折扣。这是官方数字。每个缓存输入 token 的价格是基础输入价格的 0.1 倍。读缓存就能省下每一美元里的 90 美分。anthropic - https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching[5]OpenAI 提供自动缓存。不需要改代码。只要你停止修改重复内容最新模型就会对重复内容应用折扣。缓存输入 token 最高可省 90%。关键在于写入成本。Anthropic 对初始写入收取基础价格的 1.25 倍TTL 5 分钟对 1 小时 TTL 收取基础价格的 2 倍。也就是说第一次写入更贵之后每次读取便宜很多。盈亏平衡来得非常快。使用 5 分钟缓存时只要命中一次缓存就能回本。第一次命中之后都是纯节省。cache要缓存什么。系统 prompt。工具定义。会跨调用复用的大型参考文档。few-shot 示例。对整个 session 稳定的 RAG 检索结果。任何在第 N 次调用和第 N1 次调用中完全相同的内容。不要缓存什么。用户当前输入。针对这次查询新检索的数据。agent 不断演化的 scratchpad。任何会在调用之间变化的内容。代码实现如下。import anthropic client anthropic.Anthropic() response client.messages.create( modelclaude-sonnet-4-6, max_tokens1024, system[ { type: text, text: LARGE_SYSTEM_PROMPT, cache_control: {type: ephemeral}, } ], messages[{role: user, content: user_input}], )这个 cache_control 标签就是全部集成。把它加到你想缓存的 content block 上。每次访问后缓存会保持 5 分钟热度。后续每个命中相同前缀的调用对那一部分只付 0.1 倍价格。对 RAG 系统和代码助手来说缓存部分的输入通常能省 85% 到 95%。如果你的系统 prompt 是 8,000 token用户输入是 200 token你过去每次调用都为 8,200 个输入 token 付费。缓存后你先为 8,200 个 token 付一次费。之后每次调用只为 0.1 倍的 8,000 加 200 付费。输入成本下降 88%。接入这一步时有个安全提醒。Day 1 和 Day 2 安装的网关和 skills会拿到你的 API key 和 prompt。安装任何声称能优化成本的第三方 skill 前先审计它。这样的工具有很多。skill 本质上就是代码。有一个社区 skill 叫 skill-security-audit会对任意 skill package 做 23 类模式检查危险 shell 命令、混淆 payload、凭证外传、可疑网络调用、prompt injection、Unicode 技巧。它会给出 safe、review needed 或 block 的结论。每次安装前都跑一遍。这个七天课程的目标不是省了 4,000 美元 API 账单却把凭证泄漏出去。做对的团队部署第一天就能把月度账单砍半。有时更多。团队常犯的错误是缓存了错误部分。缓存易变内容命中率就是零。缓存只对相同前缀有效。如果你的系统 prompt 顶部插入了当前日期或用户名每个用户的缓存都会被打断。把易变内容移动到末尾。把不变内容放在开头。不变前缀越长命中率越高。Day 3压缩上下文Day 3 的目标是不要把模型不需要的东西发给模型。这一天会很痛。你会看着自己的 prompt意识到它们很臃肿。系统 prompt 里有三段话本来一句就够。检索上下文里塞了完整文档而你只需要两段。工具结果历史里保存了每次 tool call 的完整输出而模型其实只需要最后一次。先看一组让我清醒过来的数字。一个典型生产 agent 大致会发送200 个 token 的工具定义300 个 token 的 telemetry 摘要150 个 token 的状态记忆200 个 token 的压缩检索上下文每轮上下文开销合计 850 个 token。压缩之前同一个 agent 发送的是3,200 个 token 的工具定义完整 JSON schema5,800 个 token 的 telemetry原始日志2,400 个 token 的状态记忆所有历史 tool call3,100 个 token 的检索上下文原始文档 chunk合计 14,500 个 token。这是 94% 的削减。同一个 agent同一个任务同一个模型。在 50 个样例的 eval set 上输出质量和未压缩基线相比保持在 2% 以内。具体做法如下。带文件引用的工具结果截断。不要把一个 50 KB 的日志文件当作 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, }还有一个配套技巧。当 agent 产出一个有结构的 artifact比如带章节的报告、对比表、diff、小 dashboard把它存成磁盘上的 HTML artifact而不是以内联 markdown 形式塞进聊天。社区 skill html-artifacts 把什么时候 HTML 优于 markdown编码成了规则包括长度阈值、表格、diff、图表、交互、分享并提供了 starter skeleton。它对成本重要的原因是聊天历史不会继续累积几千 token 的 markdown 块。agent 生成一个磁盘上的 HTML 文件返回一行路径引用下一轮就不需要再为这个 artifact 的上下文付费。总结后的 scratchpad 状态。模型不需要看到过去 30 轮的每次 tool call。它需要看到一段 200 词的摘要说明尝试过什么以及当前状态的新鲜视图。Microcompact。每轮都运行。如果同一个工具用相同输入被调用了多次把所有重复结果替换成一个缓存引用。对反复调用 grep 的 agent可以省下数千 token。Snip compact。丢弃最旧消息同时保留最近几轮作为受保护尾部。即使更早的历史被压缩模型仍能保留最近 N 轮的完整保真度。Auto compact。当 token 使用量超过阈值时运行总结。用摘要替换旧消息。记录已经发生过压缩避免 agent 下一轮又去总结摘要。把这些技术串起来的核心概念是每轮预算。多数 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 美元。把它留给真正需要它的工作。公开生产案例也能看到这个结论。KanseiLink 跑了一个中型企业场景把常规高频任务从全 Sonnet 切到 Haiku 加批处理后同一 workload 的账单从 54 美元降到 9 美元。路由部分的成本降低 83%。一家金融服务团队报告整体成本下降 37%。每天省 1,001 美元每年省 365,000 美元。内部 eval 显示质量没有下降。Anthropic 自己也测试了 advisor pattern。用 Opus 当资深 reviewer偶尔检查 Sonnet 或 Haiku 的输出。相比全 Opus成本下降 11%benchmark 质量提升 2%。advisor pattern 值得多聊几句因为这是多数团队用得还不够的路由模式。思路很简单。每一轮都用 Sonnet 或 Haiku 当 worker。每隔 N 轮或者遇到特定条件时比如破坏性动作、最终输出、模糊 tool result就升级到 Opus 做 review。Opus 读 worker 的产出提修正意见再交还给 worker。你在真正需要判断力的那部分拿到 Opus 的大部分价值而在不需要的部分付的是 Haiku 或 Sonnet 的价格。Anthropic 公开的数字相比全 Opus 省 11%、质量提升 2%其实低估了这个模式因为他们测的是一个窄 benchmark。我聊过的团队在重推理集中于少数几轮的 workload 上实际节省更接近 30% 到 50%。代码里的决策树如下。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大约 12 行代码可以省下你 50% 的账单。Day 4 常见错误是凭直觉路由而不是凭测量路由。团队猜某个任务需要 Opus因为输入很长或者 prompt 很细。先跑便宜模型。用 50 个样例测输出质量。如果通过就结束。如果失败再升级到下一档。便宜模型通过的次数通常比你预期更多。Day 5在重试循环烧钱前阻止它Claude Code 2026 年 4 月的 regression是这一天的标准案例。4 月Anthropic 发布了三个 harness 改动合起来把 API 重试率推高了 80 倍。可见 thinking 长度中位数下降 73%。模型不断被要求重试却没有产出有用结果。用户在 Anthropic 监控发现之前就感受到了。社区产出的分析揭示了这个模式。6,852 个 session。17,871 个 thinking block。234,760 次 tool call。这种重试循环一直发生在生产 agent 代码库里而多数团队完全不知道。症状如下。每个 session 的 API 调用数暴涨。正常 8 次调用完成的 session现在要 23 次。任务完成率下降。session 运行更久但产出更少。平均响应延迟增长。每个 session 成本上升而每个 session 的价值持平或下降。原因几乎总是以下四种之一。模型持续调用一个坏掉的工具工具持续以同样方式失败。模型把失败解释为「我应该换种方式再试一次」于是带着轻微变化重试。harness 没有 step limit所以重试一直继续。harness 吞掉工具错误只返回一个泛泛的 tool failed, please try again 字符串。模型没有可操作信息于是盲目重试同一个调用。agent 进入一个循环不断生成同一输出的变体却不检查输出是否已经存在。上游模型行为变化导致 agent 把一个正常响应解释成未完成然后调用下一个工具来继续完成工作。讲一个具体故事。我的一个朋友在一家小咨询公司跑 research agent。他们的账单在三周内悄悄翻了三倍。Day 1 的审计没发现异常。总请求数看起来正常。后来他们接入逐轮级别的观测发现每 9 个 session 里就有 1 个在终止前发起 187 次 tool call。agent 卡在同一个 web search 上用同一个 query 反复搜索因为搜索返回空结果而 agent 把空结果理解成「我应该再试一次」。没有重试上限。一个坏 query就让 agent 在单个 session 里烧掉 14 美元。三周下来这个模式吃掉了他们 38% 的账单。另一个来自更大公司的同类故事。一个 coding agent 本应运行 lint、format然后 commit。format 步骤偶尔会因为上游工具 bug 崩溃。agent 看到崩溃决定调查打开崩溃工具的源码猜一个原因尝试 patch 工具本身运行打过补丁的工具看它再次崩溃再猜再 patch。每次 format 失败会触发六轮迭代。agent 的调查行为本质上是披着生产性工作外衣的重试循环。一个周二下午在任何人注意到之前花掉了 210 美元。修法如下。harness 里的 MAX_STEPS 上限。每个循环都有硬上限。agent 达到上限时循环抛出 typed exception并暴露到日志。具体数字可以按经验选择但对多数 agent 来说10 是不错的起点。结构化错误结果。工具失败时返回带有 status、error type 和 message 的结构化结果。模型可以读取结构化结果并推理而不是盲目重试。tool call 的 idempotency key。如果 agent 准备第三次用相同参数调用同一个工具说明有问题。harness 可以短路返回上一次调用的缓存结果。无进展则 abort。追踪 agent 本轮产出了哪些 artifact。如果 3 轮过去没有创建新 artifact终止 session并把 trace 记录下来供调查。这四项组合可以抓住大多数重试循环。实施过的团队报告成本分布尾部下降 30% 到 60%。昂贵 session 不再昂贵。Day 6验证缓存真的在工作Day 2 你打开了缓存。Day 6 你要验证它真的有效。多数团队会跳过这一步。他们启用缓存看到账单下降宣布胜利然后继续往前。三周后有人加了一个功能把动态值放到系统 prompt 开头附近缓存命中率悄悄从 78% 掉到 12%。账单慢慢回升。没人把这两件事联系起来。要追踪的指标是按路由分组的 cache hit rate。别只看总缓存命中率要逐条路由看。因为一条本应 90% 缓存的路由即使命中率塌到 30%在平均值上也可能看起来没问题。cache目标如下。对拥有稳定不变前缀的路由系统 prompt、工具定义、持久上下文目标是 70% 到 90% 的缓存命中率。对部分稳定前缀的路由比如用户 session 状态目标是 30% 到 50%。如果某条路由的命中率低于 30%而你认为它应该被缓存那缓存结构就是错的。这一天Day 1 提到的 skeptical debugger 纪律最有价值。Day 6 的诱惑是看一眼仪表盘看到 cache hit rate然后说完成了。抵抗这个诱惑。验证不是仪表盘数字。验证是你可以挑三条具体路由并解释每一条为什么会达到目标命中率。如果解释不了就还没验证。你只是看了一张图然后感觉良好。复现单条路由的成本。假设会产生当前命中率的缓存结构。确认这个结构与你部署的内容一致。重新运行原始、未修改的 workload。这才叫验证。如何调试低命中率。检查前缀长度。Anthropic 要求达到最低 token 数后缓存才会生效。Sonnet 需要 1,024 个 token。Haiku 需要 2,048 个 token。如果你的不变前缀短于阈值就不会发生缓存。检查开头附近的易变字段。当前日期、用户名、当前模型名。任何会在调用之间变化并且位于 cache_control marker 之前的内容都会打断这个用户的缓存。检查 TTL。5 分钟 TTL 适合热路由。1 小时 TTL 适合访问不那么频繁但前缀稳定的路由。如果你的流量模式意味着多数缓存读取发生在上次读取 8 分钟之后5 分钟缓存会在复用前过期。检查 cache_control 放置位置。cache control 标记不变前缀的结束位置。如果位置放错缓存会比预期更短。每周跑一次审计。缓存命中率是领先指标。它下降时账单就要上来了。Day 7设置告警锁住节省你已经完成了工作。账单降下来了。现在要让它保持低位。没有告警节省会漂移。团队每发布一个新功能就会引入新的 prompt。每条新代码路径都是一次有人把 50 KB 文档复制进系统 prompt 的机会。每个新承包商都是一个还没内化这套纪律的人。大家忙着 shipping 时账单慢慢爬升。告警能让你在漂移变成危机之前抓住它。alert告警项如下。每日总花费超过预算。选一个阈值。如果你平时每天花 30 美元把告警设在 50 美元。告警是为异常准备的不是为日常波动准备的。每个 session 成本超过工作流阈值。你的 support agent 的 session 平均应该是 0.40 美元。如果单个 session 超过 5 美元就有问题。告警并调查。缓存命中率跌破底线。如果某条路由通常是 80%并连续三个小时掉到 50%说明 prompt 结构或流量模式发生了变化。单个用户占据超过每日总花费的 N%。通常意味着有脚本失控。最坏情况下是 API key 被盗用。告警路由到哪里。多数团队有效的模式是分级路由。成本告警达到正常阈值的 1 倍到 2 倍时发到 Slack channel在下一个工作小时内调查。成本尖峰超过正常值 5 倍时发 PagerDuty立刻打断某个人。每周成本摘要发邮件给 engineering manager 和 finance team。5 倍尖峰打断人。周报进收件箱周一早上扫一眼。这些工具开箱就支持。Helicone 在仪表盘里有 alert 配置。Langfuse 通过 console 提供同类功能。Portkey 通过 gateway events 路由告警。设阈值设路由。然后在告警触发前忘掉它。不用盯着仪表盘。该触发时告警自己会触发。三个让这套纪律留下来的 skills上面七天会砍掉你的账单。真正的复利发生在下个季度当你不再主动关注成本时纪律仍能活下来。有三个 Claude skills开源、MIT 许可可以让纪律结构化而不是靠记忆维持。github - https://github.com/Himanshu040604/Claude-Skills[6]skill-security-audit。第一个该安装的 skill。每个可观测性网关、每个优化 skill、每个第三方 token tracker都会以能访问 API key 和 prompt 内容的权限运行。多数构建者安装社区 skills 的方式和安装 npm package 一样看 README然后粘贴安装命令。这是安全错误。skill-security-audit 会在你安装前把 23 类模式应用到任意 skill package。危险 shell 命令、混淆 payload、凭证外传、可疑网络调用、prompt injection、unicode 技巧。它会返回 safe、review needed 或 block 的结论。第一次在即将安装的 skill 上运行它时你至少会发现一个之前不知道的网络调用。安装前发现比安装后发现好。skeptical-debugger。原则是复现、假设、修根因然后重新运行原始、未修改的 workload确认修复成立。它会标记工程师在 deadline 压力下容易选择的廉价捷径。跳过 marker、移除 assertion、吞掉错误、删除测试。在 token 成本工作中类似的作弊模式同样常见。为了命中数字而缩短系统 prompt却不检查 eval。因为仪表盘命中率看起来更好就缓存错误内容。因为 Haiku 更便宜就把任务路由过去却不测输出是否仍然通过。安装 skeptical-debugger并用它检查你的优化改动。它决定了你拿到的是实际 87% 降幅还是一个月后会反弹的纸面降幅。html-artifacts。三者中最小但在七天课程的 Day 3 就会回本。原则很简单。当 agent 产出多段报告、对比表、diff、图表或任何交互式内容时正确输出是保存到磁盘的 HTML 文件并在聊天中返回路径引用。不要以内联 raw markdown 输出。这个 skill 提供了一套清晰测试判断 HTML 何时优于 markdown包括长度、表格、diff、图表、交互、分享并附带五个 worked playbook 和一个 starter skeleton。成本角度很直接。聊天历史中的每个几千 token markdown 块都是你在后续每一轮持续付费的 token。把 artifact 移到磁盘聊天历史就不再累积它。May 9cp -r Claude-Skills/skill-security-audit ~/.claude/skills/ cp -r Claude-Skills/skeptical-debugger ~/.claude/skills/ cp -r Claude-Skills/html-artifacts ~/.claude/skills/Claude Code 会在下次启动时自动发现该目录中的任何 skill。不需要 registry不需要 config不需要 rebuild。这些不是生态里唯一有用的 skills。它们是和上面七天计划最直接配套的三个。如果想继续探索权威列表是 Anthropic 官方 skills repo - https://github.com/anthropics/skills[7]以及社区维护的 Awesome Claude Skills - https://github.com/travisvn/awesome-claude-skills[8]目录。安装任何新东西前都先审计。这正是 skill-security-audit 的用途。合起来会是什么样子阅读本文之前你的状态是每月 API 花费 4,800 美元。缓存命中率 27%。永远全 Opus。没有模型路由。重试静默吞掉预算。没有告警。成本每月增长 8%。这个课程之后你的状态是每月 API 花费 620 美元下降 87%。缓存命中率 78%。Haiku、Sonnet、Opus 按任务路由。有上限的循环和结构化错误。成本告警接入 Slack。随着功能发布cost per session 持平或下降。每年大约省下 50,000 美元。对小团队来说这是有意义的钱。对更大团队来说同样改动在规模化后会带来数倍收益。去年为意外超支支付 50,000 美元的同一支团队现在支付 6,500 美元并且在同一窗口内发布更多功能。另一个变化是团队和账单的关系。课程之前账单是一件发生在你身上的事。课程之后账单是你可以掌控的东西。参与优化的团队成员会对哪些功能昂贵、哪些功能不昂贵形成直觉。这些直觉几乎不需要成本却会永久回报。这个模式会复利。团队构建的每个新功能都会继承这些纪律。成本纪律会变成 shipping 的一部分而不是做一次就忘的一件事。六个月后会有一个新的初级工程师问你「为什么我们又要做这个缓存」你会给他们讲七天的故事。他们二十分钟就会内化。复利继续复利。毁掉这些节省的常见错误缓存 prompt 的易变部分。缓存只对相同前缀有效。如果 prompt 顶部附近插入了 timestamp 或 session ID命中率就是零。把易变内容移到末尾。把不变内容放在开头。长不变前缀等于高命中率。按模型名路由而不是按任务复杂度路由。团队会说「我们所有东西都用 Sonnet」或「我们标准化到 Haiku」仿佛模型是团队属性。模型应该是任务属性。先分类任务再选择模型。先优化后观测。你无法优化无法测量的东西。试图在没有 instrumentation 的情况下砍成本的团队总会砍错地方。砍掉 Opus 调用后发现那些 Opus 调用其实是需要的。缩短系统 prompt 后发现 agent 依赖的正是被删掉的部分。先接入观测。测钱花在哪里。然后优化。信任免费档但不设限制。免费档没有硬上限。它们有软上限意思是「超过后会计费」。在你的代码或网关里设置自己的硬上限。如果失控脚本一夜之间烧穿免费档你要为这个意外付费。压缩了模型需要的上下文。你可能过度压缩。如果压缩后 agent 的 eval 分数下降说明压缩过猛。把输出质量和成本一起追踪。优化目标是成本和质量的 Pareto frontier。不只是成本。MAX_STEPS 设得太低。如果把循环上限设为 3agent 会在完成真实工作之前退出。这个上限是为了拦截失控循环不是为了限制正常工作。10 是合理起点。20 很宽裕。选择前先测你的分布。安装社区 skills 前不审计。你添加到 agent 的每个 skill都会以 agent 拥有的同等权限运行。如果你不会在不阅读的情况下把陌生人的脚本粘进终端也不要在不审计的情况下把他们的 SKILL.md 粘进 skills 目录。任何安装前都先运行 skill-security-audit。永远如此。说句实话多数团队会读完这篇文章然后继续付账单。他们会跟自己说省这点钱不值得花七天时间。他们会跟自己说工程精力更该花在功能上。他们会跟自己说下个季度再做。然后他们在 API 成本上花的钱比请一个工程师来做完这件事还多。做过一次的团队复利就会开始。此后发布的每个新功能都会继承优化纪律。资深工程师把模式带进下一个代码库。初级工程师不需要专门去教自己就把习惯吸收了。不做的团队会继续运行同一个工作流。从每月 20 美元涨到每月 400 美元。账单增长比团队收入更快。到某个时刻数学就不成立了。认真对待这件事的窗口就是现在。价格战正在放缓。Anthropic 和 OpenAI 都在 2026 年初发布了价格更新下一轮不太可能带来 10 倍折扣。今年建立成本纪律的团队才会是在 API 价格停止下降后仍然盈利的团队。你的 token 账单不是模型问题。它是工程问题。工程问题会被愿意做工程的人解决。七天。六张图。三个 skills。一张降低 87% 的账单。现在去跑审计。原文[9]参考阅读QQ音乐Harness Engineering实践Hermes Agent 到底能干什么16 个分类、276 个用例的完整答案Evals 到底在评什么一文拆解 AI 评估的三种方法做 AI Agent 之前先装好这 5 样东西我把 Karpathy 的 AutoResearch 搬到了软件开发领域效果炸了Referenceshttps://www.helicone.ai/: https://www.helicone.ai/https://github.com/langfuse/langfuse: https://github.com/langfuse/langfusehttps://github.com/Portkey-AI/gateway: https://github.com/Portkey-AI/gatewayhttps://github.com/lmnr-ai/lmnr: https://github.com/lmnr-ai/lmnrhttps://docs.anthropic.com/en/docs/build-with-claude/prompt-caching: https://docs.anthropic.com/en/docs/build-with-claude/prompt-cachinghttps://github.com/Himanshu040604/Claude-Skills: https://github.com/Himanshu040604/Claude-Skillshttps://github.com/anthropics/skills: https://github.com/anthropics/skillshttps://github.com/travisvn/awesome-claude-skills: https://github.com/travisvn/awesome-claude-skillshttps://x.com/nothiingf4/status/2056381531648889007如果你也在关注 AI 应用如何真正落地到生产环境2026.6.26 - 6.27 GIAC 深圳站值得关注。这次大会会集中讨论智能应用开发、架构演进以及来自一线实践的经验与案例。识别二维码可申请大会体验门票点击阅读原文了解大会详细议程。