用 OPENAI_HOST 和精确模型 ID 让 Goose 跑在 Router One 上

安装 Goose，并单独建一把 Key

CLI 用官方安装脚本或 Homebrew（brew install block-goose-cli）安装；桌面版可直接下载，或 brew install --cask block-goose。安装脚本默认会在结尾进入交互式的 goose configure，加 CONFIGURE=false 可以跳过这一步，正适合本指南：provider 通过下面的环境变量配置，之后再用 goose configure 把同样的值持久化也可以。然后为这台机器单独创建一把设了 maxSpend 上限的 Router One Key，并从 /models 复制一个聊天模型的精确 ID；Goose 会把这个字符串原样放进请求的 model 字段。goose --version 可确认安装成功。下文的路径和默认值都对照 goose-docs.ai 页面和 v1.50.1 源码核对过。

# macOS/Linux 上安装 CLI：官方脚本；CONFIGURE=false 跳过交互式配置
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | CONFIGURE=false bash
goose --version
# 或用 Homebrew：brew install block-goose-cli（桌面版：brew install --cask block-goose）

把 Goose 配置到 Router One base URL

把代码块保存为 goose-env.sh，替换两个占位符，执行 source goose-env.sh，再运行 goose session。GOOSE_PROVIDER=openai 选中内置的 OpenAI provider，它的 id 就是 openai。GOOSE_MODEL 填目录里的模型 ID，逐字复制。OPENAI_API_KEY 会作为 Bearer token 发送；环境变量里的 Key 优先于 goose configure 保存的 Key，而写进 config.yaml 的 Key 会被忽略，表现为认证失败。OPENAI_HOST 是不带 /v1 的主机根地址：provider 会在它后面用一个斜杠拼上 OPENAI_BASE_PATH，所以按默认路径 v1/chat/completions，请求发往 https://api.router.one/v1/chat/completions；主机末尾多一个斜杠没有影响，但主机已经以 /v1 结尾就会变成 /v1/v1/chat/completions。因此 OPENAI_BASE_PATH 保持不设。选模型时要记住 provider 源码里的一条规则：base path 为默认值时，Goose 按模型名称决定端点。看起来像 OpenAI 的 gpt-5、gpt-6 或 o 系列的名称（在 ID 开头、或紧跟在 / 或连字符之后匹配，所以 openai/gpt-5.5 也算）会被送往 /v1/responses，其他名称都走 /v1/chat/completions。Router One 对目录中列出的 GPT 系列 ID 原生提供 /v1/responses，所以两条路径都能走通；Claude、Gemini、Grok 和 DeepSeek 的 ID 则留在 Chat Completions 上。发第一个请求前，用 goose info -v 打印实际生效的 provider、模型和主机：

# Goose built-in OpenAI provider -> Router One (macOS/Linux). source this file, then run: goose session
export GOOSE_PROVIDER="openai"
export GOOSE_MODEL="<exact-model-id-from-/models>"
export OPENAI_API_KEY="sk-your-router-one-key"
export OPENAI_HOST="https://api.router.one"   # host root only: no /v1, no path
# OPENAI_BASE_PATH stays at its default, v1/chat/completions.
# Goose joins it to OPENAI_HOST -> POST /v1/chat/completions
# (gpt-5, gpt-6 and o-series names are sent to /v1/responses instead).

每个值填在哪里，怎么验证

同样这几个值也可以通过 goose configure 输入（Configure Providers → OpenAI 会先问 Key，再问 OPENAI_HOST，默认值 https://api.openai.com，然后问 OPENAI_BASE_PATH，默认值 v1/chat/completions），或在 goose 桌面版填写（Settings → Models → Configure providers → OpenAI：API Key 和 Host URL）。不管走哪个界面，到达网关的请求都一样：

替代方案：自定义 provider 的 JSON 文件

如果想让 Router One 与 OpenAI provider 分开——在选择器里有自己的名字、单独的 Key 和固定的模型列表——就定义一个自定义 provider。goose configure → Custom Providers → Add A Custom Provider，以及桌面版的 Add Custom Provider（Provider Type 选 OpenAI Compatible，填 Display Name、API URL、API Key、Available Models、Streaming Support），写出的都是同一个 JSON 文件，放在 custom_providers 目录：macOS 和 Linux 是 ~/.config/goose/custom_providers/，Windows 是 %APPDATA%\Block\goose\config\custom_providers\，每个 provider 一个 <name>.json。base_url 按官方示例填完整的 Chat Completions 地址；Goose 会把它拆成主机和请求路径，所以每一轮仍是 POST /v1/chat/completions，同样的模型名称规则也会把 gpt-5、gpt-6 和 o 系列 ID 送到 /v1/responses。models 列出你想在选择器里看到的 ID，每个的 context_limit 填模型详情页上的上下文窗口，绝不能填输出 token 上限；Goose 还会向网关请求 GET /v1/models 并列出返回的模型。api_key_env 指定存放 Key 的环境变量名：启动 Goose 前先 export，或者在桌面版里输入 Key 存进系统 keyring。把 GOOSE_PROVIDER 设成 name 字段的值即可选中它：

{
  "name": "custom_router_one",
  "engine": "openai",
  "display_name": "Router One",
  "description": "Router One unified LLM API gateway",
  "api_key_env": "CUSTOM_ROUTER_ONE_API_KEY",
  "base_url": "https://api.router.one/v1/chat/completions",
  "models": [
    { "name": "<exact-model-id-from-/models>", "context_limit": <context-window-from-the-model-page> }
  ],
  "supports_streaming": true,
  "requires_auth": true
}

给一次会话定预算，并逐轮对账

一次 agent 会话是很多次模型请求。Goose 每一轮调用一次模型，每拿到一个工具结果又调用一次，它的 provider 层还会对限流、服务端错误和网络错误重试最多三次，采用指数退避（1 秒起，每次翻倍，最长 30 秒），所以每一次真正到达网关的尝试在 Dashboard → Logs 里都是独立请求，有各自的 request_id、tokens、费用和状态。给每台运行 Goose 的机器单独一把设了 maxSpend 的 Key：会话触到上限后，下一轮会收到 HTTP 402，钱包和其他 Key 不受影响。Goose 内部也要限制循环：GOOSE_MAX_TURNS（默认 1000），或 goose session 和 goose run 的 --max-turns，以及针对完全相同的重复调用的 --max-tool-repetitions。这里有三份记录，只有一份是钱。Logs 是逐请求的费用。Goose 自己的 llm_request.*.jsonl 文件（~/.local/state/goose/logs/ 下最近的十条）保存模型配置、请求体、响应和 token 用量，是查看离开本机的 model 字符串最快的办法。GOOSE_CLI_SHOW_COST（默认 false）打印的是估算成本，不是网关的实际扣费。按时间、模型和 token 数对账，报障时保留 Logs 里的 request_id。developer 扩展、MCP 服务器、会话、权限（GOOSE_MODE）和上下文压缩都在 Goose 里运行；Router One 只记录模型调用，别的都不记。

Goose 该填哪个模型 ID？

从 /models 页复制精确的模型 ID，保留大小写、连字符和版本后缀，不要用展示名称代替。打开该模型的详情页，核对支持的 API 端点、上下文窗口和工具调用等能力，再与 Goose 当前选择的 provider 和功能对应。模型出现在目录里，不等于当前客户端能调用它的所有功能。建议为每个工具单独建 API Key，并设置 maxSpend 消费上限。

Goose 用的是哪种 API 协议？

OpenAI 兼容描述的是接口格式，不能据此推断 Chat Completions（/v1/chat/completions）、Responses（/v1/responses）和 Anthropic Messages（/v1/messages）可以互换。先核对工具当前版本、provider 配置和实际请求路径，再查模型详情与 API 兼容性事实页。一次普通对话成功，也不能证明服务端工具、历史状态或文件编辑功能都受支持。

在 trace 里验证 Goose 的调用

先在 Goose 发出一次简单文本请求，再到 Dashboard → Logs 按时间、模型和 request_id 核对 trace：tokens、花费、延迟和状态码。成功后再分别验证流式输出、工具调用和多轮历史。失败时保留实际请求路径、完整错误消息及 request_id；没有对应日志时，先查客户端配置和网络，不能仅凭客户端报错认定是网关或上游故障。

常见问题