Microsoft Copilot Harness in Foundry 详解（2026）

更换模型本不该迫使团队重写整套编排逻辑，但现实中，这类返工往往足以拖慢 Agent 项目进度。Microsoft Foundry 中的 Microsoft Copilot harness，就是微软给出的托管式解决方案：它复用了 Copilot Code、Copilot Studio、GitHub Copilot 应用、CLI 和 Visual Studio Code 背后的执行层，如今已在 Foundry 进入公开预览，运行时费用在 2026 年 12 月 1 日前免费（blogs.microsoft.com）。现在可以用它做实验，但在下文提到的预览限制解决前，生产环境仍建议沿用当前技术栈。

Microsoft Copilot harness 到底解决什么问题

Microsoft Copilot harness 是围绕模型构建的托管式编排层，负责把模型的推理转化为实际完成的任务。微软提供 Agent 循环、沙箱、治理和优化能力，开发者则负责提供指令、技能、工具以及模型选择。

微软的说法很直接：“如果模型提供了智能，那么 harness 就是模型之外的一切”（blogs.microsoft.com）。具体来说，它会随着任务推进管理工作上下文，协调模型调用和工具调用，在沙箱中运行文件及代码，把范围明确的子任务交给内置子 Agent，并执行预先配置的限制和策略边界（devblogs.microsoft.com）。

多模型路由：支持 20 多个前沿模型，也支持 BYOK

Microsoft Copilot harness 支持来自多个模型系列的 20 多个前沿模型，并支持自带密钥（BYOK）配置；它会根据任务将工作路由到合适的一个或多个模型（blogs.microsoft.com）。微软在公告中没有公布完整的 20 多个模型清单，因此在规划多模型架构前，务必先确认所在 Foundry 区域的具体可用模型。微软希望用户不再需要维护自定义路由器——“指令、技能、工具和模型选择由你提供即可”。

一位早期开发者这样概括它的吸引力：每次模型变化时，不必重新编写编排层——@ai_fengshou。

Rust 运行时，以及已经由它驱动的产品

Microsoft Copilot harness 的运行时最近完成了 Rust 迁移。微软称此举降低了会话开销和首 Token 延迟（blogs.microsoft.com）。目前没有公开具体的性能提升比例或延迟数据表，因此应把这一说法理解为方向性结论。

微软表示，同一套 harness 已经为 Copilot Code、Copilot Studio、GitHub Copilot 应用、GitHub Copilot CLI、Visual Studio Code，以及其他 Microsoft 和 GitHub Copilot 产品入口提供支持（blogs.microsoft.com）。微软称，这套共享基础已经在数百万用户和数百个真实使用场景中接受测试（blogs.microsoft.com）。

该 harness 还通过 Model Context Protocol（MCP）、Agent 技能和 Agent 插件提供开放式扩展能力（blogs.microsoft.com）。

2026 年 10 月 28 日，Foundry 有哪些变化

2026 年 10 月 28 日，微软同时推进了两件相关更新：Microsoft Copilot harness 在 Foundry Agent Service 中进入公开预览；托管 Agent 的长时间运行恢复能力则正式发布（devblogs.microsoft.com）。

产品术语也在调整。Copilot Studio 文档中仍有部分页面把它称为 GitHub Copilot harness，但在新的产品术语体系中，它已经改称 Microsoft Copilot harness；不同页面的切换时间并不一致（microsoft.com）。

现在，Foundry Agent Service 提供三种抽象层级：不使用 harness 的 Prompt Agent、预览中的 Microsoft Copilot harness Prompt Agent，以及由开发者自行控制框架的 Hosted Agent（devblogs.microsoft.com）。长时间运行恢复能力属于已经正式发布的部分：Hosted Agent 即使在持续数小时或数天的工作流中遭遇中断，也可以恢复执行。

如何在 Foundry 中构建 harness Agent

Foundry harness Agent 采用声明式定义，并与应用代码一起保存（devblogs.microsoft.com）。开发者可以在 Foundry 中创建和测试 Agent，将定义文件纳入版本控制，再通过 Azure Developer CLI（azd）或 Foundry 门户部署（devblogs.microsoft.com）。

用可复用技能封装工作方法

可复用技能可以把指令、脚本、辅助资源和操作流程打包起来，让 Agent 在不同任务中重复使用。官方示例使用了位于 skills/research-brief/SKILL.md 的 research-brief 技能，要求 Agent 先确认问题、受众、范围和时间段，再通过获准工具收集证据、标注来源和日期、区分事实与解读，并指出相互冲突的证据。

连接工具，同时保留治理边界

连接工具后，Agent 可以使用 Microsoft Foundry 工具和 MCP 工具，但身份验证及审批必须显式配置。审批本身就是治理控制点；而从下文的 Reddit 用户反馈来看，当终端用户反复遇到授权弹窗时，这也会成为生产环境中的摩擦来源。

执行代码、处理文件并拆分任务

Agent 可以处理文件、执行代码，并把边界明确的任务交给内置子 Agent，再由主 Agent 汇总和协调结果。Copilot Studio 的 harness 对比文档还提到，源自 GitHub 的这套 harness 原生支持创建和编辑 Word、Excel、PowerPoint 及 PDF 文件，同时支持技能和记忆功能（learn.microsoft.com）。

定义文件纳入版本控制，只需一行启用 harness

Agent 定义可以和代码放在一起。Foundry 示例在 azure.yaml 中声明 harness（devblogs.microsoft.com）：

harness:
  type: microsoft_copilot_preview

示例将 research-brief Prompt Agent 连接到 research-brief-skill 技能，并配置网页搜索（public-research）和 Code Interpreter（research-analysis），同时使用 FOUNDRY_PROJECT_ENDPOINT 和 MODEL_DEPLOYMENT_NAME 作为环境输入（devblogs.microsoft.com）。部署和调用可以使用预览版 CLI：

azd deploy --all
azd ai agent invoke research-brief \
  "Compare publicly announced approaches to agent interoperability. Produce a concise brief with sources, tradeoffs, and open questions."

此外，还可以通过 Foundry 门户、Visual Studio Code 的 Foundry Toolkit，以及 GitHub Copilot 应用的 Foundry 插件进行开发（devblogs.microsoft.com）。

如何选择适合任务的 Foundry Agent 路径

没有一种抽象层级适合所有场景。微软自己的建议是：在满足应用需求的前提下，选择基础设施责任最少的方案（devblogs.microsoft.com）。预览期间，路径会在创建 Agent 时确定，因此最好在点击创建之前做出选择。

微软引用的早期客户反馈包括：Confluence Technologies 将精力集中在设计而非基础设施上，不到一周就交付了解决方案；Fashable 则将 harness 用于受治理的采购流程，同时把具有商业约束力的决策保留给人工处理（devblogs.microsoft.com）。

2026 年 12 月 1 日之后如何计费

Microsoft Copilot harness 运行时将从 2026 年 12 月 1 日开始按用量计费。在此之前，运行时使用免费；但模型推理、单独计费的工具和连接服务，在整个期间都需要另外付费。

价格可能因区域和客户协议而异（devblogs.microsoft.com）。预览期间，Foundry 会管理执行环境的 CPU、内存和空闲设置（devblogs.microsoft.com），并将受支持的区域、模型、工具及预览限制指向单独的文档。

在 Copilot Studio 中，使用 GitHub 系列 harness 的 Agent 会通过 Copilot Credits 按用量计费，这与 Foundry 的沙箱计量是两套独立的计费体系（learn.microsoft.com）。估算试点成本时，可以先用实际观测到的沙箱 vCPU 小时数和 GiB 小时数乘以上述费率，再加上模型 Token 和工具费用。

开始构建前，先确认这些预览限制

预览版能否顺利走向生产，往往取决于这些细节。除非特别注明为用户反馈，以下限制均来自微软的 Foundry 文章。

• 目前选定 harness 后不能回头。 创建 Agent 时就要选择 harness；已有 Agent 不会改变，创建完成后目前也不支持切换 harness。一位早期读者特别指出：“创建 Agent 时要选择 Copilot harness。已有 Agent 保持不变，创建后目前还不支持切换 harness”——@navaneethan_es。
• 区域和模型都有边界。 Foundry 将完整列表放在受支持区域、模型、工具和预览限制文档中。一位用户总结称，目前大约覆盖九个区域，不包括中东，而且还不支持完整的自带模型能力——@HeshamSaadZaki。这只是用户根据文档做出的解读，不能替代官方区域列表，实际情况仍需自行核对。
• 长时间运行任务的恢复需要由你的代码负责。 Foundry 会重启被中断的 Hosted Agent 工作，并重新提供原始输入；但应用仍必须保存进度、从检查点恢复，并防止重复操作，例如避免重复创建同一份外部报告。仅依靠对话历史无法恢复正在执行的工作。
• 发布时没有提供基准测试或 SLA 数据。 目前只能看到“行业领先性能”之类的定性说法，没有延迟、吞吐量或准确率数据表。

早期 Copilot harness 用户在生产环境遇到了什么

使用 GitHub 系列 harness 的 Copilot Studio 用户，反复提到预览版与生产环境之间的差距。以下反馈描述的是 Foundry 预览版之前的 Copilot Studio GitHub harness 使用体验；由于微软称两者拥有共同的技术血缘，本文将其作为一种参考推断（blogs.microsoft.com），而不是 Foundry 的实测结果。

这些该死的连接器在生产环境里甚至撑不过一天。——u/roberts2727，来自 r/copilotstudio

有时流程能正常工作，有时 Agent 完全不会向流程传递任何内容。——u/donstazz，来自 r/copilotstudio

业务用户没法完成这些应用注册之类的操作，必须由 IT 管理员来做，而且每个 Agent 都要单独处理。——u/Teemu_St，来自 r/copilotstudio

这些讨论中提到的问题包括：

• 基于 SharePoint 的 Agent 回复更慢；在 r/copilotstudio 中，有用户形容其速度明显慢于其他方案。
• Agent 在 Studio 测试面板中可以工作，但部署到 Teams 或 M365 Copilot 后失败，只显示通用错误；相关反馈见 r/copilotstudio。
• 连接器和流程不稳定，同时反复出现身份验证及 MCP 授权问题；相关反馈见 r/copilotstudio。
• 用户不清楚 M365 Copilot 许可证是否涵盖 harness 运行时，还是仍需支付 Copilot Credits；相关讨论见 r/microsoft_365_copilot。

这些反馈并不能否定 Foundry 预览版的价值，但足以说明试点时应该怎么测：使用真实的知识来源、真实的渠道和真实的终端用户授权流程，再决定是否对外承诺交付时间。

常见问题

Microsoft Copilot harness 和 GitHub Copilot harness 是同一个东西吗？

是的，两者属于同一条由 GitHub 打造的技术血缘，只是现在改用了 Microsoft 的新名称。过渡期间，部分 Copilot Studio 文档仍会使用旧名称。

Foundry harness 支持哪些模型？

支持 20 多个前沿模型，并支持 BYOK 和基于任务的路由。微软没有公布完整清单，因此需要根据所在区域查看 Foundry 文档（见上文的多模型部分）。

可以把现有 Foundry Agent 迁移到 harness 吗？

预览期间不支持原地切换。建议并行评估：先盘点提示词、工具、身份验证和状态需求，再在预览项目中使用 microsoft_copilot_preview 重新创建 Agent，最后对比同一任务下的质量、延迟、沙箱用量和恢复能力，再决定是否切换。

M365 Copilot 许可证是否涵盖 harness 用量？

不会自动涵盖。Foundry 会将沙箱计算和内存与模型推理分开计量，而 Copilot Studio 则通过 Copilot Credits 为这一系列 harness 计费。请根据实际使用的平台确认对应计费项。

应该使用 harness 还是 Hosted Agent？

如果你希望使用托管式循环、沙箱、技能和子 Agent，但不想自行维护编排逻辑，就选择 harness。如果必须控制框架或运行时，并且能够自行负责检查点和幂等性，则选择 Hosted Agent。

可以先在预览版中采用 research-brief 技能模式，再针对同一任务，将沙箱和 Token 成本与不使用 harness 的 Prompt Agent 进行对比。在迁移方案、可用区域和授权行为针对你的租户得到明确记录之前，生产环境仍建议沿用已经验证过的路径。