Agente-ad-Agente (A2A)

Nella pagina precedente è stato illustrato come comporre gli agenti all'interno di un singolo processo, un agente chiama un altro come strumento di funzione e il framework gestisce il resto. Questo modello funziona correttamente quando tutti gli agenti risiedono nella stessa applicazione, condividono lo stesso runtime e vengono gestiti dallo stesso team.

Ma i sistemi agenti reali spesso devono comunicare attraverso i confini. Agent-to-Agent (A2A) è un protocollo aperto progettato esattamente per questo. Definisce un modo standard per consentire agli agenti di individuarsi tra loro, scambiare messaggi e coordinare le attività, tramite HTTP, attraverso qualsiasi limite, in qualsiasi linguaggio o framework. Agent Framework offre l'integrazione A2A predefinita , in modo da poter ospitare e chiamare agenti conformi ad A2A con una configurazione minima.

Quando usare questa opzione

Usare A2A quando gli agenti devono superare un limite che la composizione in-process non può gestire:

  • Limiti del servizio. L'agente di prenotazione viaggi funziona come un microservizio, e l'agente di archiviazione delle spese è eseguito come un microservizio separato. Non possono chiamarsi tra loro come strumenti di funzione in-process, ma hanno bisogno di un protocollo di rete.
  • Limiti del team. Un team partner è proprietario di un agente di verifica della conformità. Non si ha accesso al codice, al modello o alla distribuzione. È sufficiente inviare una richiesta e ottenere una risposta.
  • Limiti dell'organizzazione. Un provider di terze parti offre un agente specializzato (elaborazione di documenti, revisione legale, valutazione medica). È necessario un modo standard per individuarlo, comprenderne le operazioni e comunicare con esso, indipendentemente dal framework o dal linguaggio con cui viene compilato.
  • Evoluzione indipendente. Gli agenti necessitano di cicli di rilascio diversi, team diversi o linguaggi diversi, senza accoppiare strettamente le implementazioni.

Suggerimento

Se tutti gli agenti vivono nello stesso processo e vengono gestiti dallo stesso team, agenti come strumenti sono più semplici e hanno meno sovraccarico. A2A aggiunge valore quando si supera un processo, un servizio o un limite dell'organizzazione.

Considerazioni

Considerazione dettagli
Interoperabilità A2A è indipendente dal framework. L'agente .NET può chiamare un agente Python, un agente LangChain o qualsiasi agente che implementa il protocollo. Si tratta del valore primario di A2A, ovvero "HTTP della comunicazione dell'agente".
Sovraccarico di rete Ogni chiamata A2A è una richiesta HTTP. In questo modo viene aggiunta la latenza rispetto alle chiamate in-process agent-as-tool. Per i percorsi sensibili alle prestazioni, mantenere gli agenti co-localizzati o utilizzare A2A solo se esiste effettivamente un confine.
Complessità operativa Gli agenti remoti sono servizi distribuiti. È necessario gestire gli errori di rete, i timeout, i ritentativi e il versioning: gli stessi problemi che si possono avere con qualsiasi comunicazione da servizio a servizio.
Individuazione in fase di esecuzione Le schede agente rendono dinamica l'individuazione, ma è comunque necessario sapere dove cercare. Nell'ambiente di produzione si configureranno in genere endpoint agente noti o si userà un Registro di sistema.
Stato della conversazione L'agente remoto gestisce il proprio stato della conversazione (identificato tramite ID contesto). L'agente non visualizza il ragionamento interno dell'agente remoto, ma solo le relative risposte. Se l'agente remoto viene riavviato e perde lo stato, il contesto della conversazione potrebbe andare perso.

Passaggi successivi

Ora che gli agenti possono comunicare attraverso qualsiasi limite, il passaggio finale del percorso è rappresentato dai flussi di lavoro , ovvero l'orchestrazione esplicita basata su grafo per processi multi-passaggio, multi-agente in cui è necessario il controllo completo sull'ordine di esecuzione, sullo stato e sulla recuperabilità.

Flussi di lavoro

Approfondimento:

  • Last updated on