GPT-5.5 Spud 核查：未发现 OpenAI 官方确认

先说结论：关于 GPT-5.5 “Spud”的传言，至少混在一起了两个问题——OpenAI 是否已经公开发布了这个名字的模型，以及这个模型是否已经证明了更强的长上下文可靠性或指令保持能力。按本次审阅到的材料，证据只能支持一个更谨慎的判断：OpenAI 官方 API 指南、更新日志和 GPT 发布说明指向的是 GPT-5.4；Spud 主要出现在社交帖、视频和非官方页面里 。

对开发者和产品团队来说，这不是咬文嚼字。模型昵称不是基准测试，所谓更大的上下文窗口，也不能自动证明模型能在很长、工具很多、跨多轮的工作流里稳定记住指令。

核查结论一览

说法	核查状态	证据能支持什么
GPT-5.5 Spud 是 OpenAI 官方记录的公开模型	未证实	本次审阅的 OpenAI API 指南、更新日志和 GPT 发布说明材料指向 Latest: GPT-5.4，而不是公开的 GPT-5.5 Spud 模型 。
OpenAI 已发布 GPT-5.5 Spud 的发布日期、模型卡、API 页面或价格	未在本次官方来源中找到	一些非官方页面讨论时间表和能力，但本次源材料中的 OpenAI 官方内容记录的是 GPT-5.4 。
OpenAI 已公开给出 Spud 的长上下文指令保持基准	未证实	本次源材料没有发现 Spud 专属的 OpenAI 系统卡或长上下文基准 。
OpenAI 有关于 GPT-5.4 Thinking 的长 rollout 证据	有，但只适用于 GPT-5.4 Thinking	OpenAI 称 GPT-5.4 Thinking 在有挑战的长 rollout traces 上明显优于早期模型，并介绍 CoT-Control 是一个包含超过 13,000 个任务的评估套件 。

为什么 Spud 传言不能等同于发布

Spud 确实有传播痕迹。它出现在 Facebook、Reddit、X、YouTube，以及一些非官方文章中，内容涉及可能的发布时间、预训练、多模态和能力猜测 。这些材料能说明“有人在讨论 Spud”，但不能证明 OpenAI 已经发布了这个模型。

如果要确认一个模型真的可用，通常更可靠的证据应来自 OpenAI 的 API 页面、更新日志、发布说明、官方公告、系统卡或可复现的基准材料。本次审阅中，这类一手材料明确指向或描述的是 GPT-5.4 。

也要强调：没有公开文档，并不等于证明 OpenAI 内部没有任何代号或实验模型。它只意味着，关于 Spud 的发布日期、API 可用性、价格、记忆能力或长上下文可靠性，在本次材料范围内都还不能被验证。

官方证据真正说明了什么

本次最强的模型证据来自 OpenAI 的 GPT-5.4 材料。OpenAI 的 API 指南标题为 Using GPT-5.4，API 更新日志和 GPT 发布说明也把读者导向 Latest: GPT-5.4 。

OpenAI 的 GPT-5.4 公告称，该模型吸收了 GPT-5.3-Codex 的编码能力，并改进了模型在工具、软件环境、电子表格、演示文稿和文档等专业任务中的表现 。同一公告还称，在 GDPval 对比中，GPT-5.4 达到 83.0%，GPT-5.2 为 70.9%；该基准被描述为测试 agent 在 44 种职业中产出明确规格知识工作的能力 。

最接近“长工作流可靠性”问题的官方证据，来自 GPT-5.4 Thinking，而不是 Spud。OpenAI 的 GPT-5.4 Thinking 系统卡称，在有挑战的长 rollout traces 评估中，GPT-5.4 Thinking 在跟踪和回滚操作、同时保持用户工作不受破坏方面明显优于早期模型；页面还介绍 CoT-Control 是一个包含超过 13,000 个任务的评估套件 。这仍然是 GPT-5.4 Thinking 的证据，不能拿来证明 GPT-5.5 Spud 已经发布或通过了同类测试。

长上下文可靠性，不只是“能塞多少 token”

长上下文可靠性不等于把一大段提示词放进窗口里。真实工作流里，模型可能要记住相隔很远的约束，在多轮或多会话中保持状态，选择正确工具，安全地修改或撤销前面的工作，还要让多个文件、表格或文档保持一致。

相关研究也把这件事当作仍在发展的评估问题。近年的综述仍在讨论如何扩展上下文长度、长上下文建模、架构调整、工作流方法和上下文工程，而不是把长上下文指令遵循视为已经解决 。另有系统性评估论文专门比较长上下文语言模型的优化技术，其中包括模型处理并保留大量信息的场景 。

指令保持也越来越多地被直接测量。LongAlign 提出 LongBench-Chat，用于评估长上下文中的指令遵循 。LifBench 提出 Long-context Instruction Following Benchmark，关注长上下文场景下的指令遵循表现和稳定性 。LocoBench 则面向复杂软件工程工作流，包含 Multi-Session Memory Retention 和多会话开发工作流 。

团队应该怎么测长工作流可靠性

OpenAI 的评估最佳实践建议围绕生产环境设计 eval，并点名“工具选择”这一评估目标；文档还提醒，当单一 agent 架构里加入更多工具和任务时，模型可能更难遵循指令或选择正确工具 。OpenAI 也发布过面向 Codex 长周期任务的开发者指导，说明长时间、多步骤工作确实是产品场景，但这并不是 Spud 的基准 。

一个务实的评估套件，至少应覆盖以下六类行为：

1. 远距离指令保持。 把关键要求分别放在长上下文的开头、中间和结尾，再检查最终输出是否全部遵守。LongAlign 和 LifBench 与这一问题直接相关，因为它们关注长上下文下的指令遵循 。
2. 多会话状态保持。 模拟多次工作会话，包含决策、约束和反悔操作，再检查模型是否能从正确状态继续。LocoBench 的 Multi-Session Memory Retention 框架与此高度相关 。
3. 高负载下的工具选择。 给模型多个看似可用的工具，检查它是否选择正确工具，并传入正确参数。OpenAI 把工具选择列为评估目标，并提示复杂度上升会影响指令遵循和工具调用 。
4. 回滚与修复。 要求模型撤销长任务中的一部分，同时不破坏无关的用户成果。这与 OpenAI 为 GPT-5.4 Thinking 报告的长 rollout 行为相近 。
5. 跨文件、跨文档一致性。 对代码、表格、演示文稿和文档，检查模型是否维护整体约束，而不是只优化最后一轮回答。GPT-5.4 的官方定位涵盖工具、软件环境、表格、演示和文档，LocoBench 则聚焦复杂软件工程工作流 。
6. 提示与输出控制。 在最终回答前，用示例明确格式、长度和风格。OpenAI 的可靠性指南讨论了提示层面的技巧，但这些技巧应补充而不是替代工作流级评估 。

什么证据会改变结论

如果未来出现更强的一手证据，结论才应改变：例如 OpenAI API 或模型页面明确写出 GPT-5.5 或 Spud，更新日志或发布说明列入该模型，OpenAI 发布公告、模型卡或系统卡，或有可复现的长上下文评估结果覆盖指令遵循、多会话记忆、工具选择、回滚修复和跨文件一致性 。

在那之前，最稳妥的说法是：本次审阅的 OpenAI 官方材料没有公开验证 GPT-5.5 Spud；可用证据也没有证明它的长上下文可靠性。对团队而言，应该测试实际可用的模型，而不是把非官方模型昵称当成已经落地的能力承诺。