Gemini 4 Argon 接入前，先在控制台确认它对当前项目是否开放

Gemini 4 Argon 能不能在当前项目上调通，和“这个模型已经上线”不是一回事。上线说的是服务侧存在这个模型，能不能调用取决于你手上这个项目有没有被授权、你手上这把密钥属于哪个项目。所以接入前值得做的一步不是在代码里把模型名换掉，而是先在控制台把可见性和权限确认到“可以用”或者“明确不可用”，再决定要不要动线上配置。

判断 Gemini 4 Argon 是否可用，建议按「账号是否可见 → 项目是否开放 → 密钥是否绑在该项目 → 一次最简请求是否返回成功」的顺序逐层验证。只有模型挂在目标项目下、且密钥所属项目与之一致时，才值得动线上模型配置；探测阶段只验证可用性，探测不通过就保持旧模型配置不变。适用于多项目、多组织共用一个开发者账号的场景，边界是控制台里的授权结果不替代计费侧与配额侧的确认。

在控制台的模型列表里确认 Gemini 4 Argon 是否挂在当前项目

控制台里“能看到 Gemini 4 Argon”和“当前项目能用 Gemini 4 Argon”是两个判断层。前者说的是账号或组织层面有没有这个模型入口，后者说的是这个模型有没有被分配到你现在要发起调用的那个项目。很多误判就来自把前者当成后者：在代码里改掉模型名，最后在日志里收到一个和模型无关的权限错误。

先在模型列表页把下面三列（各平台字段叫法不同，含义一致）逐一对照：

模型名称：确认列表里确实存在 Gemini 4 Argon 这一项，而不是名称相近的其它版本。
可用项目：这一项是空的，还是指向你准备调用的那个项目编号或项目名。空值通常说明只在账号层级可见，没有被授权给任何项目。
状态：是已启用、待审核还是已停用。停用状态下调用能不能通过，不要靠猜。

只有“可用项目”里出现目标项目，才算当前项目可调用。若列表里能看到模型，但可用项目为空或只指向另一个项目，那么无论怎么改代码里的模型标识都不会成功——这时要看的是项目级授权入口，不是代码。

核对 API Key 对应的项目与组织，排除密钥跨项目的误判

拿到权限错误时，先别急着怀疑模型。建议按下面几项把密钥和项目的对应关系确认一遍，通常能排掉大部分“看起来是模型问题、实际是密钥绑错项目”的情况：

这把密钥是在哪个项目下创建的，是不是你准备调用的那个项目。
该项目属于哪个组织，账号当前所在的组织上下文是否和它一致。
密钥是否被限制到了特定 API 或特定模型范围，限制里有没有包含目标模型。
模型列表里“可用项目”的项目编号，与密钥所属项目编号是否一致。

这些项确认完之后，再用一条最简请求打印原始返回体。不要只看 SDK 抛出的异常摘要，很多平台会把“项目不匹配”“模型未授权”“模型不存在”压在返回体的正文里，异常摘要反而丢掉了关键字段。打印原始 body 的写法在下节给出，重点是保留状态码和未解析的原文。

写一段最小探测脚本，只验证可用性不掺业务逻辑

探测脚本的目的只有一个：用最低成本拿到“能调用 / 不能调用”的明确结论。所以不要在这里加温度、最大输出长度、工具定义、系统提示词这些参数，也不要合并进业务请求。字段名和地址按你实际接口规范替换，下面只是骨架：

import json, os, urllib.request, urllib.error

endpoint = os.environ["MODEL_ENDPOINT"]
api_key = os.environ["MODEL_KEY"]
model = os.environ["MODEL_NAME"]

payload = json.dumps({"model": model, "input": "ping"}).encode("utf-8")
req = urllib.request.Request(
    endpoint,
    data=payload,
    headers={
        "Authorization": "Bearer " + api_key,
        "Content-Type": "application/json",
    },
    method="POST",
)

try:
    with urllib.request.urlopen(req, timeout=20) as resp:
        print("http_status =", resp.status)
        print("raw_body =", resp.read().decode("utf-8", "replace"))
except urllib.error.HTTPError as e:
    print("http_status =", e.code)
    print("raw_body =", e.read().decode("utf-8", "replace"))
except Exception as e:
    print("transport_error =", repr(e))

密钥从环境变量读，不要写进脚本、不要提交进仓库。脚本放在本地或跳板机上跑一次即可，输出里保留 http_status、raw_body、transport_error 三类信息，后续排查都以这份原始输出为准。

把探测结果分成三种：可调用、可见但未授权、完全不可见

探测结果先归成三类，比逐个错误码去猜更省事：

可调用：请求返回成功，返回体里是正常的模型输出结构。下一步不是改线上，而是先在非线上环境跑一遍真实调用链，确认参数拼接没问题。
可见但未授权：模型列表里能看到 Gemini 4 Argon，但请求返回权限类错误。下一步是回到项目授权或组织策略页，确认这个模型有没有被分配给当前项目；此时不该反复重试刷日志，也不该临时借用别人的密钥。
完全不可见：返回模型不存在或路径类错误。下一步先确认请求里的模型标识、项目标识有没有写错，再确认账号是否在正确的组织上下文中；此时不该动线上配置，因为问题还没定位到配置层。

三类结果对应三个阶段，混在一起判断最容易做出错误动作。

改线上配置前先保留旧模型回退分支

确认可调用之后再考虑切换。切换动作建议收敛到一个配置项：配置里同时保留新模型名和旧模型名，比如主用项和回退项两个键，切换时只改指向关系，不直接覆盖旧值。这样回退不需要重新发版，也不需要回忆原来写的是什么。

旧模型名的保留方式：新旧两个名字都存在配置里，旧值在验证稳定之前不删除。
回退触发条件：首批请求返回权限错误、模型不存在或超时，就切回旧模型名，不要在业务代码里堆多级重试再回退。
切换后需要观察的日志字段：实际命中的模型名、项目 ID、HTTP 状态码、错误原文、请求追踪 ID。

这几个字段能让你在出问题时快速分辨是模型侧的问题，还是配置项改错了。至于配额、计费和速率限制是否满足，需要在各自的控制台侧另行确认，不在这次探测的结论范围内。