使用 C# 将自有模型接入 GitHub Copilot SDK

截至 2026 年 10 月 19 日，GitHub Copilot SDK 官方资料显示，开发者现在可以通过 ProviderConfig 将模型推理路由到自行选择的提供方。官方列出的方向包括 OpenAI、Anthropic、Ollama、Microsoft Foundry Local，以及 vLLM、LiteLLM 等 OpenAI 兼容端点。这项变化并不是移除 Copilot，而是保留其运行时，只改变模型请求的去向。

具体变化在哪里

官方 .NET 示例被实现为一个 .NET 10 控制台应用：读取模型部署名、资源端点和可选 API Key，创建 BYOK provider，启动 Copilot runtime，建立会话并发送一个问题。示例默认连接 Microsoft Foundry，并采用兼容 OpenAI Responses API 的调用方式。

var provider = new ProviderConfig
{
    Type = "openai",
    BaseUrl = normalizedEndpoint,
    WireApi = "responses",
    ModelId = deploymentName,
    WireModel = deploymentName
};

ProviderConfig 负责规定推理接口、模型标识和令牌上限，会话仍由 Copilot SDK 管理。应用通过 RuntimeConnection.ForStdio("copilot") 启动本地 Copilot CLI runtime，因此 BYOK 并不等于“不用 Copilot”。这里的 BYOK 指“自带模型提供方”，不是客户托管的加密密钥。

身份验证与配置方式

• 默认使用 Microsoft Entra ID。示例以 AzureCliCredential 复用 az login 建立的登录身份；该身份需在目标资源上拥有 Cognitive Services OpenAI User 角色。
• 配置 AzureOpenAI:ApiKey 后，示例改为通过 api-key 请求头发送凭据，这条路径不要求安装 Azure CLI。
• 端点和部署名分别由 AzureOpenAI:Endpoint、AzureOpenAI:Deployment 提供。本地秘密可放入 User Secrets，部署环境则应使用环境管理的配置，不应把凭据提交到源码仓库。

适用场景

这一能力适合需要统一接入自有 Foundry 部署、OpenAI 兼容服务或本地 Ollama 的应用。开发者可以继续使用 Copilot SDK 提供的客户端、会话、系统消息和代理编排，再把推理负载交给可控的模型提供方。对于初次集成的团队，最小示例会关闭工具、技能、配置发现和宿主 Git 操作，先验证一条模型请求；基线稳定后，再逐项开放工具、MCP、技能、审批和流式响应。

限制与注意事项

• 运行环境需要 .NET 10 SDK 和 GitHub Copilot CLI；默认的 Entra ID 认证路径还需要 Azure CLI。
• 目标模型部署必须支持示例采用的 Responses API，示例中的端点规范化函数也只接受有效的 HTTPS 地址。
• 示例将 MaxOutputTokens 设为 512。对于推理模型，推理 token 同样计入输出上限，可能在可见答案生成前耗尽额度，应按实际工作负载调高或移除该覆盖值。
• 最小会话刻意禁用工具、技能、配置发现和 Git 操作，因此它只能证明模型路由已经可用，不能据此认定这些扩展能力也已完成验证。

整体接入思路可以概括为两件事：Copilot SDK 负责运行时，ProviderConfig 负责模型提供方。先跑通单轮问答，再逐步扩展代理能力，是这份官方示例最清晰的实践路径。

资料来源：Bring Your Own Model to the GitHub Copilot SDK with C#（2026-10-19）。