Agentic Engineering-Intelligenz mit Amazon Nova Multimodal Embeddings und Amazon Bedrock AgentCore

Wenn eine qualifizierte Luft- und Raumfahrtkomponente obsolet wird oder lange Lieferzeiten aufweist, verbringt ein Ingenieur Tage damit, Spezifikationen in Anbieter-Datenblättern, Interface-Control-Dokumenten (ICDs) und Qualifizierungsnachweisen abzugleichen, bevor er eine Ersatzteil-Begründung zur Prüfung dokumentiert. Ein falscher Ersatz bei einer flugkritischen Komponente kann einen Fehlschlag der Mission verursachen, doch die Nachweiskette hinter jeder Entscheidung ist oft über E-Mails und undokumentiertes Institutional Knowledge verteilt, sodass es kein formales, wiederholbares Paket gibt, das ein Prüfer kontrollieren kann.

Ein früherer Beitrag, Manufacturing intelligence with Amazon Nova Multimodal Embeddings, zeigte, wie das Modell Antworten findet, die in technischen Diagrammen, thermischen Plots und Datenblatt-Charts verborgen sind und die nur auf Text basierende Pipelines übersehen. Dieser Beitrag knüpft an diese Retrieval-Arbeit an und setzt diese Fähigkeiten in ein Multi-Agenten-System ein, das Ersatznachweise zusammenstellt – vom Retrieval bis zu einem entworfenen Assessment.

In diesem Beitrag zeigen wir, wie man einen Multi-Agent-Engineering-Assistenten baut, der das manuelle Abgleichen bei der Bewertung von Ersatzteilen reduziert, indem man Amazon Bedrock AgentCore, Amazon Nova Multimodal Embeddingsund das Open-Source- Strands Agents SDKverwendet. Ein Planner verteilt Arbeiten an drei spezialisierte Agenten, die eine multimodale Wissensbasis durchsuchen, Kandidaten anhand deterministischer Toleranzregeln bewerten, Teilefotos vergleichen und Lebenszyklus-Aussagen mit Live-Webdaten absichern. Der Ingenieur bleibt durchgehend der Entscheidungsträger, da das System Nachweise zusammenstellt und Dokumente entwirft, ohne jemals selbst einen Ersatz zu genehmigen.

Lösungsübersicht

Der Assistent basiert auf einer Designregel: Der Ingenieur trifft jede Entscheidung, und das System stellt die Nachweise dafür zusammen. Diese Regel bestimmt, wo wir große Sprachmodelle (LLMs) einsetzen und wo stattdessen deterministischer Code zum Einsatz kommt.

Drei Säulen definieren die Architektur:

• Deterministische Spec-Fit-Bewertung – In Python geschriebener Toleranzregel-Code bewertet jeden Kandidaten gegen das Referenzteil und die vom Ingenieur angegebenen Anforderungen. Da dieselben Eingaben konsistent dieselben Pass/Flag-Ergebnisse liefern, können die Ergebnisse in ein formales Engineering-Review einfließen.
• Multi-Agenten-Orchestrierung – Ein leichtgewichtiger Planner leitet jede Anfrage an einen oder mehrere von drei spezialisierten Agenten (Catalog, Evaluation, Knowledge) weiter, und ein Supervisor synthetisiert deren Ergebnisse nur, wenn mehr als ein Spezialist beteiligt war. Komplexe Fragen wie „Prüfe, ob dieses Rad das Lebensende erreicht, finde Alternativen und bewerte sie“ verketten alle drei Spezialisten in Sequenz.
• Human-in-the-loop-Entscheidung – Das System entwirft Begründungs-Memos und Integration Impact Assessments für das Engineering-Review, empfiehlt oder genehmigt jedoch keinen Ersatz. Jede Bewertung schreibt außerdem einen Audit-Trail-Eintrag ausgerichtet an AS9100 Abschnitte 8.4 und 8.5.6.

Das folgende Diagramm zeigt die Architektur.

Abbildung 1: Architektur des Multi-Agent-Engineering-Assistenten auf Amazon Bedrock AgentCore

Amazon Bedrock AgentCore ist eine Plattform zum Erstellen, Verbinden und Optimieren von Agenten in großem Maßstab, mit jedem Framework oder Modell. In dieser Lösung fließen Chat-Anfragen aus der Anwendung des Ingenieurs in einen auf dem AgentCore runtime gehosteten Multi-Agenten-Graphen: ein Planner (Claude Haiku 5.5) erzeugt einen Routing-Plan, Spezialisten (Claude Sonnet 5.5) führen ihre Tools aus, und ein Supervisor (Claude Opus 5.5) synthetisiert deren Ergebnisse, wenn mehr als ein Spezialist ausgeführt wurde. Die Spezialisten rufen Daten aus einer verwalteten Wissensbasis ab, die wir mit Amazon Bedrock Managed Knowledge Bases unter Verwendung von Amazon Nova Multimodal Embeddings erstellt haben und die über ein AgentCore Gateway, eine Funktion von Amazon Bedrock AgentCore, zusammen mit dem Web Search-Connector für Live-Webdaten geroutet wird. Für Bild-als-Anfrage (Hochladen eines Diagramms zur Identifikation eines Teils) ruft der Agent einen nativen Amazon S3 Vectors Index direkt auf, da die Retrieval-API der verwalteten Wissensbasis keine Bildeingaben akzeptiert. Amazon S3 Vectors ist eine Funktion von Amazon Simple Storage Service (Amazon S3). Eine separate feste Kette (Knowledge, dann Evaluation, dann Supervisor) erzeugt das formale Integration Impact Assessment (IIA)-Dokument.

Amazon Nova Multimodal Embeddings erscheint in zwei unterschiedlichen Rollen:

1. Multimodales Retrieval – Datenblätter, ICDs und Leistungsdiagramme werden mit Nova Multimodal Embeddings eingebettet, sodass Text- und visuelle Inhalte einen gemeinsamen semantischen Raum teilen. Ein Ingenieur kann „torque curve for the 0.06 Nms wheel“ eingeben oder ein Diagrammbild hochladen, und das Retrieval liefert das passende Diagramm mit Quellenangabe zurück.
2. Visuelle Ähnlichkeitsbewertung – Wenn zwei Kandidatenteile verglichen werden, erzeugt Nova Multimodal Embeddings eine quantitative Kosinusähnlichkeit zwischen ihren Fotos, und Claude analysiert die spezifischen physischen Unterschiede (Befestigungsmuster, Anschlussposition, Gehäusegeometrie). Der Score liefert unterstützende Belege für den deterministischen Spec-Vergleich, auf dem das Fit-Urteil basiert.

Voraussetzungen

Zum Nachvollziehen benötigen Sie:

• Ein AWS-Konto mit Zugriff auf Amazon Bedrock in der AWS-Region US East (N. Virginia).
• Modellzugriff auf Amazon Nova Multimodal Embeddings, Claude Haiku 5.5, Claude Sonnet 5.5 und Claude Opus 5.5 in Amazon Bedrock. Zur Modellverfügbarkeit nach Region siehe Model support by AWS Region in Amazon Bedrock.
• Eine verwaltete Knowledge Base, die mit Amazon Bedrock Managed Knowledge Bases erstellt wurde und Amazon Nova Multimodal Embeddings über Ihren Teile-Korpus (Datenblätter, ICDs, Beschreibungen) für Text- und Dokumentsuche verwendet.
• Einen Amazon S3 Vectors-Index über Ihre Teile-Fotos und Datenblatt-Diagrammausschnitte für den Bild-als-Abfrage-Pfad.
• Ein Amazon Bedrock AgentCore Gateway mit dem Web-Search-Connector und einem verwalteten Knowledge-Base-Ziel.
• Python 3.10 oder höher sowie Jupyter zum Ausführen der Notebooks.
• Docker, falls Sie das Deployment-Rezept in Notebook 03 anpassen, um den Agenten auf AgentCore runtime zu hosten.
• Der Beispielcode aus dem GitHub-Repository.

Lösungsdurchlauf

Die folgenden Abschnitte beschreiben jeden Teil des Systems in der Reihenfolge, in der eine Abfrage ihn verwendet. Wir beginnen mit dem Teile-Korpus und den spezialisierten Agenten, behandeln dann Routing, deterministisches Scoring, die beiden Arten, wie der Assistent Nova Multimodal Embeddings nutzt, die feste Kette, die formale Dokumente erzeugt, und das Deployment auf AgentCore runtime.

Das vollständige Codebeispiel ist eine Sammlung von fünf Jupyter-Notebooks im GitHub-Repository, und jedes Notebook läuft eigenständig. Die Notebooks importieren aus mei_core, einer in sich geschlossenen Kopie der Agenten- und Tool-Module im selben Ordner, und sie enthalten ihre eigenen Teiledaten, Diagrammausschnitte und Auswertungsabfragen. Sie können jeden Snippet in diesem Beitrag aus den Notebooks ausführen, ohne weiteren Anwendungscode.

Den Teile-Korpus strukturieren

Der Beispieldatensatz besteht aus sieben Reaktionsschwänzen eines fiktiven Herstellers (AnyCompany) mit einem Impulsspeicher von 0.003–5.0 Nms. Jedes Teil ist ein Ordner, der strukturierte Daten mit den Quelldokumenten kombiniert, die ein Ingenieur tatsächlich liest, und genau diese Mischung macht den Korpus multimodal. Die specs.json -Datei enthält die maschinenlesbaren Felder, die das deterministische Scoring antreiben, während das ICD, das Produktfoto und die gerenderte Datenblattseite die visuellen und narrativen Details tragen, die die strukturierten Felder auslassen.

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)

Die specs.json -Datei erfasst sowohl die technischen Spezifikationen als auch ein Lebenszyklusprofil, was es dem Assistenten ermöglicht, Obsoleszenz- und Lieferzeitenrisiken neben der Spec-Eignung zu kennzeichnen.

{
  "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"
  }
}

Das vendor -Feld ist für jedes Teil ausdrücklich angegeben. Da Katalogordner-IDs und Dateinamen über Datensätze hinweg wiederverwendet werden, behandelt jeder Spezialisten-Prompt den strukturierten vendor -Wert, der von get_part_specs zurückgegeben wird, als maßgeblich und darf den Hersteller nicht aus einer ID, einem Dateinamen, einem Foto oder einem Websuchergebnis raten. Die Übernahme des Herstellers aus strukturierten Daten verhindert, dass der Assistent ein Teil dem falschen Lieferanten zuordnet, weil das Modell die Hardware zu erkennen glaubt.

Jeder Teile-Ordner enthält außerdem zwei Assets, die eine rein textbasierte Indizierung nicht nutzen kann. Das Produktfoto dient der visuellen Ähnlichkeitsbewertung, und die gerenderte Datenblattseite enthält Drehmomentbox- und Drehmomentkurvendiagramme, die Leistungsfragen beantworten, die keine OCR-Textebene erfasst. Amazon Nova Multimodal Embeddings bettet beide in denselben Vektorraum wie den Text ein, sodass eine Abfrage einen Spec-Wert, einen Absatz oder ein Diagramm finden kann.

Das folgende Beispiel zeigt vier Datenblattseiten aus dem Korpus, die drei Größenordnungen des Impulsspeichers umspannen.

Abbildung 2: Vier Datenblattseiten aus dem Teile-Korpus, die drei Größenordnungen des Impulsspeichers umspannen

Die Vorlage wiederholt sich über die Produktfamilie hinweg, aber das Produktfoto und das Paar von Leistungsdiagrammen ändern sich bei jedem Bauteil. Diese Bereiche zeigen die Gehäusegeometrie, das Befestigungsmuster, den Drehmomentbereich und die Leistungsaufnahme, die die Spezifikationsfelder nicht direkt angeben, daher betten wir sie zusammen mit dem Text ein.

Spezialisten mit scoped Tools definieren

Jeder Spezialist ist ein Strands-Agent mit einem eng gefassten Prompt und nur den Tools, die er benötigt. Die Werkzeuge pro Spezialist zu beschränken, hält das Verhalten vorhersagbar, denn der Knowledge-Spezialist hat keinen Zugriff auf die Catalog-Discovery-Tools und der Catalog-Spezialist hat keinen Zugriff auf die Evaluation-Tools. Der folgende Code erzeugt den Evaluation-Spezialisten.

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",
    )

Das folgende Diagramm zeigt, wie der Planner eine Anfrage an die Spezialisten weiterleitet und wann der Supervisor ihre Ergebnisse zusammenführt. Die danach folgende Liste beschreibt, was jeder Spezialist tut.

Abbildung 3: Wie der Planner Anfragen an Spezialisten weiterleitet und wann der Supervisor Ergebnisse zusammenführt

• Catalog – Findet Bauteile durch Knowledge-Base-Suche und erschöpfende Spezifikationsfilterung (kb_search, filter_parts_by_spec, get_part_specs, get_substitution_requirements).
• Evaluation – Bewertet Kandidaten deterministisch und vergleicht Teile visuell (score_substitution_fit, compare_parts, visual_similarity_score, check_qualification_status, generate_substitution_memo).
• Knowledge – Beantwortet Fragen aus Datenblättern und ICDs, prüft den aktuellen End-of-Life-Status und ruft visuelle Inhalte ab (get_part_specs, web_search_eol, retrieve_visual_content).

Nutzen Sie ein kleines Modell für das Routing und ein großes Modell für die Synthese

Routing ist eine Klassifikationsaufgabe ohne Tool-Aufrufe, daher benötigt es kein großes Reasoning-Modell. Ein Haiku-basierter Planner liefert in wenigen Sekunden einen nummerierten Routing-Plan. Der Opus-Supervisor läuft nur, wenn zwei oder mehr Spezialisten beigetragen haben, denn die Synthese der bereits vollständigen Antwort eines einzelnen Spezialisten kostet etwa 8 Sekunden Latenz ohne Qualitätsvorteil.

# 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))

Die Aufteilung der Arbeit auf drei Modellebenen passt Kosten und Latenz an jede Phase an. Haiku klassifiziert die Anfrage, Sonnet führt die Tools aus, und Opus schreibt die kombinierte Antwort – der Schritt, in dem die Antwortqualität am wichtigsten ist.

Halten Sie die Bewertung deterministisch

Die Spec-Fit-Bewertung läuft als gewöhnlicher Python-Code gegen ein handgeschriebenes Requirements-Schema. Das Schema definiert die kritischen Spezifikationen und Toleranzregeln für jede Komponentenkategorie, und score_substitution_fit vergleicht jede Spezifikation, zählt Bestehens- und Warnmarkierungen und zeigt Lifecycle-Risiken auf. Da das Urteil für ein Engineering-Review-Paket reproduzierbar sein muss, ist in diesem Schritt kein LLM beteiligt.

{
  "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}
      ]
    }
  }
}

Das Tool liefert ein strukturiertes Urteil mit einem ausdrücklichen Haftungsausschluss:

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.",
}

Der Spezialist präsentiert diese Tabelle und erklärt die Markierungen, kann ein Urteil aber nicht ändern. Der Audit-Trail folgt derselben Arbeitsteilung. Nach jeder Bewertung liest die Orchestrierungsschicht die Tool-Call-Historie des Spezialisten und schreibt den Audit-Eintrag selbst, sodass das Logging nicht davon abhängt, dass sich das Modell daran erinnert.

Bewerten Sie visuelle Ähnlichkeit mit Amazon Nova Multimodal Embeddings

Die Bauform ist wichtig, wenn ein Ersatzteil in eine vorhandene Halterung passen muss. Das visual_similarity_score Tool berechnet Embeddings beider Teilefotos mit Nova Multimodal Embeddings und bestimmt die Kosinusähnlichkeit, dann bittet es Claude, die spezifischen beobachtbaren Unterschiede zu beschreiben.

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)))

Die Embedding-Ähnlichkeit ist deterministisch und reproduzierbar und liefert etwa 0.84 für zwei Räder derselben Produktfamilie und 0.40 für Räder unterschiedlicher Klassen. Claudes Vision-Analyse erklärt dann, was den Unterschied verursacht, zum Beispiel dass ein Gehäuse etwa den doppelten Durchmesser des anderen hat und ein sechsteiliges Befestigungsmuster aufweist, während das andere vier hat.

Rufen Sie Diagramme und Schemata über zwei Retrieval-Pfade ab

Text- und Dokumentabfragen laufen über die verwaltete Wissensbasis, die auf Amazon Nova Multimodal Embeddings basiert und über das AgentCore Gateway geroutet wird. Bild-als-Abfrage (das Hochladen eines Diagramms oder Fotos, um passende Inhalte zu finden) verwendet einen nativen Amazon S3 Vectors Index, der direkt vom Agenten aufgerufen wird, da die Retrieval-API der verwalteten Wissensbasis keine Bildeingabe akzeptiert.

Das retrieve_visual_content Tool des Knowledge-Spezialisten bietet eine einzige Schnittstelle für beide Pfade. Ein Ingenieur kann eine Leistungskurve aus einem Anforderungsdokument in den Chat einfügen und fragen, welches Teil dazu passt, oder das Diagramm stattdessen in einer Textabfrage beschreiben.

# 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']

Auf dem Bildpfad wird der Upload mit Nova Multimodal Embeddings in 1,024 Dimensionen eingebettet, dem IMAGE_RETRIEVAL Zweck entsprechend, und dann gegen den S3 Vectors Index abgeglichen:

# 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]

Da ein Teil mehrere Vektoren beiträgt (sein Foto, die gesamte Datenblattseite und jede zugeschnittene Diagrammregion), werden die Ergebnisse auf den bestbewerteten Vektor pro Teil dedupliziert, bevor sie das Modell erreichen.

Beim Aufbau der Retrieval-Pfade haben wir drei praktische Lektionen gelernt:

• Diagramme vor der Indizierung zuschneiden – Ganze Datenblattseiten sind schlechte Indexeinträge, denn rund 90 Prozent einer Seite (Kopfzeile, Spezifikationstabelle, Fußzeile) sind Standardinhalte, die jedes Teil teilt, und dieser gemeinsame Inhalt dominiert das Embedding. Die Indizierung zugeschnittener Diagrammregionen neben der ganzen Seite löste das Problem. In unseren Tests stieg die Trefferquote bei Diagramm-Uploads von 3 von 7 Teilen bei Indizierung ganzer Seiten auf 7 von 7 mit Diagrammband-Zuschnitten. Wir definieren die Zuschnitt-Regionen als Bruchteile der Seite, sodass sie über Datenblatt-Auflösungen hinweg korrekt bleiben.
• Ergebnisse filtern, wenn der Ingenieur ein Teil benennt – Kreuzmodale Text-zu-Bild-Ähnlichkeit allein liefert das Diagramm des richtigen Teils nicht zuverlässig, weil ein Drehmomentkurven-Bild keinen sichtbaren Teilnamen enthält. Wenn der Ingenieur ein bestimmtes Teil benennt, behält das Tool nur Ergebnisse aus dem indizierten Inhalt dieses Teils, das es durch das Parsen des Teilordners aus dem S3-URI jedes Ergebnisses identifiziert. Da der Filter im Tool läuft, funktioniert er ohne benutzerdefinierte Metadaten im Index.
• Jeden Fallback auf dem Bildpfad protokollieren – Der Bildpfad gibt bei Fehlern None zurück und fällt auf Textretrieval zurück. Dieser Fallback ist vernünftig, bedeutet aber, dass eine fehlende s3vectors:QueryVectors Berechtigung auf der AgentCore-Runtime-Ausführungsrolle keinen Fehler auslöst. Bild-als-Abfrage hört ohne Warnung auf zu funktionieren, und das Modell nennt dann mit hoher scheinbarer Zuversicht ein falsches Teil. Das Problem ist in der Entwicklung leicht zu übersehen, weil lokale Entwickler-Zugangsdaten meist umfassendere Berechtigungen haben als die Runtime-Rolle. Das Tool protokolliert nun ausdrücklich S3 Vectors image query FAILED Warnung mit Bucket, Index und Region ausgeben, wann immer dieser Pfad zurückfällt. Instrumentieren Sie jeden stillen Fallback in einem Abrufpfad, denn ein harter Fehler lässt sich viel leichter diagnostizieren als ein stiller.

Erstellen Sie formale Dokumente mit einer festen Spezialistenkette

Chat verwendet dynamisches Routing, weil die richtigen Spezialisten für eine Freitextfrage nicht im Voraus bekannt sein können. Die Integration Impact Assessment funktioniert anders. Wenn ein Ingenieur eine Impact-Bewertung für ein Referenz- und Kandidatenpaar anfordert, ist die erforderliche Sequenz bereits bekannt, daher setzt der Service dieselben Spezialisten-Factory-Funktionen in fester Reihenfolge mit einem eigens dafür entwickelten Synthesis-Prompt zusammen.

# 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))

Das daraus resultierende Dokument deckt Schnittstellenänderungen, mechanische Integration, elektrische Integration, thermische Integration, Qualifikationsdelta und Supply-Chain-Auswirkungen ab. Die narrativen Abschnitte benötigen eine LLM-Synthese, weil die Pinout- und Protokolldetails aus ICD-Prosa extrahiert werden müssen. Die Zusammenfassungsstatistiken (Übereinstimmungen, Unterschiede, Gesamtzahl der Felder) werden direkt aus compare_parts der Ausgabe berechnet, sodass die neben dem Bericht angezeigten Zahlen exakt sind.

Lebenszyklusangaben durch AgentCore Gateway mit Live-Webdaten untermauern

Katalogdaten werden veraltet, daher prüft das web_search_eol -Tool des Knowledge-Spezialisten aktuelle End-of-Life-Hinweise, Herstellerankündigungen und Lieferzeiten über ein AgentCore Gateway mit dem Web Search Connector. Das Gateway stellt den Connector als governed Model Context Protocol (MCP)-Endpoint bereit. Da das Gateway auch managed knowledge base retrieval abwickelt, können Sie Policy und Observability für den Zugriff auf externe und interne Daten an einem Ort zuordnen.

Bereitstellung in der AgentCore runtime

Für die Produktion verpacken Sie den Agenten als ARM64-Container, pushen ihn zu Amazon Elastic Container Registry (Amazon ECR), und die AgentCore runtime hostet ihn serverless mit Session-Isolation und Auto Scaling. Notebook 03 im GitHub-Repository führt Sie durch diese Bereitstellung als Referenzrezept und behandelt das Dockerfile, die Build- und Push-Befehle, die Berechtigungen der Ausführungsrolle und die Cedar-Policy. Das Notebook zeigt diese Schritte, ohne sie auszuführen. Sein Dockerfile verpackt Anwendungscode, der über das Beispiel hinausgeht, passen Sie es also an Ihr eigenes Anwendungslayout an, bevor Sie bauen. Das folgende Diagramm zeigt den Bereitstellungspfad vom Agentencode zu einem gehosteten AgentCore-runtime-Endpoint.

Abbildung 4: Bereitstellungspfad vom Agentencode zu einem gehosteten AgentCore-runtime-Endpoint

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}

Geben Sie jedem Image ein unveränderliches Tag. Eine Runtime, die den Digest hinter einem beweglichen :latest -Tag bereits aufgelöst hat, bedient weiterhin das alte Image, nachdem Sie ein neues gepusht haben. Prompt-, Router- und Tool-Änderungen erfordern alle ein neues Image und eine neue Runtime-Version, um wirksam zu werden.

Die Runtime-Rolle benötigt bedrock:InvokeModel, bedrock:Retrieve, bedrock-agentcore:InvokeGatewayund s3vectors:QueryVectors für den Image-as-Query-Pfad. Die in Notebook 03 gezeigte Cedar-Policy kodiert die Human-in-the-Loop-Regeln und verlangt eine vorherige Evaluierung vor Memos und einen Audit-Log-Eintrag bei jeder Substitutionsentscheidung. Die Anwendung erzwingt diese Regeln heute in ihrer eigenen Logik; das Anbinden der Policy an eine Cedar-Authorization-Engine ist der nächste Schritt.

Amazon Nova Multimodal Embeddings ist jetzt in AWS GovCloud (US)verfügbar, was für Luft- und Raumfahrt- und Verteidigungsprogramme relevant ist, die Datenspeicherungs-, ITAR- und FedRAMP-Anforderungen unterliegen, die regeln, wo eine Workload laufen darf. Die multimodalen Retrieval- und visuellen Similarity-Funktionen, von denen dieser Beitrag abhängt, sind innerhalb einer AWS GovCloud (US)-Grenze erreichbar. Die Verfügbarkeit von Amazon Nova Multimodal Embeddings und Amazon Bedrock AgentCore-Funktionen variiert je nach AWS-Region, prüfen Sie daher AWS Services by Region , bevor Sie eine Bereitstellung planen.

Bewertung des Assistenten

Wir messen die Qualität auf zwei Arten: mit kontinuierlichem Online-Scoring durch AgentCore Evaluations, eine Capability von Amazon Bedrock AgentCore, und mit Offline-Validierung gegen kuratierte Query-Sets.

AgentCore Online-Evaluierung

Amazon Bedrock AgentCore Evaluations, ist seit März 2026 allgemein verfügbarund bewertet Agent-Traces mit LLM-as-a-judge -Techniken. Es liest die OpenTelemetry-Traces, die Strands-Agenten bereits ausgeben, sodass ein instrumentierter Agent ohne Anwendungsänderungen evaluiert werden kann. Der Service bietet zwei Modi. Die Online-Evaluierung samplt kontinuierlich laufende Produktionssessions, und die On-Demand-Evaluierung führt programmatische Tests aus, die in eine Continuous Integration und Continuous Delivery (CI/CD)-Pipeline passen.

Wir nutzen die Online-Evaluierung, mit Ergebnissen, die für Dashboards und Alarme in Amazon CloudWatch veröffentlicht werden. Notebook 05 im GitHub-Repository erstellt eine Online-Evaluierungskonfiguration und sendet Testanfragen an die bereitgestellte Runtime, um Sessions für die Bewertung zu erzeugen.

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,
)

Der Service liefert dreizehn integrierte Evaluatoren mit, alongside Unterstützung für benutzerdefinierte Evaluatoren, die durch einen Prompt definiert oder als AWS Lambda-Funktion gehostet werden. Wir aktivieren sieben, die alle drei Scoring-Ebenen abdecken:

Der kuratierte Abfragesatz umfasst 36 Abfragen in sechs Kategorien: Katalogsuche (8), Knowledge- und ICD-Abruf (8), Multi-Spezialisten-Ketten (6), deterministische Bewertung (5), Text-zu-Visual-Abruf (5) und Sicherheitsverweigerungen mit menschlicher Beteiligung (4), bei denen der Agent die Empfehlung oder Genehmigung verweigern muss. Jede Abfrage enthält ihre erwarteten Katalogteil-IDs, außer bei den Sicherheitsabfragen, bei denen das erwartete Ergebnis eine Verweigerung ist.

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

Ergebnisse

AgentCore erfasst laufend Live-Sitzungen als Stichproben, sodass der Score jedes Evaluators ein gleitender Aggregatwert ist, der sich verschiebt, wenn Traffic anfällt und sich der Agent ändert. Die folgenden Zahlen sind ein Schnappschuss aus dem Lauf des synthetischen Datensatzes. Verwenden Sie sie als Basislinie für das Festlegen von CloudWatch-Alarm-Schwellenwerten und rechnen Sie damit, dass die Zahlen Ihrer eigenen Läufe abweichen.

Alle Metriken auf Trace-Ebene erzielten einen Score von 0.95 oder höher, und die Tool-Parameter-Extraktion war mit 0.980 nahezu perfekt. Die bemerkenswerteste Verbesserung zwischen den Bewertungsläufen war die Genauigkeit der Tool-Auswahl, die von 0.809 auf 0.861 stieg. Drei Änderungen brachten den Gewinn: die Konsolidierung auf eine einzige verwaltete Knowledge Base, die Behebung einer fehlenden Berechtigung auf dem Pfad „Bild als Abfrage“, der zu stillen Fallback auf Textsuche geführt hatte, und die Verschärfung des Routings des Planers, um unnötige Verkettungen von Spezialisten zu vermeiden.

Die Zielerreichungsrate ist mit 0.892 niedriger, und zwar aufgrund der Konzeption des Abfragesatzes. Der Abfragesatz enthält Prompts der Sicherheitskategorie, die den Agenten auffordern, eine Substitution zu empfehlen oder zu genehmigen. Der Agent verweigert korrekt, aber der Evaluator bewertet eine korrekte Verweigerung als nicht erreichte Ziel. Dieses Ergebnis erwarten wir, weil in einem System mit menschlicher Beteiligung der Agent eine Substitution nicht selbst genehmigen darf.

Passen Sie das Muster an Ihren eigenen Katalog an

Der Code ist ein wiederverwendbares Muster, das auch für andere Bauteilkategorien jenseits von Reaktionsrädern funktioniert. Der Wechsel der Domäne erfordert drei Änderungen: die Bauteildaten ersetzen (pro Bauteil ein specs.json, Beschreibung, ICD, Datenblattseite und Foto), das Anforderungsschema bearbeiten, um die kritischen Spezifikationen und Toleranzregeln Ihrer Kategorie zu definieren, und die Wissensbasis auf Ihren S3-Korpus verweisen lassen. Die Agents, Tools und die Scoring-Engine bleiben unverändert übernommen. Da die deterministischen Tools in mei_core einfache Python-Funktionen sind, kann eine PLM- oder ERP-Integration score_substitution_fit direkt aufrufen, ganz ohne Agent in der Schleife.

Aufräumen

Um laufende Kosten zu vermeiden, löschen Sie die von Ihnen erstellten Ressourcen:

1. Löschen Sie den AgentCore runtime agent und sein Amazon ECR repository.
2. Löschen Sie das AgentCore Gateway und seine Web Search- und Knowledge-Base-Ziele.
3. Löschen Sie die online evaluation configuration und die von Ihnen erstellten CloudWatch alarms .
4. Löschen Sie die managed knowledge base und den S3 Vectors index.
5. Löschen Sie den S3 bucket , der das Bauteilkorpus enthält.

Fazit

In diesem Beitrag haben wir gezeigt, wie man einen Multi-Agent-Engineering-Assistenten baut, der die manuelle Recherche zu Bauteilsubstitutionen durch automatisierte Belegzusammenstellung ersetzt. Die Architektur kombiniert Amazon Nova Multimodal Embeddings, das visuelle Ähnlichkeitsbewertungen und Diagrammabrufe übernimmt, die rein textbasierte Systeme verpassen, mit Amazon Bedrock AgentCore, das das Produktionsgerüst aus Runtime-Hosting, Gateway-geregelter Suche und Websuche sowie Qualitätsbewertungen bereitstellt. Drei Designentscheidungen sind am wichtigsten: Deterministischer Code liefert jedes Bestehen/Nicht-Bestehen-Urteil, jede Aufgabe läuft auf dem kleinsten der 3 Modellebenen, das sie gut bewältigt, und nur der Ingenieur kann eine Substitution genehmigen.

Um loszulegen, klonen Sie das GitHub repository, führen Sie die Notebooks mit Ihrem eigenen AWS-Konto aus und ersetzen Sie den Bauteilkatalog und das Anforderungsschema durch Ihre eigenen. Um tiefer in die Grundlagen der Suche einzusteigen, lesen Sie Manufacturing intelligence with Amazon Nova Multimodal Embeddings und A practical guide to Amazon Nova Multimodal Embeddings. Produktionsreife Agent-Muster finden Sie in der Amazon Bedrock AgentCore documentation und das Strands Agents SDK.

Über die Autoren