Sono scappato dalla trappola del nuovo framework Agente Lucido

Bene, ragazzi, Leo Grant qui, di nuovo con una profonda esplorazione del mondo selvaggio dello sviluppo di agenti. Oggi voglio parlare di qualcosa che mi ha perseguitato, qualcosa che ho visto ripetersi in forum dopo forum e, onestamente, qualcosa con cui ho lottato anch’io solo pochi mesi fa: La trappola del “Shiny New Agent Framework”. Ci siamo passati tutti, giusto?

È il 2026 e sembra che un nuovo SDK o framework per agenti emerga ogni due settimane. Ognuno promette di essere più veloce, più intelligente, più scalabile, o semplicemente più facile per costruire agenti autonomi. E come qualcuno che vive e respira queste cose, la mia reazione iniziale è sempre un mix di eccitazione e FOMO. “È questo il giusto? È questo lo strumento che finalmente realizza il mio progetto senza settimane di codice ripetitivo?”

Ricordo che a ottobre stavo lavorando a un agente assistente finanziario personale. L’idea era semplice: un agente che potesse monitorare le mie spese, identificare i servizi in abbonamento che potrei non utilizzare e persino negoziare tassi migliori per mio conto. Avevo un semplice script Python in esecuzione, utilizzando un bus di messaggi personalizzato e molti `if/else`. Era ingombrante, certo, ma funzionava.

Poi ho visto l’annuncio per “Aether,” un nuovo framework per agenti basato su Rust che vanta una straordinaria concorrenza e un linguaggio di definizione degli agenti dichiarativo. Il mio cervello rettiliano ha urlato immediatamente: “Rifallo! Rust è il futuro! Il mio disastro in Python è imbarazzante!” Così, ho speso due ottime settimane a portare l’intero progetto su Aether. E indovina un po’? Sebbene Aether fosse effettivamente performante ed elegante, ho finito con un progetto che era funzionalmente identico alla mia versione Python, ma ora dovevo imparare un intero nuovo ecosistema di strumenti di build, gestione delle dipendenze e gestione degli errori specifici per Aether.

È stata una lezione preziosa, e una che voglio condividere con voi oggi. Il principale ostacolo nello sviluppo degli agenti non è sempre trovare il framework “migliore”; è capire quando utilizzare un framework, e, cosa più importante, quando è meglio attenersi a ciò che si conosce e costruire dai principi fondamentali. Oggi parleremo di abbracciare la mentalità del “costruire”, specificamente quando si tratta della comunicazione fondamentale e della gestione dello stato dei vostri agenti, piuttosto che adottare ciecamente l’ultimo SDK.

Il Problema Principale: Sovra-Progettazione della Comunicazione

La maggior parte dei framework per agenti, alla base, cerca di risolvere due problemi principali:

1. Comunicazione Inter-Agente: Come comunicano tra loro gli agenti? Code di messaggi, RPC, stato condiviso?
2. Gestione dello Stato dell’Agente: Come tiene traccia un agente di ciò che sa, di ciò che ha fatto e di ciò che deve fare dopo?

Questi sono problemi critici, senza dubbio. Ma spesso, i framework forniscono una soluzione così approfondita e opinata che diventa eccessiva per progetti più semplici o introduce complessità non necessaria. Il mio agente finanziario, ad esempio, aveva bisogno di comunicare solo con un altro “agente” (una simulazione di API bancaria) e il proprio stato interno. Un bus di messaggi completo con routing complesso era come usare un lanciarazzi per schiacciare una mosca.

Quindi, e se lo semplificassimo? E se pensassimo al minimo assoluto necessario per far comunicare gli agenti e ricordare le cose? Non stiamo parlando di rifiutare i framework per sempre, ma di costruire prima una base solida, comprendere le meccaniche sottostanti e poi decidere se un framework aggiunge veramente valore piuttosto che solo carico.

Messaggistica Semplice: La Base HTTP/JSON

Essere brutalmente onesti: per un vasto numero di casi d’uso degli agenti, specialmente quelli che interagiscono con servizi web o altri sistemi esterni, HTTP e JSON sono i vostri migliori amici. Sono onnipresenti, ben compresi e incredibilmente flessibili. Non hai bisogno di un protocollo personalizzato o di un broker di messaggi complesso se i tuoi agenti inviano principalmente richieste e ricevono risposte.

Considera uno scenario in cui hai un “Agente Scraper” che estrae dati da un sito web e un “Agente Processore” che li pulisce e li analizza. Come comunicano?

# scraper_agent.py (semplificato)
import requests
import json

def scrape_data(url):
 response = requests.get(url)
 if response.status_code == 200:
 return response.text
 return None

def send_to_processor(data):
 headers = {'Content-Type': 'application/json'}
 payload = {'raw_data': data}
 try:
 response = requests.post('http://localhost:8001/process', headers=headers, data=json.dumps(payload))
 response.raise_for_status() # Solleva un'eccezione per errori HTTP
 print(f"Dati inviati al processore: {response.json()}")
 except requests.exceptions.RequestException as e:
 print(f"Errore nell'invio dei dati al processore: {e}")

if __name__ == "__main__":
 url_to_scrape = "https://example.com/some_data" # Sostituisci con un URL reale
 raw_content = scrape_data(url_to_scrape)
 if raw_content:
 send_to_processor(raw_content)

# processor_agent.py (semplificato usando FastAPI)
from fastapi import FastAPI, Request
from pydantic import BaseModel
import uvicorn

app = FastAPI()

class DataPayload(BaseModel):
 raw_data: str

@app.post("/process")
async def process_data(payload: DataPayload):
 # In uno scenario reale, qui faresti un'elaborazione effettiva
 print(f"Dati grezzi ricevuti per l'elaborazione: {payload.raw_data[:50]}...")
 processed_result = f"Elaborato: {payload.raw_data.upper()}" # Elaborazione di esempio
 return {"status": "success", "processed_data": processed_result}

if __name__ == "__main__":
 uvicorn.run(app, host="0.0.0.0", port=8001)

Questo è basilare, lo so. Ma è anche incredibilmente potente. Hai due agenti, in esecuzione come servizi separati, che comunicano tra loro. Nessun SDK speciale, nessun formato di messaggio personalizzato. Solo pratiche web standard. La bellezza qui è che puoi scalare questi servizi in modo indipendente, distribuirli ovunque e debuggarli con strumenti HTTP standard. Questo approccio copre una sorprendente quantità di necessità di comunicazione tra agenti senza alcun vincolo di framework.

Gestione dello Stato: Abbracciare la Persistenza

Il secondo grande pezzo è lo stato. Un agente non è molto un agente se dimentica tutto tra un’esecuzione e l’altra. Molti framework offrono stato in memoria o macchine di stato complesse. Ma spesso, ciò di cui hai realmente bisogno è una persistenza semplice e affidabile.

Per il mio agente finanziario, avevo bisogno di memorizzare cose come:

• Le mie attuali sottoscrizioni (nome, costo, data di rinnovo)
• Le mie categorie di spesa
• Le storiche tentativi di negoziazione

Inizialmente, ho provato a utilizzare alcuni meccanismi di stato in memoria forniti da un framework, ma non appena l’agente è stato riavviato (il che accade durante lo sviluppo, credetemi), tutti quei dati preziosi erano scomparsi. Frustrante!

La soluzione? Un semplice database. Per molti progetti personali o persino sistemi di produzione più piccoli, SQLite è una scelta fantastica. È basato su file, non richiede un server separato e Python ha un ottimo supporto integrato.

# agent_state.py
import sqlite3
import json

class AgentState:
 def __init__(self, db_path='agent_data.db'):
 self.conn = sqlite3.connect(db_path)
 self._create_table()

 def _create_table(self):
 cursor = self.conn.cursor()
 cursor.execute('''
 CREATE TABLE IF NOT EXISTS agent_knowledge (
 key TEXT PRIMARY KEY,
 value TEXT
 )
 ''')
 self.conn.commit()

 def set(self, key, data):
 cursor = self.conn.cursor()
 value = json.dumps(data) # Memorizza oggetti complessi come stringhe JSON
 cursor.execute('INSERT OR REPLACE INTO agent_knowledge (key, value) VALUES (?, ?)', (key, value))
 self.conn.commit()

 def get(self, key):
 cursor = self.conn.cursor()
 cursor.execute('SELECT value FROM agent_knowledge WHERE key = ?', (key,))
 row = cursor.fetchone()
 if row:
 return json.loads(row[0])
 return None

 def close(self):
 self.conn.close()

# Esempio di utilizzo:
if __name__ == "__main__":
 state = AgentState()

 # Memorizza una sottoscrizione
 state.set('subscription:netflix', {'name': 'Netflix', 'cost': 15.99, 'renewal': '2026-04-01'})
 state.set('subscription:spotify', {'name': 'Spotify', 'cost': 10.99, 'renewal': '2026-03-25'})

 # Ottieni una sottoscrizione
 netflix_sub = state.get('subscription:netflix')
 print(f"Sottoscrizione Netflix: {netflix_sub}")

 # Aggiorna una sottoscrizione
 if netflix_sub:
 netflix_sub['cost'] = 16.99 # Aumento di prezzo!
 state.set('subscription:netflix', netflix_sub)
 
 print(f"Sottoscrizione Netflix aggiornata: {state.get('subscription:netflix')}")

 # Memorizza un elenco di categorie di spesa
 state.set('spending_categories', ['generi alimentari', 'intrattenimento', 'utenze'])
 print(f"Categorie di spesa: {state.get('spending_categories')}")

 state.close()

Questo `AgentState` è super basilare, ma fornisce uno store chiave-valore che persiste tra i riavvii degli agenti. Puoi memorizzare dizionari, liste, stringhe – tutto ciò che può essere serializzato in JSON. Per relazioni più complesse, definiresti più tabelle, ma per molti agenti, un semplice store chiave-valore è tutto ciò di cui hai bisogno per la loro “memoria.”

Mettere tutto insieme: L’Agente “Essenziale”

Quindi, se combiniamo queste idee, come appare un agente “essenziale”? È un processo che:

1. Può ricevere comandi (ad es., tramite endpoint HTTP o una semplice coda di messaggi).
2. Può eseguire azioni (ad es., effettuare richieste HTTP, eseguire script locali).
3. Può ricordare le cose (ad es., utilizzando uno store di stato persistente come SQLite).
4. Ha un ciclo principale o uno scheduler per decidere cosa fare dopo.

Immaginiamo il nostro Agente Scraper di prima, ma ora con un po’ di memoria. Deve ricordare quali URL ha già estratto e quando, per evitare lavori ridondanti o per riprovare tentativi falliti.

# smart_scraper_agent.py
import requests
import json
import time
from datetime import datetime, timedelta
from agent_state import AgentState # Presupponendo che agent_state.py sia nella stessa directory

# Useremo FastAPI per ricevere comandi per iniziare lo scraping
from fastapi import FastAPI, BackgroundTasks
from pydantic import BaseModel
import uvicorn

app = FastAPI()
agent_state = AgentState(db_path='scraper_agent_data.db')

class ScrapeRequest(BaseModel):
 url: str
 target_processor_url: str

def _perform_scrape_and_send(url: str, target_processor_url: str):
 """Funzione interna per eseguire realmente lo scraping e inviare."""
 last_scraped_info = agent_state.get(f'last_scraped:{url}')
 if last_scraped_info:
 last_scrape_time = datetime.fromisoformat(last_scraped_info['timestamp'])
 # Esegui lo scraping solo se è passato più di un'ora (esempio)
 if datetime.now() - last_scrape_time < timedelta(hours=1):
 print(f"Salto {url}, recentemente scaricato a {last_scrape_time}")
 return

 print(f"Scraping di {url}...")
 try:
 response = requests.get(url, timeout=10)
 response.raise_for_status()
 raw_content = response.text

 # Invia al processore
 headers = {'Content-Type': 'application/json'}
 payload = {'raw_data': raw_content}
 processor_response = requests.post(target_processor_url, headers=headers, data=json.dumps(payload))
 processor_response.raise_for_status()
 print(f"Dati da {url} inviati al processore: {processor_response.json()}")

 # Aggiorna lo stato con lo scraping riuscito
 agent_state.set(f'last_scraped:{url}', {
 'timestamp': datetime.now().isoformat(),
 'status': 'success',
 'processor_response': processor_response.json()
 })

 except requests.exceptions.RequestException as e:
 print(f"Errore durante lo scraping o l'invio per {url}: {e}")
 # Aggiorna lo stato con il fallimento
 agent_state.set(f'last_scraped:{url}', {
 'timestamp': datetime.now().isoformat(),
 'status': 'failed',
 'error': str(e)
 })
 finally:
 agent_state.close() # Importante chiudere la connessione se non gestita a livello globale

@app.post("/scrape")
async def start_scrape(request: ScrapeRequest, background_tasks: BackgroundTasks):
 """Endpoint per attivare un'azione di scraping."""
 background_tasks.add_task(_perform_scrape_and_send, request.url, request.target_processor_url)
 return {"message": f"Scraping di {request.url} avviato."}

if __name__ == "__main__":
 # Potresti anche avere un'attività programmata qui che interroga lo stato per URL da scaricare
 # Per ora, eseguiremo semplicemente il server FastAPI.
 # Per eseguire: uvicorn smart_scraper_agent:app --reload --port 8000
 uvicorn.run(app, host="0.0.0.0", port=8000)

Questo `smart_scraper_agent.py` combina la nostra comunicazione HTTP di base con uno stato persistente. Previene scraping ridondanti all'interno di una finestra temporale definita e memorizza l'esito di ogni scraping. È ancora semplice, ma inizia a mostrare un certo comportamento "agente" – ricordando, decidendo e agendo in base al suo stato interno e agli stimoli esterni.

Quando considerare un framework (e perché)

Ora, non sto dicendo che i framework siano cattivi. Lungi da me. Hanno assolutamente il loro posto. Dovresti iniziare a considerarli quando:

• Coordinazione Complessa: Hai dozzine o centinaia di agenti che devono coordinare compiti complessi, formare team o scoprirsi dinamicamente l'uno con l'altro. Qui, un solido message bus, la scoperta dei servizi e potenzialmente uno strato di orchestrazione degli agenti diventano inestimabili.
• Comportamenti Standardizzati: I tuoi agenti devono implementare comportamenti comuni come pianificazione, definizione degli obiettivi o comprensione avanzata del linguaggio naturale. I framework spesso forniscono astrazioni o integrazioni per questi.
• Esigenze di Scalabilità: Hai a che fare con un throughput di messaggi molto alto o un numero elevato di agenti concorrenti, e hai bisogno di protocolli di comunicazione ottimizzati o gestione dello stato distribuita direttamente “out of the box”.
• Comunità & Ecosistema: Vuoi usare una grande comunità, plugin esistenti e pattern collaudati per architetture specifiche di agenti (ad esempio, agenti conformi a FIPA).

Anche in quel caso, i principi di comunicazione chiara e gestione dello stato solida di cui abbiamo discusso oggi rimangono fondamentali. Un buon framework si basa su questi, non sostituisce la necessità di comprenderli.

Pratiche Consigliate

La mia speranza per te oggi è che tu possa uscire con un rinnovato senso di capacità e uno sguardo critico per il prossimo annuncio di SDK rivoluzionario per agenti. Ecco cosa voglio che tu ricordi:

1. Inizia Semplice: Prima di tuffarti in un framework complesso, delinea le esigenze minime assolute di comunicazione e stato per il tuo agente. Puoi risolvere l'80% con HTTP/JSON e un database semplice come SQLite? Probabilmente.
2. Comprendi i Primitivi: Anche se alla fine utilizzi un framework, dedica del tempo a comprendere come funzionano il passaggio di messaggi e la persistenza dello stato a un livello fondamentale. Questa conoscenza ti renderà un miglior debugger e architetto.
3. Itera, Non Riscrivere: Costruisci prima la funzionalità del tuo agente. Fai in modo che funzioni. Se affronti un vero muro di scaling o complessità che un framework risolve in modo evidente, considera di adottarne uno. Evita l’impulso di "riscrivere tutto".
4. Concentrati sulla Logica dell'Agente: Il valore reale del tuo agente è nella sua capacità di prendere decisioni, nel suo ragionamento e nei compiti unici che svolge. Non lasciare che le preoccupazioni infrastrutturali oscurino lo sviluppo di quella logica fondamentale.
5. Scegli gli Strumenti con Criterio: Solo perché esiste un framework non significa che sia lo strumento giusto per il tuo lavoro specifico. Valuta il suo overhead rispetto ai suoi benefici.

La prossima volta che inizi un progetto di agente, prova a costruire tu stesso la comunicazione di base e la gestione dello stato, anche se è solo per un proof of concept. Imparerai molto, costruirai un agente più resiliente e probabilmente ti risparmierai molti mal di testa in seguito. Continua a costruire, continua a sperimentare e non aver paura di sporcarti le mani con i fondamenti. Leo fuori.

🕒 Published: April 3, 2026