Sono scappato dalla trappola del nuovo e brillante framework Agent

Va bene, gente, Leo Grant qui, di nuovo con un’altra esplorazione approfondita del mondo selvaggio dello sviluppo degli agenti. Oggi voglio parlare di qualcosa che mi ha assillato, qualcosa che ho visto saltare fuori in forum dopo forum, e sinceramente, qualcosa con cui ho lottato anch’io solo pochi mesi fa: La trappola del “Shiny New Agent Framework”. Ci siamo capiti, giusto?

È il 2026 e sembra che un nuovo SDK per agenti o framework compaia 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 misto di eccitazione e paura di perdere un’opportunità. “È questo quello giusto? È questo lo strumento che finalmente rende il mio progetto personale una realtà senza settimane di codice standard?”

Ricordo che lo scorso ottobre stavo lavorando su un agente assistente finanziario personale. L’idea era semplice: un agente che potesse monitorare le mie spese, identificare servizi in abbonamento che potrei non usare, e persino negoziare migliori tariffe per conto mio. Avevo uno script Python di base 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 vantava un’incredibile concorrenza e un linguaggio di definizione degli agenti dichiarativo. Il mio cervello rettiliano ha immediatamente urlato: “Riscrivilo! Rust è il futuro! La mia confusione in Python è imbarazzante!” Così, ho passato due settimane a trasferire l’intero progetto su Aether. E indovinate un po’? Anche se Aether era davvero performante ed elegante, ho finito con un progetto 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 di Aether.

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

Il Problema Centrale: Over-Engineering della Comunicazione

La maggior parte dei framework per agenti, nel loro cuore, cerca di risolvere due problemi principali:

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

E questi sono problemi critici, senza dubbio. Ma spesso, i framework forniscono una soluzione così completa 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” (un’API di banca fittizia) e il suo stato interno. Un bus di messaggi complesso con instradamento complicato era come usare un razzo per schiacciare una mosca.

Allora, cosa succede se semplifichiamo? Cosa succede se pensiamo al minimo assoluto di cui hai bisogno per permettere agli agenti di comunicare e ricordare cose? Non si tratta 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 sovraccarico.

Messaggistica Semplice: La Base HTTP/JSON

Siamo brutaliamente onesti: per un vasto numero di casi d’uso degli agenti, soprattutto 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 stanno principalmente inviando richieste e ricevendo 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 reale
 print(f"Dati grezzi ricevuti per l'elaborazione: {payload.raw_data[:50]}...")
 processed_result = f"Elaborato: {payload.raw_data.upper()}" # Elaborazione esempio
 return {"status": "success", "processed_data": processed_result}

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

Questo è semplice, lo so. Ma è anche incredibilmente potente. Hai due agenti, che funzionano 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 indipendentemente, distribuirli ovunque e fare debug con strumenti HTTP standard. Questo approccio copre una sorprendente quantità di esigenze di comunicazione tra agenti senza alcun lock-in ai framework.

Gestione dello Stato: Abbracciare la Persistenza

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

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 mie tentativi di negoziazione storici

Inizialmente, ho provato a utilizzare alcune meccaniche di stato in memoria fornite da un framework, ma non appena l’agente si è riavviato (cosa che succede durante lo sviluppo, credimi), tutti quei dati preziosi erano spariti. Frustrante!

La soluzione? Un semplice database. Per molti progetti personali o anche per sistemi di produzione più piccoli, SQLite è un’ottima scelta. È basato su file, non richiede un server separato e Python ha un eccellente 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 un'abbonamento
 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 un abbonamento
 netflix_sub = state.get('subscription:netflix')
 print(f"Abbonamento Netflix: {netflix_sub}")

 # Aggiorna un abbonamento
 if netflix_sub:
 netflix_sub['cost'] = 16.99 # Aumento del prezzo!
 state.set('subscription:netflix', netflix_sub)
 
 print(f"Abbonamento Netflix aggiornato: {state.get('subscription:netflix')}")

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

 state.close()

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

Mettere Insieme: L’Agente “Bare Bones”

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

1. Può ricevere comandi (ad esempio, tramite endpoint HTTP o una semplice coda di messaggi).
2. Può compiere azioni (ad esempio, fare richieste HTTP, eseguire script locali).
3. Può ricordare cose (ad esempio, utilizzando uno store di stato persistente come SQLite).
4. Ha un ciclo principale o un pianificatore 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 lavoro ridondante 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 # Assuming agent_state.py is in the same directory

# Utilizzeremo FastAPI per ricevere comandi per avviare 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 il vero scraping e inviare il risultato."""
 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"Saltando {url}, recentemente scrappato 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 globalmente

@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 compito programmato qui che interroga lo stato per URL da scrappare
 # 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 il risultato di ogni scraping. È ancora semplice, ma inizia a mostrare un 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. Al contrario. Hanno sicuramente il loro posto. Dovresti iniziare a considerarli quando:

• Coordinazione complessa: Hai dozzine o centinaia di agenti che devono coordinare compiti complessi, formare team o scoprire dinamicamente gli uni gli altri. Qui, un solido bus di messaggi, 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.
• Necessità di scalabilità: Stai trattando con un throughput di messaggi molto elevato o un numero elevato di agenti concorrenti, e hai bisogno di protocolli di comunicazione altamente ottimizzati o gestione dello stato distribuita "out of the box".
• Comunità e ecosistema: Vuoi utilizzare una grande comunità, plugin esistenti e pattern collaudati per architetture di agenti specifiche (ad es. agenti conformi a FIPA).

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

Indicazioni pratiche

La mia speranza per te oggi è che tu ti allontani con un rinnovato senso di abilitazione e uno sguardo critico verso il prossimo annuncio "rivoluzionario" di un SDK per agenti. Ecco cosa voglio che tu ricordi:

1. Inizia semplice: Prima di tuffarti in un framework complesso, delinea le necessità di comunicazione e stato assolutamente minime per il tuo agente. Puoi risolvere l'80% con HTTP/JSON e un semplice database come SQLite? Probabilmente.
2. Comprendere i primitivi: Anche se alla fine utilizzerai 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 incontri un vero ostacolo di scalabilità 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 vero valore del tuo agente è nella sua capacità di prendere decisioni, nel suo ragionamento e nei compiti unici che esegue. Non lasciare che le preoccupazioni infrastrutturali oscurino lo sviluppo di quella logica fondamentale.
5. Scegli gli strumenti saggiamente: Solo perché esiste un framework non significa che sia lo strumento giusto per il tuo lavoro specifico. Valuta i suoi costi rispetto ai benefici.

La prossima volta che inizierai un progetto per agenti, prova a costruire tu stesso la comunicazione core e la gestione dello stato, anche 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 avere paura di sporcarti le mani con i fondamenti. Leo out.

🕒 Published: April 3, 2026