Pārlūkprogrammai drošs reāllaika AI, izmantojot API vārteju: īslaicīgi marķieri, nomnieka politika un balss sesijas vadīklas
Praktiska pārlūkprogrammas un mobilās balss AI arhitektūra: saglabājiet reāllaika multivides zemu latentumu, izmantojot īslaicīgus klienta akreditācijas datus, kamēr vārteja ievieš nomnieku politiku, budžeta pārbaudes, rīku vadīklas un audita pēdas.
Pārlūkprogrammas un mobilās lietotnes nedrīkst saņemt ilgstošas pakalpojumu sniedzēja API atslēgas. Tomēr reāllaika balss AI gadījumā katras audio paketes nosūtīšana caur vārteju var palielināt latentumu, darbības izmaksas un atteices režīmus. Labākais modelis ir saglabāt vārteju vadības plaknē: autentificējiet lietotāju, ieviešiet nomnieka politiku, rezervējiet budžetu, izveidojiet šauru īslaicīgu reāllaika akreditācijas datus un ļaujiet latentuma jutīgiem multivides līdzekļiem izmantot pakalpojumu sniedzēja reāllaika transportu, ja tas ir nepieciešams.
Šajā rakstā ir aprakstīts ieviešanas modelis komandām, kas veido balss aģentus, zvanu palīgus, mobilos pasniedzējus, atbalsta koppilotus vai lietotnes balss saskarnes, izmantojot AI API vārteju. Mērķis ir pārlūkprogrammas drošība, nezaudējot nomnieka pārvaldību.
Problēma: tiešie reāllaika savienojumi apiet jūsu vadīklas
Vienkāršs servera puses starpniekserveris ir pievilcīgs, jo tas centralizē atslēgas un novērojamību. Standarta teksta pieprasījumiem tas bieži ir pareizais modelis. Reāllaika audio ir atšķirīgs. Balss sesija var ietvert nepārtrauktu mikrofona ievadi, divvirzienu audio izvadi, pārtraukumus, rīku izsaukumus un stingras latentuma gaidas. Visu multivides starpniekserveris, izmantojot savu vārteju, var pārvērst vārteju par multivides releju ar lielu joslas platumu, nevis politikas un norēķinu pakalpojumu.
Tiešie pārlūkprogrammas un pakalpojumu sniedzēja savienojumi atrisina latentumu, taču rada citu problēmu.
- Pārlūkprogramma nevar droši turēt standarta nodrošinātāja API atslēgu.
- Īrnieka budžeta pārbaudes var tikt izlaistas, ja lietotne tiek savienota tieši.
- Modeļa, reģiona, balss, modalitātes un rīku ierobežojumi kļūst par klienta puses solījumiem.
- Lietošanas attiecinājums kļūst nepilnīgs vai aizkavējas.
- Drošības komandas zaudē auditējamu lēmuma pieņemšanas punktu pirms sesijas sākuma.
Praktiskais dizains nav “katra baita starpniekserveris”. Tas ir “starpnieks katrā sesijā”.
Fakti, ieteikumi un prognozes
Fakti: reāllaika AI pakalpojumu sniedzēji arvien vairāk atbalsta zema latentuma pārsūtīšanu, piemēram, WebRTC, WebSocket un SIP. OpenAI Realtime API publiskajā dokumentācijā ir aprakstītas zema latentuma reāllaika saskarnes, tostarp WebRTC. Azure OpenAI reāllaika WebRTC norādījumi apraksta pārlūkprogrammas lietojumprogrammu, kas izmanto aizmugursistēmas marķiera pakalpojumu, lai izgūtu īslaicīgu marķieri pirms WebRTC savienojuma uzsākšanas, un brīdina par standarta API atslēgas izmantošanu klienta lietojumprogrammā. OpenAI Agents SDK reāllaika norādījumi iesaka arī plūsmu, kurā aizmugursistēma izveido īslaicīgu īslaicīgu klienta pilnvaru un pārlūkprogramma to izmanto, lai izveidotu WebRTC savienojumu.
Ieteikumi: uztveriet vārteju kā sesijas autoritāti. Tam vajadzētu izlemt, vai var pastāvēt reāllaika sesija, ar kuru modeli, kurā reģionā, kādam nomniekam, saskaņā ar kādu budžetu un ar kādiem rīkiem. Klientam ir jāsaņem tikai minimālie īslaicīgie akreditācijas dati, kas nepieciešami, lai sāktu šo apstiprināto sesiju.
Prognozes: reāllaika nodrošinātāju API kādu laiku paliks nevienmērīgi. Marķiera kalpošanas laiks, sesijas konfigurācijas lauki, servera puses atvienošanas vadīklas, lietošanas notikumi un reģiona atbalsts atšķirsies. Vārtejām ir skaidri jāmodelē nodrošinātāja iespējas, nevis jāizliekas, ka visas reāllaika API ir lieliski pārnēsājamas.
Atsauces arhitektūra: vārteja kā reāllaika vadības plakne
Pārlūkprogrammai drošai reāllaika plūsmai ir piecas daļas:
- Klienta lietotne: pārlūkprogramma vai mobilā lietotne, kas pieprasa balss sesiju.
- Lietojumprogrammas aizmugursistēma: autentificē galalietotāju un izsauc vārteju vai iegulta vārtejas pilnvaru kalšanas loģiku, ja vārteja ir daļa no aizmugursistēmas steka.
- AI API vārteja: ievieš nomnieka politiku, atrisina modeļa profilu, rezervē budžetu, reģistrē sesiju un izveido īslaicīgu pakalpojumu sniedzēja klienta noslēpumu.
- Reāllaika nodrošinātājs: pārtrauc WebRTC vai citu reāllaika transportu.
- Virsgrāmata un analīze: nokārto lietojumu, tiklīdz ir pieejami pakalpojumu sniedzēja notikumi, ilguma dati vai galīgie lietojuma pārskati.
Vārtejai nav jāpārraida katrs audio kadrs, lai saglabātu savu autoritāti. Tam ir jābūt sesijas izveides lēmumam un saskaņošanas ceļam.
Ieteicamā pieprasījuma plūsma
- Lietotājs klienta lietotnē atver balss funkciju.
- Klients izsauc jūsu aizmugursistēmu:
POST /voice/sessions. - Aizmugursistēma pārbauda lietotāja sesiju un pārsūta uz vārteju pieprasījumu ar nomnieka ID, lietotāja ID, paredzēto līdzekli, ierīces metadatiem un izcelsmi.
- Vārteja novērtē politiku un budžetu.
- Pirms sazināšanās ar pakalpojumu sniedzēju, vārteja izveido lokālu
realtime_sessionierakstu. - Vārteja izsauc pakalpojumu sniedzēju, izmantojot aizsargātos izpildlaika akreditācijas datus, un izveido šauri aptverošu īslaicīgu reāllaika sesiju.
- Vārteja pārlūkprogrammai atgriež tikai īslaicīgus klienta noslēpumu un apstiprinātos sesijas metadatus.
- Pārlūkprogramma izveido WebRTC savienojumu tieši ar pakalpojumu sniedzēju.
- Vārteja pārņem pakalpojumu sniedzēja lietošanas notikumus, atzvanīšanu, aptauju rezultātus vai konservatīvus, uz ilgumu balstītus aprēķinus.
- Virsgrāmata nokārto rezervēto budžetu un raksta audita notikumus.
Pārbaudes pirms naudas kalšanas politikas
Svarīgākais izpildes punkts ir pirms īslaicīgā marķiera kalšanas. Tiklīdz pārlūkprogrammai ir īslaicīgi akreditācijas dati, izpilde sesijas vidū var tikt ierobežota, ja vien pakalpojumu sniedzējs neatbalsta sesijas atjaunināšanas, atvienošanas, novērotāja vai atzvanīšanas vadīklas.
Vārtejai ir jāpārbauda vismaz:
- Īrnieka statuss: aktīvs, apturēts, izmēģinājuma periods, priekšapmaksa, rēķins vai karantīnā.
- Lietotāja tiesības: vai šis lietotājs drīkst izmantot reāllaika balsi, ne tikai teksta tērzēšanu.
- Atļautais modeļa profils: apstiprināts reāllaika modelis vai izvietošana, nevis patvaļīgi klienta nodrošināti modeļu ID.
- Reģiona un saglabāšanas politika: vai atlasītais pakalpojumu sniedzēja reģions un funkciju kopa atbilst nomnieka datu noteikumiem.
- Maksimālais sesijas ilgums: piemēram, 5, 15 vai 30 minūtes pēc plāna.
- Atļautās darbības: audio ievade, audio izvade, teksta, attēla vai rīku izsaukumi.
- Balss un norādījumu veidne: nosaka vai ierobežo politika.
- Pieejams budžets: priekšapmaksas atlikums, rezervēts ikmēneša pabalsts vai katras funkcijas tēriņu griesti.
- Vienlaicīgums: nomnieka līmeņa un lietotāja līmeņa aktīvās balss sesijas.
- Ļaunprātīgas izmantošanas kontrole: lietotāju riska karodziņi, izcelsmes reputācija, neparasts zvanu ātrums vai nomnieka iznīcināšanas slēdzis.
Drošs noklusējuma veids ir noraidīt neskaidrus pieprasījumus. Ja klients pieprasa modeli, rīku, balsi vai reģionu, kas nav iekļauts nomnieka reāllaika politikā, vārtejai ir jāatgriež skaidra politikas kļūda, nevis klusi jāpaplašina piekļuve.
Sesijas ieraksta dizains
Pirms nodrošinātāja akreditācijas datu izveidošanas izveidojiet vārtejas puses sesijas ierakstu. Tas nodrošina audita enkuru pat tad, ja nodrošinātāja izveide ir veiksmīga, bet pārlūkprogramma nekad nepievienojas.
{
"session_id": "rt_01j...",
"īrnieka_id": "īrnieks_123",
"end_user_id": "user_hash_456",
"provider": "provider_a",
"provider_session_id": null,
"model_profile": "balss atbalsta standarts",
"upstream_model_or_deployment": "realtime-model-x",
"reģions": "eastus",
"session_config_hash": "sha256:...",
"allowed_modalities": ["audio_input", "audio_output"],
"allowed_tools": ["lookup_order_status"],
"tool_approval_policy": "approve_side_effects",
"budget_reservation_id": "resv_789",
"max_duration_seconds": 900,
"issued_at": "2026-08-21T10:00:00Z",
"expires_at": "2026-08-21T10:01:00Z",
"client_origin": "https://app.example.com",
"device_id_hash": "sha256:...",
"statuss": "kalšana"
}
Pēc noklusējuma nesaglabājiet neapstrādātu mikrofona audio vai pilnas uzvednes. Veikala konfigurācijas jaucējkodi, ID, politikas lēmumi un minimālie metadati, kas ir pietiekami auditam, atbalstam un norēķiniem. Ja ir nepieciešama ierakstīšana, dariet to skaidri formulētu, informētu par piekrišanu un pamatojoties uz īrnieka politiku.
Īslaicīga marķiera kalšanas galapunkts
Uz vārteju vērsts galapunkts varētu izskatīties šādi:
POST /v1/realtime/sessions
Autorizācija: nesējs
Satura veids: lietojumprogramma/json
{
"īrnieka_id": "īrnieks_123",
"end_user_id": "user_hash_456",
"funkcija": "support_voice_agent",
"origin": "https://app.example.com",
"device_nonce": "8f3b...",
"requested_profile": "balss atbalsta standarts"
}
Atbilde nedrīkst atklāt jūsu augšējo izpildlaika atslēgu:
{
"session_id": "rt_01j...",
"provider": "provider_a",
"transports": "webrtc",
"client_secret": "ephemeral_secret_here",
"expires_at": "2026-08-21T10:01:00Z",
"apstiprināts": {
"model_profile": "balss atbalsta standarts",
"max_duration_seconds": 900,
"modalitātes": ["audio_input", "audio_output"],
"rīki": ["lookup_order_status"]
}
}
Saistīt izdošanu ar izcelsmi, autentificēta lietotāja sesiju, nomnieku un nomnieku. Pakalpojumu sniedzējs var neatbalstīt visus šos saistījumus sākotnēji, tāpēc ieviesiet to, ko varat vārtejā: ierobežojiet kalšanas mēģinājumus, noraidiet neparedzētu izcelsmi, ierakstiet ierīces metadatus un saīsiniet pilnvaras darbības laiku.
Sesiju veidnes: pēc noklusējuma šauras
Reāllaika sesijas veidnei ir jābūt ierobežojošākai nekā vispārējam tērzēšanas pabeigšanas pieprasījumam. Balss sesijas ir interaktīvas, tās ir grūtāk pārbaudīt reāllaikā, un tās var ilgt ilgāk, nekā paredzēts.
Ieteicamie veidnes lauki ietver:
- Fiksēts modelis vai izvietošana: izvēlas vārtejas modeļa profils.
- Norādījumi: servera kontrolēta uzvednes veidne ar nomnieka apstiprinātiem mainīgajiem.
- Balss: atlasīta no atļauju saraksta.
- Modalitātes: atspējojiet teksta, attēla vai rīku režīmus, ja vien tie nav nepieciešami produktam.
- Ievades audio iestatījumi: pagriezienu noteikšana, transkripcijas darbība vai klusuma apstrāde, ja tiek atbalstīta.
- Izvades ierobežojumi: maksimālais atbildes ilgums vai reakcijas uzvedība, ja tiek atbalstīta.
- Rīku atļaušanas saraksts: tikai funkcijai nepieciešamie rīki.
- Sesijas ilgums: īss akreditācijas datu derīguma termiņš plus maksimālais zvana ilgums.
Stingras veidnes samazina elastību, taču tās atvieglo izmaksas, atbilstību un atbalstu. Ja produktu komandām ir nepieciešamas dinamiskas balsis vai norādījumi, atklājiet kontrolētos profila variantus, nevis nododiet pakalpojumu sniedzējam patvaļīgu klienta konfigurāciju.
Budžeta vadīklas reāllaika balsij
Reāllaika lietojuma cenu var būt grūtāk noteikt pirms pakalpojumu sniedzēja gala lietojuma. Sesija var ilgt piecas sekundes vai divdesmit minūtes. Tas var ietvert audio ievadi, audio izvadi, transkripciju, rīku izsaukumus un teksta marķierus. Tāpēc vārtejai ir jāapvieno rezervēšana, ierobežojumi un saskaņošana.
Pirms kalšanas
- Aprēķiniet sliktākā gadījuma vai konservatīvās sesijas izmaksas, pamatojoties uz maksimālo ilgumu, modeli, modalitātēm un nomnieka plānu.
- Rezervesējiet budžetu pirms klienta noslēpuma izsniegšanas.
- Noraidīt jaunas sesijas, ja nomniekam nav pietiekama līdzsvara vai ir sasniegts dienas balss limits.
Sesijas laikā
- Izsekojiet aktīvās sesijas un paredzamo ierakstīšanas ātrumu.
- Lietojiet nomnieka un lietotāja vienlaicības ierobežojumus.
- Izmantojiet pakalpojumu sniedzēja atbalstītus pārtraukšanas vai sesijas atjaunināšanas līdzekļus, ja tie ir pieejami.
- Ieslēgt brīdinājumus par neparastu sesijas ilgumu, atkārtotu savienojumu vai neparastu balss lietojumu.
Pēc sesijas
- Iegūstiet pakalpojumu sniedzēja lietošanas notikumus vai galīgos lietojuma pārskatus, ja tie ir pieejami.
- Sakārtojiet rezervēto budžetu atbilstoši faktiskajām izmaksām.
- Ja precīza izmantošana aizkavējas vai nav pabeigta, saglabājiet konservatīvu rezervāciju līdz saskaņošanai.
- Attieciniet lietojumu uz nomnieku, lietotāju, līdzekli, modeļa profilu un sesijas ID.
Tas ir mazāk precīzs nekā sinhronais teksta rēķins atbildes brīdī, taču tas ir funkcionāli drošāks nekā tiešo akreditācijas datu izsniegšana bez rezervācijas.
Rīku izsaukumi reāllaika sesijās
Reāllaika balss aģenti bieži kļūst noderīgāki, ja tie var izsaukt rīkus: meklēt kontā, rezervēt tikšanos, atjaunināt biļeti vai aktivizēt darbplūsmu. Rīka izpildi aplūkojiet atsevišķi no audio pārsūtīšanas.
Pārlūkprogrammas multivides savienojums nedrīkst nozīmēt atļauju radīt blakusparādības. Vārtejai vai aizmugursistēmai ir jāievieš:
- Rīku reģistrs: katram rīkam ir īpašnieks, shēma, darbības jomas un riska līmenis.
- Atļauju saraksti: sesiju veidnēs ir precīzi norādīti pieejamie rīki.
- Apstiprinājuma vārti: blakusefektīvām darbībām ir nepieciešams lietotāja apstiprinājums, cilvēka apstiprinājums vai politikas apstiprinājums.
- Atsevišķi akreditācijas dati: rīka akreditācijas dati nekad netiek iegulti pārlūkprogrammas sesijā.
- Pievienota audita izsekojamība: katrs rīka izsaukums atsaucas uz reāllaika sesijas ID.
Piemēram, atbalsta balss aģentam var būt atļauts automātiski izsaukt lookup_order_status, bet refund_payment var pieprasīt skaidru apstiprinājumu un aizmugursistēmas apstiprināšanas notikumu. Reāllaika pakalpojumu sniedzējs var organizēt sarunu, taču jūsu vārtejai ir jāpārvalda atļauju robeža.
Redzamība, neizmantojot katru baitu starpniekserverī
Tiešā WebRTC multivides plūsma samazina vārtejas latentumu un joslas platuma slodzi, taču redzamība kļūst vairāk atkarīga no pakalpojumu sniedzēja notikumiem un jūsu sesijas metadatiem. Izstrādājiet analīzi, pamatojoties uz vairākiem pierādījumu avotiem:
- Sesijas izveides ieraksti no vārtejas.
- Klienta dzīves cikla notikumi, piemēram, savienojums izveidots, atvienots, mēģinājums atkārtoti izveidot savienojumu, mikrofons ir liegts vai zvans ir pārtraukts.
- Pakalpojumu sniedzēja sesijas ID, lietošanas notikumi vai galīgā lietojuma ieraksti.
- Uz ilgumu balstīti aprēķini, ja pakalpojumu sniedzēja lietošana kavējas.
- Rīku zvanu žurnāli ir savienoti ar sesijas ID.
- Budžeta rezervēšanas un norēķinu ieraksti.
Pirms vadīklu palaišanas negaidiet perfektu pakalpojumu sniedzēja telemetriju. Sāciet ar konservatīvām atrunām un skaidru attiecinājumu, pēc tam uzlabojiet norēķinu precizitāti, kad pakalpojumu sniedzēja lietojuma pārskati kļūst gatavi.
Drošības kontrolsaraksts
- Nekad nesūtiet standarta pakalpojumu sniedzēja API atslēgas pārlūkprogrammai vai mobilajiem klientiem.
- Izmantojiet īslaicīgus īslaicīgus klienta noslēpumus reāllaika sesijas startēšanai.
- Autentificējiet galalietotāju pirms marķiera kalšanas.
- Ja iespējams, piesaistiet kalšanas lēmumus ar nomnieka, lietotāja, izcelsmes, nonce un ierīces metadatiem.
- Saglabājiet nodrošinātāja izpildlaika akreditācijas datus aizmugursistēmas glabātuvē vai vārtejas slepenajā krātuvē.
- Pirms nodrošinātāja izveides ierakstiet sesijas audita rindu.
- Izmantojiet nomnieka apstiprinātas sesijas veidnes, nevis patvaļīgu klienta konfigurāciju.
- Lietojiet vienlaicības, ikdienas lietojuma un maksimālā ilguma ierobežojumus.
- Lai novērstu blakusparādības, izmantojiet rīku atļaušanas sarakstus un apstiprināšanas vārtus.
- Pēc noklusējuma samaziniet neapstrādātas uzvednes un audio saglabāšanu.
- Uzturēt nodrošinātāja iespēju matricu marķiera kalpošanas laikam, reģioniem, rīkiem, lietošanas notikumiem un pārtraukšanas vadīklām.
Pakalpojumu sniedzēja iespēju matrica
Tā kā reāllaika API atšķiras, modelējiet vārtejas adapteri, pamatojoties uz iespējām, nevis pieņēmumiem. Vienkārša matrica var vadīt maršrutēšanas un politikas lēmumus:
{
"provider_a": {
"transports": ["webrtc", "websocket"],
"ephemeral_client_tokens": taisnība,
"token_ttl_seconds": 60,
"server_side_disconnect": patiess,
"session_update": taisnība,
"usage_events": "final_and_incremental",
"reģioni": ["us", "eu"],
"tool_approval_supported": taisnība
},
"provider_b": {
"transports": ["websocket"],
"ephemeral_client_tokens": taisnība,
"token_ttl_seconds": 120,
"server_side_disconnect": nepatiess,
"session_update": nepatiess,
"usage_events": "final_only",
"reģioni": ["mums"],
"tool_approval_supported": nepatiess
}
}
Ja nomniekam ir nepieciešama ES rezidence un servera puses pārtraukšana, vārtejai ir jāmaršrutē tikai tādi pakalpojumu sniedzēji un izvietojumi, kas apmierina abus. Ja neviens pakalpojumu sniedzējs neatbilst politikai, neveiksmes aizvērts.
Migrācijas ceļš
Jums nav jāizveido katra vadīkla pirmajā dienā. Praktiska ieviešana ir šāda:
- Tikai starpniekservera sesijas izveide: saglabājiet multivides saturu tiešu, taču visas reāllaika sesijas ir jāizveido aizmugursistēmai vai vārtejai.
- Pievienojiet politikas veidnes: aizstājiet klienta nodrošināto modeļu un norādījumu laukus ar apstiprinātiem profiliem.
- Pievienot budžeta rezervāciju: rezervējiet konservatīvas sesijas izmaksas pirms marķiera izsniegšanas.
- Pievienojiet dzīves cikla analīzi: apkopojiet sesijas sākumu, izveidošanu, atvienošanu, ilgumu, nodrošinātāja sesijas ID un norēķinu statusu.
- Pievienojiet rīka pārvaldību: pieprasiet atļauju sarakstus un apstiprinājumus reāllaika rīku izsaukumiem.
- Pievienojiet pakalpojumu sniedzēja iespēju maršrutēšanu: atlasiet pakalpojumu sniedzējus pēc reģiona, modalitātes, notikumu atbalsta un pārtraukšanas vadīklām.
- Izvēles novērotāja vai ierakstīšanas darbplūsmas pievienošana: tikai tad, ja tas atbilst prasībām, ir saņemta piekrišana un nomnieks ir apstiprinājis.
Lietojams secinājums
Reāllaika balss AI AI API vārtejai nevajadzētu automātiski kļūt par multivides pārraidi. Drošāka un mazāka latentuma arhitektūra ir saglabāt vārteju, kas ir atbildīga par vadības plakni: autentificēt lietotājus, īstenot nomnieku politiku, rezervēt budžetu, izveidot audita ierakstu, izveidot šauras darbības jomas īslaicīgus akreditācijas datus un saskaņot lietošanu pēc sesijas.
Galvenais ieviešanas noteikums ir vienkāršs: pārlūkprogrammas var saņemt īslaicīgus sesijas noslēpumus, nevis ilgstošas nodrošinātāja atslēgas. Viss pārējais izriet no šīs robežas: stingras veidnes, izcelsmi apzinoša kalšana, vienlaicīgu sesiju ierobežojumi, rīku apstiprinājumi, lietojuma norēķini un nodrošinātāja iespēju matricas. Tas sniedz produktu komandām reāllaika balss pieredzi, neatsakoties no API atslēgu pārvaldības, AI API izmaksu kontroles, komandas API pārvaldības vai AI lietojuma analīzes.