Come ho sostituito i cicli API costosi con pipeline guidate da Lobster e gestione della memoria Honcho—e perché solo il programma di debug tocca gli endpoint a pagamento.

Tutti conosciamo il dilemma. Vuoi un'intelligenza multi-agente vera—memoria persistente, passaggio di consegne tra subagenti e pianificazione a lungo termine—ma i costi in token delle API a pagamento (soprattutto per il recupero della memoria in ciclo) possono uccidere un progetto prima del lancio.

Ho deciso di risolvere questo ricostruendo la mia configurazione OpenClaw da zero. L'obiettivo: un'architettura ibrida multi-agente/subagente con costo zero di inferenza per le operazioni di memoria e sovraccarico quasi nullo per la delega delle attività.

Ecco esattamente come l'ho fatto.

L'architettura: ibrida multi-agente + sciami di subagenti

La maggior parte delle implementazioni tratta ogni agente come un chiamante API di prima classe. Questo consuma token.

La mia configurazione OpenClaw utilizza un modello ibrido:

• Gli agenti primari (orchestratori) vengono eseguiti su endpoint di inferenza locale o di livello gratuito.
• I sottagenti sono effimeri—creati per compiti specifici (ricerca, sintesi, validazione) e distrutti immediatamente.
• Il segreto? I sottagenti non “ricordano.” Interrogano il negozio di memoria centrale, eseguono e svaniscono. Questo mantiene la finestra di contesto piccola. Solo l'agente principale mantiene lo stato della sessione.

La Regola d'Oro: Solo il Debugger parla alle API a pagamento

Ecco il vincolo che ha cambiato tutto.

Nel mio flusso di lavoro, esattamente un componente ha accesso agli endpoint delle API a pagamento: il debugger.

Ogni altro agente—principale, sottagente, orchestratore, lavoratore di memoria—esegue l'inferenza locale (Ollama, LM Studio o cloud gratuito). Solo il debugger può chiamare GPT-4, Claude o qualsiasi modello a pagamento.

Perché? Tre ragioni:

1. Disciplina architettonica imposta

Se qualcosa si rompe, il debugger lo traccia. Ma poiché il debugger è l'unico percorso a pagamento, non si può “imbrogliare” spargendo chiamate API lungo la pipeline. Si è costretti a ottimizzare l'inferenza locale e il recupero della memoria.

2. Il debugging come servizio a pagamento, non come dipendenza di runtime

Il sistema funziona il 99% del tempo senza toccare un API a pagamento. Solo quando un agente fallisce—output inatteso, disallineamento di schema, ciclo infinito—il debugger si attiva. Riceve il contesto del fallimento, suggerisce correzioni e le restituisce agli agenti locali. Questo trasforma le API a pagamento in un gestore di eccezioni, non in un supporto di runtime.

3. Il costo scala con i problemi, non con l'utilizzo

Un pipeline sano costa $0. Un pipeline buggato costa pochi centesimi per la diagnosi. Confrontalo con i sistemi multi-agente tradizionali, dove ogni turno di ogni agente costa denaro indipendentemente dalla correttezza.

Gestione della memoria Honcho: Persistente, Ricercabile, Zero-Costo

Per la memoria, ho integrato Honcho—un livello di memoria programmabile locale-first. Honcho mi offre:

• Archiviazione persistente di utente/sessione.
• Ricerca vettoriale senza database vettoriali cloud
• Zero chiamate API per la lettura/scrittura della memoria

Ogni interazione dell'agente scrive su Honcho. Ogni subagente avvia il proprio contesto leggendo da Honcho. Nessun embedding a pagamento. Nessun servizio di memoria esterno.

E poiché il debugger non tocca mai le operazioni di memoria, Honcho funziona interamente gratuitamente

Decadimento temporale + MMR: Combattere la memoria obsoleta

La memoria è inutile se sovrasta il contesto recente. Ho implementato due meccanismi di recupero dentro Honcho:

1. Decadimento temporale

I ricordi più vecchi vengono pesati in modo esponenzialmente decrescente. Un fatto di 10 minuti fa è più rilevante di un fatto simile di 10 giorni fa. Questo impedisce all'agente di agire su informazioni obsolete

2. MMR (Rilevanza Marginale Massima)

Quando l'agente esegue una query sulla memoria, MMR garantisce diversità. Evita di restituire dieci ricordi quasi identici. Invece, ottieni pertinenza e varietà—fondamentali per gli sottagenti che necessitano di un contesto ampio.

Entrambi vengono eseguiti localmente. Costo: $0. Il debugger non li vede mai.

Lobster: Delegazione di attività e pipeline senza sovraccarico

Qui l'utilizzo dei token collassa.

Ho sostituito le catene lineari di agenti con Lobster—un runtime di pipeline di attività leggero. Lobster mi permette di definire grafi aciclici diretti (DAG) di attività.

Il mio flusso di lavoro:

1. L'agente principale scompone una richiesta in sottocompiti.
2. Ogni sottocompito viene inserito in Lobster come nodo della pipeline.
3. Lobster esegue i sottocompiti in parallelo o in sequenza utilizzando subagenti locali.
4. Se un nodo fallisce o produce un output inatteso, Lobster lo segnala.
5. Solo allora il debugger si attiva — ricevendo il contesto del nodo fallito, generando una correzione e riprendendo la pipeline.

Poiché le pipeline di Lobster riutilizzano il contesto ed evitano chiamate LLM ridondanti, ho ridotto il consumo di token di circa il 70-80% su carichi di lavoro comparabili. E poiché il debugger gestisce solo le eccezioni, quella riduzione del 70-80% si applica specificamente all'uso a pagamento.

L'impatto reale sull'utilizzo dei token (API a pagamento)

Parliamo dei numeri.

Prima di questa configurazione, una conversazione tipica multi-agente: 3 agenti, ciascuno che chiama GPT-4. Il recupero della memoria viene aggiunto a ogni prompt. Risultato: 8,000–12,000 token per interazione utente.

Dopo l'accesso a pagamento solo per il debugger di OpenClaw + Honcho + Lobster: gli agenti primari vengono eseguiti localmente. Gli agenti secondari vengono eseguiti localmente. La memoria viene eseguita localmente. Lobster orchestra tutto senza chiamate API. L'utilizzo delle API a pagamento avviene solo in caso di guasto—che, dopo la stabilizzazione della pipeline, avviene in meno del 5% delle interazioni.

Risultato: 50–500 token per interazione per le API a pagamento, con la maggior parte delle interazioni che costa $0.

Si tratta di una riduzione dell'utilizzo di token a pagamento di 20-100x rispetto ai sistemi multi-agente tradizionali.

Per le applicazioni ad alto volume—supporto clienti, agenti di ricerca, automazioni—questa è la differenza tra un prodotto fattibile e un buco nero di denaro. Con 10.000 interazioni al giorno, le configurazioni tradizionali potrebbero costare tra $200 e $500. Questa configurazione costa pochi spiccioli, se non nulla.

Perché il vincolo solo per il debugger impone un'ingegneria migliore

Ecco l'intuizione controintuitiva: limitare le API a pagamento al debugger migliora l'affidabilità del sistema, non solo il costo.

Quando ogni agente può chiamare GPT-4, si tollera un prompting approssimativo, un recupero della memoria scadente e pipeline fragili. L'API a pagamento copre le crepe.

Quando solo il debugger ha quel privilegio, si è costretti a:

• Scrivi prompt locali robusti che gestiscano i casi limite.
• Costruisci un adeguato decadimento della memoria e MMR così che il recupero funzioni senza bisogno di assistenza.
• Progetta le pipeline Lobster con criteri di successo/fallimento chiari.
• Tratta i modelli a pagamento come investigatori, non come lavoratori.

Il risultato è un sistema che fallisce con eleganza, si auto‑debugga e costa quasi nulla da gestire.

Perché è importante

Non hai bisogno di memoria cloud costosa o di loop API incessanti per creare agenti intelligenti.

Con OpenClaw, Honcho e Lobster—vincolo dell'API a pagamento solo per il debugger—puoi costruire:

• Memoria persistente con decadimento temporale e MMR
• Sciami ibridi di agenti/sottagenti
• Pipelining delle attività con ripristino automatico degli errori
• Un sistema in cui le API a pagamento sono gestori di eccezioni, non dipendenze di runtime

…tutto ciò mantenendo la bolletta delle API a pagamento a distanza di sputo da zero.

Non sto facendo gatekeeping su questo. Chiedimi pure dei file di configurazione, degli schemi Honcho, delle definizioni DAG di Lobster o di come ho collegato il debugger affinché si attivi solo in caso di guasti della pipeline.

Costruiamo più economicamente. Costruiamo in modo più intelligente. Facciamo che le API a pagamento siano l'ultima risorsa, non il primo istinto.