Google Look up 偷跑：选中文本即可查词、看地图、追航班

谷歌面向 Googlebook 平台开发的上下文工具 Look up，于 2026 年 9 月 2 日短暂出现在 Google Play 商店，随后页面和应用详情被官方撤下。根据 IT之家援引 9to5Google 的测试，这款应用虽然定位为桌面端工具，但目前已经可以在手机上安装运行。

Look up 是一款基于选中文本提供即时信息的上下文搜索工具。它不要求用户离开正在阅读的网页、文档或聊天窗口，而是在当前页面上方打开浮动结果窗口，直接调用 Google Search、Google Maps 和 Google Flights 等服务返回答案。

这不是一次普通的“搜索框换皮”。谷歌真正想做的是把搜索入口从浏览器地址栏和独立 App 中拿出来，放到用户正在处理的内容旁边：看到一个陌生术语，可以直接查词义；读到一个地名，可以查看地图；看到一串航班信息，可以继续确认航班状态；如果第一轮结果不够，还能在浮动窗口底部继续追问。

一次偷跑，透露 Googlebook 的产品方向

Look up 的软件包名是 com.google.android.desktop.contextualtools，名称里同时出现了 desktop 和 contextualtools，基本对应它的产品定位：桌面端上下文工具，而不是一个传统意义上的独立搜索应用。

Googlebook 是谷歌此前公布的新笔记本电脑平台，目标是把 ChromeOS 与 Android 的部分能力整合到同一套设备体验中。首批产品预计在 2026 年秋季推出，Look up 则是继相机应用之后，第二个提前曝光的 Googlebook 配套功能。

从目前泄露的交互来看，Googlebook 并不只是给 ChromeOS 换一个名字。谷歌正在尝试把 Android 生态里已经成熟的能力，重新组合到笔记本的窗口、键盘和多任务环境中。相机应用负责把手机式能力带到桌面端，Look up 则负责把搜索、地图和航班等服务嵌入桌面工作流。

这条路线很明确：用户不应该为了一个小问题打断当前任务。桌面系统过去的默认逻辑是“复制文本—打开浏览器—粘贴—搜索—返回原页面”，Look up 试图把这五步压缩成“选中—查看”。对于经常阅读论文、处理邮件、查资料或规划出行的人来说，减少应用切换比单纯提高搜索结果质量更有价值。

它具体能做什么

Look up 的核心能力是对选中文本进行上下文查询，并在浮动窗口内返回与文本相关的结果。这里的关键不是“能搜索”，而是它能根据文本形态把请求分流给不同的谷歌服务。

目前已展示的服务来源包括 Google Search、Google Maps 和 Google Flights，覆盖了三类高频场景：

• 词义和事实查询：选中术语、人名、产品名称或一段短文本后，通过 Google Search 查看解释、背景和相关网页。
• 地点信息查询：选中城市、机场、景点或地址后，调用 Google Maps 查看位置、路线和周边信息。
• 航班动态查询：选中航班号、航线或相关行程信息后，调用 Google Flights 查看航班状态等内容。

Google Search 是谷歌的网页搜索服务，主要负责从开放网页中补充事实、定义和背景信息。Google Maps 是谷歌的地图与地点服务，主要负责地理位置、路线和地点详情。Google Flights 则是谷歌的航班搜索服务，可用于查看航班、票价和部分行程信息。

相比单独打开三个 App，Look up 的优势在于它能够保留用户原本的上下文。比如，用户正在阅读一篇关于英伟达的文章，选中“Blackwell”后可以直接查看解释；文章接着提到“台北”，选中地点即可查看地图；如果邮件里出现“CA 123”这样的航班编号，也可以继续查询航班动态，而不用先判断应该打开哪个应用。

更重要的是，结果页底部还提供了类似聊天机器人的输入框。用户查看第一轮结果后，可以继续提出问题，把一次性的关键词查询扩展成多轮对话。

例如，用户先选中“巴黎戴高乐机场”，Look up 返回地点信息后，还可以继续追问“从这里到市中心最快怎么走”；选中某个航班后，可以继续问“这个航班预计几点到达”；选中一个专业术语后，则可以继续问“它和 Transformer 有什么区别”。这使 Look up 从“搜索快捷方式”变成了一个附着在当前内容上的轻量研究助手。

真正的变化不是搜索，而是搜索入口

Look up 的产品价值在于，它把搜索从一个主动行为变成了阅读过程中的即时动作。

传统搜索需要用户先意识到“我需要查一下”，然后离开当前内容、组织关键词、选择搜索服务，再回到原页面。这个流程对复杂问题并不算长，但对“顺手确认一下”的小问题来说，切换成本往往高于问题本身，很多用户最终会放弃查询。

Look up 试图解决的就是这类摩擦。它更像浏览器里的即时释义、操作系统里的右键菜单和 AI 助手的结合体：入口足够近，结果足够轻，用户不必为每一个小问题建立新的工作流。

对于开发者和深度用户，这种能力尤其适合以下场景：

1. 阅读技术文档时查概念：选中一个库名、协议名或错误信息，直接查看搜索结果与解释。
2. 处理跨语言资料时补充背景：选中英文术语或缩写，快速确认它在具体上下文中的含义。
3. 整理会议和邮件信息时确认地点：选中公司、会议场馆或机场，快速查看地图位置。
4. 规划出行时核对航班：选中邮件、日历或聊天中的航班号，直接确认航班状态。
5. 边看网页边追问：第一轮查询后继续问细节，避免反复复制上下文。

它并不会替代完整的浏览器搜索，也不会替代专业航班追踪服务。它更适合处理短、快、依赖当前上下文的问题，而不是一次性完成深度研究。

与独立航班追踪工具相比，Look up 仍然偏轻

Look up 可以调用 Google Flights 查询航班相关信息，但这并不意味着它会取代 FlightAware 这类专业航班追踪服务。

FlightAware 是提供全球实时航班追踪、航班状态、航线查询和航空运行数据的专业服务，用户可以通过航班号或航线查询飞机位置、机场活动和航班趋势。相比之下，Look up 的航班能力更像是“在已有内容中快速核对”，重点是降低查询门槛，而不是提供面向航空爱好者、机场运营人员或差旅管理者的完整监控能力。

| 对比维度 | Google Look up | Google Flights | FlightAware | |---|---|---|---| | 产品定位 | 桌面端上下文查询工具 | 航班与票价搜索服务 | 专业航班追踪服务 | | 主要入口 | 选中文本后呼出 | 独立网页或服务入口 | 独立网页、地图和航班查询入口 | | 典型输入 | 航班号、地点、术语等选中文本 | 出发地、目的地、日期、航班 | 航班号、航线或飞机信息 | | 主要价值 | 不离开当前页面，快速确认信息 | 搜索航班、比较票价、追踪价格 | 查看实时航班动态和航空运行数据 | | 多轮追问 | 已展示支持 | 不是核心交互 | 不是核心交互 | | 适合用户 | 普通用户、办公用户、知识工作者 | 旅行规划者 | 航空爱好者、差旅和航空行业用户 |

Google Flights 官方帮助文档显示，用户可以追踪特定航班、航线和日期的票价，并在价格变化时接收通知。Look up 当前披露的重点则是选中文本后的即时查询，两者解决的问题并不完全相同：前者强调持续追踪和价格变化，后者强调当前页面中的快速确认。

因此，Look up 的竞争对象不只是 Google Search，还包括浏览器右键菜单、系统级搜索、AI 浏览器侧边栏以及各种“划词搜索”工具。它的机会在于把谷歌多个服务统一到一个入口，风险则是浮动窗口很容易变成另一层打扰。

多轮追问是亮点，也是最值得观察的部分

Look up 的聊天输入框说明谷歌并不满足于展示传统搜索结果，而是希望让用户在上下文中继续对话。

但“能追问”不等于“理解上下文”。真正决定体验的，是系统能否正确保留三种信息：用户选中的原文、当前页面的语境，以及上一轮搜索返回的结果。如果用户选中的是一个多义词，Look up 是否能结合上下文判断含义；如果文本包含多个航班号，系统是否能识别用户具体想查哪一个；如果用户追问“那附近有什么酒店”，它是否知道“附近”指的是刚才的地点——这些才是产品是否好用的分水岭。

从产品设计上看，谷歌拥有一个天然优势：Search、Maps 和 Flights 本来就掌握不同类型的结构化数据。Look up 不需要把所有问题都交给通用聊天模型处理，而是可以先识别实体，再调用更适合的服务。这种“模型负责理解，垂直服务负责给数据”的组合，理论上比单纯让聊天模型生成答案更稳定。

不过，谷歌目前没有公开 Look up 的正式技术架构、模型名称、支持的设备范围，也没有说明航班信息的更新时间、数据覆盖区域和结果延迟。现阶段不适合把它描述成一个完整的 AI Agent，更准确的说法是：它是一个带有多轮追问能力的上下文搜索界面。

Googlebook 需要解决的，不只是功能有没有

Look up 目前最大的未知数，是它最终会以什么权限和系统形态进入 Googlebook。

如果它只能在特定应用中使用，价值会明显下降；如果它可以读取任意窗口中的选中文本，就需要处理更复杂的隐私和权限问题。邮件、企业文档、代码仓库和内部聊天记录都可能包含敏感信息。用户选中文本后，系统是否会把完整句子、页面标题、网址甚至周围内容发送给谷歌服务，需要在正式发布时解释清楚。

第二个问题是结果窗口的控制权。浮动窗口如果出现得太慢，用户会觉得不如直接搜索；如果出现得太频繁，用户会觉得系统在抢焦点。谷歌需要在选中文本、右键菜单、键盘快捷键和自动识别之间找到平衡，也需要让用户能够关闭某些服务或限制数据访问范围。

第三个问题是跨平台一致性。参考测试显示，偷跑版本可以在手机端安装，但这更可能是 Android 兼容性或测试包未做严格设备限制的结果，不能据此判断 Look up 会以同样方式面向手机发布。它的真正价值仍然取决于桌面端能否融入键盘、鼠标、多窗口和系统剪贴板工作流。

第四个问题是信息的新鲜度。航班状态、地图地点和票价都是实时变化的信息，结果如果存在明显延迟，就会影响用户信任。尤其是航班场景，显示“已起飞”“延误”或“预计到达”时，产品需要明确数据更新时间和信息来源，而不能让用户把一个即时搜索卡片误认为专业运行监控系统。

谷歌正在把“上下文”做成操作系统能力

Look up 的出现，说明上下文计算正在从 AI 应用层下沉到操作系统层。

过去，AI 助手通常需要用户主动打开，再输入完整问题；现在越来越多的产品开始围绕“用户正在做什么”设计入口。选中文本、当前网页、剪贴板内容、鼠标位置、窗口类型，都可能成为调用 AI 或搜索服务的触发条件。

这对 Googlebook 的意义很大。新平台如果只提供一套新的桌面界面，很难与成熟的 Windows、macOS 和 ChromeOS 拉开差距；但如果它能把搜索、地图、相机、Android 应用和 AI 助手组合成一套低摩擦的工作流，就有机会形成自己的差异化。

当然，谷歌面临的竞争也很直接。微软已经把 Copilot 深度放入 Windows，苹果则在系统层持续强化 Spotlight、视觉智能和跨应用能力，各类 AI 浏览器也在尝试读取当前网页并提供侧边栏问答。Look up 的优势是谷歌搜索和本地服务数据的组合，短板则是产品还没有正式发布，功能边界、可用地区、隐私政策和系统兼容性都没有最终确认。

OpenAI Hub 判断：方向对，但现在还不能把它当成杀手级功能

Look up 是一个方向正确、但仍处于早期验证阶段的产品更新。

它最有价值的地方，不是把 Google Search、Maps 和 Flights 放进了一个窗口，而是让用户可以围绕当前内容连续完成“识别—查询—追问”。对于日常办公和资料阅读，这种体验可能比一个功能更多的独立 AI 助手更实用，因为用户不需要改变工作状态。

但它目前还谈不上杀手级功能。第一，官方尚未正式发布，应用只是短暂出现在 Play Store，很多交互仍可能属于内部测试。第二，手机端可以安装并不代表手机端会正式支持。第三，谷歌尚未公开模型、延迟、数据来源、隐私机制和地区限制。第四，航班追踪只是轻量查询，不能与 FlightAware 等专业服务的实时运行数据相提并论。

更现实的判断是：Look up 可能成为 Googlebook 上一个高频但不喧宾夺主的系统能力。它不会让用户为了一个浮动搜索框立刻购买新设备，却可能在用户已经使用 Googlebook 后，逐渐改变他们查资料、读邮件和规划行程的方式。

截至 2026 年 9 月 3 日，谷歌尚未公布 Look up 的正式发布日期、完整功能清单和面向消费者的支持范围。接下来最值得关注的不是它能否再次出现在应用商店，而是 Googlebook 首批产品发布时，Look up 是否已经成为系统默认能力，以及它能否真正做到“查完就走、追问也顺手”。