Microsoft 于 2026 年 8 月 4 日宣布，GitHub Copilot Agent 已经在 Microsoft Agent Framework 的 .NET 和 Python provider 中进入 stable。重点不是再推出一个聊天模型，而是把一个已经能够读写代码、执行 shell 和使用 MCP 的 coding harness，接入一个更通用的 agent 开发框架。
这个集成把两层能力分开。GitHub Copilot CLI 和 SDK 负责 agent loop，包括模型调用、工具执行、规划和 session state；Agent Framework 则提供统一的 instructions、tools、streaming、middleware、observability 以及 human-in-the-loop approval 接口。开发者因此可以保留 Copilot 的 repository-aware 能力，同时用熟悉的 Agent Framework 方式把它放进更大的系统。
实际可用的能力包括 shell execution、文件读写、URL fetching 和 MCP server。Microsoft 强调，这些系统能力不是默认无限开放，而是要经过 permission handler。每次敏感操作都可以由应用程序决定 approve、deny 或要求人工确认；需要审批的 function tool 也可以沿用同一套控制。
Observability 是另一个重要层次。Copilot Agent 可以参与 Agent Framework 的 OpenTelemetry tracing，让模型调用、工具使用和代理流程更容易接入现有监控系统。对 production agent 来说，知道代理完成了什么还不够，还要能够追踪它在什么时间、使用什么工具、因为什么作出某个动作，以及在哪一步被人拒绝。
不过，stable 不代表零配置部署。官方说明要求使用者拥有已验证的 GitHub Copilot runtime 和有效订阅，实际运行也要处理 CLI 路径、工作目录、模型和 timeout 等配置。如果代理获得 shell 或文件权限，Microsoft 的文档也建议在 container 或 Dev Container 中运行，以缩小代码和系统数据的暴露范围。
这次更新的讯号，是 coding agent 的竞争正由单一产品功能转向可组合的 runtime。企业未必想把所有自动化都绑定在一个聊天界面；它们可能需要把 repository agent、内部工具、审批服务、遥测和既有流程接在一起。把 Copilot harness 变成 Agent Framework 的一个 provider，正好提供了这种接驳点，但权限边界、审批策略和执行隔离仍要由部署团队自行设计。
