这里是由Robin为你带来的咸话咸说之每日AI乱炖。
安全公司 Apiiro 发现 Claude Code 设置文件里的上千个密钥被提交到 GitHub
接下来这条和安全有关，出问题的是一个我们每天都会碰到的文件。
AI 安全公司 Apiiro 在公开的 GitHub 仓库里发现了上千个密钥，包括数据库密码、API 令牌和 root 登录凭据，它们都藏在被提交进仓库的 Claude Code 设置文件里。
泄漏的根源是 Claude Code 对自动执行命令的授权方式。当用户在授权提示里选择「Yes, and don't ask again」，也就是同意并且不再询问时，这个选择会被写成本地 .claude/settings.local.json 里的一条规则。这条规则有时写成通配模式，但更多时候命令本身会原样写进这个设置文件，连同命令里夹带的任何敏感信息一起落盘。
如果这个文件一直留在开发者本机，其实算不上多大的安全问题，前提是那台机器本身没有被攻破。Anthropic 在 Claude Code 文档里也提到，这个文件会被自动加进开发者的全局 .gitignore 列表，通常也就不会被公开分享出去。
这条最值得听的不是猎奇，而是自动保护也会被绕开：文档明明说过本地配置会被自动加进忽略列表，公开仓库里照样能搜到密钥，说明「工具默认帮你做对」挡不住全部情况，尤其是人为了省事点了不再询问之后。真正值得盯的是这类授权记录会不会改成先脱敏再落盘，以及各家代理工具会不会把命令本身也纳入检查。这次事件留下的实际提醒是，凭据一旦进过提交历史，就该按还没撤回的东西来对待。
Anthropic 发布 Claude Fable 5.2 与 Mythos 5.2，1000 个智能体 30 小时形式化费马大定理
下面这条来自模型厂商，话题偏硬核，先听它对研究型任务做了什么。
Anthropic 发布了 Claude Fable 5.2 和 Mythos 5.2。Fable 5.2 定位为面向复杂研究任务的多智能体系统，可以调度大量智能体自主分工、协调，并推进形式化证明。发布材料称，1000 个 Fable 5.2 智能体在大约 30 小时里、以极少的人工干预形式化了费马大定理；智能体只从最简提示出发，自己建立协作方式，不查数学参考资料，只用一组中间定理陈述作为评分依据。作为对照，评论里提到的那个尚未发布的研究版本需要专门搭一套运行框架，还要一位人类研究员在旁边指导，前后花了 11 天。
费马大定理说的是，任意大于 2 的整数 n 都不存在正整数 x、y、z 满足 x 的 n 次方加上 y 的 n 次方等于 z 的 n 次方。形式化不是写出自然语言论证，而是把证明改写成可由计算机检查的机器可验证对象。Anthropic 此前用未发布的研究版 Claude 做过一次，耗时 11 天；这次 1000 个智能体自行组织协作，等于同时检验了模型推理、多智能体编排和形式验证三件事。
可用性上，Fable 5.2 已经能通过 Claude Platform 和 Amazon Bedrock 拿到，Mythos 5.2 只对通过 Anthropic 验证的网络安全和生命科学方向开放，所以前者的技术任务可用面更宽，后者仍然受准入限制。
社区评价是：Fable 5.2 能力已经不弱，但在普通任务上常常难以和 Opus 5.5 区分，只有把任务目标明显抬高、复杂度拉上去才看得出差别；也有人提到在一个约 12.5 万行的项目上用 Opus 5.5 做开发，体感良好，因而质疑 Fable 和 Mythos 是否对应真实刚需的工作流。还有人怀疑 5.5 可能因为新版本发布而被削弱，并质疑发布里的基准设计，比如 Carbon 那条异常的 effort-intel 曲线、缺少单一网络安全基准的横向对比，以及 Robodojo 的对比换成了 Argon 而不是 Carbon。
对做研究型工作的团队，这条的分量在于它把多智能体从编排演示推到了有明确验收标准的任务上，形式化验证恰好是那种错了会被机器当场抓出来的活儿。也正因为如此，这次演示更像一次压力测试而不是产品承诺：能不能在别的研究型任务上复现同样的协作质量，才决定它是不是可依赖的能力。另外 Mythos 只对通过验证的方向开放，说明 Anthropic 对这类能力仍然设着准入门槛。
Meta AI 发布 Muse Ember 1.0，最高支持 100 万输入 token，主打智能体任务
再来看一个定价压得很低的模型发布，定位就在日常任务里。
2026 年 11 月 10 日，Meta AI 推出 Muse Ember 1.0。Meta 把它称为自家最小、最高效的模型，主要面向智能体反复执行的工具调用、编码子任务、路由、抽取和长文档解析，材料里的独立验证目前仍然有限。
定价上，Ember 最高支持 100 万输入 token。提示不超过 20 万 token 时，输入、缓存输入和输出分别是每百万 token 0.10、0.004 和 0.50 美元；超过 20 万之后，这三项涨到 0.30、0.012 和 1.50 美元。
横向比较的话，在各自的短提示区间，Ember 与 GPT-6 Luna、Claude Haiku 5.5 的输入和输出单价完全一样，都是每百万 token 0.10 和 0.50 美元，而 Claude Fable 5.2 是 8 美元和 40 美元。三者的长提示加价阈值分别是 20 万、27.2 万和 10 万 token，GPT-6 Luna 和 Claude Haiku 5.5 的长提示输入与输出价分别是 0.20 与 0.75 美元、0.50 与 2.50 美元。
Ember 提供 minimal 到 max 六档推理强度。Simon Willison 引用的 Artificial Analysis 图表显示，xhigh 和 max 模式每项任务大约 0.12 和 0.14 美元，Intelligence Index 约 34 和 36，落在帕累托前沿上；不过这只是特定基准的结果，它在 SVG 生成上的一次尝试中，high 档没有返回完整图形，推理档位和视觉质量也没有清晰对应。
把这些数字放在一起看，智能体开发者可以分开核算短提示和长文档任务的成本；但现有证据只覆盖官方定位、一张特定基准图表和一次 SVG 生成观察，还不足以断言它在实际工作负载里一定更省。
这条对做智能体应用的人最实际：厂商开始按一次任务多少钱来定价，推理档位也被做成能直接调的旋钮，开发者可以在成本和效果之间自己取舍。真正值得盯的是它在自有负载上的表现，公开证据目前偏薄，定价表上省下的那部分能不能落到业务里，还得靠第三方实测和真实账单说话。另外值得留意的是这套定价结构会不会被其他厂商跟进，如果按次任务定价变成常态，选型的逻辑也会跟着变。
GitHub 项目描述消费版 Gemini 把邮件与云盘内容送人工审核的具体路径，Google 尚未确认
接下来这条是一则社区调查，具体机制还有待验证，边界要听清楚。
GitHub 上的开源项目 thisisme6598/gemini_files 指称，消费者版 Google Gemini 在启用 Connected Apps、并授权 Gmail 或 Google Drive 之后，可能把邮件和文件内容送给人工标注人员审核。
讨论里有一条关键限定：这一说法针对的是消费版 Gemini。评论援引的 Workspace 官方说明则称，Workspace Gemini 和面向企业的 Workspace Intelligence 不受人工审核。
如果指控属实，用户为了个性化功能交出去的个人数据就可能进入人工访问流程，关于同意范围、隐私告知和数据治理的担心也就有了现实依据。Google 方面官方未确认这一具体路径：官方帮助中心只写明 Connected Apps 的数据在有限情形下可能接受人工审阅并列出范围；这个项目补充的是具体触发路径与发生频率，这些复现细节还没得到官方证实，所以只能当作社区调查的说法来看。这个项目补充的是具体触发路径与发生频率，这些复现细节还没得到官方证实，所以只能当作社区调查的说法来看。
人工标注通常指工作人员检查模型交互或工具调用数据，用来评估安全性和质量；这个项目声称，通过 Connected Apps 读取的邮件正文和云端文件内容，也可能因此进入这条审核流程。Google 官方的帮助文档则明确写了 Connected Apps 的数据会被人工审阅，并给出被审数据的范围；真正没有官方说法的，是这个项目描述的后台拉取路径、四态流程和触发频率。
评论也提醒，不要把消费版的情况直接外推到企业产品：Workspace Gemini 和 Workspace Intelligence 仍宣称数据不受人工审核，而多位参与者对消费版在用户授权后接触邮件和文件的方式并不满意。有人提到 Gemini 的回答曾经异常贴合某封催问邮件，也有人担心人工标注数据会被用于训练或者发生泄露，但这些用户体验和推测都不能独立验证核心指控。
这条最该被听见的其实是边界：消费版和企业版在数据流向上的说明并不一致，官方文档把两边口径都写清了：消费版可能被人工审阅，企业版宣称不受；说不准的反而是这个项目声称的具体路径。目前手上的材料只是一份社区复现记录，测试流程与触发频率都还没公开，对这个项目的具体指控，Google 至今没有公开回应。所以它现在既不能被当成实锤，也不该被轻轻带过。值得跟的是后续有没有更完整的复现材料，以及官方说明会不会因此改写。
Robbyant 公开 LingBot-Touch 触觉预训练，4K 小时数据下召回率达 49.3%
下面这条偏研究，是让机器人从触觉信号里学东西。
Robbyant 发布论文，并公开了 LingBot-Touch 的推理代码和模型检查点。这个模型用 JEPA 式自监督学习，预测被遮挡接触区域的潜在表征，而不是重建原始传感器信号，并在相同数据上和同规模的 MAE、VAE 基线做了对比。
触觉到视频的 Top-5 召回率，1K 小时数据下三个方法分别是 32.1%、5.6% 和 4.4%；扩展到 4K 小时，JEPA 提升到 49.3%，MAE 仍在 9% 以下，VAE 则降到 3.1%。论文给出的解释是，稀疏触觉片段大多是接近零值的信号，重建损失可能在还没学到有效接触信息时就继续下降；为了避免高掩码率在训练初期隐藏掉所有接触像素、引发梯度爆炸，掩码率在 300 步内从 40% 预热到 80%。
编码器用规范化的指尖坐标统一处理磁性、压阻和视触觉三类传感器，通过共享 Transformer，加上包含时间、手指和三维位置的 5D RoPE 建模。在 26 个真实机器人任务、4 种策略的 104 个组合里，冻结特征有 89 个取得最高分；迁移到预训练时没见过的磁性手时，LingBot-VLA 得分从 57.21 升到 75.04。Tiny 模型在约 4K 小时处趋于饱和，Small 还在持续改善，更大的模型加更多数据是自然的后续方向。这些结论目前仍限于论文报告的基准和这一项研究。
这条有意思的地方在于它质疑了一个默认前提：接近零值的稀疏信号，未必适合用重建的方式去学。换成预测被遮住那部分的潜在表征，等于把「还原传感器读数」换成了「推断接触发生了什么」，这才是机器人真正需要的语义。对做具身数据的团队，这条比多一个基准分数更有价值；不过结论目前还锁在这一项研究的基准上，别的传感器上能不能复现，还得等更多团队的实测。
Reddit 实测：Qwen3.8 27B 用 8 位 KV 缓存，64k 上下文省约 2 GiB
收尾这条来自社区实测，跟本地跑模型时的显存开销有关。
这是一份发布在 Reddit 上的自测报告。作者对 Qwen3.8 27B 的 35 种权重量化版本，在 llama.cpp、ExLlamaV3 和 vLLM 上做了测试，KV 缓存分别用 16 位、8 位，以及在支持的情况下用 4 位，提示混合了智能体工具调用和多种领域，最长到 64k token。
以 bf16 为基准，8 位缓存把每 token 的缓存占用从 64 KiB 压到 32 到 34 KiB，在 64k 上下文下大约省下 2 GiB。分布上的变化很小：llama.cpp 的 q8_0 和 ExLlamaV3 的 8 位版本，KL 散度变化都不到 0.00012，vLLM 的 FP8 增加了 0.0004 到 0.0006。
4 位缓存则能测到明显偏移，llama.cpp 的 q4_0 通常是加 0.0016 到 0.0027，ExLlamaV3 的惩罚随权重精度不同而不同；而且 4 位的惩罚从最初 4k token 到 16 到 32k token 区间又涨了大约 15% 到 30%。vLLM 的 NVFP4 和 FP8 检查点改走 Marlin 配 bf16 激活之后有改善，但即使这样也只是追平了更小的 UD-Q5_K_XL 量化。
作者的建议是，显存紧张时用 8 位 KV 缓存，尽量别用 4 位，长上下文尤其要避开；不过这些结论只来自一个作者的方法和一个模型，只能当参考。
几个术语交代一下：KV 缓存存的是前面 token 的 key 和 value 张量，注意力靠它复用计算，降低精度能省显存，但会引入误差，在长上下文里误差更要命；KL 散度衡量的是量化之后的下一个 token 分布相对 bf16 基准偏了多远，作者用同样 token 的成对提示做对比，把缓存变化和权重量化分开。两个未量化的引擎之间本身就差 0.0004 的 KL，他把这个当成跨引擎的噪声参考线。
这条的价值在于它给出了一个可以拿来对账的标尺：多数人纠结的其实不是能不能省，而是省下来的那点显存值不值得拿输出分布去赌。这份测试把两档之间的差距摆了出来，也提醒一句——它只覆盖了一个模型和一个作者的方法，别把它当成通用结论。对本地部署的人来说，更实用的读法是把它当作先试八位、再看自己负载的顺序，而不是直接照抄参数。
这六条凑在一起看，安全和隐私占了两条，其余四条谈的都是能力与成本：让智能体自己组队、把小模型压到能大规模调用、让机器人从触觉里学、把显存省下来。热闹之外，开发者能不能放心用，还是取决于这些不显眼的工程细节。
🎧 本期已同步制作为播客节目，点击收听《每日AI乱炖 · 2026-11-10》。
