Copilot Studio Agent richtig bauen

Der erste Copilot-Studio-Agent sieht im Testfenster oft makellos aus. Kaum trifft er auf echte Nutzer, antwortet er vage oder erfindet Regeln, die es nirgends gibt. Das liegt selten an der Technik, sondern an vier typischen Anfängerfehlern: fehlendes Grounding, keine Persona, unsystematisches Debugging und eine überstürzte Veröffentlichung.

Dieser Leitfaden zeigt, wie Sie eine schlechte Antwort im Testbereich reproduzieren, den Agenten auf ein echtes Dokument stützen, ihm eine klare Identität geben und ihn kontrolliert veröffentlichen.

Warum ein Copilot Studio Agent im Test glänzt und in der Praxis scheitert

Das Testfenster in Copilot Studio ist eine geschützte Umgebung. Die Eingaben sind kurz, sauber formuliert und ähneln meist den Beispielen, die Sie selbst vorbereitet haben. Im Alltag schreiben Menschen anders. Einer fragt, wie viel er im Hotel ausgeben darf. Ein anderer tippt „Hotel-Spesen-Limit" mit Tippfehler. Ein Dritter bittet, ihn „nochmal an das Reisegeld" zu erinnern. Alle meinen dasselbe, aber der Bot erkennt nicht jede Variante.

Der Drei-Variationen-Test

So machen Sie diese Lücke sichtbar: Stellen Sie im Testbereich dieselbe Frage dreimal.

1. in sauberer, formaler Formulierung,
2. in lockerer Umgangssprache,
3. mit einem Tippfehler.

Beobachten Sie, wie sich die Antworten verändern. Manchmal werden alle drei Varianten erkannt, manchmal nur die saubere. Das ist ein deutlicher Hinweis, dass ein schönes Testergebnis noch keine Praxistauglichkeit beweist.

Trigger-Phrasen verbreitern

Bots stützen sich auf Trigger-Phrasen und Themendefinitionen, um zu entscheiden, wann eine Antwort ausgelöst wird. Sehen alle Beispiele gleich aus, wird das Modell spröde, und ein einzelnes Synonym kann genügen, um es aus dem Tritt zu bringen. Ergänzen Sie Ihre Themen deshalb um die lockere, kurz angebundene und leicht unordentliche Sprache, die Menschen tatsächlich verwenden. Dutzende Varianten sind nicht nötig. Es reicht, die offensichtlichen abzudecken. Danach testen Sie erneut.

Kanäle verhalten sich unterschiedlich

Das Testfenster ist nur eine Simulation. Auf Kanälen wie Teams, SharePoint oder einer Demo-Webseite kann sich ändern, wie Text verarbeitet und dargestellt wird. Teams bricht Zeilen womöglich anders um, eine Webseite entfernt Formatierung. Schon ein verschobener Schlüsselbegriff kann beeinflussen, wie das Modell gewichtet. Deshalb sind iterative Tests über verschiedene Kanäle nötig. Betrachten Sie das Studio als Sparringstraining: nützlich zum Lernen, aber kein Beleg für Einsatzbereitschaft.

Grounding: Den Agenten auf eine verlässliche Wissensquelle stützen

Der erste und folgenreichste Anfängerfehler ist, Copilot Studio wie eine Kristallkugel zu behandeln statt wie ein Regelwerk. Ein Agent ohne Wissensquelle ist wie ein Praktikant ohne Vorbereitung im Vorstand: Er redet schnell und souverän, aber vieles hält keiner Prüfung stand. Ein ungegroundeter Bot greift auf Muster zurück, nicht auf Fakten. Er weiß nichts, er bluffst.

Halluzinationen mit realen Folgen

Das Schlimmste sind nicht schwache, sondern erfundene Antworten, die plausibel klingen. Fragt jemand nach der Reisekostenerstattung, nennt der Bot eine Zahl, die richtig wirkt, aber frei erfunden ist. Ein Mitarbeiter bucht daraufhin ein Hotel, und es folgen Spesenstreitigkeiten und verärgerte E-Mails.

Das Beispiel aus den Contoso-Labs zeigt den Unterschied. Dort wird die Datei expenses-policy.docx hochgeladen, in der das Übernachtungslimit mit 200 Dollar pro Nacht steht. Ohne Grounding könnte der Bot auf die Frage nach der Hotelrichtlinie selbstbewusst 100 Dollar nennen. Mit der angehängten Datei zitiert er dagegen die Reiserichtlinie und nennt das korrekte Limit.

So fügen Sie Wissen hinzu

1. Öffnen Sie Ihren Agenten in Copilot Studio.
2. Klicken Sie auf der Übersichtsseite auf „Wissen".
3. Wählen Sie „Wissen hinzufügen" und anschließend die Datei-Option.
4. Laden Sie Ihre expenses-policy.docx oder eine andere vertrauenswürdige Quelle hoch.

Alternativ können Sie eine öffentliche Website oder einen SharePoint-Speicherort verbinden, Dateien sind aber sauberer. Nach dem Hochladen wird der Inhalt indiziert, was zehn Minuten oder länger dauern kann. Wenn die ersten Testfragen noch nicht greifen, ist das kein Grund zur Panik. Sobald die Indizierung abgeschlossen ist, stellen Sie die Frage erneut. Bei korrektem Grounding erscheint die Antwort mit einem kleinen Zitat, das auf das hochgeladene Dokument verweist.

Conversation Boosting ist kein Ersatz

Ein verbreitetes Missverständnis: Conversation Boosting fülle fehlendes Wissen von selbst auf. Es verstärkt jedoch nur Textmuster und schafft kein Richtlinienverständnis. Wird in Ihren Quellen nichts gefunden, kann das System auf das allgemeine Wissen des Modells zurückgreifen und vage oder ungenaue Antworten liefern. Konfigurieren Sie kritische Themen daher so, dass bei Präzisionsbedarf ausschließlich Ihre hinzugefügten Quellen durchsucht werden. Das gilt besonders für Compliance, Finanzen und Personalwesen.

Persona definieren: Name, Beschreibung, Anweisungen und Tonfall

Ein korrekter Agent ist noch kein überzeugender. Die Persona bekommen Sie in Copilot Studio nicht geschenkt, Sie müssen sie aktiv festlegen. Lassen Sie Name, Beschreibung und Anweisungen leer, erhalten Sie Standardantworten ohne Autorität und Kontext. In Bereichen wie Personal oder Finanzen wirkt das wie ein Prototyp statt wie ein verlässliches Werkzeug. Verlieren Sie Nutzer beim ersten Kontakt, kommen sie selten zurück.

Die Felder im Überblick

• Name: auf 30 Zeichen begrenzt, also kurz und prägnant, etwa „Experte für Spesenrichtlinien".
• Beschreibung: etwa 1000 Zeichen, genug für ein paar klare Sätze. Zum Beispiel: Der Agent liefert Mitarbeitern aktuelle Antworten auf Basis der offiziellen Reiserichtlinie, zitiert relevante Passagen und vermeidet Spekulationen.
• Anweisungen: bis zu 8000 Zeichen für konkrete Arbeitsregeln, etwa: Richtlinie bei Verfügbarkeit immer zitieren, spekulative Antworten vermeiden, für Führungskräfte in einem klaren Satz zusammenfassen und die Quelle nennen.

Ein bloßes „Sei hilfreich" genügt nicht. Legen Sie fest, was der Bot einbeziehen, was er vermeiden und wie er formatieren soll.

Tonfall steuern

Den Ton können Sie explizit vorgeben, etwa „formell und professionell" oder „locker und leicht verständlich für Mitarbeiter ohne technischen Hintergrund". Bei Bedarf fügen Sie Beispiele direkt in die Anweisungen ein. Schon wenig Text steuert, wie der Bot formuliert.

Begrüßung und Icon

Zwei schnelle Verbesserungen dauern jeweils nur wenige Minuten. Bearbeiten Sie das Startthema der Konversation und ersetzen Sie die generische Begrüßung durch eine rollenspezifische, etwa: „Ich helfe Ihnen, die Reiserichtlinien zu verstehen, und zitiere nach Möglichkeit das offizielle Dokument." Außerdem können Sie das Agenten-Icon durch eine Markengrafik oder ein einfaches Logo ersetzen, damit der Agent nicht schon vor der ersten Antwort nach Demo aussieht.

Diese Anpassungen sind kein optionaler Feinschliff. Eine Einleitung, die die Rolle nennt, regt relevante Fragen an. Tonregeln verhindern ausschweifende Antworten. Präzise Anweisungen halten die KI von Fülltexten fern. Das alles gelingt ohne zusätzliche Connectoren oder Plugins.

Debugging in Echtzeit: Fehler reproduzieren, korrigieren, erneut testen

Beim Debugging verwandeln Sie Fehler in Lektionen statt in Support-Tickets. Der Kreislauf lautet: Fehler beobachten, isolieren, beheben, erneut testen. Diese Routine hilft dabei:

1. Reproduzieren: Stellen Sie im Testbereich exakt die Frage, die der Nutzer gestellt hat.
2. Zurücksetzen: Starten Sie über das Aktualisierungssymbol oder „Neuer Chat" eine frische Konversation.
3. Themen prüfen: Sehen Sie nach, welches Thema ausgelöst wurde. War es keines Ihrer Themen, sondern das systemeigene Conversational Boosting, hat sich der Bot auf das Modell verlassen.
4. Index kontrollieren: Prüfen Sie bei Boosting-Antworten, ob Datei oder Website hochgeladen und indiziert sind. Kein Index, kein Grounding.
5. Korrigieren und wiederholen: Passen Sie Anweisungen oder Themeninhalte an, speichern Sie und führen Sie dieselbe Abfrage erneut aus.

Diese Schleife ist Ihr wichtigstes Werkzeug. Wer sie überspringt, hofft nur auf Glück beim nächsten Versuch.

Neues Thema per Copilot-Beschreibung

Fehlt dem Bot Struktur, hilft ein neues Thema. Auf der Themenseite können Sie Inhalte per Beschreibung mit Copilot hinzufügen, etwa „Antworten direkt, wenn Benutzer nach Ausgabengrenzen fragen". Das System entwirft daraus einen Themenbaum. Das lohnt sich besonders, wenn der Bot dieselbe Grundfrage immer wieder verfehlt.

Persona-Varianten vergleichen

Mit einem kurzen Experiment treffen Sie Tonentscheidungen auf Basis von Belegen. Schreiben Sie in die Anweisungen Variante A mit förmlicher Richtliniensprache, speichern Sie, stellen Sie die Frage nach dem Reisekostenlimit und notieren Sie die Antwort. Wechseln Sie dann zu Variante B, einem freundlichen HR-Mitarbeiter mit lockeren Erklärungen, der dabei die Regeln zitiert, und fragen Sie erneut. Dafür genügt das Testfenster.

Vage Antworten als Feedback

Antwortet der Bot auf die Frage, was sich für Hotels abrechnen lässt, nur mit „Fragen Sie die Personalabteilung", ist das ein Hinweis. Vielleicht wurde das Dokument nicht indexiert, vielleicht fehlt in den Trigger-Phrasen der Begriff „Hotelkosten". Prüfen Sie im Wissen-Tab, ob die Datei aktiv ist, und ergänzen Sie „Hotelkosten" als Trigger-Phrase im Reisethema. Kommt danach die Antwort, dass Übernachtungskosten auf 200 Dollar pro Nacht begrenzt sind, ist der Fehler behoben.

Gesprächsstarter nutzen

Leere Eingabefelder lassen Nutzer zögern. Legen Sie deshalb auf der Übersichtsseite drei bis fünf Gesprächsstarter fest, zum Beispiel: „Wie hoch ist das Hotel-Limit?", „Wie reiche ich Reisekostenanträge ein?" oder „Welche Mahlzeiten werden erstattet?". So testen Sie echte Pfade schneller, und Nutzer erkennen die Rolle des Bots, bevor sie etwas tippen.

Veröffentlichen und Kanäle: Wenn der Agent öffentlich wird

Veröffentlichen ist mehr als ein Klick. Der Schritt bestimmt, wer Ihren Agenten erreicht, wie der Zugriff erfolgt und wie Antworten erscheinen. Jeder Kanal hat seine Eigenheiten. Eine präzise Studio-Antwort kann in Teams plötzlich zu „Ich verstehe das nicht" werden, obwohl sich am Bot nichts geändert hat. Der Grund liegt darin, wie Teams Text umbricht und Metadaten überträgt. SharePoint hat eigene Regeln beim Zeilenabstand, und die Demo-Webseite stellt Formatierungen womöglich anders dar als das Studio. Jedes Ziel müssen Sie separat testen.

Die Veröffentlichungs-Checkliste

1. Index: Stellen Sie sicher, dass die Wissensdateien vollständig indexiert sind.
2. Authentifizierung: Konfigurieren Sie sie. Für eine breite Demo wählen Sie keine Authentifizierung, damit jeder mit dem Link den Bot ausprobieren kann.
3. Veröffentlichen: Achten Sie auf das grüne Bestätigungs-Banner oder das Status-Update auf der Kanalseite.
4. Demo-Webseite: Aktualisieren Sie in den Kanaleinstellungen Willkommensnachricht und Gesprächsstarter.
5. Geschlossener Pilot: Geben Sie den Agenten zunächst nur einer kleinen Gruppe frei, nicht dem gesamten Mandanten.

Der Pilotbetrieb

Die Pilotgruppe sollte wissen, dass sie die Testrunde ist. Bitten Sie sie, lockere Sprache zu verwenden, Tippfehler einzubauen und sinnvolle Dateien hochzuladen. Ihre Fehler zeigen die Schwachstellen, bevor der Bot unternehmensweit läuft. Wiederholen Sie dabei alle Szenarien aus dem Studio in jedem Zielkanal: formale Anfragen, lockere Formulierungen, Tippfehler und belegte Zitate. Prüfen Sie, ob Teams anders darstellt, wie SharePoint Abstände verändert und ob die Web-Demo das Quellzitat weiterhin anzeigt.

Nach dem Livegang überwachen

Sobald der Bot läuft, fließen Nutzungsdaten. Das Power Platform Admin Center und die integrierten Analysen zeigen Nutzerzahlen, Fehlerraten und auch Konversationen, in denen kein Thema ausgelöst wurde. Das ist kein Mehraufwand, sondern Ihr Überwachungssystem. Veröffentlichen markiert nicht das Ende, sondern den Beginn des Feldeinsatzes. Erst wenn Pilotdaten und Protokolle zeigen, dass Nutzer überall saubere Antworten erhalten, dürfen Sie den Agenten als stabil bezeichnen.

Häufige Fehler und Stolpersteine

• Nur sauber formulierte Fragen testen: Ohne lockere Varianten und Tippfehler entsteht falsche Sicherheit.
• Kein Grounding: Der Bot rät und erfindet Limits oder Regeln.
• Auf Conversation Boosting vertrauen: Es ersetzt keine Wissensquelle.
• Persona leer lassen: Standardname und Standardbegrüßung wirken wie ein Prototyp.
• Index nicht abwarten: Frisch hochgeladene Dateien liefern womöglich noch keine Treffer.
• Nur im Studio testen: Teams, SharePoint und Web-Demo verhalten sich jeweils anders.
• Ohne Pilot ausrollen: Der Schaden an Vertrauen ist größer als der Aufwand für eine Testrunde.

Praktische Takeaways und Fazit

• Führen Sie den Drei-Variationen-Test durch und erweitern Sie Themen um Synonyme und lockere Formulierungen.
• Stützen Sie den Agenten auf echte, verifizierte Quellen und achten Sie auf das Zitat in der Antwort.
• Beschränken Sie kritische Themen auf Ihre eigenen Wissensquellen.
• Legen Sie Name (max. 30 Zeichen), Beschreibung, Tonfall und Verhaltensregeln im Anweisungsfeld fest.
• Passen Sie Begrüßung, Icon und drei bis fünf Gesprächsstarter an.
• Debuggen Sie systematisch: reproduzieren, zurücksetzen, Thema und Index prüfen, korrigieren, erneut ausführen.
• Testen Sie jeden Zielkanal einzeln und starten Sie mit einem geschlossenen Pilot.
• Überwachen Sie nach dem Livegang Nutzungsdaten und Fehlerraten.

Fazit

Ein zuverlässiger Copilot Studio Agent entsteht in drei Schritten. Er braucht eine fundierte Wissensbasis, damit er nicht rät, eine klar definierte Persona, damit Nutzer ihm vertrauen, und einen Testprozess, der über das Studio hinausgeht. Wer außerdem einen geschlossenen Pilot fährt und nach der Veröffentlichung weiter beobachtet, erhält einen Bot, der Vertrauen schafft, statt Tickets zu erzeugen.