跳到正文

2026年09月25日AI 版

7 条 · 4 个来源

头版

Muse显然将允许你下载其整个文件系统

行业动态The Verge AI

Muse显然将允许你下载其整个文件系统
Meta否认泄密,但开发者称Muse几乎无提示注入抵抗力,VM隔离也难辞其咎。

打算把 Muse 接进 Gmail 或内部代码库的团队,得先决定是否接受每个用户都能导出整套根文件系统。Meta 把这件事定性为虚拟机导出而非越权,所以这条边界要由你自己的合规判断来划,而不是由它的措辞来划。

展开全文

依据

开发者 Peter James 与 Jonny L. Saunders 说,两人各自独立地用很少的提示,就让 Meta 的 Muse 把整个根文件系统压缩交出,内含 Ubuntu 系统文件、应用模板和内部文档。Saunders 在 Mastodon 上称复现「极其容易」,Muse「几乎没有提示注入抵抗力」——提示注入(prompt injection)指在输入里夹带指令,让模型越过原有约束。他给出的对照是:Muse 在几秒内生成了「数百 MB 的准确库代码和已编译二进制文件」,「除非它不到一分钟就合成出整个 Ubuntu VM,否则我认为这是真的转储」。Meta 发言人 Daniel Roberts 回应,Muse 跑在各用户自己的持久 Linux 虚拟机里,「就像你面前的笔记本,你当然能看到文件」,导出虚拟机数据不给任何人 Meta 基础设施或他人数据的特权访问。Superintelligence Labs 的 Nat Friedman 称这属于「预期行为」,同事 David Singleton 则建议用户把它当「云上的一台免费电脑」。The Verge 记者用奉承加好奇的提示复现,拿到的是剥掉 SSH 密钥的 /opt/hatch 与 /home/hatch「安全版」,但仍被交出完整目录树。同周另一起是安全研究员 Patrick Wardle 发现的漏洞,可劫持 AI agent、改道转写处理并访问用户账号,Meta 已发热修复(hotfix)。

  1. 开发者发出少量提示
    触发
  2. Muse 打包根文件系统
    导出
  3. 交出内部文档与模板
    回应
  4. Meta 称属预期行为
从一次低成本提示到 Meta 定性的链路

没写清 材料没说这批归档里具体哪些文件会让 Gmail 连接被滥用,也没给出受影响用户或实例的数量。

下一步 核对 Meta 下一次产品更新说明里,「用户可用信息量」的调整是否包含根文件系统导出这一项。

行业动态

1 条

  1. Muse看起来很像OpenClaw

    行业动态The Verge AI

    Muse看起来很像OpenClaw
    Meta的Muse日活数据仅来自美国区估算,直接照搬需警惕统计口径差异。

    正在评估 Meta Muse 的选型或投资方,应把 600,000 日活当成 Apptopia 的美国区估算、而不是官方口径,再决定是否拿它和自家产品的活跃规模直接比较。

    展开全文

    依据

    Meta 的 Superintelligence Labs 产品负责人 Nat Friedman 在 X 上写,Muse 是 from scratch(从零)构建的;但他同时承认这款产品 heavily inspired by(强烈受启发于)OpenClaw,团队沿用了后者的核心文件命名和人格文档里的句子,理由是原作者 Steinberger 把这些做对了。社媒用户则指控 Muse 只是 OpenClaw 外面套的 wrapper app(包装应用),并称它继承了同样的安全风险。机制上,争议点不是代码有没有被复制,而是 Meta 用日活证明需求、又用「从零」证明自主可控,这两件事被同一个数字绑在一起:600,000 美国日活,来源是 Apptopia 估算。材料给出的另一处对照是,OpenClaw 用 10 个月把 AI agent 从概念验证推到真正可用。

    1. OpenClaw 出圈
      启发后试用
    2. Meta 采购 Mac Mini
      沿用文件命名
    3. Muse 上线沿用命名
      社媒指控后
    4. Meta 否认直接基于它
    从试用 OpenClaw 到 Muse 上线、再到 Meta 出面否认的因果链

    没写清 材料没有 OpenClaw 官方的日活,也没有 Muse 的留存或非美国区数据,所以无法判断 600,000 在同类产品里处于什么位置。

    下一步 等 Meta 官方公布 Muse 的活跃口径,或 Apptopia 更新这份估算时,再回来核对这 600,000。

AI工具

3 条

  1. 我觉得我找到了一个值得冒险的AI Agent

    AI工具Wired AI

    我觉得我找到了一个值得冒险的AI Agent
    省550美元也白花64美元,安全风险得自己掂量。

    给不给 AI 代理开放邮箱和日历读取权限,这次该按下限来定,而不是按它代办成功的次数来定。省下的 550 美元和浪费的 64 美元出自同一次授权,退款的触发条件只是它读到了一条你自己会漏掉的航班变动。

    展开全文

    依据

    Wired 记者 Zoë Schiffer 记叙她试用仅限邀请的 AI 代理 Instinct:她把一趟纽约行程交给它取消,Instinct 发现阿拉斯加航空把她的航班提前了 90 分钟——她自己漏掉了这件事——这让她符合全额退款条件,于是退票、省下约 550 美元,并重订了回旧金山的单程票。她也写明这次使用浪费了 64 美元。机制上,Instinct 走 iMessage 和 WhatsApp 与你对话,接上邮箱、日历和消息应用,由它先提出能代办的事再执行,而不是让你自己想出要它做什么。材料里的对照是 Meta 本月推出的助手 Muse:它同样能替你打电话订餐厅,但据 404 Media 报道,其中一些电话由呼叫中心的人打。

    • 退票省下550 美元
    • 浪费64 美元
    • 航班被提前90 分钟
    同一次使用里省下的 550 美元、浪费的 64 美元,以及触发退款的 90 分钟航班变动。

    没写清 断开邮箱后仍留副本的说法只以「有人报告」出现,材料没写是谁报告的、怎么验证,也没说那 64 美元浪费在哪个任务上。

    下一步 查 Instinct 的隐私政策是否写明解除连接后收件箱副本的删除时限。

  2. AI工具AWS Machine Learning Blog

    使用AgentCore Gateway和MCP构建多账户AI agent
    多账户隔离数据下做跨账户查询,代价是MCP服务与细粒度授权都得自己搭。

    架构负责人应把 AgentCore Gateway 当作跨账户查询的唯一入口,而不是让每个 agent 各自持有对方账户凭证;代价是自建 MCP 服务与细粒度授权要写进工期。

    展开全文

    依据

    AWS Machine Learning Blog 的标题给出做法:用 AgentCore Gateway 和 MCP 构建多账户 AI agent;策展点评则点出代价:多账户隔离数据下要做跨账户查询,MCP 服务与细粒度授权都得自己搭。机制上,AgentCore Gateway 把 agent 的工具调用收敛到统一入口,MCP(Model Context Protocol,模型上下文协议)把各账户里的数据或操作包装成可授权工具;否则 agent 只能靠跨账户 IAM(Identity and Access Management,身份与访问管理)角色直连,权限会散落在每个调用方。材料没有给账户数量、跨账户查询延迟或授权粒度数字,因此不能替它算出自建 MCP 与授权的成本。

    没写清 材料没说 AgentCore Gateway 对跨账户工具调用的授权粒度能细到账户、表、字段还是行,也没给 MCP 服务的部署与运维工作量。

    下一步 下一步可核对 AWS 文档中 AgentCore Gateway 的 MCP 集成是否支持按工具或按账户下发授权策略,并确认多账户示例的 IAM 角色边界。

  3. AI工具AWS Machine Learning Blog

    Aderant利用Amazon Nova构建智能工单分诊
    Aderant把工单分类交给Nova Lite,云运维团队能省人力但需自建流程

    云运维负责人不能拿这篇当自建工单分类的依据:材料里既没有 Aderant 的工单量,也没有分类准确率或低置信度转人工的比例。

    展开全文

    依据

    AWS Machine Learning Blog 这篇《Aderant builds intelligent ticket triage with Amazon Nova》,抓到的正文几乎全是 AWS 站点的导航文案——产品目录、行业解决方案、定价入口、培训入口,没有出现 Aderant 的工程师或 AWS 方的发言,也没有任何可引用的对照数字。策展句说 Aderant 把工单分类交给 Nova Lite(AWS 的轻量基础模型系列),云运维团队省人力但要自建流程,这是策展判断,材料本身没给支撑。从机制上讲,工单分类能省下多少人力,取决于两件事:模型把工单分到正确队列的准确率,以及低置信度工单被转回人工的比例——准确率再高,只要这个比例没降下来,人力就省不掉,反而多出一层标注和复核。这两项材料都没写。

    没写清 材料没说 Aderant 原来有多少工单、分类准确率是多少、低置信度工单怎么转人工。

    下一步 等这篇 AWS 博客正文或 Aderant 在 re:Invent 的分享公布工单量与分类准确率,再算自建流程划不划算。

精选深读

2 条

  1. Google的Gemini现在可以在Pixel手机上为你打电话

    精选深读Wired AI

    Google的Gemini现在可以在Pixel手机上为你打电话
    Gemini代打电话限Pixel 11,便利背后是隐私与误拨风险谁担

    Pixel 11 用户要先决定:哪些商家查询交给 Gemini 代拨,以及是否全程盯实时转录;Google 则要决定误拨、口音失败和机器人对机器人通话时由谁负责。

    展开全文

    依据

    WIRED 的 Julian Chokkattu 写道,Google 周四发布 Call for Me(代我致电),这是仅限美国英语 Pixel 11 系列的实验性公开测试功能;用户需有 Gemini 订阅并加入 Phone by Google 应用的公开测试(public beta)。机制是:你让 Gemini 打电话,它可能先追问细节,然后向商家自我介绍并来回沟通,遇到自动菜单会导航、遇忙会等待,你可在 Pixel 上查看实时转录并随时接管。Google 发言人对 WIRED 说,他们想继续测试各种情况,以改进口音和嘈杂环境下的表现;若商家无法满足需求,Gemini 会礼貌挂断。对照是 Google 近 10 年尝试代打电话:Duplex(Google 早期代打电话服务)曾让 Google Assistant 打电话订餐厅,后来关停,如今由大语言模型驱动的新一轮。

    1. 你向 Gemini 提出致电
      补充细节
    2. Gemini 追问补充信息
      开始外呼
    3. Gemini 拨打并自我介绍
      遇菜单
    4. 导航菜单或等待
      实时转录
    5. 你查看转录并接管
    Call for Me 从用户下令到人工接管的通话流程

    没写清 材料没给 Call for Me 的误拨率、通话录音与转录保存多久、谁能调取,所以无法替 Google 划定隐私责任和挂断边界。

    下一步 下一步看 Google 是否公布 Call for Me 在口音与嘈杂环境下的测试结果,以及录音/转录留存政策。

  2. 精选深读Google DeepMind

    推出Gemini 3.8 Live与Live Avatar
    Gemini 3.8 Live主打实时交互,官方更新能否兑现低延迟体验仍需实测。

    企业客服与互动导览团队,可以不再按「先等工具返回再开口」设计话术,Live Avatar 把取数挪到对话后台并行。于是采购方的决定点从「用不用」移到「延迟与断流责任怎么写进验收条款」。

    展开全文

    依据

    Google DeepMind 的 Gemini Audio Team 在 9月24日 的发布中,由 Shuo-yiin Chang(Research Scientist)与 CJ Zheng(Software Engineer)署名介绍 Live Avatar,即给对话式 AI 加上实时视觉形象的特性。机制是把低延迟流式视频与原生实时对话能力耦合:一边处理视觉与音频输入,一边输出带唇形与表情的音视频回应。第二层是异步工具调用(asynchronous tool calling),工具在后台取数时对话不中断,官方举的例子是酒店入住登记。多语言部分是原生语音到语音同步,唇形与表情动态适配,可无缝切换 97 种语言而不降低视频保真度、不引入视觉漂移(visual drift)。今日起在 Gemini Enterprise 可用,而上一周才发布 Gemini 3.8 Live。

    1. 视听输入
      同时处理
    2. 生成语音与视频
      对话不中断
    3. 后台工具调用
    Live Avatar 在对话中同时处理视听输入并后台取数的链路

    没写清 材料只写 near real-time,没有给出延迟、帧率或并发上限的任何数字,「低延迟是否兑现」这一块不能替它补。

    下一步 在 Gemini Enterprise 里用同一段含语种切换的对话复跑,记录切换发生时唇形是否出现漂移。