把 Trae 桌面端的模型接进任意 OpenAI 客户端（二）：做成本地大模型网关之后
内容提要
作者最初为Trae桌面端开发OpenAI兼容代理，后转向构建本地大模型网关。该网关统一接入Trae、DeepSeek、Kimi、Ollama等渠道，模型ID带前缀，客户端只需一个baseURL和key。网关负责解析模型ID、选择渠道、转发请求并记录用量，支持key权限控制、SQLite用量统计和配置导入。核心产品是统一的/v1端点，Trae仅为渠道之一。
延伸解读
从代理到网关：思路转变的关键
作者最初只做Trae的OpenAI兼容代理，但实际使用中需要同时管理DeepSeek、Kimi、Ollama等多个渠道，每个都有独立的地址、密钥和模型名，客户端配置繁琐。重写后转向本地大模型网关，核心变化是从“翻译”变为“收口”：所有渠道统一注册，模型ID带前缀，客户端只需一个baseURL和key。这解决了多工具切换时反复配置的问题，也降低了维护成本。
统一模型ID与端点带来的便利
网关将不同渠道的模型统一为带前缀的ID，如trae-cn/glm-5.3、deepseek/deepseek-chat、ollama/llama3.1。客户端通过/v1/models获取模型列表，无需关心背后是哪家服务。网关负责解析模型ID、选择渠道、转发请求并记录用量。这种设计让Trae登录态等本机资源成为渠道之一，而非项目全部，提升了扩展性和一致性。
权限控制与用量统计的实用价值
网关支持为每个key限制可访问的渠道和模型，改变了以往key只有“有”和“没有”两种状态的粗放管理。每次请求的用量会写入SQLite，管理台可查看汇总、分布和最近记录，让用量从“靠猜”变为可追溯。此外，管理台能直接唤起CC Switch、opencode的官方导入，或通过脚本自动写入实时模型目录，简化了客户端配置流程。
适用场景与注意事项
如果只是偶尔在别的工具里使用Trae，轻量代理即可满足需求。但若想在本地长期维护一个“什么模型都能接、所有客户端只配一次”的入口，网关思路更合适。需要注意的是，该项目仅适用于自己已登录的账号，应遵守Trae服务条款，不得用于绕过计费或多人共享。实现思路和部分代码可参考开源仓库，版权与署名见LICENSE及THIRD_PARTY_NOTICES.md。
Q&A
本地大模型网关和之前的代理有什么区别？
代理做的是“翻译”，上游是什么就尽量原样透传成什么；网关做的是“收口”，不管上游是 Trae、OpenAI 兼容服务、Anthropic、Gemini 还是 Ollama，对客户端来说都只是同一个地址、同一个模型列表、同一套鉴权。
这个网关支持接入哪些模型渠道？
支持 Trae、DeepSeek、Kimi、智谱、本地 Ollama，甚至偶尔用一下 Anthropic 和 Gemini。所有渠道都注册在同一个网关里。
客户端如何调用网关里的不同模型？
客户端只认一个 baseURL，配一把 key，从 /v1/models 拉到什么就调什么，不需要知道模型背后是哪家。模型 id 统一带前缀，比如 trae-cn/glm-5.3、deepseek/deepseek-chat、ollama/llama3.1。
网关的 key 权限控制能做什么？
之前 key 只有“有”和“没有”两种状态，现在可以限制某个 key 只能访问某些渠道、某些模型。
网关如何记录和查看用量？
每次请求都会落到 SQLite，管理台能看到汇总、分布和最近记录。
网关提供了哪些配置导入的便利？
之前想给 CC Switch、opencode 配置，得手动填地址和 key，现在管理台直接唤起官方导入，opencode 也有脚本自动写入实时模型目录。
什么情况下适合用轻量代理而不是网关？
如果你只是想偶尔在别的工具里用一下 Trae，一个轻量代理就够了。但如果你想在自己的电脑上长期维护一个“什么模型都能接、所有客户端都只配一次”的入口，网关这个思路更顺。
使用这个项目有什么注意事项？
本项目只适用于自己已登录的账号，请遵守 Trae 的服务条款，不要用于绕过计费或多人共享。
