Cursor 提升 agent 长时运行 token 效率，用户成本降低 7%

随着智能体逐渐成熟并学会处理更具挑战性的任务，token 开销的分布也发生了变化。如今智能体运行时间更长，并在每一步之间携带更多上下文，这使得我们组装和管理这些上下文的方式变得愈发重要。

智能体推理开销的去向

生产流量 · 宽度 = 占总开销的比例 · 深浅 = 计费类型

输出

未缓存输入

缓存输入

智能体推理开销的去向

生产流量 · 宽度 = 占总开销的比例 · 深浅 = 计费类型

输出

未缓存输入

缓存输入

说明：系统与工具定义包含压缩摘要。用户文本包含手动附加的技能。技能与插件包含技能描述、MCP 工具描述，以及放入静态上下文的规则。

过去几个月里，我们通过提升 Cursor 智能体框架的效率来应对这一变化。该框架让我们能够直接控制每个请求如何组装、上下文如何复用，以及工作何时在多个智能体之间分配。这些层面的改动将用户的 token 成本降低了 7%，同时没有降低智能体的质量。

精简系统提示词

智能体的每一轮交互都会包含 Cursor 在模型开始工作之前提供的上下文。这包括系统提示词以及智能体可使用的工具定义。由于这些上下文会贯穿整个对话，它已成为我们完全可以控制的最大开销来源之一。

当模型能力较弱时，我们不得不详细写明工具使用、任务管理和代码变更工作流的指令。我们还必须防范一些奇怪的行为，比如极长的哈希转储、二进制输出和 emoji。

随着模型不断改进，其中大部分指导都变得不再必要。我们不再需要罗列一长串“不要这样做”“你必须”“重要”之类的指令，只需定义工具的行为方式，模型通常就会遵从。这一点在各个模型系列中都成立，使我们得以将系统提示词削减约 66%。

随着时间推移，我们会持续增删指令，因为新模型需要新的指导，而这些指导又会流入未来模型的训练之中。利用大规模用户群进行 A/B 测试，对于针对真实流量有效优化 harness 至关重要。虽然评测可以作为一种快速且有用的替代指标，但它们往往代表的是“困难”问题，并不能准确反映用户请求的真实分布。

仅在需要时加载工具

系统提示词只是 Cursor 在每一轮对话中提供的上下文的一部分。另一部分是工具定义，随着我们为 Cursor 智能体添加更多强大的能力——包括后台 shell 监控、云端子智能体，以及更可靠的网页内容访问——这些定义在过去一年中急剧膨胀。这些工具大多很重要，但每一个都只在不到 20% 的对话中会被用到。

这就创造了一个提升效率的机会：让工具保持可用，但不必在每次请求中都包含它们的完整定义。今年早些时候，我们在将 MCP 工具迁移到动态上下文时解决过类似的问题——仅在需要时才加载它们。这使得调用 MCP 工具的会话中总 token 数减少了 46.9%。

现在，我们将同样的技术应用到了我们自己的内置工具上。

为了决定哪些工具保留在静态上下文中，我们基于每个工具的使用频率以及模型是否需要从一开始就看到它，对多种配置进行了 A/B 测试。我们追踪了 token 用量、成本、延迟、工具调用错误以及智能体的整体使用情况，以确保节省不会导致质量下降。

最常调用的工具

至少调用一次各工具的智能体会话占比

最常调用的工具

至少调用一次各工具的智能体会话占比

最终，我们将读取、搜索、编辑以及在静态上下文中使用 shell 的高频工具保留了下来。我们还保留了 ask_question，因为一些模型往往会幻觉出对它的调用，以及对于特定产品流程至关重要的工具，例如 Plan Mode 中的 create_plan。其余工具现在会在智能体需要时再加载。

卸载内置工具使静态上下文描述 token 减少了 60%

保留在静态上下文中

卸载到动态上下文

卸载内置工具使静态上下文描述 token 减少了 60%

保留在静态上下文中

卸载到动态上下文

提升缓存复用

在减少每次请求中的静态上下文数量后，我们提升了重复上下文在多个轮次之间被缓存的有效性。

智能体的每一轮都会重新发送一个长请求，其中包含工具、系统指令、设置以及到目前为止的对话。开头的大部分内容在相邻轮次之间保持不变，而末尾的对话则持续增长。

提示词缓存让模型提供商能够复用那段未更改的前缀。不过，缓存的可配置性因提供商而异。在 GPT-5.6 之前，缓存边界是根据最新请求自动确定的。尽管工具和系统指令很少变化，但它们本身并未被清晰地标记为可复用。

自 GPT-5.6 起，OpenAI API 允许客户端在其默认的隐式缓存之外，显式标记缓存断点。我们现在将断点放在请求的稳定层之后、不断增长的对话之前，让后续轮次能够复用更多未更改的前缀。

断点只有在缀本身保持稳定时才有用，因此我们还收紧了每个请求最前面的内容。为此，我们将工具和系统指令保留给很少变化的内容，并把更多易变的设置移过缓存边界，放入我们的“幻影用户消息”中。这里存放用户和请求特定的上下文，例如技能、子智能体和环境信息。

这些改动将冷缓存未命中率降低了 20%。

压缩文件读取

token 消耗的另一大来源是智能体在工作过程中添加的上下文，其中很大一部分来自读取文件。

Cursor 的智能体通过 Read 工具读取文件，该工具传统上会为每一行编号，因为模型本身不擅长数行，并且需要为用户引用特定片段。

单个行号只占用大约三到五个 token，但当智能体在一次会话中读取数万行代码时，为每一行都编号会额外增加相当可观的上下文量。

我们通过仅每隔十行标注行号来降低这一开销。这样的频率仍然足以让模型正确引用代码，而且这一改动将缓存读取 token 减少了 1.6%，质量没有任何下降。

策略性地使用子智能体

更长的智能体运行会创造更多将工作委派给子智能体的机会。这可以减少 token 消耗，因为每个子智能体通常从全新的上下文窗口开始，而不必携带父智能体的完整对话。一旦子智能体报告了结果，父智能体就可以继续运行，而无需携带子智能体的完整工作上下文。

不过，智能体与子智能体之间的这种上下文隔离确实会带来协调成本，因为不共享上下文的智能体可能会重复工作，或去执行已不再必要的任务。

我们做了两处改动，以在不增加不必要协调的前提下获得效率收益。首先，我们移除了强烈鼓励智能体使用子智能体进行代码库探索的指令。随着子智能体在训练数据中越来越普遍，研究人员也将其纳入后训练，模型已经原生学会了这一模式。移除额外的提示后，子智能体的使用变得更加均衡。

我们还收紧了子智能体选择模型的方式。Cursor 可以使用我们提供的任意模型来派生子智能体，从而能够弥补不同模型之间的盲点，或者将一个昂贵的规划模型与一个更便宜的模型配对用于实现。我们更新了工具参数，使智能体仅在用户或 harness 指示时才选择不同的模型。

持续提升 harness 效率

我们将继续测量上下文在更长运行中如何累积，并测试 harness 在哪些环节可以减少重复处理而不影响智能体质量。随着时间推移，我们预计这将使 token 用量的增长速度远低于智能体所能完成的工作量的增长速度。我们也将这些经验带到了 Grok Bot，正在努力优化其独特的 harness，以便用户能以最低成本完成最多的工作。