5行代码评测跑了5万次，我们学到了什么

2026年6月19日 由 VS Code 评测团队发布，@code

在过去的六个月里，我们将同一个微型评测运行了 50,000 多次。它给 VS Code 智能体（agent）下达了一条指令：将一个字符串写入文件。这里没有需要理解的大型代码库，没有需要调试的测试套件，也没有需要做出的架构决策。这是我们的冒烟测试，是一种快速确认端到端模型交互是否仍然正常的有效方法。

如此简单的任务让我们能够立即了解系统的健康状况：智能体完成工作的可靠性如何，以及在实践中会出现哪些类型的故障。我们最初并没有打算让它承载更多功能。但在这种规模下，它出人意料地成为了一个丰富的信息源，让我们得以洞察模型如何处理哪怕是最简单的请求。

在我们的上一篇文章中，我们介绍了 VSC-Bench，这是我们用于衡量 VS Code 中智能体行为的离线评测套件。在这篇博客文章中，我们将探讨模型如何解决一个简单的任务，以及它对效率、模型选择以及小型、稳定评测价值的启示。

五行代码评测

一个简单的任务之所以有价值，恰恰是因为它消除了变量。当工作明确且正确答案固定时，两次运行之间发生变化的任何内容都来自于模型或其周围的系统，而不是任务本身。这使得小型评测成为一个敏感的仪器：它对测试框架回归、基础设施故障以及模型行为差异做出反应，而没有复杂问题所带来的干扰噪音。

我们为此使用的 say_hello 任务就是围绕这一理念构建的。每次运行都从相同的空工作区开始，使用相同的工具和相同的固定提示词，并采用我们的 VS Code 智能体测试框架。该任务要求智能体“将 HELLO 添加到 HELLO.txt 中”，并检查两个断言：文件是否存在以及它是否包含预期的内容。

promptSteps:
  - text: Add HELLO to HELLO.txt.
    assertions:
        - check: file_exists("HELLO.txt")
        - check: file_contains("HELLO.txt", "HELLO")

由于 say_hello 在每个基准测试套件运行前都作为冒烟测试执行，它在六个月内静静地在 30 个模型中积累了 50,974 次运行。这个数据量将一个基本的健全性检查变成了一个有用的数据集，展示了不同模型处理最简单工作时的巨大差异。

执行此任务的开发人员会认识到工作区是空的，创建 HELLO.txt，并添加所请求的内容。在最直接的 VS Code 智能体路径中，这转化为一个包含 HELLO 作为文件内容的单次 create_file 工具调用。

tool : create_file
args : {
  "filePath": "/path/to/workspace/HELLO.txt",
  "content": "HELLO"
}

模型如何解决 say_hello

正如预期的那样，say_hello 任务非常简单，以至于所有模型在大部分时间都能通过。有趣的部分不在于它们能否完成工作，而在于它们是如何完成的。模型能否识别出这是一个只需简单方案的基本请求？还是依然把它当作需要规划、探索和搜索的复杂问题来对待？

为了建立基线，我们筛选了使用这种单工具调用路径的通过运行，并查看了该组中最低的输出 Token 数量。这些运行平均产生大约 50 个输出 Token（包括工具调用结构）。然后，我们测量了每个模型走这条路径的频率。

有一个模型每次都走直接路径。更广泛的趋势引人注目：少数模型经常走直接路径，大多数模型偶尔为之，而有五个模型从不走直接路径。

在顶端，Model-A 独占鳌头。在 100% 的通过运行中，它都直接进行文件创建，每次都只使用一个工具调用。对于这个简单的请求，Model-A 总是直接创建文件，而不事先进行规划或探索。Model-B 和 Model-C 分别以 73% 和 71% 的比例紧随其后。

庞大的中间集群（Model-D 到 Model-P）在 19% 到 52% 的时间内走直接路径。这些模型能够识别出简单的任务，但不够稳定。通常情况下，它们在创建文件之前会先增加一个小步骤，例如读取内部状态或进行轻量的工作区探索。

在它们之下，Model-Q 到 Model-X 很少走直接路径，在通过的运行中占比仅为 0.2% 到 6%，其中有五个模型低于 1%。对这些模型来说，额外的工作是默认行为。在生成同样五个字符的文件之前，它们几乎总是先进行规划、探索或搜索。

在最底层，Model-Y 到 Model-AC 这五个模型在数千次通过的运行中从未走过直接路径。它们总是先做别的事情：规划、使用补丁工具而不是简单的文件创建、搜索并规划，或者在创建文件前冗长地叙述一番。对它们而言，即使是最简单的请求也会触发复杂任务的全套运转机制。

所有模型都创建了包含正确内容的文件，但它们以截然不同的工作量达到了相同的结果。即使在几乎没有歧义的任务上，某些模型仍然会进行规划、搜索或选择更复杂的编辑工具。它们都通过了评测，但它们付出的努力并不相同。

模型是如何消耗额外开销的

由于我们的离线评测框架捕获了完整的工具调用序列，我们可以将这些轨迹转化为模型行为模式。在多次运行中，模型往往会通过几种常见的方式来消耗其额外的精力

这些并不是正确性故障。它们表明模型并不总是能识别出何时“最短路径”就已经足够了。在较长的任务中，规划和探索非常有价值。但在单步骤任务中，它们只会增加延迟和成本，而不会改善结果。

过度思考的代价

为什么你需要关心模型编写一个五字符文件需要花费多少额外步骤？因为这些额外的步骤并非免费，它们会直接转化为输出 Token 的使用量，从而产生切切实实的成本。

对于这个简单的任务，大约 50 个输出 Token 是实际的最小值。下表显示了不同模型使用的输出 Token 范围。对于相同的五个字符的结果，所选模型的 Token 消耗量从该最小值一直跨越到数千个 Token！

图表明显分为四个梯队。极端组包括 Model-AB、Model-M 和 Model-U，其平均输出 Token 分别为 3,676、2,120 和 1,441 个。这比产出同样五个字符结果的实际最小值高出 29 到 74 倍。高开销组（400 到 1,000 个 Token）包括 Model-AA、Model-B、Model-N、Model-H、Model-V、Model-E、Model-S 和 Model-K。这些模型的 Token 量虽然没达到数千级别，但依然消耗了约 8x 到 12x 的实际最小值。

中等开销组（150 到 400 个 Token）包括 Model-P、Model-D、Model-X、Model-T、Model-G、Model-Z、Model-I、Model-AC、Model-F、Model-J 和 Model-Q。它们虽然增加了开销，但更接近任务本身的自然规模。高效组低于 150 个 Token：包括 Model-R、Model-A、Model-Y、Model-W、Model-O、Model-C 和 Model-L。Model-L 以 55 个 Token 最接近我们的实际最小值，这表明即使模型不总是走直接工具路径，它也可以在极少额外叙述的情况下完成任务。

选择一个较少“过度思考”的模型既能省时又能省钱，但要了解哪种模型对特定任务最高效，通常意味着你需要运行自己的基准测试。为了替你减轻这种负担，VS Code 和 GitHub Copilot 团队一直在持续投入优化和模型路由。例如，自动模型选择功能可以让 VS Code 为你的任务挑选最佳模型。

模型大小并不能预测开销

我们最初的假设是越大的模型过度思考得越多，但我们的数据与此相反

• Model-F（一个较大的模型）平均使用 160 个输出 Token 和 2.1 次工具调用。它是其模型家族中最克制的模型。

• Model-H（来自同一家族的较小模型）平均使用 485 个输出 Token 和 3.7 次工具调用。它的开销比其体型更大的同门兄弟还要大。

• Model-AB（一个“mini”模型）是开销最高的单一模型，平均输出 Token 高达 3,676 个。此样本中体积最小的模型却干了最多的活。

我们的解读是，无论参数量如何，每个模型家族中的更新代际都趋向于更加克制。这指向了训练成熟度：模型如何根据眼前的任务按比例调整其精力。这种校准并非学术上的好奇心，它会直接体现在账单上。

接下来我们将走向何方？

我们希望分享团队从这些运行中获得的一些关键见解，以及你可能可以应用到日常工作流中的一些经验。

为任务匹配合适的模型

随着采用基于使用量的计费方式，输出 Token 既代表金钱又代表时间。对于相同的输出，此任务中精简模型与沉重模型之间的差异大约为 70 倍。显而易见的教训似乎是“不要为了写 HELLO 去搬出最大的模型”。但这个教训过于肤浅，而弄清楚原因才是 say_hello 教给我们的最有用的东西。

这些结果有一个重要的前提需要注意。say_hello 是一个短期任务，只有一个步骤和一个正确答案。对于长期任务，规划、探索和推理可以防止付出高昂代价的错误并提高完成的几率。我们的目标不是消除规划，而是了解模型是否能区分单步骤任务和 30 步骤任务。

这就是为什么我们认为模型选择不应该成为开发人员负担的原因之一。诸如精力校准、Token 效率和工具克制等信号可以帮助自动模型路由为手头的任务挑选合适的模型，而无需开发者去权衡每一个取舍。我们一直在持续投入并研究 VS Code 中的自动模型选择，以便随着时间的推移，产品可以为你做出更多此类选择。

从小处着手，充分衡量

大多数团队在起步时并没有每天都可以运行的私有离线基准测试套件。即便是一个简单的任务，只要持续运行并做好日志记录，也能揭示模型或系统行为中有用的变化。

从具有明确正确答案的最小任务开始。然后不断运行它：将其用作夜间评测、模型接入以及基础设施变更之前的飞行前检查。该任务不需要多么巧妙，它只需要足够稳定，以至于通过率、延迟、工具使用或故障模式的变化具有实际意义。

重要的一点是捕获足够的结构来解释发生了什么变化。记录工具调用序列，而不仅仅是调用次数。知道有 4 次工具调用很有用，但并不完整。知道模型先进行了规划、探索、搜索，然后才创建文件，这能告诉你开销从何而来，以及为什么这次运行成本更高。

// What most harnesses log:
{ "tool_calls": 4, "pass": true }

// What you actually need:
{
  "tool_sequence": ["plan", "list_directory", "search_files", "create_file"],
  "output_tokens": 617,
  "pass": true
}

从冒烟测试到信号

say_hello 令人惊奇的地方不在于模型能够编写 HELLO.txt。而在于一个五个字符的编辑使“精力”变得清晰可见：哪些模型缩小了规模，哪些模型仍在持续规划或搜索，以及哪些系统故障只有在运行数千次后才会显现。

在 VS Code 中使用你喜欢的模型尝试相同的请求，在聊天调试视图中检查其工具调用，并思考你自己的最小有用任务可能是什么。在 VS Code 仓库中分享你的发现。

编码愉快！ 💙