Goose 接入 AIGoCode：Provider API URL 和 base path 别填成同一段

两个地址字段，先分开核对

在 Goose 的自定义 Provider 中接入 AIGoCode 时，如果拿着一条完整 API 地址，不确定该填到哪个输入框，先停在地址核对这一步。Goose 的官方接入说明把地址分成 Provider API URL 和 API base path 两栏，不能把其他客户端的一格 Base URL 配置直接搬过来。

本文处理的是已经进入配置向导、需要检查地址与协议是否配套的场景。它不是一次真实故障的复盘，也不能仅凭连接失败就认定一定多填了路径。先按下表恢复到文档中的字段组合，再观察实际结果。

第一步：给当前 Provider 选定一行协议

运行 goose configure，在 Custom Providers → Add A Custom Provider 中核对配置。AIGoCode 的Goose 接入文档给出两组示例：

这张表要按列使用。不要从左列拿 API 类型、从右列拿路径，再保留另一把 Key。示例模型也应随对应协议一起核对；它们不是任意分组都能调用的承诺。

第二步：把地址恢复成“根地址一栏、路径一栏”

建议先在不含密钥的笔记里，分别记录当前的 URL 和 base path，然后逐项与上表对照：

• 如果 URL 一栏写成了带 /v1 或完整 /v1/chat/completions 的值，先核对是否把别的工具使用的地址抄到了 Goose。
• 如果 base path 一栏写入整个 https://... 地址，先改回当前协议对应的路径形式。
• 如果两栏都出现了相同的协议路径，先按文档示例拆开，避免同时在两处添加相同片段。

这里是在比较配置字段，不是在声明 Goose 内部一定如何拼接 URL。仅凭界面中的文字，不能推断最终请求地址；更不能把所有连接故障归为路径重复。排查的目标是先得到一份与官方示例一致、便于继续验证的配置。

可以保留如下不含 Key 的检查记录：API 类型 → Key 分组名称 → Provider API URL → API base path → 模型名。记录分组名称即可，不要把完整 Key 放进截图或工单。

第三步：检查有没有只改地址、没改协议的残留

从 OpenAI 兼容配置切到 Anthropic 时，不要只把 chat/completions 换为 messages 就结束。重新对照 API 类型、对应 Key 分组及示例模型，确认它们属于同一列；鉴权和流式两项也按文档选择 Yes。

如果你仍不确定该选哪一列，先看第三方工具的分组、协议与模型选择。本文只补充 Goose 把地址拆成两个输入项后的核对顺序，不替代账户中当前分组的说明。

第四步：用一次回复和用量记录完成核验

完成配置后，在项目目录运行 goose，先发送一条简短消息。官方文档以收到模型回复作为接入验证步骤，并建议随后在 AIGoCode 控制台的用量记录中确认请求。

建议把这次验证的时间与所选 Provider、模型一同记录，再去查对应请求。一次成功只能说明本次组合能够工作，不代表其他模型或另一把 Key 同样适用。若仍失败，保留实际错误，回到协议、Key 分组、两个地址字段和模型名逐项检查；每次只调整一个已发现不一致的项目。

需要进一步区分工具地址和协议地址时，可以继续阅读Base URL 填写边界。不要通过反复更换 Key 或同时修改多个字段来代替这份对照记录。