Skip to main contentSkip to footer
Manuale e dottrina

Impara i principi alla base dell'AI agentica affidabile

Ogni pagina di principio spiega cosa significa il principio, perché è importante, quali errori previene e dove andare se stai correggendo fiducia, visibilità, orchestrazione o design delle approvazioni.

Fatti chiave

Principi
10
Usalo per
Vocabolario condiviso, revisione del design, diagnosi degli errori e preparazione alla certificazione
Cluster
delegation, visibility, trust, orchestration
Esempi collegati
96 esempi del repository disponibili per il collegamento incrociato
Ogni pagina include
Definizione, razionale, implicazioni, rischi e prove di implementazione

Dalle demo agentiche alla disciplina runtime

Un modello capace non basta a fare architettura runtime. Se gli agenti devono attivare workflow, caricare file, usare tool, delegare lavoro e agire su piu canali, il runtime ha bisogno di pattern chiari per controllo, visibilita e recovery.

Sfoglia per cluster

Ogni cluster è una home di entità canonica — un hub leggibile dai sistemi che raggruppa i principi correlati e si collega a tutti gli esempi di implementazione.

Principle 1delegation
Progettare per la delega piuttosto che per la manipolazione diretta

Progettare esperienze attorno all'assegnazione del lavoro, l'espressione dell'intento, l'impostazione dei vincoli e la revisione dei risultati, piuttosto che richiedere agli utenti di eseguire manualmente ogni passaggio.

Nei sistemi agentici, il valore viene creato quando gli utenti possono definire l'esito desiderato e fare affidamento sul sistema per eseguire azioni appropriate entro limiti concordati. L'interfaccia dovrebbe quindi supportare la delega come modello di interazione di primo livello.

Principle 2visibility
Assicurarsi che il lavoro in background rimanga percepibile

Quando il sistema opera in modo asincrono o al di fuori del focus immediato dell'utente, dovrebbe fornire segnali persistenti e proporzionati che il lavoro sta continuando.

Gli utenti perdono fiducia quando l'attività delegata diventa invisibile. La fiducia nei sistemi autonomi dipende in parte dalla capacità dell'utente di comprendere che si sta facendo progresso, anche quando non stanno osservando attivamente il processo.

Principle 3visibility
Allineare il feedback al livello di attenzione dell'utente

Il sistema dovrebbe calibrare la profondità e la frequenza del feedback in base al fatto che l'utente sia attivamente impegnato, monitorando passivamente o temporaneamente assente.

Non tutti i momenti richiedono lo stesso grado di visibilità. Alcune attività richiedono una comprensione dettagliata, mentre altre richiedono solo rassicurazione e gestione delle eccezioni. I sistemi efficaci distinguono tra queste modalità.

Principle 4trust
Applicare la divulgazione progressiva all'agenzia del sistema

Fornire per impostazione predefinita le informazioni minime necessarie, consentendo agli utenti di ispezionare ulteriori dettagli quando è richiesta fiducia, comprensione o intervento.

Utenti diversi, e lo stesso utente in contesti diversi, richiedono diversi livelli di trasparenza. L'esperienza predefinita dovrebbe rimanere chiara ed efficiente, mentre un'ispezione più approfondita dovrebbe rimanere disponibile quando giustificata.

Principle 5delegation
Sostituire la magia implicita con modelli mentali chiari

Il prodotto dovrebbe aiutare gli utenti a comprendere cosa il sistema può fare, cosa sta facendo attualmente, cosa non può fare e quali condizioni governano il suo comportamento.

La fiducia è rafforzata quando gli utenti possono formare aspettative accurate. I sistemi che sembrano intelligenti ma rimangono mal definiti creano confusione, uso improprio e affidamento errato.

Principle 6visibility
Esporre uno stato operativo significativo, non la complessità interna

Presentare lo stato del sistema in linguaggio e strutture rilevanti per l'utente, piuttosto che esporre dettagli interni di basso livello che non supportano l'azione o la comprensione.

Gli utenti hanno bisogno di comprendere la verità operativa, ma non necessariamente i dettagli di implementazione. Un buon design traduce l'attività della macchina in uno stato significativo per l'utente.

Principle 7trust
Stabilire fiducia attraverso l'ispezionabilità

Gli utenti dovrebbero essere in grado di esaminare come è stato prodotto un risultato quando la fiducia, la responsabilità o la qualità della decisione sono importanti.

La fiducia non si stabilisce solo attraverso l'affermazione. Si stabilisce consentendo una verifica proporzionata. Soprattutto in contesti ad alto impatto, gli utenti devono poter ispezionare prove, azioni e cambiamenti.

Principle 8trust
Rendere espliciti i passaggi, le approvazioni e i blocchi

Quando il sistema non può procedere, la ragione dovrebbe essere immediatamente visibile, insieme a qualsiasi azione richiesta dall'utente o da un'altra dipendenza.

Nei sistemi agentici, il fallimento spesso non deriva da un ragionamento errato ma da una responsabilità poco chiara. Gli utenti devono sapere quando un compito è in pausa, perché è in pausa e cosa riprenderà il progresso.

Principle 9orchestration
Rappresentare il lavoro delegato come un sistema, non solo come una conversazione

Dove il lavoro coinvolge più passaggi, agenti, dipendenze o attività concorrenti, dovrebbe essere rappresentato come un sistema strutturato piuttosto che solo come un flusso di messaggi.

Un registro conversazionale non è sempre una rappresentazione appropriata per la complessità operativa. Gli utenti hanno bisogno di meccanismi per comprendere relazioni, concorrenza e progressione tra i compiti delegati.

Principle 10delegation
Ottimizzare per la guida, non solo per l'inizio

Il sistema dovrebbe supportare gli utenti non solo nell'avvio dei compiti, ma anche nella guida, nel perfezionamento, nella riprioritizzazione e nella correzione del lavoro mentre è in corso.

Il prompting è un meccanismo di avvio. Non è, di per sé, un modello di controllo sufficiente per lavori complessi o consequenziali. Gli utenti richiedono la capacità di guidare l'attività in corso senza riavviare l'intero processo.

Modalità di errore comuni

Questi sono gli errori ricorrenti che la dottrina è progettata per prevenire. Ogni errore si mappa a uno o più principi nella griglia sopra.

Modalità di erroreDescrizione
AI come abbellimento dell'interfacciaUn prodotto convenzionale è dotato di un input testuale e viene etichettato come intelligente, senza alcun cambiamento significativo nel modello operativo.
Autonomia simulataIl sistema appare autonomo nel linguaggio o nella presentazione ma non può agire con un'indipendenza significativa.
Esecuzione opacaIl lavoro avviene in background senza uno stato adeguato, responsabilità o recuperabilità.
Esposizione operativa eccessivaL'esperienza predefinita presenta dettagli interni non necessari, creando un carico cognitivo senza aumentare la fiducia.
Conversazione come unico modello di coordinamentoTutta l'attività è forzata in un thread di messaggi, anche quando un'orchestrazione strutturata sarebbe più appropriata.
Fallimento silenzioso della dipendenzaIl sistema è in attesa di input, accesso o approvazione da parte dell'utente, ma ciò non viene reso visibile in tempo.
Nessun modello di guidaGli utenti possono avviare il lavoro, ma non possono guidarlo o correggerlo in modo significativo una volta iniziata l'esecuzione.
Come dovrebbe aiutare un praticante una pagina di principio?

Dovrebbe chiarire il giudizio di design, esporre la firma del fallimento e collegare il principio alle prove. La pagina dovrebbe portare un team dalla dottrina all'azione, non solo riformulare la terminologia.

Come dovrebbe aiutare qualcuno a continuare una pagina di principio?

Dovrebbe trasformare la dottrina in navigazione. Ogni pagina dovrebbe collegare il principio a esempi, corsi, laboratori e criteri di valutazione in modo che l'utente possa passare dal concetto all'implementazione e alla revisione.