本地 API Proxy： Anthropic / OpenAI Chat / Responses 互转，支持 DeepSeek

综合交流大区
,
1

最近在深度试用几家国产大模型，但几乎清一色都还是 OpenAI Chat Completions 接口，导致在较新的 Codex CLI 里没法直接用。

于是在开源工具 VibeAround 的命令行一键启动功能上，加了一个 local API proxy ，主要解决 coding agent 和模型 provider 之间 API 格式不一致的问题。

现在可以在 Anthropic Messages / OpenAI Chat Completions / OpenAI Responses 之间做转换和适配，比如把 Claude 模型跑到 Codex CLI 里，或者把 OpenAI 模型跑到 Claude Code 里。

这次重点是 DeepSeek 。

它除了 Chat → Responses 之外，还需要额外处理 thinking/reasoning content 和 tool call 合并。虽说是 vibe 出来的功能，但确实花了不少 token 。

现在配置过的 provider profile 都可以通过 VibeAround 暴露成本地 endpoint ，给 Codex CLI / Claude Code 或者其他工具比如 Cursor 使用。

理论上 Kimi 、MiniMax 、Z.AI/GLM ，以及自定义 OpenAI-compatible Chat Completions 都支持。

项目地址：
https://github.com/jazzenchen/VibeAround

2

这东西就那样，早就有类似方案了，懒得折腾。

3

小白问一下，这个代理是不是需要一直开着本地服务才能用啊？如果我想在远程服务器上部署模型，还能用这个工具做转换吗？不太懂网络这块。

4

mark一下，项目看起来不错，正好最近在折腾多个模型调用的问题，回头研究研究。

5

我来分享一下自己踩坑的经历吧。之前为了在Codex里用Claude，自己写了个简单的中间件转格式，结果在tool call那块折腾了好久，特别是一些嵌套结构，还有流式返回的时候处理起来很烦人。看到楼主重点提了DeepSeek的thinking内容处理，感觉这个痛点抓得很准，国产模型这块的适配确实是个麻烦事。不知道楼主测试过长时间对话的稳定性没有？

6

所以那个thinking和reasoning content具体是怎么转换的？是把整个reasoning内容作为单独的message字段塞进去，还是直接拼接到文本里了？如果工具调用和思考内容同时出现，转换后的消息顺序能保证吗？

7

楼里有人试过搭配Cursor用吗？效果怎么样？我平时主要用Cursor，要是这个代理能让Cursor直接调用Kimi或者DeepSeek，那可就太方便了，省得每次都要手动复制粘贴。

8

又来这种帖子了，开源个工具就吹得天花乱坠，什么“理论上都支持”，等用户实际用起来一堆bug，最后还不是得自己填坑。

9

具体操作步骤：

  1. 克隆项目到本地。
  2. 按照README配置你的模型API密钥和端点。
  3. 运行启动命令，通常是 vibe around start --profile your_profile。
  4. 代理会在本地某个端口（比如8080）启动。
  5. 把你的工具（如Codex CLI）的API地址指向这个本地地址。
    注意替换掉默认的OpenAI地址。
10

周末烤的戚风蛋糕又塌了，心累。回来看论坛发现这个工具，感觉可以试试把我那个总出错的AI助手整合一下。话说楼主提到花了不少token，是调试的时候花的吗？这成本确实得考虑进去。

11

Codex CLI不能直接用国产模型这事我一直觉得别扭

12

嵌套tool call确实是大坑 一般要展平再回灌 否则模型直接懵

13

tool call嵌套那块自己写中间件确实折腾，光JSON schema对齐就够呛

14

步骤是清楚 但profile那块文档还是太薄 卡在密钥识别的人不少