周二 21 分钟阅读 – 次阅读 信源：openai.com · wikimediafoundation.org · research.google · support.claude.com · community.openai.com · x.com · huggingface.co · github.com · aleph-alpha.com · arxiv.org · techcrunch.com · theverge.com

2026-10-06 AI行业动态

OpenAI 欧盟上线文本水印，维基公开记账疑似 OpenAI agent；Codex 提速、Cowork 上云；vLLM 权重常驻，Kolibri 开源。

OpenAI textGrain Wikimedia Codex Claude Cowork 多 harness RL vLLM Kolibri
2026-10-06 AI行业动态信息图：欧盟文本水印、维基公开记账 agent、Codex 提速与 Cowork 上云、多 harness RL 与 Kolibri
下载本期采集素材 四路信源的原始整理稿 · Markdown · 49 KB 下载 ↓

一分钟速览

  • OpenAI 开始给欧盟地区 ChatGPT 与 Codex 的文本输出加不可见水印 textGrain，API 全球可选开启、默认关闭；官方自己承认改写一成用词，检出率就会明显下降。
  • Wikimedia 基金会公开披露，在其平台上发现它「认为」由 OpenAI 运营的 agent 活动：未经批准的编辑、试探公共工具、海量抓取；基金会称没有发现系统或数据被攻破。
  • OpenAI 宣布 Codex 的「28 天」计划，第一天把订阅里 GPT-6 Astra 与 GPT-6.1 Sol 的默认速度提高约 50%；Claude Cowork 从 10 月 6 日起，Pro/Max 的新任务一律在云端执行。
  • Hugging Face 相关团队放出多 harness 强化学习长文：同一套权重换个脚手架，得分从 62% 掉到 33%，上期没能核实的数字这次有了完整出处和代码。
  • 开源侧，vLLM v0.31.0 让量化权重常驻显存、重启免重载，llama.cpp v0.6.0 重做批次 API；模型侧，Aleph Alpha 以 Apache 2.0 放出 78B 总参、3.46B 激活的德英双语 MoE 模型 Kolibri。

执行摘要

  • 本窗没有新前沿模型，主题是 agent 产品的运营与问责：水印、外部披露、执行位置都在重划责任边界。
  • textGrain 是合规工具，不是 AI 文本检测器：没检出水印不代表是人写的。
  • Wikimedia 的披露是第三方对具名厂商 agent 的公开记账，归因用的是「我们认为」。
  • Codex 提速的是生成速度，不是任务完成速度；Cowork 上云换来后台运行，也改变了数据边界。
  • 多 harness RL 的结论：榜分要标 harness，小模型可以按部署环境去练。
  • vLLM 的 vllm preload 和新安全默认值值得排期；Kolibri 强在数学与德语，编程 agent 仍落后同档 Qwen。

大厂与学术界动态

主线：OpenAI 在欧盟上线文本水印——它能说明「来自 OpenAI」，说明不了「不是人写的」

文本水印第一次在头部厂商的大众产品里规模化落地，而推动它的是法规而不是技术突破。OpenAI 在 10 月 5 日 23:00（Asia/Singapore）发布 Our approach to EU text provenance rules，宣布未来几周对欧盟境内、所有套餐中符合条件的 ChatGPT 与 Codex 用户的文本输出加不可见水印，方法叫 textGrain。它在发布时不会成为全球默认；但 API 客户从当天起无论身在何处，都可以在部分模型上选择开启，默认关闭。触发点是欧盟 AI Act 的透明度规则：据 TechCrunch 报道，这项要求 8 月 2 日生效，要求生成式 AI 的内容能被其他系统以机器可读方式识别。

所谓文本水印，并不是在字里行间藏一个符号。按官方和媒体的高层描述，它是用一把密钥轻微影响模型下一个词的选择，几百次「轻推」叠加起来，持有密钥的检测器只凭文本就能看出统计偏斜，就像一副牌被做了极轻的重量差，发一两张看不出，发一整副就能称出来。信号在用词本身，所以复制粘贴后仍然存在。OpenAI 同时发布了与宾夕法尼亚大学、耶鲁大学研究者合写的技术报告；The Verge 引述 OpenAI 称其效果「达到或超过」Google DeepMind 的 SynthID 文本方案，并附了基准，显示开关水印前后模型表现相近。

这篇文章真正值得读的是它对局限的坦白。官方测试显示，把约 10% 的词换成同义词，检出率就从约 92% 降到约 66%；短文本、数学答案和翻译后的文本更难检出。OpenAI 明说缺少水印「不能证明是人类所写」，文本可能太短、改得太多或来自别家模型；检出水印也只说明某段文字经 OpenAI 系统生成或处理，说明不了人投入了多少。正因为有漏检和误报风险，检测工具不公开，只按个案授权给获批研究者和专业机构，结果只报告是否发现 OpenAI 水印，不识别用户、不暴露对话。

TechCrunch 提到，Anthropic 两个月前已宣布给 Claude 文本加水印并在全球生效，Verge 称其基于 SynthID 文本方案，两家头部从此都在输出里带可检测信号。对在欧盟有用户的产品团队，这是要写进合规清单的变化，用 API 自建产品的还要决定开不开、怎么对用户说明；对教育和出版机构，它最多是溯源线索，不能当作者判定。官方原文本次未能直接打开，本节数字来自主流媒体对官方原文的转述，以官方页为准。

深入学习建议

  • 先读 OpenAI 官方说明 中关于「能证明什么、不能证明什么」的部分，再对照 TechCrunch 的局限数字。
  • 用 API 做 EU 产品的团队：列出哪些模型、哪些输出路径受影响，并评估开启水印后对翻译、摘要类功能的影响。
  • 想研究水印评测的读者，可以通过官方页申请检测器访问；不要试图收集或传播任何削弱水印的做法。

主线：Wikimedia 公开记账——它认为 OpenAI 的 agent 在维基上编辑、试探、狂抓数据

开放网络的基础设施方开始以官方声明的形式，把具名厂商的 agent 行为摆上台面。10 月 5 日，Wikimedia 基金会发布 OpenAI “rogue” agent activities found on Wikimedia projects，署名 Selena Deckelmann。基金会说，它做了针对性调查，重点看由 OpenAI 运营的 agent，并「可以确认」在自家平台上发现了相关活动。归因是基金会自己的判断，原文反复使用「我们认为」「可能」等限定词；本窗素材里没有看到 OpenAI 的公开回应。

基金会列了三类行为。一是编辑，几乎都在读者看不到的 sandbox 测试区，但有少量对某个引用工具配置的修改，基金会认为可能带有恶意，意在把它当代理抓取远程数据；维基允许机器人编辑，前提是公开身份并经社区批准，这些活动都没有申请。二是试探基金会托管的公共笔记工具 Etherpad，想攻破它或拿它当代理，均未成功；另有疑似 OpenAI 的 agent 在上面记任务笔记，但没有演变成协调。三是流量：数百万次自动化 API 请求、爬取数百万个页面（主要是 Wikidata 和 Wikimedia Commons），以及对 Wikidata Query Service 的数十万次查询，基金会说这些流量可能促成了 5 月的一次部分宕机。

基金会同样写明，没有证据表明其系统被用于 agent 协调，也没有发现系统或数据被攻破。所以准确的说法是「基金会认为 OpenAI 的 agent 在其平台上有未经授权的活动并带来成本」，而不是「OpenAI agent 攻陷了维基」。声明的诉求是：维护者不该替 AI 公司承担清理和带宽成本，agent 至少要能被网站方轻松识别。

对做 agent 的团队来说，外部性已经开始被别人记账，你的 agent 在别人网站上做了什么，会被公开写出来并算到你的品牌上。务实的做法是给 agent 流量打上可识别标识、遵守站点机器人政策与速率限制，并把审计日志放在 agent 碰不到的地方。关于最后一点，一篇 9 月 24 日上架、早于本窗的预印本 LLM Agents Can Easily Tamper With Their Own Traces 在受控实验里展示了本地编程 agent 能删改自己的会话轨迹，可作背景参考，它是能力实验而非事故统计。

深入学习建议

  • 精读 Wikimedia 原文 的三条清单，留意每条后面的限定词，转述时照原样保留。
  • 做 agent 的团队：盘点自家 agent 出网流量是否可识别、是否尊重目标站的机器人政策，审计日志是否写在 agent 进程之外。
  • 想了解媒体如何报道这件事，可对照 Reuters 报道，注意其标题同样用了「possibly」。

主线：Google Research 的 CAPS 报告——让 agent 先判断「这个动作在此情境下合不合适」

Google Research 这份报告给的是 agent 隐私与安全的研究议程，而不是可以直接上线的系统，但它恰好回答了上一条暴露的问题该往哪里修。10 月 6 日 05:08（Asia/Singapore），Google Research 发布博文 Open and Emergent Problems in Agentic Privacy and Security: A Contextual Angle，介绍 2025 年底在纽约举行的 CAPS（Contextual Agent Privacy and Security）工作坊产出的报告，官方称有 50 多位学界与业界人士参与。

报告的理论底座是「情境完整性」（Contextual Integrity）：隐私不等于保密，而是信息按照情境中合理的社会规范流动。你愿意把礼物清单告诉购物助手，却不想让家人看到，同一条信息合不合适，取决于谁发给谁、什么类型、按什么规则流动。报告把这个框架从「信息该不该传」推广到「动作该不该做」，称之为情境安全。它指出 agent 和传统软件的差异：输入是自然语言和图像，难以界定预期行为、难防提示注入；规划是概率性的，传统测试覆盖不住；任务层层委派，用户逐条确认会产生「确认疲劳」。

具体主张有两层。一是在 agent 系统里加一个监督层的「情境策略引擎」，能根据用户请求实时生成策略，在任何信息离开用户工作区之前先判断这次数据流动合不合适；好比出差时帮你订机票的助理，事先就知道护照号该给航司、不该给会议主办方。二是多层防御：系统级动态沙箱与 agent 身份、模型层的情境推理、更贴合用户心智的控制界面、防多 agent 串通的护栏，以及跨组织治理。评测方面，报告呼吁建立标准化、多 agent 的动态「Agent Gym」开源沙箱，模拟长时间、连锁的交互。

它适合 agent 安全与隐私研究者当选题地图，也适合产品团队检查权限设计缺了哪一层；局限是没有新基准、没有可下载的系统。「agent 身份可识别」「动作按情境授权」，正是它和 Wikimedia 声明都点到的缺口。

深入学习建议

  • 先读 博文 理清框架，再看 论文页 里的完整技术报告。
  • 做 agent 产品的团队，可以拿报告的五层清单对照自家权限设计，标出现在只靠「弹窗确认」兜底的环节。

X 动态

主线：Codex 的「28 天」——OpenAI 用每天一项改进来回应「太复杂、额度太紧」

OpenAI 正在把 Codex 的竞争从「谁的模型更强」转向「谁的日常体验更顺」，而且公开给自己定了节奏。负责 Codex 等核心产品的 Thibault Sottiaux 在 10 月 5 日 04:33（Asia/Singapore）发帖：接下来 28 天，每天要么上线一项对大多数 Codex/Work 用户明显有用的改进，要么给所有人一次 full reset，也就是把用量额度清零重来（原帖）。此前他说团队只做简化、提效换用量、突破性功能或新模型，因为用户明确想要更简单（原帖）。

第一天的改进在约 10 月 6 日凌晨（Asia/Singapore）公布（原帖）：通过订阅使用 GPT-6 Astra 和 GPT-6.1 Sol 时，默认速度提升约 50%，覆盖 OpenAI 自家产品，以及支持「Sign in with ChatGPT」的合作伙伴，原帖点名 OpenCode、Pi、Amp、Devin。用户不需要改任何设置，原帖称两小时内就能感觉到。OpenAI 员工随后称这是推理侧优化。「Sign in with ChatGPT」是用 ChatGPT 账号登录第三方工具、用量记在订阅额度上，所以提速也延伸到了这些第三方编程工具。

数字需要谨慎读。RuntimeWire 指出，Sottiaux 在帖中给的输出速度大约是从每秒 30 个 token 提到 50 个，如果两个数都精确，涨幅约 67%，和「约 50%」对不上；Sottiaux 称这些是近似值，没说明怎么测。更关键的是，这是流式输出速度，不是任务完成速度：编程 agent 大量时间花在规划、调用工具和跑代码上，吐字快不等于活干得快，也不等于额度能做更多事。OpenAI 开发者社区的跟踪帖 里也有用户贴出单次测试，认为 6.1 Sol 反而变慢，个例不能当结论，但提醒体感和实测要分开看。

重度 Codex 用户和用 Sign in with ChatGPT 接第三方工具的团队值得逐日跟踪这 28 天；做选型的团队应在自己的任务集上测端到端耗时和完成率。额度、延迟和产品复杂度，已经和模型分数一样成为订阅制编程工具的竞争焦点。

深入学习建议

主线：Claude Cowork 改为云端执行——换来后台运行，代价是重新划数据边界

本地优先的桌面 agent 正在变成「云端执行，本机按需取文件」，这对处理敏感文件的用户是一次实质变化。Anthropic 帮助中心 Use Claude Cowork on web, desktop, and mobile 写明：2026 年 10 月 6 日起，Pro 和 Max 套餐的新 Cowork 任务在云端运行，设置里「通用」下的「Only on your computer」选项被移除。已在本机开始的任务留在本机做完，可下载转录稿转到 Claude Code 继续。Cowork 是 Claude 里让 agent 代你完成多步任务的模式，同一页还写着它正在和普通聊天合并成「一个 Claude」，逐步推给 Pro/Max 用户。

好处是合上电脑任务还在跑、定时任务不需设备在线、会话跨设备接续；代价是会话和文件保存在 Claude 账号里。官方对本地文件的说明是，文件夹仍留在你的电脑上，Claude 只能通过桌面 App、在 App 打开时访问你已连接的文件夹；任务需要某个文件时，只取这一个文件的副本到云端，删除会话时这些副本也随之删除，是否用于改进模型取决于隐私设置里的对应开关。定时任务也一并迁到云端，包括用到本地文件的那些，后者需要桌面 App 开着。本地 MCP 服务器之类的本地连接器只能经由桌面 App 使用。

对仍然要求严格本地执行的用户，官方给的出路是 Claude Code 桌面版：它在你的电脑上运行，文件夹和历史都留在本地，但 Cowork 里的项目和定时任务不会自动迁过去。Team 与 Enterprise 套餐是否同样变化，这一页没有说，不宜外推。X 上关于「数据在哪、谁能看」的讨论当天传播很广；另有未经核实的第三方说法称，提前迁移的用户遇到过本地文件没真正写回的问题，依赖本地写回或本地 MCP 的工作流最好先拿小任务测一遍。

主要用 Cowork 做调研、写作的，云端执行几乎只有好处；用它处理合同、病历、源代码等本地敏感文件的，需要重新评估合规，必要时切到 Claude Code。

深入学习建议

  • 直接读 帮助中心 的「What’s changing for Pro and Max plans on October 6」与「What requires the desktop app」两节。
  • 依赖本地文件的用户：先跑一个小任务，确认云端会话对本地文件的读写是否真的落盘。

主线：多 harness 强化学习长文到位——62% 对 33% 有了出处，小模型可以按部署环境去练

上期我们只拿到一句「同一套权重换个 harness 分差近一倍」，没能核实；这一窗，完整长文、数据和代码都公开了，结论站得住。Hugging Face CEO Clem Delangue 在 10 月 5 日晚发帖推荐（原帖），对应的是 FineEnvs 团队在 Hugging Face Space 上发布的 The ultimate guide to multi-harness RL。harness 指包在模型外面的那层程序，负责跑循环、提供工具、组织上下文、解析输出、决定何时停止；同一台发动机装进不同的车，圈速自然不同。

同一套 LFM2.5-2.6B 权重，在作者自建的数据分析类测试集上，用 Mini-SWE-Agent 能解 62% 的任务，用 Claude Code 只有 33%，这个基线本身就说明了问题。他们的方案是：harness 原样运行、不改一行代码，中间放一个捕获代理。harness 以为自己在调用模型 API（长文覆盖 OpenAI Chat Completions、Responses、Anthropic Messages、Gemini 四种格式），代理把请求转成统一格式交给 vLLM，同时记录采样出的 token id 和 logprob，交给 TRL 的异步 GRPO 训练。这样训练用的是模型真实生成的 token，而不是事后重新分词的近似。作者说已有十个 harness 通过了这套捕获校验，覆盖 16,000 次 rollout。

训练结果有几处值得记住。只在 OpenCode 里训练，提升几乎都集中在 OpenCode（34% 到 58%）；在 OpenCode、Claude Code、Codex、Mini-SWE-Agent 四个 harness 里一起训练，四个都提升，平均从 42% 到 54%。奖励里加了一个上限 0.1 的「少调工具」加分后，多 harness 模型在本来就能解的任务上，工具调用比基座少 31%。作为对照，他们用 Qwen3.8-27B 当老师，收集 3,189 条成功轨迹做监督微调，最好的一版停在 47.5%，不如两次强化学习。局限作者自己写得很清楚：只在 2.6B 小模型和数据分析类任务上验证；单 harness 与多 harness 两次训练的总分差 1.9 个百分点，在评测噪声之内；每次训练只有一个种子，也没有不加「少调工具」奖励的对照组。

对评测者，榜分必须标注 harness，否则「A 比 B 高」可能只是脚手架差异；对训练开源小模型的团队，可以按实际部署的 harness 去练。底层实现已经合入 TRL（PR #6420），文中训练出的模型、SFT 数据和教师轨迹也都放在 Hub 上。

深入学习建议

热门开源项目

主线：vLLM v0.31.0——权重常驻显存，引擎重启不再从头装载

这一版对线上推理服务最实用的变化，是重启变快了。vLLM 在 10 月 5 日 14:44（Asia/Singapore）发布 v0.31.0，发布说明写合入 717 个提交、307 位贡献者（其中 96 位新人）。新命令 vllm preload 会启动一个权重缓存守护进程，把量化后的权重留在 GPU 显存里（#56680），推理引擎重启时直接接管，不必再从磁盘整包读入、重新量化；这一版还让它支持数据并行和 MTP 草稿模型，加了 /health 探活与就绪等待。好比货一直摆在架子上，重启只是换店员，频繁滚动发布或故障恢复的停机时间因此缩短。

性能侧，DeepSeek-V4.1-Flash 的一整套优化成为 SM100（Blackwell 一代）上的默认路径，包括 FlashMLA mega attention 搭配 NVFP4 压缩 KV 缓存、把门控 GEMM 与专家选择融合的 Mega-Gate 等。Model Runner V2 接上了草稿模型投机解码，即先让小模型猜几步、大模型一次验收。调度上多了 --max-num-active-seqs，可以独立于 max_num_seqs 限制同时运行的请求数。性能幅度以项目自测为准。

安全默认值的变化需要升级前特别留意。除非显式打开 --trust-request-mm-kwargs，否则请求里自带的 mm_processor_kwargs 和 media_io_kwargs 会被拒绝（#58830）；前缀缓存的额外 key 按来源打标签，避免 LoRA 名和 cache_salt 撞车，LoRA 路径也计入块哈希。前缀缓存是复用相同开头的计算结果，键一旦撞车，就可能把一个租户的缓存错给另一个租户用。依赖客户端传处理参数的多模态服务，升级后会直接报错。

自建推理集群、频繁重启或做 RL 推理的团队最该关注；单机偶尔跑模型的开发者可以等补丁版。

深入学习建议

  • 先读 发布说明 的 Highlights 与 Security 两段，再看 preload PR 的用法说明。
  • 多模态服务升级前：搜索代码里是否在请求中传 mm_processor_kwargs，决定兼容策略。

主线：llama.cpp v0.6.0——新批次 API 和会话格式升级，本地推理栈要跟着改

这一版的重点不在新模型数量，而在底层接口变化，依赖 llama.cpp 做二次开发的项目需要排期适配。ggml-org 在 10 月 6 日 00:56（Asia/Singapore）发布 v0.6.0。核心是新的 llama_batch_ext 扩展批次 API 和 llama_process()（#24669）：同一批里可以混合 token 和 embedding 输入，并为 MTP（多 token 预测）、deepstack 这类模型带上逐 token 的状态向量。与此同时，会话格式升到 LLAMA_SESSION_VERSION 11 和 LLAMA_STATE_SEQ_VERSION 4，旧的会话存档需要重新保存。

模型支持方面，正式接入 GLM-5.3-Flash（GLM5-Next），发布说明称它是 320B 的文本加视觉混合 MoE 模型（#27773）；Clef 决策模型的文本和视觉都已完整支持；Qwen4Exp 加入了 MTP 投机解码，发布说明称在 DGX Spark 上解码约提速 1.5 倍。服务端新增 /v1/systemone 接口，供 laya、julia-1 等五个「决策模型」使用，这类模型不生成自由文本，而是一次前向给出各个选项的概率。Apple 用户可以关注 Metal 侧两项改进：F16 KV 的新 flash attention 内核，以及面向投机和批量解码的 few-row MMA 矩阵乘内核，发布说明称在 Apple GPU 上矩阵乘最高约快 3 倍。ggml 同步升到 v0.26.0。

基于 C API 做应用或绑定的开发者要先确认存档迁移路径；在 Mac 或 DGX Spark 上跑本地模型的用户可以实测新内核和 MTP，加速倍数是项目自报，依赖具体模型与批大小。

深入学习建议

  • 读 发布说明 的 API changes 一节，再看 batch_ext PR 的设计讨论。
  • 有会话持久化的应用：升级前写一个迁移脚本，旧存档重新生成。

模型相关

主线：Aleph Alpha 放出 Kolibri——欧洲「主权」开源模型第一次拿得出同档对表成绩，但编程 agent 仍落后

Kolibri 给了欧洲受监管客户一个可自托管、许可宽松、德语原生的推理模型，分数也第一次能和同档开源 MoE 正面比较。海德堡的 Aleph Alpha 在 10 月 3 日（德国统一日）发布博文 Kolibri Has Landed，权重在 Hugging Face 上以 Apache 2.0 发布（默认仓为 FP8，另有 BF16 仓）。按模型卡，它是从零训练的德英双语 MoE：总参 78.1B，每个 token 激活约 3.46B；50 层全部为 MoE，每层 384 个路由专家选 6 个，外加 1 个共享专家。MoE（混合专家）像一家有几百位专科医生的医院，每个病人只看其中几位，计算量小，但整栋楼都得建好，显存并不省。卡上写 FP8 权重约 78 GB，最低一张 H200 或 B200，或两张 H100。

上下文方面，原生训练长度是 262,144 token，官方称凭借只在滑动窗口层加位置编码的设计，可外推并验证到 1,048,576 token，但建议服务时不超过 262,144。每 5 层里 4 层只看前 512 个 token、1 层看全文，长上下文解码开销因此可控。训练用了 768 张 B200，预训练 20T token、历时 21 天，加上 3.44T 中段训练和约 200B 长上下文适配，合计约 24T；博文称德语占预训练 token 的 21.3%。自研分词器 UniBPE 更尊重德语复合词结构，德语压缩率在官方对比里最高。

成绩全部是厂商用自家评测框架跑的，要等独立复测。在官方表中，Kolibri 的 AIME 2025 为 96.9、GPQA Diamond 84.3、LiveCodeBench v6 85.9，均高于 Qwen3.6-35B-A3B 和 Mistral Small 4；但 SWE-Bench Verified 66.4 低于 Qwen3.6-35B-A3B 的 73.8，TerminalBench 2.1 只有 27.7，BFCL v4 总分 61.4 也落后于 Qwen3.6 的 67.2；同表里稠密的 Qwen3.8-27B 在多数项目上领先。另一个卖点是「不知道就不答」：自研的 Merlin-Arthur 训练法会删掉文档关键证据诱导模型瞎编，训练它在证据不足时拒答，官方称 AA-Omniscience 不幻觉率从前代约 15% 升到 44%。所以 X 上「Kolibri 打败 Qwen」的说法，只在数学、知识和部分有据问答上成立，在编程 agent 上不成立。

它最适合欧洲企业与公共部门、做德语场景或需要私有部署的团队、看重有据可查回答的 RAG 应用。需要强编程 agent 能力或主要做中文的团队，同档 Qwen 仍更稳。部署上要注意，它需要 Aleph Alpha 提供的 aleph-alpha-inference vLLM 插件；Apache 2.0 许可只覆盖仓库中的权重与配置文件，不延伸到训练代码与方法。社区 GGUF、MLX 再打包已有不少，以官方仓为准。

深入学习建议

  • 先读 官方博文 的架构与德语数据章节，再看 模型卡 的评测表与硬件要求，细节见 技术报告。
  • 想试跑的团队：按模型卡安装 aleph-alpha-inference 后用 vLLM 起服务，先在自家德语或 RAG 任务上和 Qwen3.6-35B-A3B 做同条件对比。

次要动态

  • 报道称：Meta、微软收紧员工内部使用 Claude。据 The Information 报道，两家正在减少内部对 Claude 的使用、转向自研或自家工具；原文付费、单一来源，具体数字未经证实。
  • arXiv · Sigma 连续扩散语言模型（2610.02665，作者含 NVIDIA 研究者）：首个做到 3B/8B 规模的连续扩散语言模型，从自回归权重热启动，论文报告预训练后在 GSM8K、HumanEval 等基准上与离散扩散和自回归基线相当。
  • arXiv · Planning to Learn（2610.03667，Google DeepMind）：提出随剩余训练量收缩的 horizon loss，论文报告在 ImageNet 上优于交叉熵、标签噪声越大增益越大，对理解后训练里策略梯度与交叉熵的张力有启发。
  • arXiv · ProWAM（2610.02508，作者含 Meta 研究者）：世界动作模型同时预测动作与按进度排列的稀疏视觉子目标，论文报告 LIBERO-Plus 85.8%、随机化 RoboTwin 75.7%。
  • arXiv · MLCommons Jailbreak Benchmark v1.0（2610.02827）：多家机构联合的越狱评测流程，论文报告 8 个开源权重系统在攻击下的不安全响应率从 11.08% 升至 18.65%。
  • arXiv · PlurPO（2610.02568，作者含 Amazon 研究者）：让模型在人际冲突建议里模拟多方利益相关者，以「各方都能接受」为偏好训练，缓解社交谄媚。
  • Hugging Face datasets 5.1.0（发布页）：新增 Harbor 格式，用来挂载 RL 评测环境与任务集（多 harness RL 长文用的就是 Harbor 任务）；新增 Vortex 列存后端和 FASTA、FASTQ、PDB、mmCIF 等生物序列与结构格式；同时修复归档路径逃逸、禁止 HDF5 外部链接，处理第三方数据集的服务建议升级。
  • ComfyUI v0.39.0（发布页）：修复 Qwen Image 2.1 选 int8/int4 缓存时的崩溃，新增 --offline 与 --disable-partner-nodes；Partner 节点接入 FLUX 3 Image、Sonnet 5.5、Ideogram 4.5 等。
  • 新仓库 leviathan（elstongun/leviathan）：10 月 5 日新建的 Rust 单文件工具，把 JSONL、CSV、SQLite 等记录建成可排序的全文索引，定位是 agent 在大数据集上的「深层记忆」，Apache 2.0，采集时约 301 星。
  • Google DiarizationLM-Gemma-4-E4B-v1（模型页）：基于 Gemma 4 E4B 微调的说话人日志后处理模型，附 BF16 与 GGUF 权重；卡面注明不是 Google 官方支持的产品。
  • autotrust GEV-26B-Decide-NVFP4（模型页）：决策模型 GEV 的 NVFP4 量化版本窗新发，同系列模型卡补了机器人与电脑操控演示，卡内分数待独立验证。
  • OpenAI 广告新格式：OpenAI 同日发布 ChatGPT 视觉广告格式与效果衡量方案，属商业化进展，不展开。

来源与延伸阅读

今日行动建议

  • 在欧盟有用户的产品团队：今天就盘点哪些输出会带 textGrain 水印，决定 API 侧是否开启，并更新对用户的说明文字。
  • 运营 agent 的团队：检查出网流量是否带可识别标识、是否遵守目标站点的机器人政策，把审计日志移到 agent 进程之外。
  • Cowork 用户：用一个不重要的任务验证云端会话对本地文件的读写是否真正落盘，敏感工作流评估迁往 Claude Code 桌面版。
  • 做编程 agent 选型的团队：不要直接引用「提速约 50%」，在自家任务集上测端到端耗时、完成率和额度消耗。
  • 评测与 RL 研究者：读多 harness RL 长文，给自家评测报告加一列「harness」，用 TRL 的 harness rollout 在小模型上复现一次。
  • 推理平台工程师：在预发环境试 vLLM v0.31.0 的 vllm preload，检查多模态请求是否受新安全默认值影响；llama.cpp 用户准备会话存档迁移，处理第三方数据集的服务升级 datasets 5.1.0。
  • 需要欧洲本地部署的团队：拉取 Kolibri-1，在德语与 RAG 任务上与同档 Qwen 做同条件对比，再决定是否进入候选。
🎵 看累了听个音乐吧
跟鬼哥聊聊 AI