简介：微软把"骨架"开源了
GitHub Universe 2026 上，微软发布了全新的 Copilot 矩阵，同时宣布一个更重要的动作：把 GitHub 团队研发的 Copilot Harness 通过 Microsoft Foundry 向所有开发者开放。前者是产品升级，后者是范式输出——微软决定把自家 agent 的"骨架"交给生态。
Harness 是什么：Agent 的底盘工程
大模型只能"想"，Harness 负责"做"。一个生产级编码智能体背后是一整套工程设施：
- 执行环境管理：沙箱、依赖安装、运行超时与资源隔离；
- 工具调用编排：文件读写、终端命令、测试执行的统一接口与重试策略；
- 上下文供给：代码库索引、相关文件检索、对话历史的裁剪与压缩；
- 安全边界：危险命令拦截、敏感文件访问控制、网络出口管控。
这些工作没有技术光环，却决定了 agent 是"玩具"还是"生产力"。GitHub 在 Copilot 上踩过的坑，现在打包成了可复用的 Harness。
多模型开放：微软的真实意图
值得注意的细节是：Copilot Harness 是模型无关的。通过 Foundry 开放后，开发者可以把 Claude、GPT 系列、Gemini 等任意模型接到这套骨架上运行。这看起来有点"资敌"，但微软的算盘很清楚：
- 锁定工作负载：模型可以换，但编排逻辑、评测体系、运维监控都长在 Azure/Foundry 上，迁移成本远高于换模型；
- 加速生态：与其让开发者各自重复造轮子，不如统一到底层设施上，做大 Azure 的 agent 付费盘；
- 对冲模型竞争：当模型层卷到没有差异化时，谁掌握工程层谁掌握定价权。
这与 GitHub Copilot 的演进路径一脉相承：从补全工具到智能体平台，再到现在的"基础设施输出"。
对开发者的实际价值
- 省掉 3-6 个月的 agent 工程建设：执行沙箱、工具编排、安全管控这些脏活直接用现成的；
- 模型可插拔：同一条流水线上做模型 A/B 测试，切换只需改配置；
- 与现有 DevOps 融合：GitHub 生态（Actions、Issues、PR 流程）天然打通。
需要提醒的是，Harness 解决的是工程问题，不解决模型能力问题。任务规划的质量、代码的正确率仍取决于你选的模型。选型时可以参考 GPT-6.1 Terra 与 Astra 的对比，不同任务档位配不同模型才是省钱之道。
优点与不足
优点：大厂验证过的 agent 工程实践；多模型自由接入；与 GitHub/Azure 生态深度整合；降低智能体开发的工程门槛。
不足：深度绑定微软生态，多云团队要考虑锁定风险；免费额度与计费模式尚待明确；对超大规模定制场景，灵活性仍不如自建。
适合谁与总结
适合想快速落地编码智能体的团队、需要多模型对比的企业、以及 GitHub 重度用户。
总结：Copilot Harness 开放标志着 agent 竞争从"模型层"下沉到"工程层"。当造 agent 的底盘变成公共设施，竞争焦点会回到两件事：模型质量与应用场景。对开发者是好事——轮子有人造了，你只需要想清楚造什么车。