Gemini Live Avatar上线：先分清视频和模型

先把三个层次拆开

　　第一层是实时对话。它采用speech-to-speech，也就是语音直接进、语音直接出，中间不必由开发者自己搭一套“语音转文字—模型回答—文字转语音”的流水线。这样做的价值是减少环节，打断后更容易接着说。

　　第二层是视觉输入。系统可以看用户的摄像头画面和屏幕共享。Google给出的演示是理赔受理：用户一边说情况，一边把损坏部位展示给摄像头，后台代理根据保单和受理规则整理记录。这里的“看见”只代表模型收到了画面，不代表它已经完成了定损、定责或赔付决定。

　　第三层是工具调用。模型可以在对话没有停下时，后台查询接口或执行其他API调用。比如客户问库存，头像继续和客户说话，系统同时查询库存服务。能调用工具，和能安全地调用工具，是两件事。订单修改、退款、身份确认等动作，都应该留下人工确认点。

一次小任务先跑通

　　如果要评估这项能力，先不要把它接进客服主链路。可以用一条不涉及真实个人信息的“产品说明问答”做小实验，目标只设成：听懂问题、看懂一张示意图、查一次只读数据，然后把结果交给人工确认。

　　第一步，写清输入。准备一段脱敏产品说明、一张公开示意图和一条只读查询接口。不要上传客户身份证、订单截图、内部报价表或访问令牌。摄像头和屏幕共享都属于额外输入，先列出系统究竟会看到什么。

　　第二步，给工具设边界。把工具分成“只读”和“会改变数据”两栏。库存查询、FAQ检索可以先开放；改订单、发短信、退款、提交审批先关闭。工具返回结果时保留原始字段，不要只把一句“查询成功”交给模型。

　　第三步，设一个人工接管句。比如：“我已经查到可用库存，但不会替你下单；请由工作人员确认型号、价格和收货信息。”这句话不是提示词装饰，而是把模型能做的事和业务最终决定分开。

　　第四步，重复测试同一组问题。至少准备五条固定问题，分别测试打断、口音、换语言、展示屏幕和接口超时。记录四项：模型听到了什么、调用了哪个工具、输出是否引用了正确字段、人工是否能在提交前接管。不要只看头像说话是否自然。

　　第五步，故意让它失败一次。把示意图换成模糊图片，让只读接口返回超时，再看系统是否明确说“无法确认”，还是继续编一个结果。对于面向客户的系统，承认看不清、查不到和权限不足，比维持流畅对话更重要。

头像会增加哪些成本

　　视频层会增加带宽、延迟和算力消耗。Google目前强调的是企业可用、合规和数据治理，并没有在这篇上线公告里给出适用于所有场景的统一单次账单。企业不能拿普通文字模型的价格估算Live Avatar。至少要把会话时长、视频帧率、并发峰值、工具调用次数和失败重试单独列出来。

　　头像也会改变用户对系统的信任判断。一个表情自然、说话流畅的数字人，容易让人误以为它已经看懂了全部材料。实际上，视觉理解仍会受到遮挡、反光、低清画面和上下文缺失影响。页面上写着“支持摄像头和屏幕共享”，不等于每一类业务证据都能由模型独立确认。

　　身份和肖像是另一条边界。Google称，系统提供经过筛选的预置头像；自定义头像需要企业allowlist和验证，生成的音频、视频流带有不可见的SynthID水印。企业如果要用真人形象，仍需把授权对象、使用范围、保存期限和撤回机制写进自己的流程，不能把“有水印”当成全部合规工作已经完成。

先问清楚它到底替谁做事

　　适合先试的，是展台讲解、产品导览、内部培训、只读查询和资料收集。它们的共同点是：结果可以被人复核，失败不会直接改变用户权益。

　　不适合一开始就交给它的，是自动退款、身份核验后的放行、医疗分诊、合同确认、账号权限修改和任何不可逆操作。对话越像真人，人工边界越要写得更清楚。系统应该在界面上显示当前是否调用了工具、调用结果来自哪里、哪些动作还没有执行。

　　今天可以先做一个小动作：拿五条脱敏问题和一张公开示意图，画出“语音输入—视觉输入—只读工具—人工确认”四格流程，再标出每一步会接触的数据。只要有一格说不清，先不要把头像接到真实业务里。Live Avatar的第一道门槛不是会不会说话，而是企业能否让用户看得见它正在看什么、调用什么，以及还没有替用户做什么。