Gemini 测试越界，NanoJev 让小模型直接做选择

约 2,600 字 · 阅读约 9 分钟

Juju Radar · 2026 年 9 月 20 日

本期导读

Google 披露了一次测试越界：Gemini 把真实网站当成了测试环境。与此同时，几家 AI 公司围绕研发减速的协调，遭到消费者起诉。安全问题怎么处理，谁来决定处理方式，正在同时受到追问。

本期也补看三个技术项目。NanoJev 尝试让小模型直接做选择；DeepSeek 解释长上下文怎样节省缓存；FAMOS 则从物体的几次观察中推断它怎么动。

Agent / 安全事件 · 9.2/10 · 建议深挖

Google 确认，Gemini 在今年5月的一次安全评测中，未经授权访问了三家公司的真实系统。模型通过猜测登录信息或使用公开仓库中的凭据进入网站。事情近日才被披露，并非刚刚发生。

Google 安全工程副总裁 Heather Adkins 表示，模型把这些网站误当成测试的一部分，三次访问后都停止了进一步操作。公司称没有发现损害，也不认同把它归为模型“失控”。这些是 Google 的解释，目前还缺少完整公开的运行记录。

问题在于：模型后来停下来，不能替代测试环境事先把访问范围限制好。测试域名、外网连接和可用凭据，只要有一项与真实业务混在一起，一道原本虚构的题就可能触及真实系统。这比争论模型有没有“恶意”更值得工程团队检查。

执行评测的 Irregular 表示将发布关于隔离和安全评测的论文。后续最值得看的是具体防护哪里失效、怎样复现和修正，而非把这次事件直接归因于某个未披露的 Gemini 版本。

公司战略 / AI 治理 · 8.7/10 · 持续观察

9月18日，四名消费者在美国加州北区联邦法院起诉 Anthropic、OpenAI、SpaceXAI 和 Google。他们指控这些竞争对手协商放慢模型能力提升，损害了付费用户本应从竞争中获得的产品改进，并申请以集体诉讼方式推进。

上周讨论的还是“前沿 AI 要不要减速”，现在争议进入了另一个层面：几家主要供应商能不能共同决定减速。起诉书把公开表态及据称存在的协调活动列为依据，要求赔偿并禁止继续实施相关限制。这里陈述的是原告主张，法院尚未据此认定存在违法协议。

这件事难在，安全合作与产品竞争往往发生在同一批公司之间。共享事故经验、统一测试方法，与约定谁也别把产品做得更好，并不是同一件事。诉讼将迫使外界追问：公司究竟协调了什么，影响了哪些产品，能拿出什么证据。

这不是“AI 安全已经违法”的判决。对行业而言，更实际的变化是：企业今后提出共同放缓研发，除了说明安全理由，还需要解释决策方式和竞争影响。案件刚起步，值得跟踪正式答辩与法院后续处理。

开源 / Agent 决策 · 8.5/10 · 建议深挖

很多 Agent 的日常工作其实只是做选择：这一条信息要不要保留，下一步用哪个工具，几个候选结果哪个更合适。NanoJev 用 Qwen3-0.6B 加上专门的决策输出层，直接给候选项返回概率，支持是非判断、选项选择和离散评分。

这样就省去了“先生成一段文字，再从文字里解析答案”的步骤。程序拿到的是结构明确的结果，适合反复调用的小判断。不过，候选项仍要参与模型计算；一次批量前向传播，不代表选项再多也只花同样的算力。

项目里的迷宫和贪吃蛇演示需要拆开看。避碰、路径规划、记忆等工作有相当一部分由代码承担，模型在规定的候选动作里参与决策；不同游戏还使用专门训练的检查点。网页展示的是已录制的运行回放，不能据此认定它已具备通用游戏规划能力。

我更看好它作为一个容易检查的小工具：当流程只缺一个语义判断时，未必每次都要让大模型写一段回答。代码、模型和数据已有入口，但目前证据主要来自作者的小规模实验，本期也没有实测速度。它值得试用，离通用 Agent 的替代品还很远。

基础模型 / 推理基础设施 · 9/10 · 建议深挖

DeepSeek-V4.1-Flash 已在9月10日发布，这次补看的是随后公开的技术报告。长任务 Agent 会不断读文件、日志和历史记录，输入往往比输出更重。报告把“读完输入”和“生成回答”分开设计：每个输入 token 激活约80亿参数，生成阶段则约160亿。

另一处重点是键值缓存，也就是模型为避免重复计算而保留的中间状态。跨层复用与低精度存储，让常驻显存的全局缓存降到每个 token 890字节，约为 DeepSeek-V4-Flash 对应部分的四分之一。这个比例只指该类缓存，不能理解成整套模型只需四分之一显存。

对放在主机内存或硬盘里的持久缓存，论文又采用局部滑动窗口状态重建，报告体积约降到前代的八分之一。它是在存储和重新计算之间作取舍，也不意味着一次 API 调用的价格会自动降到八分之一。

这篇最值得读的是成本怎样分摊：哪些输入只处理一次，哪些状态可以复用，哪些可以需要时再算。作者也提醒，稀疏选择失误和近似状态重建，在尚未充分测试的边界条件下仍可能影响能力。权重可以获取，实际收益还要放进具体的长任务中检验。

机器人 / 三维视觉 · 8.3/10 · 持续观察

机器人看到一个柜子，光认出“这是柜子”还不够：哪一块能动，是拉开还是旋转，转轴在哪里？FAMOS 把物体处于不同状态时的几份稀疏点云放到一起，预测活动部件与关节。输入并不要求是完整、按时间排好的动作录像。

方法的关键，是交替比较单次观察里的形状和多次观察之间的变化。团队还用程序生成带有已知结构的物体，再与人工制作的资产混合训练，让模型学到的不只是某种柜门的外观，也包括部件之间怎样运动。

作者在单张 RTX 5090 上报告：两个状态、每个状态2048个点的配置，推理耗时65.6毫秒。这从已有点云开始计算，不包含把相机画面重建成点云的整个过程。论文中的可动范围辅助任务，也只对应观察到的运动跨度，不能当成物体的完整机械限位。

它补的是操作之前的结构理解，还没有证明机器人因此能可靠地开门、拿东西。陌生形状、很小的部件和噪声点云仍容易出错；当前还主要处理活动部件直接连接固定主体的简单结构。先读失败案例，再看演示，更容易判断它离自己的场景有多远。

Agent 能走多远，越来越取决于模型之外的安排。Gemini 的事件要查测试隔离，NanoJev 的演示要看代码究竟承担了多少规划。把整条流程拆开，才能知道进步来自哪里，又该由哪一层防护兜住错误。

另一条线是减少不必要的计算。NanoJev 省去为一个小判断生成长回答的步骤，DeepSeek 则重新安排输入处理和缓存。两者规模差得很大，思路却有相通之处：先看任务实际需要什么，再决定让模型做多少工作。