同一个智能体任务，今天适合用擅长代码的模型，明天可能要换成更便宜或更长上下文的模型。真正麻烦的往往不是换模型名字，而是模型外围那一整套执行系统：指令怎样装载、上下文怎样组织、工具怎样调用、代码在哪里运行、失败怎样恢复、权限怎样收紧。微软10月28日宣布，将GitHub团队打造并已在公司内部统一采用的Copilot harness，通过Microsoft Foundry提供给开发者和企业。
微软把harness解释为模型之外的编排层。模型提供推理能力，harness负责把指令、上下文、执行环境和控制措施组合成一次可完成的任务。它支持MCP、agent skills和插件，也负责智能体循环与沙箱。这个定义比“又一个模型路由器”更宽：路由只是选谁来做，harness还要决定任务怎样做、在什么边界内做，以及运行结果怎样交回应用。
这套系统已用于Copilot Code、Copilot Studio、GitHub Copilot应用、命令行和VS Code等产品。现在的变化，是微软把内部共用的执行底座变成Foundry里的托管能力。开发者可以下载SDK，也可以在云端运行，不必先为每个模型单独维护一套循环、工具接入和沙箱。
多模型不是把下拉框做长
官方称，这套harness支持20多种前沿模型，也允许客户自带密钥。看起来像是“模型选择更多”，但企业真正获得的是切换时尽量保持上层流程不变。任务仍可沿用原有指令、技能和工具，底层模型则按质量、成本或工作类型调整。
这并不意味着不同模型已经变得完全可互换。模型的输出格式、工具使用习惯、延迟和失败方式仍可能不同。微软承担的是持续评测、路由与执行层优化，应用团队仍要为自己的业务结果设置验收条件。托管harness减少维护工作，不能替代业务侧对正确性和权限的判断。
微软还透露，运行时近期已移植到Rust，目标是降低会话开销和首个令牌等待时间。这个变化发生在执行层，而不是模型本身。对于长时间运行、频繁调用工具的任务，外围开销会被重复放大；将运行时做得更轻，可能比单次模型生成快几十毫秒更影响整体体验。不过公告没有给出统一的延迟降幅，也不能据此推断所有任务都会更快。
企业买到的是托管责任，不是结果担保
在Foundry中，微软负责运行智能体循环和沙箱，并把治理与优化放进基础层；客户提供指令、技能、工具和模型选择。这个分工很重要。它把“谁维护执行引擎”交给平台，却没有把“工具能访问什么数据”“一次写入是否需要批准”“输出是否符合业务事实”一并交出去。
统一底座也带来新的集中风险。多个产品共享同一harness，改进可以同时扩散，缺陷也可能跨表面影响更多任务。因此企业需要保存模型、harness版本、工具权限和关键动作回执，不能只记录最终用了哪个模型。公告所说的持续改进，是平台承诺的方向，不等于客户无需做回归测试。
对开发团队，最实际的变化是智能体架构开始从“围着某个模型搭一套应用”转向“先建立稳定执行层，再接入不同模型”。模型仍决定能力上限，harness决定能力能否在真实系统里被约束、观察和复用。微软开放的不是一颗新大脑，而是让多颗大脑在同一工作台上协作的外骨骼。
对于已经接入多家模型的团队，这也改变了成本核算的单位：不再只比较每百万令牌价格，还要计算评测、路由、沙箱、会话恢复和工具维护的总成本。harness能把其中一部分变成平台服务，但选择权越多，记录每次实际选择与结果的要求反而越高。
