Cursor 官方博客给出的数字是 7%。他们没换模型，没砍功能，改的是 agent harness——模型外面那层负责拼上下文、挂工具、管历史的调度壳。用户的 token 成本降了 7%，agent 的完成质量没有掉。这个数字单看不算惊人，但放在每天跑几十万次调用的产品上，它是一笔实打实的钱；更值得关注的是它的来源：省 token 的主战场，已经从"选哪个模型"挪到了工程细节里。
7% 是怎么挤出来的
模型越便宜，账单越难看
过去两年模型单价一路向下，很多人以为成本问题自动解决了。现实正相反。agent 的上下文长度随任务步数线性上涨，一轮重发一遍系统提示、工具定义、历史消息和工具返回值，单价降一半，长度翻一倍，账单原地踏步。单价是外部变量，上下文长度是自己写的代码。前者你控制不了，后者每一行都在你手里。
质量是红线，所以只能省"废动作"
省 token 最容易走的歪路是砍能力：少给工具、少给上下文、少做反思。Cursor 明确说质量没有下降，这句话的潜台词是——他们试过，也知道哪些东西不能碰。真正被挤掉的不是推理能力，而是重复传输、过期信息、用不上的定义。判断标准很简单：这部分内容如果删掉，模型这一步的判断会不会变？不会变，那它就是可以省的。
浪费都藏在"重复"里
agent 的每一轮请求里，绝大部分内容是上一轮已经发过的。系统提示不变，工具定义不变，前面的对话不变，变的只有新加的那几行。但按当前的计费方式，不变的部分照样要付钱，除非缓存命中。所以 harness 的优化目标其实非常明确：让不变的部分尽可能被复用，让变化的部分尽可能小。
工具定义是最大的一块隐形税
用不上的工具，每轮都在收你的钱
一个稍具规模的编码 agent，挂二三十个工具很正常：读写文件、跑命令、搜代码、查网页、调子 agent。每个工具的 name、description、参数 schema 加起来几百上千 token，乘以轮数、乘以调用量，就是一笔可观的固定支出。而单次任务里真正被用到的，往往只有三五个。剩下那二十几个，从头到尾只是躺在提示词里占地方。
让工具定义跟着任务走
Cursor 的解法方向是动态工具加载：不再把所有工具一次性灌进上下文，而是根据当前任务阶段决定哪些该出现。写代码阶段不需要部署工具，读文件阶段不需要图像生成，检索阶段不需要 diff 工具。工具集从"常驻"变成"按需挂载"，省下的不只是 token，还有模型在长工具列表里挑错东西的概率。
把说明书改短，收益比想象中大
工具描述是典型的"写的时候没人心疼，跑起来天天付费"的文本。一段啰嗦的 description，模型读它和读三段话的差别不大，但每次调用都要重发。把描述压到一句话、把参数说明塞进 schema、把示例砍到只剩一个，这些改动不会改变工具能力，却能实打实降低每轮的基线长度。工程上最不性感的事，回报往往最稳。
缓存断点，位置比开关重要
不变的东西必须顶到最前面
提示词缓存按前缀匹配。前缀里只要有一个字节变了，后面全部作废。所以 harness 拼接上下文的顺序是有讲究的：稳定度最高的内容放最前——系统提示、静态工具定义、项目级规则；接着是变化稍慢的会话历史；最后才是这一轮新产生的内容。缓存断点就该打在这些稳定块与易变块的交界处，把可复用的部分圈起来。
一个时间戳就能毁掉整段缓存
最常见的翻车方式是把动态信息塞进了静态区域。系统提示里写一句"当前时间：某年某月某日某时某分"，缓存命中率当场归零。类似的还有会话 ID、随机排序的工具列表、每次重新序列化顺序都会变的 JSON。这类问题不会报错，只会让账单悄悄涨上去，所以必须靠监控发现，而不是靠代码 review。
命中率才是该盯的数字
缓存单价打折听起来很美，实际收益完全取决于命中率，而缓存写入本身有时候还更贵。衡量 harness 效率，应该看"每轮请求里有多少 token 命中了缓存"，而不是看"缓存单价打了多少折"。Cursor 抠出来的这 7%，大概率就是从这里一点点攒出来的——不是某个大招，是一串小改动叠在一起。
上下文要当预算花，不是当仓库堆
历史消息的三种处理，各有代价
会话太长的时候只有三条路：摘要、裁剪、外置。摘要把旧对话压缩成一段说明，省 token 但会丢细节；裁剪直接丢弃早期消息，便宜，但可能把关键约束一起扔掉；外置把内容写进文件或检索库，需要时再取，灵活，代价是多一次工具调用。没有普适答案，取决于任务是需要记住细节，还是只需要记住结论。
留任务状态，别留聊天流水
真正值得保留的是状态：改了哪些文件、当前在哪个子任务、已经验证过什么、还剩什么没做。不值得保留的是过程：模型说过的客套话、失败的尝试、重复的工具输出。很多 harness 直接把原始消息数组塞回去，等于把聊天记录当成了工作记忆。按状态重建上下文，往往能把长度砍掉一大截，还不影响判断质量。
工具返回结果先过一遍筛子
一次 grep 返回两千行，一次构建输出八百行日志，这些内容原封不动进上下文，token 就白烧了。常见的做法是截断、加摘要、只保留匹配附近的若干行，或者把完整结果写进临时文件、只把路径和摘录交给模型，需要细节时再让它自己读。核心原则只有一条：进上下文的东西必须对下一步决策有用，否则它就是在占位置。
这套打法能不能照搬
先量，再改
harness 优化最容易犯的错是凭感觉改。哪些内容占了最多 token、缓存命中率是多少、工具定义加起来多大、哪类任务的成本最高——这些数据不测出来，改动就是碰运气。花一天把每轮请求按块拆开统计，往往比直接上"优化方案"更有效，因为你会发现真正的开销和直觉对不上。
有些场景，不值得省
token 效率不是唯一目标。需要长时间推理的复杂任务、必须保留完整历史的事故排查、对可复现性要求极高的场景，硬省上下文会直接伤到结果，省下的钱不够赔一次错误决策。7% 这个数字之所以可信，恰恰是因为它建立在"质量不降"的前提上。离开这个前提，任何成本优化都只是把账单挪了个地方。
