CodeBuddy 接入自定义模型 (GPT-5.6)

2026-07-18 09:33

本文发自 http://www.binss.me/blog/connect-codebuddy-to-custom-model/，转载请注明出处。

AI 协作说明

本文以及文中绝大部分实际配置流程，基本由 gpt-5.6-sol 协助完成。从复用 SSH 登录 VPS、安装 Mihomo 和 CLIProxyAPI、完成 Codex 授权、配置 Caddy 与 Cloudflare，到接入 CodeBuddy、验证工具调用和 Prompt Cache，再到整理本文，整个过程都由 AI Agent 持续执行、检查并根据真实返回结果迭代。

这篇文章也可以直接整理成一份可复用的 SKILL.md，交给支持 Skills 和终端工具的 AI Agent，自动完成环境检查、软件安装、配置生成、systemd 服务、HTTPS 反代与验收测试。实际使用时，应把机场订阅、API Key 和域名作为私密输入，并要求 Agent 在 OAuth 网页授权、DNS 修改、安全组调整和其他影响外部状态的步骤等待人工确认。

最近我完成了一套 CodeBuddy 自定义模型接入方案：在国内 VPS 上运行 CLIProxyAPI，通过 Mihomo 访问 OpenAI 上游，再用 Caddy 和 Cloudflare 对外提供安全的 OpenAI 兼容 API。

为什么要折腾这套方案

我一直很喜欢 CodeBuddy IDE 的交互体验，尤其是它能够把模型生成的修改按行展示，让我逐行 Accept 或拒绝。对于真实项目开发，这比一次性覆盖整段代码更可控，也更接近正常的代码审查流程。目前在我使用过的工具里，CodeBuddy 和 Cursor 对这套交互支持得最丝滑。

问题是，CodeBuddy 自带额度对我的使用强度来说不太够，额外 Token 的成本也比较高。另一方面，我已经有 Codex 订阅，每月约 100 美元的档位在我的日常开发中很难真正用完。与其让大量额度闲置，我自然想到：能不能把已有的 Codex 订阅转换成 OpenAI 兼容 API，再通过 CodeBuddy 的“自定义模型”功能接进去？

为什么选择 Codex

对我而言，主要有三个原因：

额度充足：在高频编码场景下依然显得“便宜大碗”，我自己的套餐长期用不满；
能力适合编程：工具调用、长上下文和代码修改能力都符合 Agent IDE 的需求；
生态相对开放：CLIProxyAPI 等开源项目已经提供成熟的 Codex 授权和兼容接口方案，相关社区对代理接入的讨论也比较开放。

我自己的使用体验一直比较稳定，但这不代表任何形式的“永不封号”保证。订阅政策、模型权限和服务条款都可能变化，实际使用仍应遵守 OpenAI、CodeBuddy 以及相关服务的条款，不要出售、共享或滥用个人订阅凭据。

为什么选择 CodeBuddy，而不是 Cursor

Cursor 的按行修改体验同样优秀，但在我当前测试的版本和自定义模型工作流中，请求仍会受到 Cursor 服务端支持范围、协议转换和模型兼容策略的限制。

CodeBuddy 的自定义模型调用则可以直接从运行 CodeBuddy 的环境发出。对我来说，这意味着请求链路更透明：我可以看到实际请求经过哪个网关、使用哪个模型，也能从 CLIProxyAPI 返回的 usage 元数据中验证 Token 和 Prompt Cache，而不是完全依赖客户端界面的统计结果。

为什么还要部署到 VPS

如果只在本机使用 CodeBuddy，把 CLIProxyAPI 监听在 127.0.0.1 就足够了。但我经常使用 CodeBuddy Remote 连接远端开发机；这时模型请求是从远端机器发起的，远端的 127.0.0.1 并不是我的本地电脑。

因此，仅在本机启动反代会遇到一个直接问题：Remote 环境根本访问不到本机代理。虽然也可以使用 SSH 反向隧道或虚拟组网解决，但它们依赖连接持续在线，不太适合多台远端机器长期复用。

把 CLIProxyAPI 部署在 VPS 上并提供一个经过鉴权的 HTTPS 地址后，本机 CodeBuddy、CodeBuddy Remote 和其他受信任设备都可以使用同一入口。接下来真正需要解决的，就是国内 VPS 的上游网络、API 鉴权、HTTPS、源站保护和敏感日志控制。

最终效果如下：

CodeBuddy 可以使用自定义 OpenAI 兼容模型；
VPS 上的 CLIProxyAPI 只监听本机地址，不直接暴露端口；
所有上游请求都通过 Mihomo 代理；
公网入口使用 Cloudflare、Caddy 和自动 HTTPS；
API 请求必须携带独立密钥；
管理接口在公网层直接返回 404；
Prompt Cache 已实测命中，最高单次命中率超过 98%。

为避免泄露真实环境，本文统一使用 example.com、YOUR_API_KEY 和 YOUR_SUBSCRIPTION_URL 等占位符。机场订阅链接包含访问凭据，绝对不要提交到 Git 仓库或发布到博客中。

一、整体架构

flowchart LR
    A["CodeBuddy"] -->|"HTTPS + API Key"| B["Cloudflare"]
    B -->|"Full strict TLS"| C["Caddy :443"]
    C -->|"127.0.0.1:8317"| D["CLIProxyAPI"]
    D -->|"HTTP Proxy 127.0.0.1:7893"| E["Mihomo"]
    E -->|"机场节点"| F["OpenAI"]

各组件的职责很明确：

Mihomo：解决国内 VPS 访问 OpenAI 的网络问题；
CLIProxyAPI：把 Codex/OpenAI 授权转换为 OpenAI 兼容接口；
Caddy：反向代理、自动签发证书、隐藏管理接口；
Cloudflare：代理 DNS、保护源站并提供边缘 TLS；
CodeBuddy：通过 /v1/chat/completions 使用自定义模型。

二、准备工作

需要准备：

一台能够 SSH 登录的 VPS；
一个机场 Clash/Mihomo 订阅链接；
一个托管在 Cloudflare 的域名；
可以完成 Codex/OpenAI 网页授权的浏览器；
VPS 安全组放行 TCP 80 和 443。

SSH 的 22 端口最好只允许自己的固定 IP。不要在安全组中开放 7893、8317 或 9090。

本文实测环境使用 linux/amd64。如果是新服务器，建议选择仍在安全维护期内的 Debian、Ubuntu、Rocky Linux 或 AlmaLinux，不建议新部署继续使用已经 EOL 的 CentOS 7。

三、安装并配置 Mihomo

从 Mihomo Releases 下载与服务器架构匹配的二进制，然后安装：

sudo install -m 0755 mihomo /usr/local/bin/mihomo
sudo mkdir -p /etc/mihomo /var/lib/mihomo

下载订阅配置：

export SUB_URL='YOUR_SUBSCRIPTION_URL'
sudo curl -fL "$SUB_URL" -o /etc/mihomo/config.yaml
unset SUB_URL
sudo chmod 600 /etc/mihomo/config.yaml

确认配置中至少包含以下本地监听设置。节点、代理组和规则继续使用订阅提供的内容：

mixed-port: 7893
allow-lan: false
bind-address: 127.0.0.1
external-controller: 127.0.0.1:9090
mode: rule

创建 systemd 服务：

# /etc/systemd/system/mihomo.service
[Unit]
Description=Mihomo Proxy
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

启动并设置开机自启：

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
sudo systemctl status mihomo

验证代理能否访问 Google：

curl -x http://127.0.0.1:7893 -I https://www.google.com

能够返回正常 HTTP 响应，说明代理链路已经打通。

四、安装 CLIProxyAPI

从 CLIProxyAPI Releases 下载对应架构的压缩包，校验发布方提供的哈希后安装：

sudo install -m 0755 cli-proxy-api /usr/local/bin/cli-proxy-api
sudo useradd --system --home-dir /var/lib/cliproxyapi --shell /sbin/nologin cliproxyapi || true
sudo mkdir -p /etc/cliproxyapi /var/lib/cliproxyapi/auth
sudo chown -R cliproxyapi:cliproxyapi /var/lib/cliproxyapi

生成一个足够长的 API Key：

openssl rand -hex 32

创建 /etc/cliproxyapi/config.yaml：

host: 127.0.0.1
port: 8317

auth-dir: /var/lib/cliproxyapi/auth

api-keys:
  - "YOUR_API_KEY"

# CLIProxyAPI 访问 OpenAI 时走 Mihomo
proxy-url: "http://127.0.0.1:7893"

# 管理接口不对外开放
remote-management:
  allow-remote: false
  secret-key: ""
  disable-control-panel: true
  disable-auto-update-panel: true

debug: false
request-log: false
logging-to-file: false

配置文件中包含 API Key，应限制读取权限：

sudo chown root:cliproxyapi /etc/cliproxyapi/config.yaml
sudo chmod 640 /etc/cliproxyapi/config.yaml

创建服务：

# /etc/systemd/system/cliproxyapi.service
[Unit]
Description=CLIProxyAPI
After=network-online.target mihomo.service
Requires=mihomo.service

[Service]
Type=simple
User=cliproxyapi
Group=cliproxyapi
WorkingDirectory=/var/lib/cliproxyapi
ExecStart=/usr/local/bin/cli-proxy-api -config /etc/cliproxyapi/config.yaml -local-model
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target


[bash]
sudo systemctl daemon-reload
sudo systemctl enable --now cliproxyapi

确认 CLIProxyAPI 仅监听本机：

ss -lntp | grep 8317

预期结果应类似：

127.0.0.1:8317

五、完成 Codex/OpenAI 授权

停止后台服务后，以 CLIProxyAPI 服务用户执行登录流程：

sudo systemctl stop cliproxyapi
sudo -u cliproxyapi -H /usr/local/bin/cli-proxy-api \
  -config /etc/cliproxyapi/config.yaml \
  --codex-login --no-browser

CLI 会输出授权地址或设备码。在自己的电脑浏览器中完成登录，看到授权成功后重新启动服务：

sudo systemctl start cliproxyapi

验证模型列表：

curl http://127.0.0.1:8317/v1/models \
  -H 'Authorization: Bearer YOUR_API_KEY'

模型列表会随账号权限和 CLIProxyAPI 版本变化，不要在客户端中凭空填写模型 ID，应以 /v1/models 的实际返回值为准。

六、用 Caddy 提供 HTTPS 反向代理

先在 Cloudflare 中添加 DNS A 记录：

example.com -> VPS 公网 IP

第一次签发证书时可以暂时使用“仅 DNS（灰云）”。安装 Caddy 后创建 /etc/caddy/Caddyfile：

{
    admin 127.0.0.1:2019
}

example.com {
    # 即使以后误开 CLIProxyAPI 管理功能，公网也无法访问
    @management path /v0/management* /management*
    respond @management 404

    reverse_proxy 127.0.0.1:8317

    log {
        output stderr
        format json
    }
}

校验并启动：

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl enable --now caddy

Caddy 会自动完成 HTTP-01 验证、签发证书并设置 HTTP 到 HTTPS 跳转。可以在日志中确认：

journalctl -u caddy -f

证书签发成功后，将 Cloudflare DNS 记录切换为“已代理（橙云）”，并设置：

SSL/TLS -> Overview -> Full (strict)

不要使用 Flexible。源站已经拥有有效的 Let's Encrypt 证书，使用 Full (strict) 才能验证源站证书。

七、验证公网 API

检查 HTTP 跳转：

curl -I http://example.com/v1/models

未携带密钥时应返回 401：

curl -i https://example.com/v1/models

携带密钥时应返回 200：

curl https://example.com/v1/models \
  -H 'Authorization: Bearer YOUR_API_KEY'

管理接口应返回 404：

curl -o /dev/null -w '%{http_code}\n' \
  https://example.com/v0/management/config

还可以执行一次最小对话测试：

curl https://example.com/v1/chat/completions \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  --data '{
    "model": "gpt-5.6-sol",
    "messages": [{"role": "user", "content": "Reply only OK."}],
    "max_tokens": 16
  }'

八、在 CodeBuddy 中添加自定义模型

打开 CodeBuddy 的模型设置，选择 Custom，填写：

供应商：Custom
Base URL：https://example.com/v1/chat/completions
API Key：CLIProxyAPI 中生成的 API Key
模型名称：gpt-5.6-sol
工具调用：开启
推理：开启
图片输入：暂不开启
输入及输出限制：留空，使用默认值

这里有一个容易踩坑的地方：CodeBuddy 的 Base URL 输入框需要完整的 chat/completions 地址，而不只是 https://example.com/v1。

如果明明填写了 gpt-5.6-sol，服务端日志却显示请求使用了其他模型，应检查：

CodeBuddy 是否启用了 Auto 模式；
当前对话是否仍选中了旧模型；
子代理是否自动选择了 lite 或 reasoning 场景模型；
模型配置修改后是否真正保存。

九、验证 Prompt Cache

OpenAI Prompt Caching 对满足条件的请求自动生效，一般不需要在 VPS 上增加“缓存服务器”。要获得缓存命中，需要满足两个关键条件：

可缓存前缀至少达到 1,024 Token；
多次请求的前缀必须完全一致。

因此应把稳定的系统提示、工具定义和示例放在前面，把经常变化的用户问题放在后面。详情可参考 OpenAI Prompt Caching。

Chat Completions 的命中数位于：

usage.prompt_tokens_details.cached_tokens

实际测试中，CodeBuddy 界面一度显示缓存命中率为 0，但 CLIProxyAPI 记录的上游 Token 元数据证明请求可以正常走 Prompt Cache。

最新三次 CodeBuddy 请求：

第一次请求
模型：gpt-5.6-terra
输入 Token：19,218
缓存 Token：0
命中率：0%
第二次请求
模型：gpt-5.6-terra
输入 Token：19,310
缓存 Token：18,944
命中率：98.10%
第三次请求
模型：gpt-5.6-terra
输入 Token：21,137
缓存 Token：18,944
命中率：89.62%

第一次请求属于正常的冷缓存，因此命中率为 0；第二次和第三次请求分别命中 18,944 个 Token，说明相同的长前缀已经被成功复用。这也说明客户端显示为 0 不一定代表上游没有命中，也可能只是 CodeBuddy 没有识别 OpenAI 兼容响应中的嵌套 cached_tokens 字段。

只记录 Token 元数据

如果需要长期观察缓存，不建议打开 CLIProxyAPI 的完整 request-log，因为它可能记录 Prompt、代码和模型响应。更安全的做法是启用短期 usage 队列：

usage-statistics-enabled: true
redis-usage-queue-retention-seconds: 3600
request-log: false

然后用只允许本机访问的收集器读取 /v0/management/usage-queue，仅保存以下字段：

{
  "timestamp": "2026-07-18T17:15:52+08:00",
  "model": "gpt-5.6-terra",
  "endpoint": "POST /v1/chat/completions",
  "input_tokens": 19310,
  "output_tokens": 109,
  "reasoning_tokens": 20,
  "cached_tokens": 18944,
  "cache_hit_rate": 98.1,
  "total_tokens": 19439
}

不要保存 API Key、Authorization 请求头、Prompt、代码、响应正文和错误响应正文。CLIProxyAPI 当前版本不再内置持久化 usage 仪表盘；需要图形化统计时，可以参考其 README 中列出的 Usage Statistics 方案。

十、安全加固建议

这套架构可以工作，但公网 API 必须继续加固：

API Key 使用随机长字符串，不同客户端使用不同密钥；
CLIProxyAPI 仅监听 127.0.0.1；
Mihomo 只监听本机，不要开放局域网访问；
Caddy 层屏蔽管理接口；
Cloudflare 使用 Full (strict)；
SSH 只允许可信 IP；
不要长期启用完整请求日志；
定期更新 Mihomo、CLIProxyAPI 和 Caddy；
订阅链接和授权文件按密钥管理，泄露后立即轮换；
Cloudflare 橙云稳定后，可将安全组的 80/443 来源进一步限制为 Cloudflare 官方 IP 段，防止绕过 Cloudflare 直连源站。

需要注意，源站一旦用灰云公开解析过，历史 DNS 数据可能已经记录真实 IP。切换橙云并不等于源站 IP 从互联网历史中消失，因此限制源站入站范围仍然很重要。

十一、常用排查命令

# 查看三个核心服务
systemctl status mihomo cliproxyapi caddy

# 查看监听端口
ss -lntp | grep -E ':(7893|8317|80|443)'

# 测试 Mihomo 上游
curl -x http://127.0.0.1:7893 -I https://www.google.com

# 测试 CLIProxyAPI 本机接口
curl http://127.0.0.1:8317/v1/models \
  -H 'Authorization: Bearer YOUR_API_KEY'

# 查看 CLIProxyAPI 日志
journalctl -u cliproxyapi -f

# 查看 Caddy 证书与反代日志
journalctl -u caddy -f

# 查看脱敏 Token 元数据
tail -f /var/log/cliproxyapi/usage.jsonl

十二、总结

整个链路可以概括为：

CodeBuddy
  -> Cloudflare
  -> Caddy HTTPS
  -> CLIProxyAPI
  -> Mihomo
  -> OpenAI

配置过程里最关键的不是“让接口能返回 200”，而是控制每一层的暴露面：代理端口不出本机、CLIProxyAPI 不直接暴露、管理接口不出公网、API 必须鉴权、Cloudflare 使用严格 TLS、日志不保存代码和 Prompt。

完成这些之后，CodeBuddy 的自定义模型不仅能够正常对话和调用工具，Prompt Cache 也能在长会话中显著复用稳定上下文。即使客户端自身的缓存统计不准确，我们仍然可以通过 CLIProxyAPI 的脱敏 Token 元数据确认真实命中情况。

参考资料

本文发自 https://www.binss.me/blog/connect-codebuddy-to-custom-model/

采用知识共享署名-非商业性使用-相同方式共享 4.0 进行许可

Binsite