Arquitectura de agentes de IA: modelo, herramientas y control
La arquitectura de un agente de IA organiza modelo, instrucciones, herramientas, estado y controlador para convertir una petición en acciones. Define cómo las observaciones influyen en la decisión siguiente, dónde se aplican permisos, cómo se registran los errores y qué condiciones terminan o interrumpen una ejecución.
Usa esta guía si entiendes un diagrama pero no puedes señalar quién ejecuta la herramienta. Seguiremos una búsqueda de catálogo desde la petición hasta una respuesta comprobada e identificaremos las decisiones que corresponden al código de la aplicación.
Ideas principales
- Separa las propuestas de la ejecución.
- Registra cada observación con su fuente y estado.
- Valida las entradas donde la operación se realiza.
- Distingue finalización, fallo e interrupción.
Cinco componentes con trabajos distintos
Las instrucciones definen la tarea y sus límites. El modelo propone la próxima acción. Las herramientas realizan operaciones concretas. El estado conserva lo sucedido. El controlador conecta las partes y decide si continuar. Esta separación ayuda a localizar el fallo: objetivo ambiguo, propuesta equivocada, herramienta indisponible o comprobación que aceptó una respuesta sin evidencia. Cambiar el prompt no repara todas esas causas. Primero identifica el componente responsable y después modifica el diseño correspondiente.
Sigue una petición al catálogo
El estudiante pide una lección introductoria de IA. La aplicación crea un estado con el objetivo y una lista vacía de observaciones. El planificador propone buscar la clave 'ai'. El controlador comprueba el nombre y los argumentos y ejecuta la consulta. Guarda tanto el registro como el estado de la llamada. La propuesta siguiente puede utilizar esa observación para terminar. La comprobación final exige una referencia al registro recuperado, en lugar de un título de curso inventado.
- 1Objetivo
- 2Acción propuesta
- 3Validación
- 4Llamada
- 5Observación
- 6Siguiente decisión
El estado va más allá del historial
Un registro de mensajes permite reconstruir lo dicho, pero el estado operativo también necesita presupuesto restante, acciones completadas y decisiones pendientes. Conserva el identificador de una búsqueda en lugar de copiar toda la base en cada solicitud al modelo. El estado debe ser pequeño para inspeccionarlo y explícito para reanudarlo. Si una ejecución espera revisión, su situación sigue pendiente: reiniciar el proceso no debe convertirla silenciosamente en un trabajo finalizado.
Coloca las comprobaciones donde se aplican
Un prompt que dice 'solo consultas del catálogo' expresa una política. Una función que rechaza las otras herramientas la aplica. Utiliza la misma distinción para tipos, alcance de acceso y acciones repetidas. Un error recibido debe permanecer como error en el estado. Si una operación modifica otro sistema, define cómo reconocer que ya se completó antes de reintentarla. La recuperación podría repetir un cambio que tuvo éxito antes de perderse la conexión.
Diseña un ciclo observable
Define transiciones explícitas: listo, herramienta solicitada, observación registrada, pendiente de revisión, completado y detenido. Añade los estados que utiliza el ejercicio y explica la salida de cada uno. Registra metadatos y resultados sin recopilar datos personales innecesarios. Un entorno de orquestación puede ayudar con persistencia e interrupciones en sistemas grandes. Comprende primero el ciclo: un framework puede organizarlo, pero el significado de un resultado aceptable depende de tu tarea.
En palabras sencillas
Piensa en un pequeño taller. El modelo propone el trabajo, las herramientas lo realizan, un cuaderno anota los resultados y el responsable comprueba permisos y progreso. La arquitectura organiza esas responsabilidades.
Pruébalo
Dibuja una petición pasando por cinco cajas: objetivo, propuesta, validación, búsqueda y observación. Añade el punto donde la ausencia de un registro impide inventar una lección. Marca las cajas que pueden modificar datos.
Resultado esperado
Un diagrama que coloca ejecución y controles fuera del modelo, registra el estado de la consulta y termina con un resultado completado o detenido.
Comprueba tu respuesta: ¿Dónde se rechaza una herramienta prohibida?
En el límite de ejecución, antes de invocarla. Las instrucciones por sí solas no aplican esa barrera.
Preguntas y respuestas
¿El modelo es el controlador?
El modelo puede proponer la acción siguiente, pero el código recibe la propuesta, la valida e invoca la herramienta real. Separar ambas responsabilidades permite inspeccionar permisos y límites. Algunos productos las agrupan; examina su ruta de ejecución en vez de confiar solo en las etiquetas del diagrama.
¿Necesito un framework de orquestación?
Puedes estudiar un ciclo pequeño con código sencillo. Un framework resulta útil para persistencia, ejecuciones reanudables o transiciones explícitas de un grafo. Compara esas necesidades con su comportamiento documentado y prueba un fallo antes de utilizarlo en un proyecto mayor.
Sigue una petición real. Haz explícitos el límite de ejecución, la observación y la comprobación final antes de añadir funciones.
Fuentes y lecturas
- Anthropic — Building effective agents ↗Fuentes revisadas:
- LangChain — LangGraph overview ↗Fuentes revisadas:
- Yao et al. — ReAct: Synergizing Reasoning and Acting in Language Models ↗Fuentes revisadas: