∞ Perplexity Computer将支持在本地与云端AI模型之间自动分配任务
Perplexity Computer 将在今年夏天迎来一项重要升级：支持在本地与云端 AI 模型之间自动分配任务，实现更兼顾隐私保护与计算性能的混合推理能力。
Perplexity 表示，Perplexity Computer 是公司用于“替用户完成实际工作”的智能体系统，即通过自动化编排不同模型和工具来处理复杂任务。 即将上线的新功能，将允许该系统根据任务类型与数据敏感程度，在设备本地运行的紧凑模型和云端更强大的前沿模型之间智能切换。 官方介绍称，这样的设计旨在在处理敏感数据时尽量留在本地，同时在需要强算力时又能无缝调用云端模型，从而在安全性与效率之间取得平衡。
据介绍，在新的“混合智能体推理”（hybrid agentic inference）模式下，涉及财务记录、健康信息及个人文件等敏感内容的工作，将优先由运行在用户设备上的本地小型模型来判断哪些数据必须严格保留在本地处理。 与此同时，那些对隐私要求不高、但需要更强推理和大上下文能力的任务，则会被自动分派给云端的前沿模型执行。 Perplexity 强调，大多数现实世界任务往往同时包含敏感和非敏感部分，因此系统会自动将任务拆分成若干子任务，并在本地与云端之间进行协同调度，而不是要求用户事先在“本地”或“云端”模式中二选一。
Perplexity 在社交平台 X 上发布的视频中进一步展示了这一混合架构的理念，称 Perplexity Computer 能在保证隐私数据留在设备上的前提下，最大化利用云端模型的上下文窗口和算力，同时优化 token 使用效率。 官方消息显示，该混合 AI 编排功能计划于 7 月正式向 Perplexity Computer 用户推出。
∞ 微软推出开源规范 协助开发者精细管控AI代理行为
微软正尝试用一套全新的开源标准，帮助企业在不同系统和应用中更可控地部署功能日益强大的 AI 代理（AI agents）。 这套名为“Agent Control Specification”（代理控制规范，简称 ACS）的标准，旨在为开发者提供一种更一致、更细粒度的方式，去限定 AI 代理“能做什么、不能做什么，以及何时必须有人类介入”。
随着企业加速把 AI 代理嵌入各类应用、工作流和产品，一个突出难题是：同一个代理在不同环境中运行时，如何确保其行为始终符合预期和合规要求。 目前，开发者往往通过系统提示词、在应用代码中加入自定义校验，或利用分类器拦截问题输入输出等方式“拼接式”地搭建控制机制。 这些做法在短期内可以工作，但很容易导致控制策略分散在不同框架和接口中，既难以审计，也难以在多个系统之间复用。 在行业反思 AI 工具调用错误、意外操作引发连锁故障等问题的背景下，这一痛点愈发突出。
微软表示，ACS 的目标是把分散的控制手段整合到一个统一的治理层中，让开发、替换正文合规和安全团队可以通过一份策略文件来约束代理行为。 在这些策略文件中，团队可以明确规定：代理允许执行哪些操作、禁止执行哪些操作、在什么情况下需要人类审批，以及需要记录哪些证据以备日后审查。 在代理执行任务的多个关键“拦截点”，系统会对照这些策略进行检查，以确保代理始终在“护栏”之内运行。
具体而言，ACS 允许在代理工作流的多个阶段实施检测：包括代理接收输入之前、调用工具之前、工具返回结果之后，以及向用户输出最终回复之前。 策略可以在这些节点上给出不同处置：例如直接允许某个动作、阻断执行、对敏感信息进行脱敏或遮盖，或者将决策提交给指定人员审批。 除此之外，开发者还可以集成输入和输出分类器，对信息进行分类、预测可能结果或指导代理如何回应；也可以引入大型语言模型配合特定提示词，让其充当策略“裁判”，并加入检查工具调用、工具选择、输入准确性、输出使用方式以及回复内容的逻辑。
ACS 的一大设计思路，是将这些控制策略写成独立、可移植的单一文件，并与代理一同“打包”。 这样一来，同样的一套安全与合规策略可以随代理在不同框架和运行环境之间迁移，而无需反复重写规则逻辑，从而增强了跨系统的一致性和可审计性。 对于在多个业务线、多个技术栈中并行推进 AI 部署的大型企业而言，这种“策略随代理走”的模式，有望在降低治理成本的同时，提升合规透明度。
在落地形态上，ACS 以 SDK 形式提供，并已集成到多个主流代理框架和开发工具中。 据介绍，ACS SDK 目前支持 LangChain、OpenAI Agents SDK、Anthropic Agents SDK、AutoGen、CrewAI、Semantic Kernel、Microsoft.Extensions.AI 以及 MCP 工具等生态。 通过这些插件，开发者可以在既有的代理应用中接入 ACS，将策略文件嵌入原有工作流，无需从头重构系统架构。
在 AI 代理快速渗透企业业务的当下，如何在“可用”“好用”和“可控”“可审计”之间找到平衡，已经成为技术团队、合规部门与安全团队共同面对的现实课题。 微软此次推出的 Agent Control Specification，试图以开放标准的方式，为行业提供一套统一的治理基础设施，使 AI 代理在不同场景中运行时，既能保持灵活性，又能够被清晰地约束和追责。
∞ Google在Android上推出“假电话检测”功能 应对AI换脸冒充诈骗
Google当地时间周二宣布，Android系统将上线一项“假电话检测”（Fake Call Detection）新功能，用于防范利用AI深度伪造技术进行的来电冒充诈骗。该功能将通过“Google 电话”应用在本月面向全球Android 12及以上设备推送，首先覆盖Pixel手机。
随着越来越多用户拒接未知号码来电，骗子开始调整手法，通过伪装可信号码并利用AI深度伪造技术，模拟权威人士、家庭成员或雇主的声音实施诈骗。比如，受害者手机上显示来电人为“妈妈”，对方声音也与母亲极为相似，但实际上是骗子使用AI工具伪造身份，以紧急情况为由诱导转账汇款。
Google表示，“假电话检测”功能默认开启，在后台自动运行，无需用户额外设置。其工作原理类似于设备之间的“数字握手”。当通讯录联系人向用户拨打电话且双方均使用“Google 电话”应用时，对方手机会向用户设备发送一段静默确认信号，用于验证来电确实源自联系人本人设备。一旦有骗子试图冒充可信联系人，这一初始确认信号将缺失。用户手机在检测到异常后，会主动向该联系人的真实设备发出二次确认请求；如对方设备反馈“当前并未拨打电话”，用户屏幕上就会出现警示，建议立即挂断来电。
Google指出，该功能构建在富通信服务（RCS）之上，使其他应用和企业在技术上也可以采用类似方案，从而在更大范围内提升来电安全性。
在发布“假电话检测”功能的同时，Google还宣布了多项Android平台更新。其中，Google 相册即将上线一项名为“衣橱”（wardrobe）的新功能，允许用户在照片库中对日常穿搭进行归档，并以快照形式浏览、混搭并“虚拟试穿”不同服饰组合。该功能计划于下周向美国、印度和巴西的符合条件用户推出，支持Android 10及以上版本。
此外，Google Play 图书新增了“Catch me up”功能，帮助用户在中断阅读后通过简要回顾快速重新进入故事情节。用户还可以高亮标注某段内容并发起提问，以获得与该段落相关的互动式解读，这些功能今日起率先在部分英文书目中开放。
Google同时扩展了“圈选即搜”（Circle to Search）的能力，使其支持对整套穿搭进行识别搜索。用户只需圈选画面中的一整套服装，系统即可一次性识别并搜索其中的所有单品，而无需逐件搜寻。这项更新现已在搭载Android 14且支持“圈选即搜”的设备上全面推送。
∞ 微软发布企业级个人智能代理Scout 深度集成Microsoft 365 Copilot
微软近日正式推出一款面向企业客户的全新个人智能代理 Microsoft Scout，并将其集成进 Microsoft 365 Copilot 应用，同时提供 Windows 与 macOS 桌面端版本，目前已开始向 Microsoft 365 Frontier 客户推送。
Scout 基于近来颇受关注的个人 AI 助理项目 OpenClaw 架构打造，后者不同于传统只回答问题的聊天机器人，更侧重代替用户执行具体操作，例如管理邮件、处理日程以及通过 WhatsApp、Telegram 等消息应用与他人互动。 通过引入这一理念，微软希望将类似的“代办型”智能助理能力引入工作场景，让 Scout 成为职场环境中的常驻个人代理。
与传统需要用户主动下达指令的助手不同，Scout 被定位为“始终在线”的自治式工作代理，它可以根据用户的工作上下文主动处理日常事务，而无需每次都等待用户发出明确请求。 Scout 构建在 OpenClaw 框架之上，同时叠加了微软自家的 Work IQ 智能层，为企业内部场景提供更强的上下文理解和决策支持。
Work IQ 被微软描述为一个基于数据、记忆与推理的智能层，能够连接企业内部及个人相关的数据来源，包括 SharePoint 文件、Outlook 邮件和 Teams 会议等。 在此基础上，系统还会围绕用户的偏好、习惯与工作流程构建个性化记忆，使各类 AI 代理在企业环境中可以提供更贴合个人需求的响应和行动方案。
在具体功能方面，微软强调 Scout 可以帮助企业用户准备即将召开的会议，主动识别并解决日程冲突，并在无需反复提示的情况下处理一系列日常任务。 官方列出了 Scout 的几大核心能力：它可以在用户工作空间内对文档“主动动手”，包括创建、编辑以及搜索各类文件，覆盖 Word、Excel、PowerPoint、代码文件等多种类型。 此外，Scout 还能执行命令行操作，用于构建、测试和运行脚本，并通过分级权限控制机制保障安全性。
在自动化操作方面，Scout 可借助 Playwright 对浏览器进行自动化控制，完成网页导航、表单填写以及与各类 Web 应用的交互。 与 Microsoft 365 深度集成则使其能够统一管理用户的电子邮件、日历、Teams 消息、OneDrive 文件以及各类会议活动，形成围绕办公套件的一体化智能中枢。
作为一款自治式代理，Scout 支持按照用户预先设定的计划任务或触发条件在后台自动运行，减少人工介入。 在处理更复杂的工作量时，Scout 还可以“委派任务”，启动专门的子代理并行完成诸如研究调研、代码审查以及多步骤复杂业务流程等工作，从而提升整体执行效率。
微软表示，随着 Scout 能力的不断扩展并逐步面向更多客户开放，将会陆续披露进一步的技术细节和应用案例。 与此同时，在今年的 Google I/O 2026 开发者大会上，Google也发布了名为 Gemini Spark 的全天候个人 AI 代理，同样主打在用户授权与指引下主动管理任务并代为执行操作。 Gemini Spark 基于 Gemini 3.5 和 Google 的 Antigravity 平台，能够在后台运行并联动 Gmail、Docs、Slides 等Google生产力工具，这意味着围绕“主动型个人智能代理”的竞争，正在微软与Google之间加速展开。
∞ 苹果或暗示下代 macOS 将命名为“Big Bear”
苹果在为全球开发者大会（WWDC）2026 预热的社交媒体物料中，疑似提前埋下了下一代 macOS 27 命名的线索，引发业界关注。据介绍，一位名为 Andreas Storm 的设计师在社交平台 X 上发现，在 #WWDC26 等话题标签旁边显示的苹果发光 Logo 小图标（所谓“hashmoji”）本身并不特别，但其底层图片文件名却颇为耐人寻味。
该图片文件名被标注为“Project_Big_Bear_2026_Hashmoji_only.png”.在 OS 命名上，苹果近年来一直采用加州著名地名作为 macOS 正式版本名称，例如 macOS Tahoe 就源自加州的太浩湖（Lake Tahoe）。报道指出，在这一命名传统下，同样位于加州南部圣贝纳迪诺山脉的 Big Bear Lake（大熊湖），无论从地理位置还是知名度来看，都十分符合苹果的既有命名逻辑，因此“Big Bear”被认为是 macOS 27 的热门候选名称之一。
不过，仍有分析认为，这一名称出现在文件名中，可能只是苹果内部项目代号意外“外露”，并不必然对应最终的市场推广名称。此前有苹果高管在采访中提到，苹果在产品开发阶段会长期使用内部代号，而面向市场的正式名称往往要到发布前才在公司内部有限范围内确定。在此背景下，也不排除苹果有意利用这一“泄露”制造话题或刻意放出的“烟雾弹”。
AppleInsider 指出，苹果非常清楚外界对其未来产品动向的高度敏感和“挖线索”的热情，因此类似命名线索究竟是无心疏漏还是精心设计，目前尚难下结论。如果“Big Bear”最终未被采用，苹果仍有大量加州地名可供选择，包括编辑提到的 Redwood、Mono、Shasta、Almanor、Donner、Oroville、Tulare 等多个湖泊或地标名称，均可能成为 macOS 27 或后续版本的候选名字。
当前距离 WWDC 主旨演讲还有一周时间，macOS 27 的正式命名预计将由 Craig Federighi 按照惯例在发布会上“揭晓”，届时“Project Big Bear”究竟是内部代号、营销伏笔，还是一次成功的“障眼法”，也将水落石出。
