WorkBuddy对接GPT-6.1 Terra遇阻，LiteLLM桥接适配成功

最近，有用户在获得某AI平台的Pro账号API额度后，尝试将其应用于工作助手工具WorkBuddy时遇到了连接失败的问题。该用户原本计划将这笔额度用于解决朋友的接入难题，却在调试过程中发现了更多接口适配的问题。

朋友的接入失败，起初被认为是网络问题——对方填写的是官方API地址，而该地址在国内无法直接访问。该用户之前曾为旧版模型搭建过海外VPS的Nginx转发，于是尝试为新模型GPT-6.1 Terra复刻这套转发逻辑：先在AI平台为WorkBuddy创建专属API密钥，再在WorkBuddy的设置中添加自定义模型，填入自己的转发地址和模型名称。

但配置完成后，WorkBuddy仍提示“连接失败”。原本以为只是网络转发的小问题，却没想到涉及到模型参数的适配差异。

借助Codex工具排查后，定位到核心原因：WorkBuddy发送的max_tokens参数，当前的GPT-6.1 Terra模型并不支持，该参数仅能在GPT-4.1及更早的模型上生效。用户尝试将模型切换为GPT-4.1后，连接成功，但这并非所需的目标模型，于是交给Codex寻找解决方案。

Codex最终选择了LiteLLM作为接口适配方案，它可以将WorkBuddy使用的Chat Completions协议，转换为GPT-6.1 Terra要求的Responses API协议，实现了对客户端的透明兼容。这套方案的请求链路为：WorkBuddy → 自建HTTPS网关 → LiteLLM的Chat Completions接口 → 目标AI平台的Responses API。

LiteLLM的核心配置围绕模型路由展开，使用1.106.6版本时，关键配置如下：

model_list:
  - model_name: gpt-6.1-terra
    litellm_params:
      model: openai/responses/gpt-6.1-terra
      api_key: os.environ/OPENAI_API_KEY
      reasoning_effort: none
      store: false
      num_retries: 0
      allowed_openai_params: [tool_choice]

这里的model_name是WorkBuddy看到的模型标识，明确指定上游调用Responses API；api_key从服务器环境变量读取，避免直接暴露；allowed_openai_params则解决了工具调用时的参数拒绝问题，显式允许tool_choice参数通过。

配置完成后，该用户通过多轮测试验证链路有效性：包括普通对话、多轮上下文、流式工具调用等，都顺利通过。为进一步确认工具执行的正确性，还设计了文件操作测试：要求读取一个测试文件，修改第一行内容后写入新文件，且不修改原文件。任务在十几秒内完成，结果符合预期，验证了模型调用和数据传输的准确性。

最终的部署方案保留了原有的转发逻辑，同时为WorkBuddy增加了独立入口：LiteLLM仅监听服务器本机，由Nginx提供HTTPS访问；WorkBuddy的自定义模型中填写的三项信息为：模型ID（gpt-6.1-terra）、接口地址（自建网关地址）、专属API密钥，且客户端凭证与AI平台的密钥分开管理，确保安全性。

在完成WorkBuddy的接入后，该用户还借助GPT-6.1 Terra开发了一个图片模糊化工具——由于之前的调试截图中包含私人地址，先制作了网页版工具，随后优化为Mac端的小应用，本文中所有模糊处理后的图片均由该工具生成。

整个调试过程的核心是解决不同接口协议的适配问题，最终通过LiteLLM的桥接方案实现了跨协议兼容。如果有更高效的适配经验，欢迎分享交流。