digerindo o atual debate "sistema de arquivos vs banco de dados" para memória de agente: atualmente, estou vendo 2 grupos em como construímos a memória do agente. de um lado, temos o grupo "interfaces de arquivo são tudo o que você precisa". do outro lado, temos o grupo "sistemas de arquivos são apenas bancos de dados ruins". "interfaces de arquivo são tudo o que você precisa" grupo líderes como anthropic, letta, langchain e llamaindex estão inclinando-se para interfaces de arquivo porque "arquivos são surpreendentemente eficazes como memória de agente". • a ferramenta de memória da anthropic trata a memória como um conjunto de arquivos (a implementação de armazenamento fica a cargo do desenvolvedor) • o construtor de agentes da langsmith também representa a memória como um conjunto de arquivos (os dados são armazenados em um banco de dados e os arquivos são expostos ao agente como um sistema de arquivos) • letta que ferramentas simples de sistema de arquivos como grep e ls superaram ferramentas especializadas de memória ou recuperação em seus benchmarks • a llamaindex argumenta que para muitos casos de uso, um sistema de arquivos bem organizado com busca semântica pode ser tudo o que você precisa os agentes são bons em usar sistemas de arquivos porque os modelos são otimizados para tarefas de codificação (incluindo operações de CLI) após o treinamento. é por isso que estamos vendo um padrão de "sistema de arquivos virtual" onde a interface do agente e a implementação de armazenamento estão desacopladas. "sistemas de arquivos são apenas bancos de dados ruins" grupo mas então você tem vozes como dax da opencode que corretamente aponta que "um sistema de arquivos é apenas o pior tipo de banco de dados". swyx e colegas no espaço de banco de dados alertam sobre reinventar acidentalmente bancos de dados ao resolver o problema da memória do agente. Evite escrever versões piores de: • índices de busca, • logs de transação, • mecanismos de bloqueio, compromissos...