Mercury 3 发布，AI 响应提速能改变哪些交互？

AI 的回答是否及时，要看用户正在做什么。阅读一份报告时，用户通常可以等几秒再继续；语音交谈却需要及时回应，过长的停顿会打断对话。智能眼镜也有类似的要求，用户提出问题时，注意力往往仍在眼前的事物上。如果答案迟迟没有返回，用户就不得不暂停手头的事情，专门等待系统。响应速度影响的，因而不只是等待多久，还包括 AI 能否配合用户原本的行动节奏。

2026 年 10 月 19 日，语言模型公司 Inception 发布 Mercury 3，将低延迟作为主要卖点之一。按照官方数据，新模型的生成速度超过每秒一千 token，目前已经通过 API 及 Vercel 等平台开放。公告同时列出了浏览器 Agent、实时辅导、搜索和客户服务等合作方应用。

每秒一千 token 描述的是模型生成文本的速度，却不能直接回答用户需要等多久。一次完整请求还可能经过检索、工具调用和数据传输。输出阶段再快，也不代表前面的准备已经结束。用户感受到的是从提出要求，到获得可用结果之间的完整间隔。

为智能眼镜提供搜索能力的 Octen AI 给出了另一组更接近产品体验的数据。该公司在官方公告中介绍，Sense API 测试里的搜索耗时约为 80 毫秒，Mercury 3 的模型生成耗时中位数为 0.9 秒，端到端响应中位数则是 2.2 秒。这些数字来自合作方自述，不是独立测评，但它们呈现了一个重要区别。模型速度只是完整响应中的一部分，产品是否回应及时，仍要沿着整条请求过程判断。

低延迟模型的价值，也不完全体现在用户阅读文字时。浏览器 Agent 每执行一段操作，都可能需要再次调用模型，判断页面状态，再决定下一步。单次请求减少的等待，会在连续步骤中累积。

对 UI／UX 设计师而言，响应速度会影响设计师如何安排操作流程。如果一次请求需要等待较长时间，产品更适合让用户先处理其他事情，完成后再通知；如果系统能够迅速回应，用户就可以在当前界面中连续尝试，根据结果调整要求，不必每提出一个想法都中断操作。低延迟带来的设计空间，在于让原本分散的“提交、等待、查看结果”，有机会成为一段连续的交互。

要判断这种交互是否可行，设计团队需要测量用户实际经历的等待，而不只是模型生成文字的速度。眼镜搜索应当记录从用户发问到获得可用答案的时间；浏览器 Agent 则应当记录完成整项任务的总耗时，因为一次任务可能包含多轮模型调用和页面操作。比较速度时，还必须确认结果是否正确、任务是否完成。更快地输出内容，与更快地解决用户的问题，不能视为同一件事。

目前，Mercury 3 公布的数据主要来自厂商和早期合作方。中位数也没有说明复杂请求或较慢请求会等待多久，更不能成为所有接入产品的响应承诺。它提供的是一个值得实际检验的新条件，而不是已经完成的体验保证。