GPT-5.5 最该被认真读的不是"又一个更聪明的模型"，而是 OpenAI 公开宣传里第一次把"模型参与数学研究并拿到可验证新结果"作为主卖点。过去 frontier model 发布通常强调 MMLU/AIME/GPQA 这类基准分数，5.5 的叙事被刻意推到了更高层——Ramsey 数是组合数学里几十年才前进一步的核心对象，off-diagonal 渐近结果被 Lean 形式化验证意味着"这条证明已经不是社交媒体级炫技，而是数学社区能接受的投稿形态"。和 4/17 Google Gemini 在 STOC 2026 做自动反馈、4/18 Dive into Claude Code 综述把 agent 抽象为 interface engineering 放在一起，"模型作为研究协作者"在 2026 年春天已经从演示进入产出阶段。

第二条值得注意的主线是"更贵但更省 token"。5.4 之后社区最大的抱怨是 agent 工作流的 token 费用曲线——跑一轮 Codex long-horizon 任务的边际成本接近初级工程师小时费。5.5 的定价策略是把单 token 单价抬高但总 token 用量压低，本质是"更少步数、更少反刍、更少自我修正"。这和 4/19 简报报道的 Atropos（trace-based 动态升级模型路由）走的是同一条经济学：frontier model 的真实成本由"完成一次任务所需 token × 单价"决定，不是单价本身。对企业用户，5.5 的 Codex 场景定价反而更友好，这是给 4 月初 Claude Opus 4.7 的一次明确反击。

第三个需要平衡看待的点：5.5 当前不直接开放 API，Anthropic 发布 Mythos 后 OpenAI 明确表态"cyber 能力需要不同安全栈"，与 4/17 Trusted Access for Cyber 的生态策略一脉相承。所以 API 上的 5.5 会延迟到 cyber 防护被 productized 之后——意味着自建 agent 栈的团队近期仍需以 5.4 为基线，同时关注 5.5 API 发布时是否会附带新的使用限制。

27B dense 打 397B MoE 这条比较方式需要小心读：Qwen 团队对比的不是任意基准，而是特定 coding 评测，并且"激活量约等"（27B dense ≈ 单次推理实际计算量，vs. MoE 的 17B active）。这意味着核心说法不是"参数压缩 14 倍仍更强"，而是"同等推理 FLOPs 下，dense + 新训练 recipe 超过上代 MoE 在 coding 上的表现"。这条叙事如果成立，对开源 MoE 路线是一次真切的压力——过去 18 个月开源社区一窝蜂做 MoE 就是因为认为"稀疏激活是唯一能追上闭源的 shortcut"，Qwen3.6-27B 说明只要数据和训练策略到位，dense 依然有剩余空间。

与 4/17 Qwen3.6-35B-A3B 并列，Qwen 团队现在给出一个明确的 "小 dense / 大 MoE" 双轨：27B dense 面向需要稳定吞吐、简单部署的场景（本地开发、边缘推理、FP8 量化），35B-A3B 面向多模态 agent 场景（10× active size 效能诉求）。对"上游模型栈怎么选"的团队，决策轴从"哪个分数更高"变成"你的瓶颈在吞吐还是在多模态"。结合 HN 热度（948 分、435 条评论）和 unsloth 48 小时 13 万次的 GGUF 下载，社区首选仍是 27B dense——主要原因是 GGUF + llama.cpp 在 MoE 上的支持仍有性能损耗，而 dense 天然友好。

技术细节需要关注两点：（1）image-text-to-text pipeline tag 说明 27B dense 保留多模态输入，不是纯 coder；（2）Qwen3.6-27B-FP8 官方首发量化版同步发布，说明训练阶段已考虑 FP8 鲁棒性。这在 4/17 AMD GAIA、4/19 Driftwood 的 "消费级 GPU / Apple Silicon 本地部署"主线里意义很大——一个 Apache 2.0、FP8 原生、coding 打到 flagship 档的 27B dense 模型，基本是"本地 copilot"场景的新默认基线。

LLaDA 系列是 2025 年扩散语言模型（Diffusion LM）路线里最积极的一支。2.0-Uni 的核心技术贡献是"单目标统一"——所有模态（文本、图像 token、交错多模态）都用 Mask Token Prediction 训练，不再像 2024 年的混合栈那样"文本用 AR、图像用 diffusion、多模态靠 cross-attention 缝合"。这和 4/18 OpenBMB VoxCPM2 选择"tokenizer-free 连续表征 + 扩散-AR 混合"形成有趣对照：两者都在挑战"AR 是唯一主干"的共识，但切入方向完全不同——VoxCPM2 去离散化，LLaDA2.0 反向极端推 token 化但把去噪目标统一。对正在做多模态基础模型的团队，这两条路线定义了未来两年的主要假设空间。

最具工程意义的是 decoder-turbo：50 步 ODE 蒸馏到 8 步，约 10× 推理加速。这解决了扩散 LM 路线最大的短板——推理步数太多。过去 open-source diffusion LM 的现实部署障碍是"每次响应都要跑几十步"，8 步后延迟已经逼近 AR 单 token 生成成本。配合 SPRINT 的 KV cache 复用和自适应 unmask，实际端到端吞吐进入可用区间。思考模式（32 内部步）也值得关注——这是扩散 LM 首次把 "reasoning budget" 参数化到生成过程里，和 AR 模型的 thinking tokens 形成同构概念。

需要冷静看的点：16B / 1B active 的规模仍不足以和 Qwen3.6-27B / K2.6 正面比较 reasoning，而 47GB 生成所需显存门槛也比同等级 AR 模型高。当前定位更像"研究基础设施"——把扩散 LM 的可行性边界推到更靠近产品的位置，但"扩散 LM 取代 AR" 仍是一个需要多轮迭代才能解答的假设。

这篇论文定位到了 agent 成本曲线的一个被长期忽视的黑洞：tool schema 本身。现实部署里，一个接入了 50+ MCP server（Gmail、GitHub、Slack、Figma、数据库…）的 agent，每轮请求仅仅把所有工具的 JSON Schema 序列化进 system prompt 就能吃掉 40-60k token——而模型大概率只用其中 1-2 个工具。这 95% 的开销在 Opus 4.7 / GPT-5.4 这种按 token 计费的 frontier 模型上直接等于 agent 单次任务成本的 30-50%（MCP 用户反复在 HN 讨论过这个问题）。

Tool Attention 的方案是"两级门控"：第一级基于用户 intent 判断候选工具子集，第二级 lazy 加载 schema——只把候选工具的完整签名送入 context，其他仅保留工具名和一句话描述。这和 4/19 Cloudflare Agent Memory 把"长程记忆"下沉到基础设施、4/18 OpenAI Agents SDK v0.14 把 tool origin metadata 加入 SDK 是同一条主线：agent 运行时正在从"把所有东西塞进 context"演化为"把 context 本身作为需要优化的资源"。与今天 GPT-5.5 "更省 token" 的叙事叠加，token 效率的优化维度在 2026 年春天已经铺开到模型、推理、路由、schema 四层。

对正在自建 MCP-based agent 的团队，这是可以立即复用的工程路径——不需要等厂商把它做进 SDK。关键实现点：（1）intent classifier 可以用 7B 级小模型在每轮前置跑一次；（2）schema cache 按 tool × intent 构建，热点工具直接内联；（3）召回率要做 held-out 评估，避免小模型漏选导致 agent 主模型无法调用所需工具。

ml-intern 和 4/18 DeepTutor、4/19 DeerFlow 2.0 放在一起看，"垂直领域 autonomous agent harness"在 2026 年春天已经形成明确产品形态——不再是通用 agent 框架，而是围绕具体工作流（学习、研究、ML 工程）做深度整合。ml-intern 最具差异性的设计是"与 HF ecosystem 深度绑定"：工具面不是泛化的"读网页 / 写代码 / 跑命令"，而是 HuggingFace docs、papers、datasets、repos 作为一等公民工具——这让 ML 研究这一特定任务的召回率大幅优于通用 agent。这也是 4/17 Google Android CLI + Skills + Knowledge Base 的同一思路："给 agent 提供窄而稳的 action surface"比"给它更强的 base model"更能决定落地可靠性。

170k token auto-compaction + doom loop 检测是两个工程细节值得学习：前者是 long-horizon agent 最常翻车的点（context 突破模型限制后静默失败），后者针对 RDI / RLVR 反复揭示的"agent 在失败后会在同一工具上无限重试"失效模式。对正在自建 agent 框架的团队，这两条是可以直接复刻的工程路径。

ml-intern 目前仍在 active development（370 commits、9 贡献者、无 formal release），说明这是 HF 的"边开发边开源"项目——和 DeerFlow 2.0 的完全重写、OpenAI Agents SDK v0.14 的密集迭代节奏一致。这条"公开 main 分支 + 频繁 breaking change" 的发布节奏在 2026 年春天已成 agent 项目常态，对用户意味着"可复用代码"比"稳定接口"价值更高，锁定版本 hash 是选型必做动作。