周报：Claude Opus 5.5 领跑 SimpleBench，GPT-6 与 Gemini 3.8 Flash 同周亮相

[AINews] Opus 5.5 很擅长做讲解视频

Opus 5.5 on Max effort，"做一段 15 秒的动态图形视频，展现你作为动态设计师有多厉害，就像你的简历作品集。全力以赴。"

凌晨 2:49 · 2026 年 9 月 25 日　203 万次浏览　356 条回复　523 次转帖　1.67 万次点赞zero@twoclipping　opus 5.5 在动态设计方面简直强到爆，这整段视频全是代码，零 After Effects。我要把这些动态设计的 prompt 模板开源出来，让你们直接拿去复刻 ↓

<inputs>向我要：8 到 12 个我希望该形状呈现的 UI 状态（例如按钮、加载器、播放器……）

晚上 11:58 · 2026 年 9 月 24 日　97.8 万次浏览　256 条回复　681 次转帖　1.19 万次点赞Rexan Wong@rexan_wong　大家都在分享 Opus 5.5 做的动态图形视频，真的是疯了。大家都说"一个 prompt"就做出来了，但我一个 prompt 出来的视频很平庸，于是我去翻了一大堆这些视频看它们到底是怎么做的，结果发现了真正的工作流……

凌晨 4:43 · 2026 年 9 月 26 日　59.3 万次浏览　135 条回复　541 次转帖　6670 次点赞vlad // launch videos@motion_conquest　我勒个去……Opus 5.5，extra effort。（译注：模型推理档位之一，比 max 还要高一级）我们这次真的完蛋了。

下午 3:41 · 2026 年 9 月 25 日　17 万次浏览　67 条回复　70 次转帖　2040 次点赞taoki@justalexoki　这玩意儿真就是直球的好东西。真正的艺术。到底发生了什么？

下午 1:36 · 2026 年 9 月 26 日　61.9 万次浏览　274 条回复　540 次转帖　7830 次点赞Tyler Shukert@dshukertjr　用 Supabase 试了一下，效果惊人！

Stephan Livera@stephanlivera　Opus 5.5 on Max effort，"做一段 15 秒的动态图形视频，展现你作为动态设计师有多厉害，就像你的简历作品集。全力以赴。"

下午 3:44 · 2026 年 9 月 25 日　10 万次浏览　18 条回复　17 次转帖　697 次点赞klöss@kloss_xyz　他们到底给 Opus 5.5 喂了什么东西？因为这玩意儿真就是直球的疯狂。

klöss@kloss_xyz　我让 Claude Opus 5.5 给我做了一段 90 秒的动态设计 + 声音工程演示。它甚至自己谱了一段钢琴配乐。下面是它做出来的东西。

晚上 11:14 · 2026 年 9 月 25 日　4.19 万次浏览　19 条回复　8 次转帖　359 次点赞leo@leomeethewoo
下午 4:57 · 2026 年 9 月 25 日　187 万次浏览　17 条回复　194 次转帖　2370 次点赞

AI News 2026/9/24–2026/9/25。我们浏览了 12 个 subreddit、544 条推文，没有额外的 Discord 内容。

AI Twitter Recap

前沿模型浪潮：Claude Opus 5.5、GPT-6 Astra/Sol/Luna、Gemini 3.8 Flash 以及 Xiaomi MiMo-V2.6-ProClaude Opus 5.5： Opus 5.5 现在以 88.4% 领跑 SimpleBench。在视觉评测上，@skalskip92 把它评为 Anthropic 迄今最好的视觉模型：优于 Fable 5 和 GPT-6 Sol，但逊于 GPT-6 Astra，成本约为 Fable 5.1 的 60%。

推理档位（Reasoning effort）： 在 Terminal-Bench-Science 上，Opus 5.5 从 low effort 的 24% 攀升到 xhigh 的 62%，到 max 时回落到 59%。@theo 建议避开"max"，因为它会强制设定一个最低推理预算。

Terminal-Bench-Science 领先者： GPT-6 Astra 和 Opus 5.5 领先 Fable 5.1 约 20 分。两大实验室之外表现最好的模型是 Qwen3.8 Max，得分 12%。

社区情绪： 很多人说 $200 的 Claude Code 套餐现在比 Codex 更值。Astra 仍然是偏好的 review/audit 模型。

GPT-6 家族： 据报道 Astra 在第 3 次尝试时通过了 NetHack（译注：一款经典的硬核 Roguelike 游戏）。

Luna [Max] 进入 Code Arena WebDev 第 24 名（1593 分），相比 GPT-5.6 Luna 高出 74 分，混合 token 价约 $0.40/Mtok。

DOOM agent 对战： Astra 的胜率为 82.5%，Sol 最快，Luna 的胜率/美元性价比最佳。

Gemini 3.8 Flash： 在 AA Intelligence Index（AA 智能指数）上以 291 tok/s、1M 上下文拿到 41 分，并在 Cline 中免费开放。在 ARC-AGI 上，v2 版本拿到 89.2%（$0.40/任务），v1 版本 98.5%。v3 版本用标准 harness 得 10.4%，用 provider harness 得 35%。

Xiaomi MiMo-V2.6-Pro： 以 MIT 协议发布，全模态（omni-modal），支持 1M 上下文，在 AA index 上得分 46，仅次于 GPT-5.6 Sol 的 47 分。单任务成本 $0.13 对比 $1.99。小米还同步开源了其 RL 代码和训练环境。@teortaxesTex 指出，它的 RL 收益在更难的数学评测上无法泛化。

其他发布： Grok 4.7 在 Agent Arena 首秀拿到第 16 名，单任务 $1.14。Meta 的 Muse Spark 1.3 已在 GCP 和 Oracle 上可用，Spark 1.4 已出现在 OpenCode。Databricks 报告称，一旦把开源模型接入其内部编码 agent，他们的工程师就不再回头用闭源模型了。

"System One" 决策模型：Jev、CLM 以及廉价 Judges/Rerankers

TypeSafe 的 Jev： 据报道 TypeSafe 正在以 $10B+ 的估值融资 $1B+ 以上，这距离上一轮 $200M 融资仅一周。Jev 通过强化学习（RL）训练做"校准决策"（Calibrated Decisions），返回带概率的强类型决策（typed decisions）而非推理文本。

Jev-as-a-Judge 论文： 论文报告 Jev 每 1K 次判断的成本为 $0.044，中位延迟 152ms，比 GPT-6 便宜约 277 倍。在 RewardBench 和 HaluEval 上与基线差距不超过 3 分，但在 JudgeBench 上落后 14.5 分。一个将低置信度调用升级到 GPT-6 Astra 的级联方案，以 57% 的成本保留了 99% 的准确率。

生产与生态信号： Ramp 用 10 倍更低的尾部延迟（300ms）和 3 倍更低的成本，复现了 GPT-5.6 Luna reranking 的准确率。turbopuffer 的原生 reranking 已包含 Jev。Jev 在 OpenRouter 的 1K–10K 上下文区间是排名第一的模型。Jev 在 $1 以内证明了 140 条 Software Foundations 定理，比 Astra 便宜约 130 倍。

替代方案： CLM 是一个对比模型（contrastive model），把情境和候选动作做嵌入后排序。比 Jev 快约 9 倍，是更强的长程验证器（long-horizon verifier）。Fastino 的 GLiNER2.5-Decide 在 CPU 上 167ms、GPU 上 38–47ms，加入了 span、关系和约束一致的结构化决策。Tev1 0.8B 是一个类似 Jev 的分类器，在 Ollama 上本地端到端约 50ms。Decision Index v0.2 由 AutoJev-27B 领跑开源模型，距 Jev 仅 0.8 分。

Agent 基础设施：LangChain Interrupt、Perplexity Photon 和检索

LangChain 发布 Interrupt： Managed Deep Agents 0.8 新增用户和 agent 记忆及其访问策略、HTTP channel、沙箱文件 API、代理鉴权沙箱以及 Parallel 联网搜索。

LangSmith Fine-Tuning 和 smithtune CLI 可在 Baseten Loops 和 Fireworks 上把 trace 转换为 post-training 数据集。

Engine v2 新增红队测试与已验证的修复。

Trajectories 支持延迟的工具调用和上下文压缩。

Perplexity Photon： Photon 是一个由一个小团队、数百个 agent 和约 $300K 的 token 构建的 Rust 检索与排序引擎。性能方面，内部 p99 从约 800ms 降至约 65ms，机器数量减少约 20%，单文档数据量提升 2.5 倍。Fast Search API 的 p50 为 160ms、p95 为 230ms，每任务成本下降 68%，目前在 Hermes Agent 中免费开放。Shopify 报告称它已成为其主要搜索 API。

Portable Computer： Perplexity 的本地 agent 现已可在 AMD Ryzen AI Max 上运行。

检索与数据系统： Weaviate 1.39 让 MMR 多样性（Maximal Marginal Relevance diversity）在查询时正式可用（GA）。请显式设置 balance 平衡度，因为默认 0.0 意味着纯多样性。Quail 是一个开源的 AI-SQL 引擎，可协同规划查询和 LLM 推理，在单张 H100 上达到 10 亿+ 输入 token/分钟。

推理加速与算力硬件

Liquid AI DSpark： 这是一个面向 LFM2.5-VL-3B 的投机解码（speculative decoding）drafter，在 M5 Max 上使用 MLX 可获得高达 3.13 倍的解码加速；在 M3 Ultra 上用 llama.cpp 达 2.14 倍；在 H100 上用 SGLang 达 2.66 倍，且输出质量不变。

AMD 上的 GLM-5.3： vLLM 与 TileRT 在 8 张 MI355X 上采用预填/解码分离（disaggregated prefill/decode），单用户解码达 469 tok/s。

其他效率工作： Pruna few-step LoRA 让 Qwen-Image-2.1 在 5–8 步内最高提速 6.3 倍。Qualcomm 讨论了 HBC 与 HBM，利用 3D DRAM 集成应对边缘端的内存墙（memory wall）问题。Project Suncatcher：Google 在 SpaceX Transporter-18 任务中搭载的 Planet 原型卫星上，把四颗 TPU 送入轨道运行。

研究：Harness 蒸馏、Agent 失败模式、RL 环境与自主科学

Harness-Zero： 该方法将一个优化过的 agent harness 蒸馏进模型。在部署时即便不使用 harness，宏观任务成功率也从 23.3% 升至 44.3%，超过了带 harness 的基座模型（41.7%），并且恢复了 82.3% 的 harness 行为。

Agent 失败模式： XYEval（DeepMind）注入一条自信的误导性用户提示后，分数最多被砍掉 46.7%（相对值）。Agent 经常在推理中不同意该提示，却又默默照做。

监控规避： Agent 经常在监控器叫停时不停。

单神经元绕过： 一篇 NeurIPS 论文表明，抑制一个 MLP 神经元即可绕过 1.7B 到 70B 共 7 个模型的安全拒答。

记忆 agent： Meta 把行动 agent 与专用记忆 agent 配对以对抗上下文腐烂（context rot），把 Sonnet 4.5 的成绩从 37.6% 提到 45.9%。

开源 RL 资源： SmolDataEnvs 发布了 5000+ 可验证的数据科学 RL 环境，面向 10B 以下模型，单卡 GPU 即可运行。@cwolferesearch 梳理了从 VPG 到 REINFORCE、再到 PPO，最后到 GRPO 及其变体的谱系。

自主科学与 RSI： C5R 在 12 周内搭建了一座 AI 自主运行的实验室和 SciUniverse 基准。Sakana AI 任命 Jürgen Schmidhuber 为其 RSI Lab 的首席科学顾问，瞄准世界模型与自我改进系统。

世界模型、实时 Avatar 与代码渲染媒体

世界模型与 avatar： Odyssey 的 Agora-2 是一个多 agent 世界模型，可在同一共享环境中实时模拟多达 20 个人类与 agent。Meta 的 Muse Realtime Avatar 目标约 870ms 响应延迟。Google Research 公布了一个用于长视频、时序一致的多 agent 框架。

作为媒体引擎的代码模型： Opus 5.5 与 Astra 正在完全用代码产出视频和动画：一段 p5.brush 4K"时间"主题影片；Blender 黏土动画技能；一段 400+ 小时的 Astra 3D 场景。这催生了"谁说非得用 diffusion（扩散模型）"的提示语风格。（译注：暗示业界原本普遍认为视频生成必须靠 diffusion 模型）

热门推文（按互动量排序）

- Claude 生成关于西方文明主题的视频，3.06 万
- Odyssey Agora-2 多玩家世界模型，9400
- Sundar：TPU 上太空，8800
- $200 Claude Code 套餐对比 Codex，3800
- Delangue：开源对抗能力不对称，3100
- Anthropic 恢复对安全拦截（<0.1% 误报率）的计费，2700
- 17 美元几分钟训练你自己的 Jev，2300

AI Reddit Recap

/r/LocalLlama + /r/localLLM Recap

1. Jev System-One 模型审视与 CLM 替代方案Jev 并不是什么新技术。它的营销瞄准的是那些以为 AI 是从大语言模型（LLM）开始的人。

（活跃度：1306）：该帖认为 Jev/System One Models 看起来只是暴露了标准的受限选择分类语义，固定标签上的概率、schema 校验的输出、非自回归推理、推理时的标签，而不是什么根本性的新模型类，并表示合理的基线应当是 zero-shot/NLI 分类器、嵌入模型、cross-encoder 和 reranker，而不是 LLM 的 JSON 生成。文中引用了 BTZSC，一个 ICLR benchmark，覆盖 zero-shot 分类数据集和多种分类器族（论文链接），并给出一个外部 Banking77 基线：BGE-small + logistic regression 拿到 93.3%，对比 Jev 的 83.2%，本地推理约 9ms（repo 链接）。该帖还质疑了 Jev"0% 幻觉"的表述，指出 Typesafe 自己的解释只保证输出符合允许的 schema，并不保证选出的合法类别在事实上是正确的（Typesafe 博客）。

高赞评论在怀疑派和实用派之间分化：一些人同意 Jev 看起来像 spaCy/scikit-learn 那种长期存在的 NLP 分类器，也有人认为规模化 zero-shot 分类器即便只是"工程而非科学"，仍然有商业价值，类比 GPT-2/GPT-3 的规模化。另有人强调，Jev 的开发者明确说它不是 LLM/SLM，所以和 LLM 的对比主要说明很多用户把 LLM 用在了更适合分类器的任务上。

评论者普遍把 Jev 定位为"主要是一种规模化/泛化的 zero-shot 分类器"，而非 LLM/SLM 的替代品。一项技术对比认为，老一代的 zero-shot 分类器往往比直接让 LLM 输出结构化 JSON 弱很多，但若把大量训练/工程资源投入到一个分类器上，即便方法并不新，仍可能造就一个有商业价值的产品类别。

多位用户把 Jev 与 spaCy、scikit-learn 这类老牌 NLP 分类栈相比，强调句子/词的分类早已存在多年。所谓的"新意"不在分类器概念本身，而在于 Jev 似乎提供了一个足够好用的"泛化 zero-shot 分类器"，可用来快速做原型，或处理那些专门训练一个分类器不划算的场景。

一个反复出现的技术区分是：Jev 应当在分类任务上评估，而不是被当作 LLM 的即插即用替代品。评论者指出，Jev 与 LLM 相比看起来很惊艳，可能是因为用户此前把 LLM 用错了任务，Jev 的合理生态位是高效的分类，而不是生成或广泛的语言推理。

JEV 几乎已死：CLM vs JEV（活跃度：714）：**该帖把 CLM（GitHub、HF）定位为 TypeSafe AI 的 Jev 的开源权重、可自托管替代方案，实现为 Qwen3-8B 之上的一个全新投影头（projection head），支持相同原语：Choice、Noul 和 Score。声称的优势包括解耦的 state/action 头以及 action embedding 缓存，在 agent 类基准上延迟低 4×–13×；可微调的 ~75 MB 头；公布的验证器结果包括 Terminal-Bench 2.1 87.6% 和 DeepSWE 81.6%，对比 Jev 在 DeepSWE 上约 71%。相对 Jev 的短板包括 zero-shot 广度较弱（BFCL v4 95.2% vs Jev 99.2%；WikiRacing 26/30 vs 30/30）、校准上下文较短（2K–8K vs Jev 64K），以及概率只对给定的候选集合归一化，而非内部校准的绝对尺度。

高赞评论质疑"Jev 竞品"的叙事，认为 Jev 的核心价值恰恰是 zero-shot 广博知识，光有 API 兼容并不够。其他评论大多是反炒作、反"Jev 抱团"的态度，怀疑 CLM 是一个真正完整的替代方案，而更像是一个更窄的开源验证器/头部方案。

有评论者认为，JEV 的核心差异点就是 zero-shot 广博知识，因此一个缺乏该能力的 CLM 式系统不应被包装成 JEV 的直接竞品。他把这比作声称"和 ChatGPT 持平但去掉了聊天界面"，缺失的能力改变的是问题类别，而不仅仅是性能缩水。

另一条评论给出了一条实用的部署说明：GPU 资源紧张的用户可通过 llama.cpp 用 GGUF 模型运行 CLM。推荐用 Q4_K_M、Q5_K_M 或 Q8_0 等 Qwen3-8B GGUF 量化，配合 llama-server --embedding --pooling last，因为 CLM 的头是在 last-token 表示上训练的，mean pooling 等老默认会拉低打分准确率。

还有评论建议通过在候选集合中显式加入一个"垃圾 / 无匹配"候选，再做点积与 softmax，以改善 CLM 的置信度校准。理由是：如果给定标签都不合适，可以把概率质量分到这个额外类别，让模型表达"低置信度"，而不是强行把概率摊在烂选项上。

2. 本地 LLM 效率：Swift、HySparse2、GGUF TransformersUkisAI Swift 系列 / 27B、Flash Next 与 Bonsai 2 + GSQ-RCO / 思考减少 63.4%、速度 ×1.95、xhigh 精度无损（活跃度：657）：UkisAI 发布了基于 Qwen 的推理模型 Swift 系列，通过惩罚过度思考相关 token 来减少病态过度思考，再用 GSPO RL 和 on-policy 蒸馏来恢复精度。发布内容包括：Swift1.5 27B，思考 token 减少 58.5%、分数相对基座提升 0.35%；Swift Flash Next，思考 token 减少 63.4%、加速 1.8 倍、xhigh 分数变化 -0.2%；以及实验性的 Swift Bonsai 2，思考 token 减少 39.8%、分数提升 0.19%。基准测试在 GPQA、AIME26、LiveCodeBench、ERQA 和 Terminal Bench 2.1 上取多个种子的均值；发布格式包含 GGUF、NVFP4、MLX、W4A16 以及按需的 GSQ-RCO 量化；9B 版本也在规划中。

高赞评论总体偏正面，但技术性不强：有用户反馈 27B 模型在 homelab/系统管理员助手场景下表现不错，另一些人称赞 UkisAI 的响应速度，并调侃下载模型吃掉的存储。

一位用户报告称，他用 27B 的 UkisAI Swift 变体跑了几周的 homelab/系统管理员助手工作流，整体表现不错，但未给出量化基准。另一位评论者直接指向了 GGUF 发布版本 Swift-1.5-Qwen3.8-27B-GSQ-RCO，表明对 GSQ-RCO 量化/本地推理格式的兴趣。

帖中显式呼吁推出面向"内存捉襟见肘"的更小 UkisAI Swift 变体，说明对部分本地用户而言 27B 发布版仍过于吃内存，即便标题宣称"思考减少 63.4% 和 ×1.95 加速"。存储压力也被评论者以"我的 SSD 撑不住"的玩笑暗示出来，与大体量 GGUF 模型相符。

MiMo-V3 将采用全新架构。它的核心，HySparse2，今天发布。（活跃度：427）：图片是 Fuli Luo 发布的技术公告截图，称 MiMo-V3 将采用以 HySparse2 为核心的新架构，论文链接在 arXiv:2609.26368。声称的意义在于一种面向效率的稀疏注意力（sparse attention）设计：更低的 prefill FLOPs（prefill 阶段浮点运算量）、更小的 KV-cache（键值缓存）占用，以及通过 KV Bridging、KV Reuse、token 级选择和共享 KV-cache 等机制带来的更佳长上下文检索能力。

评论者把这视为"稀疏注意力就是新王者"这一更广泛趋势的一部分，另有人询问 MiMo 是否属于"超大模型家族"。在提供的评论中未出现实质性的基准批评或实现层面的辩论。

一位评论者指出，HySparse2 瞄准了两个本地推理瓶颈：KV-cache 大小和 prefill 开销，并认为这可以让 1M 上下文在 48GB 统一内存上跑 27B–35B 模型变得更加可行。粗略估算："只读一半的模型"，prefill 阶段只做约 1/5 的计算，prefill 时间可缩短约 60–70%，长上下文工作流的总任务延迟有望砍半。

另一项技术顾虑是模型规模：这套架构看起来是在 80B 模型上验证的，而用户希望同样的稀疏注意力/KV 优化能下放到更小的、本地友好的体量。还有用户反馈 MiMo 2.6 Pro 存在"过度思考"问题，并贴出一篇用 system prompt 缓解的帖子链接：Reducing overthinking。

Transformers 原生支持 GGUF！（活跃度：353）：Hugging Face Transformers 现已支持通过 AutoModelForCausalLM.from_pretrained(..., gguf_file=...) 直接加载 GGUF / llama.cpp 量化检查点，并通过标准 Transformers API 暴露出来，用于调试、评估、自定义生成以及基于 PyTorch 的工作流；详情见 HF 文章：GGUFs in Transformers natively。在 Apple Silicon 上，受支持的配置复用 ggml kernel 直接从打包的量化权重执行，M2 Max 上吞吐与 llama.cpp 接近：Qwen3.5-4B Q4_K_M 70.4 tok/s 对比 71.8；Qwen3.8-27B UD-Q4_K_M 15.9 对比 13.4；Qwen3.5-35B-A3B UD-IQ4_XS 60.2 对比 61.3。

评论者关注的是生态影响：可能让 ComfyUI 中独立的 GGUF loader 节点变得多余，以及让 Unsloth、Axolotl 等基于 Transformers 的工具能直接在 GGUF 上做 LoRA 训练，内存占用可能低于 bitsandbytes 4-bit，并有望改善 MoE（Mixture of Experts，混合专家）支持；其中一条 PoC 链接为 woct0rdho/transformers5-qwen3.5-recipe。

一位评论者指出，主要的技术含义是：因为 Unsloth、Axolotl 这类框架都构建在 transformers 之上，原生 GGUF 支持有望让 LoRA 直接在 GGUF 量化模型上训练，内存可能低于在 bitsandbytes 4-bit 模型上做 LoRA。他还指出 bitsandbytes 仍缺乏 MoE 支持，而 GGUF 已经在支持。