Trae / Windsurf / Kilo Code：新一代 IDE 的 base_url 配置差异

先做一次协议筛查

在动手配置之前，先回答一个问题：这个客户端支持哪些协议？

这决定了你能不能直接指向中转站，还是必须先做一次格式转换。

结论：如果你的中转站只提供 OpenAI 兼容端点，Windsurf / Trae 这类更省事；如果你要接的模型只在 Anthropic 协议下表现正常（尤其是 Claude 系列的工具调用），优先选支持 Anthropic 的客户端。

三类共性问题

一、模型名必须手动填，且必须与中转站一致

这一点和 Cursor 一样。没有哪个客户端会自动从中转站拉取模型列表。

可靠做法：先用 curl 打 /v1/models 拿到真实清单，再照抄。

二、工具调用是否需要额外开启

Agent 类功能（读文件、改文件、跑命令）依赖工具调用。有几件事要确认：

1. 客户端侧：是否开启了 Agent / Tools 模式；
2. 中转站侧：是否支持工具调用（用本站《函数调用兼容性》那篇的四个用例测）；
3. 协议侧：如果走 OpenAI 格式调 Claude，工具调用的转换质量决定了 Agent 能不能用。

经验：用 OpenAI 格式调 Claude 系模型时，工具调用出问题的概率明显高于用 Anthropic 原生格式。这不是玄学 —— OpenAI 的 arguments 是字符串、Anthropic 的 input 是对象，转换层在这一步出错的概率很高。

所以：能用原生 Anthropic 协议就用原生，不要图省事统一走 OpenAI 格式。

三、官方登录与自定义 API 的优先级

这几款客户端都有官方订阅通道。配置自定义 API 时要注意：

• 部分版本在检测到官方登录态时优先走官方通道，导致你以为在用自己的 Key，实际没有；
• 建议先在设置里退出官方账号，或明确切换 provider。

判断方法：去中转站后台看请求日志。如果发请求后站方后台没有任何记录，说明请求根本没到中转站。

这是排查「配置完没反应」最快的一招 —— 先看服务端有没有收到请求，能立刻把问题分成「客户端没发出来」和「服务端处理失败」两类。

VS Code 系插件的通用配置要点

Kilo Code / Roo Code / Cline 这一系插件，配置项结构相似：

1. API Provider：选 OpenAI Compatible 或 Anthropic；
2. Base URL：注意带不带 /v1（通常要带）；
3. API Key；
4. Model ID：手填，与中转站一致；
5. 上下文长度：手填。这一项容易被忽略，填默认值可能导致请求超限。建议填中转站标称值的 80%，留出余量。
6. 是否开启工具调用：显式打开。

第 5 项值得单独强调：这类插件会把整段对话历史 + 系统提示一起发出去，消息量比 Chat 大得多。上下文长度填错会直接报错或触发静默截断，表现为「Agent 用几轮之后就开始忘事」。

一个排错顺序

配置不通时按这个顺序查，每步都能把范围缩小一半：

1. curl 直连中转站的 /v1/chat/completions —— 通不了就是站点或 Key 的问题，与客户端无关；
2. curl 模拟一次带 tools 的请求 —— 通不了说明站点工具调用有问题，客户端再怎么配都没用；
3. 客户端里发一句纯聊天 —— 通不了说明 Base URL 或 Key 填错；
4. 客户端里让 Agent 读一个文件 —— 只有这一步失败，说明是工具调用/协议转换问题。

绝大多数「配置不通」的问题在第 1、2 步就能定位，不需要在客户端里反复试。

小结

这几款客户端在「能不能接中转站」上差别不大，真正的差别在协议支持范围和配置项的清晰程度。

选择顺序建议：

1. 优先用支持 Anthropic 原生协议的客户端接 Claude 系模型；
2. 优先用支持 OpenAI 格式的客户端接 GPT / Gemini / 国产模型；
3. 上下文长度、模型名这两项手动配置一定要对得上。

本站详情页会标注各站「适配的客户端」（来自站点自宣，页面有标注来源），可以配合本文一起看。