模型正在变成零件（微软开始卖模型外面的那一层）
微软把驱动 Copilot 的 harness 拿出来，开发者可以在 Foundry 上托管或用 SDK 自己跑；同日 GitHub Copilot Fusion GA，Fusion Max 的成绩与成本数字均为厂商自报。
模型正在变成零件。
这句话听起来刺耳，尤其是对那些每周都在追新模型的人。
但看看 10 月 28 日微软官方博客写了什么。
文章由 Foundry 的 CVP Tina Schuchman 和 GitHub CTO Vladimir Fedorov 署名，大意是：想竞争就得多模型，而想用好多个模型，你需要一个好的 harness。今天最前沿的模型，明天可能就落后了。
注意这里的重心。
不是“我们有最好的模型”。
是“我们有一层，能让你不再依赖任何一个模型”。
这一层叫 harness。微软把它从自家产品里拿出来，放进 Microsoft Foundry，对外提供。
这件事值得停下来想一想。
冷水：你一直在优化错的东西
先说清楚 harness 是什么。
据微软官方博客，如果模型提供的是智能，harness 就是模型周围的一切：给 agent 正确的指令、上下文、执行环境和控制，让它能完成真正有意义的工作。
大多数团队把时间花在这里：
- 对比哪个模型分数更高
- 换模型，再调一遍提示词
- 等下一个版本发布
很少有人把时间花在这里：
- 指令怎么写，才能跨模型复用
- 上下文怎么组织，才不浪费
- 工具和权限怎么设计，才可控
前者是追逐。后者是建造。
追逐的成果，会在下一次模型发布时清零。
建造的成果，会在每一次模型发布时增值。
因为更好的模型放进一个更好的系统，收益是叠加的。放进一个临时拼起来的系统，收益会被漏掉很多。
微软官方博客的说法，大意是：改进 harness，它碰到的每个产品都会跟着受益。
微软官方的说法是，自己做 harness 或模型路由去追赶新模型，又慢又痛苦，而且维护比搭建更难。
这句话的潜台词是：harness 比单个模型更难做，也更值钱。
分岔：两种团队
接下来会出现两种团队。
第一种把模型当成产品本身。每次新模型发布，就是一次重建。他们的护城河是“我们用的是最新的”。这条护城河每隔几周就会被填平。
第二种把模型当成可替换的零件。他们的资产是指令、skills、工具和评估方法。新模型来了，换一个零件，系统照常运转。
微软这次做的事，本质上是把第二种团队的基础设施打包出售。
据官方博客，这套 harness 由 GitHub 工程团队打造，已经驱动 Copilot Code、Copilot Studio、GitHub Copilot app、CLI、VS Code 等产品。现在你可以下载 SDK，也可以在云上让 Foundry 托管运行。
它支持 MCP、agent skills 和 agent plugins。官方称可以跨模型家族使用 20+ 前沿模型，外加 BYOK（自带密钥），并按任务把工作路由到合适的模型。
还有一个细节：harness 运行时最近移植到了 Rust。官方称这降低了会话开销和首 token 时间。官方没有给出具体数字，所以这里也不给。
模型决定上限，harness 决定你每天能稳定拿到多少。
三件必须做的事
如果你接受“模型是零件”这个前提，下面三件事就不是可选项。
1) 把指令和 skills 当成资产
微软的分工写得很清楚：微软跑 agent loop 和沙箱，内置治理和优化。开发者提供指令、skills、工具和模型选择。
看看哪一半留给了你。
全是“判断”的部分。
agent loop 可以外包。沙箱可以外包。但你的业务该怎么拆解、哪个工具该在什么时候调用、什么输出算合格——这些是你的 point of view，外包不了。
所以：
- 把指令写成文件，而不是散落在聊天记录里
- 把重复的流程沉淀成 skills
- 给每个工具写清楚边界
这里有一个很少被说破的事实：
提示词是写给某一个模型的。
指令是写给一个系统的。
前者换个模型就要重写。后者换个模型，最多微调几句。
如果你过去一年写下的东西，大部分属于前者，那你积累的其实不是资产，是一次性的适配。
这些东西不会因为换了模型就作废。
2) 让路由替你追模型
同一天，GitHub Changelog 宣布 Copilot Fusion GA。在我看来，它可以当成 harness 之上路由层的一个例子，这是我的归类，不是官方的说法。
据 GitHub 官方介绍，Fusion 有 Standard、High、Max 三档，以及 Single、Cascade、Critique 三种编排方式（站内之前写过 HydraFusion，这里不展开路由细节）。
官方称，在 Artificial Analysis Coding Agent Index 上，Fusion Max 得 60 分，与 Claude Code + Opus 5.5 Max 相差两分以内。同时平均每个任务的 API 成本约为一半，token 约为一半，耗时少约 40%。
这些都是厂商自报的数字。公告里没有给出对比对象的具体分数，你没法只凭这一段判断差距。
但方向是清楚的：未来你不该亲自决定每个任务用哪个模型。你该决定的是“什么算做对了”，然后让路由去找最划算的做法。
你的角色从“驾驶员”变成“curator”。
3) 想清楚控制权在谁手里
这是最容易被忽略的一条。
托管很省事。但省事的另一面是：agent loop 和沙箱跑在别人那里。
微软官方也说了，平台仍然开放，你可以接入其他 harness 和框架。这是好事。但“可以接入”和“实际上迁得走”是两回事。
在决定之前，问自己三个问题：
- 如果明天换平台，我的指令和 skills 能原样带走吗
- 治理规则是我定的，还是平台默认的
- 评估结果存在哪里，我能导出吗
能回答清楚，托管就是 leverage。回答不清楚，托管就是依赖。
三个误区
误区一：有了托管 harness，就不用想架构了。
现实：harness 管的是 loop、沙箱和治理。业务怎么拆、agent 该停在哪一步，还是你的事。
误区二：路由会自动帮你选“最好”的模型。
现实：路由选的是在它的评估标准下“合适”的模型。标准是谁定的，决定了“合适”是什么意思。
误区三：平台开放，所以随时能走。
现实：开放是一种能力，迁移是一种成本。成本不会因为一句“开放”就消失。
看清这三点，你才能把托管当工具用，而不是被它用。
选择
模型会继续变强，也会继续变便宜，继续变得可以互相替换。
这不是坏消息。这是一次重新分配注意力的机会。
你可以继续追下一个模型，每次从头再来。
或者，你可以开始建自己的那一层：指令、skills、工具、评估、品味。
前者让你永远在追。
后者让你终于有东西可以积累。
来源：Microsoft 官方博客（2026-10-28）；GitHub Changelog：Copilot Fusion。Fusion Max 60 分、与 Claude Code + Opus 5.5 Max 相差两分以内、成本和 token 约一半、耗时少约 40% 均为厂商自报，公告未给出对比对象的具体分数；Rust 移植只采用官方定性说法；“模型变成零件”和“Fusion 是 harness 之上的路由层”为作者看法。