文章 / AI实践

省 Token 不是少打字：一个工程师踩了 85 个 Skill 的坑之后

9,038 字 阅读约 20 分钟
#AI #Token #上下文工程 #Prompt Caching #AI工作流
目录 ▾

前阵子，我整理了一次 Hermes Agent 的技能目录。

里面有 85 个文件，每天会用到的，大概只有 5 个。

其中一份个人档案写了 5000 多字，履历、项目经历、写作偏好、内容方法全放在里面。初衷很直接：让 Agent 更了解我，做事时少解释一点。

结果正好相反。

写微博，它带上我的完整履历；做复盘，它加载一整套内容方法；分析技术问题，它还记得我做个人品牌时的表达要求。系统提示词越来越长，输出开始变慢，也更容易被无关规则带偏。

我一开始以为，把提示词写短一点就能省 Token。后来发现，这只是最小的一部分。

更该控制的是，AI 每一轮到底读了什么。

Token 到底花在哪里？

很多人只盯着自己输入的那句话。

比如你问：“帮我总结这份文档。“看起来只有十几个字，好像花不了多少 Token。

但模型实际收到的内容，可能还包括：

Token 来源常见内容容易忽略的浪费
常驻指令系统提示词、全局规则、个人档案每轮都带上，很少变化
对话历史前面所有提问、回答和修改记录废弃方向也一直留在里面
外部资料附件、知识库内容、代码和会议纪要经常整份读取，实际只用几段
工具结果搜索结果、日志、接口返回值返回太多字段和无关明细
模型输出正文、解释、表格、分析过程”全面详细”很容易写过头

你眼前只发了一句话，模型背后可能已经搬来一整张工作台。

一次提问，不等于一次模型调用

我们平时说”问了 AI 一次”，很容易把事情看简单。

普通聊天里，一次提问就是一次输入、一次输出。但在 Agent 工作流里，一次提问通常会拆成：

你提问题 → 模型判断要做什么 → 调用搜索/读文件/查日志 → 工具返回结果 → 模型再读一遍上下文和工具结果 → 不够就继续调工具 → 最后生成答案。

这里最容易被忽略的一点是：每一次模型调用，都不是只带上”新问题”。

模型是无状态的。它每次都要重新拿到上下文，才知道你们前面聊过什么、项目规则是什么、当前任务做到哪一步、工具刚刚返回了什么。前面每一轮的历史、工具返回、模型输出，都可能进入下一轮输入。

这就是 Token 滚雪球的来源。

你本轮新增的问题可能不到 100 个 Token，但这一轮模型实际处理的上下文可能是 5 万、10 万。任务越长，轮次越多，历史越厚，后面每一句追问都更贵。

很多 Token 浪费，发生在系统每一轮都把一大包旧东西重新打包的时候。

先看懂账单上的四列

不同平台、不同模型的价格会变，缓存策略也不完全一样。但你只要抓住四类成本，就能理解大部分账单。

第一类是 Input（输入）。 不只是你打出来的那句话，还包括系统提示词、开发者规则、工具描述、Skill、历史对话、外部资料、工具返回内容。很多人以为自己只输入了几十个字，实际上真正进入模型的输入可能是整个工作现场。

第二类是 Output（输出）。 模型回答的正文、解释、代码、工具调用指令都算在输出里。绝大多数计费表里，输出单价高于输入。即使具体倍数不同，方向很明确：废话越多，成本越高；而且本轮输出还会成为下一轮历史输入，继续被重复携带。

第三类是 Cache Read（缓存读取）。 如果平台支持 Prompt Caching，前面一段稳定且重复的上下文可以命中缓存。命中以后，重复读取这段内容会便宜很多，也可能更快。

第四类是 Cache Write（缓存写入）。 第一次把稳定前缀写进缓存，可能要付额外成本。它像在为后续多轮调用铺路。后面能不能赚回来，取决于这段前缀是否稳定、是否会被反复使用。

所以 Token 成本不能只按”你问了什么”理解，更要看三件事：

模型每轮搬了多少上下文； 为了完成任务调用了几次模型； 固定上下文有没有命中缓存。

这也是为什么同样一句”帮我优化下”，有时候很便宜，有时候很贵。

2026 年主流模型价格参考

为了让后面的算法有点坐标系，我把 2026 年 8 月主流模型的价格放在这里。不同平台会有浮动，但量级差距大致是这样：

模型输入（$ / 百万 Token）输出（$ / 百万 Token）缓存输入（命中）上下文
Claude Opus 4.75.0025.000.50（90% off）200K（1M beta）
Claude Sonnet 4.63.0015.000.301M
Claude Haiku 4.51.005.000.10200K
GPT-5.42.5015.000.25（90% off）272K（Codex 1M 实验）
Gemini 3.1 Pro2.0012.000.20（90% off，≤200K）1M（>200K 触发 $4/$18）
DeepSeek V4 Flash国内调价后极低同上命中 cache 后更便宜128K 量级

几个值得记住的对比：

Opus 4.7 输入是 GPT-5.4 的 2 倍，输出约 1.67 倍，但在编码、Agent 多步、文档推理这类长链路任务上明显领先。 Gemini 3.1 Pro 的 1M 上下文最长，但超过 200K 触发长上下文 tier（$4/$18），缓存最低门槛 32K token，对短前缀不友好。 DeepSeek V4 Flash 在国内是”够用且敢长期开”的档位——我自己跑过一个月，14.5 亿 Token，79 元。

便宜的模型不是替你省钱的，是替你”敢把 AI 当基础设施”的。这一点我们后面会回到。

Token 的目标是 ROI，不是越少越好

我现在更愿意用一个公式看 Token：

有效使用 = 效果 / 成本

效果要拆成三件事。

第一，质量。 它有没有一次做对？有没有少返工？产出能不能直接用？一个回答很短但方向错了，后面还要追问五轮，并不便宜。

第二，速度。 它是不是减少了来回确认？是不是更快到达可执行结果？提问更精准、上下文更干净，既省 Token，也省时间。

第三，沉淀。 这次消耗能不能变成下次的资产？比如沉淀成一个模板、一个 Skill、一份检查清单、一段可复用脚本。如果每次都从零开始，同一个坑反复解释，那就是一次性消耗。

成本也可以拆成四个乘子：

调用次数 × 每轮 Token 量 × 模型单价 × 缓存系数

这四个乘子是相乘关系。任何一个失控，都会把账单放大。

一个任务如果提问模糊，模型会多走几轮；上下文又很臃肿，每一轮都很大；还选了高价模型；前缀又经常变化，缓存打不中——四个问题叠在一起，成本就会成倍放大。

反过来也一样。减少无效调用，压住每轮上下文，用合适档位的模型，保持稳定前缀，账单会明显变薄。更重要的是，结果通常也会更准。

所以别把”省 Token”理解成”少打几个字”。真正的大头，在系统背后反复搬运的上下文、不断增长的历史、过长的输出、多余的工具往返，以及没命中的缓存里。

省 Token 的核心原则只有一句：别让 AI 每轮重读无关内容、重复走无效路径、输出没人需要的东西。

八个能直接抄走的动作

动作 1：把提问变精准，减少调用次数

模糊提问很贵。

原因不在这句话本身很长，而在它会让模型进入穷举模式。

比如你问：

订单接口有点慢，帮我优化下。

AI 不知道慢在哪里，也不知道你怀疑哪一层。它可能去扫业务实现、各层拦截器、数据访问层、SQL、下游调用、线程池、GC，再给你一份”接口优化建议大全”。

这类答案看起来努力，实际很容易泛而不中。

换一种问法：

@订单服务#下单方法 近一周 P99 从 300ms 涨到 2s，优先查数据访问层。输出疑点清单和最小修复 diff，不展开 JVM 通用优化。

锚点明确，目标明确，边界明确，输出格式明确。模型不用先替你猜”慢在哪里”，可以直接进入目标路径。

精准提问拆成三件事：

给锚点。 文件、类、方法、行号、报错时间、日志片段、文档标题，都比一句模糊描述有用。能 @ 到具体文件，就不要让 AI 在全仓库盲搜；能 @ 到符号，就不要只写文件名。

给目标。 排查根因、写修复 diff、做代码 review、整理成文档、生成测试用例——这些目标不一样，模型要读的材料也不一样。

给输出合同。 比如”只输出 3 条疑点 + 1 个建议""用表格列出风险和验证方式""给最小 diff，不重构”。输出合同越清楚，越少出现写了一大段又被你推翻的情况。

省 Token 的关键不是少写几个字，是把该说的一次说完整。

动作 2：一会话一件事，长会话留交接单

长会话是 Token 成本里最隐蔽的放大器。

一个会话从需求分析聊到后端实现，再聊到代码检查，最后又开始写发布文档。人觉得这是同一个项目，AI 却要每轮带着越来越厚的历史。

前面讨论过但已经废弃的方案，仍然在上下文里。前面生成过但后来改掉的代码，也可能继续进入下一轮。前面随口提到的限制，可能和新的目标互相干扰。

这时再补一句”刚才那个方向不要了”，并不能真正让历史消失，只是又增加一层解释。

更好的方式是：一个会话只服务一个相对独立的任务。需求分析是一段，实现某个功能是一段，代码 review 是一段，发布文档是另一段。阶段结束时，用一份短交接单带走必要信息：

  1. 当前目标是什么
  2. 已经确认了什么
  3. 哪些方向被否掉了
  4. 哪些文件被改过
  5. 下一步要做什么
  6. 验收标准是什么

然后开新会话继续。

这不是形式上的整洁，目的是让下一轮输入只带必要上下文。尤其在 Agent 编码、长文改稿、复杂资料整理里，这个动作非常明显。

长会话不是不能用。真正有连续推理依赖的任务，比如复杂方案推演、连续调试、需要保留上下文的审查，可以留在同一个会话里。但任务边界已经切换时，继续拖着旧历史，通常是在为无关信息付费。

特别要保留”已废弃方向”，否则 AI 很容易把旧方案重新端上来。

动作 3：先定位再读取，精准引用

很多人用 AI 的方式是：

你先把这个仓库看一遍。

或者：

你先读完这些资料，再帮我总结。

这当然省心，但不省 Token，也不一定更准。

代码仓库里，真正相关的可能只有几个文件；一份长日志里，真正有价值的可能是报错前后几十行；一个知识库里，真正命中的可能只有两三篇笔记；一个 PPT 或会议纪要里，真正要转成文章的可能是结构、案例和关键判断。

正确的顺序是：

先定位，再读取；先片段，再全文。

处理代码时，先看目录、符号、引用关系；处理日志时，先锁定时间、错误码、关键字；处理文档时，先看标题、目录、摘要；处理知识库时，先搜索，再读命中的几段。

这里有一个很实用的判断：

你能替 AI 指出入口，就不要让它全局摸索。

比如”改下订单服务的下单校验”，模型可能需要 Glob、Grep、Read 几轮才能定位到目标位置。但如果你直接 @订单服务#校验方法，它可以少走很多盲搜路径。

精准引用有两个好处：减少工具调用次数，减少模型误读无关文件的机会。

不要把 AI 当成一个需要”先熟悉全局”的新人。大多数任务里，它更像一个即时协作者：你给它准确现场，它才更容易直接动手。

动作 4：四层上下文，Skill 按需加载

清理完那批 Skill 后，我没有把它们全部删掉，而是换了存放方式。

层级放什么什么时候加载
核心层少量稳定偏好、长期边界、基本身份每次任务都带
路由层Skill 名称、用途和触发条件先判断该调用谁
任务层当前 Skill 的完整规则、模板和案例任务命中后再加载
资料层历史文档、原始记录、低频参考资料搜索到相关片段时再读取

这套结构的目标很简单：东西照样保存，但不要同时摊在桌上。

核心层保持轻，保证 Agent 知道基本边界；路由层只负责找到入口；任务层按需展开；大量资料继续放在外部文件和知识库里，需要时再搜。能力没有减少，常驻上下文却轻了很多。

每个 Skill 的入口只保留三件事：它解决什么问题、什么时候触发、完整规则在哪里。只有任务真的命中，才加载完整流程。写公众号时读取写作 Skill，查数据库问题时读取技术 Skill，两者不应该同时出现。

这也是上下文工程和普通 Prompt 最大的区别。

Prompt 更像一次性的表达；上下文工程更像系统设计：哪些东西常驻，哪些东西路由，哪些东西按需加载，哪些东西交给工具确定执行。

一个常被忽视的点：模型负责判断，工具负责执行。

能用 CLI 一次返回清楚结果的，不必强行走 MCP；能用脚本稳定处理的，不必让模型每次现场推理；高频能力可以常驻，低频能力应该按需加载；Skill 入口只保留触发条件和流程骨架，细节放进 reference，需要时再读。

好的 Skill 不该是一份巨长说明书天天常驻在上下文里，它更像一套可被路由、可被展开、可被验证的操作入口。

动作 5：输出合同 + 输出压缩

很多人只关心输入 Token，忽略输出 Token。

但输出通常更贵，而且本轮输出会进入下一轮历史。这意味着冗长输出有复利成本。

模型这轮写了 3000 字解释，你下一轮只问”把第二点改一下”，那 3000 字很可能仍然被带进上下文。你每追问一次，都在为前面那段长输出继续付费。

所以做 Agent 任务时，我现在会更明确地限制输出：

只给结论，不解释过程。 最多 5 条，每条不超过 40 字。 只输出可执行 diff，不写背景说明。 先给 3 个疑点和验证命令，等我确认后再改代码。

当然，这不是说所有输出都要短。如果是在写文章、做方案、准备分享，长输出本身就是交付物，那该花就花。真正要压的是那些没有阅读价值、没有决策价值、还会进入下一轮上下文的铺垫、重复解释和宽泛建议。

输出压缩的目标是提高信噪比，不是让回答显得冷冰冰。

而在给输出合同之前，先给读者、目的、长度、格式和禁区。比如：

面向产品经理，用 300 字说明问题、影响和建议；保留 3 个关键数据，不展开技术实现。

读者、目的、长度、格式和禁区越明确，越少出现”写了一大段又全部推翻”的情况。

动作 6：模型分档，匹配优先

省 Token 有一个常见误区：永远用最便宜的模型。

这不一定省钱。简单任务用贵模型是浪费；复杂任务用便宜模型反复失败，也是浪费。

我更建议按任务分档。

轻量任务：格式整理、会议纪要初筛、简单摘要、批量分类、改错别字、生成基础测试——可以用 Haiku 4.5、Gemini Flash、DeepSeek V4 Flash 这类便宜档。

主力任务：常规编码、文章改稿、普通方案整理、代码 review——可以用 Sonnet 4.6、GPT-5.4 这类默认主力。

高复杂任务：架构决策、疑难根因定位、复杂交互方案、多方案权衡、关键文档定稿——再上 Opus 4.7、Opus 5、Gemini 3.1 Pro 这类旗舰。

2026 年新增的成本旋钮：effort 参数

过去控制思考深度靠 budget_tokens，2026 年这套机制已经被废弃了。Opus 4.7/4.8、Sonnet 5 这些新模型上，旧配置直接 400 报错。

新方式是 thinking.type: "adaptive" 配合 output_config.effort，五档可调：

Effort 等级适合场景Token 倍数（vs 纯输出）
low分类、提取、子 agent、高量级流水线1.1–1.5×
medium常规分析、编程、标准 Agent 工作流1.5–3×
high（默认）复杂编程、规划、多步骤工具调用3–10×
xhigh高难度推理、长 horizon 编码10–30×
max前沿难题，成本不敏感不设上限

为什么这件事重要：effort 控制的是思考 token + 输出 + 工具调用的总和。思考默认开启，一个看起来简单的请求，如果默认跑 high effort，可能先想 8000 token 再回你 2000 字。

值得注意的几个坑：

第一，迁移老代码会突然全错。 把 thinking.type: "enabled" + budget_tokens 套到 Opus 4.7 上，直接 400。如果再叠加 effort: "xhigh"，更是必错。

第二，max_tokens 是硬天花板，包含思考。 你以为设了 4096 是给回答用，结果模型先思考 3500 token 再回答 500 字就截断。xhigh 及以上时，官方建议 max_tokens 起步 64000。

第三，新分词器悄悄涨价。 Sonnet 5 和 Opus 4.7 都换了新分词器，但涨幅按内容类型差别很大。以 Sonnet 5 实测数据看：英文文本约 1.42 倍、Python 代码约 1.27 倍、简体中文约 1.01 倍。Opus 4.7 官方披露 1.0–1.35 倍，社区实测代码和结构化数据涨幅更大——系统提示词能涨到 1.46 倍，密集 YAML 最高 1.52 倍。单价不变，不代表成本不变。

第四，同一任务中途切模型，可能破坏缓存。 很多平台的缓存会按模型、前缀和会话状态隔离。你在一个长任务里先用高价模型，后面切到便宜模型，以为在省钱，实际可能让已经积累的上下文按新模型重新计算，旧缓存也用不上。

更稳的方式是：开会话前先判断任务档位。如果要降档，就把阶段结论压缩清楚，开新会话继续；不要在同一个不断膨胀的会话里频繁切来切去。

模型选择看任务匹配，不看价格排序。

动作 7：稳定前缀，让缓存真的生效

Prompt Caching 很像一件容易被高估、也容易被低估的事。

高估它的人，会以为只要有缓存，塞多少上下文都没关系。低估它的人，完全不管理固定前缀，让系统每轮都按原价处理重复内容。

更合理的做法是：把稳定前缀当成一种资产。系统提示词、长期规则、工具定义、项目入口、Skill 路由，如果经常被重复使用，就应该尽量稳定。

三家平台的缓存机制不一样

2026 年，OpenAI、Anthropic、Google 三家的 Prompt Caching 实现差别很大，写法、最低门槛、TTL 都不同：

维度ClaudeOpenAIGemini
触发方式显式 cache_control 或自动模式完全自动，无 code 改动implicit 自动 + explicit 手动
最低门槛1024 token1024 token32,768 token（explicit）
默认 TTL5 分钟5–10 分钟，GPT-5.5+ 默认 24himplicit 不可控，explicit 默认 1h
写入溢价5min: 1.25× / 1h: 2×无explicit 按小时收 storage
命中折扣90% off90% off（GPT-5.x 系列）75–90% off
最大断点4 个 explicit自动1 个 explicit object

几个对实操有影响的点：

Claude 的缓存读不算 rate limit。 高频读同一前缀，相当于白嫖 ITPM。 Claude 的 5min 缓存命中会刷新 TTL。 只要持续在用，不会过期。 1 小时缓存适合 Agent 跨分钟级操作。 如果你的 side-agent 要跑 10 分钟，5 分钟缓存会过期，1h 是对的。 OpenAI 的 24h retention 在 GPT-5.5+ 上是默认免费。 不需要单独申请。 Gemini 的 explicit 缓存适合大型静态文档，不适合短系统提示。 32K 起步门槛把短前缀挡在外面。 Claude 缓存 + Batch API 可叠加，最高 95% off。 Sonnet 4.6 batch + cache read 实际是 $0.15/M input，相当于标价的 5%。

但所有这些机制都有一个边界：缓存只能降低重复内容的计费成本，不能让无关内容变得有用。

上下文里常驻 20 份无关 Skill，即使命中缓存，也还是会干扰模型注意力。Anthropic 自己的多 agent 研究系统实测：隔离上下文（每个子 agent 独立 context）消耗 15 倍 token，但任务表现好 90.2%——他们付了 15 倍的钱，因为模型注意力涣散的代价比 token 贵。

所以顺序应该是：先精简，再稳定，再谈缓存。

不要在前缀里塞时间戳、随机 ID、临时变量；不要在同一会话中途频繁加新规则、新 Skill、新 MCP；不要把一次性资料放进长期规则；不要把项目细节全部写进 AGENTS 或全局提示词。

长期规则只放长期有效的东西。业务细节、版本坑、案例、模板，应该放在可检索资料里；需要时读取，而不是每次都带上。

稳定前缀的价值在于：一次设计，多轮受益。

动作 8：该花的 Token 要花

省 Token 最怕省错地方。

有些人为了省，把背景删掉，把验收标准删掉，把例子删掉，把边界删掉，只留一句”帮我优化下”。

结果模型开始猜。猜错以后，你再解释；解释以后，它再改；改完以后，你发现约束没对齐；最后花的 Token 更多，结果也更差。

复杂任务里，有些 Token 是必要投资：

给 1-2 个示例，让模型知道你要的风格； 写清验收标准，让它知道什么叫完成； 先让它给方案，再执行，避免方向错了以后大返工； 把通用结果沉淀成 Skill，让下一次不用重新解释。

我现在判断一个 Token 值不值得花，会问三个问题：

  1. 它能不能减少后面的不确定性？
  2. 它能不能提高一次做对的概率？
  3. 它能不能沉淀成下次可复用的资产？

如果答案是肯定的，该花就花。

Token 的问题从来不是”越少越好”。更重要的是，把它花在该花的位置。

三个最常见的高耗现场

结合很多 Agent 使用场景，我觉得最典型的高耗 Token 场景有三个。

现场 1：对着设计稿反复抠像素

颜色、间距、阴影、悬浮态、适配差异，这些东西让模型来回猜，很容易进入死循环。

超过三轮还没对齐，就应该人工给明确值，或者直接把关键样式写死，再让 AI 处理剩下的结构。

AI 适合生成和改造，不一定适合无限接近视觉稿里的每一个像素。

现场 2：长会话不拆

一个窗口里塞进需求、开发、联调、改稿、复盘，后面每一句话都在为前面所有历史付费。更糟的是，模型会被旧方向干扰，出现”刚删掉的东西又回来了”。

拿到阶段答案就收口，留下交接单，再开下一段。

现场 3：接口没定就提前造假数据

这个在产品和开发协作里很常见。为了先把页面跑起来，提前造一大批 mock 数据。后面接口字段一改，假数据全失效，AI 还要再帮你拆、改、查引用、清理旧逻辑。

造一次，拆一次，双倍成本。

更稳的做法是先定字段、状态、边界和验收样例。真要提前做，也只做最小可跑样例，不要在接口未定时铺大规模假数据。

这三个场景有一个共同点：模型可能很强，但任务边界不够清楚。

边界模糊，Token 就会拿来试错。

上下文工程的四个失败模式

除了具体场景，最近社区在系统总结上下文工程的失败模式。知道这四个名字，你会开始到处看到它们：

Poisoning（污染）：一个幻觉进入上下文，会被反复重读、自我强化。DeepMind 那个 Gemini 玩 Pokémon 的案例里，模型把一个错误的游戏状态写进目标区，后面每一轮都基于这个错误目标行动，几十轮都纠不回来。

Distraction（分心）：上下文超过 100K token 后，模型开始 pattern-matching 自己的历史，而不是基于当前状态推理。表现为重复过去的动作而不是规划新的方案。

Confusion（混淆）：无关材料即使可被忽略，也会拉低输出质量。模型不是真的”忽略”噪音，它要为噪音付注意力税。这里要更新一个常见误解：新一代模型（Opus 4.6 / Sonnet 4.6 之后）对工具数量其实相当宽容，实测 80 个工具定义都不会显著降低准确率。真正会搞崩的，是系统提示词层层堆叠——persona、规则、安全、格式、知识库全往里塞，堆到 8 层时合规率会从 1.0 掉到 0.67。

Clash（冲突）：跨轮的互相矛盾会让推理脱轨。Microsoft/Salesforce 的实验里，把任务分到多轮对话中，平均性能掉 39%。他们的结论是：“LLM 一旦在对话里走错一步，就找不回来了。”

这四个失败模式的共同根源，都是上下文里塞了不该塞的东西。这就是为什么”先精简”这件事在 2026 年的模型上仍然有效——模型越强，任务越长，上下文压力越大，精简的边际收益反而越高。

一张实践清单

如果只带走一份清单，我会这样写。

降低调用次数：

  • 提问时给锚点、目标、格式
  • 背景、目标、验收一次说完整
  • 不要聊天式挤牙膏

压每轮 Token：

  • 一个会话一件事
  • 任务切换就新开
  • 长会话阶段性压缩
  • 先搜索再读取
  • 能 @ 文件和符号，就不要让 AI 盲搜

治理工具：

  • 高频能力常驻
  • 低频 Skill 按需加载
  • 能脚本处理的交给脚本
  • 工具返回只保留决策需要的信息

控制输出：

  • 明确读者、目的、长度和格式
  • 不要无意义铺垫
  • 只让模型输出下一步需要用的内容

选择模型和 effort：

  • 简单任务用便宜档或 low/medium effort
  • 常规任务用主力模型 + medium
  • 复杂决策再上旗舰模型 + xhigh
  • 同一任务中途少切模型
  • 迁移老代码先检查 budget_tokens 是否还在用

提高缓存命中：

  • 稳定系统提示词和长期规则
  • 变量字段后置
  • 不要中途频繁加新工具
  • 先精简前缀，再谈缓存
  • Claude 5min TTL 命中会刷新，持续用不会过期
  • Batch API + 缓存可叠加，最高 95% off

主动投资效果：

  • 复杂任务给示例
  • 写清验收标准
  • 先对齐方案再执行
  • 把可复用结果沉淀成模板、Skill、文档或检查清单

简单算一笔账

假设一个 Agent 每轮固定携带 2 万 Token 的系统指令和资料，连续工作 30 轮。

先不考虑缓存，也不计算逐渐变长的对话历史，仅常驻内容就会产生：

2 万 × 30 = 60 万输入 Token。

如果拆层以后，常驻核心只剩 3000 Token；某个 4000 Token 的专业 Skill 只在 5 轮相关任务中加载，那么大约是：

3000 × 30 + 4000 × 5 = 11 万输入 Token。

能力还在，重复读取量已经降到原来的五分之一以内。

这只是示意账，真实成本会受模型、平台、缓存策略和对话实现影响。但它足够说明问题：减少一次输出，只省一轮；缩小常驻上下文，每一轮都在省。

如果再叠加缓存：3000 Token 的稳定核心前缀，按 Opus 4.7 的缓存价 $0.50/M 算，30 轮只需 0.045 美元。如果不命中缓存，按 $5/M 算，要 0.45 美元。同一个核心层，缓存命中让成本降 90%。

这就是为什么”稳定前缀”是资产：一次设计，多轮受益。

别把 Token 省成返工

上下文越少，并不一定越好。

如果把关键约束、验收标准和失败记录一起删掉，AI 会因为信息不足反复猜测。省下来的输入 Token，最后可能以错误输出和多轮返工的方式加倍还回来。

所以我现在不追求”单次调用最便宜”，而是看完成一个正确结果，总共用了多少 Token。

该常驻的边界要留下，该按需加载的规则要找得到，该压缩的历史要留下结论。最该清掉的，是与当前任务无关、每轮重复出现、也不会影响判断的内容。

写在最后：省 Token 的终点，是敢让它一直跑

上个月，我用 DeepSeek V4 Flash 跑了一个月的 Hermes Agent。

微博内容流水线、每日复盘、AgentLog 收件箱、健康数据分析、每日知识推送——五类事情每天在跑，30 天累计 14.5 亿 Token，花费 79 元。

这件事实给我的反向教训是：当模型成本低到接近水电，“省 Token”的优先级会发生位移。

之前我会犹豫：这个任务真的值得调模型吗？这个 Prompt 能不能再省一点？这一轮要不要少跑几次？失败重试一次，会不会又多花一笔？

如果每次调用之前都要先算账，很多自动化念头最后根本长不出来。不是做不到，是在起步阶段就已经开始舍不得跑。

便宜的模型不是替你省钱的，是替你”敢把 AI 当基础设施”的。

这件事和前面八个动作并不矛盾。恰恰相反——只有当你把上下文拆层、把 Skill 按需加载、把输出合同写清、把缓存命中率拉高以后，你才能真的让一套系统持续跑起来。否则再便宜的模型，也扛不住一个 85 个 Skill 全部常驻、长会话不拆、输出滚雪球的 Agent。

省 Token 的终点，不是把账单压到最低，是让该跑的事能跑起来。

现在每当我准备往 Agent 的全局提示词里再加一条规则，都会先问一句：

如果不让它每次都读这段内容，大多数任务会失败吗？

如果答案是否定的，我就把它放进对应 Skill 或资料库，需要时再加载。

AI Agent 用久以后，最容易失控的是系统积累了太多”可能以后有用”的东西。

省 Token，先少让 AI 重读无关内容。

该给的上下文要给足，该拆的会话要拆开，该沉淀的经验要沉淀。

一次调用便宜，不一定真的便宜。一次做对、后面还能复用，才是真正的便宜。

参考资料

文章里 2026 年 8 月的定价、缓存机制、effort 参数、上下文工程失败模式、分词器涨幅等数据，主要来自下面这些来源。你可以按需查阅原始资料。

模型定价（2026 年 8 月）

Prompt Caching 机制

effort 参数与思考机制

上下文工程与失败模式

多 agent 与反向证据

我自己的实战数据

  • 《14.5 亿 token，79 元：我让 DeepSeek 跑了一个月 Hermes Agent》：https://image.kuangyichen.com（我自己 2026-07-31 发布的公众号文）— 文章结尾呼应的那笔 79 元账单，原始数据来自这里

一点说明

模型定价、缓存折扣、effort 等级、分词器倍率这些数据在 2026 年还在快速变化，不同来源会有几周到几个月的时间差。如果你要按本文做决策，建议以厂商官方定价页为准，第三方比价站做交叉验证。本文数据快照时间 2026 年 8 月 6 日。

易浅小站

EACHEN STUDIO / ARTICLE END

关于作者 →

相关文章

RELATED / 3

在AI时代，刻意学习不是为了更快，而是为了不被悄悄淘汰

AI从震撼到不安，我走完了一条完整的认知曲线。刻意学习不是为了更快，而是为了不被悄悄淘汰。

Agent 的技能不是越多越好，我差点被 85 个文件拖垮

从 85 个技能清理到三层能力系统：记忆、技能与管家如何协作，让 AI Agent 越用越轻，而不是越用越重。

当 AI 能直接读我的运动数据，手表里的记录终于活了

我把 COROS 官方 MCP 接进 Hermes 后，第一次把运动、睡眠、HRV 和静息心率做成了每周可追踪的健康复盘。