VS Code 官方发了一篇重磅博客，把 GitHub Copilot 背后的 coding harness 架构公开拆解——上下文装配、工具调用、agent loop、终端执行、记忆系统，全部摊开讲。核心判断：模型只能产出文本，把文本变成"能改代码、能跑测试、能自己修 bug"的工程系统，才是 AI 编程产品真正的竞争力。
2026 年 5 月 15 日，Visual Studio Code 官方账号在 X 上发了一条帖子，开头就跟主流讨论唱反调：
"The conversation around AI for developers usually starts with the model. But inside @code, what really shapes the experience is the coding harness: the layer responsible for context, tool calling, agent loops, terminal execution, memory, and more."
「开发者聊 AI 通常从模型开始。但在 VS Code 内部，真正塑造体验的是 coding harness：负责上下文、工具调用、agent loop、终端执行、记忆等能力的那一层。」
这条帖子链接到官方博客《The Coding Harness Behind GitHub Copilot in VS Code》，作者是 Julia Kasper、Megan Rogge 和 Aaron Munger——VS Code 的核心工程团队。
每次新模型发布，开发者社区的第一反应永远是：哪个最强？哪个最快？该换谁？VS Code 团队说，这些问题有价值，但对于实际产品来说，模型只是 agentic coding experience 的一部分。
那另一部分是什么？
博客里给了一个非常直接的定义：
"Language models do not edit files, execute commands, or run tests by themselves. They can only produce text."
「大语言模型本身不会编辑文件、执行命令或跑测试。它们只能产出文本。」
这个判断看起来简单，但很多人确实没想过这一层。你在 VS Code 里让 Copilot 改一个文件、跑一段测试、看终端输出然后继续修——这整个过程里，模型做的事情只有一件：生成文本。
谁在编辑文件？谁在跑命令？谁在把终端输出喂回给模型？谁在判断该不该继续下一轮？
答案是 coding harness。
"The coding harness is the system that acts as a bridge between the code editor and the language model."
「coding harness 是代码编辑器和语言模型之间的桥。」
VS Code 团队给了一个比喻，博客收束句写得很到位：
"The model is the engine. The harness is the car."
「模型是引擎，harness 是整辆车。」
引擎当然重要。但没有车身、方向盘、传动系统和刹车，引擎跑不上路。
博客把 coding harness 的职责拆成三块：
在请求到达模型之前，harness 要构建 prompt。这个 prompt 包含 system message、用户请求、workspace 结构、语言和框架信息、打开的编辑器、对话历史、之前的工具结果、custom instructions、记忆……
关键点在于：harness 决定模型能看到什么。 你给它全局 repo 还是只给当前文件，直接影响输出质量。上下文装配做得好，模型像一个熟悉项目的同事；做得差，模型像一个只看了 README 的实习生。
harness 声明模型可以调用哪些工具——读文件（read_file）、改代码（replace_string_in_file / apply_patch）、跑终端命令（run_in_terminal）、搜索代码库（semantic_search）……
每个工具都有 JSON schema 和描述。工具集合可以按请求变化：有的模型才启用，有的需要用户确认，用户也可以在 tool picker 里自己开关。MCP server 和扩展还能贡献新工具，custom agents 可以限制工具子集。
当模型请求运行工具时，harness 验证参数、运行工具、处理错误、格式化结果并在下一轮反馈给模型。比如模型要求编辑文件，harness 写 diff；要求跑 shell 命令，harness spawn 进程、捕获输出并转交。
简单说：上下文决定模型能看到什么，工具决定它能做什么，执行层决定它能不能安全、可控、可复现地做下去。
很多用户的感知是"我说一句，AI 改了代码"。但实际上中间可能经历了多轮读文件、改文件、跑测试、看输出、修失败。
VS Code 官方把这个循环描述为：
"think → act → observe → think again"
每一轮（round），harness 构建 prompt，把 system instructions、context、history、所有工具结果发给模型。如果模型响应里有 tool calls，harness 执行工具、捕获结果，然后回到下一轮。没有 tool calls 时，才结束这一个 turn。
博客还特地区分了三个层级：
真实体验好不好，取决于 loop 控制、取消检查、工具调用上限、stop hooks、历史压缩这些细节。用户看到的是"AI 帮我修好了 bug"，看不到的是 harness 在背后跑了多少轮、每轮喂了什么上下文、哪次工具调用失败了、怎么恢复的。
博客里有一段对产品团队来说特别扎心的内容：GitHub Copilot in VS Code 支持不断扩大的模型生态，开发者可以切换模型、用 auto-selection、自带 API key、通过扩展装额外 provider。
这意味着 VS Code 面对的是"广泛且持续演化的模型生态"。同一个 harness 要伺候完全不同的模型——它们在 tool calling、structured outputs、reasoning controls、prompt caching、context limits、error behavior 上都不一样。
官方给了几个具体差异：
replace_string_in_file 做编辑；GPT 模型用 apply_patch所以你在不同 AI 编程工具里用同一个模型，体验可能天差地别。差距往往出在产品层有没有针对这个模型做适配——prompt 对不对、工具 schema 对不对、conversation 管理有没有处理好那些边界情况。
模型越多，harness 就越成为产品本身。
公共 benchmark 怎么看？VS Code 团队态度明确：有用，但在 frontier 水平上已经不够了。
博客提到，SWE-bench 更偏公开 bug-fixing task，Terminal-Bench 更偏 isolated terminal puzzles。但真实 coding agent 还要 scaffold projects、migrate codebases、跨文件重构、遵循指令、处理 terminals 和 browsers——这些场景公共 benchmark 覆盖不到。
所以 VS Code 团队构建了 VSC-Bench，一个面向 VS Code agent behavior 的 offline evaluation suite。它覆盖的任务包括：custom agent modes、extension workflows、MCP/tool use、terminal/browser interaction、多轮对话，以及 TypeScript、Python、C++ 等多语言任务。
衡量维度有四个：solution correctness、agent effort、token efficiency、latency。
博客展示了一张图表：40 次 VSC-Bench runs，覆盖 8 个 model-effort configurations。每个点代表一种配置；越高代表解决更多任务，越靠右代表消耗更多 tokens。官方特别指出，某些 extra-high effort 配置消耗更多 tokens 但解决率反而略低——"想得更多"未必带来更好结果。
需要注意：VSC-Bench 目前是 VS Code 的内部评测工具，用于判断新模型、新 prompt、新工具改动是否真的改善体验。它补足了公共 benchmark 的盲区，但还没有成为公开行业标准。
VS Code 已经开始把 harness 的内部状态暴露给开发者。官方文档《Debug chat interactions》提供了两个调试工具：
"Visual Studio Code provides tools to help you understand what happens when you send a prompt to the AI."
「VS Code 提供工具帮你理解：当你发一句 prompt 给 AI 时，背后到底发生了什么。」
这意味着 AI 编程工具的下一阶段竞争，不只是谁跑得快、谁模型强，还要看谁能让用户（和工程师）看见 agent 在干什么——可观察、可调试、可审计。
X 上的开发者回复里，@this_subhan 说：
"This is the part people skip when they say 'just use a better model'."
「这正是那些说'换个更好的模型就行'的人跳过的部分。」
他还补了一句：
"Models are flashy, but the harness is where the real product decisions live."
「模型很耀眼，但真正的产品决策藏在 harness 里。」
@rtheoryxyz 的评论更尖锐：
"The harness is where model capability becomes actual work instead of a leaderboard screenshot."
「harness 是模型能力变成真实工作的地方，而非停留在榜单截图上。」
@inflectivAI 做了一个对比：
"A strong coding harness can make an average model feel powerful, while a weak harness can make a great model frustrating to use."
「强的 harness 能让普通模型用起来很强，弱的 harness 能让顶级模型用起来让人抓狂。」
但也有人提出了重要的补充。@MindTheGapMTG 提醒：harness 的视角还不完整，缺的是 constraint architecture——没有权限边界的 tool calling，像把 root 权限交给一个 junior dev。
这个观点很值得注意：harness 一边在放大模型的能力，一边也在承载风险。 它能调用终端、能编辑文件、能跑任意命令、能接 MCP server——这些执行面如果没有权限、确认、审计和隔离机制，能力越强，风险越大。
VS Code 这篇博客的行业意义在于，它把一个很多产品团队心里知道但很少公开讲的判断说出来了：
AI 编程工具的竞争焦点，正在从"谁第一个接入最新模型"转向"谁拥有更成熟的 agent runtime"。
早期的 AI 编程工具主要是补全和问答，用户关注的是模型聪不聪明。现在 coding agent 要打开 repo、读文件、生成 diff、跑测试、看失败、继续修，还要接 MCP、浏览器、终端、私有上下文和 custom instructions。
在这个阶段，产品差异不再只是"接了哪个模型的 API"，而是：
模型是引擎。但真正让 AI 从"能聊天"变成"能干活"的，是围绕模型搭建的整套系统。
VS Code 把这层摊开讲了。接下来，看其他玩家怎么跟。
— END —