选了 GPT-6，却像 Luna？模型路由怎么查

明明选了 GPT-6 Astra，回答却差得让人怀疑人生。你追问“你到底是什么模型”，它报出另一个名字。看到这里，很容易觉得已经抓到了换模型的证据。

问题在于，这个名字也是模型生成的文本。它可能受身份提示影响，可能沿用了旧说法，也可能只是猜的。要查模型路由，需要沿着那一次请求去找记录。

最近的 Astra 降质争议让这个问题变得很实际。截至 9 月 15 日，我们查阅的公开资料还无法确认 Astra 被大范围、未告知地替换为 GPT-5.6 Luna。具体到自己遇到的某一次响应，可以从下面几层证据查起。

已有一份报告，正好说明了“自报身份”的问题

Codex Issue #44598记录了一个案例：用户给三个子 Agent 请求的模型是 gpt-5.6-sol，它们却自称 GPT-6。检查记录后，用户发现其中有 GPT-6 身份指令，也有 Sol 请求配置，但缺少实际服务模型字段。报告因此将问题描述为身份信息与可观测性不一致，没有把它当成模型覆盖设置失效的证明。

这个例子恰好和“被换成 Luna”的怀疑方向相反。它说明，无论自报的模型更强还是更弱，光看那句话，都无法确定后台跑了什么。

沿着同一次响应，依次看这几层

“模型”这个词，在不同地方指的可能是不同事实。

先看自己的入口实际提供了什么。如果只有模型选择器和用量表，就从这两个事实开始。缺少服务模型字段，是当前排查的一个缺口；用“它看起来像某个模型”填进去，并不会让记录更完整。

OpenAI 的 Responses API 文档将响应对象中的 model 定义为生成该响应所用的模型 ID，同时提供响应 id。API 调用方可以据此关联记录，但不能假设每个 ChatGPT 或 Codex 客户端都会把这些字段展示给用户。

还要记下元数据来自哪个端点。第三方网关可能转换模型别名、规范化返回格式。如果你的日志只到网关这一层，需要由它的运营方继续提供对应的上游记录。供应方自己的响应字段，比聊天里的自我介绍更有依据，但它依然是供应方的声明，不是对底层实现的密码学证明。

父 Agent、子 Agent 和重试，分别记一行

屏幕上的一个任务，可能对应多次模型调用。

举个假设例子：父 Agent 使用 Astra，一个明确指定使用 Luna 的子 Agent 负责找文件，最后父 Agent 再修改代码。此时在子 Agent 记录里看到 Luna，符合这个配置本身。

再比如，第一次 Astra 请求失败，客户端按设置切换到了备用模型。后面的成功响应属于另一次尝试。如果拿它的模型字段去对照最初的请求，却省略中间的重试，就会得到一份缺少关键背景的“路由不一致”记录。

对相关调用，至少保留：

• 它属于父任务、子任务还是重试；
• 请求模型，以及可见的响应模型；
• 时间和用于关联记录的请求或响应标识；
• 是否明确配置了备用模型或单独的模型覆盖。

不用为了证明一条响应，公开整个项目的聊天记录。一条能够准确关联的响应，通常比一大包找不到重点的日志更容易查。

几种流行的“模型鉴定法”，适合用来做什么

让它画鹈鹕骑自行车。 这能暴露空间关系、遵循要求等方面的错误。但不同模型和配置都可能画出相似结果，画坏了也不能确定是谁画的。给它制定固定评分条件以后，它更适合作为一个质量测试题。

问知识截止日期。 回答可能来自提示词，也可能是模型生成的记忆。开启联网后，模型还能查到训练截止日之后的信息。这两种情况都不能反推出实际路由。

看思考时间和 Token 数。 时间变短、输出减少，可能伴随质量下降，也可能来自更高效的解法、任务差异或指令变化。值得记录，但不能直接拿来识别模型。

凭口吻和某种错误认模型。 可以把它写成待验证的猜测。没有经过验证的识别方法和误判率，就不足以把一次响应归到 Luna。

如果关心“它有没有变差”，用真实任务回归检查去测行为；如果关心“它究竟是谁”，继续查请求与响应记录。两条调查线可以相互提供线索，但回答的是不同问题。

一份可以直接填写的问题报告

只填写能核实的字段。拿不到就写“不可见”。

时间与时区：客户端名称和版本：使用入口 / 请求端点域名：Agent harness 与界面选择的模型：推理强度与速度设置：
调用关系：父任务 / 子任务 / 重试 / 未知请求模型及记录来源：响应模型及记录来源，或注明不可见：明确配置的备用模型或模型覆盖：请求 / 响应 ID：保留给私下支持渠道
任务要求与起始文件：预期通过的验收条件：实际失败现象：复现次数，含成功的尝试：对照期间还修改了哪些设置：
现有记录能够确认什么：尚不能确认什么：

公开报告中去掉认证请求头、Cookie、私有源码和无关提示词。用于追踪的标识和必要诊断片段，可以通过供应方适当的支持渠道提供。完整的浏览器网络存档可能带着大量账户信息，通常没必要直接公开。

如果客户端没有实际模型字段，就在报告中明确写出这一点。运营方可能还能用响应标识继续查。不要把请求里的 model 复制到“实际模型”一栏，制造出本来不存在的证据。

查完以后，怎样决定下一步

如果记录对应明确的子 Agent 配置或备用模型，下一步就是核对这项设置。如果请求和响应确实不一致，又找不到解释，就把这次具体的不一致提交给负责该边界的运营方。如果响应字段拿不到，模型身份仍然没有结论，但你依然可以用受控测试证明某个任务失败了。

在 Agent.Space 中尝试另一种配置时，也保留 Agent harness 与模型的区别：选择该 harness 支持的模型，给出范围明确的任务，保存补丁与验证结果。换配置可能帮助你完成工作，但不能反过来证明之前那次响应用了什么后台。

一份有用的路由报告，最终应该能落到一次具体请求、一个可以核实的判断，以及持有剩余证据的人该查什么。做到这一步，讨论才有继续推进的基础。

资料核对日期为 2026 年 9 月 15 日。诊断模板及父、子 Agent 场景为本文整理的示例。