发布季从昨天延续至今，今天有传闻中的 Gemini 3.8 Flash，但上个月在扎克的大回归信中承诺的 Muse Spark 1.3，今天绝对配得上头条新闻的胜利。根据 AAII，它现在是世界排名第 3 的模型（！？！）
看看它展现出的自信，终于拿出了与 OpenAI 和 Anthropic 的前沿模型（Opus，不是 Fable）相当的数字……并承诺它也将是开放权重（！！！）：
他们有一个有趣的定价模式：如果你选择加入训练，价格便宜 90% 以上：
2026/8/22-2026/8/24 的 AI 新闻。我们检查了 12 个 subreddit、[544 个 Twitter] 账号，没有进一步的 Discord。[AINews 的网站]让你搜索所有过往期刊。提醒一下，[AINews 现在是 Latent Space 的一个栏目]。你可以[选择加入/退出]邮件频率！
AI Twitter 回顾
智能体工程课程、课程体系与开发者实践
斯坦福正在将 AI 原生软件工程正式确立为一门学科：@mihail_eric宣布推出新版*《现代软件开发者》，核心是他所称的软件工程“2026 年蜕变”。值得注意的信号不只是课程本身，而是课程体系的重置：2025 年秋季 85% 的材料正在被替换，取而代之的主题包括*智能体技能、上下文工程、MCP 门户、面向智能体的代码库设计、智能体式代码审查、安全、并行后台智能体以及软件工厂。该课程还要求学生向真实的 OSS 仓库提交 PR，并得到 Browserbase、OpenHands、Semgrep、Milvus、Marimo、CrewAI、Warp、Vercel、Unsloth 和 Anyscale 等合作伙伴的支持。斯坦福的第二门课程聚焦于第一性原理的智能体构建：@Diyi_Yang和@michaelryan207宣布了CS329Z：工程化 AI 智能体，明确围绕“从零开始”构建智能体来设计。与 Mihail Eric 的课程一起，这表明从“提示词”教学法向面向系统的智能体工程的更广泛转变：测试框架、评估、记忆、工具、编排和生产约束，而不仅仅是模型使用。从业者的讨论正汇聚于有状态智能分配，而非简单的路由：在一个小组讨论提示中，@HarryStebbings强调了 @EnoReyes 的论点：要充分利用模型，需要的不仅仅是路由——智能体需要理解任务状态、刚刚发生了什么以及接下来会发生什么，以便动态分配智能。这与@jerryjliu0的观点一致：供应商中立的初创公司可以通过端到端优化测试框架并有选择地同时使用前沿模型和开放权重模型，在狭窄任务上超越前沿实验室。
模型架构与推理：Astra 传闻、循环 Transformer 与实时服务
“Astra 是一个循环 Transformer”的传闻可能没有标题所暗示的那么新颖：@rasbt 解读了围绕 OpenAI 传闻中的 Astra 架构的报道，并认为所引用的“循环深度”或“循环 Transformer”概念只是一种相当温和的架构微调，而非其自身的突破。他指出 Nanbeige 4.2-3B 是一个开放权重的先例：一个 22 层 Transformer 堆栈被复用两次，实际上表现得像一个 44 层模型，而无需将参数存储翻倍。权衡很直接：内存占用相近，计算量大约 ~2 倍，并且与标准堆栈相比只能部分保留 token 效率。更具实质性的历史参照是 Mixture-of-recursions，其中学习到的路由器自适应地决定一个 token 获得多少次传递，让简单的 token 提前退出，而困难的 token 获得更多计算。隐藏推理并非循环的必然含义：来自 @rasbt 的第二个重要澄清是，层复用并不天然“遮蔽思维链”。它只是将更多计算移入 token 发出之前的潜在激活中。如果循环深度减少了可见的推理痕迹，那是因为模型可能需要发出更少的中间 token，而不是因为循环 Transformer 本质上抑制了文本 CoT。服务基础设施更新继续瞄准实时多模态工作负载：@vikhyatk 发布了 Photon 2.1，为实时多模态推理引擎添加了文本转语音模型和 NVIDIA B200 支持。另外，Baseten 宣布 GLM-5.3 Fast 已可托管使用，通过 @baseten 强调更高的 TPS 和实时部署定位。
Agent Harnesses、技能检索与 RL 后训练工具
字节跳动 Seed 的 HarnessDev 将智能体评估的重心重新聚焦于 harness，而不仅仅是任务完成：@omarsar0 重点介绍了一篇关于 HarnessDev 的新论文，该论文要求模型从一个薄弱但可运行的种子出发，构建一个执行 harness，然后在第二阶段利用下游反馈对其进行改进。两个阶段都按能力与执行 token 成本进行评分，使效率成为目标的一部分。在六个创作者 LLM、四个领域以及 2,207 个留出的下游实例上，生成的 harness 在代码、搜索和研究方面仍落后于成熟的人工工程系统，但在写作和机器学习实验方面达到或超过它们。关键的细微之处在于，自进化 harness 确有帮助，但收益不稳定、依赖模型，且只能部分迁移。相关生态信号：exo 与递归自我改进工具：@omarsar0 还指出 exo harness 是理解递归自我改进工作流的一个有用切入点，表明人们对智能体不仅改进输出、还改进自身脚手架的框架兴趣日益增长。技能检索在总体上可能表现良好，却会损害真正触发它的那些任务：@dair_ai 总结了一篇论文，该论文提出了检索调用实际使用效应（Retrieval-Invoked Actual-Use Effect），这是一种匹配评估方法，将同一任务运行两次，一次启用技能、一次不启用，并且只统计检索实际触发的任务。在编码和数学任务上对 17 个 LLM 的测试中，该论文发现了一些情况：检索提高了总体分数，却对使用检索的那部分任务产生了负面的同任务效应。对于维护技能库或工具目录的团队来说，这是一个实用的警告：不要过度解读总体提升。RL 后训练基础设施正变得更加产品化：SGLang 团队宣传了一场与 Baseten 和 NVIDIA Dynamo 围绕 Miles 举办的活动，Miles 是一个 RL 训练框架，使用 SGLang 作为 rollout 推理引擎，以实现更快、更可靠的 RL 后训练@sgl_project。@AravSrinivas 另外将 Miles 描述为开源 RL 即服务，强化了向可复用后训练栈而非定制内部流水线发展的趋势。
Google Gemini 3.8 Flash Cyber 与 Google 工具链周围的生产摩擦
谷歌推出了一款专门的网络安全模型，并给出了强有力的基准测试声明：@sundarpichai 宣布了 Gemini 3.8 Flash Cyber，将其定位为谷歌能力最强的网络安全模型，同时保持 Flash 级别的速度和定价。报告的数据包括 CyberGym 上 86.2%、CWE-Bench 补丁修复上 47.2%，以及在覆盖 20 种编程语言的内部漏洞发现基准测试中成功率超过 70%。与此同时，开发者情绪指向了测试框架和账号风险方面的担忧：@theo 认为，谷歌目前在测试框架、代码应用、第三方集成方面的开发者体验较弱，尤其是与核心谷歌账号相关的激进封禁。@QuinnyPig 进一步强化了这一担忧，指出影响范围可能超出 Gmail/Workspace，延伸到与同一身份关联的 Google Cloud 账号。Theo 随后对 Gemini 任务中缓慢、工具调用繁重的编码行为的抱怨（1、2、3）虽属轶事，但凸显了基准测试表现与生产环境开发者体验之间的差距。
Meta Muse Spark 1.3 与视频/多模态发布周期
Meta 推出 Muse Spark 1.3，面向智能体和编码工作负载：@shengjia_zhao 介绍了 Muse Spark 1.3，称其为 Spark 系列中面向智能体和编码任务的最强模型，强调更长周期的工作以及对复杂指令更可靠的遵循。社区反应强调了其性价比优势，包括 @alexandr_wang 指出它“只花一毛钱”就能做到什么，而其他用户则在速度和 token 效率上将其与竞品“xhigh”产品进行有利比较。阿里巴巴的 Wan 3.0 在视频领域的第三方排行榜上取得了强劲成绩：@ArtificialAnlys 报告称，在 Artificial Analysis 排行榜上，Wan 3.0 在带音频视频编辑中排名第 1、在带音频文本生成视频中排名第 2、在带音频图像生成视频中排名第 5。该版本被定位为一款一体化生成与编辑模型，可接受文本、图像、视频、音频、文档和网页作为参考，支持原生音频，并可生成最长 30 秒的 1080p 内容。公开预览定价从 480p 每秒 0.05 美元起，最高到 1080p 每秒 0.20 美元。大量参考素材的多模态用户体验也在改善：@imagine 宣布支持每个视频最多 14 个参考素材，涵盖图像、声音和角色参考，通过在提示中使用 @
标签实现，这是面向多素材创意控制的一项虽小但实用的界面改进。
开放模型、机器人技术与热门推文
开放模型工作持续推进：@percyliang 分享称 Marin 535B-A23B 已完成 13% 的训练，算力由 Jen-Hsun and Lori Huang Foundation 资助，并在 CoreWeave 上运行。这篇帖子值得注意之处不在于基准测试，而在于由慈善算力支持的大规模开放模型训练持续可行。物理 AI 与开放机器人平台正缓慢推进：@maze_rapid 发布了 Palmimo DevKit，这是一个桌面 AI 机器人平台，配有开源软件和可替换的 AI“大脑”，设计目标是让开发者用几行 Python 就能控制机器人应用，而无需深厚的机器人专业知识。这还处于早期，但作为智能体框架向具身系统延伸的一个例子具有相关性。热门推文（按互动量）：@mihail_eric：斯坦福改版后的AI 原生软件开发者课程，课程内容大幅更新，并与开源软件协作。@sundarpichai：Gemini 3.8 Flash Cyber 发布，声称在网络安全基准测试中表现强劲。@rasbt：对循环 Transformer 的详细架构拆解，以及为何 Astra 的传闻可能夸大了新颖性。@Diyi_Yang/@michaelryan207：斯坦福新课程 CS329Z：Engineering AI Agents。
AI Reddit 回顾
/r/LocalLlama + /r/localLLM 回顾
1. Muse Spark 与 Spark-X2.5 开放权重模型
（活动量：902）：Muse Spark 开放权重即将发布评论者将这些结果视为多个领先实验室在技术上正在趋同的证据，其中一人表示图片是 Mark Zuckerberg/X 帖子的截图，宣布 Muse Spark 1.3 推出，声称在编码、智能体工作流和长上下文任务方面有重大改进，Muse Spark 开放权重“即将发布”。附带的基准测试表将 Muse Spark 1.3 排在 Muse Spark 1.2 之上，并在智能体、长上下文和编码评估中与标记为 GPT 5.6 Sol 和 Opus 5 的模型具有竞争力，不过 Reddit 帖子的作者指出 Spark 对其硬件来说可能太大，并表示他们在等待 Llama 5 或 Glimmer 与 Spark 之间的中间模型。“没有秘密配方”，前沿差距可能只有几个月。另一位评论者认为 Muse Glimmer 被低估，并声称它在非编码任务上优于 Qwen 3.8:27B。评论者强调了一个异常高的长上下文报告结果：
MRCR512k–1m
在98.1%
，有用户询问这是否意味着 Muse Spark 已在百万 token 规模上有效解决了“上下文腐烂”。如果准确，该基准将是该帖中最具技术意义的声明，因为在512k+
上下文上保持检索/推理质量仍是许多开放和闭源模型的主要弱点。一位用户报告称
Muse Glimmer“相当不错”，在非编程任务上主观上优于Qwen 3 8/27B，这表明 Muse 更小/更早的模型可能已经在编程基准之外具有竞争力。这一比较是轶事性的，但它指向的是任务相关的优势，而非全面的排行榜表现。几位评论者质疑所显示分数背后可能的参数量，并推测如果基准测试准确，Muse Spark 可能达到
万亿参数规模。这引发了实际部署方面的担忧：它可能无法供爱好者本地运行，但开放权重对于因政策/合规原因需要非中国模型选项的组织仍可能有用。
（活动：301）：新模型：Spark-X2.5-4B、Spark-X2.5-1.7BXHToken 发布了 Spark-X2.51.7B
和4B
，显然是一种自定义架构，而非简单的微调，模型卡声称原生1M
token 上下文、多语言支持，并在约20T
token 以及长上下文/后训练阶段上训练。据报道，该架构混合使用全注意力和滑动窗口注意力，以降低长上下文的 KV/计算成本，而4B
的基准测试声明被表述为可与大得多的模型（如 Qwen 级约9B
模型）竞争。运行时支持尚未上游合并到llama.cpp
；它依赖于待处理的llama.cpp
PR #27868或 XHToken 的自定义分支，GGUF 可用于1.7B
和4B
。评论者主要对报告的20T
-token 预训练规模印象深刻，尤其是声称在低于 5B 参数规模下具有原生1M
上下文。对于基准测试声明——特别是4B
匹配约9B
模型——能否在独立测试中成立，人们持谨慎兴趣。评论者强调了 Spark-X2.5 报告的
20T
训练 token 规模，这对于1.7B/4B参数范围来说异常之大，如果基准测试可复现，这可能解释4B变体匹配9B模型的说法。另一个突出规格是在此模型规模下的原生1M
上下文，读者认为这比原始基准测试持平更具技术意义。一位测试者报告了使用“pi harness”的早期定性行为：当被问及
“你是什么模型”时，该模型似乎先使用工具检查/分析 harness 名称再回答，这表明具有智能体/工具使用倾向，但也“过度思考很多”。在快速推理检查中，它未通过“洗车”测试，测试者计划进一步与Qwen3.5 9B比较日常使用质量。
2. Qwen3.8 基准测试与 GGUF 加速
（活动：732）：Qwen 会成为王者吗？该图片显示了一个 Arena AI Code Arena WebDev 排行榜，其中 Qwen3.8-Max-0902 以1,691
分排名第 1，略高于 Claude Opus 5 Max 的1,688
和 Kimi K3 Max 的1,674
。结合该帖子的语境，这一结果被用来论证 Qwen 的扩展推理/后训练扩展可能正在缩小与规模大得多的前沿系统之间的差距，且这一差距的缩小可能发生在未来的 Qwen 4 发布或可能的开放权重更新之前。评论者对本地/开放权重的 Qwen 变体明显持乐观态度，其中一人声称本地运行的 Q3.8-27B 表现优于其付费的 ChatGPT 编程体验。其他人则质疑表现最佳的 Max 模型是否会开放权重，而一位评论者称赞了扩展推理，但指出了权衡之处：困难任务需要数小时的延迟。一位用户报告称，将
Q3.8-27B 与 PI 配合使用时，本地编程性能强劲，声称其在编程任务上优于此前付费的 ChatGPT 5.1 访问权限。他们强调了实际的任务遵循能力：当提供相关上下文（例如 .txt
文件中的 wiki 页面）时，该模型生成的可用代码几乎无需修正，同时完全在本地 PC 上运行并保护数据隐私。多位评论者将
扩展推理视为主要差异化因素：一位评论者表示 Qwen 3.8 Max 在其挑战集上*“100% 正确”*，但可能需要数小时才能得出答案。这构成了准确性/可靠性与推理密集型工作负载极高推理延迟之间的权衡。有人对所提供的基准图表持怀疑态度，一位评论者称这些数字看起来
“非常经过修饰”，另一位则质问为什么 Fable 5.1 未出现在对比中。其担忧在于，模型排名声明可能严重依赖于基准选择、报告方法或被省略的竞争对手。
（活动：671）：****Unsloth 发布了 MTP 支持/文件，用于 MTP released for Qwen3.8-Flash-Next-GGUF Qwen3.8-Flash-Next-GGUF
，测试说明与 Unsloth 的 llama.cpp
分支/PR（unslothai/llama.cpp#144
）以及面向本地运行时/OpenAI 兼容端点的 GGUF 使用路径相关联。一位评论者指出一个新合并的上游 llama.cpp
优化（ggml-org/llama.cpp#28123
），报告 MTP 吞吐量提升：代码上从 123 tok/s → 183 tok/s
，散文上从 83 tok/s → 144 tok/s
，相比之下无草稿时为 108 tok/s
；据报道，在该补丁之前，散文上的 MTP 比完全不用草稿还要慢。评论讨论大多是实用性的：用户询问 SSD offload 是否稳定/“已解决”，并指出 MTP 文件可能已经可用数天了。一位评论者引用了一个新合并的
llama.cpp 优化 PR（ggml-org/llama.cpp#28123），显示 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 是否稳定，以及 -shared
选项相对于非共享模式对 MTP 文件有何改变。另一位用户指出，他们认为所需的 llama.cpp 功能支持仍未完全合并，并报告本地性能很低，仅约 9 tok/s
，这意味着硬件/配置敏感性仍然显著。