Canali di accesso ai modelli

In breve

«Usare un modello» non identifica un contratto tecnico. Applicazione interattiva, harness da terminale, SDK, API realtime e telefonia possono arrivare alla stessa famiglia di modelli, ma differiscono per identità, dati ammessi, strumenti, trasporto e gestione degli errori. Una capacità vista in un canale non va promessa negli altri finché non è stata verificata sulla superficie effettiva.

Mappa dei contratti

Canale	Chiamante	Feedback	Fallimento da progettare
Applicazione interattiva	Persona autenticata	UI, conferme, correzione immediata	sessione o capacità non disponibile
Harness da terminale	Processo avviato dall’utente	stdout, exit status, artefatti	comando risolto male o run silenzioso
SDK o API	Codice applicativo	risultato strutturato, eccezione	timeout, schema invalido, quota
Realtime voce	Client multimediale	eventi, audio e testo in streaming	disconnessione, turno di parola, latenza
SIP/telefonia	Infrastruttura di comunicazione	eventi di chiamata e controllo	routing, consenso, trasferimento umano

Pi come harness minimale appartiene alla seconda riga; Grok Voice attraversa le ultime due. Il nome del modello non annulla queste differenze.

Stesso modello, criteri di successo diversi

In un’interfaccia interattiva, una risposta vuota può essere corretta dalla persona e lo stato è visibile nella UI. In un processo headless, lo stesso risultato è ambiguo: potrebbe significare completamento senza contenuto, timeout o perdita dell’evento finale. Se l’adattatore restituisce soltanto testo, cancella proprio l’informazione necessaria a distinguere i tre casi.

Il contratto headless deve quindi conservare almeno stato terminale, categoria dell’errore e correlazione fra richiesta e risposta. Non basta replicare il prompt dell’interfaccia. Dopo aver definito questi criteri, la verifica operativa controlla che il canale reale li produca.

Scheda prima dell’integrazione

Prima di scrivere codice bastano sei campi:

chiamante: persona | processo | servizio
identità: come viene attribuita e revocata
input: dati e formati ammessi
output: forma osservabile del successo
consenso: dove una persona conferma o interrompe
errore: timeout, retry e fallback espliciti

La scheda impedisce di nascondere una decisione commerciale dentro un dettaglio tecnico. Se il chiamante è un servizio, la policy tramite abbonamento non può essere ereditata dalla sessione personale dello sviluppatore. Se il canale è realtime, un fallback testuale può essere più sensato di fingere equivalenza fra trasporti.

Quando astrarre

Un progetto può astrarre una capacità solo dopo aver definito l’intersezione reale delle implementazioni: stesso significato degli input, errori traducibili e proprietà di sicurezza compatibili. Quando queste condizioni non esistono, è più onesto dichiarare la dipendenza dal canale e offrire un errore chiaro. Un adattatore riduce differenze sintattiche; non crea capacità, autorizzazioni o garanzie mancanti.

Limiti

Questa mappa non è una matrice di compatibilità fra provider. Disponibilità, autorizzazioni e formati cambiano; i claim di prodotto vanno controllati nella documentazione primaria e con un test autorizzato del canale scelto.

Voci correlate

• Politica di accesso tramite abbonamento
• Verificare il canale eseguito
• Grok Voice: superfici e protocolli
• Pi come harness minimale

Fonti

• Pi documentation, fonte primaria per modalità interattive e programmatiche dell’harness.
• xAI: Speech-to-Speech, fonte primaria per la superficie realtime bidirezionale.