Cuando un componente aeroespacial calificado se vuelve obsoleto o tiene un tiempo de entrega largo, un ingeniero pasa días haciendo referencias cruzadas de especificaciones en hojas de datos de proveedores, documentos de control de interfaz (ICDs) y registros de calificación antes de documentar una justificación de sustitución para revisión. Una sustitución incorrecta en un componente crítico para el vuelo puede causar un fallo en la misión, sin embargo, la pista de evidencia detrás de cada decisión a menudo se encuentra dispersa en correos electrónicos y conocimiento institucional no documentado, por lo que no hay un paquete formal y repetible para que un revisor lo verifique.

Una publicación anterior, Manufacturing intelligence with Amazon Nova Multimodal Embeddings, mostró cómo el modelo recupera respuestas bloqueadas dentro de diagramas de ingeniería, tramas térmicas y gráficos de hojas de datos que los pipelines de solo texto pasan por alto. Esta publicación continúa donde dejó el trabajo de recuperación, poniendo esas capacidades dentro de un sistema de múltiples agentes que ensambla la evidencia de sustitución, desde la recuperación hasta una evaluación redactada.

En esta publicación, mostramos cómo construir un asistente de ingeniería de múltiples agentes que reduce la referencia cruzada manual detrás de la evaluación de sustitución de partes utilizando Amazon Bedrock AgentCore, Amazon Nova Multimodal Embeddings y el kit de desarrollo de software de código abierto Strands Agents SDK. Un planificador enruta el trabajo a través de tres agentes especializados que buscan en una base de conocimiento multimodal, puntúan a los candidatos contra reglas de tolerancia deterministas, comparan fotos de partes y basan las reclamaciones de ciclo de vida en datos web en vivo. El ingeniero sigue siendo el responsable de la toma de decisiones en todo momento, porque el sistema ensambla la evidencia y redacta documentos sin aprobar nunca una sustitución por sí mismo.

Visión general de la solución

El asistente se construye alrededor de una regla de diseño, que es que el ingeniero toma todas las decisiones y el sistema ensambla la evidencia para ello. Esa regla determina dónde usamos modelos de lenguaje grande (LLM) y dónde usamos código determinista en su lugar.

Tres pilares definen la arquitectura:

• Evaluación de especificaciones determinista – El código de reglas de tolerancia escrito en Python califica cada parte candidata con respecto a la parte de referencia y los requisitos establecidos por el ingeniero. Dado que las mismas entradas producen consistentemente los mismos veredictos de aprobación/marca, los resultados pueden incorporarse en una revisión formal de ingeniería.
• Orquestación de multi-agente – Un planificador ligero enruta cada consulta a uno o más de tres agentes especializados (Catálogo, Evaluación, Conocimiento), y un supervisor sintetiza sus hallazgos solo cuando más de un especialista contribuyó. Preguntas complejas como “Verificar si esta rueda está llegando al final de su vida útil, encontrar alternativas y calificarlas” encadenan a los tres especialistas en secuencia.
• Decisión con intervención humana – El sistema redacta memorandos de justificación y Evaluaciones de Impacto de Integración para revisión de ingeniería, pero no recomienda ni aprueba una sustitución. Cada evaluación también escribe una entrada de auditoría alineada con las secciones 8.4 y 8.5.6 de AS9100.

El siguiente diagrama muestra la arquitectura.

Figura 1: Arquitectura del asistente de ingeniería de multi-agente en Amazon Bedrock AgentCore

Amazon Bedrock AgentCore es una plataforma para construir, conectar y optimizar agentes a gran escala, con cualquier framework o modelo. En esta solución, las solicitudes de chat desde la aplicación del ingeniero fluyen hacia un grafo de multiagente alojado en el runtime de AgentCore: un planificador (Claude Haiku 5.5) produce un plan de enrutamiento, los especialistas (Claude Sonnet 5.5) ejecutan sus herramientas y un supervisor (Claude Opus 5.5) sintetiza sus resultados cuando más de un especialista se ejecuta. Los especialistas recuperan desde una base de conocimiento administrada que creamos con Amazon Bedrock Managed Knowledge Bases utilizando Amazon Nova Multimodal Embeddings, enrutados a través de un Gateway de AgentCore, una capacidad de Amazon Bedrock AgentCore, junto con el conector de búsqueda web para datos web en vivo. Para la consulta de imagen (subir un gráfico para identificar una parte), el agente llama directamente a un índice de vectores de Amazon S3, porque la API de recuperación de la base de conocimiento administrada no acepta entrada de imagen. Amazon S3 Vectors es una capacidad del Servicio de almacenamiento simple de Amazon (Amazon S3). Una cadena fija separada (Conocimiento, luego Evaluación, luego Supervisor) produce el documento formal de Evaluación de Impacto de Integración (IIA).

Amazon Nova Multimodal Embeddings aparece en dos roles distintos:

1. Recuperación multimodal – Las hojas de datos, los ICD y las gráficas de rendimiento se incrustan con Amazon Nova Multimodal Embeddings para que el contenido de texto y visual compartan un espacio semántico. Un ingeniero puede ingresar “curva de torque para la rueda de 0,06 Nms” o subir una imagen de gráfico, y la recuperación devuelve el diagrama coincidente con la atribución de fuente.
2. Puntuación de similitud visual – Cuando se comparan dos partes candidatas, Amazon Nova Multimodal Embeddings produce una similitud cosina cuantitativa entre sus fotos, y Claude analiza las diferencias físicas específicas (patrón de montaje, colocación del conector, geometría del alojamiento). La puntuación agrega evidencia de apoyo a la comparación de especificaciones determinista, en la que se basa el veredicto de ajuste.

Requisitos previos

Para seguir adelante, necesitas:

• Una cuenta de AWS con acceso a Amazon Bedrock en la región de AWS US East (N. Virginia).
• Acceso a modelos a Amazon Nova Multimodal Embeddings, Claude Haiku 5.5, Claude Sonnet 5.5 y Claude Opus 5.5 en Amazon Bedrock. Para obtener información sobre la disponibilidad de modelos por región, consulte Soporte de modelos por región de AWS en Amazon Bedrock.
• Una base de conocimientos administrada creada con Amazon Bedrock Managed Knowledge Bases, utilizando Amazon Nova Multimodal Embeddings sobre su corpus de partes (hojas de datos, ICD, descripciones) para recuperación de texto y documentos.
• Un índice de vectores de Amazon S3 sobre sus fotos de partes y recortes de gráficos de hojas de datos, para el camino de consulta de imagen.
• Un gateway de Amazon Bedrock AgentCore con el conector de búsqueda web y un objetivo de base de conocimientos administrada.
• Python 3.10 o posterior y Jupyter para ejecutar los cuadernos.
• Docker, si adapta la receta de implementación en la notebook 03 para hospedar el agente en el runtime de AgentCore.
• El código de ejemplo del repositorio de GitHub.

Guía de solución

Las siguientes secciones describen cada parte del sistema en el orden en que se utiliza una consulta. Comenzamos con el corpus de partes y los agentes especializados, luego cubrimos la routificación, la puntuación determinista, las dos formas en que el asistente utiliza Nova Multimodal Embeddings, la cadena fija que produce documentos formales y la implementación en el runtime de AgentCore.

El ejemplo de código completo es un conjunto de cinco cuadernos de Jupyter en el repositorio de GitHub, y cada cuaderno se ejecuta de forma independiente. Los cuadernos importan desde mei_core, una copia autocontenida de los módulos de agente y herramientas en la misma carpeta, e incluyen sus propios datos de partes, recortes de gráficos y conjunto de consultas de evaluación. Puede ejecutar cada fragmento de este mensaje desde los cuadernos sin otro código de aplicación.

Estructurar el corpus de partes

El conjunto de datos de ejemplo consta de siete ruedas de reacción de un fabricante ficticio (AnyCompany) que abarcan 0,003-5,0 Nms de almacenamiento de momento. Cada parte es una carpeta que empareja datos estructurados con los documentos de origen que un ingeniero lee en realidad, y esta mezcla es lo que hace que el corpus sea multimodal. El archivo specs.json contiene los campos legibles por máquina que impulsan la puntuación determinista, mientras que el ICD, la foto del producto y la página de hoja de datos renderizada llevan el detalle visual y narrativo que dejan fuera los campos estructurados.

data/synthetic-parts-data/rw_rl_0060/
├── specs.json # structured specs + lifecycle fields
├── description.txt # flat text for text retrieval
├── AC-ICD-00068-RW3-0.06-Interface-Control-Document-v2.2.pdf
├── datasheet_page.png # rendered datasheet page
├── datasheet_chart.png # cropped chart region (image-as-query index)
└── photo.png # product image (visual similarity + chart matching)

El archivo specs.json captura tanto las especificaciones de ingeniería como un perfil de ciclo de vida, lo que permite al asistente marcar la obsolescencia y el riesgo de tiempo de entrega junto con la coincidencia de especificaciones.

{
  "name": "AnyCompany RW3 0.06",
  "category": "reaction_wheel",
  "vendor": "AnyCompany",
  "model": "RW3-0.06",
  "momentum_storage_nms": 0.06,
  "max_torque_mnm": 20,
  "mass_g": 235,
  "voltage_v": "28",
  "voltage_range_v": "7.5 to 36",
  "operating_temp_c": "-30 to +70",
  "interface": "RS-422 or Redundant RS-485",
  "qual_standard": "AnyCompany internal (flight heritage qualified)",
  "lifecycle": {
    "lifecycle_status": "Active",
    "production_status": "Full production",
    "estimated_years_to_eol": "10+",
    "last_time_buy": "Not announced",
    "typical_lead_time_weeks": 10,
    "lead_time_risk": "Low",
    "bathtub_region": "Useful life (highly mature)",
    "recommended_screening": "Standard flight acceptance"
  }
}

El campo vendor se establece explícitamente para cada parte. Debido a que los IDs de carpetas de catálogo y los nombres de archivo se reutilizan en varios conjuntos de datos, cada prompt especializado trata el valor vendor estructurado devuelto por get_part_specs como autorizado y no está permitido adivinar un fabricante a partir de un ID, un nombre de archivo, una foto o un resultado de búsqueda web. Tomar el fabricante de los datos estructurados evita que el asistente atribuya una parte al proveedor incorrecto porque el modelo piensa que reconoce el hardware.

Cada carpeta de parte también lleva dos activos que la indexación de solo texto no puede utilizar. La foto del producto alimenta la puntuación de similitud visual, y la página de hoja de datos renderizada lleva tramas de caja de torque y curva de torque que responden a preguntas de rendimiento que no captura ninguna capa de texto OCR. Las incrustaciones multimodales de Amazon Nova incrustan ambos en el mismo espacio vectorial que el texto, por lo que una consulta puede coincidir con un valor de especificación, un párrafo o una trama.

La siguiente muestra muestra cuatro páginas de hoja de datos del corpus, que abarcan tres órdenes de magnitud de almacenamiento de momento.

Figura 2: Cuatro páginas de hoja de datos del corpus de partes, que abarcan tres órdenes de magnitud de almacenamiento de momento

La plantilla se repite en toda la familia, pero la foto del producto y el par de tramas de rendimiento cambian con cada parte. Estas regiones muestran la geometría del alojamiento, el patrón de montaje, el sobre de torque y la potencia de extracción, que los campos de especificaciones no establecen directamente, por lo que los incrustamos junto con el texto.

Definir especialistas con herramientas con ámbito

Cada especialista es un agente Strands con un prompt estrecho y solo las herramientas que necesita. Limitar las herramientas por especialista mantiene un comportamiento predecible, porque el especialista en conocimiento no tiene acceso a las herramientas de descubrimiento de catálogo y el especialista en catálogo no tiene acceso a las herramientas de evaluación. El siguiente código crea el especialista en evaluación.

from strands import Agent

def create_evaluation_specialist() -> Agent:
    """Evaluation Specialist: deterministic spec-by-spec comparison and scoring."""
    return Agent(
        name="evaluation_specialist",
        system_prompt="""You are the Evaluation Specialist. Your job is to run
deterministic, spec-driven comparisons between parts.
...
RULES:
- Your comparisons are deterministic (code, not opinion)
- NEVER recommend or approve --- present evidence and flags; the engineer decides
- Always include the disclaimer that this is evidence only""",
        tools=[score_substitution_fit, compare_parts, visual_similarity_score,
               check_qualification_status, generate_substitution_memo],
        model="us.anthropic.claude-sonnet-5-5",
    )

El siguiente diagrama muestra cómo el planificador enruta una consulta a los especialistas y cuándo el supervisor sintetiza sus resultados. La lista después describe qué hace cada especialista.

Figura 3: Cómo el planificador enruta consultas a especialistas y el supervisor sintetiza resultados

• Catálogo – Descubre partes a través de la búsqueda de la base de conocimientos y el filtrado exhaustivo de especificaciones (kb_search, filter_parts_by_spec, get_part_specs, get_substitution_requirements).
• Evaluación – Puntuación de candidatos de manera determinista y comparación visual de partes (score_substitution_fit, compare_parts, visual_similarity_score, check_qualification_status, generate_substitution_memo).
• Conocimiento – Responde preguntas de hojas de datos y ICD, verifica el estado de fin de vida en vivo y recupera contenido visual (get_part_specs, web_search_eol, retrieve_visual_content).

Utilice un modelo pequeño para la ruta y un modelo grande para la síntesis

La ruta es una tarea de clasificación sin llamadas a herramientas, por lo que no necesita un modelo de razonamiento grande. Un planificador basado en Haiku devuelve un plan de ruta numerado en un par de segundos. El supervisor Opus solo se ejecuta cuando dos o más especialistas contribuyeron, porque sintetizar la respuesta ya completa de un solo especialista agrega alrededor de 8 segundos de latencia sin ganancia de calidad.

# Step 1: Planner (fast model) plans the routing (may be multi-step).
plan_response = planner(planning_prompt)
ordered_specialists = _parse_specialist_plan(str(plan_response))

# Step 2: Execute specialists in sequence, passing context forward
accumulated_context = ""
for spec_name in ordered_specialists:
    specialist = specialists[spec_name]
    specialist_response = specialist(spec_prompt)
    accumulated_context += f"\n[{spec_name.upper()}]: {specialist_response}\n"

# Step 3: Synthesize only when 2+ specialists ran.
if len(ordered_specialists) == 1:
    final_text = steps[0]["response"]
else:
    final_text = str(supervisor(synthesis_prompt))

Dividir el trabajo en tres niveles de modelo coincide con el costo y la latencia de cada etapa. Haiku clasifica la consulta, Sonnet ejecuta las herramientas y Opus escribe la respuesta combinada, que es el paso donde la calidad de la respuesta es más importante.

Mantenga la puntuación determinista

La evaluación de ajuste de especificaciones se ejecuta como código Python ordinario contra un esquema de requisitos escrito a mano. El esquema define las especificaciones críticas y las reglas de tolerancia para cada categoría de componentes, y score_substitution_fit compara cada especificación, cuenta los pases y las banderas, y muestra el riesgo del ciclo de vida. Como el veredicto debe ser reproducible para un paquete de revisión de ingeniería, no se involucra a LLM en este paso.

{
  "categories": {
    "reaction_wheel": {
      "critical_specs": [
        {"field": "voltage_v", "label": "Bus voltage (V)",
         "rule": "match", "required_from_user": true},
        {"field": "mass_g", "label": "Mass (g)",
         "rule": "candidate_lte_reference_within_pct", "tolerance_pct": 20,
         "required_from_user": false}
      ]
    }
  }
}

La herramienta devuelve un veredicto estructurado con un aviso explícito:

return {
    "spec_results": results,  # per-spec pass/flag/review status
    "counts": counts,
    "out_of_tolerance": out_of_tolerance,
    "lifecycle": {...},  # obsolescence and lead-time flags
    "summary": summary,
    "disclaimer": "Evidence only. This tool does not recommend or approve "
                  "a substitution; the engineer decides.",
}

El especialista presenta esta tabla y explica las banderas, pero no puede cambiar un veredicto. El registro de auditoría sigue la misma división de trabajo. Después de cada evaluación, la capa de orquestación lee el historial de llamadas de herramientas del especialista y escribe la entrada de auditoría en sí misma, por lo que la registración no depende de que el modelo recuerde hacerlo.

Calificar la similitud visual con Amazon Nova Multimodal Embeddings

El factor de forma es importante cuando un sustituto debe ajustarse a un soporte existente. La herramienta visual_similarity_score incrusta ambas fotos de piezas con Nova Multimodal Embeddings y calcula la similitud del coseno, luego le pide a Claude que describa las diferencias observables específicas.

def embed_image(image_bytes):
    """Embed one image with Nova MME (IMAGE_RETRIEVAL) -> 1024-d vector."""
    b64 = base64.b64encode(image_bytes).decode('utf-8')
    fmt = 'png' if image_bytes[:8] == b'\x89PNG\r\n\x1a\n' else 'jpeg'
    body = {
        'taskType': 'SINGLE_EMBEDDING',
        'singleEmbeddingParams': {
            'embeddingPurpose': 'IMAGE_RETRIEVAL',
            'embeddingDimension': 1024,
            'image': {'detailLevel': 'STANDARD_IMAGE', 'format': fmt,
                      'source': {'bytes': b64}},
        },
    }
    resp = bedrock.invoke_model(
        modelId='amazon.nova-2-multimodal-embeddings-v1:0',
        body=json.dumps(body), accept='application/json',
        contentType='application/json',
    )
    result = json.loads(resp['body'].read())
    return np.array(result['embeddings'][0]['embedding'])

# cosine similarity of the two photo embeddings
emb_a, emb_b = embed_image(photo_a_bytes), embed_image(photo_b_bytes)
similarity = float(np.dot(emb_a, emb_b) /
                   (np.linalg.norm(emb_a) * np.linalg.norm(emb_b)))

La similitud de incrustación es determinista y reproducible, devolviendo alrededor de 0,84 para dos ruedas de la misma familia de productos y 0,40 para ruedas de diferentes clases. El análisis de visión de Claude explica entonces qué impulsa la diferencia, por ejemplo, observando que una carcasa es aproximadamente el doble del diámetro de la otra y tiene un patrón de montaje de seis agujeros donde la otra tiene cuatro.

Recuperar gráficos y diagramas con dos rutas de recuperación

Las consultas de texto y documento pasan por la base de conocimientos administrada respaldada por Amazon Nova Multimodal Embeddings, enrutada a través de la puerta de enlace AgentCore. La imagen como consulta (subir un gráfico o foto para encontrar contenido coincidente) utiliza un índice de vectores nativo de Amazon S3 llamado directamente desde el agente, porque la API de recuperación de la base de conocimientos administrada no acepta entrada de imagen.

Herramienta retrieve_visual_content del especialista en conocimientos proporciona una interfaz para ambas rutas. Un ingeniero puede pegar una curva de rendimiento de un documento de requisitos en el chat y preguntar qué pieza coincide con ella, o describir el gráfico en una consulta de texto en su lugar.

# Image-as-query: embed the uploaded image with Nova MME, exactly as the
# datasheet crops and photos were embedded at indexing time.
def embed_query_image(image_bytes):
    b64 = base64.b64encode(image_bytes).decode('utf-8')
    fmt = 'png' if image_bytes[:8] == b'\x89PNG\r\n\x1a\n' else 'jpeg'
    body = {'taskType': 'SINGLE_EMBEDDING', 'singleEmbeddingParams': {
        'embeddingPurpose': 'IMAGE_RETRIEVAL', 'embeddingDimension': 1024,
        'image': {'detailLevel': 'STANDARD_IMAGE', 'format': fmt,
                  'source': {'bytes': b64}}}}
    r = bedrock.invoke_model(modelId=NOVA_MME_MODEL_ID, body=json.dumps(body),
                             accept='application/json', contentType='application/json')
    return json.loads(r['body'].read())['embeddings'][0]['embedding']

En la ruta de imagen, la carga se incrusta con Nova Multimodal Embeddings en 1.024 dimensiones utilizando el propósito IMAGE_RETRIEVAL, luego se empareja con el índice de vectores S3:

# Query the native S3 Vectors index and collapse to the best vector per part.
emb = embed_query_image(image_bytes)
s3v = boto3.client('s3vectors', region_name=REGION)
fetch_k = max(top_k * 6, 12)  # each part has several vectors; dedupe below
resp = s3v.query_vectors(
    vectorBucketName=S3_VECTOR_BUCKET, indexName=S3_VECTOR_INDEX,
    queryVector={'float32': emb}, topK=fetch_k,
    returnDistance=True, returnMetadata=True,
)

best = {}
for v in resp.get('vectors', []):
    meta = v.get('metadata', {}) or {}
    pid = meta.get('part_id', '')
    if not pid:
        continue
    sim = 1.0 - v.get('distance', 1.0)  # cosine distance -> similarity
    if pid not in best or sim > best[pid]['score']:
        best[pid] = {'part_id': pid, 'score': sim}
ranked = sorted(best.values(), key=lambda r: r["score"], reverse=True)[:top_k]

Como una pieza contribuye con varios vectores (su foto, la página completa de la hoja de datos y cada región de gráfico recortada), los resultados se deduplican al vector con la mejor puntuación por pieza antes de que lleguen al modelo.

Aprendimos tres lecciones prácticas mientras construíamos las rutas de recuperación:

• Recortar los gráficos antes de indexarlos – Las páginas completas de hojas de datos hacen malas entradas de índice, porque aproximadamente el 90 por ciento de una página (encabezado, tabla de especificaciones, pie de página) es contenido estándar que cada parte comparte, y ese contenido compartido domina la incrustación. Indexar regiones de gráficos recortados junto con la página completa resolvió este problema. En nuestras pruebas, la coincidencia de subida de gráficos pasó de 3 de 7 partes correctas con indexación de página completa a 7 de 7 con recortes de banda de gráficos. Definimos las regiones de recorte como fracciones de la página, lo que mantiene su corrección en todas las resoluciones de hojas de datos.
• Filtrar resultados cuando el ingeniero nombra una parte – La similitud de texto a imagen entre modos cruzados por sí sola no devuelve de manera confiable el gráfico correcto de la parte, porque una imagen de curva de torque no contiene un nombre de parte visible. Cuando el ingeniero nombra una parte específica, la herramienta mantiene solo los resultados del contenido indexado de esa parte, que identifica analizando la carpeta de la parte de la URI de S3 de cada resultado. Como el filtro se ejecuta en la herramienta, funciona sin metadatos personalizados en el índice.
• Registrar cada fallback en la ruta de la imagen – La ruta de la imagen devuelve None en caso de errores y pasa a la recuperación de texto. Ese fallback es razonable, pero significa que una falta de permiso s3vectors:QueryVectors en el rol de ejecución del runtime de AgentCore no genera un error. La imagen como consulta deja de funcionar sin advertencia, y el modelo nombra una parte incorrecta con alta confianza aparente. El problema es fácil de pasar por alto durante el desarrollo, porque las credenciales de desarrollador local suelen tener permisos más amplios que el rol de runtime. La herramienta ahora registra una advertencia explícita S3 Vectors image query FAILED con el bucket, índice y región cada vez que esa ruta pasa a un fallback. Instrumentar cada fallback silencioso en una ruta de recuperación, porque un fallo duro es mucho más fácil de diagnosticar que uno silencioso.

Producir documentos formales con una cadena de especialistas fija

Chat utiliza enrutamiento dinámico porque los especialistas adecuados para una pregunta de forma libre no se pueden conocer de antemano. La Evaluación de Impacto de Integración funciona de manera diferente. Cuando un ingeniero solicita una evaluación de impacto para un par de referencia y candidato, la secuencia requerida ya se conoce, por lo que el servicio compone las mismas funciones de fábrica de especialistas en un orden fijo con una llamada de síntesis con propósito específico.

# 1. Knowledge Specialist --- ICD/datasheet interface detail for both parts
knowledge_text = str(knowledge(knowledge_prompt))

# 2. Evaluation Specialist --- structured field delta + qualification check
evaluation_text = str(evaluation(evaluation_prompt))

# Deterministic structured delta for exact summary stats
comparison = compare_parts(reference_id, candidate_id)

# 3. Supervisor --- synthesize into the six-section IIA document
markdown = str(supervisor(synthesis_prompt))

El documento resultante cubre cambios de interfaz, integración mecánica, integración eléctrica, integración térmica, delta de calificación y impacto de la cadena de suministro. Las secciones narrativas necesitan síntesis de LLM, porque los detalles de pinout y protocolo deben extraerse de la prosa de ICD. Las estadísticas resumidas (coincidencias, diferencias, campos totales) se calculan directamente a partir de la salida de compare_parts, por lo que los números mostrados junto a la narrativa son exactos.

Reclamos de ciclo de vida en datos web en vivo a través de la puerta de enlace de AgentCore

Los datos del catálogo se vuelven obsoletos, por lo que la herramienta web_search_eol del especialista en conocimiento verifica los avisos de fin de vida actuales, los anuncios de los proveedores y los tiempos de entrega a través de una puerta de enlace de AgentCore con el conector de búsqueda web. La puerta de enlace expone el conector como un punto final de protocolo de contexto de modelo (MCP) gobernado. Como la puerta de enlace también maneja la recuperación de la base de conocimientos administrada, puede adjuntar la política y la observabilidad tanto al acceso a datos externos como internos en un solo lugar.

Implementar en tiempo de ejecución de AgentCore

Para producción, se empaqueta el agente como un contenedor ARM64, se lo envía a Amazon Elastic Container Registry (Amazon ECR) y el tiempo de ejecución de AgentCore lo hospeda de forma serverless con aislamiento de sesión y escalado automático. La libreta 03 en el repositorio de GitHub muestra este proceso de implementación como una receta de referencia, cubriendo el Dockerfile, los comandos de compilación y envío, los permisos de ejecución de roles y la política de Cedar. La libreta muestra estos pasos sin ejecutarlos. Su Dockerfile empaqueta código de aplicación que va más allá del ejemplo, así que adapte el layout de su propia aplicación antes de compilar. El siguiente diagrama muestra la ruta de implementación desde el código del agente hasta un punto final de tiempo de ejecución de AgentCore hospedado.

Figura 4: Ruta de implementación desde el código del agente hasta un punto final de tiempo de ejecución de AgentCore hospedado

export TAG=mei-$(date +%Y%m%d-%H%M%S)
export ACCOUNT=<your-account-id>
export ECR=${ACCOUNT}.dkr.ecr.us-east-1.amazonaws.com/mfg-engineering-intelligence

# Build the container for ARM64 (required by AgentCore Runtime)
docker buildx build --platform linux/arm64 -f agentcore/Dockerfile \
  -t mfg-engineering-intelligence:${TAG} --load .

# Push the immutable tag to Amazon ECR
aws ecr get-login-password --region us-east-1 \
  | docker login --username AWS --password-stdin ${ACCOUNT}.dkr.ecr.us-east-1.amazonaws.com
docker tag mfg-engineering-intelligence:${TAG} ${ECR}:${TAG}
docker push ${ECR}:${TAG}

Asigne a cada imagen una etiqueta inmutable. Un tiempo de ejecución que ya ha resuelto el resumen detrás de una etiqueta :latest en movimiento sigue sirviendo la imagen antigua después de enviar una nueva. Los cambios de prompt, router y herramienta requieren una nueva imagen y una nueva versión de tiempo de ejecución para surtir efecto.

El rol de tiempo de ejecución necesita bedrock:InvokeModel, bedrock:Retrieve, bedrock-agentcore:InvokeGateway y s3vectors:QueryVectors para la ruta de consulta de imagen. La política de Cedar mostrada en la libreta 03 codifica las reglas de bucle humano, que requieren una evaluación previa antes de los memorandos y una entrada de registro de auditoría en cada decisión de sustitución. La aplicación hace cumplir estas reglas en su propia lógica hoy en día, y adjuntar la política a un motor de autorización de Cedar es el próximo paso.

Amazon Nova Multimodal Embeddings ahora está disponible en AWS GovCloud (US), lo que es importante para los programas de defensa y aerospaciales sujetos a requisitos de residencia de datos, ITAR y FedRAMP que gobiernan dónde se puede ejecutar una carga de trabajo. Las capacidades de recuperación multimodal y similitud visual en las que depende esta publicación están accesibles dentro de un límite de AWS GovCloud (US). La disponibilidad de Amazon Nova Multimodal Embeddings y las características de Amazon Bedrock AgentCore varía según la región de AWS, así que consulte Servicios de AWS por región antes de planificar una implementación.

Evaluando el asistente

Medimos la calidad de dos maneras, con puntuación en línea continua a través de Evaluaciones de AgentCore, una capacidad de Amazon Bedrock AgentCore, y validación fuera de línea contra conjuntos de consultas curados.

Evaluación en línea de AgentCore

Evaluaciones de Amazon Bedrock AgentCore, disponibles en general desde marzo de 2026, puntuación de trazas de agente utilizando técnicas de LLM-as-a-judge. Lee las trazas de OpenTelemetry que los agentes de Strands ya emiten, por lo que un agente instrumentado no necesita cambios de aplicación para ser evaluado. El servicio ofrece dos modos. La evaluación en línea muestrea continuamente sesiones de producción en vivo, y la evaluación bajo demanda ejecuta pruebas programáticas que se ajustan a una pipeline de integración y entrega continuas (CI/CD).

Usamos la evaluación en línea, con resultados publicados en Amazon CloudWatch para paneles y alarmas. La libreta 05 en el repositorio de GitHub crea una configuración de evaluación en línea y envía consultas de prueba a la runtime implementada para generar sesiones para puntuación.

config = eval_client.create_online_config(
    config_name=CONFIG_NAME,
    agent_id=RUNTIME_ID,
    sampling_rate=SAMPLING_RATE,
    evaluator_list=[
        "Builtin.GoalSuccessRate",
        "Builtin.Correctness",
        "Builtin.Helpfulness",
        "Builtin.Faithfulness",
        "Builtin.ResponseRelevance",
        "Builtin.ToolSelectionAccuracy",
        "Builtin.ToolParameterAccuracy",
    ],
    auto_create_execution_role=True,
    enable_on_create=True,
)

Trece evaluadores integrados se envían con el servicio, junto con el soporte para evaluadores personalizados definidos por una llamada o alojados como una función de AWS Lambda. Habilitamos siete, abarcando los tres niveles de puntuación:

El conjunto de consultas curadas contiene 36 consultas en seis categorías: descubrimiento de catálogos (8), recuperación de conocimientos y CIE (8), cadenas de especialistas múltiples (6), evaluación determinista (5), recuperación de texto a visual (5) y rechazos de seguridad con intervención humana (4) que afirman que el agente se niega a recomendar o aprobar. Cada consulta lleva sus identificadores de partes de catálogo esperados, excepto las consultas de seguridad, donde el resultado esperado es un rechazo.

export AGENTCORE_RUNTIME_ARN=arn:aws:bedrock-agentcore:us-east-1:ACCOUNT:runtime/YOUR_RUNTIME
jupyter lab 05_evaluation.ipynb

Resultados

AgentCore muestrea sesiones en vivo de forma continua, por lo que la puntuación de cada evaluador es un agregado en movimiento que cambia a medida que se acumula el tráfico y el agente cambia. Los siguientes números son una instantánea de la ejecución del conjunto de datos sintéticos. Úselos como línea de base para establecer umbrales de alarmas de CloudWatch y espere que los números de sus propias ejecuciones difieran.

Todas las métricas de calidad de nivel de rastreo obtuvieron una puntuación de 0,95 o superior, y la extracción de parámetros de herramientas estuvo casi perfecta con 0,980. La mejora más notable entre las ejecuciones de evaluación fue la precisión de la selección de herramientas, que aumentó de 0,809 a 0,861. Tres cambios impulsaron el aumento: la consolidación a una sola base de conocimientos administrada, la corrección de un permiso que faltaba en la ruta de consulta de imagen que había causado un fallback silencioso a la búsqueda de texto, y el ajuste de la ruta del planificador para evitar la cadena de especialistas innecesarios.

La tasa de éxito de los objetivos es menor, en 0.892, debido a cómo se diseñó el conjunto de consultas. El conjunto de consultas incluye instrucciones de categoría de seguridad que solicitan al agente que recomiende o apruebe una sustitución. El agente se niega correctamente, pero el evaluador califica una negativa correcta como un objetivo no cumplido. Esperamos este resultado, porque en un sistema con intervención humana el agente no debe aprobar una sustitución por su cuenta.

Adaptar el patrón a su propio catálogo

El código es un patrón reutilizable que funciona para otras categorías de partes, más allá de las ruedas de reacción. Cambiar de dominio requiere tres cambios: reemplazar los datos de las partes (un specs.json, descripción, ICD, página de hoja de datos y foto por parte), editar el esquema de requisitos para definir las especificaciones críticas y reglas de tolerancia de su categoría, y apuntar la base de conocimientos a su corpus de S3. Los agentes, herramientas y motor de puntuación se transfieren sin cambios. Debido a que las herramientas determinísticas en mei_core son funciones de Python simples, una integración de PLM o ERP puede llamar a score_substitution_fit directamente, sin agente en el bucle.

Limpieza

Para evitar cargos continuos, elimine los recursos que creó:

1. Elimine el agente de tiempo de ejecución de AgentCore y su repositorio de Amazon ECR.
2. Elimine el puerta de enlace de AgentCore y sus objetivos de búsqueda web y base de conocimientos.
3. Elimine la configuración de evaluación en línea y las alarmas de CloudWatch que creó.
4. Elimine la base de conocimientos administrada y el índice de vectores de S3.
5. Elimine el bucket de S3 que contiene el corpus de partes.

Conclusión

En esta publicación, mostramos cómo construir un asistente de ingeniería de multiagente que reemplaza la investigación manual de sustitución de partes con la ensambladura automatizada de evidencia. La arquitectura empareja Amazon Nova Multimodal Embeddings, que maneja la puntuación de similitud visual y la recuperación de gráficos que los sistemas de solo texto pasan por alto, con Amazon Bedrock AgentCore, que proporciona el andamiaje de producción de hosting de runtime, recuperación gobernada por Gateway y búsqueda web, y evaluaciones de calidad. Tres opciones de diseño son las más importantes. El código determinista produce cada veredicto de aprobado/reprobado, cada tarea se ejecuta en el nivel de modelo más pequeño de los tres que lo maneja bien, y solo el ingeniero puede aprobar una sustitución.

Para empezar, clona el repositorio de GitHub, ejecuta los cuadernos con tu propia cuenta de AWS y reemplaza el catálogo de partes y el esquema de requisitos con los tuyos. Para profundizar en los fundamentos de recuperación, lee Inteligencia de fabricación con Amazon Nova Multimodal Embeddings y Guía práctica para Amazon Nova Multimodal Embeddings. Para patrones de agentes de producción, consulta la documentación de Amazon Bedrock AgentCore y el SDK de Strands Agents.

Acerca de los autores