Conversation
|
工具调用是原对话的自然延伸,不应被割裂为多个独立的 TTS 会话。 当前流程为: |
你说的场景是当前的局限,只能接受调用工具的结果,一问一答 call mcp tool
response 'success' --> TTS但实际上,MCP支持异步的,一问多答,所以FIRST 和 LAST在每次TTS都必须存在,没有例外 call mcp tool
progress 0.3/1.0 --> TTS
progress 0.6/1.0 --> TTS
progress 0.9/1.0 --> TTS
response 'success' --> TTS |
|
你这个异步时间间隔多少?TTS不会超时断开?在这么长等待进度通知的时间里,TTS要一直处于激活状态即使没有语音要合成? |
|
这个异步工具的话是3秒左右就能有中间结果了,绝大部分TTS使用websocket链接都能保持一定时间内的文本接收,阿里云是10秒(这个试了一下,解析函数意图需要2-3秒,所以中间层应该是个6秒左右的时间需要传文本,不然那边服务端就自行关闭了),百炼的是1分钟,火山的是2分钟,部分是需要采取重新链接的方式(讯飞),至于那些使用http的,本身就是随到随用就不用考虑链接问题了。 |
|
这个异步工具的话是3秒左右就能有中间结果了?这个结论是哪里来的,progress的存在是为了耗时操作的,这个耗时可能是5s,20s,120s,甚至5分钟,MCP协议也没有规定3秒就必须有结果。
你说的是允许TTS空运行,这本身就是不合理的,TTS就是根据文字合成语音,没有文字的情况下就应该释放。火山引擎/阿里云都有并发限制,按需使用,尽早释放链接都是官方建议的。 上面我说的很明白了,TTS是TTS,和大模型不能强耦合,FIRST LAST的目的就是为了标记文字的开头和结尾,方便用来开始初始化/结束TTS。上层应用需要调用TTS就发送FIRST | 待合成文本 | LAST去执行合成就好了。而不是把TTS合成时机一层一层向上耦合 |
|
有道理,应该得适配一下TTS空开(AiBL没文本发送的话会报错) |

No description provided.