analizzando il dibattito attuale "filesystem vs database" per la memoria degli agenti: attualmente vedo 2 fazioni su come costruiamo la memoria degli agenti. da un lato, abbiamo la fazione "le interfacce file sono tutto ciò di cui hai bisogno". dall'altro lato, abbiamo la fazione "i filesystem sono solo brutti database". "le interfacce file sono tutto ciò di cui hai bisogno" fazioni come anthropic, letta, langchain e llamaindex si stanno orientando verso le interfacce file perché "i file sono sorprendentemente efficaci come memoria degli agenti". • lo strumento di memoria di anthropic tratta la memoria come un insieme di file (l'implementazione dello storage è lasciata allo sviluppatore) • l'agente builder di langsmith rappresenta anche la memoria come un insieme di file (i dati sono memorizzati in un DB e i file sono esposti all'agente come un filesystem) • letta ha dimostrato che strumenti di filesystem semplici come grep e ls hanno superato strumenti di memoria o recupero specializzati nei loro benchmark • llamaindex sostiene che per molti casi d'uso un filesystem ben organizzato con ricerca semantica potrebbe essere tutto ciò di cui hai bisogno gli agenti sono bravi a usare i filesystem perché i modelli sono ottimizzati per compiti di codifica (incluso. operazioni CLI) dopo l'addestramento. è per questo che stiamo vedendo un modello di "filesystem virtuale" dove l'interfaccia dell'agente e l'implementazione dello storage sono decouple. "i filesystem sono solo brutti database" fazione ma poi ci sono voci come dax di opencode che giustamente sottolinea che "un filesystem è solo il peggior tipo di database". swyx e colleghi nel campo dei database avvertono di non reinventare accidentalmente i db risolvendo il problema della memoria degli agenti. Evita di scrivere versioni peggiori di: • indici di ricerca, • log delle transazioni, • meccanismi di locking, ...