La majoria dels equips d'IA que volen millorar el rendiment dels agents recorren a les mateixes solucions: finestres de context més grans, més documents i indicacions més intel·ligents. Aquest article sosté que aquest instint és del tot equivocat. L'ingredient que falta no és més informació. És control. Una capa de control ben dissenyada és el que separa un agent que funciona en una demostració d'un que funciona en producció.
Donar a un agent d'IA una memòria més gran, més documents o una finestra de context més llarga no el fa més intel·ligent, sinó més lent i més car. Les millores reals provenen d'ensenyar l'agent a triar què necessita i quan ho necessita, en lloc de consumir-ho tot alhora.
La fiabilitat prové del bucle, no del model. La diferència entre un agent que impressiona en una demostració i un que resisteix en producció no és la qualitat de la IA, sinó si el sistema comprova la seva pròpia feina. Els agents que planifiquen, actuen, observen i verifiquen en cada pas detecten els seus propis errors en lloc d'equivocar-se amb plena confiança.
Avui, la majoria dels agents d'IA són essencialment bots de xat amb passos addicionals: no tenen cap mecanisme per saber si van pel bon camí, quan han d'aturar-se ni quan han de provar un enfocament diferent. Afegir una capa de control adequada —criteris d'èxit clars, un estat estructurat i comprovacions de validació— és el que converteix un objecte amb aparença d'agent en una cosa en què realment pots confiar.
Què vas dinar ahir?
Probablement no vas repassar tots els records de la teva vida fins a arribar a "ahir + dinar". Vas saltar directament a la part de l'experiència on es troben aquests conceptes. És un model mental útil per crear agents:
Una finestra de context gegant no és memòria.
Un munt de documents recuperats no és comprensió.
Una cadena de pensament llarga no és fiabilitat.
Aquests són els ingredients. Però allò que fa que un agent sembli realment un agent és el mateix que evita que el cervell hagi de repassar per força bruta tota la teva vida: el control.
Un estudi recent, Agentic Reasoning for Large Language Models, va resumir (i batejar) molt bé el canvi que molts percebem mentre desenvolupem: passar del raonament dins del model al raonament mitjançant la interacció. Aquest article no és un resum d'aquell estudi. És un intent de traduir aquest canvi en un disseny pràctic de sistemes:
Si crees agents com si fossin bots de xat amb eines, continuaràs patint els errors propis dels bots de xat, però amb equivocacions més cares.
Durant un temps, la nostra recepta habitual per "fer que el model sigui més intel·ligent" consistia essencialment en millors indicacions, cadena de pensament, autoconsistència o millores basades en mostreig i, potser, una mica de cerca.
ReAct va marcar un punt d'inflexió perquè va fer que "pensament → acció → observació" semblés natural. Però fixa't en la restricció implícita: bona part d'això continua sent "inferència amb un sol exemple, però amb més tokens". El plantejament de l'estudi és més precís: el raonament agèntic posa l'accent a escalar la interacció en temps de prova, tot convertint la inferència en un procés iteratiu en què el model, la memòria i l'entorn continuen formant part del bucle.
Si has creat o utilitzat agents que impressionen en les demostracions, però són fràgils en fluxos de treball reals, això és per a tu.
Deixa'm descriure un patró que he vist sovint i del qual jo també he creat unes quantes versions:
Agafa un bon model de xat
Afegeix-hi unes quantes eines (cerca, consultes a bases de dades i, potser, execució de codi)
Afegeix-hi RAG
Afegeix-hi una indicació de sistema que digui "you are an autonomous agent"
Embolcalla-ho tot en un bucle while fins que s'aturi o s'esgoti el temps
Enhorabona, ja tens un objecte amb aparença d'agent. Però sol fallar de maneres previsibles:
Context inflat: s'hi afegeix cada observació i les indicacions es converteixen en estrats arqueològics.
Ús erràtic de les eines: "l'eina equivocada, però amb plena confiança" es converteix en el mode d'error predeterminat.
Sense condicions d'aturada: continua perquè pot, no perquè ho hagi de fer.
Sense disciplina d'ancoratge: no s'adona que s'equivoca si no l'hi obligues.
Memòria = historial del xat: que bàsicament consisteix a escriure registres i anomenar-ho aprenentatge.
Per això els "agents" sovint semblen màgics en les demostracions i caòtics en producció. La nostra experiència desplegant sistemes agèntics en producció també ho reflecteix: quan ja no avalues un model sinó un sistema, els modes d'error inclouen la navegació, l'ús rigorós de les eines, la poda del context i el disseny de l'avaluació, no només si "el model ha respost correctament".
Per tant, la pregunta és: com és l'agent concebut expressament?
Per fer-ho menys abstracte, vegem un flux de treball senzill que gairebé tothom pot imaginar: "Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat."
Una implementació habitual amb aparença d'agent funciona així:
Recupera immediatament un munt de documents sobre aerolínies i polítiques de viatge, encara que no en calgui cap.
Crida una eina de cerca, enganxa una llarga llista de resultats a la indicació i "en tria un".
Fa la reserva abans d'hora sense verificar les restriccions d'arribada, equipatge, seient o política.
Si falla, ho torna a intentar d'una manera lleugerament diferent, però sense tenir clar què ha canviat ni què ha après.
El problema no és que el model no pugui raonar, sinó que el sistema no controla el flux de treball.
Una versió més agèntica tracta la tasca com un procés interactiu amb un estat i unes comprovacions explícits:
PLANIFICAR: reformular les restriccions i enumerar la informació que falta (p. ex., "Which airport do you prefer?" o "Is one stop OK?").
ACTUAR: cridar la cerca de vols amb una consulta estructurada (interval de dates, restricció d'arribada i pressupost).
OBSERVAR: desar els resultats en un objecte d'estat compacte (els 5 millors candidats amb preu, arribada i escales), no pas en un bloc enorme de text enganxat.
ACTUALITZAR: refinar la consulta si no es compleixen les restriccions (p. ex., "Arrival before 6pm is too strict—widen time window or raise budget?").
VERIFICAR: executar validadors ("arribada < 18:00", "preu ≤ 900 £", "compleix la política" i "selecció de seient disponible").
ATURAR: només quan l'API de reserves retorni una confirmació i se superin tots els validadors.
El canvi és subtil, però decisiu. La recuperació és condicional, no un reflex; el context es gestiona, amb un estat estructurat en lloc d'acumulat; i la verificació forma part del bucle, en comptes de deixar-la en mans de l'usuari. Canvia "reservar un vol" per "crear una ordre de compra", "emetre un reemborsament", "modificar una configuració de producció" o "lliurar una PR" i la situació serà la mateixa: quan l'agent pot actuar, el bucle importa més que la indicació.
L'estudi esmentat abans organitza el raonament agèntic en tres capes: fonamental (planificació, ús d'eines i cerca), autoevolutiva (retroacció i memòria) i col·lectiva (coordinació entre diversos agents).
Però la idea de fons és que el raonament esdevé el principi organitzador de la planificació, la presa de decisions i la verificació, i no es limita a generar una cadena de pensament plausible. Sembla abstracte fins que ho trasllades als canvis que implica per a l'arquitectura. Cal recordar tres punts essencials:
Un bon agent no hauria de tractar la recuperació com una cosa que "sempre s'ha de fer". Recuperar és una decisió, no un reflex.
Una heurística pràctica:
Si el sistema recupera informació en cada torn, no has creat un sistema de recuperació, sinó un impost sobre el context.
Això passa constantment en la feina real. Quan depures un incident de producció, no aboques tots els registres al context, sinó que decideixes quines mètriques o quins registres cal recuperar a continuació segons la hipòtesi actual. Això és la "recuperació agèntica". Vegem-ne un patró més concret:
Decideix si necessites recuperar informació
Si és així: redacta una consulta, recupera, revisa per sobre i extreu
Si les proves es contradiuen: torna a recuperar informació
Només llavors, sintetitza
Aquí és també on el "RAG agèntic" comença a diferenciar-se del RAG tradicional: la recuperació esdevé un pas deliberat del raonament, no una etapa predeterminada del procés.
Quan deixes d'avaluar "un model" i comences a avaluar "un sistema", el seguiment i la traçabilitat de l'estat passen a ser importants.
A hores d'ara, el sector ja reconeix més explícitament la importància de l'observabilitat en els fluxos de treball dels agents. Per exemple, l'SDK Agents d'OpenAI inclou traçabilitat integrada i un tauler Traces que registra les execucions dels agents (generacions, crides a eines, transferències, mesures de protecció i esdeveniments personalitzats), justament perquè puguis depurar i auditar pas a pas què ha passat.
No és una cosa que "estaria bé tenir". És la diferència entre un sistema que pots depurar i un que només pots valorar per les sensacions que transmet.
Al meu parer, la part més pràctica de l'estudi és la franquesa amb què tracta la retroacció. Divideix la retroacció en tres règims: retroacció reflexiva (generar → criticar → revisar), adaptació paramètrica (aprendre mitjançant ajust fi o RL) i retroacció basada en validadors (reintentar fins que se superi una validació).
La majoria d'equips haurien de començar per la retroacció basada en validadors perquè és avorrida, però eficaç. Si pots escriure qualsevol validador que executi proves unitàries, comprovi l'esquema, estableixi regles o restriccions de negoci ("cap reemborsament superior a X sense escalat") o verifiqui la veracitat ("calen citacions"), podràs convertir la sortida no determinista del model en una cosa en què realment es pot confiar.
Un dels canvis més senzills entre els "desconeguts desconeguts" és aquest: en el món dels agents, la fiabilitat sovint prové més del bucle que del model.
Aquesta és la disciplina de bucle més senzilla que he trobat per millorar el comportament de manera fiable sense entrenament:
Treballa per passos: Planificar → Actuar → Observar → Actualitzar,
Després de cada acció, resumeix l'observació en entre 1 i 3 punts,
Atura't quan es compleixin els criteris d'èxit o s'esgoti el pressupost; retorna el millor resultat conegut i les incerteses pendents.
No es tracta de fer que el model sigui prolix. Es tracta de fer que el sistema sigui entenedor i d'obligar-lo a "tocar de peus a terra" en cada pas. Un exemple molt proper per als enginyers és l'ancoratge de bucle tancat a l'estil de la integració contínua:
Planificar: proposar una llista de canvis
Actuar: executar proves i l'anàlisi estàtica
Observar: analitzar els errors
Actualitzar: aplicar correccions i tornar-ho a provar
Algunes preguntes que solen revelar dissenys d'agents accidentals:
"El meu agent tria què ha de recuperar o sempre ho recupero jo?"
Si la recuperació és incondicional, ho pagaràs en forma de latència, cost, dilució del context i més risc que entrin dades brossa i en surtin resultats brossa.
"El meu agent pot adonar-se que s'equivoca?"
Si l'únic senyal de retroacció del teu agent és que "l'usuari s'enfada", estàs fent RL a costa del patiment humà. Un bucle de reintents basat en validadors és la manera més neta de fer-lo tocar de peus a terra.
"Es pot escriure en la memòria i millora amb el temps?"
Si la teva "memòria" només afegeix l'historial del xat, bàsicament estàs escrivint registres. La manera com l'estudi planteja la memòria és important: es converteix en un context que creix dinàmicament i que els agents perfeccionen amb el temps, no només en una transcripció.
Els registres t'expliquen què ha passat; la memòria, què cal fer la pròxima vegada. L'historial del xat és una transcripció. La memòria és una política en evolució sobre què val la pena conservar per al futur.
Una opció pràctica per començar és una petita taula de "lliçons apreses", amb una clau formada pel tipus de tasca, l'eina i el mode d'error, i un valor que indiqui què ha funcionat i què cal evitar. L'objectiu no és crear un graf de coneixement perfecte. L'objectiu és crear un efecte acumulatiu: la memòria i la retroacció converteixen els agents, que passen de ser "ajudants sense estat" a sistemes que milloren amb el temps.
La temptació és llançar més agents contra el problema, però sovint això multiplica la sobrecàrrega de coordinació. Un bon patró d'"equip mínim viable":
Coordinador: descompon i assigna
Executor: fa les crides a eines i els canvis
Crític o avaluador: comprova la correcció i el risc
Responsable de la memòria: escriu i selecciona lliçons
Si no pots explicar de què és responsable cada agent, probablement encara no en necessites més d'un.
Si realment acceptem el canvi de paradigma, probablement deixarem d'encabir-ho tot dins les indicacions, de tractar els errors com a resultats finals i d'avaluar els agents com si fossin bots de xat. I començarem a tractar els agents com el que són: sistemes de programari en què el llenguatge és el pla de control i la fiabilitat prové del bucle.
Abans d'afegir un altre model, afegeix un altre bucle d'avaluació. Abans de recuperar-ho tot, fes que la recuperació sigui condicional. Desplega un validador abans de desplegar-ne deu. Tracta la memòria com decisions de política, no com una base de dades. I quan passis a un sistema multiagent, comença amb dos agents, no amb vint. No són regles, sinó els patrons que han superat la prova de la producció.