Unverzichtbares Lesen für Produktmanager: Leitfaden zur AI-Agent-Architektur
Das Göttliche Übersetzungsbüro ist ein Übersetzungsteam von 36Kr, das sich auf Technologie, Geschäft, Arbeitsplatz und Lebensbereiche konzentriert und vor allem neue Technologien, neue Ansichten und neue Trends aus dem Ausland vorstellt.
Herausgeberhinweis: Das Vertrauensparadoxon von AI-Agenten: Warum setzen Benutzer nicht auf den stärksten AI-Agenten, sondern vertrauen stattdessen eher demjenigen, der „schwächer“ ist? Dieser Artikel ist eine Übersetzung.
Letzte Woche habe ich mit einem Produktmanager gesprochen, der vor einigen Monaten einen AI-Agenten ins Leben gerufen hat. Die Daten sehen sehr gut aus: eine Genauigkeit von 89%, eine Reaktionszeit im Subsekundenbereich und auch die Rückmeldungen aus der Benutzerbefragung sind positiv. Aber die Benutzer geben den Agenten auf, nachdem sie das erste reale Problem haben, z. B. wenn ein Benutzer gleichzeitig mit einer Abrechnungsstreitigkeit und einer gesperrten Konto rechnet.
Unser Agent kann normale Anfragen perfekt behandeln. Aber sobald es um komplexe Probleme geht, werden die Benutzer frustriert, nachdem sie ihn einmal ausprobiert haben, und verlangen sofort die Weiterleitung an einen menschlichen Kundendienstmitarbeiter.
Dieses Phänomen lässt sich in jedem Produktteam beobachten, das sich nur darauf konzentriert, den Agenten „intelligenter“ zu machen. Die echte Herausforderung besteht jedoch darin, Architekturentscheidungen zu treffen, die bestimmen, wie die Benutzer den Agenten erleben und ihm vertrauen lernen.
In diesem Artikel werde ich Sie in die verschiedenen Ebenen der AI-Agenten-Architektur einführen und Ihnen zeigen, wie Ihre Produktentscheidungen bestimmen, ob die Benutzer Ihrem Agenten vertrauen oder ihn aufgeben. Nach dem Lesen werden Sie verstehen, warum einige Agenten „beeindruckend“ wirken, während andere „enttäuschend“ sind. Noch wichtiger ist, wie Produktmanager die Architektur gestalten können, um ein beeindruckendes Erlebnis zu schaffen.
Im gesamten Artikel wird anhand eines konkreten Beispiels eines Kundensupport-Agenten gezeigt, wie jede Architekturwahl in der Praxis funktioniert. Wir werden auch untersuchen, warum die ungewöhnliche Vertrauensstrategie (Hinweis: Der Schlüssel liegt nicht in der Verbesserung der Genauigkeit) tatsächlich effektiver für die Steigerung der Benutzerakzeptanz ist.
Angenommen, Sie entwickeln einen Kundensupport-Agenten
Sie sind als Produktmanager dabei, einen Agenten zu entwickeln, der Benutzern bei der Lösung von Konto-Problemen (z. B. Passwortzurücksetzung, Abrechnungsfragen, Tarifänderung) hilft. Klingt einfach, oder?
Aber was sollte passieren, wenn ein Benutzer sagt: „Ich kann nicht auf mein Konto zugreifen, und es scheint mit meinem Abonnement etwas nicht in Ordnung zu sein“?
Szenario A: Ihr Agent beginnt sofort mit der Überprüfung des Systems. Er sucht im Konto und stellt fest, dass das Passwort gestern zurückgesetzt wurde, aber keine E-Mail erhalten wurde. Gleichzeitig entdeckt er ein Abrechnungsproblem, das zu einer Tarifsenkung geführt hat. Dann erklärt er dem Benutzer genau die Situation und bietet eine Lösung an, um beide Probleme mit einem Klick zu beheben.
Szenario B: Ihr Agent beginnt mit Fragen, um das Problem zu klären. „Wann haben Sie sich das letzte Mal erfolgreich angemeldet? Welche Fehlermeldung haben Sie gesehen? Können Sie genauer beschreiben, was mit dem Abonnement nicht stimmt?“ Nachdem er alle Informationen gesammelt hat, sagt er: „Lassen Sie mich Sie an unseren menschlichen Kundendienst weiterleiten. Sie können Ihr Konto und Ihre Abrechnung überprüfen.“
Der gleiche Benutzerantrag, dasselbe Basis-System, aber völlig unterschiedliche Produkterlebnisse.
Vier Ebenen der Produktentscheidungen
Sie können sich die Architektur des Agenten als Technologie-Stack vorstellen, wobei jede Ebene eine Produktentscheidung darstellt, die Sie treffen müssen.
Erste Ebene: Kontext und Gedächtnis (Was merkt sich Ihr Agent?)
Entscheidungspunkt: Wie viel Informationen sollte Ihr Agent sich merken? Wie lange sollte das Gedächtnis bestehen bleiben?
Dies ist nicht nur ein technisches Speicherproblem, sondern auch mit dem Gefühl verbunden, dass der Agent Sie versteht. Das Gedächtnis des Agenten bestimmt, ob das Gespräch mit ihm eher wie ein Dialog mit einem Roboter oder wie ein Gespräch mit einem gut informierten Kollegen anfühlt.
Kundendienst-Agent: Soll er nur die aktuelle Unterhaltung speichern oder auch die gesamte Support-Historie des Kunden? Sogar deren Produktnutzungsmuster? Frühere Beschwerdeaufzeichnungen?
Denkbare Gedächtnistypen:
Konversationsgedächtnis: Die aktuelle Unterhaltung („Sie haben gerade über ein Abrechnungsproblem gesprochen...“)
Kundengedächtnis: Frühere Interaktionen über mehrere Gespräche hinweg („Letzten Monat hatten Sie auch ein ähnliches...“)
Verhaltensgedächtnis: Nutzungsmuster („Ich habe bemerkt, dass Sie normalerweise unsere Mobilanwendung nutzen...“)
Situationsgedächtnis: Der aktuelle Konto-Status, gültige Abonnements, jüngste Aktivitäten
Je mehr Ihr Agent sich merkt, desto besser kann er die Bedürfnisse vorhersagen und nicht nur passiv auf Fragen antworten. Jede Ebene des Gedächtnisses macht die Antwort intelligenter, erhöht aber auch die Komplexität und die Kosten.
Zweite Ebene: Daten und Integration (Wie tief sollte die Integration sein?)
Entscheidungspunkt: Welche Systeme sollte Ihr Agent anbinden? Welchen Zugriffsebene sollte er haben?
Je tiefer Ihr Agent in den Benutzerarbeitsablauf und die bestehenden Systeme integriert ist, desto höher sind die Umstellungskosten für die Benutzer. Diese Ebene bestimmt, ob Ihr Produkt am Ende ein Werkzeug oder eine Plattform ist.
Im Fall eines Kundendienst-Agenten: Soll er nur das Abrechnungssystem von Stripe integrieren oder auch Salesforce CRM, das ZenDesk-Ticketsystem, die Benutzerdatenbank und die Audit-Protokolle? Jede Integration macht den Agenten nützlicher, schafft aber auch mehr potenzielle Störungsmöglichkeiten – wie API-Ratenlimits, Authentifizierungsprobleme und Systemausfälle.
Interessanterweise versuchen die meisten von uns am Anfang, alles zu integrieren und geraten dadurch in Schwierigkeiten. Die erfolgreichsten Agenten beginnen jedoch oft mit 2 - 3 wichtigen Integrationen und erweitern dann schrittweise in Abhängigkeit von den tatsächlichen Bedürfnissen der Benutzer.
Dritte Ebene: Fähigkeiten und Kompetenzen (Was macht Ihren Agenten einzigartig?)
Entscheidungspunkt: Welche spezifischen Fähigkeiten sollte Ihr Agent haben? Wie stark sollte er sein?
Die Fähigkeitsebene ist der Schlüssel zum Erfolg im Wettbewerb. Es geht nicht darum, die meisten Funktionen zu haben, sondern darum, die richtigen Fähigkeiten zu besitzen, die die Benutzer darauf vertrauen lassen.
Im Fall eines Kundendienst-Agenten: Soll er nur die Kontoinformationen lesen können oder auch die Abrechnung ändern, das Passwort zurücksetzen und die Tarifeinstellungen ändern? Jede zusätzliche Fähigkeit erhöht den Nutzen für die Benutzer, aber auch die Komplexität und das Risiko.
Implementierungsanmerkung: Tools wie das Model Context Protocol (MCP) machen es einfacher, Fähigkeiten über verschiedene Agenten hinweg zu erstellen und zu teilen, ohne dass die Fähigkeiten von Grund auf neu entwickelt werden müssen.
Vierte Ebene: Bewertung und Vertrauen (Wie wissen die Benutzer, was sie erwarten können?)
Entscheidungspunkt: Wie messen Sie den Erfolg und kommunizieren die Grenzen des Agenten an die Benutzer?
Diese Ebene bestimmt, ob die Benutzer Vertrauen in den Agenten aufbauen oder ihn aufgeben, nachdem er den ersten Fehler gemacht hat. Es geht nicht nur um die Genauigkeit, sondern auch um die Zuverlässigkeit.
Im Fall eines Kundendienst-Agenten: Zeigen Sie einen Vertrauenswert („Ich bin zu 85% sicher, dass dies Ihr Problem löst“)? Erklären Sie den Denkprozess („Ich habe drei Systeme überprüft und festgestellt...“)? Fordern Sie immer eine Bestätigung, bevor Sie eine Aktion ausführen („Ich setze jetzt Ihr Passwort zurück. Ist das in Ordnung?“)? Jede Wahl beeinflusst die Wahrnehmung der Zuverlässigkeit durch die Benutzer.
Denkbare Vertrauensstrategien:
Darstellung des Vertrauenswerts: „Ich bin mir sicher über den Status Ihres Kontos, aber ich möchte die Abrechnungsdetails noch einmal überprüfen.“
Transparenz des Denkprozesses: „Ich habe zwei fehlgeschlagene Anmeldeversuche und eine abgelaufene Zahlungsmethode festgestellt.“
Elegante Abgrenzung: „Dies scheint ein komplexes Abrechnungsproblem zu sein. Lassen Sie mich Sie an unseren Abrechnungsexperten weiterleiten. Sie haben mehr Werkzeuge, um es zu behandeln.“
Bestätigungsmodus: Wann sollte man um Erlaubnis bitten und wann kann man direkt handeln und dann erklären.
Eine ungewöhnliche Erkenntnis ist: Benutzer vertrauen einem Agenten eher, wenn er seine Unsicherheit eingesteht, als wenn er sich zuversichtlich irren lässt.
Wie sollte man nun die Architektur eines Agenten gestalten?
Okay, Sie kennen nun die verschiedenen Ebenen der Entscheidungen. Und jeder Produktmanager stellt diese Frage: „Wie realisiere ich das überhaupt? Wie spricht der Agent mit den Fähigkeiten? Wie greifen die Fähigkeiten auf die Daten zu? Wie wird die Bewertung durchgeführt, während der Benutzer wartet?“
Ihre Orchestrierungsauswahl bestimmt die Entwicklererfahrung, den Debugging-Prozess und die Fähigkeit zur schnellen Iteration.
Schauen wir uns einige gängige Methoden an. Ich werde Ihnen ehrlich sagen, in welchen Fällen jede Methode funktioniert und in welchen Fällen sie zu einem Albtraum werden kann.
Einzel-Agenten-Architektur (Beginnen Sie hier)
Alles geschieht im Kontext eines einzelnen Agenten.
Im Fall eines Kundendienst-Agenten: Wenn ein Benutzer sagt „Ich kann nicht auf mein Konto zugreifen“, wird alles von einem Agenten behandelt – Überprüfung des Konto-Status, Erkennung eines Abrechnungsproblems, Erklärung der Situation und Angebot einer Lösung.
Vorteile: Einfache Konstruktion, einfaches Debugging, vorhersehbare Kosten. Man weiß genau, was der Agent kann und was nicht.
Nachteile: Die Behandlung komplexer Anfragen kann teuer werden, da jedes Mal der gesamte Kontext geladen werden muss. Es ist schwierig, bestimmte Teile zu optimieren.
Die meisten Teams beginnen hier. Ehrlich gesagt müssen viele Teams überhaupt nicht zu einer komplexeren Architektur wechseln. Wenn Sie sich zwischen dieser Lösung und einer komplexeren Lösung nicht entscheiden können, beginnen Sie hier.
Fähigkeitsbasierte Architektur (Wenn Effizienz erforderlich ist)
Es wird eine Routing-Mechanik eingeführt, um die Benutzerbedürfnisse zu bestimmen und dann die Aufgaben an spezialisierte Fähigkeiten zu verteilen.
Im Fall eines Kundendienst-Agenten: Der Router erkennt, dass es sich um ein Kontozugangsproblem handelt und leitet es an die Login-Fähigkeit weiter. Wenn die Login-Fähigkeit feststellt, dass es sich tatsächlich um ein Abrechnungsproblem handelt, leitet sie die Aufgabe an die Abrechnungs-Fähigkeit weiter.
Beispiel für einen realen Ablauf:
Benutzer: „Ich kann mich nicht anmelden“
Router → Login-Fähigkeit
Die Login-Fähigkeit überprüft: Das Konto existiert ✓, das Passwort ist falsch ✗, Abrechnungsstatus... Warte, das Abonnement ist abgelaufen
Login-Fähigkeit → Abrechnungs-Fähigkeit: „Behandle das abgelaufene Abonnement von user123“
Die Abrechnungs-Fähigkeit behandelt den Verlängerungsprozess
Vorteile: Effizienter – für einfache Fähigkeiten können billigere Modelle verwendet werden, für komplexe Schlussfolgerungen teurere Modelle. Jede Fähigkeit kann unabhängig optimiert werden.
Nachteile: Die Koordination zwischen den Fähigkeiten kann schnell komplex werden. Wer entscheidet, wann es weitergeleitet wird? Wie teilen sich die Fähigkeiten den Kontext?
Hier kommt das MCP ins Spiel – es standardisiert die Art und Weise, wie die Fähigkeiten ihre Fähigkeiten offenlegen, so dass der Router weiß, was jede Fähigkeit kann, ohne dass diese Zuordnung manuell gepflegt werden muss.
Workflowbasierte Architektur (Lieblingsarchitektur für Unternehmensanwendungen)
Sie definieren im Voraus die Prozessschritte für häufige Szenarien. Sie können sich an Tools wie LangGraph, CrewAI, AutoGen, n8n orientieren.
Im Fall eines Kundendienst-Agenten: Ein „Kontozugangsproblem“ löst den folgenden Workflow aus: