把 GitHub Copilot 接入模型路由工具的适配层

使用 GitHub Copilot 的开发者在搭建或使用编码智能体（coding agent）时，希望像调度其他模型一样把 Copilot 作为一个 model provider 纳入模型路由体系，而不是被锁死在 VS Code 的 Copilot 界面内。有用户在 Show HN 中直接询问某个开源模型路由工具："Do you have plan to support gh copilot as model provider?"。与此同时，GitHub 自身的 HydraFusion（研究预览）开始自动为编码任务选择模型和工作流，说明"多模型路由用于编码"是真实且被官方注意到的需求，但官方方案目前限于 VS Code 内、且处于 research preview 阶段。

已在付费使用 GitHub Copilot、同时使用开源模型路由工具或自建编码智能体的开发者。这是一个细分人群：重度 AI 编码工作流用户，单个用户价值高但总量有限，偏向开发者社区（Hacker News、GitHub）中的早期采用者。

• 本地代理服务，把 GitHub Copilot 封装成 OpenAI 兼容的 API 端点，供任意模型路由工具调用
• Provider 注册向导：输入 Copilot 凭据后自动生成路由工具可识别的 provider 配置
• 模型透传与切换：把请求路由到 Copilot 可用的具体模型，并在路由工具侧保持统一的模型命名
• 使用量与失败重试的本地日志，方便调试 agent 工作流 AI 的角色：本产品本身是模型编排/适配层，不生成内容，而是让编码智能体把 Copilot 当作可调度的模型之一（类似信号 1 中 HydraFusion 的 "choose models and workflows for your coding tasks automatically" 能力，但开放给第三方路由工具）

GitHub 刚在 VS Code Copilot 中推出 HydraFusion 研究预览，允许智能体自动选择模型和工作流，说明"编码任务的多模型路由"刚刚成为官方认可的能力方向；同时社区用户已开始要求开源路由工具支持 gh copilot 作为 provider，需求出现在官方能力尚未正式开放的窗口期。

第一版只做一件事：本地运行的代理服务，把 GitHub Copilot 的模型能力封装成 OpenAI 兼容的 chat/completions 接口，让主流模型路由工具和编码智能体能把 Copilot 添加为 provider，支持在多个模型间手动切换。明确不做：自动模型选择策略（留给路由工具本身）、训练或微调模型、多人协作和企业账号管理。

• 平台依赖是最大风险：对接 Copilot 需要使用非官方/未文档化接口，GitHub 随时可能封锁或改动，也可能直接在 Copilot 中官方开放 provider 能力使该工具失效。
• 官方竞争：HydraFusion 已是研究预览，若正式发布并开放，需求窗口可能关闭。
• 合规风险：转售或代理 Copilot 的模型额度可能违反 GitHub 服务条款，需法务评估。
• 付费意愿不明：信号全部来自免费工具生态，商业化路径缺乏证据。