Aufbau einer produktionsreifen, robusten agentenbasierten KI-Architektur

vor 4 Stunden

8 Min. Lesezeit

Die Evolution der Unternehmens-KI

Unternehmen erleben derzeit einen bedeutenden Paradigmenwechsel im Umgang mit künstlicher Intelligenz. Die erste Welle der KI-Einführung in Unternehmen konzentrierte sich stark auf generative KI-Chatbots – reaktive Systeme, die ständige menschliche Eingaben benötigten, um statische Texte, Code oder Bilder zu generieren. Obwohl diese isolierten Systeme für die individuelle Produktivität wertvoll sind, eignen sie sich nicht für die Bewältigung komplexer, funktionsübergreifender Geschäftsprozesse.

Die Branche bewegt sich rasant in Richtung agentenbasierter KI . Agentenbasierte Systeme sind zielorientierte, semi-autonome oder vollständig autonome Software-Einheiten, die in der Lage sind, mehrstufige Arbeitsabläufe zu planen, spezialisierte digitale Werkzeuge einzusetzen, Hindernisse zu überwinden und Aufgaben sicher in Unternehmensumgebungen auszuführen.

Es hat sich jedoch ein Paradoxon herausgebildet: Während rund 60 % der Unternehmen massiv in agentenbasierte KI-Systeme investieren, verfügen nur 15 % über die notwendige Datengrundlage, um deren Erfolg zu gewährleisten . Die meisten Organisationen stecken in einer kostspieligen Schleife fest, in der sie veraltete Datenbestände manuell bereinigen müssen, nur um einfache Machbarkeitsstudien durchführen zu können.

Dieser Leitfaden liefert die ultimativen strategischen, architektonischen und codebezogenen Blaupausen für den Aufbau einer produktionsreifen, hochverfügbaren Agentic-AI-Architektur. Wir zeigen, wie Sie selbst bei stark fragmentierter oder unstrukturierter Dateninfrastruktur massive Unternehmenseffizienz erzielen können, indem Sie eine hybride Kombination aus AWS-Cloud-nativen Primitiven und Open-Source-Workflow-Netzwerken (LangGraph, Temporal und dem Model Context Protocol) nutzen.

Der strategische Kern: Warum eine agentenbasierte KI-Strategie?

Der Einsatz von KI ohne eine gezielte, systemische Strategie führt zu isolierten technologischen Schulden. Eine unternehmensweite agentenbasierte KI-Strategie ist aus vier grundlegenden Gründen erforderlich:

Übergang von einzelnen Eingabeaufforderungen zu autonomen Arbeitsabläufen

Herkömmliche generative KI-Modelle warten auf eine einzelne Eingabe, führen eine einzelne Aufgabe aus und übergeben die Kontrolle dann an den menschlichen Anwender. Agentische KI kehrt diese Dynamik um. Ein Benutzer definiert ein übergeordnetes Ergebnis (z. B. „Abgleich der Lieferverzögerungen im dritten Quartal mit unserer B2B-Forderungspipeline“) . Der Agent erkennt das Ziel, zerlegt es in aufeinanderfolgende Schritte, ruft externe APIs auf, aktualisiert die Systeme und überprüft seine Arbeit dynamisch.

Beseitigung kognitiver Ermüdung beim Menschen und Skalierung von Operationen

Die manuelle Verwaltung dutzender fragmentierter, isolierter Automatisierungsskripte ist nicht skalierbar. Agenten entlasten den menschlichen Bediener von der zugrundeliegenden Tool-Verwaltung. Hochkomplexe Unternehmensprozesse – wie Kreditvergabe, Durchführung von KYC-Prüfungen (Know Your Customer), Management mehrstufiger Lieferketten oder die Orchestrierung komplexer technischer Kunden-Fehlerbehebungen – lassen sich zu einem Bruchteil der üblichen Betriebskosten und -zeiten automatisieren.

Neugestaltung von Arbeits- und Teamstrukturen

Anstatt Aufgaben einfach nur zu ersetzen, fungieren agentenbasierte Systeme als digitale Kollegen. Sie koordinieren komplexe Abläufe, überwachen Systemzustände in Echtzeit und eskalieren Ausnahmefälle proaktiv an menschliche Spezialisten – jedoch nur dann, wenn strenge Geschäftsregeln menschliches Eingreifen erfordern. Dadurch wird Humankapital von der Datenverarbeitung mit geringem Wert hin zu wertvollen strategischen Entscheidungen verlagert.

Schutzmechanismen, Vertrauen und Sicherheit schaffen

Da autonome Agenten technisch in der Lage sind, Aktionen in der realen Welt durchzuführen (z. B. finanzielle Rückerstattungen an Kunden zu autorisieren, Felder in Produktionsdatenbanken zu bearbeiten oder Aufgaben der Netzwerkinfrastruktur auszuführen), birgt eine unkontrollierte Einführung kritische Risiken. Ein strategisches Rahmenwerk gewährleistet strikte architektonische Grenzen – durch die Zuordnung nicht-menschlicher digitaler Identitäten, die Durchsetzung von Datenverträgen und die Integration unveränderlicher Validierungspunkte mit menschlicher Beteiligung –, bevor sich ein KI-Fehler in internen Umgebungen ausbreitet.

Die Minimum Viable Data Foundation (Das Agentic MVP)

Wenn Ihr globaler Data Lake unübersichtlich und unstrukturiert ist, sollten Sie nicht versuchen, einen autonomen Agenten direkt damit zu verbinden. Einem LLM uneingeschränkten Zugriff auf chaotische Datenbankstrukturen zu gewähren, führt zu häufigen Fehlfunktionen , fehlerhaften Ausführungspipelines und einem hohen Risiko für kritische Datenverluste.

Sie müssen jedoch nicht auf den Abschluss eines mehrjährigen, millionenschweren Data-Warehouse-Modernisierungsprojekts warten, bevor Sie fortfahren. Konzentrieren Sie sich stattdessen auf die Entwicklung eines Agentic MVP , indem Sie manuell vier minimale technische Grundlagen für ein einzelnes, klar abgegrenztes Geschäftsproblem schaffen.

1. Zugängliche API-Endpunkte (Die "Hände")

Agenten können nicht direkt mit statischen PDF-Ausdrucken oder nicht indizierten Rohdatentabellen interagieren. Sie müssen mindestens einen sauberen REST-API-Endpunkt oder eine sichere Datenbankansicht bereitstellen, die es einem externen Prozess ermöglicht, Datensätze sicher zu lesen oder zu schreiben. APIs sind die Werkzeuge eines Agenten; ohne sie bleibt das Analysesystem in einer geschlossenen Sandbox gefangen.

2. Strenge, JSON-lesbare Schemas (Das "Gehirnkartierung")

LLMs benötigen explizite Parameter, um Werkzeuge zuverlässig auszuwählen. Sie müssen ein sauberes JSON-Schema oder eine OpenAPI-Spezifikation bereitstellen, die genau beschreibt, welche Eigenschaften die API erwartet und welche Struktur die zurückgegebenen Daten haben. Ruft ein Agent einen Endpunkt auf und erhält einen unstrukturierten, fehlerhaften Text, schlägt die nachfolgende Logik fehl.

3. Eine Vektordatenbank oder ein Wissensindex (der „Speicher“)

Vor einer Geschäftsentscheidung muss ein Mitarbeiter Kontext, interne Richtlinien und Compliance-Vorgaben prüfen. Voraussetzung ist ein einfacher, verwalteter Vektorindex (z. B. Pinecone, Qdrant oder PostgreSQL mit `pgvector` ), der übersichtliche, segmentierte Einbettungen Ihrer wichtigsten Betriebshandbücher, Standardarbeitsanweisungen (SOPs) oder Produktkataloge enthält. Dies bildet die Grundlage für die abrufgestützte Datengenerierung (Retrieval-Augmented Generation, RAG).

4. Dedizierte Servicekonten und eingeschränktes IAM (Die „Leitplanken“)

Sie müssen einen nicht-menschlichen KI-Agenten genauso behandeln wie einen neu eingestellten menschlichen Mitarbeiter. Er muss mit einem eigenen, separaten Dienstkonto ausgestattet werden, dessen Identity & Access Management (IAM) -Richtlinien zunächst auf * Nur-Lese- Berechtigungen* beschränkt sind und strengen API-Ratenbegrenzungen unterliegen. Übergeben Sie niemals die Anmeldeinformationen der Stammdatenbank an eine LLM-Kontextschleife.

Die zweigleisige Ausführungsstrategie

Um die langfristige technische Stabilität mit der kurzfristigen Geschäftsdynamik in Einklang zu bringen, müssen Organisationen, die vor Herausforderungen im Bereich der Infrastruktur stehen, eine parallele Zwei-Spur-Strategie verfolgen.

Track 1: Entwicklung isolierter taktischer Agenten (Der Sandbox-Ansatz)

Umgehen Sie die unübersichtliche Unternehmensarchitektur, indem Sie manuell eine isolierte, fehlerfreie „Dateninsel“ für einen spezifischen, wertvollen Prozess erstellen. Wenn Ihr CRM-System unübersichtlich ist, exportieren Sie manuell eine verifizierte Teilmenge von 500 Datensätzen in einen separaten Vektorindex. Halten Sie den Agenten strikt schreibgeschützt, erzwingen Sie das Entwurfsformat für seine Ausgaben und setzen Sie am Ende der Verarbeitung einen menschlichen Prüfer ein, der die endgültige Ausgabe überprüft und ausführt.

Track 2: Agenten helfen bei der Infrastrukturreinigung (Der Hausmeisteransatz)

Nutzen Sie spezialisierte Code-Generierungs- und Datenverarbeitungsagenten, um Ihre langfristige Datenmodernisierungsstrategie zu beschleunigen. KI-Agenten sind äußerst effektiv beim Scannen von in Konflikt stehenden Legacy-Datenbanktabellen, beim automatischen Ableiten von Datentypen, beim Erstellen sauberer Zielschemata und beim Schreiben von Python- oder SQL-Skripten zum Bereinigen, Normalisieren und Migrieren von Duplikaten.

Semantische Bibliothek

Die Workflow-Abbildung ist unerlässlich für die korrekte Implementierung spezifischer Agentenaktivitäten. Dazu müssen Sie Informationen erfassen, die den Übergang reibungsloser und effektiver gestalten: Erstellen Sie eine semantische Bibliothek. Diese hilft Ihren Agenten, sich zu informieren – sei es bei der Orchestrierung zwischen Agenten oder bei RAG-Aktivitäten innerhalb eines Agenten. Es handelt sich um eine geschäftsorientierte Informationssammlung, die heutzutage üblicherweise auch technologische Komponenten umfasst.

Die Bibliothek sollte Folgendes umfassen:

1. Geschäftsbedingungen

Es könnten einige Fachbegriffe durchsickern.

2. Kontexte, in denen sie verwendet werden

Dies muss für überladene Begriffe wie Märkte, Bestandteile usw. genauer spezifiziert werden.
„Alle“ ist ein gültiger Kontext, aber wenn alle Ihre Begriffe den Kontext „alle“ haben, haben Sie dies wahrscheinlich falsch gemacht.

3. Definition der Begriffe im Kontext

Bei „Bestandteilen“ kann es sich um einen Bezug zu einem Portfolio, einer Gruppe von Portfolios, einer oder mehreren chemischen Verbindungen, mehreren Materialien usw. handeln.

4. Autoritative Datenquelle(n).

Hier muss angegeben werden, woher die physischen Daten abgerufen werden. Wenn also Dienste Daten aus Caches lesen oder SQL-Abfragen CRUD-Transaktionen von Datenbanken durchführen, müssen diese Informationen hier hinterlegt werden. Es sollten die aktuellen oder geplanten Datenzugriffsmethoden aufgeführt werden, nicht etwa ein Katalog physischer Datenbanken*, S3-Buckets usw.
* wenn Sie keine Dienste haben, die auf die Daten zugreifen.
Der Code (SQL, JS, Python usw.) muss hier nicht angegeben werden; es handelt sich um eine Objektverweis.

5. Katalog der Datenelemente innerhalb einer Datenquelle

Service-Ein- und -Ausgaben, Tabellen, Ansichten usw.; was sich hinter dem Service oder der Ansicht verbirgt. Dies ist wichtig für die Abhängigkeitsanalyse bei Codeänderungen.

6. Falls zutreffend, Phase(n) des/der Arbeitsablaufs/Arbeitsabläufe, in der/denen sie verwendet werden.

Punkte im Arbeitsablauf, an denen Daten verbraucht oder erzeugt werden.

Wenn mehrere „autoritative“ Datenquellen vorhanden sind, sollten diese hierarchisch strukturiert werden, um die Zugriffsreihenfolge festzulegen. Die „semantische Bibliothek“ und ihre Zuordnung bilden im Wesentlichen eine semantische Ebene für Ihre Agenten.

Semantische Bibliotheken lassen sich in kleinen Teilen aufbauen, die den Agentic-MVP-Phasen entsprechen. Die Erstellung einer zusammenhängenden Bibliothek erfordert zwar mehr Koordination, ist aber eine bessere Alternative zu einem Wasserfallmodell, bei dem alles auf einmal umgesetzt wird. Bei diesem Ansatz verschiebt sich die Grenze zum „Fertigstellen“ leider oft, anstatt einen logischen Endpunkt zu haben; in den MVP-Phasen ist dies viel klarer. Wenn Sie bereits eine Bibliothek, wie beispielsweise einen Datenkatalog, besitzen, sollte der Aufbau des Agentic-MVP eine Validierung dieser Bibliothek mit Aktualisierungen sein, aber idealerweise kein kompletter Neuaufbau. Ein Datenkatalog allein ist keine semantische Bibliothek; Kontext und Workflow-Komponenten fehlen.

In jedem Fall sollten Sie damit rechnen, Ihre Bibliothek im Laufe der Zeit zu aktualisieren. Da sie möglicherweise geschäftsbereichsspezifisch ist, ist die Erfassung des Kontextes besonders wichtig. Gegebenenfalls müssen Sie Ihre Bibliothek an die jeweilige Agentenaktivität anpassen.

Verhinderung der Agentenfragmentierung: Die Multi-Agenten-Orchestrierungsschicht

Wenn Sie mehrere taktische Agenten über verschiedene Abteilungen hinweg skalieren, ohne eine einheitliche Ebene einzuführen, wird Ihr Unternehmen einen Wandel von veraltetem Spaghetti-Code zu „KI-Agenten-Spaghetti“ erleben – einem Zustand, in dem unabhängige Agenten auf separaten Codebasen laufen, widersprüchliche Ergebnisse erzeugen und keine einheitliche Geschäftstransparenz aufweisen.

Um dieses Problem zu lösen, sollten Sie nicht versuchen, die unübersichtlichen zugrundeliegenden Datenbanken zusammenzuführen. Standardisieren Sie stattdessen die Kommunikation der Agenten untereinander. Dies erreichen Sie durch die Erstellung einer ereignisgesteuerten, zustandsbehafteten Orchestrierungsschicht, die als Hub-and-Spoke-Multiagentensystem konfiguriert ist.

Die architektonischen Kernpfeiler der Orchestrierung

Zustandsautomat und Workflow-Engine (Deterministischer Pfad)

Der übergeordnete Ablauf eines Unternehmensworkflows darf niemals der unkontrollierten Logik eines linearen Modells überlassen werden. Die Orchestrierungsschicht basiert auf einem deterministischen Zustandsautomaten (basierend auf Frameworks wie LangGraph oder verteilten Systemen wie Temporal.io ). Dadurch wird sichergestellt, dass der Workflow starren Geschäftsprozessen folgt (z. B. kann Schritt B erst ausgeführt werden, wenn Schritt A eine verifizierte JSON-Antwort liefert ). Timeouts, Ausnahmen und Schleifen werden behandelt.

Der Messaging- und Ereignisbus (Entkoppelte Kommunikation)

Da die Verarbeitung von Agentenlogik und der Zugriff auf ältere Datenbanken mehrere Minuten dauern können, kommt es bei synchronen API-Architekturen zu Timeouts und Fehlern. Die Orchestrierungsschicht nutzt daher einen asynchronen Message Broker oder Event Bus (wie Amazon EventBridge , Apache Kafka oder RabbitMQ ). Agenten kommunizieren über das Veröffentlichen und Abonnieren standardisierter JSON-Ereignisumschläge, anstatt direkte Peer-to-Peer-Codeaufrufe auszuführen.

Der LLM Router/Judge (Dynamischer Controller)

Innerhalb der strengen Pfade der Zustandsmaschine wird ein LLM-Wrapper als dynamischer Router oder Judge eingesetzt. Er wertet den semantischen Inhalt der Ausgabe eines Zwischenagenten aus, um den nächsten Pfad zu bestimmen. Hier zahlt sich Ihre Arbeit an der oben erwähnten semantischen Bibliothek aus. Wenn beispielsweise ein Datenbankabruf eine Fehlermeldung zurückgibt, prüft der LLM Judge den Text, um festzustellen, ob es sich um ein routinemäßiges Verbindungs-Timeout handelt, das einen automatischen Wiederholungsversuch erfordert, oder um einen strukturellen Validierungsfehler, der eine sofortige Eskalation an einen Systemadministrator notwendig macht.

Der gemeinsame Kontextspeicher (der Notizblock)

Um eine übermäßige Token-Speicherung und eine Beeinträchtigung des Kontextfensters zu vermeiden, übertragen Agenten keine großen Datenmengen aus früheren Transaktionen. Die Orchestrierungsschicht stellt einen zentralen, persistenten Key-Value- oder Dokumentencache (z. B. Redis oder eine schnelle Amazon DynamoDB- Tabelle) bereit. Dieser dient als gemeinsamer Sitzungsspeicher, in dem Agenten den aktuellen Status einer Transaktion lesen, ihre verifizierten Ausgabedaten anhängen und das Token weiterleiten. Die semantische Bibliothek wird hier erneut verwendet, sofern die Informationen wie zuvor definiert erfasst wurden.

Implementierungspläne für hybride Unternehmensarchitekturen

Blaupause A: AWS IAM-Aufgabenrichtlinie

--json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowEventBridgePublishing",
      "Effect": "Allow",
      "Action": ["events:PutEvents"],
      "Resource": "arn:aws:events:us-east-1:123456789012:event-bus/EnterpriseAgentBus"
    },
    {
      "Sid": "AllowStateCacheAccess",
      "Effect": "Allow",
      "Action": ["dynamodb:GetItem","dynamodb:PutItem","dynamodb:UpdateItem"],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/AgentWorkflowState"
    }
  ]
}

Blaupause B: FastMCP-Serverschnittstelle

-- python

from mcp.server.fastmcp import FastMCP
import psycopg2
import json

mcp = FastMCP("Logistics Enterprise Database Server")
@mcp.tool()

async def get_shipment_status(invoice_id: str) -> str:

    if not invoice_id.startswith("INV-"):
        return json.dumps({"error": "Invalid format"})

    return json.dumps({"invoice_id": invoice_id, "status": "DELAYED", "delay_days": 14, "severity": "CRITICAL"})

Blaupause C: Zeitliche Aktivitätsschleife

--typescript

import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js';

export async function executeLogisticsAgent(invoiceId: string) {
  const transport = new StdioClientTransport({ command: 'python3', args: ['logistics_mcp_server.py'] });

  const mcpClient = new Client({ name: 'TemporalClient', version: '1.0.0' }, { capabilities: { tools: {} } });

  await mcpClient.connect(transport);

  const toolResult = await mcpClient.callTool({ name: 'get_shipment_status', arguments: { invoice_id: invoiceId } });

  await transport.close();

  return JSON.parse(toolResult.content.text);
}

Runbook für Enterprise-Entwickler: Hinzufügen eines neuen Agenten-Silos (Finanzen/Abrechnung)

Dieser Abschnitt beschreibt die praktischen technischen Verfahren, die erforderlich sind, um diese Architektur durch Hinzufügen eines dritten Datensilos zu skalieren: Finanzen & Abrechnung .

Schrittweise Umsetzung

Bereitstellung des Datenansichts- und MCP-Tools: Erstellen Sie ein isoliertes Tool innerhalb von `src/tools/finance_mcp_server.py`, um Regeln über FastMCP zu extrahieren.
Interagenten-Ereignismodell definieren : Strenge semantische Schemastrukturen mithilfe von Pydantic-Klassen erzwingen.
Implementierung einer temporalen Aktivitäts-Worker-Warteschlangenschleife: Erstellen Sie den TypeScript-Worker-Listener-Code.
Registrieren Sie den Knoten in LangGraph: Aktualisieren Sie die Zustands-DAG-Strukturkonfiguration.
Routingregeln aktualisieren: Die AWS EventBridge-Filterkonfigurationen instanziieren, um siloübergreifende Benachrichtigungsendpunkte zuzuordnen.