Microsoft 通过 Foundry 提供 Copilot 执行框架

2026 年 10 月 28 日，Microsoft 通过 Microsoft Foundry 向开发者和企业客户开放了 Microsoft Copilot 执行框架。该框架是多模型编排层，已为 Copilot Code、Copilot Studio、GitHub Copilot 应用、Copilot CLI 和 VS Code 提供支持。Microsoft 官方博客上的公告对此进行了介绍。

Microsoft 将执行框架描述为模型周围的一切：它是编排层，为代理提供完成工作所需的恰当指令、上下文、执行环境和控制机制，并支持 Model Context Protocol 等开放标准，以及代理技能和代理插件。GitHub 工程团队构建了 Copilot 执行框架，Microsoft 已在全公司采用该框架。同日发布的Microsoft Foundry 博客配套文章介绍了在 Foundry Agent Service 中推出该框架的公开预览版，并宣布面向托管代理的长时运行弹性恢复功能正式推出。

Microsoft 表示，该执行框架旨在适配不同模型系列，支持 20 多种前沿模型以及自带密钥，并会根据任务将工作分配给合适的一个或多个模型。该公司称，框架负责运行代理循环和沙盒，并内置治理与优化功能；客户则提供指令、技能、工具并选择模型。Copilot SDK 已开放下载，该执行框架也可以在 Foundry 托管的云端运行；Microsoft 表示，其平台仍对其他执行框架和框架保持开放。

Foundry Agent Service 中的托管式执行

根据 Foundry 博客文章，公开预览版由四个构建模块组成。可复用技能将指令、脚本和辅助资源打包成流程，供代理在不同任务中应用。互联工具涵盖受支持的 Foundry 工具和 Model Context Protocol 工具，并可明确配置身份验证和审批。执行与委派功能让代理能够处理文件和代码，并将范围明确的任务交给内置子代理，同时由主代理协调结果。受源代码控制的代理定义可以与应用程序代码一同管理。随着任务推进，执行框架会管理工作上下文，并在配置的限制和策略边界内协调模型与工具的各个步骤；客户还可以选择受支持的 Foundry 模型，而无需重写围绕该模型构建的编排。

开发者可以通过预览版 Azure Developer CLI (azd) 界面、Foundry 门户、适用于 Visual Studio Code 的 Foundry Toolkit，或 GitHub Copilot 应用中的 Microsoft Foundry 插件和技能来创建代理。文章还收录了两家公司的表述。Confluence Technologies 首席技术官 Chris Evans 表示，其团队不到一周就运行起了解决方案，因此能够专注于设计和功能，而不是底层基础设施。Fashable 首席执行官 Orlando Ribas Fernandes 表示，该执行框架为公司提供了基础，使其能够将复杂的寻源流程转化为受治理、可衡量的代理工作流，同时让具有商业约束力的决策继续由人工掌控。

预览版限制与 12 月计费

在预览期间，客户创建代理时可以选择 Microsoft Copilot 执行框架。现有代理不会发生变化，创建代理后目前还不支持切换执行框架；Foundry 负责管理执行环境的 CPU、内存和空闲设置。

Foundry Agent Service 中 Copilot 执行框架的计费将于 2026 年 12 月 1 日开始，按用量计费。在此日期之前，执行框架的运行时用量免费；模型推理以及单独计费的工具和互联服务仍按各自适用的费用收费。自 12 月 1 日起，沙盒计算按每 vCPU 小时 0.0994 美元计费，内存按每 GiB 小时 0.0118 美元计费，价格因地区和协议而异。

文章还介绍了在 Foundry Agent Service 中的三种方案：如果任务只需指令和受支持的工具，可使用不带执行框架的提示词代理；若要借助技能、文件和子代理实现托管式执行，可使用搭载 Copilot 执行框架的提示词代理；如果团队需要使用自己的框架、代理循环、中间件、依赖项或运行时行为，同时保留由 Foundry 托管的主机服务，则可使用托管代理。

为托管代理提供长时运行弹性恢复能力

面向托管代理的长时运行弹性恢复功能现已正式推出，适用于需要数小时或数天才能完成的工作。Foundry 会检测中断，并使用原始输入重新启动工作；客户代码则保存进度和中间结果，以便代理从中断处继续执行。当代理更新其他系统时，工作流还必须确保重启后不会重复执行操作。Microsoft 指出，仅凭对话历史不足以恢复正在进行的工作。

由 GitHub 打造

Microsoft 表示，该执行框架由参与其多模型编排工作的同一批 GitHub 工程师构建，并称公司正以此为基础统一 Copilot 体验。2026 年 9 月 4 日，GitHub 推出了 Project HydraFusion 研究预览版。它可通过三种模式，针对来自多个提供方的模型制定执行计划：单模型模式，即由一个模型直接完成任务；级联模式，即先由高效模型起草解决方案，再由质量关卡决定是否升级至更强的模型；批判审查模式，即由来自不同模型系列、独立且只读的评审模型审查草稿，再由起草模型进行修改。GitHub 报告称，在离线评估中，与 Claude Opus 5 在 TerminalBench 2.1 上的表现相比，HydraFusion 的已验证任务质量提高了 4.9 个百分点，预估成本降低了 67%；在 DeepSWE 上，表现相差不超过 1.5 个百分点，成本降低了 36%；在其内部的 CheckpointBench 上，表现相差不超过 0.1 个百分点，成本降低了 65%。

GitHub 还于 2026 年 9 月 16 日披露，已将 Copilot 智能体运行时从 TypeScript 移植到 Rust，截至 2026 年 8 月 21 日，生产环境中的 Rust 代码已达 832,378 行，分 128 个逐步发布的拉取请求完成移植；Copilot SDK 则通过六种语言前端开放该运行时。Microsoft 将行业领先的性能，以及会话开销和首个 token 生成时间的缩短归功于此次移植。在 Microsoft 卓越工程师 Stephen Toub 通过 C# SDK 进行的基准测试中，创建客户端和会话并完成一个轮次所需的时间，从移植前的 5.25 秒降至 Rust 运行时在进程内加载时的 292 毫秒；而在一个包含十个客户端的批次中，新增内存峰值则从 1,383 MB 降至 126 MB。