AREX Feed Article
Cursor 宣布 agent token 成本降低 7%、质量未降：官方详解四项节省来源
北京时间 9 月 23 日 23 时 46 分，AI 编程工具 Cursor 的官方 X 账号 发帖宣布，已将 Cursor 中的 token（模型处理与计费所用的文本单位）成本降低 7%，agent 质量没有下降。帖文将节省归因于四项改动：更紧凑的提示词（tighter prompts）、选择性工具加载（selective tool loading）、更好的缓存（better caching）和压缩文件读取（compressed file reads），并在同分钟发出的跟帖里附上博客《Improved token efficiency for longer agent runs》的链接。截至北京时间 9 月 24 日 20 时许，这条主贴获得约 24.6 万次浏览、4,200 多个点赞和 208 条回复。
这些数字目前只有 Cursor 的单方测算。随帖发布的同样发布于 9 月 23 日，逐项给出了改动的百分比，并称结论建立在对大规模真实用户流量的 A/B 测试之上；博客没有按模型划分的明细数据，也没有引入第三方复核。
节省来自哪一层：模型开工前的静态上下文
博客把这项工作归入 agent harness（agent 运行框架）——Cursor 在模型开始工作前组装每次请求的那一层。按博客的说法，harness 让团队直接控制三件事：请求如何组装、上下文如何复用、工作何时在多个 agent 之间分工；过去几个月里跨这些层面的改动，合计得出了帖文宣布的那笔节省。
静态内容是其中可以完全控制的一块。每一轮 agent 交互，Cursor 都会在模型开工前注入系统提示词和可用工具的定义；由于这些内容贯穿整场对话，博客称它已经成为「我们完全可控的支出里最大的来源之一」。
系统提示词砍掉约 66%：模型变强，「禁止清单」成了冗余
在模型能力还有限的时期，Cursor 需要在提示词里写明工具用法、任务管理和代码修改流程，还要防范超长 hash 倾倒、二进制输出、表情符号这类古怪行为。博客称，随着模型进步，这些指令大部分不再必要：与其罗列「DO NOT do this」「You must」「Important」式的长清单，不如只定义工具的行为，模型大体就会遵守，且这一点在各模型家族上都成立。结果是系统提示词缩减了约 66%。
提示词的增删没有终点。博客称团队会随新模型的需求继续调整指令，这些调整随后会进入未来模型的训练。判断改动是否有效，靠的是在大用户基数上做 A/B 测试——博客认为 evals（自动化评测）虽然快，但往往代表「难」问题，无法反映真实用户请求的分布。
每个内置工具都只在不到 20% 的对话里被用到：转为按需加载
工具定义是另一项大头。过去一年，Cursor agent 的能力清单不断变长——后台 shell 监控、云端子代理（subagent）、更可靠的网页内容访问——每一项都以工具定义的形式占着上下文。博客称，这些工具多数重要，但每个工具在不到 20% 的对话里才会被用到。
今年早些时候，Cursor 已把 MCP（Model Context Protocol，模型上下文协议）工具挪进动态上下文、需要时才加载，使调用过 MCP 工具的会话总 token 量下降 46.9%。现在同样的做法扩展到内置工具：团队按使用频率和「模型是否需要一开始就看到某个工具」做了多组 A/B 测试，期间追踪 token 用量、成本、延迟、工具调用错误率和整体 agent 使用情况。最终留在静态上下文里的是读取、搜索、编辑和 shell 四类高频工具，以及 ask_question（部分模型容易幻觉式调用它）和 Plan Mode 必需的 create_plan；其余工具改为 agent 需要时再加载。博客称，此举把静态上下文中的工具描述 token 减少了 60%。
借 GPT-5.6 的显式缓存断点，冷缓存未命中减少 20%
缓存改动解决的是重复发送的问题。每一轮交互都会把工具、系统指令、环境设置和此前的整段对话重新发一遍，请求开头基本不变，末尾的对话持续增长，提示词缓存（prompt caching）本可让模型服务商复用不变的前缀。但博客指出，缓存的可配置程度因服务商而异：在 GPT-5.6 之前，缓存边界由系统按最近一次请求自动确定，很少变化的工具和系统指令并没有被干净地标成可复用段。
GPT-5.6 起，OpenAI API 允许客户端在默认隐式缓存之外标注显式缓存断点（cache breakpoints）。Cursor 把断点放在请求稳定层之后、持续增长的对话之前，让后续轮次复用更多前缀。断点要奏效，前缀本身还得稳得住：团队把极少变化的内容留在请求开头，把更多随请求变化的设置挪到缓存边界之后的「phantom user message」里，其中装有技能、子代理和环境信息。博客称，这些改动把冷缓存未命中率降低了 20%。
行号每十行标一次：读文件与子代理的细账
第四项来源藏在 agent 的工作过程里。Cursor 的 agent 用 Read 工具读文件，传统上每一行都带行号——模型自己数不准行数，向用户引用代码段时又离不开行号。单个行号只占约 3～5 个 token，但一场会话读下数万行代码，逐行标注累积成一笔可观的上下文。现在行号只标注在每第十行。博客称这仍足以让模型准确引用代码，此项改动使缓存读取 token 减少 1.6%，质量没有下降。
同一层还有两笔子代理的细账。子代理通常从全新的上下文窗口起步，不必背着父对话的全部历史，省 token，但代价是协调税：不共享上下文的 agent 可能重复劳动，或去追已经不需要的任务。博客称，团队先删掉了强推「用子代理探索代码库」的指令——子代理已大量进入训练数据和后训练，模型原生掌握这个模式，去掉多余提示反而让子代理使用更均衡；又收紧了子代理的选模型逻辑，agent 只在用户或 harness 指定时才切换模型。
回复区在催的：Composer 3、按模型的明细，和一次能自测的重置
主贴下的回复里，催更和技术讨论混在一起。不少人直接问 Composer 3 什么时候发布，；用户 称成果「很难得」，但建议按主要模型分别公布数字，因为「每个模型的怪癖差别很大，一套 harness 并不适合所有模型」；自称工程经理的用户 提醒，harness 只是杠杆之一，把整个仓库一股脑塞给 agent、指望它自己弄明白任务，才是大部分成本所在。也有用户报告了相反的体感： 称最近两周 agent 越来越不聪明，任务执行混乱、浪费 token。
博客结尾给出的方向是：继续测量长任务中上下文的累积方式，测试 harness 还能在哪里减少重复处理而不影响质量；博客预期 token 用量的增速会远低于 agent 完成工作量的增速，并称这些经验已带往 Grok Bot，团队正在优化它那套独特的 harness。
至于这 7% 能不能在普通用户自己的用量里得到印证，回复区里出现了直接的请求： 问：「能不能给我们一次重置，好验证一下这个说法？」