Claude Fable 5 重新上线，出口管制解除

1. Claude Fable 5 重新上线，出口管制同步解除

7 月 1 日，Anthropic 宣布 Claude Fable 5 重新部署上线。就在一天前（6 月 30 日），美国商务部正式撤回了 6 月 12 日对 Claude Mythos 5 和 Fable 5 的出口许可要求，解除对这两款模型权重和服务的出口、再出口及境内转移限制。

Fable 5 is back.
— @claudeai

Fable 5 回来了。

不过，重新上线的 Fable 5 附带了更新的网络安全防护措施——部分请求可能被路由到 Opus 4.8 执行，生物/化学分类器依然过于宽泛，会误触发一些基础科学查询的回退。付费用户可在 7 月 7 日前享受促销期访问（上限为每周用量的 50%），之后将转为使用额度（usage credits）计费。

生态反应迅速：Cursor 报告 Fable 5 在其评测中领先但每任务成本最高；Devin 在 Cloud/Desktop/CLI 全平台接入；Perplexity 恢复其作为编排模型；Anthropic 也同步重置了用户速率限制。

社区最大的担忧是定价——有用户报告 Fable 5 在执行代码审查任务时自动生成了 18 个子 Agent，在约 120 秒内耗尽了 5 小时用量块的剩余 50%，让人对其成本可控性产生疑虑。

2. Claude Sonnet 5 正式发布，定位为"最具 Agent 能力的 Sonnet"

同日，Anthropic 发布了 Claude Sonnet 5，基准测试显示其编码和推理能力大幅提升：SWE-bench Pro 63.2%、Terminal-Bench 2.1 80.4%、OSWorld-Verified 81.2%，接近 Opus 4.8 水平但定价更低，对 Free/Pro 计划默认可用。

然而社区质疑声不小。BrowseComp 搜索基准测试的图表被发现在夜间悄然更新——新版坐标轴和数值位置发生实质性变化，引发了对厂商自发布基准图表可信度的讨论。更关键的是，多个用户反映 Sonnet 5 在 high/xhigh 设置下延迟和会话成本均不如 Opus 4.8：有任务 Sonnet 5 耗时 17 分钟消耗 9% 会话额度，而 Opus 4.6/4.8 仅需 3 分钟、消耗 4-5%。

3. 多模型编排成主流策略：Fable 仅用于高价值推理

Fable 5 回归后，开发者社区的讨论焦点不是"模型多强"，而是如何在前沿模型受限的情况下构建多模型工作流。

I've been getting a TON done with Fable today and I'm not hitting rate limits. Wanted to share some tips on how I'm doing that.

1. I only use Fable on "high" effort for now. xhigh is token hungry.
2. I taught Claude Code how to use Codex as a fallback for lots of implementation tasks. GPT-5.5 is incredibly steerable, and Fable can learn how to steer it.
3. I wrote up a big section in my CLAUDE.md on how to prioritize different models for different work when orchestrating workflows and subagents.
4. Things that are unnecessarily token hungry (computer use, codebase analysis, etc), I do with other models and report results back to Fable.
   — @theo

今天我用 Fable 完成了大量工作且没触发速率限制。分享几个技巧：

1. 目前只用 Fable 的 "high" 模式，xhigh 太吃 token
2. 我教 Claude Code 用 Codex 作为实现任务的回退方案，GPT-5.5 高度可操控，Fable 能学会引导它
3. 我在 CLAUDE.md 中写了大段内容来定义不同工作负载的模型优先级
4. 高 token 消耗的操作（Computer Use、代码库分析等）交给其他模型，结果汇报给 Fable

@theo 报告端到端 PR 产出有实质性提升。@omarsar0 也主张团队应设计模型组合策略而非依赖单一前沿模型；@MParakhin 则反对"简单任务预分类器"，认为可靠的路由往往需要先解决任务本身。这一趋势在 Anthropic 自身的 Sonnet 5 + Opus 4.8 分层架构中也得到了印证。

4. Z.ai 发布 ZCode，GLM-5.2 专属 AI 编程 IDE

Z.ai 推出了 ZCode——GLM-5.2 的官方开发环境，这标志着 Z.ai 从单纯发布模型权重转向构建完整产品体验。

Introducing ZCode, the official development environment for GLM-5.2

• GLM Coding Plan subscribers: now 1.5x usage quota in ZCode
• BYOK supported: works with your existing subscriptions and APIs
• Available on macOS, Windows, and Linux
  — @Zai_org

发布 ZCode，GLM-5.2 的官方开发环境。

• GLM Coding 计划订阅者可获 1.5 倍使用配额
• 支持 BYOK（自带密钥），兼容现有订阅和 API
• 支持 macOS、Windows 和 Linux

@kimmonismus 将其定位为"针对 GLM 工作流和长时自主任务优化的 AI 原生编码 IDE"。LangChain 同步发布了 GLM-5.2 编码流程使用指南，@hwchase17 明确指出开发者正在将 GLM-5.2 作为日常主力模型。

5. GLM 5.2 登顶 APEX-SWE 集成任务，开源模型首次在该类领先

基准测试方面，@mercor_ai 报告 GLM 5.2 成为首个在 APEX-SWE 某个类别中领先的开源模型，以 55.3% Pass@1 拿下 Integration 任务第一名，也是所有测试中表现最好的开源模型。Kimi K2.7 紧随其后。

@scaling01 提醒不要过度宣称 GLM 已超越西方顶级前沿模型，但承认编码差距正在快速缩小。

6. vLLM 原生 DSpark 投机解码落地，GLM-5.2 解码提速 1.5×

推理基础设施方面，vLLM 合并了针对 DeepSeek 模型的 DSpark 原生投机解码支持，在 8×B300 上达到约 250 tok/s，接受率优于 MTP 方法。@mgoin_ 发布了 GLM-5.2 DSpark 预览版，宣称解码速度提升约 1.5×。

另外，@jon_durbin 报告了自研 dflash drafter 在 Qwen3-32B 上实现相同硬件下约 50% 的吞吐量提升——开源模型的推理优化正成为竞争的新维度。

7. NVIDIA TwoTower：扩散式语言模型实现 2.42× 生成加速

NVIDIA Research 发布了 Nemotron-Labs-TwoTower，将 30B 模型改造为扩散式语言模型，通过双塔架构并行写入 token。

We took a 30B model and split it in two to write tokens in parallel instead of one at a time.

Introducing Nemotron-Labs-TwoTower: a diffusion language model from NVIDIA Research adapted from Nemotron-3-Nano-30B-A3B. Here's how it works: one half holds the context, the other writes the tokens, with both reusing the pretrained model instead of training a new one from scratch.

We found it kept 98.7% of the original model's quality at 2.42× faster generation.
— @NVIDIAAI

我们把一个 30B 模型拆成两个部分来并行写 token，而不是逐个生成。

发布 Nemotron-Labs-TwoTower：NVIDIA Research 推出的扩散语言模型。一侧保留上下文，另一侧写入 token，两者复用预训练模型而非从头训练。

结果：保持原模型 98.7% 的质量，生成速度提升 2.42 倍。

@LiorOnAI 总结其核心技巧为"冻结上下文模型 + 训练写模型"，避免了全量重新训练的高昂成本。这一架构在生成速度和质量之间的权衡具有工程参考价值。

8. Devin Security Swarm：Agentic MapReduce 安全扫描模式

Cognition 发布了 Devin Security Swarm——基于 Agentic MapReduce 架构的安全漏洞扫描系统。

Introducing Devin Security Swarm

A more cost effective and accurate way to find security vulnerabilities in complex codebases, based on a new architecture: Agentic MapReduce.
— @cognition

发布 Devin Security Swarm——一种基于全新架构 Agentic MapReduce 的、更经济精准的复杂代码库安全漏洞发现方式。

该系统将受限 Agent 分发（fan-out）到整个代码库，汇总发现结果，验证可利用性后再呈现确认的漏洞。Cognition 声称这比替代方案更经济、更准确，某 Fortune 500 企业试点期间在真实仓库中发现并修复了超过一千个漏洞。

@jakejluo 和 @levie 等开发者认为这一模式将推广至大规模文档、代码和知识工作流。Agentic MapReduce 的 fan-out / fan-in 模式正在成为多个产品和技术路线的共同方向。

9. Agent 记忆系统进化：OpenWiki + Weaviate Engram

Agent 的记忆管理成为当日另一个焦点。核心洞见是：Agent 在线程间反复丢失工作上下文，需要一个可维护、可审查的知识层。

LangChain 发布了 OpenWiki（openwiki --init），用于生成和维护 Agent 可消费的代码库文档。Weaviate 推出 Engram，代表了一种新的记忆范式：候选记忆被提取后，先与已有记忆进行转换对比，解决矛盾后再提交——将冲突消解前置到写入阶段，而非每次查询时处理。@bpalit 进一步指出企业场景中 Agent 记忆必须具备治理、权限感知和共享能力。

同时，@omarsar0 介绍的 SkillComposer 将技能选择建模为联合自回归组合问题，在 SkillsBench 上相比无技能基线分别提升 +23.1pp 和 +18.2pp。Deep Agents 新增了递归语言模型工作流支持，@hwchase17 将其与 Agentic MapReduce 的模式联系起来。

10. Together Compute $800M Series C，Etched 推理芯片正式亮相

资本层面，Together Compute 宣布完成 8 亿美元 C 轮融资，估值 83 亿美元（@vipulved）。与此同时，AI 芯片公司 Etched 正式结束隐身模式——完成 A0 流片、手握超 10 亿美元客户合同、累计融资 8 亿美元，首批推理服务器将于今夏出货。Artificial Analysis 同步推出 AA-AgentPerf 新基准，衡量每兆瓦功率下系统可运行的 Agent 数量，为推理硬件提供了新的评估维度。

在开源硬件生态方面，华为发布 OpenPangu-2.0-Flash（92B 总参数 / 6B 激活 / 512K 上下文 MoE），完全开放权重、推理代码和训练细节，宣称完全在华为加速器上训练——这在中美芯片出口管制背景下具有战略意义。OpenPangu-2.0-Pro（505B 总参 / 18B 激活）计划于 7 月发布。

此外，NVIDIA 发布了 Qwen3.6-27B-NVFP4 量化版（约 22GB），对 32GB VRAM 显卡更加友好；社区用户将 Gemma4-31B 扩展至 44B 用于韩语法务/STEM 微调；audio.cpp 为 VibeVoice 1.5B 实现原生 C++/ggml 推理，在 RTX 5090 上以 4.08× 实时速度完成 90 分钟播客生成。

本作品采用《CC 协议》，转载必须注明作者和本文链接