Que é un AI agent: cinco tipos clásicos, dúas definicións rivais

O exemplo máis antigo do campo é unha aspiradora nun mundo de dous cadrados, A e B, cada un limpo ou sucio.¹ Sobrevive en todos os libros de texto porque é o mundo máis pequeno no que un agent pode acertar ou equivocarse.

O percepto é un par — onde estou, e se aquí está sucio — e as accións son SUCK, LEFT e RIGHT. Todo o programa é unha liña.

type Percept = { dirty: boolean; where?: "A" | "B" };
type Action = "SUCK" | "LEFT" | "RIGHT";

const textbook = (p: Percept): Action =>
  p.dirty ? "SUCK" : p.where === "A" ? "RIGHT" : "LEFT";   

Execútao contra todas as configuracións iniciais do mundo de dous cadrados:

A dirty, B dirty, start A    -> steps=3 clean=true
A clean, B dirty, start A    -> steps=2 clean=true
A dirty, B clean, start B    -> steps=2 clean=true

Iso é un simple reflex agent: actúa só sobre o percepto actual, sen memoria de nada anterior. Non é unha categoría de xoguete — un termóstato é un, e tamén o é unha soa chamada a un modelo de linguaxe sen conversa asociada.

Agora rómpeno como fai a realidade. Un robot aspirador real ten un sensor de sucidade e un parachoques, non un cadrado etiquetado como A debaixo da alfombra. Saca a localización do percepto e non cambies nada máis:

const dirtOnly = (p: Percept): Action => (p.dirty ? "SUCK" : "RIGHT");

A dirty, B dirty, start A    -> steps=3   clean=true   still dirty=0
      t=0 at=A percept={dirty:true}  -> SUCK
      t=1 at=A percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:true}  -> SUCK

A dirty, B clean, start B    -> steps=500 clean=false  still dirty=1
      t=0 at=B percept={dirty:false} -> RIGHT
      t=1 at=B percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:false} -> RIGHT
      t=3 at=B percept={dirty:false} -> RIGHT

O mesmo programa, dous cadrados. Desde un estado inicial remata en tres pasos; desde outro bate contra a parede da dereita cincocentas veces e seguiría ata que morrese a batería. Non pode percibir a diferenza entre as dúas situacións, así que non pode actuar de forma distinta nelas. Russell e Norvig formulan o resultado xeral nunha liña: os bucles infinitos adoitan ser inevitables para simple reflex agents en ambientes parcialmente observables.¹

Hai unha corrección que custa unha liña e nada de memoria, e paga a pena medila antes de ir buscar algo máis intelixente.

let seed = 12345;
const rnd = () => ((seed = (seed * 1103515245 + 12345) & 0x7fffffff) / 0x7fffffff);

const coin = (p: Percept): Action => (p.dirty ? "SUCK" : rnd() < 0.5 ? "LEFT" : "RIGHT");  

Dúas mil execucións dun corredor todo sucio con tres tamaños, un único xerador sementado durante todo o experimento:

A aleatorización elimina o bucle por completo. Tamén custa: oito habitacións necesitan quince movementos se sabes o que fas, e este agent fai unha media de 68,7 e unha vez tardou 306. Ese é todo o capítulo en miniatura. Cada capacidade que engadimos compra corrección nun caso que o agent anterior non podía manexar, e cobra por ela nunha moeda que primeiro tes que nomear.

Un agent percibe o seu ambiente mediante sensores e actúa mediante actuadores. O programa do agent é a función de perceptos a accións — cada listaxe anterior é unha. A secuencia de perceptos é todo o percibido ata agora, e un simple reflex agent ignora todo agás o último elemento.

Racionalidade é a palabra que a maioría dos artigos entende mal, e entendela ben fai que o resto deste capítulo sexa útil. Un agent non é racional ou irracional en si mesmo. Russell e Norvig definen un agent racional como aquel que, para cada posible secuencia de perceptos, selecciona a acción que se espera que maximice a súa medida de rendemento, dadas as probas desa secuencia e calquera coñecemento incorporado que teña.¹ A medida de rendemento non está dentro do agent: pertence ao deseñador, e a racionalidade só se define en relación con ela.

A especificación escríbese convencionalmente como catro cousas, PEAS: medida de rendemento, ambiente, actuadores, sensores.

Fíxate en que fila é a distinta. Case todos os equipos que constrúen agents en 2026 escriben E, A e S — os esquemas das ferramentas, as integracións, o formato da mensaxe — porque o código non executará sen eles. Case ninguén escribe P. Sen iso, «o noso agent vai ben» non ten ningún significado que ninguén poida comprobar, e «racional» non se pode aplicar ao sistema en absoluto, só a unha demostración. O Capítulo 29 trata de converter P nun número, e por iso existe.

    ┌───────────────────────── the environment ─────────────────────────┐
    │                                                                   │
    │   ┌──────────────────────── the agent ─────────────────────┐      │
    │   │                                                        │      │
 ───┼──►│  sensors  ──►  the agent program  ──►  actuators  ─────┼──────┼──►
percept │                                                        │    action
    │   └────────────────────────────────────────────────────────┘      │
    └───────────────────────────────────────────────────────────────────┘
                                   ▲
              the performance measure lives out here, in the head of
              whoever built the thing, and the agent cannot change it

Os ambientes de tarefa clasifícanse ademais ao longo de sete eixes, cinco dos cales deciden a maior parte da dificultade aquí: totalmente ou parcialmente observable, determinista ou non, episódico ou secuencial, estático ou dinámico, coñecido ou descoñecido.¹ Un agent que fala con ferramentas reais por unha rede real está no recuncho difícil dos cinco — non determinista mesmo a temperatura cero (Capítulo 17) e, o subestimado, descoñecido, porque non tes un modelo fiable do que as túas propias ferramentas lle fan ao mundo. Por iso o bucle do Capítulo 23 necesita tratamento de erros máis que planificación.

Os chans reais non son unidimensionais, así que eleva o mundo a un plano. Os signos de grade son paredes, os asteriscos son sucidade, e o robot empeza na cámara central:

        col  0 1 2 3 4 5 6
      row 0  * . . # . . *
      row 1  . # . # . # .
      row 2  . # . S . # .        S = the robot starts here
      row 3  . # . # . # .
      row 4  * . . # . . *

A mellora obvia é a memoria. O agent mantén un mapa: cada cadrado no que estivo e cada cadrado onde saltou o parachoques. A súa regra é entrar nun cadrado adxacente que non visitou — dereita, logo abaixo, logo esquerda, logo arriba — e recuar cando todo arredor é coñecido. Isto é un model-based reflex agent: mantén estado interno a partir do historial de perceptos, así que pode actuar sobre o que non pode ver nese momento.

É unha mellora real, e aínda así non abonda:

5,000 steps allowed -> steps=5,000  distinct squares visited=13/25  still dirty=2/4

Cinco mil movementos, metade do chan nunca visto. O mapa é correcto e as regras son correctas. O que o agent non pode facer é usar o mapa para ir a algún sitio: as súas regras só responden «a cal dos meus catro veciños debería entrar», así que cando queda sen cadrados non visitados ao seu lado non ten forma de expresar o pensamento hai un cadrado non visitado a oito movementos e gustaríame estar nel. Sabe onde está. Non sabe onde quere estar.

Un goal-based agent mantén, ademais do seu modelo do mundo, unha descrición da situación que quere provocar, e escolle accións buscando sobre secuencias delas ata atopar unha que remate alí. Os obxectivos converten a selección de accións dunha consulta nunha busca.

O obxectivo é «non queda ningún cadrado sucio». A busca é un percorrido en anchura ata o cadrado sucio máis próximo, e o camiño que devolve é o plan.

goal-based (fewest moves)      -> moves=27  battery=52  still dirty=0
      from 2,3 -> 4,6 via 5 moves:  2,3 2,4 3,4 4,4 4,5 4,6
      from 4,6 -> 0,6 via 4 moves:  4,6 3,6 2,6 1,6 0,6
      from 0,6 -> 4,0 via 10 moves: 0,6 0,5 0,4 1,4 2,4 2,3 2,2 3,2 4,2 4,1 4,0
      from 4,0 -> 0,0 via 4 moves:  4,0 3,0 2,0 1,0 0,0

Vinte e sete movementos, chan limpo. Pero mira a columna da batería e o último tramo do plan. A columna 0 ten alfombra: cruzar un cadrado con alfombra custa seis unidades de batería, un cadrado de baldosa unha. O agent volveu á casa pola columna 0 porque son catro movementos en vez de oito, e eses catro movementos con alfombra custaron 24 onde o desvío de oito movementos custaría 13.

Non pode facer outra cousa. Un obxectivo é unha proba binaria: o chan está limpo ou non o está. Todo plan que remate cun chan limpo o satisfai por igual, así que cando varios teñen éxito o agent non ten nada co que escoller entre eles. Preferir un éxito sobre outro require un número sobre os resultados, e ese número é unha función de utilidade. Un agent que a maximiza é un utility-based agent.

O cambio no código é un termo dentro da busca. A busca en anchura conta movementos; fai que conte custo no seu lugar e tes o algoritmo de Dijkstra e un agent distinto:

const nd = dist.get(k)! + (byCost ? cell.cost : 1);   // <- the entire difference

goal-based    (fewest moves)   -> moves=27  battery=52  still dirty=0
utility-based (cheapest route) -> moves=31  battery=41  still dirty=0
      from 4,0 -> 0,0 via 8 moves: 4,0 4,1 4,2 3,2 2,2 1,2 0,2 0,1 0,0

Catro movementos extra, once unidades de batería menos: un vinte e un por cento máis barato. Mesmo obxectivo, mesmo mapa, mesmo código agás por un termo. Os dous agents só difiren no que intentan facer ben, e toman rutas distintas para volver á casa.

Este é tamén o primeiro punto no que o agent necesita algo que non pode producir. Alguén ten que decidir canto vale unha unidade de batería en relación cun movemento. A utilidade é a medida de rendemento escrita nunha forma coa que o agent pode calcular, e escribila é traballo do deseñador. Cando a xente di que un agent «optimizou o incorrecto», case nunca quere dicir un bug. Quere dicir que esta liña foi escrita sen coidado.

Agora deixa que a sucidade volva. Catro habitacións ensúcianse de novo a catro ritmos distintos, e ao agent nunca llos din. Visita unha habitación por tick e só ve esa habitación. A medida de rendemento son ticks-habitación pasados sucios ao longo de 4.000 ticks — canto menos, mellor.

Un learning agent, na descomposición do libro de texto, é calquera dos anteriores máis tres partes: un elemento de aprendizaxe que cambia o agent, un crítico que lle di como vai o agent fronte a un estándar de rendemento fixo, e un xerador de problemas que propón accións que paga a pena probar polo que ensinarían.¹ Tres políticas no mesmo ambiente. A primeira non aprende; a segunda e a terceira aprenden o mesmo e úsano de forma distinta.

As taxas ocultas eran 0,35 para a cociña, 0,05 para o vestíbulo, 0,02 para o estudo e 0,01 para o faiado — e learner A atopounas. Identificou correctamente a cociña como a habitación máis sucia da casa, logo foi á cociña en cada tick durante o resto da simulación mentres as outras tres quedaban sucias para sempre. É cinco veces peor ca non aprender nada, e non está roto.

A lección é a da sección de utilidade. Learner A maximizou «probabilidade de que a habitación que estou a piques de visitar estea sucia». A medida de rendemento era «ticks-habitación pasados sucios». Números diferentes; o segundo é o que puntuaba o crítico, e ninguén llo dixo ao agent. Learner B multiplica a mesma taxa aprendida polo tempo desde a última visita — a sucidade que espera atopar, non a probabilidade de atopar algunha — e supera a patrulla da que partiu.

Un detalle de implementación decidiu o resultado. Na primeira versión de learner B, unha habitación na que non aparecera sucidade en tres visitas recibía unha taxa exactamente cero — e cero por calquera cousa é cero, así que nunca se volvía visitar e a estimación nunca podía corrixirse. Suavizar a fracción, éxitos máis un sobre intentos máis dous, converteu 11.895 en 1.576. «Aínda non observado» e «medido e deu cero» son afirmacións distintas, e un sistema que as garda no mesmo campo toma decisións que non pode desfacer.

  1  simple reflex    percept ────────────────────────────────► rules ────► action
  2  model-based      percept ──► [state] ──────────────────► rules ────► action
  3  goal-based       percept ──► [state] ──► [goal] ──────► search ───► action
  4  utility-based    percept ──► [state] ──► [goal] ──► [U] ──► argmax ► action
  5  learning         all of the above, plus [critic] ──► changes the parts above

Cada un dos cinco está en produción hoxe con outro nome.

Dúas filas están máis preto ca unha analoxía, dun xeito que custa cartos.

O chat é un model-based reflex agent cuxo modelo non é interno. No libro de texto, o estado é unha variable dentro do programa do agent. Nun chat é a transcrición: vive do teu lado, reenviase completa en cada chamada e reconstrúese desde cero dentro do modelo cada vez. Esa é a factura cuadrática do Capítulo 16, e é o mesmo obxecto que o libro de texto debuxaba como unha caixa etiquetada «estado». Aquí está a diferenza, medida nunha pregunta de seguimento con e sen as dúas mensaxes anteriores:

with the transcript      prompt=67  "The current temperature in Lisbon, Portugal is 15°C."
without the transcript   prompt=29  "Lisbon is the capital of Portugal, not a city in Portugal."

O mesmo modelo, as mesmas tres palabras de entrada do usuario, e o segundo é o robot do corredor batendo contra a parede. Nesa execución non había ferramentas, así que o 15 é inventado — pero o estado é o que fai que o seguimento signifique algo. Reconstrúelo cada vez e pagas 2,3× os tokens de entrada por iso nunha conversa de dúas quendas. O Capítulo 16 mediu ata onde chega ese multiplicador na quenda corenta.

Reflexion é un learning agent que cambia a súa entrada en vez do seu programa. Na descomposición do libro de texto, o elemento de aprendizaxe modifica o elemento de rendemento. Reflexion deixa os pesos intactos e escribe texto reflexivo nun búfer episódico que le o seguinte intento.³ O elemento de aprendizaxe é un prompt, a memoria unha fila de base de datos, o elemento de rendemento un modelo conxelado — e o diagrama é o do libro de texto, sen cambios.

E aquí está o límite honesto da correspondencia. Os cinco tipos clasifican o programa do agent. En 2026 ese programa está partido polo medio: unha parte é o teu código, outra está dentro de pesos que ti non adestraches. Cando un modelo decide pola súa conta chamar unha ferramenta, a proba de obxectivo está no teu programa ou no modelo? A taxonomía non ten resposta, porque cando se escribiu non había outro lugar onde puidese estar — e esa pregunta é exactamente onde se separan as dúas definicións modernas.

As definicións son argumentos sobre comportamento, e son moito máis fáciles de xulgar cunha traza diante.

O bucle de abaixo envía a conversa a un modelo; se a resposta contén unha chamada a ferramenta, executa a ferramenta, engade o resultado e envía todo de novo. Execútase contra un Qwen2.5-0.5B-Instruct local detrás dun endpoint con forma de OpenAI nesta máquina — a costura do Capítulo 14, así que ao bucle nin lle importa nin sabe que hai detrás do porto.

const BASE = process.env.LLM_BASE_URL ?? "http://127.0.0.1:8799/v1";

async function loop(question: string, maxTurns = 6) {
  const messages: Msg[] = [
    { role: "system", content: SYSTEM },
    { role: "user", content: question },
  ];

  for (let turn = 1; turn <= maxTurns; turn++) {
    const reply = await call(messages, TOOLS);
    const calls = reply.choices[0].message.tool_calls ?? [];
    messages.push(reply.choices[0].message);

    if (!calls.length) return messages;                      

    for (const c of calls) {
      const out = runTool(c.function.name, JSON.parse(c.function.arguments));
      messages.push({ role: "tool", name: c.function.name, content: out });
    }
  }
  throw new Error("turn cap reached");                       
}

Dúas liñas levan toda a idea, e ambas están marcadas; o resto é contabilidade. Os tres comportamentos son visibles nunha soa execución. Cando lle preguntas algo que pode facer por si mesmo, o modelo responde. Cando lle preguntas algo que non pode, chama:

=== a question the model cannot answer, one tool available
  turn 1  prompt= 187  out= 21  finish=tool_calls  CALL get_temperature({"city": "Oslo"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
  turn 2  prompt= 238  out= 12  finish=stop        TEXT "The current temperature in Oslo is 4
                                                        degrees Celsius."
  => model calls=2  prompt tokens=425  output=33  wall=6,257 ms
  => stopped by: the model produced text instead of a call

E para — o terceiro comportamento, e o máis fácil de pasar por alto, porque parece que non acontece nada. O bucle remata porque a quenda 2 volveu sen chamada a ferramenta. Ninguén o decidiu; decidiuo o modelo, emitindo prosa. A condición de terminación deste programa é o sinal dunha ausencia.

Dúas execucións máis merecen o espazo. Cando se lle pide comparar dúas cidades, o modelo emite ambas chamadas a ferramentas nunha soa quenda, recibe ambas lecturas de volta, e fai mal a comparación:

  turn 1  prompt= 188  out= 43  finish=tool_calls  CALL get_temperature({"city": "Oslo"}),
                                                        get_temperature({"city": "Lisbon"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
          tool  get_temperature -> {"city":"Lisbon","celsius":19}
  turn 2  prompt= 284  out= 13  finish=stop        TEXT "Oslo is currently warmer than Lisbon
                                                        at 4°C."

As ferramentas funcionaron. A chamada paralela funcionou. O bucle funcionou. A resposta é falsa, cos dous números correctos sentados na transcrición. Envolver un modelo nun bucle non fai que razoe; dálle a un modelo que está equivocado a capacidade de actuar sobre o seu erro — que é o Capítulo 30 por adiantado, e a metade do Capítulo 29.

Agora elimina o return marcado e deixa que o bucle execute ata o seu límite. Mesma pregunta, mesmo modelo:

  turn 1  prompt= 187  out= 21  CALL get_temperature({"city": "Oslo"})
  turn 2  prompt= 238  out= 12  TEXT "The current temperature in Oslo is 4 degrees Celsius."
  turn 3  prompt= 261  out= 30  TEXT "Could you please specify the exact location you're..."
  turn 4  prompt= 302  out= 14  TEXT "Sure! Could you tell me which city you're interested in?"
  turn 5  prompt= 327  out= 35  TEXT "I'm sorry, but I need more details to provide an..."
  turn 6  prompt= 373  out= 12  TEXT "Which city would you like to know the temperature for?"
  => model calls=6  prompt tokens=1,688  output=124  wall=25,261 ms  stopped by: turn cap

Catro veces os tokens de entrada, catro veces o tempo de reloxo, e un final no que o agent esqueceu que lle preguntaran e está interrogando ao usuario sobre unha pregunta que respondera na primeira quenda. A resposta correcta estaba na pantalla na quenda 2, e cada quenda despois dela empeorou a transcrición.

Así que un agent non é un bucle. É un bucle máis unha regra para saír del, e este ten exactamente unha regra dese tipo. O Capítulo 23 atopa cinco, e mostra que se rompe cando falta cada unha.

Citadas as dúas, non parafraseadas, porque as paráfrases son onde se fabrica a confusión.

A primeira definición pon o límite en quen controla o fluxo. Building effective agents de Anthropic nomea a ambigüidade e decide sobre ela:

"At Anthropic, we categorize all these variations as agentic systems, but draw an important architectural distinction between workflows and agents: Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."⁴

A proba é unha pregunta sobre o teu código fonte: quen escolleu o seguinte paso? Un switch no teu programa: fluxo de traballo. O modelo: agent. O mesmo documento di que os agents «normalmente son simplemente LLMs que usan ferramentas baseándose no feedback ambiental nun bucle» — que é exactamente a listaxe anterior.

A segunda definición pon o límite na independencia fronte ao usuario. A practical guide to building agents de OpenAI abre a súa páxina definitoria así:

"While conventional software enables users to streamline and automate workflows, agents are able to perform the same workflows on the users' behalf with a high degree of independence. Agents are systems that independently accomplish tasks on your behalf."⁵

Dúas frases despois, na mesma páxina, exclúe:

"Applications that integrate LLMs but don't use them to control workflow execution—think simple chatbots, single-turn LLMs, or sentiment classifiers—are not agents."⁵

Le esas citas en orde. As frases iniciais trazan a liña na independencia: isto marcha e remata o traballo sen min? A cuarta trázana no control da execución, que é exactamente a liña de Anthropic. Probas diferentes, mesma páxina, e hai sistemas reais nos que discrepan.

Por baixo hai unha colisión de vocabulario, e causa discusións en reunións reais. No primeiro documento un fluxo de traballo é unha arquitectura, e é a cousa que non é un agent. No segundo un fluxo de traballo é «unha secuencia de pasos que deben executarse para cumprir o obxectivo do usuario» — o traballo en si, que todo agent ten. «Substituímos o fluxo de traballo por un agent» é coherente baixo a primeira definición e case sen sentido baixo a segunda.

Tres sistemas que existen en 2026, baixo ambas definicións.

Dous dos tres cambian de lado. Iso non é un fracaso de ningún dos documentos. É unha advertencia sobre un tipo de reunión na que dúas persoas que están completamente de acordo sobre o que fai un sistema pasan unha hora discrepando sobre como chamalo.

As definicións chocan porque cada unha comprime dúas preguntas independentes nunha soa palabra. Sepáraas e o desacordo convértese nunha táboa, que é máis útil ca un veredicto.

Cada definición discute unha cela distinta, e as outras dúas non están en disputa. Así que cando a etiqueta importa — nun contrato, nunha revisión de risco, nun postmortem — as dúas frases que paga a pena escribir non son «é un agent», senón quen escolleu o seguinte paso e quen estaba mirando. Ambas se poden responder lendo código, ningunha necesita a definición de ninguén, e xuntas levan todas as consecuencias que a etiqueta estaba substituíndo.

Nada disto é novo. Wooldridge e Jennings revisaron os sentidos competidores de «agent» en 1995;⁶ Franklin e Graesser fixeron a pregunta deste capítulo en 1996, reuniron as definicións en circulación e atoparon que discrepaban.⁷ Unha enquisa de 2023 aínda define agents desde primeiros principios — «entidades artificiais que perciben o seu ambiente, toman decisións e realizan accións»⁸ — porque non existía nada asentado que citar, e CoALA describe partes en vez de trazar un límite.⁹ Trinta anos negándose a poñerse de acordo din que a palabra está facendo máis dun traballo.

Agora a consecuencia que chega antes da filosofía, que é a factura.

Cada medición aquí ten a mesma forma. A chamada única custou 39 tokens de entrada; a mesma pregunta cunha ferramenta custou 420 en dúas chamadas; o bucle coa súa regra de parada eliminada custou 1.688 en seis. O crecemento é peor ca lineal, porque a quenda n leva consigo todas as quendas anteriores: a columna de prompt desa execución de seis quendas di 187, 238, 261, 302, 327, 373. O Capítulo 16 derivou que o total é $\Theta(n^2)$ e axustou a curva nunha conversa real. Un agent converte cada tarefa nesa conversa, aínda que ningún humano a vexa nunca.

Se eses recontos de tokens medidos foran a un endpoint comercial coas tarifas que o Capítulo 16 leu o 6 de setembro de 2026 — $2.00 por millón de tokens de entrada e $12.00 por millón de saída — as catro execucións sairían así:

A fila dous contra a fila un é o número que hai que gardar. Sete veces e media o custo, para unha resposta peor a unha pregunta que o modelo xa sabía. Nada estaba mal configurado: existía unha ferramenta, así que o modelo usouna — e o achado do Capítulo 18, que o que doe é o prezo dun catálogo e non a súa precisión, ten aquí a súa demostración máis barata cun catálogo de unha.

Por iso a metade útil de ambos documentos é a metade sobre non construír isto. Anthropic é directo: atopa a solución máis simple posible e engade complexidade só cando faga falta, o que «podería significar non construír agentic systems en absoluto», xa que os agentic systems «trocan latencia e custo por mellor rendemento da tarefa» e «para moitas aplicacións, optimizar chamadas LLM únicas con retrieval e exemplos in-context adoita ser suficiente».⁴ O seu caso a favor dun agent é estreito: problemas abertos nos que non podes predicir o número de pasos nin codificar unha ruta de forma fixa, nun ambiente no que confías, aceptando «custos máis altos, e o potencial de erros compostos».⁴ A pantalla de OpenAI é a imaxe espello — xuízo complexo, conxuntos de regras imposibles de manter, datos non estruturados — e remata igual: «noutro caso, unha solución determinista pode abondar».⁵

Así que, na taxonomía deste capítulo: un número fixo de pasos nunha orde fixa é un pipeline, e chamalo agent non o fará máis rápido. Se o número de pasos depende do que atopes polo camiño, queres un bucle — e compras esa flexibilidade con N chamadas, unha transcrición cuadrática, e un sistema que pode equivocarse N veces en vez de unha.

Agora tes a taxonomía, ambas definicións modernas, os dous eixes que as fan compatibles, e un bucle curto que responde, chama e para.

Ese bucle ten unha forma de rematar: o modelo deixa de pedir ferramentas. O Capítulo 23 rómpeno a propósito, sete veces, e cada rotura engade unha peza. Unha tarefa imposible, e nunca remata — un límite de quendas. Unha noite executándose, e chega a factura — un orzamento en dólares. Unha ferramenta que falla — un erro sobre o que o modelo pode actuar. A mesma chamada dúas veces — unha chave de idempotencia. Un ficheiro que non debería tocar — unha aprobación humana. Un reinicio a medias — persistencia de sesión. Unha ferramenta que tarda tres minutos en silencio — progreso e cancelación. O que sae é un harness, o ficheiro sobre o que se executa o resto deste curso.

O que deixa a pregunta sobre a que ía realmente a diagonal disputada deste capítulo. Un bucle que decide o seu propio seguinte paso ten que decidir cando parar, e acabamos de ver que pasa cando non pode: seis quendas, catro veces a factura, e un agent interrogando ao usuario sobre unha pregunta que xa respondera. Parar non é unha condición. Cantas hai, e cal salta primeiro?

LLM Powered Autonomous Agents de Lilian Weng (2023) é a descomposición máis coñecida dun language agent en planificación, memoria e uso de ferramentas, e é a seguinte lectura correcta xunto cos dous documentos de provedores; os seus tres compoñentes son os Capítulos 23, 24 e 18 deste curso, nesa orde.

Cada número deste capítulo produciuse nesta máquina e nada foi estimado. O corredor, o plano, os catro agents que o percorren e as tres políticas de patrulla son o TypeScript de arriba, executado en Node 22; as cifras do agent aleatorizado son medias sobre 2.000 execucións sementadas cada unha e as cifras da patrulla son execucións sementadas únicas de 4.000 ticks. As trazas do modelo veñen de Qwen2.5-0.5B-Instruct en float32 en CPU con decodificación greedy, servido por loopback mediante un pequeno endpoint local en Python que carga os pesos e fala a forma de chat-completions de OpenAI — a costura outra vez, cos tensores no lado de Python e o bucle no de TypeScript — así que os recontos de tokens son os do tokenizer dese modelo e as latencias son as desa máquina. As únicas cifras tomadas doutro sitio son os dous prezos da táboa de custos, que son as tarifas que o Capítulo 16 leu na páxina de prezos de OpenAI o 6 de setembro de 2026, aplicadas aquí a recontos de tokens medidos localmente como ilustración e non como factura observada.