Principi

Per ingegneri

Quali principi Blueprint contano di più per l'architettura degli agenti, il design del runtime e l'implementazione.

Inizia con la delegazione

Il cluster di delegazione definisce cosa un agente può decidere da solo rispetto a cosa richiede un umano. Gli ingegneri implementano il confine decisionale — ma il confine stesso è una decisione di prodotto.

L'orchestrazione determina l'affidabilità

I sistemi multi-agente falliscono in modi che le chiamate a modelli singoli non fanno. Il cluster di orchestrazione affronta i passaggi tra agenti, i percorsi di fallback e il contratto di visibilità attraverso una pipeline.

Principi chiave per gli ingegneri

Concentrati su: design-for-delegation-rather-than-direct-manipulation, ensure-that-background-work-remains-perceptible, preserve-undo-retry-rollback-or-repair e prefer-structured-outputs-and-typed-payloads.

Principi essenziali per gli ingegneri4

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.

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.

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.

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.

Anche rilevante

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.

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.

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.

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.

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.

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.

Also in this section

Per designer Guida alla revisione Inizia qui