Última revisión: junio de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen NCP-AAI. Lee de arriba a abajo o salta a una sección.
Elegir entre un agent y un sistema multi-agent para un flujo de trabajo complejo.
Por defecto, usar un solo agent con herramientas. Dividir en múltiples agentes solo cuando los límites de la tarea sean distintos, el contexto se desborde o diferentes niveles de modelos se adapten a diferentes subtareas.
Por qué: Cada agent añadido multiplica la latencia, la superficie de error y el costo de orquestación; la mayoría de las cargas de trabajo tienen éxito con un solo agent bien equipado.
El orquestador debe despachar subtareas heterogéneas a especialistas.
Usar un agent supervisor que descomponga el objetivo, dirija a los agentes trabajadores con sus propios prompts y herramientas, y agregue los resultados.
Por qué: El control centralizado mantiene el estado coherente y hace que el límite de decisión sea auditable, a diferencia de un enjambre descontrolado.
El flujo del agent tiene ramas condicionales, bucles y distribución paralela.
Modelar el flujo de trabajo como un grafo explícito de nodos y aristas en lugar de un bucle de forma libre, para que el flujo de control sea determinista y reanudable.
Por qué: Un grafo hace que las ramas sean testeables y permite hacer checkpoints y reproducir desde cualquier nodo después de una falla.
Las solicitudes entrantes varían mucho en tipo y costo.
Poner delante del sistema un lightweight router agent que clasifique la intención y despache al agent o herramienta downstream más barato y capaz.
Por qué: El routing evita pagar el costo del modelo "frontier" para solicitudes triviales y aísla las preocupaciones por cada ruta.
Múltiples agentes deben leer y escribir el estado común del flujo de trabajo.
Externalizar el estado a un shared store (clave-valor o documento) indexado por sesión, en lugar de pasar la transcripción completa entre agentes.
Por qué: Un shared store limita el crecimiento del contexto y evita copias divergentes del estado entre agentes.
Diseñar agentes para escalado horizontal.
Mantener el cómputo del agent sin estado; persistir la conversación y la memoria externamente para que cualquier réplica pueda atender cualquier solicitud.
Por qué: Los nodos sin estado se autoescalan de forma limpia y sobreviven a los reinicios de pod sin perder el trabajo en curso.
Un sub-agent o herramienta falla a mitad del flujo de trabajo.
Diseñar pasos idempotentes con reintentos/retardos, acciones compensatorias para efectos secundarios, y una ruta de respaldo o escalada humana cuando se agoten los reintentos.
Por qué: Los sistemas agentic fallan parcialmente; la recuperación debe ser una preocupación de diseño de primera clase, no un pensamiento secundario.
Los sub-agentes son desarrollados por equipos separados.
Definir el contrato de entrada/salida de cada agent como un esquema tipado y tratar a los agentes como servicios detrás de interfaces estables.
Por qué: Los contratos explícitos permiten que los agentes evolucionen independientemente y sean probados unitariamente de forma aislada.
La calidad de la salida del agent es inconsistente en tareas difíciles.
Añadir un paso de crítico/reflexión que revise el borrador contra criterios y active un reintento limitado antes de devolverlo.
Por qué: La autocrítica detecta errores de forma económica, pero limita las iteraciones para evitar bucles descontrolados y costos.
El agent debe interactuar con APIs externas, bases de datos o archivos.
Exponer las capacidades como definiciones tipadas de función/tool; el modelo emite una llamada a herramienta, tu código la ejecuta y devuelve el resultado, luego el bucle continúa.
Por qué: La llamada estructurada a herramientas es más fiable y auditable que el análisis de instrucciones en texto libre.
El agent debe razonar sobre las observaciones antes de volver a actuar.
Implementar un bucle ReAct: el modelo produce un pensamiento, selecciona una herramienta, recibe la observación y repite hasta que se cumple una condición de parada.
Por qué: Intercalar el razonamiento y la acción expone la cadena para depuración y mejora la precisión en múltiples pasos.
El modelo utiliza incorrectamente o "alucina" los argumentos de la herramienta.
Escribir descripciones precisas de las herramientas, restringir los tipos de argumentos y los enums, y proporcionar uno o dos ejemplos de uso por herramienta.
Por qué: La mayoría de los errores de llamada a herramientas se deben a esquemas vagos; la descripción es el prompt para la herramienta.
El código downstream necesita JSON fiable del agent.
Restringir la generación a un esquema JSON (salida estructurada) en lugar de analizar texto libre, y validar antes de usar.
Por qué: La decodificación restringida por esquema elimina el frágil análisis de expresiones regulares y la deriva silenciosa de formato.
Construir un agent de producción en la pila NVIDIA.
Usar el NeMo Agent Toolkit para componer agentes, herramientas y flujos de trabajo, conectando las llamadas al modelo a backends servidos por NIM.
Por qué: El toolkit estandariza la fontanería del agent y se integra de forma nativa con el servicio de NVIDIA.
Una herramienta devuelve un error o se agota el tiempo de espera.
Devolver el error al modelo como resultado de la herramienta para que pueda reintentar, ajustar los argumentos o elegir una ruta alternativa.
Por qué: Mostrar las fallas al agent permite la recuperación; ocultarlas deja al agent ciego.
Se necesitan varias llamadas a herramientas independientes en un solo paso.
Realizar llamadas a herramientas en paralelo cuando el modelo lo admita y las llamadas no tengan dependencia de orden, luego fusionar los resultados.
Por qué: La ejecución paralela reduce la latencia de tiempo real para trabajos de distribución como búsquedas de múltiples fuentes.
Una capacidad especialista debe ser reutilizable en varios flujos de trabajo.
Envolver un sub-agent detrás de una única interfaz de herramienta para que el padre lo invoque como cualquier otra herramienta.
Por qué: Tratar a los sub-agentes como herramientas mantiene la composición uniforme y oculta la complejidad interna.
El agent se desvía de la tarea o ignora las restricciones.
Fijar el rol, las herramientas permitidas, el formato de salida y las restricciones estrictas en un system prompt conciso; reafirmar las reglas críticas cerca del final.
Por qué: Un system prompt bien definido es el control más barato y de mayor impacto sobre el comportamiento del agent.
Medir si un agent resolvió correctamente una tarea de múltiples pasos.
Evaluar tanto la respuesta final como la trayectoria (precisión de la llamada a la herramienta, orden de los pasos y acciones innecesarias) contra un conjunto etiquetado.
Por qué: Una respuesta correcta de una trayectoria defectuosa es frágil; la puntuación de la trayectoria detecta fallas latentes.
No existen etiquetas de ground-truth para las salidas de agentes de tipo abierto.
Usar un LLM-as-judge con una rúbrica para puntuar las salidas, calibrado con una pequeña muestra etiquetada por humanos.
Por qué: Los modelos Judge escalan la evaluación, pero deben ser calibrados o introducirán su propio sesgo.
Necesitas detectar regresiones antes de cada lanzamiento.
Construir un arnés de evaluación offline con un conjunto de escenarios fijos que se ejecute en cada cambio y condicione los despliegues a un umbral de aprobación.
Por qué: El comportamiento agentic cambia sutilmente con los cambios de prompt o modelo; un conjunto de regresión es la red de seguridad.
El agent elige la herramienta incorrecta o argumentos erróneos.
Rastrear la precisión/recall de la selección de herramientas y la validez de los argumentos como métricas independientes, no solo el éxito de la tarea final.
Por qué: Isolar la capa de llamada a herramientas permite identificar si las fallas provienen de la selección o del esquema.
La tasa de aprobación de la evaluación disminuyó después de un cambio.
Inspeccionar las trayectorias completas de los casos fallidos, agrupar los modos de falla y corregir primero el grupo dominante.
Por qué: Las puntuaciones agregadas ocultan la causa raíz; el agrupamiento por traza revela el defecto real.
El agent tiene un rendimiento inferior y debes mejorarlo.
Iterar los prompts y las descripciones de las herramientas primero; solo escalar a un modelo más grande o al fine-tuning cuando los cambios en los prompts se estanquen.
Por qué: La iteración de prompts es rápida y barata; los cambios de modelo añaden costo y deben basarse en evidencia.
Comparar dos diseños de agentes que ambos superan los objetivos de precisión.
Añadir el costo por tarea y la latencia p95 a la evaluación para que el diseño más barato y rápido gane en caso de empate.
Por qué: La viabilidad en producción es precisión más costo más latencia, no solo precisión.
Servir la inferencia del modelo para agentes en producción.
Desplegar modelos como microservicios NIM, proporcionando a los agentes un endpoint de inferencia estandarizado y acelerado por GPU con batching incorporado.
Por qué: NIM empaqueta la inferencia optimizada detrás de una API estable para que los agentes no necesiten gestionar los internos del serving.
El tráfico del agent es irregular e impredecible.
Contenerizar agentes y el servicio, ejecutar en Kubernetes y autoescalar según la concurrencia o la utilización de GPU con límites mínimos/máximos sensatos.
Por qué: El autoescalado absorbe los picos, mientras que las réplicas mínimas evitan la latencia de arranque en frío en la ruta crítica.
El costo de inferencia de GPU es demasiado alto bajo carga.
Habilitar el batching dinámico/continuo en la capa NIM para aumentar los tokens-por-GPU-segundo antes de añadir hardware.
Por qué: El batching mejora drásticamente la utilización de la GPU; escalar nodos primero desperdicia capacidad.
Los agentes lanzan llamadas a herramientas y modelos paralelos sin límites.
Aplicar límites de concurrencia por agent y globales con una cola para que el sistema degrade elegantemente bajo carga.
Por qué: La distribución sin límites agota las cuotas de GPU y downstream, lo que provoca fallas en cascada.
Elegir hardware de GPU para una carga de trabajo de inferencia de agent.
Dimensionar según el footprint del modelo y los objetivos de latencia: H100 para modelos grandes establecidos, Blackwell donde dominan el ancho de banda de memoria y el rendimiento del razonamiento.
Por qué: Hacer coincidir el hardware con el modelo evita tanto el subaprovisionamiento como el pago por capacidad ociosa.
Lanzar una nueva versión de agent o modelo de forma segura.
Desplegar vía canary a un pequeño segmento de tráfico, comparar las métricas en vivo con la línea base, luego progresar o revertir.
Por qué: Los cambios en el comportamiento del agent son difíciles de predecir completamente offline; el canary limita el radio de impacto.
Las cadenas largas de agentes corren el riesgo de solicitudes colgadas.
Establecer presupuestos de tiempo de espera por paso y de extremo a extremo; cancelar y retroceder cuando se superen.
Por qué: Sin presupuestos, una sola herramienta lenta puede inmovilizar una ranura de GPU y privar de recursos a otras solicitudes.
La tarea requiere muchos pasos interdependientes.
Usar un patrón de planificar y ejecutar: generar un plan explícito primero, luego ejecutar los pasos, replanificando cuando una suposición falle.
Por qué: La planificación inicial reduce la divagación y proporciona un checkpoint para validar antes de gastar llamadas a herramientas.
La calidad de la descomposición es el cuello de botella.
Dirigir el paso de planificación a un modelo de razonamiento Nemotron mientras se utilizan modelos más baratos para la ejecución.
Por qué: Gastar el cómputo de nivel de razonamiento donde importa — el plan — no en cada sub-paso rutinario.
El agent debe recordar hechos a lo largo de una sesión prolongada.
Mantener los turnos recientes en el contexto de trabajo; persistir los hechos duraderos en un almacén de memoria a largo plazo recuperado bajo demanda.
Por qué: Meter todo en el contexto aumenta el costo y la latencia y eventualmente desborda la ventana.
Elegir cómo almacenar la memoria del agent.
Almacenar el historial de interacción episódica por separado de los hechos semánticos; recuperar la memoria semántica por similitud, la episódica por novedad/sesión.
Por qué: Diferentes patrones de acceso demandan diferentes almacenes; un solo cubo recupera mal para ambos.
Una conversación de larga duración se acerca al límite de contexto.
Resumir los turnos antiguos en un resumen compacto continuo y descartar el historial sin procesar, manteniendo solo los turnos recientes verbatim.
Por qué: El resumen continuo preserva la continuidad mientras limita el costo de tokens y evita errores de truncamiento.
El agent debe fundamentar las respuestas en datos empresariales privados.
Dar al agent una herramienta de retrieval sobre un vector store para que decida cuándo y qué recuperar, en lugar de siempre anteponer contexto.
Por qué: La recuperación agentic busca solo cuando es necesario, reduciendo tokens y contexto irrelevante.
Construir un pipeline de retrieval de alta calidad en NVIDIA.
Usar los microservicios NIM de embedding y reranking de NeMo Retriever para un RAG acelerado y de grado de producción.
Por qué: NeMo Retriever proporciona modelos de embedding/rerank ajustados y servidos eficientemente en GPU.
La búsqueda de vectores pura omite las consultas de coincidencia exacta y de palabras clave.
Combinar la búsqueda de vectores densos con la recuperación de palabras clave/escasas y rerankear los candidatos fusionados.
Por qué: La recuperación híbrida recupera términos precisos (IDs, códigos) que los embeddings desdibujan.
Los chunks recuperados son demasiado burdos o demasiado fragmentados.
Chunkear en límites semánticos con superposición modesta y adjuntar metadatos; ajustar el tamaño al modelo de embedding y al tipo de consulta.
Por qué: La granularidad del chunk impulsa directamente la relevancia de la recuperación; ambos extremos degradan la fundamentación.
El agent devuelve información obsoleta del índice.
Realizar un re-indexing incremental en los cambios de la fuente y marcar los documentos con sellos de tiempo para un ranking sensible a la actualidad.
Por qué: Sin manejo de la frescura, RAG fundamenta con confianza las respuestas en datos desactualizados.
Elegir un backend de modelo para el razonamiento del agent.
Seleccionar un modelo Nemotron dimensionado para la carga de razonamiento y servirlo a través de NIM para un endpoint estandarizado.
Por qué: Las variantes de razonamiento de Nemotron están ajustadas para la planificación agentic y el uso de herramientas; NIM estandariza el serving.
Mapear una necesidad agentic al componente NVIDIA correcto.
Usar NeMo Agent Toolkit para orquestación, NIM para serving, NeMo Retriever para RAG, NeMo Guardrails para seguridad y Nemotron para razonamiento.
Por qué: Saber qué componente es responsable de cada preocupación es una pregunta recurrente de examen y una decisión de diseño.
Ensamblar una aplicación agentic de extremo a extremo en NVIDIA.
Componer microservicios NIM discretos (LLM, embedding, rerank, guardrails) detrás de la capa del agent, escalando cada uno independientemente.
Por qué: La descomposición en microservicios permite que cada capacidad escale y versione por sí misma.
Las reglas de residencia de datos prohíben enviar datos a APIs externas.
Autohospedar microservicios NIM en infraestructura GPU propia para que los modelos y los datos permanezcan dentro del límite.
Por qué: El empaquetado portable de NIM soporta despliegues on-prem que cumplen con los requisitos de residencia.
Un agent en producción se comporta mal y debes diagnosticarlo.
Emitir trazas distribuidas que capturen cada llamada a modelo, llamada a herramienta y decisión, luego inspeccionar la trayectoria fallida de extremo a extremo.
Por qué: Las fallas del agent son multi-paso; sin trazas completas no puedes localizar dónde falló el razonamiento.
El gasto de tokens y la latencia del agent aumentan con el tiempo.
Rastrear tokens, costo y latencia p95 por agent y por herramienta, con alertas sobre el incumplimiento de umbrales.
Por qué: El costo y la latencia se desvían silenciosamente a medida que los prompts y el tráfico evolucionan; las métricas lo detectan temprano.
La calidad se degrada gradualmente sin cambios en el código.
Ejecutar el conjunto de evaluación continuamente contra muestras de producción y alertar sobre la deriva de métricas respecto a la línea base.
Por qué: La deriva de datos y del modelo upstream erosiona la calidad de forma invisible entre lanzamientos.
El agent debe mantenerse en el tema y rechazar solicitudes inseguras.
Aplicar NeMo Guardrails con "rails" de entrada, salida, temáticos y de diálogo alrededor del agent.
Por qué: Los "rails" programables aplican la política independientemente y como respaldo al propio comportamiento del modelo.
Contenido no confiable podría secuestrar al agent a través de datos recuperados o de herramientas.
Tratar todo el contenido externo como no confiable, aislarlo de las instrucciones y restringir la autoridad de la herramienta para que los comandos inyectados no puedan escalar.
Por qué: La inyección explota el poder del agent; la defensa es de menor privilegio más separación de instrucciones/datos.
El agent maneja datos regulados o personales.
Redactar o tokenizar la PII antes de las llamadas al modelo y escribir registros de auditoría a prueba de manipulaciones de las acciones del agent y las invocaciones de herramientas.
Por qué: El cumplimiento exige tanto minimizar la exposición como probar lo que hizo el agent.
El agent puede realizar acciones de alto riesgo como pagos o eliminaciones.
Insertar una puerta de aprobación humana antes de llamadas a herramientas irreversibles o de alto impacto, pausando el flujo de trabajo hasta que se confirme.
Por qué: La autonomía está bien para pasos reversibles; las acciones con consecuencias necesitan un humano en el bucle.
El agent no está seguro o falla repetidamente una tarea.
Definir un umbral de confianza/falla que escale a un humano con contexto completo en lugar de adivinar.
Por qué: Una entrega elegante es mejor que una respuesta incorrecta segura en trabajos de alto riesgo.
Los stakeholders desconfían de las salidas del agent.
Mostrar el resumen de razonamiento del agent, las fuentes y las herramientas utilizadas para que los humanos puedan revisar y anular decisiones.
Por qué: La explicabilidad genera confianza y a menudo es necesaria para la supervisión y la auditoría.