════ 2026.05.16 ════
今日要点
详细内容
ENTRY 001/010
[ LLM · 推理 · 训练 · RL · 数学 · 科学推理 ]
30B-A3B 模型达到 Olympiad 金牌级推理的统一 recipe
(Achieving Gold-Medal-Level Olympiad Reasoning via Simple and Unified Scaling)
论文提出把 post-trained reasoning backbone 转成严谨 Olympiad solver 的简单统一流程：reverse-perplexity curriculum SFT、从 verifiable rewards 到 proof-level RL 的两阶段强化学习，以及 test-time scaling。作者在 30B-A3B backbone 上用约 340K 条 sub-8K 轨迹做 SFT，再跑 200 RL steps，得到 SU-01，并报告其能在 IMO 2025、USAMO 2026、IPhO 2024/2025 级问题上达到金牌水平。
这篇工作的价值在于它不是只报告“某个大模型会做奥赛题”，而是把 Olympiad reasoning 的训练 recipe 拆成可复用的三段：先用 reverse-perplexity curriculum 建立严谨 proof-search 与 self-checking 行为，再用可验证奖励把解题方向推起来，最后切到更细的 proof-level RL 处理证明质量。这个流程对中等规模 MoE backbone 尤其重要，因为 30B-A3B 级别意味着推理能力不一定只靠参数规模堆出来。
超过 100K token 的稳定 reasoning trajectory 是另一个关键点。当前很多数学推理系统在长链条中会出现 proof drift、重复搜索或自洽性坍塌，SU-01 的训练目标显式把“长程证明搜索”作为行为塑形对象。对研究团队来说，这比单点 benchmark 分数更可迁移：如果 recipe 能迁到代码验证、科学假设生成或形式化证明，Olympiad solver 就会变成长程 reasoning agent 的训练样板。
ENTRY 002/010
[ 视频生成 · DIFFUSION · 蒸馏 · 实时交互 · 世界模型 ]
Causal Forcing++：1-2 步 frame-wise AR diffusion 蒸馏实时视频
(Causal Forcing++: Scalable Few-Step Autoregressive Diffusion Distillation for Real-Time Interactive Video Generation)
Causal Forcing++ 面向实时交互视频生成，把 few-step autoregressive diffusion 推到 frame-wise 1-2 sampling steps。论文指出关键瓶颈在 AR student 初始化，并用 causal consistency distillation 从单个 online teacher ODE step 学习 AR-conditional flow map，避免预计算完整 PF-ODE trajectory；结果在 frame-wise 2-step 设置下超过 4-step chunk-wise Causal Forcing，并把首帧延迟降低 50%、Stage 2 训练成本约降 4x。
视频生成正在从“离线生成一段 clip”转向“边交互边 rollout”。这要求模型不只是画质好，还要低首帧延迟、streaming 输出、可被用户操作或环境动作持续条件化。Causal Forcing++ 把 chunk-wise 4-step 再往下压到 frame-wise 1-2 step，本质上是在为游戏、机器人模拟、可交互 world model 做推理路径改造。
causal CD 的工程意义是减少蒸馏数据负担。传统 ODE distillation 需要预先生成和存储 trajectory，成本高且不易扩展；这里用相邻时间步的 online teacher ODE step 直接提供监督，让初始化更贴近 AR 条件流。它和 5 月份连续出现的 AnyFlow、Forcing-KV、RAVEN 等视频扩散加速工作形成同一趋势：视频模型竞争点不再只是 base model 质量，而是“同一质量下多少步、多少延迟、能否长 rollout”。
ENTRY 003/010
[ AGENT · RL · 后训练 · GRPO · SELFDISTILLATION ]
SDAR：给多轮 agent RL 加 gated token-level self-distillation
(Self-Distilled Agentic Reinforcement Learning)
SDAR 针对多轮 LLM agent 后训练中 trajectory-level reward 太稀疏的问题，把 On-Policy Self-Distillation 作为 gated auxiliary objective 接到 RL 主干上。它用 detached token-level signals 形成 sigmoid gate，强化 teacher-endorsed positive-gap tokens，同时软化 negative teacher rejections；在 Qwen2.5 与 Qwen3 系列上，ALFWorld、WebShop、Search-QA 分别相对 GRPO 提升 9.4%、10.2% 与 7.0%。
agent RL 的核心痛点是 reward 太晚。一次 WebShop 或 ALFWorld 轨迹可能包含几十步观察、思考、检索和动作，最后成败只能粗粒度告诉模型“这条轨迹好不好”。SDAR 的思路不是替代 RL，而是在 RL 旁边加一个受控的 dense supervision：teacher branch 有 privileged context，但它的 token-level 指导不能被无条件相信，所以要用 gate 筛掉不可靠的负向拒绝。
这类方法会影响 agent 训练栈的默认形态。过去很多 agent 后训练只是在 GRPO / PPO 外层换 reward 或环境，SDAR 显示更细粒度的 token-level 监督依然有空间，前提是承认 teacher signal 在多轮交互中会不稳定。对生产 agent 来说，这对应一个直接问题：模型不是不会做单步工具调用，而是在长轨迹里逐渐偏离目标；能否稳定利用局部正确的 teacher trace，会决定多轮任务的可训练性。
ENTRY 004/010
[ OPENAI · 语音 · REALTIMEAPI · AGENT · 工具调用 · 多语言 ]
OpenAI 发布 GPT-Realtime-2、Realtime-Translate 与 Realtime-Whisper
(Advancing voice intelligence with new models in the API)
OpenAI 在 Realtime API 中发布三类实时语音模型：GPT-Realtime-2、GPT-Realtime-Translate 与 GPT-Realtime-Whisper。GPT-Realtime-2 支持 GPT-5-class reasoning、parallel tool calls、tool transparency、128K context、可调 reasoning effort；OpenAI 报告其在 Big Bench Audio 上比 GPT-Realtime-1.5 高 15.2%，在 Audio MultiChallenge 上高 13.8%，Zillow 早测中 call success rate 从 69% 提升到 95%。
这次更新把 voice agent 从“低延迟聊天”推进到“实时执行任务”。语音产品过去常被拆成 ASR、LLM、TTS、工具调用四段 pipeline，每段都能工作，但端到端体验容易被打断：用户插话、纠正、切换目标时，系统要么沉默等待，要么丢上下文。GPT-Realtime-2 把 preamble、parallel tool calls、audible tool transparency 和 128K context 放进同一个实时模型接口，说明 OpenAI 正在把 voice agent 当作完整 orchestration runtime，而不是音频版聊天框。
Realtime-Translate 和 Realtime-Whisper 则补齐两个生产常见需求：跨语言客服与直播式转写。70+ input languages 到 13 output languages 的 live translation，加上每分钟定价模型，会让很多原本依赖批处理翻译或离线字幕的应用转向同步交互。真正要验证的是复杂业务场景下的错误恢复、合规提示和 tool side effect 控制；语音 agent 一旦能直接执行操作，安全边界就必须和传统 API agent 一样严肃。
ENTRY 005/010
[ ANTHROPIC · AGENT · MEMORY · 评估 · 多AGENT · 平台 ]
Claude Managed Agents 加入 dreaming、outcomes 与 multiagent orchestration
(New in Claude Managed Agents: dreaming, outcomes, and multiagent orchestration)
Anthropic 在 Claude Managed Agents 中推出 dreaming research preview，并把 outcomes、multiagent orchestration、webhooks 开放给开发者。dreaming 是一个定期过程，会回看 past sessions 与 memory stores，抽取 recurring mistakes、shared preferences 与 converged workflows；outcomes 允许用 rubric 定义成功标准，由独立 grader 在独立 context 中评估结果；multiagent orchestration 支持 lead agent 拆分任务并协调多个 subagents。
dreaming 的名字很营销，但技术问题非常实际：长期运行的 agent 不能把所有旧 transcript 都塞进下一次 context，也不能完全靠人手维护 memory。它相当于把 memory consolidation 做成平台能力，在任务间隔期清洗、重组和升级 memory。这个设计与 5 月份 agent memory 论文密集出现的方向一致，只是 Anthropic 把它放进了托管 agent runtime。
outcomes 可能比 dreaming 更接近企业落地。传统 prompt 要求开发者一步步指定 agent 怎么做，outcomes 则把接口上移到“成功长什么样”，再用单独 grader 避免 agent 自评污染。组合起来看，Managed Agents 的竞争点已经不是单次 Messages API 调用，而是 memory、eval、subagent routing、webhooks 与托管执行环境。代价也很清楚：团队会把 agent 的操作历史、评价标准和协作结构一起绑定进平台，迁移成本比模型 API 更高。
ENTRY 006/010
[ GOOGLEDEEPMIND · ALPHAEVOLVE · 科学发现 · 代码AGENT · 优化 ]
AlphaEvolve 从算法发现走向 Google 基础设施与科学优化
(AlphaEvolve: How our Gemini-powered coding agent is scaling impact across fields)
Google DeepMind 回顾 AlphaEvolve 的实际影响：在 genomics 中改进 DeepConsensus，使 variant detection errors 降低 30%；在 AC Optimal Power Flow 中把 GNN 可行解率从 14% 提升到 88% 以上；在 natural disaster risk 预测的 20 个类别上整体 accuracy 提升 5%；在 quantum circuit 优化中给 Willow processor 找到比传统 baseline 低 10x error 的电路；并已用于下一代 TPU 设计和 cache replacement policies。
AlphaEvolve 的重要性在于它不是单个 coding benchmark，而是“用 coding agent 搜索算法空间”的跨领域实例。DeepMind 列出的案例覆盖 genomics、电网、地灾、量子电路、数学与 TPU 设计，说明 Gemini-powered coding agent 正在从写代码转向自动发现可执行算法和优化策略。尤其是 AC Optimal Power Flow 从 14% 到 88% 可行解率这类数字，说明它解决的是工程系统里长期依赖专家调参的约束优化问题。
这类系统与普通 coding agent 的区别在于 closed-loop evaluator。AlphaEvolve 不是生成一段看似合理的代码，而是持续提出候选程序、跑评价、保留改进、再变异搜索。对企业来说，可迁移方向不是“让 agent 接管所有研发”，而是找到可自动评分的内部优化问题：调度、缓存、压缩、编译、路线规划、实验设计。只要 evaluator 足够可信，模型就可以把大量人类试错转为机器搜索。
ENTRY 007/010
[ MICROSOFT · CYBERSECURITY · AGENT · 漏洞挖掘 · 多模型 · BENCHMARK ]
Microsoft MDASH：100+ specialized agents 的漏洞发现 harness
(Defense at AI speed: Microsoft’s new multi-model agentic security system tops leading industry benchmark)
Microsoft Autonomous Code Security 团队发布 multi-model agentic scanning harness，代号 MDASH。该系统编排 100+ specialized AI agents 与 frontier / distilled model ensemble，用于发现、辩论并证明可利用漏洞；在私有 test driver 中找到 21/21 planted vulnerabilities 且 zero false positives，在 clfs.sys 五年 MSRC cases 上 96% recall、tcpip.sys 上 100% recall，并在 CyberGym 1507 个真实漏洞 benchmark 上拿到 88.45%。
MDASH 与 Mozilla Mythos harness 形成了同一条生产化曲线：AI 安全能力不再表现为单个模型读一段代码，而是一个面向 codebase 的扫描、验证、辩论和复现系统。Microsoft 选择 multi-model ensemble 与 100+ specialized agents，说明漏洞发现被拆成了多个子任务：定位 suspicious pattern、构造 proof-of-concept、交叉验证 exploitability、过滤 false positive。这里的关键不是“模型聪明”，而是系统能否把错误假设快速淘汰。
公开数字里最值得看的是 CyberGym 88.45% 与 private driver zero false positives。安全团队最怕的是大量不可复现 findings 淹没 triage，所以 false positive 控制往往比 recall 更影响采用。下一阶段的竞争会落在两个层面：一是 benchmark 是否覆盖真实大型代码库和现代 sandbox / IPC / kernel 边界；二是 AI 找到漏洞后，组织有没有 patch、regression、release 与 disclosure pipeline 接住。
ENTRY 008/010
[ GOOGLE · GEMINIAPI · RAG · EMBEDDING · 多模态 · 引用 ]
Gemini API File Search 加入 multimodal RAG、metadata 与 page citations
(Gemini API File Search is now multimodal)
Google 扩展 Gemini API File Search：支持 image + text 共同索引，底层由 Gemini Embedding 2 驱动；新增 custom metadata，可用 department: Legal、status: Final 等 key-value label 在 query time 过滤；新增 page-level citations，把回答中的 indexed information 绑定到原始 PDF 页码，帮助用户验证出处。
这条更新看似是开发者工具小改，但它击中的是生产 RAG 的三个老问题：多模态资料不能混搜、企业资料缺少结构化过滤、答案无法精确回到原文页码。Gemini Embedding 2 让图片和文本进入同一检索空间，适合设计资产、科研图像、工程图、图表与文档混合的知识库；metadata filter 则避免把所有文件丢进一个语义池后靠模型猜范围。
page citations 的意义在于把 RAG 从“能回答”推进到“能审计”。法律、财务、科研、医疗场景里，用户需要知道答案来自哪一页，而不是只看到一段流畅总结。与本周 DCI 论文对 vector DB 接口的质疑相对照，Google 的路线是继续把托管 File Search 做得更细：不是只给 top-k chunk，而是把 multimodal indexing、过滤和可验证引用包装成平台能力。
ENTRY 009/010
[ QWEN · LLAMA.CPP · MTP · SPECULATIVEDECODING · 本地推理 · GGUF ]
Qwen3.6 MTP 在 llama.cpp 社区落地，本地 speculative decoding 加速进入主线
(Qwen3.6-27B MTP via llama.cpp PR #22673)
社区围绕 Qwen3.6 的 Multi-Token Prediction head 推进 llama.cpp PR #22673，把 mtp spec type、共享 hidden states 的 target / MTP head pipeline，以及 Qwen3.6 27B 和 35B-A3B 支持带到本地推理工具链。社区测试显示 RTX 5090M 上 Qwen3.6-27B MTP GGUF 从 35 tok/s 到 78 tok/s，Strix Halo 上 Qwen3.6-35B-A3B q8 从 40 到 70 tok/s。
Qwen3.6 在本地社区的热度不是单纯因为模型分数，而是它的架构特性开始被运行时吃到。MTP head 让模型在一次 forward 中预测多个未来 token，serve 时再由主模型并行验证，接受正确 token、丢弃错误 token。vLLM 早已支持类似配置，但 llama.cpp 支持意味着 consumer GPU、Windows、本地 coding agent 这些场景也能拿到 speculative decoding 的收益。
社区数字需要谨慎看，因为硬件、quant、context、batch 和 prompt 都会影响 tok/s；但“2x 级别”加速信号已经足够有工程意义。对于本地 agentic coding，速度不是体验小优化，而是决定 agent 是否能多轮试错、读文件、改代码、跑反馈。Qwen3.6-27B / 35B-A3B、Unsloth GGUF 与 llama.cpp MTP 的组合，正在把“本地模型能不能工作”推进到“能否在真实开发节奏中足够快”。
ENTRY 010/010
[ CODINGAGENT · OPENSOURCE · VSCODE · PRODUCTHUNT · 开发者工具 ]
Kilo Code v7 for VS Code：Product Hunt 本月开源 coding agent 信号
(Kilo Code v7 for VS Code)
Kilo Code v7 for VS Code 在 Product Hunt 5 月榜单中排名靠前，定位为开源 AI coding assistant。v7 重建 VS Code extension，强调 parallel agents、diff reviewer、multi-model comparison、subagent delegation 与跨平台 session continuity；Product Hunt 页面显示 Kilo Code 已有 3M+ users、30T+ tokens processed，并在 5 月 5 日拿到当日与当周第一。
Product Hunt 信号通常不能直接等同技术突破，但 Kilo Code v7 有明确工程趋势：coding agent 正在从单聊天窗口变成 IDE 内的多 agent 工作台。parallel agents、diff reviewer、multi-model comparison 这些功能说明用户不只需要“让模型写代码”，还需要并行探索、比较输出、审查 diff、保留可回滚的编辑路径。
这和 Claude Code、Codex、OpenCode、Cline SDK 等工具形成同一竞争带。未来 IDE agent 的差异化大概率不在“能否调用模型”，而在本地文件权限、任务拆分、diff 审批、模型路由、上下文压缩、测试反馈和团队审计。Kilo Code 以开源形态抢这条路线，值得关注的是它能否把高频 token 消耗和多模型调用做成可控成本，而不是只把 agent 数量堆起来。
其他值得关注