Goose 自定义供应商接入：完整路径与凭证存储

Goose 的自定义供应商不只是修改默认密钥：它可以为不同端点保存独立名称、模型清单和凭证。官方支持 OpenAI、Anthropic 或 Ollama 兼容格式，但具体模型的工具与流式行为仍要由服务确认。

Goose 自定义供应商与认证原创示意图，非运行截图

桌面入口和 CLI 入口

桌面端按 Settings → Models → Configure providers → Add Custom Provider 添加服务；CLI 则运行 goose configure，选择 Custom Providers 和 Add A Custom Provider。官方向导会询问协议、API URL、是否需要认证、可用模型及流式支持。

第一次接入优先使用向导，让客户端生成对应定义，避免凭记忆手写全部字段。认证确实由服务要求时，不应为了跳过报错而关闭认证选项。

API URL 的路径要按入口区分

官方自定义供应商 JSON 示例的 base_url 包含完整聊天补全路径。它与内置 OpenAI provider 的 OPENAI_HOST、OPENAI_BASE_PATH 拆分方式不同，不要在两个入口间原样复制地址。

自定义 OpenAI 兼容供应商示例
API URL: https://80321.cn/v1/chat/completions
API Key: YOUR_API_KEY
Available Models: YOUR_MODEL_ID

这里所有值均为占位，本站没有提供对应真实接口。真实接入前，让服务方确认完整请求路径；若使用内置 provider，则单独核对主机与路径拼接结果。

先看普通响应，再检查流式

保存后在 Goose 的供应商列表选中目标服务和模型，以纯文本短问题确认基础响应。接着在无私密资料的测试目录做一次只读任务，手动批准必要操作，检查工具请求是否被服务识别以及工具结果是否进入后续回答。

流式选项只在服务明确支持时启用。一次响应正常不能证明所有扩展可用，模型请求成功也不能证明 MCP 的独立认证完成。

404 与取不到密钥是两类问题

官方说明内置 OpenAI provider 的路径不匹配可能导致 404；密钥没有被加载则应检查凭证来源，不要一起修改主机、协议和认证方式。每次只改一个变量，并保留失败状态和脱敏错误，方便比较。

桌面端暂不能直接设置自定义请求头；CLI 的相应向导也仅对 OpenAI 兼容类型开放请求头输入，其他类型需按官方配置文件方式处理。

扩展之前先检查本地秘密存储

官方向导通常把静态密钥放入钥匙串；钥匙串不可用或被禁用时，可能使用 secrets.yaml。因此不要把整个 Goose 配置目录同步到公共仓库。先评估文本和只读工具，再按任务添加扩展，不运行来源不明的认证命令。本文核验的是文档提供的配置路径，没有执行模型调用或接通本站服务。