五万次运行的启示：5 行 eval 如何度量 VS Code 智能体模型的努力校准与 Token 成本

文档教程【免费下载链接】vscode-docsPublic documentation for Visual Studio Code项目地址https://gitcode.com/gh_mirrors/vs/vscode-docs点击查看免费下载2026-06-19 · VS Code Eval Team作者Julia Kasper2025 年底到 2026 年年中VS Code 团队在六个月里把同一个只有 5 行定义的say_helloeval 重复运行了50,974 次覆盖30 个模型把一次向文件写入字符串的冒烟测试变成了一份观测模型努力校准effort calibration、工具使用纪律tool discipline与输出 Token 成本的数据集。读完本文你将理解为什么最简单的 eval 反而是最灵敏的仪表学会用工具调用序列 输出 Token两个维度评估编码模型的真实效率并了解 VS Code 与 GitHub Copilot 如何把这些信号接入自动模型选择。从编码 harness 到最小的冒烟测试要理解这次实验需要先回到它的上游VSC-Bench。在仓库的前一篇博客《GitHub Copilot in VS Code 背后的编码 harness》中团队介绍了 VSC-Bench——用于度量 VS Code 智能体行为的离线评测套件。它强调一个核心观点开发者真正交互的不是模型本身而是编码 harness——负责组装上下文、暴露工具、运行智能体循环、解释工具调用并把模型输出变成编辑器内实际动作的那一层。正是这套 harness 让工具调用序列成为一个可观测、可记录的信号上下文组装context assembly请求到达模型之前harness 会把系统消息、用户查询、工作区结构、对话历史、工具结果等拼装成 prompt工具暴露tool exposureharness 声明模型允许调用的工具读文件、编辑、终端、搜索等每个工具都有 JSON Schema 与描述工具执行tool execution模型请求调用工具后由 harness 负责校验参数、执行、处理错误并把结果回传给下一轮迭代。say_hello就是这套 harness 上的体温计一个任务足够简单简单到任何变化都只能来自模型或 harness 本身而不是任务复杂度带来的噪声。因此它能灵敏地反映 harness 回归、基础设施事故和模型行为差异——一个简单任务是有价值的恰恰因为它剔除了变量。say_hello 的定义5 行 eval 的完整配置say_hello围绕一个想法构建每一次运行都从同一个空工作区开始使用相同的工具、相同的固定 prompt 和相同的 VS Code 智能体 harness。任务本身只要求智能体向 HELLO.txt 写入 HELLO并检查两条断言文件存在、内容正确。完整的 eval 定义如下promptSteps: - text: Add HELLO to HELLO.txt. assertions: - check: file_exists(HELLO.txt) - check: file_contains(HELLO.txt, HELLO)这份 YAML 值得拆开来看promptSteps定义一次运行要发给智能体的用户指令序列。say_hello只有一个步骤、一条指令因此任何跨运行的行为差异都不可能是任务理解偏差造成的text发送给智能体的 prompt 原文固定不变assertions判定通过与否的检查器。file_exists(HELLO.txt)验证文件是否被创建file_contains(HELLO.txt, HELLO)验证内容是否精确匹配——两条断言共同构成正确结果唯一且无歧义的通过标准。因为say_hello在每个基准测试套件运行前都会先作为冒烟测试执行一次它悄无声息地在六个月里积累了 50,974 次运行、跨越 30 个模型。这个规模把一次基本的健全性检查变成了一份关于不同模型如何处理最简单任务的数据集。[!NOTE] VS Code eval harness 会把工作区状态包含在初始 prompt 上下文中。我们假定模型不应该执行冗余的存在性检查——这正是 harness 上下文组装职责在 eval 中的体现模型拿到 prompt 时应当知道工作区是空的。理想路径一次 create_file 调用一个开发者做这件事时会先意识到工作区是空的然后创建HELLO.txt并写入要求的内容。在 VS Code 智能体最直接的路径里这对应一次create_file工具调用内容就是HELLOtool : create_file args : { filePath: /path/to/workspace/HELLO.txt, content: HELLO }这条直达路径direct path是本次分析的核心基准一次工具调用、无规划、无探索、无搜索直接产出正确结果。为了建立基线团队筛选出走这条路径的通过运行并观察其中最低的输出 Token 数——这些运行平均约50 个输出 Token含工具调用结构本身这就是本任务现实可行的下限。模型如何解决 say_hello直接路径的四层分布如预期的那样say_hello足够简单所有模型大多数时候都能通过。有意思的不是能不能做而是怎么做模型能否识别出这是一个只需简单方案的基础请求还是会像处理复杂问题一样先规划、再探索、再搜索下图展示各模型在通过运行中达成单次工具调用直达路径的占比数据的分布可以清晰地分为四层榜首100%Model-A 独占。它在 100% 的通过运行中都直接创建文件每次都只用一次工具调用从不先做规划或探索跟随组71%–73%Model-B 与 Model-C 分别以 73% 和 71% 紧随其后中部集群19%–52%Model-D 至 Model-P 直接路径的达成率在 19% 到 52% 之间。它们能识别简单任务但不够稳定——更多时候会先加一个小步骤读取内部状态或做轻量工作区探索再创建文件底部集群0.2%–6%Model-Q 至 Model-X 很少走直接路径其中五个模型低于 1%。对它们而言额外工作是默认行为——几乎总是先规划、探索或搜索才产出同一个只有 5 个字符的文件零达成0%Model-Y 至 Model-AC 这五个模型在数千次通过运行中从未走过直接路径。它们总是先做点别的规划、改用 patch 工具而不是简单的文件创建、先搜索再规划、或者长篇叙述后才创建文件。对它们来说哪怕最简单的请求也会触发完整的那套复杂任务机制。所有模型最终都创建了内容正确的文件但达成同一结果所付出的工作量天差地别。在一个几乎没有任何歧义的任务上部分模型仍然要规划、搜索或选择更复杂的编辑工具——全部通过了 eval但通过的努力量并不相同。顺带一提仓库中与本文同目录附带了一份图表生成脚本 generate_chart.py。从脚本结构看它是一份可复现的 SVG 图表管线每个模型一行绘制横向条形图按厂商Vendor A/B/C/D用不同颜色区分并对达成率为 0% 的模型追加红色注解最终把 SVG 写入临时 HTML 供预览核对。这说明这类评测数据图表是数据驱动、可再生成的资产而不是手绘的示意图。多余的开销花在哪里五种典型模式因为离线 eval harness 会记录完整的工具调用序列团队可以把这些 trace 转成模型行为模式。跨运行统计后模型的额外努力主要落在五种熟悉的形式上开销模式频率代表模型具体表现先规划再行动52–99%Model-AC、Model-Z、Model-S 及其他 13 个模型在创建 5 字符文件之前先起草清单或读取内部状态。可测量的 16 个模型里每个都至少在一半的运行中如此Model-AC 达到 99%Model-Z 达到 96%。有一次甚至在单步任务里出现了 4 个规划步骤。探索空工作区56–96%Model-T、Model-Q、Model-AA在空工作区里列目录或搜索文件。Model-T 在 96% 的运行中都会列目录Model-AA 在 56% 的运行中既列目录又搜索——在空房间里寻找线索。叙述推理过程1,441–3,676 TokenModel-AB、Model-M、Model-U输出远多于任何工具调用需要的文本一边推理一边反复确认任务。这三个模型在输出 Token 榜上登顶是现实下限的 29–74 倍而文件本身只有 5 个字符。用错工具约 95%Model-AA使用面向修改既有文件的复杂 patch/编辑工具而不是简单的文件创建——好比用数控机床去裁一张纸。运行终端命令3–14%Model-W、Model-Z、Model-V在存在更简单的文件创建 API 时选择运行终端命令如echo HELLO HELLO.txt。这些都不是正确性失败。它们是**模型未能一致地识别最短路径何时已经足够**的信号。在长任务上规划与探索可能非常宝贵但在单步任务上它们只增加延迟和成本不改善结果。过度思考的代价输出 Token 的四档分布为什么要关心模型写一个 5 字符文件多走了几步因为这些额外步骤并不免费——它们会直接转化为输出 Token 消耗而输出 Token 意味着真金白银的成本。对这个简单任务而言约 50 个输出 Token 是现实可行的下限。下图展示不同模型每次运行的平均输出 Token 数跨度从贴近下限一直到数千 Token而产出的都是同一个HELLO.txt图表清晰地分成四个波段极端组1,441–3,676 TokenModel-AB、Model-M、Model-U 平均分别消耗 3,676、2,120、1,441 个输出 Token——对同一个 5 字符结果而言是现实下限的29 到 74 倍高开销组400–1,000 TokenModel-AA、Model-B、Model-N、Model-H、Model-V、Model-E、Model-S、Model-K。没有到数千级别但仍约为现实下限的8 到 12 倍中等组150–400 TokenModel-P、Model-D、Model-X、Model-T、Model-G、Model-Z、Model-I、Model-AC、Model-F、Model-J、Model-Q。它们有额外开销但更贴近任务的天然规模高效组低于 150 TokenModel-R、Model-A、Model-Y、Model-W、Model-O、Model-C、Model-L。其中 Model-L 以平均 55 Token 最接近现实下限——即使不总走直接工具路径也能在几乎不叙述的情况下完成任务。从产品视角看这与 VS Code 文档中关于语言模型的说明相互印证docs/agents/concepts/language-models.md 指出思考 Tokenthinking tokens同样计入上下文窗口、即使不可见也会影响延迟而更高思考强度会带来更多思考 Token。选一个想得更少的模型能同时节省时间与金钱但要知道哪个模型在具体任务上最高效通常意味着要跑自己的基准。为了替开发者承担这个负担VS Code 与 GitHub Copilot 团队持续投入优化与模型路由。模型大小并不预测开销团队最初的假设是更大的模型想得更多但数据否定了这一点Model-F同族中较大的模型平均只用 160 个输出 Token、2.1 次工具调用——是它所属模型家族中最自律的一个Model-H同族中较小的模型平均消耗 485 个输出 Token、3.7 次工具调用——开销反而高于它的大兄弟Model-AB一款 mini 模型是全部样本中开销最高的平均 3,676 个输出 Token——样本里最小的模型干了最多的活。团队的解读是在每个模型家族内部新一代的模型趋势上更自律与参数量无关。这指向训练成熟度training maturity——模型能否把自己的努力按眼前任务的规模缩放。而这种校准能力并非学术好奇它直接体现在账单上。走向何方从洞察到工程决策团队从这些运行中提炼了几条关键洞察其中一些也可以直接应用到你自己的日常流程里。[!NOTE]say_hello给了我们很好的洞察但它只代表一个任务。对于 harness 优化我们避免只围绕单一任务做过度优化。我们仍然会定期在多样化的任务集上运行完整基准以验证改动是否在大面上改善了 harness。让模型与任务匹配GitHub Copilot 采用基于用量的计费后输出 Token 同时代表金钱和时间。在这个任务上最精简与最沉重的模型之间同样的输出相差约70 倍。最直白的教训似乎是别拿最大的模型去写 HELLO但这个教训太粗糙——看清为什么才是say_hello教给团队最有用的东西。这里有一个重要的前提say_hello是单步、单正确答案的短视界任务。在长视界工作上规划、探索和推理可以避免昂贵的错误、提高完成几率。目标不是消灭规划而是理解模型能否区分一步任务和三十步任务。这也是为什么团队认为模型选择不应该成为开发者的负担。努力校准、Token 效率、工具纪律这类信号可以帮助自动模型路由为手头任务挑选合适的模型而不必要求开发者权衡每一个取舍。仓库文档对这套机制有明确描述docs/agents/concepts/language-models.md#auto-model-selection 说明VS Code 的自动模型选择由两套系统协同一套实时跟踪模型健康度与可用性另一套评估任务复杂度两者共同把请求路由到能以最高效率解决问题的模型——把高成本推理模型留给真正需要它的难题把简单任务路由给更快的模型同时尊重组织级的模型访问策略。团队表示会继续投资和研究自动模型选择让产品替开发者逐步做出更多此类决策。从小处着手好好测量大多数团队一开始并没有一套每天可跑的私有离线基准套件。但哪怕是一个简单任务只要稳定运行、完整记录也能揭示模型或系统行为的有用变化。实践建议如下从拥有无歧义正确答案的最小任务开始然后持续运行它把它当作夜间评测之前、新模型接入之前、基础设施变更之前的预检preflight检查任务不需要巧妙它需要的是足够稳定——稳定到通过率、延迟、工具使用或失败模式的变化都有意义。最关键的一点是记录足够的结构来解释发生了什么。要记录工具调用序列而不只是调用次数。知道有 4 次工具调用是有用的但不够知道模型先规划、再探索、再搜索、最后创建文件才能告诉你开销来自哪里、为什么这次运行更贵// 大多数 harness 只记录 { tool_calls: 4, pass: true } // 你真正需要的是 { tool_sequence: [plan, list_directory, search_files, create_file], output_tokens: 617, pass: true }这套结构化日志的思路与仓库中智能体调试文档的设计一致文档提供了多个互补的诊断视图——Chat Debug 视图展示发送给模型的 prompt、上下文与工具Summary 视图汇总耗时、Token 用量与错误Logs 视图按顺序还原事件。这些能力同样服务于看清工具调用序列而不是只看计数这一目标。从冒烟测试到信号say_hello最出乎意料的地方不是模型能写出HELLO.txt而是一次 5 字符的编辑让努力变得可见哪些模型会按任务规模收缩哪些始终在规划或搜索又有哪些系统级故障只有在数千次运行之后才会显形。你也可以在自己的 VS Code 里复现这个实验用你偏好的模型发出同样的请求打开 Chat Debug 视图 检查它的工具调用序列与 Token 消耗然后想一想——属于你自己的最小有用任务是什么。用上文的两条标准稳定 无歧义答案把它固定下来、持续运行、完整记录工具序列你就能把一次冒烟测试变成长期观察模型行为与成本的长效信号。赞分享文档教程【免费下载链接】vscode-docsPublic documentation for Visual Studio Code项目地址https://gitcode.com/gh_mirrors/vs/vscode-docs点击查看免费下载相关推荐Claude Code /code-review 低努力模式Low Effort解析一次 Diff 扫描完成运行时正确性审查Claude Code /code review 低努力模式Low Effort解析一次 Diff 扫描完成运行时正确性审查 本文基于开源仓库 claud文档提示工程人工智能Go并发编程实战第2版示例项目5种并发模式的最佳实践与应用场景Go并发编程实战第2版示例项目5种并发模式的最佳实践与应用场景 Go语言以其出色的并发编程能力而闻名而《Go并发编程实战》第2版示例项目正是学习和掌握Go并从源码到部署Argon Design System React项目完整流程指南从源码到部署Argon Design System React项目完整流程指南 Argon Design System React是基于Bootstrap 4创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考