过去四个月构建一个实时语音语言学习agent的历程(1)

过去四个月，我和 John 在语言学习方面，特别是口语方面，做了一些探索，下面主要介绍我们在构建这个产品的一些思考，以及agent 的实现的经验。起因是看到 Gemini 3 可以理解 youtube 视频，并且Google 还有一个 Live API 可以支持原生的audio输入输出，也就是说不需要用TTS去生成语音，而是在客户端通过websocket进行长连接，这让我发觉有机会去构建一个基于Gemini 和 Live API的一个口语学习的工具。

基于YouTube视频的角色扮演语言学习、Live对话

初始版本的思路是这样的，通过让用户授权自己Google账户的Youtube Data API权限，我们可以抓取到这个账户下用户的所有palylists, 然后我们创建一个专属的playlist, 比如叫做 Youchannel AI. 这样用户就可以在平常浏览youtube视频的时候，把想要作为口语练习材料的视频添加进这个playlist，后台会定时去扫描用户playlists的情况，对用户的视频，调用gemini进行分析，视频分析的prompt包含，transcript，视频的主要角色，summary，这样就完成了一个视频的分析，用户在间隔一段时间进入我们的产品，可以选择该视频中的任意角色进行对话。

不过上面的流程其实存在一些问题，就是Youtube Data API的权限要的scope太大了，如果我们要创建playlist，就必须拿到写入权限，这实际上意味着我们对用户的其他playlist也有操作权限。不过更大的问题是同步和自动后台分析导致的用户tokens消耗，由于后台分析做不到实时，和用户保存视频存在一个时间差，所以存在用户在短时间新增了大量视频、导入另一个playlist的视频、对视频重新进行排序，都有很多异常场景。Youtube Data API每天存在调用次数限制，同时playlist接口一次返回的数量最多50个，也就是说我们之前的逻辑实际上是默认用户处于一个低频率添加视频的状态，并且不会移除视频。由于后台分析Youtube视频是一个比较耗费token的行为，大概5分钟左右视频10w tokens左右，30分钟的视频50w tokens左右。分析一个视频的成本就在 0.5$. 所以后来变成了不创建专有的playlist，也就不需要写的scope权限了，把playlist视频全部读取展示出来，用户手动选择需要分析的视频。

第一版而言，不算一个agent，只是利用了Gemini的能力，所以在看到Chrome内置了Gemini的 Panel，用户也可以分析视频，可以直接进行Live对话。是否这是一个伪需求？当初引入Youtube的考虑就是可以让用户选择自己感兴趣的素材，并且Youtube是一个天然的合适的素材库。当时来看这个产品处境很尴尬，从功能上来说，没有NotebookLLM强大，可以索引分析任何来源的素材（并且我们也烧不起token），从体验上来说，用户天然可以选择OpenAI或者Gemini的APP去直接进行对话，不用花一分钱。并且学习本身就是一件反人性的事情，有多少人会坐在电脑前戴上耳机，然后开始和AI聊天呢？为什么不用手机直接开始？。第一版就这样折腾了一个半月，前期花了太多时间在具体功能的实现上，没有考虑产品自身是否可行，是否有付费人群。可惜当时没有意识到，我们的第二版朝着加强Live API的能力努力，之前的Live API的上下文我们塞的Context是视频分析得到的信息，以及模型的角色定义。本质上还是一个Live API.没有任何记忆，没有任何工具调用。这之后开始了Live Agent的探索之路。

第一版的仓库开源了，感兴趣的可以看下：https://github.com/larry-xue/youchannel 和 https://github.com/larry-xue/youchannel-service

Live Agent

在初版的尝试后，我们放弃了基于Youtube的idea，打算专注于构建一个基于Live API的 agentic 产品。我一开始的思路是这样的，由于Live API本质上是基于Gemini 2.5训练的，所以智能化和上下文有限，并且Live对话的场景，用户对于时延敏感度很高，不适合改成 llm+tts 的agent形式，所以我增加了一个observer agent，这个agent作为一个在live对话时侧载的agent，主要的功能是分析当前的聊天记录，然后给出聊天方向的调整。但是由于llm调用的延时，通常调整的指令回来，对话已经进行了很多轮了。同时还给live api加了一些tool，比如googleSearch，补充了用户当前电脑环境的上下文（界面语言、时区、地区信息），让模型能够很自然的和用户进行聊天。不过这些的效果说实话都不明显，然后我们当时又折腾了很多其他的功能，比如让模型说的快一点，慢一点。这实际上和产品无关，都是在测试模型能力的边界。还有如何处理用户第一次使用的问题，如何告诉用户如何视频模型，如何和用户对话，我们不想要传统的初始化流程，希望它是AI原生的，让模型自己推理出是不是新用户，自己适配。针对这些问题，给live api添加了一些tool。不过效果还是不明显。

某一天，我们开始反思当前的产品，觉得现在的产品还是很初级，并不是一个agentic产品，于是我们去掉了observer，去掉了初始化流程，打算先把对话能力打磨好。考虑到live api的特点，我加了一个hints的实时调用，分析当前对话，然后给出用户可以说的回复，并在里面固定加一句，系统使用的tip，比如：“如果你觉得太快了，可以告诉Rio说慢点~”。使用vercel ai gateway + kimi 2.5 模型，可以做到在1-2s左右返回，使用上很顺畅，模型一般说完以后，提示就能看到了，用户就可以跟着说。另一个就是给Live api加了一个replan的tool，当它识别到需要重新规划当前对话时（用户觉得话题无聊，需要加快降低语速，想换个voice），就主动断连当前live对话，拿到resumeHandler，然后后台的replan模型根据上下文信息，给出调整的提示，再重连对话，发送最新的指令，接着继续对话。不过效果依旧不好，这时候刚好是春节了，就一整周其实都没怎么动，实际上也没什么思路。