Meta 发布 Muse Spark 1.3，开源权重即将上线

[AINews] Muse Spark 1.3 媲美 GPT-5.6-Sol，Meta Superintelligence 确认跻身最新前沿实验室，训练折扣超 90%

看看这份底气。终于拿出了能和 OpenAI、Anthropic 前沿模型（Opus，不是 Fable……）（译注：「Fable」相对于 Opus 是戏称，暗指水平明显落后于前沿的对照对象）掰手腕的数字，而且承诺做到open weights（开源权重）

开放（!!!）：

Mark Zuckerberg@finkd Muse Spark 1.3 今天开始上线，性能达到前沿水平，便宜到几乎可以忽略不计。这是我们目前编码和 agentic（智能体）方向上最大的一次跃升。可以在 Muse Code 和我们的 API 里试用。

接下来是 🍉（译注：英文社交媒体上常用 🍉 代指「吃瓜」或预告后续爆料，此处指下一波发布），还有即将到来的 Muse Spark 开源权重版本。

7:26 PM · Sep 2, 2026 481K Views 494 Replies 543 Reposts 7.03K Likes他们的定价模型很有意思。只要你同意把数据用于训练，价格能便宜 90% 以上。

AI News for 8/22/2026-8/24/2026。我们翻了 12 个 subreddit、544 个 Twitter，没扫到更多 Discord。

AINews 的官网可以检索往期所有内容。提醒一下，AINews 现在是 Latent Space 的一部分。你可以选择加入或退出邮件频次。

AI Twitter Recap

Agent 工程课程、大纲与开发者实践

斯坦福把 AI 原生软件工程正式立为一门学科@mihail_eric宣布了新版The Modern Software Developer，围绕他所谓的软件工程「2026 metamorphosis（蜕变）」展开。值得关注的信号不止课程本身，还有课程大纲的彻底重置：

2025 年秋季 85% 的内容正在被替换，换成了agent skills（智能体技能）、context engineering（上下文工程）、MCP portals（Model Context Protocol 门户）、agent-ready codebase design（面向智能体的代码库设计）、agentic code review（智能体式代码审查）、security（安全）、parallel background agents（并行后台智能体）以及 software factories（软件工厂）

这类主题。课程还要求学生在 Browserbase、OpenHands、Semgrep、Milvus、Marimo、CrewAI、Warp、Vercel、Unsloth、Anyscale 等合作伙伴的支持下，向真实的开源仓库提交 PR。

第二门斯坦福课程专注从第一性原理构建智能体@Diyi_Yang和@michaelryan207宣布开设CS329Z: Engineering AI Agents，明确以「from scratch（从零开始）」构建智能体为框架。连同 Mihail Eric 的课程一起看，这指向一个更广泛的转向，从「prompting（提示工程）」式的教学法，转向systems-oriented agent engineering（系统导向的智能体工程）

：harness（执行框架）、evaluation（评估）、memory（记忆）、tooling（工具）、orchestration（编排）以及生产环境的约束，而不只是模型怎么用。

从业者讨论正汇聚到一个方向，有状态地分配算力，而非简单路由在一次圆桌讨论中，@HarryStebbings着重介绍了 @EnoReyes 的观点。要把模型能力榨干，光做 routing（路由）是不够的。智能体得understand task state, what just happened, and what comes next（理解任务状态、刚刚发生了什么、接下来会发生什么）

，才能动态分配算力。这与@jerryjliu0的看法一致。

vendor-neutral startups（厂商中立型初创公司）

可以通过端到端优化 harness，有选择地同时用上前沿模型和开源权重模型，在窄任务上反超前沿实验室。

模型架构与推理：Astra 传闻、循环 Transformer、实时服务

「Astra 是循环 Transformer」的传闻大概没有标题看上去那么新@rasbt拆解了关于 OpenAI 传闻中Astra架构的报道，认为所谓的「recurrent depth（循环深度）」或「looped transformer（循环 Transformer）」只是相当温和的架构调整，谈不上独立的突破。他举了Nanbeige 4.2-3B这个开源权重先例。一个22-layer transformer stack reused twice（22 层 Transformer 堆栈被复用两次）

，行为上相当于一个44-layer model（44 层模型）

，参数存储却没翻倍。取舍很清楚：

similar memory footprint（内存占用相近），约 ~2x compute（约两倍计算量）

，token 效率相比标准堆栈只有部分保留。更具实质性的历史参考是Mixture-of-recursions（递归混合）

。其中 learned router（学习得到的路由器）自适应决定每个 token 走多少遍计算，让容易的 token 提前退出，让困难的 token 拿到更多算力。

隐式推理并非循环结构的必然结果@rasbt的第二个重要澄清是，layer reuse（层复用）

does not inherently "obscure chain-of-thought"（说到底并不会「掩盖思维链」）

。它只是把更多计算前移到 token 输出之前的 latent activations（隐层激活）里。如果循环深度让可见的推理痕迹变少，那是因为模型本身需要输出更少的中间 token，而不是循环 Transformer 天然会抑制文本化的 CoT。

服务基础设施的更新继续瞄准实时多模态工作负载@vikhyatk宣布Photon 2.1发布，为实时多模态推理引擎加上了text-to-speech models（文本转语音模型）

和NVIDIA B200 support（NVIDIA B200 支持）

。另外，Baseten 宣布GLM-5.3 Fast上线托管，通过@baseten主打higher TPS（更高 TPS，每秒 token 数）

和实时部署定位。

Agent Harness、技能检索与 RL 后训练工具链

字节跳动 Seed 的 HarnessDev 把智能体评估的重心拉回到 harness，而非仅看任务完成度@omarsar0重点介绍了一篇关于HarnessDev的新论文。这套方法要求模型从一个弱但能跑的 seed（种子）起步，先搭出一个 execution harness（执行框架），第二阶段再借助下游反馈去改进它。两个阶段都按capability and execution-token cost（能力与执行 token 成本）

打分，把效率纳入了目标函数。在six creator LLMs, four domains, and 2,207 held-out downstream instances（6 个创作者 LLM、4 个领域、2207 个保留的下游实例）

上，自动生成的 harness 在code, search, and research（代码、搜索和研究）

上仍然落后于成熟的人工设计系统，但在match or exceed them on writing and ML experimentation（写作和 ML 实验上与之持平或超越）

。关键的细微之处在于，自演化 harness 确实有帮助，但收益是unstable, model-dependent, and only partially transferable（不稳定、依赖模型、且只能部分迁移）

的。

相关生态信号：exo 与递归自我改进工具链@omarsar0还点名了exo harness，把它当作理解 recursive self-improvement（递归自我改进）工作流的有用入口。这背后是对一类框架的兴起，智能体不仅改进输出，还会改进自身的脚手架。

技能检索在总体上看着漂亮，却可能伤害真正被它命中的任务@dair_ai总结了一篇提出Retrieval-Invoked Actual-Use Effect（检索调用的实际使用效应）

的论文。方法是一种 matched-evaluation（匹配评估），把the same task twice（同一任务跑两次）

，一次开启技能，一次不开启，只统计检索实际触发的任务。在 17 个 LLM 的编程和数学测试里，论文发现存在这种情况：检索拉高了总体分，但在被调用任务的子集上反而产生negative same-task effect（负面的同任务效应）

。对维护技能库或工具目录的团队来说，这是个很现实的提醒，别过度解读总体提升。

RL 后训练基础设施正在走向产品化SGLang 团队联合 Baseten 和 NVIDIA Dynamo 一起为Miles做了宣传，一个用SGLang as the rollout inference engine（以 SGLang 作为 rollout 推理引擎）

的 RL 训练框架，目标更快、更可靠的 RL 后训练@sgl_project。

@AravSrinivas另外把Miles形容为open-source RL-as-a-service（开源 RL 即服务）

，进一步强化了一个趋势，可复用的后训练栈正在取代各家自建的内部流水线。

Google Gemini 3.8 Flash Cyber 与 Google 工具链的生产环境摩擦

Google 发布了一款基准亮眼的网络安全专用模型@sundarpichai宣布推出Gemini 3.8 Flash Cyber，定位是 Google 在网络安全方向能力最强的模型，同时保留了Flash-level speed and pricing（Flash 级别的速度和定价）

。公开的数字包括86.2% on CyberGym、47.2% on CWE-Bench for patching，以及在覆盖20 programming languages（20 种编程语言）

的内部漏洞发现基准上达到70%+ success。

与此同时，开发者情绪指向 harness 体验和账号风险的隐忧@theo认为，Google 当前在 harness、code apps、第三方集成，尤其是aggressive bans tied to core Google accounts（与核心 Google 账号绑定的激进封号）

上，开发者体验偏弱。

@QuinnyPig进一步点明了这个问题，指出冲击半径会从 Gmail/Workspace 扩展到Google Cloud accounts associated with the same identity（与同一身份绑定的 Google Cloud 账号）

。Theo 后续对 Gemini 任务中slow, tool-call-heavy coding behavior（缓慢、工具调用繁重的编码行为）

的吐槽（,,）是个例，但确实点出了 benchmark performance（基准性能）和production developer UX（生产环境开发者体验）

之间的差距。

Meta Muse Spark 1.3 与视频/多模态发布周期

Meta 发布 Muse Spark 1.3，主打智能体和编程工作负载@shengjia_zhao推出Muse Spark 1.3，介绍其为 Spark 系列中最强的模型，面向agentic and coding tasks（智能体和编程任务）

，强调longer-horizon work（更长视野的工作）

以及对复杂指令更可靠的遵从。社区反应集中在性价比，包括@alexandr_wang点名它能「for a single dime（花一毛钱）」做到的事，其他用户则在速度和 token 效率上把它和竞品的「xhigh」档位做了对比。

阿里 Wan 3.0 在视频方向的第三方榜单上表现抢眼@ArtificialAnlys报道，Wan 3.0在 Artificial Analysis 榜单上Video Editing with Audio（带音频的视频编辑）

排第

#1，Text-to-Video with Audio（带音频的文本生成视频）

排第

#2，Image-to-Video with Audio（带音频的图像生成视频）

排第

#5。发布定位为all-in-one generation and editing model（一体的生成与编辑模型）

，接受文本、图像、视频、音频、文档、网页作为参考，支持native audio（原生音频）

，可生成最长30 秒 1080p视频。公开预览定价从480p 下 $0.05/s起步，到1080p 下 $0.20/s。

重度参考的多模态 UX 也在变好@imagine宣布支持up to 14 references per video（每个视频最多 14 个参考）

，通过提示中的@-tagging 覆盖图像、声音、角色参考。这是个小但很实用的多资产创作控制界面改进。

开源模型、机器人与热门推文

开源模型的体量还在往上走@percyliang分享说Marin 535B-A23B已经13% through training（完成 13% 训练）

，算力由Jen-Hsun and Lori Huang Foundation资助，跑在CoreWeave上。这条消息的价值不在某个基准，而在于「由慈善算力资助的大规模开源模型训练」这一路径仍然走得通。

物理 AI 与开源机器人平台在缓慢推进@maze_rapid宣布推出Palmimo DevKit，一个桌面级 AI 机器人平台，配开源软件和可替换的 AI「大脑」，目标让开发者写几行 Python 就能控制机器人应用，不必有深厚的机器人背景。现在还早，但作为agent frameworks extending into embodied systems（智能体框架向具身系统延伸）

的案例值得留意。

热门推文（按互动量）

@mihail_eric：斯坦福重新设计的AI-native software developer（AI 原生软件开发者）

课程，课程大纲大幅更替并引入开源协作。

@sundarpichai：

Gemini 3.8 Flash Cyber发布，网络安全基准成绩亮眼。

@rasbt：深度拆解looped transformers（循环 Transformer）

的架构，以及 Astra 传闻为何可能夸大了新颖性。

@Diyi_Yang/@michaelryan207：斯坦福新课程CS329Z: Engineering AI Agents。

AI Reddit Recap

/r/LocalLlama + /r/localLLM Recap

1. Muse Spark 与 Spark-X2.5 开源权重模型

Muse Spark 开源权重即将发布（Activity: 902）：

图是 Mark Zuckerberg 的 X 帖截图，宣布 Muse Spark 1.3 上线，声称在编程、智能体工作流和长上下文任务上有重大改进，并称 Muse Spark 的开源权重「coming soon（即将发布）」。附带的基准表把 Muse Spark 1.3 排在 Muse Spark 1.2 之上，并在智能体、长上下文、编程评估上对标 GPT 5.6 Sol 和 Opus 5。不过 Reddit 帖主表示 Spark 自己的硬件可能跑不动，正在等 Llama 5 或者介于 Glimmer 和 Spark 之间的中间型号。

评论者把这一结果看作多个头部实验室在技术上趋同的证据，一位说已经「no secret sauce（没有秘密配方）」

，前沿差距可能只剩几个月。另一位评论者认为Muse Glimmer被低估了，声称它在非编程任务上胜过Qwen 3.8:27B。

评论者着重提了一个异常高的长上下文成绩：

MRCR 512k–1m拿到98.1%，有人问这是不是说明 Muse Spark 已经基本解决百万 token 规模的「context rot（上下文腐化）」问题。如果数字真实，这个基准会是这帖里最值得关注的声明，因为在512k+上下文上维持稳定的检索/推理质量，仍然是许多开源和闭源模型的主要弱点。

一位用户反馈Muse Glimmer「pretty good（相当不错）」，主观上在非编程任务上优于Qwen 3 8/27B，暗示 Meta 更小/更早的型号在编程基准之外已经具备竞争力。这种比较是个例，但指向的是任务相关的优势，而非笼统的榜单排名。

有评论者质疑展示分数背后的参数量，猜测如果基准属实，Muse Spark 可能是trillion-parameter scale（万亿参数规模）

。这也引出实际部署层面的顾虑：业余玩家本地可能跑不动，但出于政策/合规需要，开源权重对需要非中国模型选项的机构仍有用。

新模型：Spark-X2.5-4B、Spark-X2.5-1.7B（Activity: 301）：

XHToken 发布了 Spark-X2.5 1.7B和4B，看起来是自定义架构而非简单微调。模型卡声称原生1M token 上下文、多语言支持，并在约20T个 token 上完成训练，加上长上下文/后训练阶段。据称架构用了 full attention（全注意力）和 sliding-window attention（滑动窗口注意力）的混合，以压低长上下文的 KV/计算成本，4B的基准被表述为可对标 Qwen 系列约9B的更大模型。运行时支持还没合入上游llama.cpp，依赖一个待合并的llama.cpp PR #27868，或 XHToken 的自定义分支。

1.7B和4B的 GGUF 已可下载。

评论者主要对所报的20T-token 预训练规模印象深刻，尤其对在 5B 以下参数量下声称的原生1M context（1M 上下文）印象深刻。他们对基准声明，特别是4B对标约9B模型，能否在独立测试中站住，态度偏谨慎。

评论者重点强调了 Spark-X2.5 的20T训练 token 规模，这在1.7B/4B的参数量级是反常地大，如果基准可复现，或许能解释4B版对标9B模型的说法。另一个突出的规格是这一体量下的原生1M context（1M 上下文）

，读者认为这点在技术意义上比单纯的基准持平更值得关注。

一位测试者报告用「pi harness」做的早期定性行为。当被问「what model are you（你是什么模型）」

时，模型似乎先调用工具去检查/分析 harness 的名字，再给出回答，体现出 agentic/tool-use（智能体/工具调用）倾向，但也「overthink[ing] a lot（想太多）」。

一次快速推理检查中，它没过「car wash（洗车）」测试。测试者计划再和Qwen3.5 9B做一轮日常使用质量的对比。

2. Qwen3.8 基准与 GGUF 提速

Qwen 要称王？

（Activity: 732）：

图是 Arena AI Code Arena WebDev 排行榜，Qwen3.8-Max-0902 以分排第一，略高于 Claude Opus 5 Max 的分和 Kimi K3 Max 的分。结合帖子语境，这一结果被用来论证 Qwen 通过扩展推理/后训练的规模化，可能正在拉近与更大前沿系统的距离，甚至可能赶在未来的 Qwen 4 发布或可能的开源权重更新之前做到这一点。

评论者对本地/开源权重的 Qwen 变体明显乐观，一位声称本地跑的Q3.8-27B在编码体验上超过了他们付费的 ChatGPT。其他人质疑最强的 Max 模型会不会出开源权重，另一位评论者肯定扩展推理，但指出取舍明显，困难任务要付出hours级的延迟。

一位用户反馈，用PI跑本地Q3.8-27B编码性能很强，声称在编程任务上优于他们之前付费的ChatGPT 5.1。他强调实际的任务跟随能力。给定 wiki 页等相关的.txt文件上下文，模型只需少量修正就能生成可用的代码，同时完全在本地 PC 上跑，保护了数据隐私。

多位评论者聚焦extended reasoning（扩展推理）

，把它当作主要差异化点。一位说Qwen 3.8 Max在他的挑战集上「100% correct（100% 正确）」

，但要花hours才出答案。这把权衡框定为推理密集型工作负载下的准确性/可靠性 vs 极高的推理延迟。

也有人对所展示的基准图表示怀疑，一位评论者说数字看起来「very massaged（明显修饰过）」

，另一位问为什么Fable 5.1没出现在对比中。顾虑在于，模型排名声明可能高度依赖基准选择、报告方法，或被刻意略去的对手。

Qwen3.8-Flash-Next-GGUF 的 MTP 发布（Activity: 671）：****Unsloth 为Qwen3.8-Flash-Next-GGUF发布了 MTP 支持/文件，测试说明和 Unsloth 的llama.cpp分支/PR（unslothai/llama.cpp 的 #144 PR）绑定，GGUF 的使用路径面向本地运行时/OpenAI 兼容端点。一位评论者指出新合并的上游llama.cpp优化（ggml-org/llama.cpp 的 #28123 PR），MTP 吞吐从代码123 tok/s → 183 tok/s、散文83 tok/s → 144 tok/s，作为对比，无草稿时为108 tok/s。在该补丁之前，散文的 MTP 据称比无草稿还要慢。

评论讨论以实操为主。用户问SSD offload是否稳定 /「ironed out（修好了）」，并提到 MTP 文件可能已经放出来好几天了。

一位评论者引用了新合并的llama.cpp优化 PR（ggml-org/llama.cpp 的 #28123 PR），展示了Qwen3.8-Flash-Next-GGUF的 MTP 大幅吞吐增益。无草稿基线为108 tok/s，变更前 MTP 在代码上为123 tok/s，但散文上只有83 tok/s；变更后 MTP 在代码上提升到183 tok/s，散文上提升到144 tok/s。关键技术点是，合并前 MTP 在散文工作负载上可能比常规解码更慢，补丁则让草稿机制在所有场景下都带来收益。

多位评论者仍在跟踪llama.cpp中未解决的运行时/支持细节，包括SSD offload是否稳定、MTP 文件下-shared选项相对非共享模式改变了什么。另一位用户表示自己原本以为所需的 llama.cpp 功能支持还没完全合入，并报告本地性能只有约