Autonome Agenten von Anfang bis Ende

Für: Kontoinhaber und Entwickler, die andere Systeme mit dem Assistenten verbinden·Voraussetzung: Die Rolle Admin zum Einrichten (Agenten ansehen kann jeder angemeldete Benutzer); für Tokens die Anmeldung eines Unternehmensadministrators und ein Endnutzer mit PIN oder Passwort·Screenshots zeigen Beispieldaten

Manche Arbeit für Ihren Assistenten beginnt nicht damit, dass ein Besucher tippt. Eine Rechnung wird in Ihrem Abrechnungssystem überfällig, eine Zahlung scheitert, ein Wochenbericht steht an. Mit autonomen Agenten startet dieses andere System einen KI-Agenten mit einem einzigen Webhook-Aufruf: Der Agent liest die Daten des Aufrufs, arbeitet mit denselben Tools und Anweisungen wie eines Ihrer Widgets und gibt das Ergebnis zurück.

Was es tut

Ohne autonome Agenten wartet jedes Ereignis, das das Urteil des Assistenten braucht, darauf, dass jemand einen Chat öffnet und die Details einfügt. Das ist langsam, und diese Person muss wissen, welche Fragen zu stellen und welche Tools zu nutzen sind.

Mit autonomen Agenten ruft Ihr System die Webhook-Adresse des Agenten mit einem benutzerspezifischen Zugriffstoken und einem JSON-Body auf. StrikeUp füllt den Prompt des Agenten aus dem Body, lässt den Agenten im Namen des Endnutzers laufen, dem das Token gehört, und gibt die Antwort sofort zurück, über eine Statusadresse oder an Ihre eigene Rückrufadresse. Daraus folgt:

• Sie bestimmen mit einem Prompt, der den Body liest, was der Agent tut. In 7 Schritten einrichten.
• Jeder Endnutzer hat sein eigenes Token, und jeder Lauf wird ihm zugeordnet. Tokens je Endnutzer.
• Ihr System entscheidet, ob es auf die Antwort wartet oder sie später abholt. Warten oder später abholen.
• Sie verfolgen jeden Lauf beim Agenten und als Job mit Schritten und Ereignissen. Autonome Läufe in StrikeUp.

Jeder Lauf wird mit Status, Kunde, Ausgabe oder Fehler und seinen KI-Kosten aufgezeichnet, und der Job dahinter hält einen Zeitverlauf jedes Schritts fest.

Bevor Sie beginnen

Voraussetzung	Details
Rolle	Agenten unter Konfigurieren › Autonome Agenten anlegen erfordert die Rolle Admin; alle anderen angemeldeten Benutzer können sie ansehen.
Ein Widget mit Toolkit	Der Agent arbeitet mit Toolkit, Skills, Anweisungen, Leitplanken und Budgets eines Widgets. Richten Sie diese zuerst am Widget ein.
Die Anmeldung eines Unternehmensadministrators	Ein Zugriffstoken zu erstellen braucht ein Admin-Token aus einer Anmeldung über die API.
Ein Endnutzer mit PIN oder Passwort	Jedes Zugriffstoken gehört einem aktiven Kunden Ihres Kontos mit PIN oder Passwort. Kunden stehen unter CRM › Kunden.
Ein System, das HTTPS-Anfragen senden kann	Ihr Abrechnungssystem, ein Skript oder ein Automatisierungswerkzeug.
Kosten	Die KI-Aufrufe jedes Laufs zählen als Nutzung Ihrer Agenten, zugeordnet zu Agent und Endnutzer, und zählen zu Ihren Budgets.

Gut zu wissen

Ein autonomer Agent hat keinen eigenen Zeitplan. Er läuft nur, wenn etwas seinen Webhook aufruft; den Zeitpunkt bestimmt also das aufrufende System.

Einen Lauf verstehen

Ein Lauf durchläuft diese Status. Die Laufliste des Agenten und die Abfrage-Antwort zeigen sie wie unten; der Job unter Agentenjobs nutzt eigene Bezeichnungen.

Status	Was geschieht	Typisches Beispiel	Erneut abfragen nach
Pending	Angenommen, noch nicht gestartet	Direkt nach dem Aufruf	2 Sekunden
Running	Der Agent arbeitet	Er sucht die Rechnung	2 Sekunden
WaitingForApproval	Ein Tool braucht eine Freigabe, bevor der Agent weitermacht	Eine Gutschrift ausstellen	30 Sekunden
WaitingForInput	Der Agent hat eine Frage gestellt und wartet auf eine Rückmeldung	Welcher Rechnungskontakt gilt	30 Sekunden
Completed	Fertig; die Ausgabe liegt vor	Eine entworfene Zahlungserinnerung	—
Failed	Mit einem Fehler beendet	Die Rechnung existiert nicht	—

Wie StrikeUp einen Aufruf behandelt

1. Das Token wird geprüft. Es muss für Ihr Konto gelten und darf nicht widerrufen sein; sein Endnutzer muss ein aktiver Kunde sein.
2. Der Agent wird geprüft. Er muss existieren und aktiv sein.
3. Die Ratenbegrenzungen werden geprüft. Jeder Endnutzer kann 5 Läufe pro Minute starten. Eine aufrufende Adresse kann 300 Aufrufe pro Minute an Ihr Konto senden, Laufstarts und Statusabfragen zusammen; diese Grenze wird schon vor dem Token geprüft.
4. Der Prompt wird gefüllt. Jede Variable {{payload.path}} wird aus dem JSON-Body ersetzt. Jeder Wert wird als Daten markiert, sodass Text im Body nie als Anweisung befolgt wird.
5. Der Lauf startet mit eigener Chat-Sitzung und einem Job mit dem Auslöser Webhook, zugeordnet dem Endnutzer des Tokens.
6. Der Agent arbeitet durch die normale Verarbeitung des Widgets: Leitplanken, Planung, Toolkit, Skills und die geltenden Budgets.
7. Das Ergebnis geht zurück in der Antwort, über die Statusadresse oder an Ihre Rückrufadresse.

Was keinen Lauf startet

• Ein Aufruf ohne Token oder mit einem widerrufenen oder unbekannten (HTTP 401).
• Ein Aufruf an einen pausierten Agenten (HTTP 403 “Agent is disabled”) oder für einen deaktivierten Endnutzer bzw. einen, dessen Unternehmen deaktiviert ist (HTTP 403 “Customer is not active”).
• Ein Aufruf für einen Agenten oder ein Konto, das es nicht gibt (HTTP 404).
• Ein Body über 64 KB (HTTP 413).
• Ein sechster Aufruf für denselben Endnutzer innerhalb einer Minute (HTTP 429).
• Mehr als 300 Aufrufe in einer Minute von einer aufrufenden Adresse an Ihr Konto, Laufstarts und Statusabfragen zusammen (HTTP 429 “Too many requests. Please wait a minute and try again.”).
• Ein Aufruf, während ein durchgesetztes Budget für das Widget oder das Unternehmen des Endnutzers aufgebraucht ist: Der Lauf wird abgewiesen.

In 7 Schritten einrichten

1. Das Widget vorbereiten. Stellen Sie sicher, dass das Widget ein Toolkit mit den nötigen Tools sowie die passenden Skills und Anweisungen hat.

2. Den Agenten anlegen. Öffnen Sie Konfigurieren › Autonome Agenten, wählen Sie Neu, geben Sie einen Name ein, wählen Sie Widget und Antwortmodus und dann Agent erstellen.

3. Den Prompt schreiben. Fügen Sie einen Beispiel-Body in Beispiel-Payload (JSON) ein, setzen Sie seine Felder als Variablen {{payload.…}} ein und sagen Sie, was der Agent tun und zurückgeben soll. Speichern Sie.

   

   Der Prompt sagt dem Agenten, was zu tun ist; {{payload…}}-Variablen übernehmen Werte aus dem Webhook-Body.

   Was dieser Screenshot zeigt

   Ansicht

   Prompt (/admin/configure/autonomous-agents)

   Hervorgehoben

   textbox “”, prompt, filled. defines the agent's task

   Außerdem sichtbar

   Widget Demo Ltd Support chat; Async (202); Active

   Zweck

   step 2 — the prompt

4. Als Unternehmensadministrator anmelden. Kopieren Sie im Bereich Webhook des Agenten die Anfrage unter 1. Als Unternehmensadministrator anmelden mit Anmeldung kopieren und senden Sie sie mit Ihrer Admin-E-Mail und Ihrem Passwort. Behalten Sie das token aus der Antwort; es gilt etwa eine Stunde.

5. Das Token des Endnutzers erstellen. Kopieren Sie die Anfrage unter 2. Token erstellen (Unternehmensadministrator) mit Austausch kopieren, tragen Sie die externalUserId des Endnutzers und seine PIN oder sein Passwort als credential ein und senden Sie sie mit dem Admin-Token. Bewahren Sie das Token ahu_… aus der Antwort auf; es wird nur einmal angezeigt.

6. Den Agenten aufrufen. Kopieren Sie die Anfrage unter 3. Agenten auslösen mit curl kopieren, setzen Sie das Token des Endnutzers in den Header Authorization: Bearer, fügen Sie Ihren JSON-Body hinzu und senden Sie sie. Kopieren Sie die im Bereich gezeigte URL; tippen Sie sie nicht ab.

7. Das Ergebnis abholen. Bei einem synchronen Agenten enthält die Antwort die Ausgabe. Bei einem asynchronen fragen Sie den Lauf mit der Anfrage unter 4. Ergebnis abrufen ab oder senden in Schritt 6 einen Header X-Callback-Url.

Empfohlene Einführung

Beginnen Sie mit einem Agenten im Modus Synchron (200) und einem Test-Endnutzer, und rufen Sie ihn von Hand auf, bis Ausgabe anzeigen die gewünschten Antworten zeigt. Stellen Sie dann auf Asynchron (202) um, verbinden Sie das echte System und beobachten Sie Letzte Ausführungen und die Jobs eine Woche lang, bevor Sie weitere Agenten hinzufügen.

Alle Einstellungen erklärt

Jede Einstellung unten sagt, wo sie ist, was sie bewirkt und warum sie für das aufrufende System wichtig ist.

Widget, was der Agent kann

Wo

Konfigurieren › Autonome Agenten › der Agent › Widget. Wird mit dem Formular gespeichert.

Was

Der Agent nutzt Haupt-Toolkit, Skills, Anweisungen, Leitplanken und Budgets dieses Widgets. Ein Widget ohne Toolkit zeigt im Formular eine Warnung, und Läufe damit scheitern mit “Server ID is required”. Läufe lesen und schreiben das Chat-Gedächtnis des Endnutzers nicht.

Warum

Sie richten die Fähigkeiten eines Agenten einmal an einem Widget ein, und es gelten dieselben Regeln wie im Chat.

Öffnen Sie einen Agenten, um seinen Prompt zu bearbeiten und die Webhook-Angaben zu erhalten.

Was dieser Screenshot zeigt

Ansicht

Agenten (/admin/configure/autonomous-agents)

Hervorgehoben

“”, agent-cards, Active. opens the agent editor

Außerdem sichtbar

Weekly usage digest (Active), Failed payment triage (Disabled)

Zweck

step 1 — the agent

Prompt, was der Agent tun soll

Wo

Der Prompt des Agenten, mit Beispiel-Payload (JSON) und den Variablen-Schaltflächen. Wird mit dem Formular gespeichert.

Was

Pflicht. Variablen {{payload.path}} mit doppelten Klammern werden beim Start des Laufs aus dem JSON-Body ersetzt; Punktpfade und Listenpositionen [n] funktionieren. Ein fehlendes Feld wird leer. Jeder Wert ist auf 4.000 Zeichen begrenzt. Ist der Body kein gültiges JSON, bleibt der Prompt unverändert.

Warum

Ein Agent behandelt jedes Ereignis einer Art, mit den Details jedes Ereignisses eingesetzt.

Empfehlenswert	Zu vermeiden
Sagen, was zurückkommen soll: „Antworte nur mit dem Text der Erinnerung.“	Das Ausgabeformat offen lassen, wenn ein anderes System es liest
Variablen für jedes Detail, das sich je Aufruf ändert	Beispielwerte aus dem Testaufruf in den Prompt schreiben
Den Agenten anhalten lassen, wenn ein wichtiger Wert leer ist	Annehmen, dass jeder Aufrufer jedes Feld sendet

Warten oder später abholen

Wo

Antwortmodus des Agenten. Ein Aufrufer kann außerdem ?wait=true an die Webhook-Adresse hängen, um einmal zu warten.

Was

Asynchron (202) (Vorgabe): Der Aufruf gibt sofort HTTP 202 mit executionId, status “Running”, statusUrl und einem Location-Header zurück. Synchron (200): Der Aufruf wartet bis zu 6 Minuten und gibt HTTP 200 mit executionId, chatSessionId, status, output und, falls der Lauf wartet, pendingApprovalIds zurück. Ein gescheiterter synchroner Lauf gibt HTTP 500 mit dem Fehler zurück; ein längerer gibt HTTP 504 “Agent execution timed out” zurück und wird abgebrochen.

Warum

Kurze Aufgaben sind am einfachsten, wenn der Aufrufer wartet. Lange Aufgaben und solche, die auf eine Freigabe warten können, brauchen den asynchronen Modus.

Situation	Wählen Sie
Der Aufrufer braucht die Antwort in derselben Anfrage, und die Aufgabe dauert Sekunden	Synchron (200)
Die Aufgabe kann Minuten dauern oder auf eine Freigabe warten	Asynchron (202)
Der Aufrufer kann keine Verbindung offen halten	Asynchron (202) mit Rückrufadresse

Tokens je Endnutzer, wessen Lauf es ist

Wo

Über die API erstellt in den Schritten 4 und 5; gelistet und widerrufen unter Konfigurieren › Autonome Agenten › Zugriffstokens.

Was

Jedes Token gehört einem Endnutzer, gilt für jeden Agenten des Kontos, läuft nie ab und wird nur einmal angezeigt. Senden Sie es als Authorization: Bearer ahu_… oder im Header X-Autonomous-Token. Jeder Lauf wird dem Endnutzer des Tokens zugeordnet. Eine geänderte PIN des Endnutzers widerruft seine Tokens nicht; das tut nur das Widerrufen.

Warum

Jeder Lauf gehört einem echten Kunden; seine Kosten, Jobs und Freigaben gehören damit ebenfalls diesem Kunden.

Jeder Endnutzer erhält ein eigenes Token, erstellt mit seiner PIN oder seinem Passwort; jede Ausführung wird ihm zugeordnet.

Was dieser Screenshot zeigt

Ansicht

Webhook (/admin/configure/autonomous-agents)

Hervorgehoben

button “Austausch kopieren”, webhook-step-2, enabled. copies the token request

Außerdem sichtbar

Steps 2 and 3 with curl commands

Zweck

step 3 — the per-user token

Aktiv, der Ausschalter

Wo

Der Schalter Aktiv des Agenten, beim Bearbeiten. Wird mit dem Formular gespeichert.

Was

Aus: Neue Aufrufe werden mit HTTP 403 “Agent is disabled” abgewiesen. Bereits gestartete Läufe bleiben per Abfrage lesbar.

Warum

Einen Agenten sofort stoppen, etwa wenn das aufrufende System sich fehlerhaft verhält, ohne ihn zu verlieren.

Wie die Einstellungen zusammenwirken

Modus	?wait=true	X-Callback-Url	Was der Aufrufer erhält
Asynchron	Nein	Nein	HTTP 202 mit Lauf-ID; Ergebnis abfragen
Asynchron	Nein	Ja	HTTP 202 mit Lauf-ID; das Ergebnis wird an Ihre Adresse gesendet, wenn der Lauf endet
Asynchron	Ja	Ignoriert	Die Antwort in der Antwort, wie synchron
Synchron	Beliebig	Ignoriert	Die Antwort in der Antwort, bis zu 6 Minuten

Was sollte ich wählen?

Wählen Sie asynchron mit Abfragen, sofern Sie nicht wissen, dass jeder Lauf in Sekunden fertig ist. Abfragen funktioniert immer, auch wenn Ihre Rückrufadresse ausfällt; ergänzen Sie eine Rückrufadresse, sobald das Abfragen läuft.

Das Ergebnis erhalten

Die Statusadresse abfragen

Fragen Sie die statusUrl aus der 202-Antwort oder die Anfrage unter 4. Ergebnis abrufen mit demselben Token ab, das den Lauf gestartet hat.

Ein asynchroner Agent antwortet sofort mit einer Ausführungs-ID; das Ergebnis holen Sie per Statusabfrage oder Callback-URL.

Was dieser Screenshot zeigt

Ansicht

Webhook (/admin/configure/autonomous-agents)

Hervorgehoben

button “Statusabfrage kopieren”, webhook-step-4, enabled. copies the status request

Außerdem sichtbar

Async note, step 4 and callback note

Zweck

step 4 — collecting the result

Antwort	Bedeutung	Nächster Schritt
HTTP 200, status “Running” oder “Pending”, Retry-After: 2	Arbeitet noch	Nach 2 Sekunden erneut abfragen
HTTP 200, status “WaitingForApproval” mit pendingApprovalIds, Retry-After: 30	Eine Freigabe steht aus	Nach 30 Sekunden erneut abfragen
HTTP 200, status “WaitingForInput”, Retry-After: 30	Eine Rückmeldung steht aus	Nach 30 Sekunden erneut abfragen
HTTP 200, status “Completed” mit output	Fertig	Die Ausgabe nutzen
HTTP 200, status “Failed” mit error	Mit Fehler beendet	Den Fehler lesen
HTTP 404 “Run not found”	Unbekannter Lauf, Lauf eines anderen Agenten oder eines anderen Endnutzers	IDs und Token prüfen

Ein Token sieht nur die Läufe seines eigenen Endnutzers. Die Läufe eines pausierten Agenten bleiben lesbar.

Rückruf an Ihre Adresse

Fügen Sie einem asynchronen Aufruf einen Header X-Callback-Url mit einer HTTPS-Adresse hinzu. Endet der Lauf, sendet StrikeUp einen POST dorthin, mit demselben Body wie eine Abfrage und dem Header X-StrikeUp-Event: autonomous.run.finished.

• Ein Rückruf pro Lauf, wenn er abschließt, scheitert oder auf eine Freigabe zu warten beginnt. Einen zweiten Rückruf beim Weiterlaufen gibt es nicht.
• 3 Versuche zu je 10 Sekunden, mit wachsender Pause dazwischen. Scheitern alle, fragen Sie stattdessen ab.
• Nur öffentliches HTTPS. Eine Adresse, die nicht HTTPS ist oder nicht im öffentlichen Internet liegt, wird ohne Fehler im Aufruf ignoriert.

Autonome Läufe in StrikeUp

Wo	Was es zeigt	Welche Daten
Die Karte des Agenten	{{count}} Ausführungen	Alle Läufe
Letzte Ausführungen beim Agenten	Status, Kunde, Fehler und Ausgabe	Die letzten 20 Läufe
Analysen › Agentenjobs	Ein Job je Lauf, nach Auslöser filterbar	Alle Läufe
Die Detailseite des Jobs	Übersicht, Ergebnis, Schritte, Freigaben, Ereignisse	Ein Lauf
KI-Ausgaben	Kosten nach autonomem Agenten und nach Kunde	Der gewählte Zeitraum

Letzte Läufe beim Agenten

Die Laufliste des Agenten zeigt für jeden Lauf Status, Start und Ende, den Kunden und einen etwaigen Fehler, mit Ausgabe anzeigen für die Antwort.

Warum: Die schnellste Prüfung, was ein Agent getan hat, ohne das aufrufende System zu öffnen.

Eine Ausführung, die ein freigabepflichtiges Werkzeug erreicht, wartet, bis über die Freigabe entschieden ist.

Was dieser Screenshot zeigt

Ansicht

Letzte Ausführungen (/admin/configure/autonomous-agents)

Hervorgehoben

“”, runs-table, waiting. none

Außerdem sichtbar

Running, Waiting for approval, Completed and Failed runs with customer IDs

Zweck

monitoring runs on the agent

Tab der Zugriffstokens

Der Tab Zugriffstokens listet jedes Token mit der ID seines Endnutzers, Erstellungsdatum und letzter Nutzung und lässt Sie es widerrufen.

Warum: Zeigt, welche Integrationen aktiv sind, und lässt Sie eine sofort abschneiden.

Jedes Token gehört zu einem Endnutzer; widerrufen Sie es hier, wenn eine Integration enden soll.

Was dieser Screenshot zeigt

Ansicht

Zugriffstokens (/admin/configure/autonomous-agents)

Hervorgehoben

“”, token-list, shown. none

Außerdem sichtbar

4 tokens with Created / Last used and Revoke

Zweck

managing tokens

Agentenjobs

Unter Analysen › Agentenjobs ist jeder Lauf ein Job, benannt nach dem Agenten mit Datum und Uhrzeit, mit dem Auslöser Webhook, der Quelle Autonomer Agent und dem Endnutzer als Besitzer. Filtern Sie nach Auslöser, um nur Webhook-Läufe zu sehen. Die Liste ist schreibgeschützt und lädt neu, wenn Sie es wünschen.

Warum: Alle automatisierte Arbeit an einem Ort, mit denselben Status und Kosten wie per Chat gestartete Jobs.

Jede Webhook-Ausführung erscheint auch als Job unter Agentenjobs; der Filter „Webhook“ zeigt nur diese.

Was dieser Screenshot zeigt

Ansicht

Agentenjobs (/admin/agent-jobs)

Hervorgehoben

combobox “”, filters, [object Object]. filters jobs by trigger

Außerdem sichtbar

5 webhook jobs: Running, Needs approval, Failed, Needs an answer, Completed

Zweck

step 5 — monitoring jobs

Jobdetails und Ereignisse

Ein geöffneter Job zeigt Übersicht, Ergebnis, Schritte, Freigaben und den Zeitverlauf Ereignisse: wann der Lauf startete, welchen Plan er machte, jeden Schritt und wo er wartet.

Warum: Scheitert oder wartet ein Lauf, zeigen die Ereignisse den genauen Schritt.

„Ereignisse“ ist der zeitliche Ablauf der Ausführung bis zu dem Schritt, an dem sie wartet.

Was dieser Screenshot zeigt

Ansicht

Ereignisse (/admin/agent-jobs/:id)

Hervorgehoben

“”, events-section, read-only. none

Außerdem sichtbar

Running → plan ready → progress → approval required → WaitingForApproval

Zweck

reading what happened

Budgets und autonome Läufe

Wo

Konfigurieren › Budgets & Limits, ein Budget mit eingeschaltetem Als hartes Limit durchsetzen.

Was

Läufe zählen zu den Budgets für das Konto, das Widget des Agenten und das Kundenunternehmen des Endnutzers. Ist ein durchgesetztes Budget aufgebraucht, wird ein neuer Lauf abgewiesen und als fehlgeschlagen markiert, und ein laufender pausiert mit Pausiert — das KI-Kontingent für diese Periode ist aufgebraucht; der Lauf geht weiter, sobald es zurückgesetzt oder das Limit erhöht wird., bis der Zeitraum neu beginnt oder das Limit erhöht wird.

Warum

Eine Automatisierung kann weit öfter laufen, als Menschen chatten. Ein Budget verhindert, dass ein fehlerhafter Aufrufer die Kosten hochtreibt.

• Geben Sie jeder Integration einen eigenen Endnutzer, damit ihre Kosten auf KI-Ausgaben nach Kunde getrennt erscheinen.
• Setzen Sie ein Tagesbudget auf ein Widget, das nur autonome Agenten nutzen.
• Achten Sie auf Läufe, die nach einer Welle von Aufrufen wegen des aufgebrauchten Kontingents scheitern.

Ein pausierter Lauf ist kein gescheiterter Lauf

Ein vom Budget pausierter Lauf behält seinen Platz und läuft weiter, sobald das Budget es erlaubt. Wiederholen Sie den Aufruf nicht, solange er pausiert, sonst starten Sie einen zweiten Lauf für dasselbe Ereignis.

Was Sie wissen sollten

Thema	Fakt
Auslöser	Nur Webhook-Aufrufe mit benutzerspezifischem Token.
Body	JSON, bis 64 KB; jeder eingefügte Wert bis 4.000 Zeichen.
Synchrone Grenze	6 Minuten, dann HTTP 504; der Lauf wird abgebrochen.
Ratenbegrenzung	5 Läufe je Endnutzer und Minute sowie 300 Aufrufe pro Minute je aufrufender Adresse und Konto, gemeinsam mit den Statusabfragen; dann HTTP 429 mit Retry-After. Token erstellen: 20 Anfragen pro Minute je Adresse.
Abfragen	Dasselbe Token; Retry-After 2 Sekunden während der Arbeit, 30 Sekunden beim Warten.
Rückruf	Nur asynchrone Aufrufe, öffentliches HTTPS, einer pro Lauf, 3 Versuche zu 10 Sekunden.
Tokens	Kein Ablauf, einmal angezeigt, für jeden Agenten gültig, nur auf dem Tab der Tokens widerrufbar.
Gedächtnis	Läufe lesen und schreiben nie das Chat-Gedächtnis des Endnutzers.
Ausfall	Fallen alle KI-Anbieter aus, scheitert der Lauf mit “The assistant is temporarily unavailable. Please try again shortly.”
Löschen eines Agenten	Entfernt ihn und seine Laufliste; Chat-Sitzungen und Jobs bleiben.
Kosten	Agent und Endnutzer zugeordnet; zählen zu Budgets.

Häufige Fragen

Allgemein

Wofür ist ein autonomer Agent da?

Ein autonomer Agent lässt ein anderes System einen KI-Agenten mit einem einzigen Webhook-Aufruf starten, ohne dass jemand chattet. Ihr Abrechnungssystem, ein Skript oder ein Automatisierungswerkzeug sendet die Daten des Ereignisses; der Agent bearbeitet sie mit den Tools und Anweisungen eines Widgets und gibt die Antwort zurück.

Kann ein autonomer Agent nach Zeitplan laufen?

Nein. Ein autonomer Agent läuft nur, wenn etwas seinen Webhook aufruft. Soll er täglich oder wöchentlich laufen, lassen Sie das aufrufende System, etwa einen Planer oder ein Automatisierungswerkzeug, den Aufruf zur gewünschten Zeit senden.

Wer kann autonome Agenten einrichten?

Personen mit der Rolle Admin legen Agenten unter Konfigurieren › Autonome Agenten an; alle anderen angemeldeten Benutzer Ihres Kontos können sie ansehen, und ihre Änderungen schlagen fehl mit “This action requires the Admin role.” Ein Zugriffstoken zu erstellen braucht die Anmeldung eines Unternehmensadministrators über die API und PIN oder Passwort des Endnutzers.

Den Agenten aufrufen

Soll ich asynchron oder synchron nutzen?

Nutzen Sie Synchron (200), wenn die Aufgabe Sekunden dauert und der Aufrufer bis zu 6 Minuten warten kann. Nutzen Sie Asynchron (202) für längere Aufgaben und solche, die auf eine Freigabe warten können; der Aufruf gibt sofort eine Lauf-ID zurück, und Sie holen das Ergebnis ab.

Wie erhalte ich das Ergebnis eines asynchronen Laufs?

Fragen Sie die statusUrl aus der HTTP-202-Antwort mit demselben Token ab, bis der Status “Completed” oder “Failed” ist, oder senden Sie mit dem Aufruf einen Header X-Callback-Url, damit StrikeUp das Ergebnis an Ihre HTTPS-Adresse sendet, wenn der Lauf endet.

Wie oft soll ich abfragen?

Folgen Sie dem Header Retry-After: 2 Sekunden, solange der Lauf aussteht oder arbeitet, 30 Sekunden, solange er auf eine Freigabe oder eine Rückmeldung wartet. Schnelleres Abfragen bringt nichts und zählt trotzdem als Nutzung des Tokens. Es zählt außerdem zur Grenze von 300 Aufrufen pro Minute je aufrufender Adresse, die sich die Abfragen mit den Laufstarts teilen.

Wie groß darf der Body sein?

64 KB. Ein größerer Body wird mit HTTP 413 abgewiesen. Jeder in den Prompt eingefügte Wert ist außerdem auf 4.000 Zeichen begrenzt und wird bei Überlänge mit ” …[truncated]” gekürzt; senden Sie also nur die Felder, die der Agent braucht.

Wie viele Läufe kann ein Endnutzer starten?

5 pro Minute. Ein sechster Aufruf in derselben Minute wird mit HTTP 429 und einem Header Retry-After abgewiesen, und nichts wird gestartet. Verteilen Sie Spitzen oder geben Sie getrennten Integrationen getrennte Endnutzer. Eine aufrufende Adresse kann zudem höchstens 300 Aufrufe pro Minute an Ihr Konto senden, Statusabfragen eingeschlossen.

Kann mein Aufrufer bei einem asynchronen Agenten eine synchrone Antwort erzwingen?

Ja. Hängen Sie ?wait=true an die Webhook-Adresse. Dieser Aufruf wartet dann wie bei einem synchronen Agenten bis zu 6 Minuten auf die Antwort, während andere Aufrufe asynchron bleiben.

Was passiert, wenn ein synchroner Lauf zu lange dauert?

Nach 6 Minuten gibt der Aufruf HTTP 504 “Agent execution timed out” zurück, und der Lauf wird abgebrochen. Stellen Sie den Agenten auf Asynchron (202), wenn seine Aufgaben so lange dauern können.

Tokens

Kann ein Token mehrere Agenten auslösen?

Ja. Ein Zugriffstoken gilt für jeden autonomen Agenten Ihres Kontos. Jeder damit gestartete Lauf wird demselben Endnutzer zugeordnet, egal welchen Agenten er aufruft.

Läuft ein Token ab?

Nein. Ein Token funktioniert, bis es auf dem Tab Zugriffstokens widerrufen wird. Eine geänderte PIN oder ein geändertes Passwort des Endnutzers widerruft es nicht.

Was passiert, wenn der Endnutzer deaktiviert wird?

Aufrufe mit seinem Token werden mit HTTP 403 “Customer is not active” abgewiesen, bis der Kunde wieder aktiv ist. Dasselbe gilt, solange sein Unternehmen deaktiviert ist. Seine früheren Läufe bleiben beim Agenten und als Jobs sichtbar.

Rückrufe

Werden Rückrufe wiederholt?

Ja, bis zu 3 Versuche zu je 10 Sekunden, mit wachsender Pause dazwischen. Scheitern alle Versuche, wird für diesen Lauf kein weiterer Rückruf gesendet; fragen Sie die Statusadresse ab, um das Ergebnis zu erhalten.

Warum kam mein Rückruf nie an?

Die Adresse muss HTTPS nutzen und im öffentlichen Internet liegen; andere Adressen werden ohne Fehler ignoriert. Rückrufe gibt es nur bei asynchronen Aufrufen. Prüfen Sie, ob Ihr Endpunkt innerhalb von 10 Sekunden mit einem Erfolgsstatus antwortet, und fragen Sie den Lauf bis dahin ab.

Gibt es einen zweiten Rückruf, wenn ein wartender Lauf weiterläuft?

Nein. Ein Rückruf wird gesendet, wenn der Lauf endet, auch wenn er zu warten beginnt. Fragen Sie danach die Statusadresse ab, um ihn weiter zu verfolgen.

Läufe und Daten

Was bedeutet Wartet auf Freigabe?

Der Agent hat ein Tool erreicht, das vor der Ausführung eine Freigabe verlangt, und angehalten. Der Lauf geht weiter, sobald über die Freigabe entschieden ist. Die Abfrage-Antwort nennt die wartenden Freigaben in pendingApprovalIds, und der Job zeigt, welches Tool wartet.

Kann das Chat-Gedächtnis des Endnutzers in einen Lauf gelangen?

Nein. Autonome Läufe lesen und schreiben nie das Chat-Gedächtnis des Endnutzers. Jeder Lauf beginnt mit dem Prompt des Agenten, gefüllt aus dem Body des Aufrufs.

Wo erscheinen Läufe in StrikeUp?

Sie erscheinen beim Agenten unter Letzte Ausführungen, als Jobs unter Analysen › Agentenjobs und als Kosten nach autonomem Agenten und nach Kunde auf Dashboard › KI-Ausgaben.

Was ist die chatSessionId in einer synchronen Antwort?

Jeder Lauf erhält eine eigene Chat-Sitzung mit seinem Austausch mit den Tools, benannt nach dem Agenten mit Datum und Uhrzeit. Die chatSessionId bezeichnet sie, etwa wenn Sie sich wegen eines Laufs an den Support wenden.

Was passiert, wenn die KI-Anbieter ausfallen?

StrikeUp wiederholt zuerst und versucht Ausweichmodelle. Fällt jedes Modell aus, scheitert der Lauf mit dem Fehler “The assistant is temporarily unavailable. Please try again shortly.” Rufen Sie den Agenten später erneut auf.

Zählt ein Lauf gegen meine Budgets?

Ja. Die Aufrufe jedes Laufs an KI-Modelle zählen zu den Budgets für Ihr Konto, das Widget des Agenten und das Kundenunternehmen des Endnutzers. Ein aufgebrauchtes durchgesetztes Budget weist neue Läufe ab und pausiert laufende.

Fehlerbehebung

Symptom	Was Sie prüfen sollten
HTTP 401 “Missing access token”	Senden Sie das Token als Authorization: Bearer ahu_… oder in X-Autonomous-Token.
HTTP 401 “Invalid access token”	Das Token wurde widerrufen, falsch übernommen oder gehört zu einem anderen Konto. Erstellen Sie ein neues.
HTTP 401 “Invalid credential” beim Erstellen eines Tokens	ID, PIN oder Passwort des Endnutzers sind falsch, oder der Kunde ist deaktiviert oder gesperrt. Wiederholte Fehler sperren den Kunden eine Weile.
HTTP 429 beim Erstellen eines Tokens	Mehr als 20 Anfragen mit PIN oder Passwort in einer Minute von Ihrer Netzwerkadresse. Warten Sie Retry-After ab.
HTTP 403 “Agent is disabled”	Schalten Sie Aktiv ein und speichern Sie.
HTTP 403 “Customer is not active”	Aktivieren Sie den Kunden oder sein Unternehmen wieder, oder nutzen Sie das Token eines anderen Endnutzers.
HTTP 404 “Agent not found”, oder das Konto wird nicht gefunden	Kopieren Sie die URL erneut aus dem Webhook-Bereich des Agenten; der Agent wurde vielleicht gelöscht.
HTTP 413	Der Body ist größer als 64 KB. Senden Sie weniger Felder.
HTTP 429 “Too many runs for this customer in the last minute.”	Mehr als 5 Läufe für diesen Endnutzer in einer Minute. Warten Sie Retry-After ab.
HTTP 429 “Too many requests. Please wait a minute and try again.”	Mehr als 300 Aufrufe in einer Minute von Ihrer Adresse an dieses Konto; Laufstarts und Statusabfragen zählen zusammen. Warten Sie Retry-After ab und fragen Sie seltener ab.
HTTP 504 “Agent execution timed out”	Der synchrone Lauf dauerte über 6 Minuten. Nutzen Sie den asynchronen Modus.
Lauf scheitert mit “Server ID is required”	Das Widget des Agenten hat kein Toolkit. Verbinden Sie eines oder wählen Sie ein anderes Widget.
Lauf bleibt bei “WaitingForApproval”	Ein Tool wartet auf eine Freigabe. Prüfen Sie den Job unter Agentenjobs oder lassen Sie den Agenten Tools ohne Freigabe nutzen.
Kein Rückruf kommt an	Die Adresse ist kein öffentliches HTTPS, der Aufruf war synchron, oder Ihr Endpunkt ist 3-mal gescheitert. Fragen Sie stattdessen ab.
Variablen stehen wörtlich in der Ausgabe	Nutzen Sie doppelte Klammern und einen Pfad, der im Body existiert.
Eine Änderung schlägt mit Anfrage fehlgeschlagen und “This action requires the Admin role.” fehl	Änderungen auf dieser Seite erfordern die Rolle Admin. Bitten Sie eine Person mit der Rolle Admin, die Änderung vorzunehmen oder Ihnen die Rolle unter Einstellungen › Benutzer zu geben.

Kommen Sie nicht weiter?

Wenden Sie sich an den Support mit dem Namen des Agenten, der executionId oder chatSessionId, dem Zeitpunkt des Aufrufs und dem erhaltenen HTTP-Status. Der Support kann den Lauf, seinen Job, jeden Schritt und den Fehler sehen, mit dem er endete.

Verwandte Seiten

• Autonome Agenten
• Zugriffstokens für autonome Agenten
• Agentenjobs
• Agentenjob
• Budgets & Limits
• Kunden