VS Code × OpenAI：两周内优化系统prompt减少token消耗

2026 年 7 月 6 日，VS Code 团队，@code

在上一篇文章中，我们介绍了 VS Code coding harness：它是连接模型与工具、上下文、指令及 Agent 循环的一层，让模型具备执行编程任务的能力。

不同模型响应工具调用和指令的方式各不相同，而 harness 可以针对这些差异进行调整，从而改善结果。本文将介绍我们与 OpenAI 合作开展的一项为期两周的实验，目标是调优 VS Code 中 GPT-5.5 的 system prompt。我们要回答的问题很简单：如果引导 Agent 减少探索、更早验证，能否在不降低质量的前提下，让它运行得更快、成本更低？结合 OpenAI 在模型方面的专业能力与我们从 harness 获得的数据，我们测试了两项细微的 prompt 改动，在真实流量中将它们与对照组进行比较，并最终上线表现更好的方案。

随着按用量计费机制落地，这件事变得更加重要。Token 效率不只是基础设施指标：Agent 每多花一个 token 漫无目的地探索，你就要为这个 token 付费，也要等待它处理。一个能更早做出有依据修改的 Agent，不仅体验更好，账单也更低。

假设：减少探索，更早验证

GPT-5.5 发布后，作为《提升 GitHub Copilot 的 token 效率》一文所述工作的一部分，我们研究了模型在 VS Code Agent harness 中如何消耗 token。两个模式格外突出：模型把 token 花在了哪里，以及它在采取行动前进行了哪些过度探索。Agent 可能会在真正做出有用修改之前，耗费大量精力进行搜索、反复读取，以及比较相近的代码路径。

这指向了一个单一且可验证的想法：Agent 应该少花精力四处游走，多花精力沿着一条经过审慎设计的“证据、行动、验证”循环推进。

在测试不同假设并运行离线评估后，我们把这个想法转化成 GPT-5.5 system prompt 的两个变体。它们在离线评估中都展现出了潜力，因此我们在真实流量中将它们与当前默认方案进行了比较。

实验设计

我们在 VS Code 中开展了为期两周的实验，将 GPT-5.5 Agent 流量分配给两个实验组和一个对照组，比例为 25/25/25。两个实验组验证的是同一个假设，区别在于它们为 prompt 增加的结构化程度不同。

注意：各组分配比例之和为 75%，这是因为实验记分卡比较的是规模相同的组。剩余的 GPT-5.5 流量继续使用记分卡统计范围之外的默认 prompt，这样我们就能在相同类型的用户流量中比较两个实验组与对照组。

实验方案 A：经济高效地搜索与编辑

实验方案 A 是一项小而聚焦的改动：添加一条简短、紧凑的提醒，引导模型减少不必要的探索。

prompt 中的 <economical_search_and_edit> 部分要求 Agent 从具体的锚点开始，只收集足够的局部上下文，避免大范围探索；一旦找到成本较低且具有区分力的检查方法，就立即采取行动；同时避免重复读取未发生变化的上下文。

你可以在 gpt55BasePrompt.tsx 中查看完整实现细节：

{economicalSearchAndEditEnabled && <Tag name='economical_search_and_edit'>
    - Start from the most concrete available anchor: a file, symbol, failing behavior, failing command, or nearby implementation surface.<br />
    - Gather only enough nearby context to choose one plausible local hypothesis and one cheap check that could disconfirm it.<br />
    - Prefer one targeted search or nearby read over broad repo exploration.<br />
    - Once the cheapest discriminating check is known, act.<br />
    - Do not re-read unchanged context unless a new result makes it relevant.<br />
</Tag>}

实验方案 B：大型 prompt 区块

实验方案 B 测试了同一思路的更广泛版本，同样旨在限制探索。它没有只添加一条有关经济高效搜索的简短提醒，而是将 Agent 工作流重新组织成明确的 <Before_the_first_edit> 和 <After_the_first_edit> 两个部分。与实验方案 A 不同，这些新增内容会让 system prompt 本身变得更长。因此，一个关键问题在于：额外增加的结构能否真正提高效率，而不只是改变 Agent 的行为。

其目标是解决完整的循环，而不仅仅是搜索环节：在编辑前形成局部假设，避免大范围探索，做出有依据的第一次修改，并在第一次实质性修改后立即进行验证。

你可以在 gpt55BasePrompt.tsx 中查看完整实现细节：

{largePromptSectionsEnabled && <>
    <Tag name='Before_the_first_edit'>
        - Start from the most concrete anchor available: a file, symbol, failing behavior, failing command, test, or nearby implementation surface. If the request does not name one explicitly, use the first targeted search or nearby read to identify that anchor, then continue locally from there.<br />
        - Before the first edit, gather only enough nearby evidence to state one falsifiable local hypothesis about how the requested behavior should work or why it is failing, and one cheap check that could disconfirm it.<br />
        [...]
        - Once you can state one falsifiable local hypothesis, the nearby code path it depends on, one cheap check that could disconfirm it, and one small edit that would test it, the next action must be a grounded edit.<br />
        - If confidence is incomplete, the first edit may be a small reversible probe that exposes missing types, behavior mismatches, control-flow gaps, or validation failures.<br />
        - If you find yourself still searching after that local-routing budget, treat that as drift. Recover by choosing the best current hypothesis and the best available nearby check, then make the smallest plausible edit that will let that check discriminate.<br />
    </Tag>
    <Tag name='After_the_first_edit'>
        - Prefer this order for that first validation action:<br />
        - the cheapest behavior-scoped or failing check that can falsify the current hypothesis<br />
        - a narrow test for the touched slice<br />
        - a narrow compile, lint, or typecheck command for the touched slice<br />
        [...]
        - Finish with at least one post-edit executable validation step whenever the environment provides one. Only fall back to diff-only validation when no focused command exists or commands are unavailable.<br />
    </Tag>
</>}

两周实验记分卡揭示了什么

我们从三个维度跟踪实验方案的表现：质量（代码是否被保留下来）、延迟（第一次修改落地的速度），以及效率（token 和工具调用）。下表将每种实验方案与对照组进行了比较。

10 分钟留存率（按用户统计）： 模型编写的代码中，有多少在 10 分钟后仍然留在文件里，没有被删除或重写。这是我们用来衡量“AI 编写的代码是否真正被保留下来”的替代指标。计算方式为“留存字符数 ÷ 写入的总字符数”，以百分比表示。例如约 90%，意味着模型每添加 10 个字符，大约有 9 个会被保留。

Commit 留存率（按用户统计）： 这是一个范围更窄、要求更严格的指标：AI 编写的代码中，有多少最终一直保留到 git commit。它衡量的是“这些代码是否进入了真实、已保存的工作成果”。计算方式同样是字符比例，但只统计 commit 时仍然存在的代码。例如约 87%。

p50 首次编辑耗时（按轮次统计）： 对于一次典型请求，从按下回车到第一处实际修改落入代码，需要多长时间。这里统计的不是模型开始输出文字，而是真正的工作成果出现在代码中。单位为秒。例如，中位数轮次约为 74 秒。

p95 首次编辑耗时（按轮次统计）： 计时方式相同，但关注最慢的 5% 请求，也就是那些让人产生“为什么这么久还没动静？”的情况。这是一项关键的尾部延迟护栏指标。例如约 6.4 分钟（383K ms），在困难任务或大量探索中，第一次编辑会被推迟。

p50 token 总量（按用户统计）： 一名典型用户一天内，模型读取与写入的 token 总量，可用来衡量每位用户的成本和上下文负载。计算方式是先汇总每位用户的 token，再取所有用户的中位数。例如约 12.9M tokens/user/day。

p95 token 总量（按轮次统计）： 最重的 5% 单次交互所消耗的 token，用来衡量那些规模庞大、不断扩展，会推高成本峰值并触及上下文限制的请求。例如，单次交互可能消耗数百万 token，而中位数约为 500K–900K。

平均工具调用次数（按轮次统计）： Agent 为完成一次请求执行了多少次操作，例如读取文件、搜索、运行终端和编辑等。数值较低可能意味着效率更高，但过低也可能意味着不够彻底。该指标是每轮工具调用次数的平均值。例如每轮约 24 次。

信号图例： ● 有利且高度显著（p < 0.001），○ 有利且具有统计显著性（p < 0.05），● 不利且高度显著，○ 不利且具有统计显著性，- 不具有统计显著性。

质量： 护栏指标整体保持健康。实验方案 B 的 Commit 留存率小幅上升（+0.68%），实验方案 A 则小幅下降（-0.48%），两者都不具有统计显著性。两种实验方案的 10 分钟留存率均略有下降：实验方案 B 下降 0.44%，实验方案 A 下降 0.40%。只有实验方案 B 的变化刚刚越过统计显著性门槛（p=0.0493），这与高度显著的效率提升不同。我们将其视为需要权衡的真实代价，但变化幅度很小，另一项质量护栏指标也没有出现退化。

质量： 护栏指标整体保持健康。实验方案 B 的 Commit 留存率小幅上升（+0.68%），实验方案 A 则小幅下降（-0.48%），两者都不具有统计显著性。两种实验方案的 10 分钟留存率均略有下降：实验方案 B 下降 0.44%，实验方案 A 下降 0.40%。只有实验方案 B 的变化刚刚越过统计显著性门槛（p=0.0493），这与高度显著的效率提升不同。我们将其视为需要权衡的真实代价，但变化幅度很小，另一项质量护栏指标也没有出现退化。

延迟： 实验方案 B 在编辑延迟方面取得了最明显的改善，而且两项结果都具有高度统计显著性：p50 首次编辑耗时改善了 5.68%（快 3.9 秒，p=2e-5），p95 首次编辑耗时改善了 9.30%（快 38.8 秒，p=1e-10）。实验方案 A 的变化方向同样正确，但对编辑延迟的影响较弱：p50 首次编辑耗时改善 2.88%（快 2.0 秒，p=0.0271），p95 首次编辑耗时改善 1.93%（不显著）。

延迟： 实验方案 B 在编辑延迟方面取得了最明显的改善，而且两项结果都具有高度统计显著性：p50 首次编辑耗时改善了 5.68%（快 3.9 秒，p=2e-5），p95 首次编辑耗时改善了 9.30%（快 38.8 秒，p=1e-10）。实验方案 A 的变化方向同样正确，但对编辑延迟的影响较弱：p50 首次编辑耗时改善 2.88%（快 2.0 秒，p=0.0271），p95 首次编辑耗时改善 1.93%（不显著）。

Token 效率： 两种实验方案都降低了每位用户的 token 总量中位数，但这些 p50 变化不具有统计显著性：实验方案 B 降低 3.25%，实验方案 A 降低 2.54%。在分布上尾，实验方案 B 将 p95 token 总量降低了 7.64%，具有高度统计显著性（p=0.0003）。实验方案 A 也将 p95 token 总量降低了 5.19%，具有统计显著性（p=0.0157）。两个变体都减少了每轮的平均工具调用次数：实验方案 B 降低 8.54%（少 2.04 次工具调用），具有高度统计显著性（p=1e-12）；实验方案 A 降低 3.19%（少 0.77 次工具调用），具有统计显著性（p=0.0091）。

Token 效率： 两种实验方案都降低了每位用户的 token 总量中位数，但这些 p50 变化不具有统计显著性：实验方案 B 降低 3.25%，实验方案 A 降低 2.54%。在分布上尾，实验方案 B 将 p95 token 总量降低了 7.64%，具有高度统计显著性（p=0.0003）。实验方案 A 也将 p95 token 总量降低了 5.19%，具有统计显著性（p=0.0157）。两个变体都减少了每轮的平均工具调用次数：实验方案 B 降低 8.54%（少 2.04 次工具调用），具有高度统计显著性（p=1e-12）；实验方案 A 降低 3.19%（少 0.77 次工具调用），具有统计显著性（p=0.0091）。

实验方案 B 的整体表现最强：它显著改善了延迟，大幅减少了上尾 token 消耗，降低了工具调用次数，同时让质量护栏指标基本保持稳定。唯一值得持续关注的变化，是 10 分钟留存率的小幅下降，但它的显著性较弱（p=0.0493）；相比之下，延迟、token 和工具调用方面的提升幅度更大，也稳健得多。实验方案 A 也让多项指标朝正确方向变化，但对于 VS Code 最重要的指标而言，实验方案 B 的表现更加一致。

因此，我们正式上线了实验方案 B：LargePromptSections 现已成为 GPT-5.5 的默认 system prompt。

真正值得关注的，并不只是这些数字发生了变化。这些变化源自一个根据模型提供方反馈提出、具体且可验证的 harness 假设：先通过离线评估验证，再在为期两周的线上生产环境中确认。我们希望持续运行的，正是这样的循环。

持续优化

这次实验只是一个例子，展示了模型发布之后，我们如何继续与模型提供方合作。模型发布并不意味着调优循环结束。它提供了又一次机会，让我们观察 VS Code 中的真实行为，测试聚焦的改进方案，并找到新的方法，让使用体验变得更快、更可靠、更高效。

我们会继续从模型、prompt、工具和 VS Code coding harness 等方面寻找改进机会，让每个 Agent 的预算更多地用于真正重要的工作，而不是不必要的探索。

欢迎在 VS Code 中尝试 Agent，切换不同模型，并比较各个模型处理同一任务时采用的不同方式。也欢迎在我们的 GitHub repo 中分享反馈。这些反馈能帮助我们持续改善使用体验。