微软开放 Copilot 编排底座，迁移成隐忧

Microsoft 把支撑 GitHub Copilot 等产品的 Agent 执行框架，开放成了 Foundry 里的托管服务。开发者选好模型、配置指令和工具，就能让 Agent 读写文件、运行代码、分派任务，执行环境由 Microsoft 管理。

省下的运维工作，对应着更少的运行时控制权：框架选定后不能在原 Agent 内更换，也不能自带模型。理解这组取舍，比单看「更容易部署 Agent」更有用。

托管的到底是哪一层

这里的 harness，可以理解成 Agent 的执行框架。模型决定下一步做什么，harness 负责组织模型调用、执行工具、维护上下文，并让整个过程遵守配置好的策略。

Microsoft Copilot harness 目前通过 Foundry Agent Service 提供公开预览。它内置沙箱、可复用技能（Skills）、MCP 集成和子 Agent（subagents）。主 Agent 可以把任务交给子 Agent，再协调返回结果；技能则把指令、脚本和辅助资源打包，方便重复使用。

MCP 集成也有权限边界，需要认证和批准。接上工具不等于获得无条件调用权。

按原文描述，同一套 harness 已支撑 Copilot Code、Copilot Studio、GitHub Copilot、CLI 和 VS Code。这延续了 Microsoft 在 Build 2026 提出的 Foundry 策略：让企业更容易运行、管理和控制 Agent。

不过，共用基础设施不代表这些产品的能力、配置和权限完全一致，原文没有给出这样的承诺。

部署变简单，因为执行环境有人接管

Microsoft 的技术演示使用了一个研究 Agent。开发者通过 Markdown 技能描述收集证据、分析数据、撰写报告的步骤，再用 azure.yaml 定义模型部署、工具、指令和 harness。

部署时，将 harness 类型设为 microsoft_copilot_preview，运行 azd deploy --all，随后通过 Azure Developer CLI 调用 Agent。

这里值得借鉴的是配置管理方式。Agent 的行为不必只存在于聊天窗口或控制台里：指令、技能和辅助文件都能进入源码仓库，跟应用代码一起追踪变更。团队排查结果变化时，至少能先确认配置改过什么。

Microsoft 接管了 Agent 的运行和执行环境，但原文没有给出部署耗时、成功率或维护成本的对照数据。「更容易」有明确的功能依据，节省多少工作则尚未量化。

想换框架时，边界就露出来了

最硬的限制发生在创建阶段：创建 prompt agent 时必须选定 Copilot harness，之后不能更换，即使创建新版本也不行。

harness 是创建时的固定选择，版本升级不能解除这个约束。

这不等于整个应用永远无法迁移，但也不能把迁移理解为修改一个配置字段。原文没有说明跨 harness 迁移工具、状态迁移方式或具体迁移成本。

运行资源同样由平台决定。Microsoft 控制 Agent 获得多少 CPU、内存，以及允许空闲多久。开发者决定任务和工具，却不能自由调整这些环境参数。

模型选择也有范围。团队可以选择部署在 Foundry 上的兼容模型，但托管 Copilot harness 不支持自带模型。「支持多模型」因此不能直接理解为「任意模型都能接」。

需要更多控制权时，原文给出的替代方案是 Foundry hosted agents：团队使用自己的框架构建和运行 Agent，自定义运行方式，Microsoft 负责托管。Microsoft 还宣布，hosted agents 的长任务恢复能力正式可用，用于帮助持续数小时甚至数天的任务从中断中恢复。不要把这项能力直接算到 Copilot harness 名下。

成本也得分开看。Copilot harness 在 Foundry Agent Service 中免费至 2026 年 12 月 1 日，但模型推理、部分工具和连接服务仍单独收费。此后计算资源为 $0.0994/vCPU-hour，内存为 $0.0118/GiB-hour；实际费率可能随地区和客户协议变化。

我的判断

这套方案解决的是执行基础设施的交付问题。对于已经使用 Azure、接受 Foundry 模型范围、又不想自行维护 Agent 环境的团队，它的吸引力很直接。

但限制里有两个需要提前判断的部分。CPU、内存和空闲时长关系到任务能否稳定完成；harness 不可更换，则关系到后续架构调整是否方便。它们都应在创建 Agent 前评估。

与 hosted agents 相比，托管 Copilot harness 提供更多现成执行能力，也收走了部分控制权。哪种更划算，取决于团队究竟缺的是运行基础设施，还是需要定制执行逻辑。

原文更接近产品能力与边界说明，没有提供真实团队迁移案例，也没有与自建框架的成本、可靠性对照。因此，可以认可它减少了需要自行搭建的环节，但不能据此断言它更便宜、更稳定。

能拿来做什么

• 如果准备部署研究或报告类 Agent，可以参考原文，把工作步骤写进 Markdown 技能，将 azure.yaml 和辅助文件一起纳入版本控制，让行为配置变得可追踪。
• 创建 prompt agent 前，先确认模型兼容范围，以及 CPU、内存和空闲限制是否满足任务需求。需要自带模型或定制框架的项目，应先评估 hosted agents。
• 试运行时分别记录模型、工具、连接服务和运行资源费用。免费期只覆盖原文所述的 harness 服务，不能用它代表完整使用成本。
• 为后续更换方案预留空间：明确哪些逻辑写在技能和脚本里，哪些依赖平台行为，并实际验证重建 Agent 的流程，避免把「能升版本」当成「能换框架」。