Fortschritte im Prompt Engineering

Vom Prompt-Trick zum Conversation Engineering

Große Sprachmodelle können schreiben, Fragen beantworten, zusammenfassen und schlussfolgern. Ein Voice-Agent muss aber mehr liefern als einen plausiblen Satz. Er muss das Anliegen des Anrufers erkennen, innerhalb einer festgelegten Grenze bleiben, entscheiden, ob ein Tool-Aufruf gerechtfertigt ist, und das Gespräch in Gang halten, während das Audio Redebeitrag für Redebeitrag ankommt. Für ein Unternehmen mit 50 bis 100 Beschäftigten ist das eine praktische Ingenieursaufgabe. Ein kleines Team braucht einen Agenten, der sich verlässlich genug verhält, um einen echten Workflow zu tragen. Und es braucht einen Weg, ihn zu verbessern, ohne davon abzuhängen, wer zuletzt einen Absatz geändert hat.

Prompt Engineering ist deshalb nur eine Ebene einer breiteren Praxis. Conversation Engineering, also die Gestaltung des ganzen Gesprächs, verbindet Anweisungen, Sprecherwechsel, Tools, Kontext, Ergebnisse und Prüfung. Zero-Shot-Anweisungen helfen weiterhin beim ersten Entwurf. Few-Shot-Beispiele machen ein gewünschtes Muster greifbar, und Angaben zu Rolle oder Persona geben eine passende Stimme vor. Keine dieser Techniken ersetzt eine festgelegte Grenze oder ein testbares Ergebnis. Die entscheidende Frage ist nicht, ob ein Prompt raffiniert klingt. Sie lautet: Führt das gesamte Gespräch unter normalen und schwierigen Bedingungen zur richtigen nächsten Aktion?

Den Prompt für den Produktivbetrieb in Ebenen aufbauen

Ein Prompt im Produktivbetrieb ist leichter zu durchschauen, wenn jede Ebene genau eine Aufgabe hat. Getrennte Ebenen machen auch Änderungen leichter prüfbar. Eine Anpassung des Tons sollte nicht nebenbei die Befugnis für Erstattungen ändern. Ein neues Tool sollte nicht stillschweigend neu definieren, was ein erfolgreicher Anruf ist.

Anliegen und Grenzen festlegen

Beginnen Sie mit der Aufgabe, die der Agent erledigen darf. Benennen Sie die unterstützten Anliegen in einfacher Sprache, etwa einen Termin buchen, einen Bestellstatus prüfen, eine Nachricht aufnehmen oder ein technisches Problem weiterleiten. Benennen Sie dann die angrenzenden Anfragen, die er ablehnen, klären oder übergeben muss. Eine Grenze beschreibt eine Handlung, nicht bloß eine vage Charaktereigenschaft. „Hilfsbereit sein“ lässt sich kaum testen. „Einen bestehenden Termin verschieben ist erlaubt, sobald Anrufer und neuer Termin bestätigt sind. Eine Leistung mit finanziellen Folgen zu stornieren ist nicht erlaubt.“ Damit hat der Betrieb etwas, das sich prüfen lässt.

Geben Sie dem Agenten die Informationen, die er braucht, um ähnliche Anliegen auseinanderzuhalten. Wer „morgen ändern“ möchte, meint vielleicht ein Lieferfenster, eine Reservierung oder eine Kontaktpräferenz. Der Agent stellt die kleinste sinnvolle Rückfrage und setzt dann den gewählten Weg fort. Das verhindert einen typischen Fehler: Eine selbstsichere Antwort überdeckt eine falsche Einordnung.

Richtlinien von Tool-Anweisungen trennen

Die Richtlinie beantwortet, was erlaubt ist. Tool-Anweisungen beantworten, wie eine erlaubte Aktion ausgeführt wird. Halten Sie beides ausdrücklich fest. Legen Sie für jedes Tool fest: Pflichtfelder, zulässige Werte, Bestätigungspunkt, erwartetes Ergebnis und Ausweichweg, wenn das Tool nicht verfügbar ist. Sagen Sie, ob der Agent ein Ergebnis vorlesen, vor dem verbindlichen Schritt um Bestätigung bitten oder eine Abfrage nur kurz quittieren soll. Behandeln Sie fehlende, veraltete oder widersprüchliche Daten als festgelegten Zustand, nicht als Einladung zum Raten.

Ein nützliches Vorher-nachher-Muster ersetzt einen Wunsch durch eine Entscheidungsregel:

Vorher: „Dem Anrufer helfen, seine Buchung zu ändern, und bei Bedarf das Buchungssystem nutzen.“ Nachher: „Zuerst die Buchung identifizieren und die gewünschte Änderung des Anrufers bestätigen. update_booking nur verwenden, wenn alle Pflichtfelder vorliegen. Vor einer kostenpflichtigen Änderung die Gebühr erklären und ausdrücklich um Bestätigung bitten. Findet das Tool keine passende Buchung, kein Ergebnis erfinden, sondern eine Übergabe an einen Menschen oder eine Nachricht anbieten.“

Es geht nicht darum, jeden Prompt riesig zu machen. Es geht darum, Entscheidungen mit hohem Risiko dorthin zu stellen, wo man sie sehen, testen und verantworten kann.

Der Ton soll der Genauigkeit dienen

Der Ton zählt, weil Anrufer verstehen müssen, was als Nächstes passiert. Er ersetzt aber keine Richtigkeit. Beschreiben Sie einige beobachtbare Verhaltensweisen: kurze Sätze, Frust anerkennen, ohne einer ungeprüften Behauptung zuzustimmen, eine Frage nach der anderen, keine Füllwörter, während ein Tool arbeitet. Verzichten Sie auf lange Listen von Adjektiven wie freundlich, herzlich, professionell und empathisch. Solche Wörter können sich widersprechen oder eine Stimme erzeugen, die angenehm klingt, aber ausweicht.

Wenn Ton und Genauigkeit kollidieren, gewinnen Genauigkeit und ehrliche Unsicherheit. Ein ruhiges „Eine bestätigte Lieferzeit habe ich noch nicht. Ich kann das gern prüfen oder Sie mit dem Team verbinden.“ ist besser als eine beruhigende Vermutung. Prüfen Sie den Ton zusammen mit dem Erfolg der Aufgabe. Ein Agent kann geschliffen klingen und den Anrufer trotzdem mit einer falschen Erwartung zurücklassen.

Das Gespräch nach echtem Telefonverhalten gestalten

Unterbrechungen und Stille bewusst behandeln

Ein Telefonat ist kein Text-Chat mit Sprachausgabe. Menschen unterbrechen, wenn sie die Antwort verstanden haben, ihr widersprechen, sich an ein weiteres Detail erinnern oder einfach die Führung übernehmen wollen. Legen Sie fest, was passiert, wenn der Anrufer dem Agenten ins Wort fällt: die laufende Antwort stoppen oder kürzen, die Worte des Anrufers festhalten und mit der neuen Information weitermachen, statt das ganze Skript neu zu beginnen. Vor einer längeren Erklärung bietet der Agent eine Wahl an, etwa: „Ich kann es Ihnen kurz sagen oder die Details erklären.“ Lassen Sie den Anrufer keinen ganzen Absatz abwarten, nur damit der Agent gründlich wirkt.

Auch Stille braucht eine Regel. Eine kurze Pause kann heißen, dass der Anrufer nachdenkt, in einem Dokument nachsieht oder mit einer Verzögerung in der Leitung zu tun hat. Der Agent wartet, bevor er nachfragt, und fragt dann behutsam nach, statt dieselbe Frage in voller Länge zu wiederholen. Nach längerer Stille bietet er einen klaren Weg zurück: die letzte Frage wiederholen, den Anrufer einladen, „Mitarbeiter“ zu sagen, oder den Anruf nur nach einer festgelegten Regel beenden. Die passenden Schwellenwerte gehören in die Laufzeitkonfiguration und in die Testfälle, nicht als ungeprüfte Annahme in den Fließtext.

Die Telefonie-Ebene liefert wichtige Signale zu Verbindungsstatus, Weiterleitung und Audioverhalten. Wie der Agent auf diese Zustände reagiert, müssen die Gesprächsanweisungen trotzdem festlegen. Prompt-Arbeit und Telefonie-Arbeit sollten gemeinsam geprüft werden.

Kontext und Gedächtnis eine Aufgabe geben

Kontext soll Wiederholungen verringern, ohne falsche Sicherheit zu erzeugen. Legen Sie fest, was der Agent zu Beginn eines Anrufs erhält, was er sich während des Anrufs merken darf und welche Fakten er sicher über mehrere Anrufe hinweg mitnehmen kann. Name, gewählter Termin und Anlass des Anrufers können im laufenden Gespräch nützlich sein. Eine vermutete Vorliebe, eine alte Adresse oder eine ungeklärte Beschwerde darf ohne Prüfung nicht als aktueller Stand gelten.

Arbeiten Sie mit einem kompakten Zustandsmodell, statt das Modell ein unstrukturiertes Transkript behalten zu lassen. Nützliche Felder sind zum Beispiel intent, identity_status, requested_action, required_fields_missing, tool_status, handover_reason und next_step. So arbeiten der Agent im nächsten Redebeitrag und Ihr Team mit demselben Bild. Außerdem lässt sich testen, ob der Agent nach einer Unterbrechung oder einer Tool-Antwort ein wichtiges Detail verliert.

Über Retrieval abgerufene Inhalte können aktuelle Richtlinien oder Kontodaten liefern. Abgerufener Text ist aber Kontext, keine Autorität aus sich selbst heraus. Legen Sie fest, welche Quelle maßgeblich ist, was gilt, wenn Quellen sich widersprechen, und wann dem Anrufer gesagt werden muss, dass eine Information nicht verfügbar ist. Das Gedächtnis soll das Gespräch stimmiger machen, nie sicherer, als die Belege es erlauben.

Strukturierte Ergebnisse zurückgeben

Ein erfolgreicher Anruf ist nicht immer eine abgeschlossene Transaktion. Manchmal ist das richtige Ergebnis eine bestätigte Buchung, manchmal eine offene Anfrage und manchmal eine saubere Übergabe. Legen Sie das Vokabular der Ergebnisse fest, bevor Sie den Prompt schreiben. Wenige stabile Status sind meist nützlicher als ein Absatz Notizen: completed, pending_customer, pending_team, handover_required und not_supported sind Beispiele, kein allgemeingültiges Schema.

Jedes Ergebnis trägt die Felder, die das nächste System oder die nächste Person braucht: Ziel des Anrufers, versuchte Aktion, bestätigte Fakten, fehlende Informationen, Tool-Ergebnisse und den Grund für den Status. Lassen Sie den Agenten diese Struktur am Ende des Workflows erzeugen oder befüllen, während der gesprochene Abschluss knapp bleibt. So bleibt getrennt, was der Anrufer hört und was der Betrieb prüfen muss.

Verbinden Sie das Design der Ergebnisse mit den Integrationen des Unternehmens. Bekommt ein CRM, Kalender oder Ticketsystem uneinheitliche Labels, laufen Berichte und Nachverfolgung auseinander, auch wenn das Gespräch gut klingt.

Die Übergabe an einen Menschen als vollwertiges Ergebnis behandeln

Eine Übergabe ist kein Scheitern, das man verstecken muss. Sie ist das richtige Ergebnis, wenn die Anfrage außerhalb des Umfangs liegt oder eine Richtlinie einen Menschen verlangt. Das gilt auch, wenn der Anrufer nach einem Menschen fragt, die Konfidenz nach einer Rückfrage niedrig bleibt oder ein Tool eine folgenreiche Aktion nicht abschließen kann. Sagen Sie dem Agenten, was er sagen soll, und legen Sie auch fest, was er weitergibt. Eine Live-Übergabe mit Kontext bewahrt den Grund der Weiterleitung, den Stand des Gesprächs und bereits erledigte Prüfungen, ohne dass der Anrufer sensible Angaben wiederholen muss.

Ist eine Live-Übergabe nicht möglich, weckt der Agent eine ehrliche Erwartung an den nächsten Schritt und nimmt nur die Informationen auf, mit denen das Team arbeiten kann. Der Grund der Übergabe muss konkret genug sein, um die Arbeit zu verteilen: „Strittige Rechnung, Prüfung nötig“ hilft mehr als „Agent angefordert“. Messen Sie, ob das übernehmende Team den Vorgang schnell versteht, nicht nur, ob die Weiterleitung zustande kam.

Verbesserung zum Betriebsprozess machen

Testsets und Regressionsfälle aufbauen

Beginnen Sie mit einem kleinen Testset, das die Aufgabe abbildet, nicht mit einer Sammlung idealer Fragen. Nehmen Sie klare und vage Anfragen auf, falsche Nummern, Unterbrechungen, Stille, wiederholte Anrufer, Tool-Ausfälle, Grenzfälle der Richtlinie, nicht unterstützte Anfragen und den ausdrücklichen Wunsch nach einem Menschen. Ergänzen Sie Testfälle, in denen der Anrufer seine Meinung ändert. Legen Sie für jeden Testfall fest: erwartetes Anliegen, erlaubte Aktion, nötige Rückfrage, angemessener Ton und Endergebnis.

Few-Shot-Beispiele sind hier am wertvollsten, wenn sie eine Grenze oder einen Weg zurück ins Gespräch zeigen. Halten Sie Beispiele kurz und vermerken Sie, warum sie enthalten sind. Die Chain-of-Thought-Aufforderung „Schritt für Schritt denken“ ersetzt kein Entscheidungsraster verlässlich. Fragen Sie bei einem Voice-Agent im Produktivbetrieb besser nach der nötigen internen Entscheidung oder dem strukturierten Feld und bewerten Sie das Ergebnis, statt sich auf sichtbaren Begründungstext zu verlassen.

Jede relevante Änderung läuft gegen die bestehenden Testfälle. Ein Prompt kann die Terminbuchung verbessern und gleichzeitig den Umgang mit Unterbrechungen verschlechtern. Werten Sie das Ergebnis nach Anliegen und Fehlerart aus, dazu eine kleine Stichprobe vollständiger Transkripte für die qualitative Prüfung. Die Qualitätsprüfung und Evaluation sollte Regressionen sichtbar machen, bevor ein breites Release erfolgt.

Rückmeldungen aus dem Betrieb nutzen, ohne Rauschen in den Prompt zu kopieren

Live-Gespräche sind die ergiebigste Quelle neuer Testfälle, aber rohe Rückmeldungen müssen gesichtet werden. Verschlagworten Sie Anrufe nach Anliegen, Ergebnis, Richtlinienrisiko, Tool-Verhalten, Problemen bei Sprache oder Sprecherwechsel und Qualität der Übergabe. Trennen Sie ein einmaliges Transkriptionsproblem von einer wiederkehrenden Lücke in den Anweisungen. Prüfen Sie erfolgreiche und erfolglose Anrufe. Erfolge zeigen nützliche Formulierungen und effiziente Wege. Fehler zeigen, wo das Design eine neue Grenze, einen neuen Zustand, einen Test oder eine Produktänderung braucht.

Reagieren Sie nicht auf jeden schlechten Anruf mit einem weiteren Satz im Prompt. Fragen Sie zuerst, welche Ebene versagt hat. Die Lösung kann ein fehlendes Tool-Feld sein, eine falsche Zuordnung in der Integration, eine unklare Richtlinie, eine Telefonie-Einstellung, eine Wissensquelle oder ein menschlicher Arbeitsablauf. Ist die Lösung eine Prompt-Änderung, nehmen Sie das auslösende Gespräch in das Regressionsset auf. So bleibt die Korrektur beobachtbar.

Operative Analysen helfen, diese Signale nach Anliegen und Ergebnis zu gruppieren. Entscheidend ist, aus Mustern benannte Arbeit zu machen: eine Fehlerkategorie, eine verantwortliche Person, eine vorgeschlagene Änderung und ein Test, dessen Ergebnis sich bewegen soll.

Freigabeschwellen passend zum Risiko setzen

Freigabeschwellen müssen nicht aufwendig sein, um zu nützen. Prüfen Sie vor der Veröffentlichung einer Änderung: Hat sich das Zielverhalten in seinen Testfällen verbessert? Werden unterstützte Anliegen weiterhin abgeschlossen, halten die Grenzen, enthalten Tool-Aufrufe gültige Eingaben, bewahren Übergaben nützlichen Kontext, und lässt sich das Gespräch weiterhin unterbrechen? Bei einem Workflow mit weitreichenden Folgen braucht es zusätzlich eine menschliche Prüfung repräsentativer Transkripte und einen stufenweisen Rollout mit klarem Rollback-Punkt.

Halten Sie fest, wer einen Prompt freigeben darf, wer das angebundene Tool oder die Richtlinie verantwortet und wer die ersten Anrufe im Produktivbetrieb beobachtet. Ein Unternehmen mit 50 bis 100 Beschäftigten braucht kein großes Gremium, aber benannte Verantwortung. Versionieren Sie Prompt und Testset gemeinsam, dokumentieren Sie den Grund der Änderung und halten Sie die letzte bewährte Version verfügbar. So bleibt Verbesserung umkehrbar, und es gibt weniger Diskussionen, die sich nur auf das Gedächtnis stützen.

Der Verbesserungskreislauf der Agent Factory

Der nachhaltigste Fortschritt im Prompt Engineering ist der Schritt vom isolierten Editieren zu einem wiederholbaren Verbesserungskreislauf. Im Modell der Agent Factory legt ein Team die Aufgabe und ihre Grenzen fest und stellt Gespräch und Tools zusammen. Es testet den Agenten an realistischen Szenarien, gibt ihn mit passenden Freigabeschwellen frei und führt die beobachteten Ergebnisse in den nächsten Designzyklus zurück. Der Kreislauf ist wertvoll, weil er Prompts einen festen Platz im Betrieb gibt. Sie werden zu versionierten Artefakten mit verantwortlicher Person, Belegen und einem Grund für jede Änderung.

Halten Sie den Kreislauf in einem wachsenden Unternehmen sichtbar. Führen Sie ein gemeinsames Backlog für neue Anliegen, Entscheidungen zu Grenzen, Lücken bei Tools oder Integrationen, Testfälle und Prompt-Änderungen. Prüfen Sie regelmäßig eine kleine Auswahl von Anrufen. Machen Sie wiederkehrende Fehler zu Regressionstests, und nehmen Sie Tests heraus, wenn sich der zugrunde liegende Workflow ändert. Die Agent Factory, mit der DRING Agenten baut, testet und verbessert, ist gerade deshalb ein nützlicher Rahmen: Sie verbindet den Aufbau von Agenten mit Evaluation und laufendem Betrieb, statt den Start als Ziellinie zu behandeln.

Praktische Checkliste für die Umsetzung

Unterstützte Anliegen des Agenten und ausdrückliche Grenzen des Umfangs aufschreiben.
Für jeden mehrdeutigen Weg die kleinste nötige Rückfrage festlegen.
Richtlinien von Tool-Eingaben, Tool-Ausgaben und Fehlerbehandlung trennen.
Festlegen, was der Agent vor einer folgenreichen Aktion prüfen muss.
Den Ton als beobachtbares Verhalten beschreiben, mit Vorrang für Genauigkeit und ehrliche Unsicherheit.
Festlegen, wie Unterbrechungen, Barge-in, kurze Pausen und längere Stille behandelt werden.
Entscheiden, welcher Kontext zum laufenden Anruf gehört und welche Informationen erneut geprüft werden müssen.
Strukturierte Ergebnisse festlegen, mit den Feldern, die ein Mensch oder ein nachgelagertes System braucht.
Die Übergabe an einen Menschen leicht auslösbar machen, auf Wunsch des Anrufers und wenn die Richtlinie es verlangt.
Tool-Timeouts, leere Ergebnisse, widersprüchliche Daten und nicht verfügbare Systeme testen.
Ein repräsentatives Testset aufbauen, das schwierige Gespräche enthält, nicht nur den Idealverlauf.
Nach jeder relevanten Änderung an Prompt, Richtlinie, Modell oder Integration die Regressionstests laufen lassen.
Rückmeldungen aus dem Betrieb nach Anliegen, Ergebnis und fehlerhafter Ebene verschlagworten, bevor Anweisungen geändert werden.
Für jedes Release eine verantwortliche Person, eine prüfende Person, eine Version und einen Rollback-Punkt festlegen.
Wiederkehrende Fehler aus dem Betrieb zu neuen Tests machen und in den nächsten Verbesserungszyklus geben.

Das Fazit

Prompt Engineering für Voice-KI im Betrieb heißt, eine verlässliche Entscheidungsumgebung zu gestalten. Es ist keine Suche nach magischen Formulierungen. Die stärksten Systeme verbinden klare Grenzen der Anliegen mit sicherer Tool-Nutzung, natürlichem Sprecherwechsel, diszipliniertem Umgang mit Kontext, strukturierten Ergebnissen und einer respektvollen Übergabe. Verbessert werden sie über Testsets, Belege aus dem Betrieb und Freigabeschwellen, und für die Entscheidungen rund um das Modell sind Menschen verantwortlich. Modelle und Werkzeuge entwickeln sich weiter. Diese Betriebsdisziplin sorgt dafür, dass ein Unternehmen mit 50 bis 100 Beschäftigten Fähigkeiten gewinnt, ohne die Kontrolle über das Kundenerlebnis zu verlieren.

Entwickeln und verbessern

Gespräche führen

Verbinden und handeln

Sehen und entscheiden

Fortschritte im Prompt Engineering und die Zukunft der Optimierung großer Sprachmodelle