sfogo casuale su dove siamo con gli agenti AI:

alcuni non li chiamano agenti, ma "agenti di flusso di lavoro" con flussi deterministici sono ovunque e funzionano. chiunque può costruire semplici agenti di flusso di lavoro, anche partendo da strumenti senza codice come Zapier e n8n. gli agenti di flusso di lavoro complessi richiedono molto più pensiero per essere costruiti in modo affidabile ed efficiente. un flusso di lavoro complesso per un caso d'uso comune e prezioso, con integrazioni pertinenti incorporate, può esistere autonomamente come un'attività, e anche come una grande strategia di go-to-market per espandersi successivamente in altri flussi di lavoro o in un lavoro più autonomo.

agenti più dinamici/autonomi stanno iniziando a lavorare e sono utili per la ricerca (soprattutto se basati sul web) e la programmazione. meno affidabili una volta che inizi ad aggiungere più fonti di dati (ad es. API). gli agenti in sola lettura sembrano sicuri e facili da testare, ma lasciare che gli agenti autonomi agiscano (scrivano) è spaventoso. (idea casuale su questo: sarebbe interessante se strumenti come un CRM ti permettessero di "forkare" un mirror di sviluppo e eseguire esperimenti di automazione che puoi ripristinare o reintegrare.)

gli agenti dinamici funzionano bene quando possono (1) creare e monitorare un buon piano e (2) eseguire correttamente i compiti, mentre (3) trovano il contesto giusto da inserire in ogni fase (sia nella pianificazione che in ogni compito). infine, devono (4) riflettere lungo il percorso (con o senza input umano) in modo da poter adattare il piano in modo appropriato e migliorare anche il modo in cui eseguono compiti falliti o con scarse prestazioni.

pianificazione dei compiti: le capacità di ragionamento degli LLM funzionano bene per elenchi di compiti semplici che non richiedono contesto privato (come la ricerca approfondita, solo una serie di ricerche sul web mentre si riassume). Se vuoi ricercare molte entità, la ricerca approfondita non funziona altrettanto bene perché la gestione dell'elenco dei compiti è relativamente basilare. Gli strumenti AI basati su fogli di calcolo funzionano meglio per la ricerca di molte entità perché stai effettivamente delegando la gestione dei compiti al foglio di calcolo, poiché passare lunghi elenchi di compiti tra i prompt non funziona qui. La gestione dei compiti negli agenti di codifica funziona con problemi semplici, codice semplice, o quando stai partendo da zero. Una volta che entri in progetti preesistenti più complessi, diventano meno affidabili - e gli sviluppatori aumentano l'affidabilità documentando come funziona e come è organizzato il loro codice (file .md) il che consente all'agente di costruire elenchi di compiti meglio informati. Il codice complesso richiede più documenti e alla fine estrae dinamicamente solo il contesto rilevante da quei documenti. Molte persone/aziende hanno opinioni forti e non documentate sull'ordine/approccio/strumenti corretti per affrontare un progetto, e abbiamo bisogno di più approcci per documentare questo in anticipo e al volo. Un'altra ragione per cui gli agenti di codifica e di ricerca web funzionano bene è che utilizzano tutti lo stesso insieme di strumenti, quindi non c'è bisogno di "imparare" come utilizzare quegli strumenti (ne parlerò di più dopo).

esecuzione del compito: i compiti sono solitamente chiamate API (richiedono autenticazione e comprensione di come utilizzare l'API e la struttura dei dati sottostante - che può essere unica come in un CRM o un DB con tabelle/colonne personalizzate), ragionamento LLM (ad es. riassumere), una combinazione e persino agenti di flusso di lavoro*. un agente di ricerca è semplicemente ricerca web e sintesi in un ciclo. gli agenti di codifica sono CRUD sulla tua base di codice e forse ricerca web per apprendere le API. l'autenticazione e l'accesso di base all'API sembrano risolti (MCP si adatta qui), ma mi piacerebbe vedere di più riguardo al contesto specifico degli strumenti (chiedere all'utente, ma anche analizzare all'inizio della connessione, approfondire i dati esistenti per capire come viene utilizzato lo strumento, come sono strutturati i dati, quali scenari/progetti utilizziamo per lo strumento). errori/riflessione/feedback devono trasformarsi in apprendimenti organizzati che vengono reinseriti come contesto quando rilevante. gli stessi strumenti possono essere utilizzati per scopi diversi e in modi diversi tra le organizzazioni e dobbiamo catturare/documentare questo in qualche modo per eseguire bene i compiti.

contesto: immagina di essere un nuovo dipendente in un'azienda. impari molto durante l'onboarding (e più è efficace l'onboarding, più sei produttivo fin da subito), e poi c'è l'apprendimento sul lavoro che si suddivide in apprendimento dall'esperienza dell'organizzazione ("questo è come facciamo le cose") e apprendimento dalla propria esperienza - il primo è più predominante nelle grandi organizzazioni. la gestione del contesto è simile. ci sono livelli di contesto come meta (utente/azienda), specifico per progetto/dipartimento, specifico per compito, specifico per strumento, ecc. siamo evoluti da semplici prompt di sistema a strategie ibride RAG (vettore, parola chiave, grafo), ma oltre ad avere i dati/il contesto, abbiamo bisogno di indicazioni su quando e come recuperare il contesto, che vediamo nelle prime versioni di oggi - ma c'è molto margine di miglioramento. questo non è semplicemente un problema tecnico, ma anche una questione aziendale - poiché devi sostanzialmente creare un documento di onboarding che copra ogni scenario che ti aspetti. man mano che i progetti diventano più complicati, ci vuole più attenzione per potare correttamente il contesto in modo che solo le informazioni rilevanti vengano incluse nel prompt, minimizzando il contesto irrilevante.

riflessione: abbiamo strumenti di monitoraggio degli agenti che coprono i costi di LLM/api, osservazione, ma assegnare successo/fallimento è una sfida - un'area in cui gli agenti di codifica hanno un vantaggio sugli altri è un modo deterministico per notare i fallimenti (attraverso il testing del codice). per molti altri compiti agentici, stiamo ancora cercando il modo giusto per raccogliere input umani per migliorare l'output futuro. per quanto ne so, la riflessione oggi è umana nel loop, dove il feedback viene in gran parte fornito agli sviluppatori umani per migliorare l'agente, ma la chiave si sblocca quando capiamo come trasformare la riflessione in auto-miglioramento - dove l'agente trae spunti dai fallimenti nella generazione della lista di compiti e nell'esecuzione dei compiti per fare meglio la prossima volta. fondamentalmente, la riflessione deve trasformarsi in un contesto ben organizzato che può essere utilizzato nei prompt solo quando è rilevante. questo evolve in un affinamento dei pezzi dell'agente, e poi in ambienti RL agentici - sembra ancora piuttosto presto qui.

*in precedenza ho menzionato l'assegnazione di compiti agli agenti di workflow, che inizia a avere senso quando il tuo agente trarrebbe vantaggio dall'avere nessun agente di workflow come strumenti (rispetto a capire una lista di compiti nota ogni volta) o quando il tuo sistema è abbastanza complicato da far sì che agenti specializzati con contesti e strumenti specializzati performino meglio. oppure se stai sfruttando agenti costruiti da altre persone (un modello che ho iniziato a vedere qui sono gli endpoint API di linguaggio naturale per una collaborazione più semplice tra agenti).

se avessimo la qualità del modello di oggi con una finestra di contenuto infinita (senza degrado nella qualità), calcolo infinito, archiviazione infinita, accesso tramite browser e un metodo di pagamento, un singolo ciclo LLM è probabilmente sufficiente per fare molto il punto del punto inutile sopra (niente è infinito) è che l'orchestrazione degli agenti riguarda principalmente la gestione delle limitazioni architettando modi per scaricare il lavoro dall'LLM attraverso struttura e codice.

Gli agenti in produzione si presentano in varie forme: come strumenti interni, come prodotto autonomo che combina vari strumenti e integrati come funzionalità in uno strumento principale. Possono essere generici o specializzati. Gli agenti di chat, voce e di sfondo sembrano essere le interfacce UI più comuni per attivare flussi agentici.

cosa mi manca ancora?