WEBVTT
Kind: captions
Language: zh

00:00:00.166 --> 00:00:02.333
谷歌刚刚改掉了语音AI里

00:00:02.333 --> 00:00:04.066
一个很不起眼的信号

00:00:04.166 --> 00:00:06.933
过去系统发出turn complete

00:00:07.266 --> 00:00:09.733
开发者就知道这一轮结束了

00:00:09.766 --> 00:00:11.766
可以收尾释放状态

00:00:11.766 --> 00:00:13.533
等用户说下一句话

00:00:13.600 --> 00:00:16.566
到了Gemini3.8 live EXTENDED thinking

00:00:17.100 --> 00:00:19.733
这个信号不再代表模型已经停下

00:00:19.800 --> 00:00:21.533
它可能还在后台推理

00:00:21.600 --> 00:00:23.266
可能正在调用工具

00:00:23.333 --> 00:00:25.900
也可能过几秒又送回一段语音

00:00:25.933 --> 00:00:27.933
一个看似普通的协议变化

00:00:27.966 --> 00:00:29.466
留下了真正的问题

00:00:30.166 --> 00:00:32.366
如果AI已经能一边和人说话

00:00:32.466 --> 00:00:34.200
一边在后台继续工作

00:00:34.366 --> 00:00:35.866
它还是语音助手

00:00:35.900 --> 00:00:36.900
还是一个藏在

00:00:36.900 --> 00:00:38.900
对话框背后的执行系统

00:00:39.066 --> 00:00:41.100
2026年9月15日

00:00:41.300 --> 00:00:43.733
谷歌正式发布Gemini3.8live

00:00:43.733 --> 00:00:46.300
和Gemini3.8live EXTENDED THINKING

00:00:47.333 --> 00:00:48.466
名字很接近

00:00:48.533 --> 00:00:50.333
定位却被刻意拆开

00:00:50.400 --> 00:00:53.400
基础版主打规模成本和低延迟

00:00:53.766 --> 00:00:55.600
适合大量实时会话

00:00:56.000 --> 00:00:56.800
extended thinking

00:00:57.133 --> 00:00:59.200
负责复杂多步骤任务

00:00:59.533 --> 00:01:01.133
允许模型在保持语音

00:01:01.133 --> 00:01:02.866
交流的同时继续推理

00:01:03.100 --> 00:01:04.600
谷歌没有把两者包装

00:01:04.600 --> 00:01:06.800
成同一款模型的快慢档位

00:01:06.866 --> 00:01:09.866
而是把实时语音市场分成了两层

00:01:10.000 --> 00:01:13.266
大量便宜反应快的日常交互

00:01:13.366 --> 00:01:15.700
以及需要更长思考更强

00:01:15.700 --> 00:01:17.500
工具调用的复杂工作

00:01:17.866 --> 00:01:18.866
过去十多年

00:01:19.066 --> 00:01:20.500
手机里的语音助手

00:01:20.500 --> 00:01:22.333
一直卡在一个尴尬位置

00:01:22.533 --> 00:01:25.666
它们能设闹钟查天气拨电话

00:01:25.666 --> 00:01:27.766
也能回答结构简单的问题

00:01:28.100 --> 00:01:29.900
一旦任务跨过几个步骤

00:01:30.200 --> 00:01:31.933
体验就会迅速崩掉

00:01:32.200 --> 00:01:33.400
用户说一句话

00:01:33.500 --> 00:01:35.200
语音先被转成文字

00:01:35.400 --> 00:01:37.066
文字交给语言模型

00:01:37.500 --> 00:01:38.766
模型生成答案

00:01:38.800 --> 00:01:41.466
再由另一个系统把文字念出来

00:01:41.533 --> 00:01:42.600
每经过一层

00:01:42.966 --> 00:01:44.300
延迟都会增加

00:01:44.400 --> 00:01:47.666
语气停顿和现场信息也会损失

00:01:47.800 --> 00:01:49.066
用户打断时

00:01:49.333 --> 00:01:51.866
系统还得判断这究竟是补充要求

00:01:51.866 --> 00:01:53.266
还是要求它闭嘴

00:01:53.466 --> 00:01:56.133
Gemini3.8live试图把这条流水线

00:01:56.133 --> 00:01:58.166
压成一套原生的实时模型

00:01:58.500 --> 00:01:59.766
它直接接收音频

00:01:59.766 --> 00:02:02.866
也能同时接收文字图像和视频

00:02:03.000 --> 00:02:05.166
再直接输出语音与文字

00:02:05.200 --> 00:02:06.366
对用户来说

00:02:06.466 --> 00:02:08.600
变化不止体现在声音更顺

00:02:08.733 --> 00:02:12.100
更关键的是模型能够保留说话方式

00:02:12.200 --> 00:02:15.100
视觉环境和任务状态之间的联系

00:02:15.566 --> 00:02:16.900
摄像头对着设备

00:02:16.933 --> 00:02:19.400
用户可以边移动镜头边追问

00:02:19.666 --> 00:02:21.066
画面发生变化

00:02:21.133 --> 00:02:22.733
回答也能跟着调整

00:02:22.933 --> 00:02:25.933
语音不再只是把文字送进去的入口

00:02:26.066 --> 00:02:28.300
而是整个交互过程的一部分

00:02:28.400 --> 00:02:30.666
但基础版最有价值的能力

00:02:30.866 --> 00:02:32.866
可能并不在对话本身

00:02:33.000 --> 00:02:34.800
而在异步函数调用

00:02:35.366 --> 00:02:38.266
传统语音智能体调用外部工具时

00:02:38.266 --> 00:02:39.733
经常要停下来等

00:02:39.800 --> 00:02:40.866
它查订单

00:02:40.900 --> 00:02:42.700
就等订单系统回传

00:02:43.166 --> 00:02:44.200
它安排日程

00:02:44.333 --> 00:02:46.100
就等日历接口完成

00:02:46.666 --> 00:02:47.800
他修改账户

00:02:47.800 --> 00:02:49.666
就等权限验证结束

00:02:49.866 --> 00:02:51.133
几秒钟的停顿

00:02:51.300 --> 00:02:53.133
放在网页里不算什么

00:02:53.300 --> 00:02:54.866
放在电话里却足以

00:02:54.866 --> 00:02:56.666
让人怀疑线路断了

00:02:56.733 --> 00:02:58.166
Gemini3.8live

00:02:58.300 --> 00:03:00.266
可以让工具在后台运行

00:03:00.266 --> 00:03:01.600
前台对话继续

00:03:02.066 --> 00:03:03.700
模型能先确认请求

00:03:03.700 --> 00:03:05.400
也能补问必要信息

00:03:05.533 --> 00:03:08.600
甚至在任务执行期间解释当前进度

00:03:08.733 --> 00:03:11.700
查航班和确认酒店可以同时进行

00:03:11.800 --> 00:03:13.333
用户临时改变日期

00:03:13.600 --> 00:03:15.800
系统再调整尚未提交的步骤

00:03:16.366 --> 00:03:18.200
这里出现的是一套开始具备

00:03:18.200 --> 00:03:20.366
并行工作能力的语音执行层

00:03:20.733 --> 00:03:22.733
聊天只是它的前台表现

00:03:23.166 --> 00:03:25.933
extended thinking把这条路线推得更远

00:03:26.133 --> 00:03:27.600
复杂任务到来时

00:03:27.766 --> 00:03:30.066
它可以先说一句正在检查

00:03:30.200 --> 00:03:32.366
随后继续做多步骤推理

00:03:32.700 --> 00:03:34.400
模型的后台状态不会

00:03:34.400 --> 00:03:36.600
因为一句回答结束而清空

00:03:36.733 --> 00:03:39.366
开发者必须持续监听服务器信息

00:03:39.766 --> 00:03:41.733
通过interaction status判断

00:03:41.733 --> 00:03:43.933
他仍在思考等待工具

00:03:43.966 --> 00:03:45.500
还是已经真正空闲

00:03:45.666 --> 00:03:46.566
也就是说

00:03:46.766 --> 00:03:48.900
应用不能再把一次对话当成

00:03:48.900 --> 00:03:51.533
问一句答一句的回合制游戏

00:03:51.766 --> 00:03:54.000
它需要管理一个持续存在

00:03:54.400 --> 00:03:57.000
随时可能返回新动作的代理状态

00:03:57.166 --> 00:03:59.100
这个变化听起来很技术

00:03:59.300 --> 00:04:01.066
商业影响却很直接

00:04:01.200 --> 00:04:03.166
客服系统过去按照通话

00:04:03.166 --> 00:04:05.133
时长和单轮处理设计

00:04:05.566 --> 00:04:07.666
新的语音代理可能在一通电话

00:04:07.666 --> 00:04:10.500
里同时访问知识库核对身份

00:04:10.666 --> 00:04:13.466
修改后台记录并生成后续邮件

00:04:13.666 --> 00:04:16.333
办公软件过去等用户点击菜单

00:04:16.600 --> 00:04:18.266
新系统则允许用户用

00:04:18.266 --> 00:04:19.966
连续语音描述目标

00:04:20.100 --> 00:04:22.366
让模型跨越邮件文档

00:04:22.366 --> 00:04:24.266
和待办事项处理工作

00:04:24.466 --> 00:04:26.466
产品界面也会随之变化

00:04:26.566 --> 00:04:28.400
屏幕上的按钮不会消失

00:04:28.533 --> 00:04:31.466
但越来越多操作会从用户自己点完

00:04:31.466 --> 00:04:33.100
变成用户交代目标

00:04:33.266 --> 00:04:34.566
系统汇报过程

00:04:34.866 --> 00:04:37.500
谷歌给出的演示很能说明方向

00:04:37.900 --> 00:04:39.733
模型可以根据实时画面

00:04:39.733 --> 00:04:41.766
指导员工完成入职流程

00:04:41.933 --> 00:04:44.800
可以观察棋盘并保持自然对话

00:04:44.866 --> 00:04:47.400
也可以把手绘草图和语音修改

00:04:47.400 --> 00:04:50.200
要求变成可运行的react组件

00:04:50.333 --> 00:04:52.700
另一个场景是多步骤预定

00:04:53.166 --> 00:04:55.733
模型同时协调不同函数调用

00:04:55.733 --> 00:04:57.133
又不让谈话中断

00:04:57.400 --> 00:04:59.066
这些例子看起来分散

00:04:59.200 --> 00:05:00.966
底层依赖同一种能力

00:05:01.300 --> 00:05:03.400
让视觉与语音交互连

00:05:03.400 --> 00:05:05.500
到推理和工具调用中

00:05:05.500 --> 00:05:07.400
并维持一个持续会话

00:05:07.600 --> 00:05:10.300
语言覆盖也被扩大到97种

00:05:10.600 --> 00:05:11.966
系统可以在谈话中

00:05:11.966 --> 00:05:13.766
自动发现语言变化

00:05:13.866 --> 00:05:16.566
不要求用户先进入设置切换

00:05:16.733 --> 00:05:18.966
对于跨国客服与旅游服务

00:05:19.066 --> 00:05:21.466
以及医疗预约和远程协作

00:05:21.500 --> 00:05:24.166
这比单纯增加语言数量更实用

00:05:24.366 --> 00:05:27.333
真实交流经常混入公司名和产品名

00:05:27.800 --> 00:05:30.400
也常夹着数字与英文缩写

00:05:30.700 --> 00:05:33.700
一段话里切换两种语言并不少见

00:05:33.800 --> 00:05:36.200
谷歌还特别强调字母数字精度

00:05:36.266 --> 00:05:38.333
因为验证码和理赔编号

00:05:38.400 --> 00:05:40.266
以及地址与技术参数

00:05:40.333 --> 00:05:41.933
正是语音系统最容易

00:05:41.933 --> 00:05:44.266
听错又最不能听错的内容

00:05:44.533 --> 00:05:47.200
不过模型支持97种语言

00:05:47.200 --> 00:05:50.266
不等于97种语言都达到同样水平

00:05:50.500 --> 00:05:52.733
训练数据口音覆盖和

00:05:52.733 --> 00:05:54.900
地区用词都会影响表现

00:05:54.933 --> 00:05:57.366
一个模型在英语测试里领先

00:05:57.366 --> 00:06:00.766
不能自动证明它能处理粤语加英文

00:06:00.800 --> 00:06:03.733
印度英语或嘈杂门店里的专业术语

00:06:04.100 --> 00:06:06.266
谷歌公布的是能力边界

00:06:06.600 --> 00:06:09.133
企业真正部署前仍要用自己

00:06:09.133 --> 00:06:12.600
的用户设备和环境重新测试

00:06:12.800 --> 00:06:15.666
官方模型卡给出了更清楚的规格

00:06:15.866 --> 00:06:19.100
两款模型都建立在Gemini3Pro之上

00:06:19.133 --> 00:06:21.066
可以接收文字与图片

00:06:21.133 --> 00:06:23.133
也能处理视频和音频

00:06:23.500 --> 00:06:27.000
上下文上限为131,072个TOKEN

00:06:27.333 --> 00:06:30.733
输出上限为65,536个TOKEN

00:06:31.300 --> 00:06:33.266
EXTENDED thinking支持搜索

00:06:33.266 --> 00:06:35.200
接地和异步函数调用

00:06:35.200 --> 00:06:37.866
却不支持代码执行与文件搜索

00:06:38.266 --> 00:06:41.100
也没有结构化输出和网址上下文

00:06:41.200 --> 00:06:43.933
功能表里的一排不支持很重要

00:06:44.100 --> 00:06:45.500
它提醒开发者

00:06:45.500 --> 00:06:47.866
这是一款为实时语音和

00:06:47.866 --> 00:06:49.766
工具协作优化的模型

00:06:50.066 --> 00:06:51.566
并没有把所有Gemini

00:06:51.566 --> 00:06:53.466
能力都塞进电话线路

00:06:53.566 --> 00:06:56.466
谷歌把边说边想放在发布重点里

00:06:56.600 --> 00:06:58.600
评测自然也集中在语音

00:06:58.666 --> 00:07:00.700
质量推理和任务完成

00:07:01.000 --> 00:07:03.100
Gemini 3.8 live

00:07:03.333 --> 00:07:04.133
EXTENDED thinking

00:07:04.166 --> 00:07:05.733
AI artificial analysis

00:07:05.800 --> 00:07:07.700
speech to speech quality index

00:07:07.700 --> 00:07:09.500
琼获得82.6分

00:07:09.666 --> 00:07:13.000
这个指数把语音推理对话动态

00:07:13.100 --> 00:07:15.800
和代理任务表现合在一起计算

00:07:16.200 --> 00:07:20.566
模型在bigbench Audio中达到97.7%

00:07:20.733 --> 00:07:22.966
在测试智能体任务完成

00:07:22.966 --> 00:07:26.933
能力的tall voice里达到68.6%

00:07:27.166 --> 00:07:29.533
这些数字解释了谷歌为什么敢把

00:07:29.533 --> 00:07:31.966
它称为最先进的实时对话模型

00:07:32.133 --> 00:07:34.800
可真正值得盯住的数字是

00:07:34.800 --> 00:07:37.966
银行业务基准里的35.1%

00:07:37.966 --> 00:07:39.866
这个测试要求语音代理

00:07:39.866 --> 00:07:41.933
处理多步骤银行流程

00:07:42.200 --> 00:07:43.733
成功率越过三成

00:07:44.166 --> 00:07:47.566
却仍有接近2/3的任务没有完整完成

00:07:47.666 --> 00:07:51.966
82.6分很适合放在发布会大屏幕上

00:07:52.166 --> 00:07:53.700
35.1%

00:07:54.066 --> 00:07:57.066
更接近企业部署时必须面对的现实

00:07:57.366 --> 00:07:59.133
模型已经能处理过去

00:07:59.133 --> 00:08:00.733
做不到的复杂流程

00:08:01.133 --> 00:08:03.300
但离可以把高风险业务放心

00:08:03.300 --> 00:08:05.933
交出去仍然隔着很长一段路

00:08:05.933 --> 00:08:09.100
这也说明语音AI的竞争正在换指标

00:08:09.466 --> 00:08:12.200
早期产品比较谁的声音更像真人

00:08:12.366 --> 00:08:14.700
随后比较首个音节要等多久

00:08:14.766 --> 00:08:16.966
现在声音自然只是门票

00:08:17.166 --> 00:08:18.933
真正决定价值的是

00:08:18.933 --> 00:08:20.866
一通对话结束以后

00:08:21.200 --> 00:08:22.666
事情有没有办成

00:08:22.900 --> 00:08:24.366
记录有没有写对

00:08:24.566 --> 00:08:25.933
权限有没有越界

00:08:26.200 --> 00:08:27.866
用户临时改口以后

00:08:27.866 --> 00:08:29.733
系统有没有撤回旧操作

00:08:29.900 --> 00:08:31.466
一个声音很自然

00:08:31.700 --> 00:08:33.300
任务却做错的代理

00:08:33.300 --> 00:08:35.300
只会让错误更有迷惑性

00:08:35.500 --> 00:08:38.000
排行榜本身也需要谨慎解读

00:08:38.466 --> 00:08:39.600
官方发布时

00:08:39.800 --> 00:08:42.333
基础版Gemini 3.8live在

00:08:42.333 --> 00:08:44.300
盲测偏好中排名靠前

00:08:44.866 --> 00:08:47.533
extended thinking在综合质量指数领先

00:08:47.600 --> 00:08:49.933
可不同榜单测量的东西不同

00:08:50.500 --> 00:08:52.533
模型设置和思考强度

00:08:52.566 --> 00:08:54.466
再加上延迟与价格

00:08:54.500 --> 00:08:55.933
都会改变结果

00:08:56.400 --> 00:08:59.466
盲测更看重人是否喜欢这段对话

00:08:59.733 --> 00:09:02.700
任务基准更看重流程是否完成

00:09:02.866 --> 00:09:05.300
企业不能只选总分最高的模型

00:09:05.466 --> 00:09:06.800
还得确认自己的

00:09:06.800 --> 00:09:08.800
任务更怕延迟与费用

00:09:09.200 --> 00:09:11.933
还是听错数字或错误调用工具

00:09:12.133 --> 00:09:15.166
价格正是谷歌这次进攻的另一部分

00:09:15.733 --> 00:09:17.800
官方开发者资料给出的音频

00:09:17.800 --> 00:09:21.100
输入价格约为每分钟0.005美元

00:09:21.366 --> 00:09:24.666
音频输出约为每分钟0.018美元

00:09:25.100 --> 00:09:27.766
连续输入一小时大约0.3美元

00:09:28.100 --> 00:09:30.766
连续输出一小时约1.08美元

00:09:30.933 --> 00:09:33.666
真实通话不会始终由同一方说话

00:09:34.066 --> 00:09:36.566
实际账单还取决于沉默处理

00:09:36.700 --> 00:09:40.366
上下文长度工具调用和会话管理

00:09:40.566 --> 00:09:43.533
但这个价格已经足以让大规模客服

00:09:43.766 --> 00:09:46.766
陪练和企业助手认真计算替代方案

00:09:46.966 --> 00:09:49.800
谷歌选在这个时间点推出两款模型

00:09:50.266 --> 00:09:52.166
也暴露了他对市场的判断

00:09:52.500 --> 00:09:55.100
实时语音不会只有一个冠军通吃

00:09:55.266 --> 00:09:56.600
高频简单

00:09:56.700 --> 00:09:59.366
成本敏感的业务需要基础版

00:09:59.933 --> 00:10:02.700
少量复杂价值更高的流程

00:10:02.700 --> 00:10:04.766
才值得开启extended thinking

00:10:05.066 --> 00:10:06.466
要是每次查天气都

00:10:06.466 --> 00:10:08.100
让模型长时间推理

00:10:08.366 --> 00:10:09.666
用户会觉得慢

00:10:09.900 --> 00:10:12.500
企业也会为没有必要的计算付钱

00:10:12.700 --> 00:10:14.766
双模型结构等于把什么时候

00:10:14.766 --> 00:10:17.700
值得思考变成产品设计的一部分

00:10:18.100 --> 00:10:20.600
开发者还要承担新的工程成本

00:10:20.866 --> 00:10:23.933
要求函数调用全部采用异步方式

00:10:24.200 --> 00:10:27.266
客户端不能在出现后立即关闭连接

00:10:27.666 --> 00:10:28.866
后台推理可能继续

00:10:28.866 --> 00:10:30.966
返回工具请求和音频帧

00:10:31.466 --> 00:10:33.966
应用必须能取消和处理超时

00:10:34.166 --> 00:10:37.000
还要防止重复提交并恢复状态

00:10:37.166 --> 00:10:39.100
用户说算了不要定

00:10:39.466 --> 00:10:42.200
系统能否及时终止已经启动的步骤

00:10:42.400 --> 00:10:44.166
网路短暂中断以后

00:10:44.300 --> 00:10:47.266
模型会不会把同一笔操作执行两次

00:10:47.533 --> 00:10:48.966
这些问题不会出现在

00:10:48.966 --> 00:10:50.700
漂亮的语音演示里

00:10:50.700 --> 00:10:52.900
却会决定产品能不能上线

00:10:53.066 --> 00:10:55.266
权限设计也比过去更难

00:10:55.333 --> 00:10:58.066
一个只能回答问题的模型说错话

00:10:58.133 --> 00:10:59.600
主要风险是误导

00:10:59.766 --> 00:11:01.966
一个可以访问邮箱与日历

00:11:02.133 --> 00:11:03.900
还能接触客户资料和

00:11:03.900 --> 00:11:05.900
付款接口的模型说错话

00:11:06.200 --> 00:11:08.133
风险会变成真实动作

00:11:08.266 --> 00:11:10.100
企业需要把能听懂请求

00:11:10.100 --> 00:11:12.166
和有权执行请求拆开

00:11:12.366 --> 00:11:14.200
查询信息可以自动完成

00:11:14.666 --> 00:11:17.900
修改账户发送敏感邮件或提交交易

00:11:17.900 --> 00:11:19.600
应当触发再次确认

00:11:19.800 --> 00:11:20.900
语音越自然

00:11:20.900 --> 00:11:23.500
越不能让用户误以为系统拥有

00:11:23.500 --> 00:11:26.100
和人类员工相同的判断能力

00:11:26.300 --> 00:11:29.000
银行场景能把这套矛盾看得最清楚

00:11:29.366 --> 00:11:31.466
客户打电话修改通讯地址

00:11:31.666 --> 00:11:33.200
表面只是几句话

00:11:33.300 --> 00:11:35.000
后台先要验证身份

00:11:35.200 --> 00:11:37.166
查询账户和提示风险

00:11:37.333 --> 00:11:40.200
随后还要变更资料并留下审计记录

00:11:40.366 --> 00:11:41.600
任何一步做错

00:11:41.600 --> 00:11:44.666
后面的动作都会建立在错误状态上

00:11:45.366 --> 00:11:47.466
实时模型的优势是不用把

00:11:47.466 --> 00:11:49.933
客户反复转接给不同菜单

00:11:50.266 --> 00:11:52.733
风险则是它可能用非常自然的

00:11:52.733 --> 00:11:56.133
语气把一条错误路径执行到底

00:11:56.333 --> 00:11:58.100
因此企业需要给每个

00:11:58.100 --> 00:11:59.700
工具设置独立权限

00:12:00.000 --> 00:12:02.366
不能因为模型通过了身份验证

00:12:02.366 --> 00:12:03.900
就默认它获得整场

00:12:03.900 --> 00:12:05.666
会话的全部操作权

00:12:06.100 --> 00:12:07.600
医疗预约也一样

00:12:07.766 --> 00:12:09.566
模型可以查看时间表

00:12:09.666 --> 00:12:10.700
询问症状

00:12:10.733 --> 00:12:11.666
匹配科室

00:12:11.700 --> 00:12:12.800
再发送提醒

00:12:12.933 --> 00:12:15.000
这些工作很适合自动化

00:12:15.100 --> 00:12:17.600
可它不能因为听见几个关键词

00:12:17.600 --> 00:12:19.200
就替医生做诊断

00:12:20.066 --> 00:12:21.500
系统必须把行政

00:12:21.500 --> 00:12:23.533
流程和医疗判断分开

00:12:23.600 --> 00:12:25.400
哪句话只是收集信息

00:12:25.566 --> 00:12:27.366
哪句话属于健康建议

00:12:27.500 --> 00:12:29.333
什么情况必须转给真人

00:12:29.333 --> 00:12:31.966
都应在模型之外写成明确规则

00:12:32.333 --> 00:12:34.066
模型越能自由交流

00:12:34.166 --> 00:12:35.933
外部规则越要清楚

00:12:36.166 --> 00:12:39.133
企业培训可能成为更早成熟的市场

00:12:39.500 --> 00:12:42.466
谈判训练销售陪练和客服模拟

00:12:42.466 --> 00:12:45.000
不需要模型真的修改客户账户

00:12:45.133 --> 00:12:48.600
却非常依赖语气打断和连续追问

00:12:48.766 --> 00:12:51.333
Gemini 3.8live可以扮演

00:12:51.333 --> 00:12:53.066
不同类型的对话对象

00:12:53.300 --> 00:12:55.866
根据学员表现及时改变难度

00:12:55.866 --> 00:12:58.366
再把交流记录交给评估系统

00:12:58.600 --> 00:13:00.300
这里即使出现错误

00:13:00.300 --> 00:13:02.600
也容易在训练结束后纠正

00:13:03.000 --> 00:13:05.166
部署风险低于金融交易

00:13:05.200 --> 00:13:07.966
却能充分利用实时语音的优势

00:13:08.266 --> 00:13:10.733
无障碍交互同样值得注意

00:13:10.933 --> 00:13:13.300
用户可以把摄像头对准设备

00:13:13.300 --> 00:13:15.866
让模型用语音描述按钮位置

00:13:15.866 --> 00:13:18.100
或者边操作边询问下一步

00:13:18.466 --> 00:13:19.533
视力受限者

00:13:19.733 --> 00:13:21.333
手部操作不便者

00:13:21.333 --> 00:13:23.566
以及不熟悉复杂软件的人

00:13:23.666 --> 00:13:25.966
都可能因此减少学习成本

00:13:26.066 --> 00:13:28.066
不过视觉帧率

00:13:28.500 --> 00:13:31.166
环境光线和网络延迟会影响判断

00:13:31.533 --> 00:13:33.300
模型看漏一个指示灯

00:13:33.366 --> 00:13:35.600
后面的指导就可能失去依据

00:13:35.700 --> 00:13:37.300
无障碍工具更需要

00:13:37.300 --> 00:13:38.933
明确表达不确定性

00:13:38.966 --> 00:13:41.466
不能为了流畅而假装看清了

00:13:41.466 --> 00:13:44.100
这些场景共同指向一个工程原则

00:13:44.533 --> 00:13:46.400
实时语音代理不应只按

00:13:46.933 --> 00:13:48.800
回答是否好听验收

00:13:49.066 --> 00:13:50.800
还要拆成多个指标

00:13:50.900 --> 00:13:52.400
听写是否准确

00:13:53.100 --> 00:13:55.733
身份信息有没有串到下一名用户

00:13:56.300 --> 00:13:57.933
工具参数是否正确

00:13:58.166 --> 00:14:00.333
取消指令能否及时生效

00:14:00.600 --> 00:14:03.000
长会话以后状态会不会漂移

00:14:03.266 --> 00:14:05.733
网路恢复后是否重复执行

00:14:05.800 --> 00:14:07.133
都要单独测试

00:14:07.400 --> 00:14:09.766
传统聊天机器人的离线

00:14:09.766 --> 00:14:11.966
问答集覆盖不了这些问题

00:14:12.133 --> 00:14:14.400
官方评测也暴露了这一点

00:14:14.800 --> 00:14:17.300
artificial analysis的综合指数把

00:14:17.300 --> 00:14:19.500
多项能力合并成一个分数

00:14:19.666 --> 00:14:21.066
便于横向比较

00:14:21.133 --> 00:14:23.000
却无法替代业务测试

00:14:23.333 --> 00:14:25.333
top voice测量代理在完整

00:14:25.333 --> 00:14:27.200
语音任务中的完成情况

00:14:27.333 --> 00:14:30.000
已经比单轮问答接近真实使用

00:14:30.366 --> 00:14:31.933
银行基准进一步加入

00:14:31.933 --> 00:14:33.666
规则和多步骤流程

00:14:33.800 --> 00:14:35.866
所以成功率明显下降

00:14:36.166 --> 00:14:37.800
任务越接近现实

00:14:37.900 --> 00:14:39.566
票量分数越难维持

00:14:39.766 --> 00:14:42.700
35.1%直接标出了企业

00:14:42.700 --> 00:14:44.166
自动化的真实边界

00:14:44.466 --> 00:14:46.533
不能简单算作发布失败

00:14:46.666 --> 00:14:49.266
还有一个容易忽略的成本是上下文

00:14:49.666 --> 00:14:51.733
实时会话不断积累音频

00:14:51.933 --> 00:14:54.800
视觉帧工具结果和系统状态

00:14:55.066 --> 00:14:57.300
即使每分钟音频价格很低

00:14:57.500 --> 00:14:59.100
长时间保留全部内容

00:14:59.100 --> 00:15:00.866
也会增加推理负担

00:15:01.000 --> 00:15:02.400
产品需要决定哪些

00:15:02.400 --> 00:15:04.766
信息继续留在上下文里

00:15:04.900 --> 00:15:06.500
哪些压缩成摘要

00:15:06.666 --> 00:15:09.266
哪些在任务结束后立即删除

00:15:09.600 --> 00:15:10.600
压缩太早

00:15:10.766 --> 00:15:13.566
模型可能忘记用户刚刚修改的条件

00:15:13.900 --> 00:15:15.066
什么都保留

00:15:15.166 --> 00:15:18.666
费用延迟和隐私风险都会上升

00:15:18.733 --> 00:15:21.700
这会催生一层新的会话基础设施

00:15:22.200 --> 00:15:24.900
他要检测语音活动和处理打断

00:15:25.100 --> 00:15:27.766
也要压缩状态管理工具队列

00:15:27.966 --> 00:15:30.866
并负责用户确认与错误恢复

00:15:31.133 --> 00:15:33.133
基础模型给出能力上限

00:15:33.466 --> 00:15:34.966
这层基础设施决定

00:15:34.966 --> 00:15:36.733
能力能否稳定落地

00:15:36.933 --> 00:15:40.666
谷歌同时与Livekit Agora Pipekit

00:15:41.200 --> 00:15:43.866
Lang chain和Versatile等平台合作

00:15:44.000 --> 00:15:45.133
原因就在这里

00:15:45.133 --> 00:15:46.800
多数开发团队不愿从头

00:15:46.800 --> 00:15:48.566
处理实时音视频传输

00:15:48.733 --> 00:15:51.100
他们更希望直接设计业务流程

00:15:51.266 --> 00:15:53.533
产品经理面对的问题也变了

00:15:53.566 --> 00:15:55.400
过去设计语音助手

00:15:55.500 --> 00:15:57.966
需要为每个意图写固定路线

00:15:58.333 --> 00:16:00.500
现在模型能理解开放表达

00:16:00.666 --> 00:16:02.866
团队不用穷举所有说法

00:16:02.866 --> 00:16:04.600
却必须规定哪些目标

00:16:04.600 --> 00:16:06.500
允许模型自行拆解

00:16:06.566 --> 00:16:07.766
自由度越高

00:16:07.900 --> 00:16:09.333
测试空间越大

00:16:09.333 --> 00:16:11.200
一个用户可能先订酒店

00:16:11.300 --> 00:16:13.200
再突然要求取消航班

00:16:13.366 --> 00:16:15.266
随后补充同行者信息

00:16:15.766 --> 00:16:18.266
系统得知道哪些动作仍在草稿

00:16:18.366 --> 00:16:19.733
哪些已经提交

00:16:19.866 --> 00:16:21.166
哪些需要退款

00:16:21.300 --> 00:16:23.333
自然语言只是入口

00:16:23.566 --> 00:16:25.733
真正困难的是交易状态

00:16:25.966 --> 00:16:28.966
谷歌把可配置思考加入EXTENDED thinking

00:16:29.300 --> 00:16:32.066
也是在处理成本与可靠性的冲突

00:16:32.533 --> 00:16:34.933
简单问题不需要长时间推理

00:16:35.566 --> 00:16:38.166
复杂流程才值得付出更多计算

00:16:38.333 --> 00:16:39.666
企业可以根据任务

00:16:39.666 --> 00:16:41.533
风险调整思考强度

00:16:41.666 --> 00:16:44.766
高价值操作用更严格的推理和验证

00:16:45.100 --> 00:16:47.333
普通查询则优先保证速度

00:16:47.400 --> 00:16:49.200
但思考时间更长并不

00:16:49.200 --> 00:16:50.900
自动等于结果正确

00:16:51.133 --> 00:16:54.300
模型可能用更多步骤巩固错误假设

00:16:54.900 --> 00:16:56.366
因此仍要依靠外部

00:16:56.366 --> 00:16:58.366
数据和工具回传纠正

00:16:58.866 --> 00:17:01.200
实时进度播报也需要节制

00:17:01.533 --> 00:17:03.900
模型如果每走一步都解释

00:17:04.000 --> 00:17:06.966
会拉长通话并增加输出费用

00:17:07.400 --> 00:17:08.400
完全沉默

00:17:08.500 --> 00:17:10.900
用户又不知道任务是否卡住

00:17:10.933 --> 00:17:13.400
合理做法是只在状态发生变化

00:17:13.533 --> 00:17:15.333
需要用户补充信息或

00:17:15.333 --> 00:17:17.266
等待明显变长时播报

00:17:17.566 --> 00:17:19.533
这个细节会决定AI听起来像

00:17:19.533 --> 00:17:21.266
一个有效率的服务人员

00:17:21.333 --> 00:17:24.000
还是一个不停描述自己动作的系统

00:17:24.266 --> 00:17:26.733
视觉输入又打开了另一条供给面

00:17:27.066 --> 00:17:29.300
塞他们能看见屏幕和摄像头

00:17:29.333 --> 00:17:30.866
也可能读到画面里

00:17:30.866 --> 00:17:33.000
专门写给AI的恶意指令

00:17:33.100 --> 00:17:33.966
一个网页

00:17:33.966 --> 00:17:35.000
一张海报

00:17:35.166 --> 00:17:37.666
甚至远程会议中的共享画面

00:17:37.733 --> 00:17:40.566
都可能试图诱导代理忽略原任务

00:17:40.900 --> 00:17:43.966
语音里同样可以夹带间接提示注入

00:17:44.133 --> 00:17:45.500
实时系统必须知道

00:17:45.500 --> 00:17:47.066
哪些内容来自用户

00:17:47.100 --> 00:17:48.333
哪些来自环境

00:17:48.400 --> 00:17:50.333
哪些只应该被当做资料

00:17:50.766 --> 00:17:53.533
不能让所有输入拥有同等指挥权

00:17:53.766 --> 00:17:55.133
隐私问题也不会因为

00:17:55.133 --> 00:17:57.500
模型更流畅而自动消失

00:17:57.900 --> 00:18:00.700
实时语音往往包含背景谈话

00:18:00.700 --> 00:18:03.966
家庭环境办公室画面和身份信息

00:18:04.300 --> 00:18:05.966
模型为了保持连续性

00:18:05.966 --> 00:18:08.500
还需要维护更长的会话状态

00:18:08.800 --> 00:18:11.533
企业必须明确音频是否保存

00:18:11.800 --> 00:18:12.800
保存多久

00:18:12.966 --> 00:18:14.066
谁能访问

00:18:14.300 --> 00:18:15.566
是否用于训练

00:18:16.100 --> 00:18:17.733
以及用户怎样删除

00:18:17.966 --> 00:18:19.300
很多人愿意把一条

00:18:19.300 --> 00:18:21.133
文字问题交给云端

00:18:21.333 --> 00:18:23.600
不代表他们愿意把整场会议

00:18:23.600 --> 00:18:26.166
和摄像头画面持续送出去

00:18:26.300 --> 00:18:29.066
谷歌为生成音频加入SINC ID水印

00:18:29.766 --> 00:18:32.133
所有自家AI产品产生的音频

00:18:32.133 --> 00:18:34.100
都嵌入不可感知的标记

00:18:34.566 --> 00:18:36.733
这有助于识别合成内容

00:18:37.200 --> 00:18:38.933
却解决不了全部问题

00:18:39.166 --> 00:18:42.200
水印主要说明一段音频由AI生成

00:18:42.266 --> 00:18:43.900
不能证明内容真实

00:18:44.000 --> 00:18:46.533
也不能阻止有人截取混剪

00:18:46.566 --> 00:18:48.800
或通过其他系统重新编码

00:18:48.966 --> 00:18:51.666
更何况实时语音代理最大的

00:18:51.666 --> 00:18:54.300
风险未必是伪造一段录音

00:18:54.666 --> 00:18:56.066
而是他在真实账户

00:18:56.066 --> 00:18:57.866
里执行了错误操作

00:18:58.066 --> 00:18:59.666
模型卡还列出几个容易

00:18:59.666 --> 00:19:01.733
被发布热度盖住的限制

00:19:02.133 --> 00:19:04.500
两款模型仍会产生幻觉

00:19:04.666 --> 00:19:07.166
也可能遇到响应变慢和超时

00:19:07.666 --> 00:19:10.700
知识截止时间是2025年1月

00:19:11.000 --> 00:19:12.266
他们在前沿安全和

00:19:12.266 --> 00:19:14.133
越狱抵抗上经过加强

00:19:14.133 --> 00:19:16.300
却没有被宣布为不可绕过

00:19:16.366 --> 00:19:17.900
用于新闻与金融

00:19:18.066 --> 00:19:20.100
或者医疗和法律场景时

00:19:20.133 --> 00:19:23.100
实时说出答案不等于答案已经核验

00:19:23.266 --> 00:19:24.266
速度越快

00:19:24.366 --> 00:19:26.600
产品越需要把引用权限

00:19:26.600 --> 00:19:28.600
和人工复核放到界面里

00:19:28.866 --> 00:19:31.766
Gemini3.8live已经进入Gemini API

00:19:32.000 --> 00:19:34.100
Google AI studio和search live

00:19:34.466 --> 00:19:35.900
企业端通过Gemini

00:19:35.900 --> 00:19:37.566
enterprise提供私有预览

00:19:38.100 --> 00:19:39.700
EXTENDED thinking也开始进入

00:19:39.700 --> 00:19:42.566
Gemini应用以及Gmail keep和Docs

00:19:43.133 --> 00:19:45.300
这个发布范围说明谷歌没有

00:19:45.300 --> 00:19:47.466
把它当成孤立的模型展示

00:19:47.600 --> 00:19:50.400
搜索办公套件云平台和

00:19:50.400 --> 00:19:53.066
消费者助手都在争夺同一件事

00:19:53.600 --> 00:19:55.300
成为用户交代任务时

00:19:55.300 --> 00:19:57.133
最先接到指令的入口

00:19:57.200 --> 00:20:00.266
这才是此次发布最值得关注的竞争

00:20:00.500 --> 00:20:04.100
过去搜索框掌握的是问题入口

00:20:04.800 --> 00:20:07.133
操作系统掌握的是应用入口

00:20:07.600 --> 00:20:10.100
办公软件掌握的是工作入口

00:20:10.300 --> 00:20:13.066
实时语音代理试图把三者压到一起

00:20:13.133 --> 00:20:15.466
用户不再先决定打开哪个应用

00:20:15.600 --> 00:20:17.133
而是先说出目标

00:20:17.533 --> 00:20:19.200
再由代理选择搜索

00:20:19.333 --> 00:20:21.366
调用工具或修改文档

00:20:21.466 --> 00:20:23.066
谁控制这个调度层

00:20:23.200 --> 00:20:26.133
谁就有机会决定后面的流量去哪里

00:20:26.300 --> 00:20:27.666
调用哪项服务

00:20:27.766 --> 00:20:30.333
以及哪些产品逐渐退到后台

00:20:30.666 --> 00:20:32.100
谷歌的优势很明显

00:20:32.300 --> 00:20:34.933
它有搜索地图邮件

00:20:35.100 --> 00:20:37.966
文档日历安卓和云服务

00:20:38.300 --> 00:20:40.100
模型能调用的真实工具

00:20:40.133 --> 00:20:42.266
比许多竞争对手更完整

00:20:42.300 --> 00:20:43.733
可这也是它的压力

00:20:43.933 --> 00:20:45.533
跨产品权限越多

00:20:45.533 --> 00:20:47.100
出错的影响越大

00:20:47.133 --> 00:20:48.166
接入越深

00:20:48.366 --> 00:20:50.500
监管者越会追问平台是否

00:20:50.500 --> 00:20:52.666
利用入口偏袒自家服务

00:20:52.900 --> 00:20:55.200
语音代理若替用户完成选择

00:20:55.466 --> 00:20:58.133
传统的搜索排序广告展示和

00:20:58.133 --> 00:21:00.333
应用分发规则都会受到冲击

00:21:00.600 --> 00:21:02.766
安卓会成为另一个关键弱点

00:21:02.900 --> 00:21:04.866
手机有麦克风与摄像头

00:21:05.100 --> 00:21:08.266
也掌握位置通知和大量应用入口

00:21:08.333 --> 00:21:10.500
最适合承载持续语音代理

00:21:10.600 --> 00:21:12.800
问题在于Gemini3.8live

00:21:12.933 --> 00:21:14.600
主要依赖云端服务

00:21:14.800 --> 00:21:16.133
网路质量和数据

00:21:16.133 --> 00:21:18.333
上传会直接影响体验

00:21:18.566 --> 00:21:20.333
真正稳定的手机代理

00:21:20.333 --> 00:21:22.200
很可能采用混合架构

00:21:22.600 --> 00:21:24.466
本地模型处理唤醒

00:21:24.700 --> 00:21:27.366
隐私敏感识别和简单动作

00:21:27.600 --> 00:21:31.533
云端模型承担长推理与跨服务协调

00:21:31.700 --> 00:21:33.400
哪些内容留在设备

00:21:33.566 --> 00:21:35.100
哪些送入云端

00:21:35.133 --> 00:21:37.200
会成为新的产品卖点

00:21:37.300 --> 00:21:39.566
搜索业务也可能被重新定义

00:21:40.000 --> 00:21:42.000
用户过去输入关键词

00:21:42.200 --> 00:21:43.933
自己浏览多个页面

00:21:44.066 --> 00:21:45.600
再完成后续操作

00:21:45.866 --> 00:21:48.566
search live可以边听问题边看镜头

00:21:48.866 --> 00:21:50.200
给出步骤式帮助

00:21:50.200 --> 00:21:51.700
要是它进一步接入

00:21:51.700 --> 00:21:53.866
预订购物和本地服务

00:21:54.100 --> 00:21:55.800
搜索结果就会从链接

00:21:55.800 --> 00:21:57.366
列表变成代理行动

00:21:57.533 --> 00:22:00.866
广告和内容网站依靠点击获得流量

00:22:01.000 --> 00:22:03.733
代理替用户读完并执行以后

00:22:03.800 --> 00:22:06.966
价值怎样分配会变成更尖锐的问题

00:22:07.333 --> 00:22:09.300
办公套件的变化更直接

00:22:09.500 --> 00:22:12.066
Gmail Docs和keep掌握了

00:22:12.066 --> 00:22:13.800
用户工作上下文

00:22:14.133 --> 00:22:16.933
extended thinking可以从邮件提取任务

00:22:16.933 --> 00:22:18.700
在文档中生成材料

00:22:18.700 --> 00:22:20.466
再把结果写进待办

00:22:20.800 --> 00:22:22.366
单项功能并不惊人

00:22:22.533 --> 00:22:24.800
跨应用连续完成才是护城河

00:22:25.066 --> 00:22:26.500
竞争对手可以训练出

00:22:26.500 --> 00:22:28.066
同样会说话的模型

00:22:28.133 --> 00:22:29.800
却未必拥有同样深的

00:22:29.800 --> 00:22:31.600
服务接口和用户授权

00:22:31.666 --> 00:22:33.333
这也解释了谷歌为什么

00:22:33.333 --> 00:22:35.800
同时强调开发者与自家产品

00:22:36.400 --> 00:22:37.933
API负责扩大生态

00:22:37.933 --> 00:22:40.866
让外部公司替它寻找高价值场景

00:22:41.366 --> 00:22:44.300
Workspace search和Gemini应用

00:22:44.300 --> 00:22:46.066
负责建立默认入口

00:22:46.166 --> 00:22:48.000
外部场景产生需求

00:22:48.133 --> 00:22:50.066
自家产品提供分发

00:22:50.333 --> 00:22:52.066
两条路线互相加强

00:22:52.266 --> 00:22:54.700
Gemini3.8live是一款模型

00:22:54.866 --> 00:22:58.000
也是一场争夺交互入口的部署行动

00:22:58.266 --> 00:23:00.400
普通用户最先感受到的变化

00:23:00.533 --> 00:23:02.666
可能不会是某个惊人的新按钮

00:23:02.800 --> 00:23:04.766
而是等待方式被改写

00:23:05.266 --> 00:23:06.666
过去AI沉默时

00:23:06.666 --> 00:23:09.100
没人知道它是在工作卡住

00:23:09.100 --> 00:23:10.566
还是已经忘了任务

00:23:11.066 --> 00:23:13.733
extended thinking会用简短语音确认

00:23:13.733 --> 00:23:15.500
并在后台继续处理

00:23:15.700 --> 00:23:18.766
这种进度叙述能降低等待焦虑

00:23:18.866 --> 00:23:21.000
也可能制造另一种错觉

00:23:21.166 --> 00:23:22.866
只要系统一直在说

00:23:22.966 --> 00:23:25.100
它就一定知道自己在做什么

00:23:25.366 --> 00:23:26.866
流畅表达和可靠

00:23:26.866 --> 00:23:28.766
执行必须被分开评估

00:23:29.000 --> 00:23:31.800
企业端也会重新计算人机分工

00:23:31.966 --> 00:23:34.266
语音代理适合处理信息明确

00:23:34.266 --> 00:23:35.500
工具边界清楚

00:23:35.933 --> 00:23:37.733
结果容易验证的流程

00:23:37.933 --> 00:23:39.966
例如预约资料查询

00:23:40.066 --> 00:23:42.500
标准化故障排查和内部事务

00:23:42.700 --> 00:23:44.700
涉及价值判断异常

00:23:44.700 --> 00:23:46.700
授权或不可逆操作时

00:23:46.800 --> 00:23:48.900
人类仍应保留最后一步

00:23:49.133 --> 00:23:50.966
最合理的部署方式不会是

00:23:50.966 --> 00:23:53.133
一夜之间替换整支团队

00:23:53.200 --> 00:23:56.333
而是先让模型承担等待检索

00:23:56.800 --> 00:23:58.666
记录和低风险操作

00:23:58.766 --> 00:24:00.900
再观察错误集中在哪里

00:24:01.000 --> 00:24:03.366
岗位变化也会先落在流程上

00:24:03.466 --> 00:24:06.466
客服人员过去需要边听边搜索资料

00:24:06.533 --> 00:24:09.133
还要把通话内容重新录入系统

00:24:09.400 --> 00:24:12.066
实时代理可以先接管检索和记录

00:24:12.133 --> 00:24:14.366
让人类集中处理例外情况

00:24:14.500 --> 00:24:16.966
企业如果只把它当成裁员工具

00:24:17.133 --> 00:24:19.966
可能会把最熟悉业务的人一起清走

00:24:20.366 --> 00:24:22.300
随后才发现模型犯错时

00:24:22.300 --> 00:24:23.800
没人知道怎样纠正

00:24:24.100 --> 00:24:26.900
比较稳妥的路线是保留领域人员

00:24:26.966 --> 00:24:28.766
让他们定义工具权限

00:24:28.900 --> 00:24:30.266
检查失败案例

00:24:30.300 --> 00:24:32.300
并把新规则写回系统

00:24:32.466 --> 00:24:34.366
责任链必须同步调整

00:24:34.966 --> 00:24:37.300
模型提供商负责基础能力

00:24:37.533 --> 00:24:39.733
集成平台负责实时传输

00:24:39.966 --> 00:24:42.466
企业负责工具和业务规则

00:24:42.766 --> 00:24:45.533
最终操作又可能落在第三方系统

00:24:45.733 --> 00:24:47.100
事故发生以后

00:24:47.133 --> 00:24:50.133
任何一方都不能只说模型生成的

00:24:50.133 --> 00:24:52.200
日志需要记录用户说了什么

00:24:52.566 --> 00:24:53.900
模型怎样理解

00:24:54.133 --> 00:24:55.400
调用了哪个工具

00:24:55.566 --> 00:24:57.566
谁批准了不可逆动作

00:24:57.733 --> 00:24:59.133
没有这条证据链

00:24:59.500 --> 00:25:01.133
实时代理越能办事

00:25:01.200 --> 00:25:02.966
出问题时越难追责

00:25:03.100 --> 00:25:04.466
从技术路线看

00:25:04.500 --> 00:25:05.866
Gemini3.8live

00:25:06.000 --> 00:25:07.766
代表语音模型正在离开

00:25:07.766 --> 00:25:09.900
会说话的聊天机器人阶段

00:25:10.066 --> 00:25:11.900
它开始拥有持续状态

00:25:12.366 --> 00:25:13.533
能够看到环境

00:25:13.600 --> 00:25:15.366
能在后台调用工具

00:25:15.500 --> 00:25:18.100
还能把复杂任务拆成多个步骤

00:25:18.166 --> 00:25:21.400
可从35.1%的银行任务成功率看

00:25:21.400 --> 00:25:22.800
它也远没有成为可以

00:25:22.800 --> 00:25:24.900
独立承担责任的数字员工

00:25:25.466 --> 00:25:27.166
能力跨过了产品门槛

00:25:27.200 --> 00:25:29.600
可靠性还没有跨过制度门槛

00:25:29.800 --> 00:25:31.933
还有一项体验会决定用户

00:25:31.933 --> 00:25:34.066
是否真的愿意长期使用

00:25:34.266 --> 00:25:35.333
那就是打断

00:25:35.933 --> 00:25:37.466
人与人交谈时

00:25:37.466 --> 00:25:38.966
对方说错一个日期

00:25:39.166 --> 00:25:41.133
听者会立刻插话纠正

00:25:41.200 --> 00:25:43.000
不会等整段话结束

00:25:43.266 --> 00:25:44.733
实时模型必须在播放

00:25:44.733 --> 00:25:46.666
语音的同时继续监听

00:25:46.800 --> 00:25:48.333
判断用户是在附和

00:25:48.500 --> 00:25:50.533
补充还是要求停止

00:25:50.966 --> 00:25:52.000
判断太敏感

00:25:52.100 --> 00:25:54.333
背景声音会频繁打断回答

00:25:54.400 --> 00:25:55.500
判断太迟钝

00:25:55.733 --> 00:25:57.333
系统又会恢复成过去

00:25:57.333 --> 00:25:59.500
那种必须等它说完的机器

00:25:59.566 --> 00:26:01.733
发布页强调流畅对话

00:26:01.766 --> 00:26:03.466
真正的产品考验却在

00:26:03.466 --> 00:26:05.133
这些毫秒级决定里

00:26:05.166 --> 00:26:07.533
打断以后还要处理任务状态

00:26:08.000 --> 00:26:09.600
用户说不要周五

00:26:09.600 --> 00:26:10.800
改成周六

00:26:11.133 --> 00:26:14.166
模型需要撤销尚未提交的查询条件

00:26:14.500 --> 00:26:17.200
同时保留人数地点和预算

00:26:17.666 --> 00:26:19.933
要是后台工具已经返回周五

00:26:20.066 --> 00:26:23.000
结果系统不能把旧数据混入新方案

00:26:23.266 --> 00:26:26.100
语音体验看起来只是一段声音

00:26:26.333 --> 00:26:28.900
底下却需要严密的事务管理

00:26:29.533 --> 00:26:32.866
Gemini3.8live把模型能力推到新的位置

00:26:32.966 --> 00:26:34.666
也把传统软件工程的

00:26:34.666 --> 00:26:36.766
问题重新带回AI产品

00:26:36.900 --> 00:26:40.000
所以开头那个协议细节才重要

00:26:40.666 --> 00:26:43.300
turn complete不再意味着任务结束

00:26:43.566 --> 00:26:45.600
代表AI的工作第一次

00:26:45.600 --> 00:26:47.733
可以延伸到一句话之后

00:26:47.866 --> 00:26:50.133
用户听见的回答只是前台

00:26:50.133 --> 00:26:52.200
后台还在推理和行动

00:26:52.300 --> 00:26:53.766
下一场竞争不会只

00:26:53.766 --> 00:26:55.366
比谁回答得更聪明

00:26:55.366 --> 00:26:56.700
而会比谁能把这个

00:26:56.700 --> 00:26:58.300
看不见的后台管住

00:27:19.066 --> 00:27:21.100
他接下来必须证明的是

00:27:21.100 --> 00:27:22.466
模型做错时

00:27:22.500 --> 00:27:25.000
整个系统也知道怎样停下来

00:27:25.100 --> 00:27:26.533
那个问题还没有关闭

00:27:26.800 --> 00:27:28.733
而它会决定实时智能体

00:27:28.733 --> 00:27:30.800
究竟成为下一代操作界面

00:27:30.866 --> 00:27:33.100
还是下一批企业事故的来源