代理用久了，想法会变
上一篇文章写了怎么把 Trae 桌面端的模型变成本地 OpenAI 兼容接口。当时脑子里想的还是“代理”：Trae 的私有协议进来，标准的 OpenAI 协议出去，能调通就行。
用了一段时间之后，想法慢慢变了。
因为我发现自己在调的不只是 Trae。DeepSeek 的官方 key、Kimi、智谱、本地 Ollama，甚至偶尔用一下 Anthropic 和 Gemini——每个都有自己一套地址、key、模型名。Trae 这边有两个区域，代理还得开两个端口。客户端里塞了四五套配置，每次换工具都要重新填一遍。
所以后来重写的时候，方向就不是“把 Trae 转发得更稳”，而是“把本地所有模型渠道收拢成一个入口”。也就是一个本地大模型网关。
网关和代理的区别
代理做的是“翻译”：上游是什么，就尽量原样透传成什么。
网关做的是“收口”：不管上游是 Trae、OpenAI 兼容服务、Anthropic、Gemini 还是 Ollama，对客户端来说都只是同一个地址、同一个模型列表、同一套鉴权。
具体到现在的项目：
所有渠道都注册在同一个网关里，模型 id 统一带前缀，比如 trae-cn/glm-5.3、deepseek/deepseek-chat、ollama/llama3.1。客户端只认一个 baseURL，配一把 key，从 /v1/models 拉到什么就调什么，不需要知道模型背后是哪家。
网关自己负责拆模型 id、选渠道、转发、记录用量。Trae 登录态这种只有本机能拿的东西，也成了其中一个渠道，而不是整个项目的全部。
顺带解决的那些小事
做成网关之后，很多以前“凑合能用”的地方自然就有了答案。
之前 key 只有“有”和“没有”两种状态，现在可以限制某个 key 只能访问某些渠道、某些模型。之前用量全靠猜，现在每次请求都会落到 SQLite，管理台能看到汇总、分布和最近记录。之前想给 CC Switch、opencode 配置，得手动填地址和 key，现在管理台直接唤起官方导入，opencode 也有脚本自动写入实时模型目录。
这些功能单个看都不算复杂，但合在一起才像“网关”而不是“脚本”。
一点感受
这个项目做到后面，最大的变化不是代码变多，而是看待它的方式变了：Trae 只是模型来源之一，真正的产品是本地那个统一的 /v1 端点。
如果你只是想偶尔在别的工具里用一下 Trae，一个轻量代理就够了。但如果你想在自己的电脑上长期维护一个“什么模型都能接、所有客户端都只配一次”的入口，网关这个思路更顺。
参考与许可
实现思路和部分代码参考：
版权与署名见仓库的 LICENSE 与 THIRD_PARTY_NOTICES.md。
Github: https://github.com/anghunk/trae-proxy
提醒：本项目只适用于自己已登录的账号，请遵守 Trae 的服务条款，不要用于绕过计费或多人共享。
评论