微软开放 Copilot Harness：同一套智能体底座，换模型不用重写

10 月 28 日，微软在官方博客上宣布：把自家 Copilot 产品一直在用的智能体“底座”开放出来，开发者和企业客户可以通过 Microsoft Foundry 用上它。这件事听起来像又一次平台发布，但它真正值得注意的地方不在“又多了一个产品”，而在微软把竞争的焦点往下挪了一层：模型可以换，底座才是自己的。过去一年大家争的是谁家的模型更强，微软这一步等于在说，模型会轮换，管模型干活的那套东西才是长期资产。

先把最核心的事实摆清楚。微软所说的 harness，原文的定义是“模型之外的全部东西”：给智能体正确的指令、上下文、执行环境和控制手段的那一层编排。Copilot Code、Copilot Studio、GitHub Copilot 应用、Copilot 命令行和 VS Code 背后跑的都是同一套 harness，它由 GitHub 的工程师团队建造，微软内部已经全公司采用。这次开放的，就是这一套东西，入口是 Microsoft Foundry：可以下载 SDK 自己跑，也可以在云端用 Foundry 托管的版本，微软负责跑智能体循环和沙箱，里面内置了治理和优化，开发者带来自己的指令、技能、工具和模型选择。

这次到底开放了什么

第一，跨模型。微软说这套 harness 天生就是为多模型设计的，支持 20 多个前沿模型，还支持自带密钥（bring your own key），会按任务把活儿路由给合适的模型或者几个模型组合。这句话要拆开听：它承诺的不是“所有模型都一样好用”，而是“你不用为了换模型重写一整套管法”。对开发者来说，换模型的成本从“重做编排层”降到了“换一个模型选择”。但要注意，微软博客没有给出任何跨模型的基准数字，也没有说路由策略长什么样——路由是按成本、按速度还是按任务类型，原文没有展开，这部分只能等实际用起来再验证。

第二，开放标准。harness 支持 MCP（Model Context Protocol）这类开放标准，还有智能体技能（agent skills）和智能体插件。这一点很重要，因为它决定了这套底座是不是只能接微软自家的东西。微软在文末也补了一句：平台保持开放和互操作，开发者可以继续用任何自己想用的 harness 和框架。这句话是说给担心被锁定的企业听的，但也要诚实地说：开放标准支持和“换底座零成本”是两回事，技能、工具和治理配置一旦按这套 harness 的方式写深了，迁移仍然有成本。

第三，性能工程。微软提到最近把 harness 的运行时移植到了 Rust，带来了行业领先的性能， session 开销和首 token 时间都有所降低。但原文没有给出任何具体数字：降低了多少、跟什么基线比、什么场景下测的，一概没说。所以这句话目前只能当作厂商说法听，不能当作实测结论写。同样，博客说这套 harness“在数百万用户和数百个真实场景的规模下经过实战检验”，这也是微软自家产品的规模背书，不是第三方评测。

第四，分工。微软把分工说得很直白：微软跑智能体循环和沙箱，治理和优化从第一天就内置；开发者带来指令、技能、工具和模型选择。这个分工对小团队最友好：以前要自己搭“模型路由器 + 沙箱 + 审批 + 观测”这一整套，现在可以只写业务部分的指令和工具。但分工的另一面是：治理规则、沙箱边界、优化策略的默认值都在微软手里。你的智能体能调什么工具、能花多少钱、出错时怎么停，这些关键默认值是谁定的，部署之前要先翻一遍配置，不要默认全盘接受。

为什么是现在：模型在轮换，底座在沉淀

微软博客开篇就点出了时机：今天最强的模型，明天可能就落后了。自己搭一套能跟上模型迭代的 harness，又痛苦又慢，维护起来更难。这句话放在 10 月 28 日这个时间点上有特殊的上下文：同一天，GitHub 还把 Copilot Fusion 推向了全面可用——选模型这件事本身正在被平台接管；同一天，GitHub Copilot SDK 也开始向 Microsoft Copilot SDK 过渡，SDK 的定位从“GitHub Copilot 的编程接口”变成了“微软 Copilot harness 的编程接口”。三件事拼在一起，微软的意图就很清楚了：模型层交给市场去卷，微软要卡住的是模型之上的那一层。

对开发者来说，这个判断意味着选型逻辑要变。以前选型先问“用哪个模型”，以后可能要先问“用哪套 harness”。模型可以在 harness 里换，但 harness 一旦选定，技能写法、工具接入方式、治理配置、观测数据都会围绕它长出来，迁移成本比换模型高一个数量级。所以评估 harness 的时候，真正要问的问题不是“它支持多少模型”，而是：我的技能和工具能不能原样搬走？治理规则能不能按我的合规要求改？账单能不能按任务拆开算？这三个问题的答案，比“20+ 模型”这个数字重要得多。

对企业客户来说，还有一个更现实的考量：Foundry 托管版和自跑 SDK 版是两条不同的路。托管版省事，微软管循环、管沙箱、管优化，但数据和执行环境也在微软的云里；自跑版可控，但维护责任回到自己手里。博客把两条路都摆出来了，却没有说清两条路在功能、计费和合规上到底差什么。选型之前，这张对照表要找微软销售或者文档要到手，不要凭博客里的两句话做决定。

先别急着追的三件事

第一，别把“可用”等同于“全面上市”。微软博客用的词是“通过 Foundry 提供”，没有用全面上市（GA）来描述 harness 本身。同日 Foundry 方面的消息有第三方报道称其在 Foundry Agent Service 里是公开预览，另外还提到了托管智能体长时运行韧性的全面上市——但这两点来自第三方报道口径，不是微软这篇博客的原文，本文把它们明确标为第三方说法，不当作官方承诺。公开预览意味着接口、计费和限制都可能变，生产系统接入之前，先确认预览条款里有没有你不能接受的限制。

第二，别被“20+ 模型”带偏。支持 20 多个模型不等于 20 多个模型都一样好用，也不等于免费。每个模型有自己的价格和速率限制，harness 帮你路由，但账单还是按模型收的。真正要测的是：在你的任务上，路由选出来的模型是不是真的比你自己指定的更好、更便宜。建议拿自己的一组真实任务跑两周对比：固定模型一组、harness 路由一组，比任务成功率、token 花费和延迟三项，再决定要不要把路由权交出去。

第三，别忽略治理这条线。博客反复强调“治理从第一天就内置”，对企业来说这是卖点，但对开发者来说这是必查项：工具调用要不要审批、审批能不能按路径和风险分级、智能体花超预算时是停还是告警、沙箱里能不能访问内网资源。这些问题在博客里都没有答案，答案在 Foundry 的文档和配置里。接入之前先把这张治理清单列出来，逐项在文档里找到对应项，找不到的就先当作不支持来规划。

这对 vibe coding 意味着什么

对 vibe coding 的实践者来说，harness 开放最直接的影响在提示词和技能的写法上。以前很多人把“怎么干活”写进提示词里：先读什么文件、用什么工具、什么情况下停下来问人。harness 把这一层抽出来之后，这些东西会越来越多地写成技能和配置，而不是提示词。这是个好方向：技能可以复用、可以测试、可以版本管理，提示词做不到这三点。但这也意味着，过去攒的那套“万能提示词”会慢慢贬值，值钱的东西会变成一套可测试的技能库和一套说得清的治理规则。

还有一个值得注意的信号：微软说“改进 harness，所有用到它的产品都受益”。这句话反过来也成立——harness 的问题也会同步扩散到所有产品上。过去 Copilot 各产品线的体验差异，某种程度上是各产品自己调参的结果；统一底座之后，差异会缩小，但单点故障的影响面也会变大。对依赖 Copilot 全家桶的团队来说，这意味着要更认真地看 harness 层的更新日志，而不是只看自己用的那个产品的更新日志。

最后，把这篇和站内已有的几篇“harness”文章区分开：10 月 8 日的 Harness 收购 Augment Code 讲的是一家叫 Harness 的公司收购另一家公司；10 月 21 日的 Vercel durable-harness 讲的是开源的崩溃续跑脚手架；10 月中旬的 Chainguard Harness 讲的是用 AI 找漏洞的产品。它们和今天这篇讲的微软 Copilot harness 不是同一个东西，名字撞了，产品完全不同。本文讲的只是微软这一套：GitHub 团队建造、全公司采用、现在通过 Foundry 对外开放的智能体底座。名字容易混，选型的时候先对一下全名，别被“harness”这个词带偏。

一句话总结：微软这次不是在卖一个更强的模型，而是在卖“模型可以随便换、底座不用重写”这个承诺。承诺值不值钱，取决于三件事：你的技能和工具能不能搬走、治理规则能不能按你的要求改、路由是不是真的比你自己选更省。对小团队来说，先拿一个非核心任务试两周，再决定要不要把核心任务也交过去，是最不吃亏的做法。

自研 harness 的成本账：为什么微软敢说“别自己搭了”

要理解微软这篇博客的底气，得先算一算自己搭一套 harness 到底要花多少钱。表面上看，harness 就是“调模型、给工具、跑循环”三件事，找个开源框架拼一周就能跑起来。真正贵的部分在后面，而且每一项都不好外包。第一是评测：模型一换，同一套提示词和工具组合的表现就会变，你需要一套固定的任务集，每次换模型、每次改提示词都重跑一遍，否则根本不知道是变好了还是变差了。没有评测集的 harness，每次升级都是一次赌博。第二是成本控制：智能体循环跑起来之后，token 花费不像调用一次模型那样可预测，一个任务可能循环三步，也可能循环三十步，没有预算上限、没有中途熔断，账单会在某个月底给你一个惊喜。第三是安全边界：沙箱不是“把命令关在一个容器里”就完事了，工具调用的审批、敏感路径的隔离、密钥的注入方式、出错时的回滚，每一项都要单独设计和测试。

这三项加起来，就是微软说的“维护比建造更难”。建造是一次性的，维护是持续的：模型每个月都在换，工具接口每个季度都在变，安全威胁每周都有新的花样。一个三五个人的小团队，自己维护这套东西，等于长期抽一个人出来专门伺候底座。这就是托管 harness 真正的卖点：它卖的不是功能，而是把维护工作外包出去。对小团队来说，这笔账很好算——如果你的团队没有专人负责底座，托管版省下来的人力通常比它收的费用贵得多；如果你的团队已经有成熟的底座和评测集，换过去的迁移成本反而可能高于收益，那就没必要为了“微软同款”四个字折腾。

还有一个经常被忽略的成本：观测。智能体出问题的时候，你要能回答三个问题：它走了哪几步、每一步调了什么工具、花了多少钱。没有这三项记录，调试智能体就是纯靠猜。微软博客提到“治理和优化内置”，观测应该是其中一部分，但博客没有展开观测数据的粒度：能不能按任务、按工具、按模型拆开看？数据保留多久？能不能导出到自己的系统？这些问题在选型时要逐项确认，因为一旦用上托管版，观测数据的口径就由平台定了，事后想换口径很难。

上手路径：先拿一个非核心任务试两周

如果你想试这套 harness，建议按三步走。第一步，用 SDK 在本地跑一个最小任务：给智能体一个明确的、失败了也不心疼的任务，比如“读一份公开文档，整理成一张表”，先验证 SDK 的接入成本和基本表现，不要一上来就接核心业务。第二步，把这个任务放到 Foundry 托管版上跑一遍，对比两条路的体验差：部署要多久、治理配置在哪里改、账单能不能按任务拆开。第三步，列出你的治理清单，逐项在文档里找到答案：工具审批能不能按路径分级、预算超了是停还是告警、沙箱能不能隔离内网资源、观测数据能不能导出。三步走完，你对这套 harness 的判断就不再是博客给的印象，而是自己测出来的结论。

也有三种情况建议先不追。第一，你已经有一套跑顺了的 harness，技能、评测、治理都齐了，换底座的收益盖不过迁移成本，那就继续用自己的，等这套 harness 再成熟一版。第二，你的合规要求数据不能出自己的云或者机房，托管版直接出局，只能考虑自跑 SDK 版，而且要先确认 SDK 版的功能和托管版是不是对齐的。第三，你的任务根本不需要智能体循环，一次模型调用加固定流程就能解决，那就不要为了“智能体”三个字引入一整套底座，简单任务用简单架构，是成本最低的选择。harness 是给长任务、多工具、需要反复决策的场景准备的，不是给所有任务准备的。

把分工再说透一点：微软跑循环和沙箱，开发者带来指令、技能、工具和模型选择。这个分工对三五人的小团队最划算，因为底座的维护工作被外包了；但对已经有成熟底座的团队，迁移成本可能高于收益。判断标准不在博客里，在你自己的账本里：你的团队有没有专人维护底座？你的技能库能不能原样搬走？你的治理要求能不能在对方的默认值上改出来？三个问题有一个答不上来，就先拿非核心任务试两周，别急着把核心任务交过去。

顺带补一句：选型时还要问清一件事——harness 的改进会不会自动同步到你自跑的 SDK 版，还是只先给托管版。博客说“改进 harness，所有用到它的产品都受益”，但这句话说的是微软自家产品；外部开发者用的 SDK 版，更新节奏和托管版是不是一致，博客没有说。生产接入之前，这个更新节奏要先确认，否则你可能在用一个落后托管版几个版本的底座而不自知。