-
Notifications
You must be signed in to change notification settings - Fork 2.6k
在异步多轮对话中,会丢失FIRST LAST; FIRST与LAST每次对话都要有 #2555
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
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.