1. auto-review 报 codex-auto-review 模型名不支持，问题到底出在哪

你打开 auto-review 自动审查，日志里蹦出一句 model name not supported: codex-auto-review，审查结果一个都没有，功能整体挂掉。这个报错的核心检索词就是 auto-review、codex-auto-review、model name not supported、模型名校验、别名解析。它是什么？是 Codex 类工具在触发自动审查时，内部拿了一个写死的模型名去请求模型服务，而服务端的支持矩阵里根本没有这个名字。能做什么？把模型名从硬编码改成可配置，加上别名解析和前置校验，让 auto-review 重新识别到正确的模型名。适合谁？正在用 Codex 类工具做自动代码审查、被这句含糊报错卡住的开发者。

我先把现象拆清楚。开启 auto-review 后，工具会尝试调用一个叫 codex-auto-review 的模型；模型服务返回“该模型名不被支持”；auto-review 整个流程失败，没有产出任何审查结果；更麻烦的是报错没有告诉你“到底支持哪些模型名”，你根本不知道该往哪改。

这个问题其实有两层。第一层是这个名字本身不在服务端的支持列表里，可能是个过时的别名，也可能需要走特定端点。第二层是失败时没有给出可操作提示，客户端把服务端的拒绝原样透传，你只能干瞪眼。

模型服务通常维护一张支持矩阵：哪些模型名或别名当前可用、各自走哪个端点、有哪些能力。客户端请求时传一个 model 字段，服务端查矩阵——命中已知名就路由到对应后端，命中别名就解析成真实模型再路由，都不命中就返回“不支持”。bug 的根子在于：auto-review 功能里写死了一个模型名，但这个名字既不在矩阵里，也不是一个能被解析的别名，等于客户端和服务端的“可用名清单”对不上。

根因可以拆成五条：硬编码过时名，代码里 MODEL = "codex-auto-review"，但服务端已改名或挪了端点；无别名解析，即使它有别名，客户端也没做“别名到真实名”的映射，直接把原始串发出去；无前置校验，发请求前没先检查名字是否在支持列表，等服务端拒绝才知道；错误不友好，服务端说不支持，客户端原样透传，没补上“支持的有这些”；配置缺失，该功能没让你在配置里指定模型名，只能吃硬编码的死值。

下面我用一个最小模型复现“请求一个不在支持列表的名字被拒”，再一步步给修复方案，最后落到 config.toml 的可复制配置骨架。

2. 用 TaoToken 做模型服务前置准备

在动手改配置之前，得先有一个能正常响应模型请求的服务端。我这边用 TaoToken 作为模型服务入口，它的 API 地址是 https://taotoken.net/api，官网在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=。你需要先去控制台拿一个 API Key，再确认当前账号下实际可用的模型名清单——这一步很关键，因为后面 config.toml 里填的模型名必须和这份清单对得上。

拿 Key 的路径是进控制台，找到 API Keys 页面创建。创建完把 Key 存到环境变量里，别直接写进配置文件明文，后面配置里用 ${TAOTOKEN_API_KEY} 这种占位引用。

export TAOTOKEN_API_KEY="sk-你的实际key"
echo $TAOTOKEN_API_KEY

确认环境变量生效后，先别急着配 auto-review，先用一个最朴素的请求验证模型服务本身是通的。这一步能帮你把“服务端问题”和“客户端配置问题”分开，省得后面排查时两头猜。

curl -s https://taotoken.net/api/v1/models \
  -H "Authorization: Bearer $TAOTOKEN_API_KEY" \
  | head -c 800

返回的 JSON 里会列出当前可用的模型名。把这份清单记下来，它就是你的“支持矩阵”来源。如果这里返回的清单里压根没有 codex-auto-review，那报错的根因就坐实了——客户端写死的名字和服务端清单脱节。

注意：模型名清单会随服务端演进变化，所以任何写死在代码或配置里的名字都有过时风险。正确做法是让模型名可配置，并在启动时做一次校验。

3. config.toml 中模型别名解析与校验的可复制配置骨架

现在进入正题。Codex 类工具的配置通常放在 config.toml，我们要在这里定义模型名、别名映射和校验开关。下面这份骨架你可以直接抄，把模型名换成你从上面清单里查到的真实名字。

# config.toml
[model]
# 真实模型名，必须与服务端支持矩阵一致
name = "codex-review"
# 别名映射：旧名/简写 -> 真实名
[model.aliases]
"codex-auto-review" = "codex-review"
"review" = "codex-review"
"reviewer" = "codex-review"

[auto_review]
enabled = true
# 引用 model.name，不再写死
model = "codex-auto-review"
# 发请求前先校验名字是否受支持
validate_before_request = true
# 校验失败时是否列出支持清单
friendly_error = true

[provider]
base_url = "https://taotoken.net/api"
api_key = "${TAOTOKEN_API_KEY}"

这份配置的关键点有三个。第一，[model] 段里的 name 是真实名，[model.aliases] 段负责把历史名字映射过去。第二，[auto_review] 段的 model 可以继续写旧名 codex-auto-review，因为别名层会在发请求前把它解析成 codex-review。第三，validate_before_request = true 让客户端在发请求前先查支持矩阵，不支持就早失败，而不是等服务端拒绝。

如果你用的工具不支持 [model.aliases] 这种嵌套写法，可以退化成扁平键：

[model]
name = "codex-review"
alias_codex_auto_review = "codex-review"
alias_review = "codex-review"

配置写完后，别直接重启就完事，先做一次静态校验。很多工具提供了 --check-config 之类的参数，没有的话就自己写个小脚本读 TOML 并比对支持清单。

import tomllib

with open("config.toml", "rb") as f:
    cfg = tomllib.load(f)

real_name = cfg["model"]["name"]
aliases = cfg["model"].get("aliases", {})
auto_model = cfg["auto_review"]["model"]

resolved = aliases.get(auto_model, auto_model)
print(f"auto_review 配置名: {auto_model}")
print(f"解析后真实名: {resolved}")
print(f"是否与 model.name 一致: {resolved == real_name}")

运行后如果 resolved == real_name 为 True，说明别名解析链路是通的。这一步能提前抓出拼写错误和映射缺失，比等到运行时看报错强得多。

4. 验证请求与成功结果

配置改完，重启工具，再触发一次 auto-review。验证要分两步走：先确认模型服务本身能响应，再确认 auto-review 能拿到审查结果。

第一步，用解析后的真实名直接打一次请求，确认服务端认这个名字。

curl -s https://taotoken.net/api/v1/chat/completions \
  -H "Authorization: Bearer $TAOTOKEN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "codex-review",
    "messages": [{"role": "user", "content": "review this: int a = 1;"}]
  }' | head -c 600

如果返回里带了正常的 choices 字段，说明服务端认 codex-review 这个名字。如果这里就报 model name not supported，那说明你从清单里抄的名字不对，回去重新查 /v1/models。

第二步，触发 auto-review，观察日志。成功的标志是：不再出现 codex-auto-review model name not supported，审查结果正常产出。日志里应该能看到类似“alias resolved: codex-auto-review -> codex-review”的提示，这说明别名层生效了。

[auto-review] config model: codex-auto-review
[auto-review] alias resolved: codex-auto-review -> codex-review
[auto-review] validate ok, sending request
[auto-review] review completed, 3 findings

看到 review completed 就说明整条链路通了。如果还是失败，进入下一节的排查。

5. 本篇常见错排查

错误一：改了 [model].name 但没改 [auto_review].model。 这两个字段是分开的，auto_review.model 才是 auto-review 实际用的名字。如果你只改了前者，后者还是旧名，别名层又没配，照样报错。检查方法就是上面那段 Python 校验脚本。

错误二：别名映射写反了。 [model.aliases] 的键是旧名，值是真实名。写成 "codex-review" = "codex-auto-review" 就反了，解析后反而指向不支持的名字。记住方向：左边是你要兼容的历史名，右边是服务端认的真实名。

错误三：validate_before_request 开了但支持清单没拉取。 有些工具需要你显式配置支持清单的来源，比如 supported_models_url。如果没配，校验时清单为空，任何名字都会被判为不支持。补上清单来源，或者退一步把校验关掉先跑通。

错误四：端点配错导致“不支持”。 有些模型名需要走特定端点，比如 /v1/responses 而不是 /v1/chat/completions。名字对但端点错，服务端也可能返回不支持。检查 base_url 和请求路径是否匹配该模型的要求。

错误五：环境变量没生效。 api_key = "${TAOTOKEN_API_KEY}" 这种占位引用依赖工具支持环境变量展开。如果工具不支持，会直接把字面量当 Key 发出去，返回 401 而不是模型名不支持。先用 echo $TAOTOKEN_API_KEY 确认变量存在，再确认工具是否支持展开语法。

错误六：TOML 语法错误导致配置没加载。 嵌套表 [model.aliases] 必须写在 [model] 之后，否则会被解析成顶层表。用 tomllib 读一遍，语法错会直接抛异常，比运行时猜强。

排查顺序建议按这个清单走：先确认名字来源是写死还是配置，再确认服务端支持矩阵里有没有这个名字，然后看别名层有没有做映射，接着看发请求前有没有前置校验，最后看错误提示是否友好、模型名是否可配置。按这个顺序，基本能在五分钟内定位到具体哪一环断了。

6. 把模型名从硬故障变成一次清晰的配置调整

回到最初的问题：auto-review 因 codex-auto-review 模型名不支持而失败，本质是客户端硬编码的模型名与服务端支持矩阵脱节，且失败时缺乏别名解析与友好提示。修复分三层——前置校验，发请求前查支持矩阵，不支持就早失败；别名解析，旧名和别名自动映射成真实支持名，兼容历史配置；友好错误加可配置，错误列出支持项并给建议，模型名允许你在配置里覆盖。

核心原则就一句：模型名这类会随服务端演进而变化的东西，绝不该在客户端写死。用支持矩阵加别名层加可配置加友好错误，把“名字对不上”从硬故障变成一次清晰的配置调整。

如果你在配 config.toml 时卡在别名解析或校验环节，可以直接去 TaoToken 的 API Keys 页面确认 Key 和模型清单，接入文档里有完整的端点说明；想先验证模型名能不能正常响应，用模型对话页面发一条测试请求最快；如果你是要长期跑 auto-review 或 Agent 类编码任务，Coding Plan 更适合持续调用场景。把模型名配对了，auto-review 才能真正帮你把代码审查跑起来。