CodeBuddy 多模型安全接入

要解决的问题

CodeBuddy 原生只内置官方模型列表，但很多用户手里已经有 ChatGPT（Codex）或 Gemini（Antigravity）订阅。直接手写 ~/.codebuddy/models.json 有两个坑：一是不知道订阅里真正可用的模型 ID，靠猜出来的名称写进去，调用时才报错；二是本机代理、OAuth 凭据和配置之间的耦合很容易把 CodeBuddy 拖进死循环——最典型的就是它缓存了过期的系统代理，之后所有请求都走不通，而反复改 JSON 只会让情况更糟。

核心能力

这个技能把「接入外部模型」拆成一条可审计的流水线：

• 审计优先，不急着写配置：先检查 CLIProxyAPI 是否存在、是否只监听 127.0.0.1、models.json 当前有多少条目、以及是否出现 codebuddy_stale_system_proxy。一旦发现过期代理，立刻停止写操作，让用户完全退出并重启 CodeBuddy。
• 本地桥接：以 Homebrew（macOS）或官方 Release + SHA-256 校验（Windows）安装 CLIProxyAPI，绑定回环地址，禁用远程管理和控制台，生成独立的随机 client key，并在改动前做时间戳备份。
• 分提供者授权：GPT 和 Gemini 各自走 CLIProxyAPI 原生 OAuth 流程，不从 Codex CLI、Gemini CLI 或浏览器复制 token，也不把 Provider 凭据写进 CodeBuddy。
• 探测后同步：从实时 /v1/models 读取账户实际可用模型，分别探测文本、SSE 流式、工具调用、图像输入和推理控制；失败的可选能力降级为 false，文本或流式失败的模型直接跳过。同步采用原子合并，保留手动条目，拒绝覆盖非 Skill 管理的同名 ID。
• 验证无回归：确认桥接仍只监听回环、内置模型回复正常、至少各有一个 GPT 与 Gemini 模型完成真实调用。

适用边界

• macOS 优先，Windows 需自行校验 Release ZIP 的 SHA-256，校验失败必须停止。
• --skip-probes 只用于离线测试，真实安装中不得使用。
• 图像理解探测通过不能当作图像生成能力。
• 输出日志中不得出现 API key、OAuth token、一次性授权码、账号邮箱或 Authorization 头。
• 修复时先区分桥接服务、client key、Provider OAuth、路由、缓存与系统代理六类原因，不要反复覆写同一份 JSON。
• Provider OAuth 续期不需要轮换 CodeBuddy 使用的本地代理 key，两者生命周期不同。