Ho sfuggito alla trappola del nuovo framework di agenti brillanti

D’accord, amici, Leo Grant qui, di nuovo con un’altra esplorazione approfondita del mondo selvaggio dello sviluppo di agenti. Oggi voglio parlarvi di qualcosa che mi inquieta, qualcosa che ho visto apparire in forum dopo forum, e onestamente, qualcosa con cui ho avuto difficoltà io stesso solo pochi mesi fa: La trappola del “Nuovo Quadro di Agente Brillante”. Ci siamo stati tutti, vero?

È il 2026, e sembra che un nuovo SDK o quadro di agenti appaia ogni settimana. Ognuno di essi promette di essere più veloce, più intelligente, più scalabile, o semplicemente più facile per creare agenti autonomi. E come persona che vive e respira questo campo, la mia reazione iniziale è sempre un mix di eccitazione e FOMO. “È questo? È lo strumento che finalmente rende il mio progetto del cuore una realtà senza settimane di codice boilerplate?”

Ricordo che in ottobre stavo lavorando su un agente di assistente finanziario personale. L’idea era semplice: un agente capace di monitorare le mie spese, di identificare i servizi in abbonamento che potrei non utilizzare, e persino di negoziare tariffe migliori a mio nome. Avevo uno script Python di base in esecuzione, usando un bus di messaggi personalizzato e molti `if/else`. Era goffo, è sicuro, ma funzionava.

Poi ho visto l’annuncio per “Aether”, un nuovo quadro di agenti basato su Rust che vantava un’incredibile velocità e un linguaggio di definizione di agenti dichiarativo. Il mio cervello rettiliano ha immediatamente urlato: “Riscrivilo! Rust è il futuro! Il mio casino Python è una vergogna!” Così, ho passato due belle settimane a portare tutto il mio progetto su Aether. E indovinate un po’? Anche se Aether è in effetti performante ed elegante, mi sono ritrovato con un progetto che era funzionalmente identico alla mia versione Python, ma ora dovevo imparare tutto un nuovo ecosistema di strumenti di costruzione, gestione delle dipendenze e gestione degli errori specifici di Aether.

È stata una lezione preziosa, e voglio condividerla con voi oggi. Il più grande ostacolo nello sviluppo di agenti non è sempre trovare il quadro “migliore”; è comprendere quando usare un quadro, e ancora più importante, quando è meglio attenersi a ciò che già si conosce e costruire da principi di base. Oggi parleremo di adottare la mentalità del “build”, specificamente in relazione alla comunicazione e alla gestione dello stato di base dei vostri agenti, piuttosto che appropriarsi ciecamente dell’ultimo SDK.

Il Problema Principale : Sovra-ingegnerizzazione della Comunicazione

La maggior parte dei quadri di agenti, in fondo, cerca di risolvere due problemi principali:

1. Comunicazione Inter-Agente: Come comunicano gli agenti tra loro? 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 quadri offrono una soluzione così complessa e opinata da diventare esagerata per progetti più semplici o introdurre complessità inutile. Il mio agente finanziario, per esempio, aveva bisogno solamente di comunicare con un altro “agente” (una API bancaria fittizia) e il suo stato interno. Un bus di messaggi completo con un instradamento complesso era come usare un lanciagranate per schiacciare una mosca.

E se semplifichiamo? E se riflettiamo al minimo indispensabile di cui avete bisogno per far comunicare gli agenti e ricordare le cose? Non si tratta di rinunciare ai quadri per sempre, ma di costruire una base solida prima di comprendere i meccanismi sottostanti, e poi decidere se un quadro aggiunge davvero valore piuttosto che semplicemente carichi aggiuntivi.

Messaging Semplice : La Baseline HTTP/JSON

Siamo brutalmente onesti: per un gran numero di casi d’uso di agenti, in particolare 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 avete bisogno di un protocollo personalizzato o di un broker di messaggi complesso se i vostri agenti inviano principalmente richieste e ricevono risposte.

Consideriamo uno scenario in cui avete un “Agente Scraper” che recupera 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() # Provoca 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" # Sostituire 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, eseguireste un trattamento reale qui
 print(f"Dati grezzi ricevuti per trattamento: {payload.raw_data[:50]}...")
 processed_result = f"Trattato: {payload.raw_data.upper()}" # Esempio di trattamento
 return {"status": "success", "processed_data": processed_result}

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

È basico, lo so. Ma è anche incredibilmente potente. Avete due agenti, che funzionano come servizi separati, che comunicano tra loro. Niente SDK speciale, nessun formato di messaggio personalizzato. Solo pratiche web standard. La bellezza qui è che potete scalare in modo indipendente, distribuirli ovunque e debuggare con strumenti HTTP standard. Questo approccio copre un sorprendente numero di esigenze di comunicazione tra agenti senza alcuna dipendenza da un quadro.

Gestione dello Stato: Abbracciare la Persistenza

Il secondo grande punto è lo stato. Un agente non è davvero un agente se dimentica tutto tra le esecuzioni. Molti quadri offrono uno stato in memoria o macchine a stati complesse. Ma spesso, ciò di cui avete davvero bisogno è una persistenza semplice e affidabile.

Per il mio agente finanziario, dovevo memorizzare elementi come:

• I miei abbonamenti attuali (nome, costo, data di rinnovo)
• Le mie categorie di spesa
• Le tentativi di negoziazione storici

All’inizio, ho provato a utilizzare alcuni meccanismi di stato in memoria offerti da un quadro, ma non appena l’agente è stato riavviato (cosa che succede durante lo sviluppo, credetemi), tutti quei preziosi dati erano scomparsi. Frustrante!

La soluzione? Un semplice database. Per molti progetti personali o anche sistemi di produzione più piccoli, SQLite è un’ottima scelta. È basato su un 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()

 # Memorizzare 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'})

 # Recuperare un abbonamento
 netflix_sub = state.get('subscription:netflix')
 print(f"Abbonamento Netflix: {netflix_sub}")

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

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

 state.close()

Questa classe `AgentState` è molto semplice, ma fornisce un archivio di coppie chiave-valore che persiste tra i riavvii dell’agente. Puoi memorizzare dizionari, liste, stringhe – tutto ciò che può essere serializzato in JSON. Per relazioni più complesse, dovresti definire ulteriori tabelle, ma per molti agenti, un semplice archivio chiave-valore è tutto ciò di cui hai bisogno per la loro “memoria”.

Mettere Tutto Insieme: L’Agente “Semplice”

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

1. Può ricevere comandi (ad esempio, attraverso un endpoint HTTP o una semplice coda di messaggi).
2. Può eseguire azioni (ad esempio, effettuare richieste HTTP, eseguire script locali).
3. Può ricordare le cose (ad esempio, utilizzando un archivio 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 gli URL che ha già scaricato e quando, per evitare di fare lavoro ridondante o riprovare tentativi falliti.

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

# Useremo FastAPI per ricevere comandi di avvio dello 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 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'])
 # Non scaricare di nuovo se è trascorsa meno di un'ora (esempio)
 if datetime.now() - last_scrape_time < timedelta(hours=1):
 print(f"Saltando {url}, recentemente scaricato a {last_scrape_time}")
 return

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

 # Invio 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 di {url} inviati al processore: {processor_response.json()}")

 # Aggiornare lo stato con uno 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}")
 # Aggiornare lo stato con un 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 viene gestita globalmente

@app.post("/scrape")
async def start_scrape(request: ScrapeRequest, background_tasks: BackgroundTasks):
 """Endpoint per avviare 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à pianificata 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. Impedisce lo scraping ridondante in una finestra temporale definita e memorizza il risultato di ogni scraping. È ancora semplice, ma inizia a mostrare un comportamento "agente" – ricordare, decidere e agire in base al proprio stato interno e agli stimoli esterni.

Quando Considerare un Framework (e perché)

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

• Coordinazione complessa: Hai decine o centinaia di agenti che devono coordinare compiti complessi, formare squadre o scoprire dinamicamente l'uno tramite l'altro. Qui, un solido bus di messaggi, la scoperta di servizi e potenzialmente uno strato di orchestrazione degli agenti diventano inestimabili.
• Comportamenti standardizzati: I tuoi agenti devono implementare comportamenti comuni come pianificazione, definizione di obiettivi o comprensione avanzata del linguaggio naturale. I framework forniscono spesso astrazioni o integrazioni per questo.
• Bisogni di scalabilità: Stai trattando un elevato throughput di messaggi o un gran numero di agenti concorrenti, e hai bisogno di protocolli di comunicazione altamente ottimizzati o di una gestione dello stato distribuita pronta all'uso.
• Comunità e ecosistema: Vuoi utilizzare una grande comunità, plugin esistenti e modelli collaudati per architetture di agenti specifici (ad esempio, agenti conformi alla norma FIPA).

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

Punti Chiave

La mia speranza per te oggi è che tu possa partire con un nuovo senso di autonomia e una visione critica sulla prossima annuncio del SDK di agenti "rivoluzionario". Ecco cosa voglio che tu ricordi:

1. Inizia semplice: Prima di immergerti in un framework complesso, definisci i bisogni di comunicazione e stato assoluti per il tuo agente. Puoi risolvere l'80% di questo con HTTP/JSON e un database semplice come SQLite? Probabilmente.
2. Comprendi le primitive: Anche se alla fine utilizzi un framework, dedica un po' di tempo a comprendere come funziona il passaggio di messaggi e la persistenza dello stato a un livello fondamentale. Questa conoscenza ti renderà un migliore debugger e architetto.
3. Itera, non riscrivere: Costruisci prima la funzionalità del tuo agente. Fai funzionare tutto. Se incontri un vero muro di scalabilità o complessità che un framework risolve in modo evidente, allora considera di adottarlo. Evita l'impulso di "riscrivere tutto".
4. Concentrati sulla logica dell'agente: Il vero valore del tuo agente risiede nella sua capacità di prendere decisioni, ragionare e svolgere compiti unici. Non lasciare che le preoccupazioni infrastrutturali oscurino lo sviluppo di questa logica di base.
5. Scegli gli strumenti con cura: Non è perché esiste un framework che sia lo strumento giusto per il tuo compito specifico. Valuta i suoi costi rispetto ai benefici.

La prossima volta che inizierai un progetto di agente, prova a sviluppare tu stesso la comunicazione di base e la gestione dello stato, anche solo per un proof of concept. Imparerai molto, costruirai un agente più resiliente e probabilmente eviterai molti mal di testa in seguito. Continua a costruire, continua a sperimentare e non aver paura di sporcarti le mani con le basi. Leo out.

🕒 Published: April 3, 2026