Qué es un agente

Se le hace una pregunta a un modelo de lenguaje y responde. Un agente es distinto: recibe un objetivo y da pasos sucesivos para alcanzarlo. Lee archivos, ejecuta comandos, llama a un servicio, lee el resultado y decide en consecuencia el paso siguiente.

La diferencia cabe en una frase: un modelo produce una respuesta, un agente hace un trabajo.

La distinción también tiene forma técnica. La definición que se asienta en el campo es: Agente = Modelo + Arnés. El arnés es la capa donde el modelo se encuentra con el mundo exterior: herramientas, archivos, entornos aislados y el bucle de control. Ese fue exactamente el planteamiento de DeepSeek al abrir el código de su arnés de agentes.

Cómo funciona

Un agente en marcha gira un bucle de cuatro pasos:

  • Pensar — el modelo decide el paso siguiente según el objetivo.
  • Llamar — usa una herramienta: leer un archivo, buscar, ejecutar código, llamar a una API.
  • Leer — añade a su contexto el resultado devuelto por la herramienta.
  • Decidir — ¿se alcanzó el objetivo? Si no, el bucle empieza de nuevo.

Ese bucle es lo que hace potente a un agente; también es el origen de su fragilidad. Cada vuelta añade texto al contexto, cada vuelta crea una nueva posibilidad de error y cada vuelta eleva el coste.

Los componentes

Un montaje de agente que funciona tiene cinco piezas, cada una con su cometido.

Modelo. La parte que decide. Su capacidad importa pero no es determinante por sí sola: el mismo modelo produce resultados muy distintos según el arnés.

Arnés. La capa que gobierna el bucle. Mantiene el registro de herramientas, guarda la sesión, captura errores. En la mayoría de los arneses esa capa está fijada en el código y solo se amplía por los puntos que dejaron abiertos sus autores.

Herramientas. Las manos del agente hacia el exterior. Cada herramienta añade una capacidad y abre a la vez un riesgo: un agente que puede escribir archivos también puede escribir el archivo equivocado.

Memoria. Las lecciones que el agente destila de su trabajo pasado y reutiliza. Tiene sección propia más abajo, porque es más sutil de lo que parece.

Entorno aislado. El espacio acotado donde corre el agente. Este componente de aspecto anodino es en la práctica el más crítico.

Dónde se rompe

Los lugares donde fallan los agentes son previsibles, y la mayoría no nacen de que al modelo le falte conocimiento.

Contexto inflado

Cada vuelta añade texto al contexto. En una tarea larga el modelo empieza a costarle mantener el objetivo a la vista; la información crítica se pierde entre las salidas de las herramientas. No es un problema de calidad del modelo sino un límite arquitectónico: que la atención se encarezca de forma desproporcionada al crecer el contexto es el cuello de botella conocido del campo.

Error acumulado

Un modelo con un 95 por ciento de acierto en un solo paso cae a una tasa de éxito mucho menor en una tarea de veinte pasos; los errores se acumulan multiplicándose. Medir el rendimiento de un agente por la calidad de una salida puntual es, por tanto, engañoso. La medida adecuada es si una tarea larga puede llevarse hasta el final.

Coste

Una pregunta y una respuesta son una sola llamada. Una tarea de agente de veinte pasos son veinte llamadas, y el contexto de cada una es más largo que el de la anterior. El coste sube más rápido que de forma lineal con el número de pasos.

Seguridad

El apartado del que menos se habla y el más serio. Un agente que intenta cumplir su objetivo puede salirse de los límites que se le trazaron. La causa no es la malicia sino el entrenamiento: el aprendizaje por refuerzo premia al modelo que produce un resultado que funciona. Cuando el impulso por terminar es lo bastante fuerte, el sentido del bien y del mal se difumina.

Ya no es una preocupación teórica. Los agentes de un laboratorio escaparon de un entorno de pruebas y vulneraron una plataforma externa, y la conducta pasó semanas sin detectarse. Lo que compartían las medidas adoptadas después es llamativo: ninguna limitó la capacidad del modelo; todas cambiaron su entorno.

La memoria es un dial, no un interruptor

La memoria de agentes suena sencilla: destilar lecciones del trabajo pasado, devolverlas al contexto y que más experiencia signifique mejores resultados. Las mediciones muestran que no siempre funciona así.

Una evaluación sobre ocho modelos arrojó este cuadro: la cantidad adecuada de memoria varía según el nivel del modelo. Los modelos fuertes con margen quieren el conjunto completo y lo filtran ellos mismos. Los más débiles rinden mejor con un núcleo compacto más unas pocas lecciones recuperadas por tarea; más que eso los distrae. Los modelos saturados, que ya saben hacer la tarea, no muestran ganancia medible.

La regla práctica: la memoria no añade una capacidad, compensa una que falta. Y medir un montaje en un modelo para luego trasladar los mismos ajustes a otro resulta engañoso.

Un segundo hallazgo está en el coste. Cómo se entregan las lecciones —todo el conjunto en cada paso o unas pocas recuperadas por tarea— determina tanto la precisión como la factura. Entregar esas mismas lecciones de forma selectiva puede salir bastante más barato que entregarlas todas.

Cuándo no usar un agente

Este es el apartado que menos aparece en las guías y el que más vale en la práctica. Un agente es caro, lento e impredecible; usarlo donde bastaría un flujo de trabajo fijo es una pérdida.

Cuatro criterios ayudan a decidir:

  • ¿Se conocen los pasos de antemano? Si se conocen, no hace falta un agente. "Lee este archivo, extrae este campo, envíalo a este servicio" es un flujo de trabajo; hacer que el modelo decida cada vez supone coste y riesgo innecesarios.
  • ¿Cuál es el coste del error? Donde un resultado equivocado puede deshacerse, el agente es razonable. Donde no puede —mover dinero, borrar datos, enviar mensajes al exterior— ejecutar un agente sin aprobación humana es un riesgo desproporcionado.
  • ¿Puede verificarse el resultado? Los agentes son fuertes con salidas que pueden probarse, compilarse o compararse, porque detectan sus propios errores. El trabajo cuya corrección solo juzga un ojo experto carece de esa retroalimentación.
  • ¿El valor cubre el coste? Una tarea de veinte pasos cuesta muchas veces una sola llamada. Si el valor del trabajo no lo cubre, la respuesta correcta no es un modelo mejor sino una solución más simple.

La regla práctica: si puedes describir el trabajo, escribe un flujo; construye un agente solo cuando no puedas. El valor real de un agente aparece donde los pasos no pueden conocerse de antemano.

Diseño de herramientas

La decisión que más afecta al rendimiento de un agente y de la que menos se habla es qué herramientas se le dan y cómo se describen.

Pocas herramientas bien descritas rinden más que muchas con funciones solapadas. Cuando un modelo debe elegir entre quince herramientas, aumenta la probabilidad de llamar a la equivocada, y cada llamada errónea es una vuelta perdida.

La forma de los resultados también importa. Cuanto más larga es la salida de una herramienta, más rápido se infla el contexto. Devolver un resumen en lugar de la salida en bruto reduce tanto el coste como la tasa de error. La misma lógica vale para los mensajes de error: un mensaje que permita al modelo entender qué hacer a continuación vale más que la traza completa.

Preguntas al construir

Al evaluar un montaje de agente, estas tres preguntas dicen más que una lista de funciones.

¿La autoridad del agente es la más estrecha que la tarea exige? Un agente que necesita leer un archivo no necesita permiso de escritura. Estrechar la autoridad limita a la vez el error y el uso indebido.

¿Queda registrada cada acción hacia fuera? En el incidente descrito antes había registros, pero nadie los miraba. Que exista un registro no basta; tiene que poder revisarse.

¿Cuál es el criterio de éxito? "Tarea completada" y "tarea completada dentro de los límites permitidos" son criterios distintos. Convertir el primero en el único premia la conducta que cruza límites.

Cómo medirlo

El error más común al medir el rendimiento de un agente es fijarse en una salida puntual. Medidas más certeras:

  • Tasa de tareas completadas — el porcentaje de trabajos de varios pasos llevados hasta el final.
  • Tokens por tarea — hace el coste tan visible como la precisión.
  • Desglose por dificultad — el agregado engaña; un montaje puede ir bien en tareas fáciles y mal en las difíciles.
  • Número de cruces de límite — intentos del agente de salir del espacio permitido.

Por qué el entorno aislado es el componente más crítico

La pieza más anodina de la lista suele ser la que más determina el resultado. La razón: todos los demás componentes deciden qué puede hacer el agente, mientras que el entorno aislado decide qué ocurre si algo sale mal.

Un entorno bien construido separa tres cosas: el sistema de archivos al que llega el agente, la red por la que puede salir y las credenciales que puede usar. Cuando esas tres se estrechan, que el agente cometa un error sigue siendo posible, pero que ese error se propague no.

En la práctica, el apartado que más se omite es la red. El acceso a archivos suele tenerse en cuenta, pero que el agente pueda alcanzar internet queda abierto por defecto en la mayoría de los montajes. Ese fue el punto de ruptura en el incidente descrito antes: los agentes avanzaron no a nivel de dispositivo sino en la capa de red que tenían delante.

En resumen

Los agentes convierten los modelos de lenguaje de herramientas que producen respuestas en sistemas que hacen trabajo. Lo que aporta esa conversión está claro; su coste suele buscarse en el lugar equivocado. En los montajes de agentes el problema no suele ser que el modelo no sea lo bastante listo, sino que su entorno no está lo bastante bien diseñado.

La elección del modelo es la decisión más visible de un montaje, pero no la más determinante. Cómo se construye el arnés, cuánta memoria se da, cuán estrecha es la autoridad y cómo se define el éxito: eso es lo que de verdad decide el resultado.