Pattern di design agentici
Le forme con cui si costruiscono gli agenti: ognuna eseguibile e letta rispetto ai dieci principi.
Cosa contiene un pattern che un esempio non ha
Ogni pattern indica quali principi esprime direttamente nel codice, quali la sua implementazione classica infrange silenziosamente e cosa aggiungere quando succede. Sapere che ReAct rende il ragionamento ispezionabile è risaputo; sapere che la sua forma predefinita non offre alcun modo di guidarlo durante l'esecuzione, e cosa aggiungere perché lo faccia, è la parte che crea problemi in produzione.
Tre tipi di relazione, e il silenzio è il quarto
Un pattern dichiara strutturale dove esprime un principio nel codice, lacuna predefinita dove la sua forma base ne infrange uno, e dipende dove decide la tua implementazione e non il pattern. La maggior parte dei principi non ha alcuna riga, ed è voluto. I pattern sono forme di inferenza; i principi governano come il lavoro viene delegato e reso visibile.
Strumenti e azioni (1)
I loop di base. Parti da qui.
Ragionamento e riflessione (1)
Investi più ragionamento per guadagnare affidabilità.
Recupero (1)
Ancora la risposta a qualcosa fuori dal modello.
Memoria (1)
Stato che sopravvive alla sessione successiva.
Campionamento e ricerca (1)
Genera più candidati, poi scegli.
Multi-agente (1)
Dividi il lavoro quando è davvero parallelo.
Sicurezza e instradamento (1)
Decidi cosa viene eseguito e cosa si ferma a chiedere.
Specializzati (0)
Forme specifiche per problemi specifici.
Fa parte della tassonomia. Per questa famiglia non è stato ancora costruito un pattern.
Come si differenzia dalle altre due superfici
Queste sono forme di ragionamento: come un agente decide, quando agisce, cosa ricorda. L'AI Pattern Blueprint copre un altro livello, come comporre l'interfaccia intorno a una superficie mediata dall'AI. Agent runtime architecture ne copre un terzo, gli aspetti di deployment: trigger, pianificazione, caricamento del contesto e ripristino. Un sistema di solito ha bisogno di tutti e tre.
Queste relazioni sono analisi, non una validazione
Le relazioni sono analisi di prima parte sulla doctrine, scritte insieme al codice, non il risultato di una validazione con punteggio. Indicano onestamente quale tecnica descrivono e ne citano la fonte; non valutano mai il framework di un fornitore specifico. Per ottenere un giudizio con punteggio, esegui il validatore sul tuo repository.
Le relazioni con la doctrine sono analisi di prima parte, non il risultato di una validazione. Esegui il validatore sul tuo codice per ottenere un verdetto con punteggio.
Also in this section