In questo articolo Indice dei contenuti 3 sezioni
La collaborazione tra gli agenti AI non è una proprietà che compare da sola quando si mettono insieme tre o quattro agenti dentro lo stesso progetto. Va costruita, pezzo per pezzo, decidendo chi fa cosa e soprattutto come le informazioni passano da un componente all’altro. Dopo aver visto come progettare un sistema di agenti con CrewAI, definendo ruoli specializzati, task e workflow sequenziali, il passo successivo riguarda proprio questo: collegare i pezzi e far girare il modello linguistico in locale con Ollama.
Ollama come motore locale della crew
L’obiettivo dichiarato è costruire sistemi eseguibili sulla propria macchina, senza dipendere da servizi esterni. A seconda della versione di CrewAI e del metodo di integrazione, il modello Ollama si configura come LLM locale e si assegna agli agenti. Un esempio concettuale:
from crewai import Agent, LLM
llm = LLM(model=”ollama/llama3.2″, baseurl=”http://localhost:11434″)
researcher = Agent(role=”Ricercatore tecnico”, goal=”Raccogliere informazioni sull’argomento richiesto”, backstory=”Siamo esperti di ricerca tecnica.”, llm=llm, verbose=True)
Il nome del modello deve corrispondere a quello effettivamente presente nell’installazione, e per verificarlo basta il comando ollama list dal terminale. Se in elenco compare llama3.2, quello è il valore da mettere nella configurazione. Il dettaglio interessante è che lo stesso oggetto llm può essere assegnato a più agenti contemporaneamente: un ricercatore, un analista e uno scrittore, tutti alimentati dal medesimo modello. L’architettura resta leggera, un modello locale e più agenti specializzati coordinati da una crew.
Come le informazioni passano da un task all’altro
Qui sta il cuore della faccenda. Nel workflow di esempio il ricercatore produce un rapporto, l’analista usa quel rapporto come contesto e ne ricava una rappresentazione diversa delle stesse informazioni, lo scrittore parte dall’analisi per arrivare al documento finale. Il collegamento si realizza con il parametro context, che elenca i task precedenti da cui attingere.
Il programma completo mette insieme tutto: tre agenti con ruoli e backstory distinti, tre task con description ed expectedoutput specifici, e una Crew che li orchestra con process=Process.sequential. L’avvio avviene con crew.kickoff passando gli inputs, per esempio topic impostato su “Sistemi multi agente con intelligenza artificiale”. Nel codice il researchtask viene richiamato come context dell’analysistask, e quest’ultimo diventa il contesto del writing_task.
Una catena così ordinata ha un vantaggio pratico non banale: rende il debug molto più semplice. Se il risultato finale non convince, diventa possibile chiedersi con precisione se il problema nasce nella fase di ricerca, in quella di analisi o nella scrittura, invece di osservare un blocco unico e indecifrabile.
Ruoli complementari e task scritti bene
Aumentare il numero di agenti non migliora automaticamente nulla. Se tre agenti condividono esattamente lo stesso obiettivo, cresce la complessità e il vantaggio resta zero. Meglio responsabilità complementari: in un sistema dedicato alla produzione di un report possono convivere un ricercatore che raccoglie dati, un verificatore che ne controlla la qualità, un analista che li interpreta e uno scrittore che confeziona il risultato.
Lo stesso discorso vale per la descrizione dei task. Un’istruzione come “Analizza l’argomento” lascia campo libero al modello. Una formulazione del tipo “Analizzare i dati ricevuti e identificare tre conclusioni principali, fornendo per ognuna una breve motivazione e indicando quali informazioni del rapporto la supportano” stabilisce invece cosa deve essere prodotto e in quale forma. Sembra una differenza minima, ma in un sistema multiagente l’output di un agente diventa l’input del successivo, quindi ogni ambiguità si propaga a valle.
La qualità di questa architettura, insomma, dipende dalla progettazione delle responsabilità, dalla precisione dei task e dal modo in cui le informazioni vengono trasferite tra le fasi. Su queste basi si innestano gli elementi della lezione successiva: memoria, knowledge base e strumenti, che permetteranno agli agenti di lavorare non soltanto sul prompt ricevuto ma anche su informazioni persistenti e risorse esterne o locali.
Fonte: TecnoAndroid
