Fehlerbehebung
Grenzen Sie Fehler bei Veröffentlichung, Wissen, Einbettung, Sprache, Connectors, Domains, Abrechnung und API sicher ein.
Grenzen Sie Fehler bei Veröffentlichung, Wissen, Einbettung, Sprache, Connectors, Domains, Abrechnung und API sicher ein.
Mit einem reproduzierbaren Fall beginnen#
Halten Sie vor jeder Änderung an den Einstellungen Folgendes fest:
- Den Workspace bzw. die Website, die öffentliche Route oder den API-Endpunkt sowie die genaue Uhrzeit mit Zeitzone.
- Erwartetes und tatsächliches Ergebnis.
- Browser/Gerät oder externer Provider-Channel.
- Ob der Fehler die Vorschau des Owners, die übrig gebliebene gehostete Demoseite, die Einbettung, einen Connector und/oder die API betrifft.
- Unbedenklichen Status-/Fehlertext, die
x-request-idder Antwort, den letzten Fehler des Connectors oder die Zustellungsereignis-ID des Providers. - Den Zeitpunkt, zu dem zuletzt alles funktionierte, und die kleinste letzte Änderung.
Geben Sie keine API-/Provider-/Connector-Zugangsdaten im Klartext, keine Webhook-Secrets, keine privaten Kundendaten, keine vollständigen Authorization-Header und keine unnötigen Gesprächsinhalte an.
Änderungen an der Website erscheinen nicht#
- Prüfen Sie, ob die Dashboard-URL zur vorgesehenen Website und zum richtigen Workspace gehört.
- Prüfen Sie, ob die Speicheraktion Erfolg gemeldet hat.
- Anweisungen und indexiertes Wissen gelten ohne erneute Veröffentlichung für neue Gespräche. Wenn das Widget selbst ausgeblendet ist, aktivieren Sie es wieder über das Menü Put it live auf der Agent-Seite → Website widget (oder über die Karte On your website auf dem Tab Overview).
- Änderungen an den Display-Einstellungen (und am Branding-Badge) werden automatisch gespeichert und aktualisieren die Live-Einbettung bereits – überspringen Sie die erneute Veröffentlichung und öffnen Sie ein privates Fenster.
- Öffnen Sie eine echte Einbettung (oder einen übrig gebliebenen gehosteten Slug, falls Sie noch einen haben) in einem privaten Fenster.
- Wenn nur eine Social-Vorschau veraltet ist, verwenden Sie den Cache bzw. Debugger der jeweiligen Plattform.
Die Veröffentlichung zurückzuziehen und Bearbeiten sind zwei verschiedene Dinge. Ein verbundener Messaging-Connector kann weiterhin antworten, auch wenn die Einbettung deaktiviert ist.
Die Antwort des Agents ist schwach oder falsch#
Stellen Sie dieselbe Frage im Tester für Owner und in einem neuen öffentlichen Gespräch. Prüfen Sie, ob die relevante Wissensquelle indexiert wurde, eine eindeutige Antwort enthält, aktuell ist und keiner anderen Quelle widerspricht. Prüfen Sie die Sprach- und Persona-Regeln auf eine Grenze, die die Antwort verhindert.
Wenn die Quelle keine Antwort enthält, verbessern Sie das Fallback-/Eskalationsverhalten, statt den Agent anzuweisen zu raten. Nutzen Sie Wissensquellen, um ein Abnahme-Set aus direkten Fragen, Umformulierungen und Grenzfällen zu erstellen.
Der Launcher der Einbettung fehlt oder wird blockiert#
Prüfen Sie, ob die Website veröffentlicht und die Einbettung aktiviert ist, ob das Skript den exakten Site-Slug enthält und ob der endgültige übergeordnete Origin des Browsers – einschließlich Schema, Hostname und Port – in der Allowlist steht. Untersuchen Sie in den DevTools die Anfrage an embed.js, CSP-Fehler, den Status des Consent-Managers, die iframe-Anfrage und das Vorhandensein genau eines data-maf-embed-Roots.
Wenn Text funktioniert, das Mikrofon aber nicht, prüfen Sie HTTPS, die Browserberechtigung, die allow-Berechtigung des iframes und die Permissions Policy des Hosts. Folgen Sie der vollständigen Übersicht zur Einbettung und Sicherheit und CSP.
Sprache funktioniert nicht#
Grenzen Sie den fehlerhaften Modus ein: Sprachnachricht, Live-Anruf oder Connector-Sprache. Ein funktionierender Textpfad belegt nur, dass der Schlüssel für das Sprachmodell in Ordnung ist.
Prüfen Sie die Schlüssel für Transkription, TTS und Echtzeit-Provider unabhängig voneinander; prüfen Sie anschließend den Anspruch laut Tarif, das Credit-Guthaben, das Kontingent an Live-Minuten, die Browserberechtigung und die konfigurierten Sprachen. Testen Sie eine kurze, saubere Aufnahme, bevor Sie eine lange oder verrauschte Datei untersuchen.
Der Connector empfängt keine Nachrichten#
Nutzen Sie die Kanalanleitung und vergleichen Sie beide Seiten. Prüfen Sie, ob der Connector aktiviert ist, die Zugangsdaten weiterhin validiert werden, die Webhook-/Interaktions-/Skill-URL beim Provider die aktuelle ist, das erforderliche Ereignis bzw. die erforderliche Page, Nummer oder der erforderliche Block abonniert ist, der App-Modus den Testnutzer einschließt und die Zustellung über öffentliches HTTPS gelingt.
Eine erfolgreiche Webhook-Verifizierung belegt weder das Abonnement der Laufzeitereignisse noch die Berechtigungen für ausgehende Nachrichten. Vergleichen Sie die Zustellungsprotokolle des Providers mit Last message und dem gespeicherten Fehler des Connectors. Testen Sie zuerst Text, dann Sprache.
Eigene Domains werden nicht angeboten#
Wir verkaufen keine Kundendomains und verbinden sie auch nicht. Platzieren Sie den Agent per Einbettung auf der Website, die Sie bereits haben. Übrig gebliebene Ereignisse des Polar-Domain-Add-ons werden ignoriert oder storniert und erzeugen niemals Credits.
API-Anfrage schlägt fehl#
Notieren Sie Methode, versionierten Pfad, Status, stabilen Fehlercode, die x-request-id der Antwort und relevante Rate-Limit-Header. Ordnen Sie den Fehler dann ein:
| Status | Wahrscheinlichste Maßnahme |
|---|---|
400 | JSON-/Formularstruktur oder Validierungsdetails korrigieren; nicht unverändert wiederholen |
401 | Gültige, nicht abgelaufene und nicht widerrufene MAF-Zugangsdaten verwenden; niemals einen Provider-Schlüssel verwenden |
403 | Erforderlichen Scope hinzufügen oder Zugriff auf Tarif/Ressource wiederherstellen |
404 | Prüfen, ob die ID zum authentifizierten Workspace gehört und der Pfad korrekt ist |
409 | Zustandskonflikt beheben oder denselben Idempotency-Key mit derselben Payload erneut senden |
415 | Den dokumentierten Content-Type senden |
429 | retry-after-/Reset-Header mit Jitter beachten; keine Busy-Loop verwenden |
500 | Sichere/idempotente Anfrage wiederholen und Request-ID sowie Zeitpunkt aufbewahren |
Nutzen Sie Zugangsdaten und Token, Scopes und Fehler und Rate Limits. Beheben Sie einen API-Fehler niemals, indem Sie Server-Zugangsdaten in Browsercode verlagern.
Abrechnung oder Nutzung wirkt falsch#
Unterscheiden Sie zwischen Plattformzugang, monatlichen Credits, gekauften Credits, Anzahl der Websites, Live-Minuten, API-Rate, Messaging-Channels (Operate+) und BYOK/Team (Scale). Eine Aufladung ändert nur die Credits. Die Gebühren des BYOK-Providers sind von der Abrechnung von Make Agent Fast getrennt.
Bei unerwarteter Nutzung sollten Sie vor der Untersuchung die wahrscheinliche Quelle eindämmen: einen Connector deaktivieren, einen Schlüssel widerrufen, einen unbeabsichtigten Einbettungs-Origin entfernen oder eine API-Wiederholungsschleife stoppen. Bewahren Sie Zeitraum sowie Request-/Provider-IDs auf, ohne Secrets preiszugeben.
Sichere Support-Details sammeln#
Wenn Sie weiterhin blockiert sind, nutzen Sie das Feedback-Element in der passendsten Anleitung oder kontaktieren Sie den Support über das Dashboard und geben Sie Folgendes an:
- Kennung von Website/Workspace und betroffene Funktion.
- Exakten Zeitstempel/Zeitzone und reproduzierbare Schritte.
- Erwartetes und tatsächliches Ergebnis.
- Öffentliche URL ohne Secrets, sofern relevant.
- HTTP-Status, stabilen Fehlercode,
x-request-idoder Provider-Ereignis-ID. - Geschwärzten Screenshot oder minimale Payload ohne Secrets und personenbezogene Daten.
Geben Sie an, was Sie bereits geprüft haben. So vermeiden Sie wiederholte Einrichtungstipps und machen die Fehlergrenze klar.