上周还能独立完成的修改，这周做到一半就停了。刚补充的要求没被处理，Agent 又开始回答前面的问题。你多提醒了几轮，额度也跟着往下掉。
如果连续遇到这些情况，怀疑服务发生了变化很正常。最近围绕 GPT-6 Astra 的“降智”讨论，也已经有了一些值得认真看的证据：OpenAI 公开说明了几类质量问题及其修复，用户则留下了任务失败、输出变化和额度消耗的记录。
但讨论里还有一个更强的说法：GPT-6 请求被大范围替换成了 GPT-5.6 Luna。截至 2026 年 9 月 15 日，我们查阅的公开资料还不足以确认这件事。 输出变差值得追查，后台原因可以暂时保留为未知。
OpenAI 到底确认了什么
OpenAI 的 Tibo Sottiaux 在 9 月 12 日 UTC 发布的说明中提到三类问题：
- 部分旧 Skills 触发过于频繁，或妨碍 Agent 检查工作。
- 一个需要主动加入的上下文管理实验，可能导致提前停止、回答旧消息；实验已停用，估计涉及 4,000–5,000 人。
- 一些配置不当的引擎导致部分流量出现可测得的质量下降，已被移除。
这里的 4,000–5,000 人只对应那项实验，不能当作全部问题的影响人数。说明也没有把问题归因于换成 Luna，没有公布全站质量下降比例。某项修复已经完成，同样不代表后来每一次失败都能归入那个原因，或者都已解决。
所以，看到“OpenAI 承认存在质量问题”可以找到依据；把它继续改写成“官方确认所有 Astra 用户被降级到 Luna”，就超出了原文。
用户反馈里，哪些信息值得留下
OpenAI 社区的讨论帖中，有人提到需要反复强调要求、任务不能完成，以及与发布初期明显不同的体验。这些是用户陈述，论坛使用 OpenAI 域名并不意味着每条结论都得到官方认可。
一份更具体的 Codex GitHub 报告 #44851比较了账户出现容量错误前后的 SVG 生成结果，记录了客户端版本和请求模型。作者也明确指出，自己查看的记录没有揭示实际服务模型。输出更短、图画更差，是值得复查的现象；仅凭这些，还认不出后台究竟用了哪个模型。
至于 Reddit 上关于静默降级的讨论，有人反馈变差，也有人说使用正常。“看起来像 Luna”在其中更多是一种猜测。它可以成为下一次测试的起点，但不能直接充当路由记录。
这些反馈不够完整，也不该因此被忽略。具体任务、发生时间和使用配置，能帮助定位问题。现在缺的是分母：同一时期，在相近条件下有多少次正常请求？没有这个信息，就无法从发帖数量推算整个服务的故障率，更谈不上确认每个账户都受影响。
“变差了”里面，其实混着四个问题
先把自己遇到的情况归到具体一类，后续报告才有可查的对象。
额度掉得快，单独不能证明模型能力下降。回答很快，也不能证明换了小模型。反过来，界面上的模型名字一直没变，并不能保证任务表现始终相同。
Coding Agent 的结果还取决于外围软件：读到了哪些指令，工具有没有正确返回文件，长会话怎么处理旧上下文，修改以后有没有真正验证。模型当然很重要，但用户拿到的是整条执行链的结果。
这也是为什么同一段“帮我修复”的提示词，不一定构成相同输入。前面的会话、项目文件和实际生效的规则都可能不同。
怎样才能进一步核实 Luna 路由的说法
从一次具体请求开始，保留界面选择、实际发出的模型标识，以及供应方响应里可见的模型标识，并用同一个请求或响应 ID 把它们关联起来。父 Agent、子 Agent 和重试请求可能各有一条记录，不能混着看。
如果客户端只记下“请求了什么模型”，就如实写到这一步。直接问“你是什么模型”，得到的仍是一段生成文本，不是服务端记录。模型路由核验指南整理了不同证据能证明什么，也提供了一份可填写的排查模板。
即使真的出现不一致，还要继续确定发生位置：显式设置的备用模型、子 Agent 的单独配置、网关映射和未经解释的供应方替换，含义各不相同。找到选择在哪一层发生变化，比给所有异常起同一个名字更有用。
不必再花一整晚，才能做一次有用的排查
选一个已经失败的任务，保存起始文件、完整任务要求、验收条件和失败产物。不要一边测试，一边不断改提示词，最后只留下偶然成功的那次结果。
然后给排查设一个小预算。在等价的新会话中，保持模型、推理设置、工具和代码基线一致，重复运行，记录是否通过、需要多少人工修补、总共用了多少额度。失败尝试也算进去。少量样本适合发现线索，还不能给整个服务下统计结论。
如果怀疑旧指令拖累了执行，先看实际生效的规则。AGENTS.md 与 Skills 检查文章给了一个范围很小的起点。改指令和换模型最好分开测试，否则即使恢复正常，也不知道哪一步起了作用。
主要症状是额度不够用，可以接着看用量拆解方法；主要症状是代码不可靠，则适合做基于真实任务的回归检查。不需要把整份订阅都烧完，才能提交一份有价值的报告。
问题可以继续调查，项目也要继续做
交付日期通常等不到后台原因完全查明。留下可复现的失败样本后，把下一段边界清楚的工作交给另一个兼容模型，或者换到 Claude Code 等 Agent harness，是合理的应对方式。把新配置记下来，再检查它交付的结果。
在 Agent.Space 中，同一个持久化 Workspace 可以保留项目文件，并由多个 Session 使用；可选模型取决于当前 harness 的支持情况。这让你可以保留项目，把下一项任务交给另一个 Session。需要写文件的对照测试，仍要先准备独立副本或分支：共享 Workspace 不会自动隔离同时发生的修改。
最终有用的产物，是一份能工作的改动，加上一份别人查得下去的问题记录。如果需要换工具继续，用简短的交接说明带走已确认的进展。原问题尚未解释清楚，也不妨碍你先恢复工作。
资料截至 2026 年 9 月 15 日。本文整理公开声明与用户报告，Agent.Space 没有独立复现文中用户的事故；排查方法由我们整理。