Zum Inhalt
beta
← Hilfe-Start

Ein Agent verbindet sich nicht oder fängt nicht an

Prüfe den Zugriff, aktualisiere die Werkzeuge des Clients und mach sicher weiter.

Für wen dieser Leitfaden ist
Für wen
Die Verbindung steht, aber der Agent hat nicht getan, was du erwartet hast.
Was Sie erreichen
Eine echte Anfrage erreicht den Hub, und der Agent kann eine bestimmte Aufgabe öffnen.
Auf dieser Seite

Eine Verbindung für neue Chats

Jeder Chat braucht keinen neuen Schlüssel. Die Verbindung liegt im Konto, Profil oder Projekt des Clients. Ein anderes Konto oder eine andere Ausführungsumgebung braucht die eigene Einrichtung.

Lokaler Codex, die CLI und die IDE teilen das Profil des Computers. Für gehostetes ChatGPT oder Work fügst du den Hub unter Plugins hinzu: die bestehende Verbindung oder „+ → Add custom MCP server“, die MCP-Adresse aus dem Hub und OAuth. Einstellungen auf dem Computer verbinden Cloud-Chats nicht von allein.

Ruft ein Agent die API aus einer Cloud-Umgebung auf, braucht diese Umgebung autorisierten Zugriff in ihrer wiederverwendbaren Konfiguration, mit den eigenen Zugangsdaten der vorgesehenen Person. Nimm keinen Schlüssel aus einem anderen Chat und schreib kein Geheimnis ins Repository.

  1. Nach der Einrichtung öffne einen neuen Chat im selben Client und Konto. Bitte ihn, über die bestehende Verbindung get_status aufzurufen und Person und Team zu nennen.
  2. Bitte ihn, die vorgesehene Aufgabe zu lesen. Fehlt das Werkzeug, prüfe das gewählte Plugin, das Profil und den Ausführungsort, bevor du einen weiteren Schlüssel anlegst.
  3. Nutze die gespeicherte Verbindung in späteren Chats. Fehlt der Zugriff, prüfe zuerst Plugin, Konto und Profil; jeder Chat braucht die Einrichtung nicht neu.

Prüfe die Verbindung der Reihe nach

  1. Öffne Agenten im vorgesehenen Team. Such deine Verbindung und prüfe, ob nach dem Anlegen des Schlüssels eine Anfrage kam. „Schlüssel angelegt“ ist nicht „Anfrage erhalten“.
  2. Öffne die Anleitung deines Clients unter Verbindungen noch einmal. Prüfe die vollständige MCP-Adresse und die Autorisierung. Auf einem Freigabebildschirm prüfe Konto, Team und App-Adresse.
  3. Schick die Prüfnachricht von der Einrichtungsseite in der Agenten-App selbst. Bitte den Agenten, Person und Team zu nennen, für die er handelt.
  4. Bitte ihn, eine bestimmte Aufgabe zu öffnen. Kann er das nicht, prüfe das Produkt und den Zugriff deines Kontos. Ein Agent umgeht die Grenzen des Inhabers nicht.
  5. Funktioniert die Verbindung, aber es startet keine Arbeit, bitte den Agenten ausdrücklich, seine Warteschlange zu prüfen oder diese Aufgabe zu bearbeiten. Regelmäßige Warteschlangenprüfungen brauchen einen passenden Modus in der Client-App.

Die Verbindung steht, aber eine Aktion scheitert

„Anfrage erhalten“ bestätigt einen früheren Aufruf. Nach einem Hub-Update kann eine App noch eine ältere Werkzeugliste oder ältere Argumentregeln halten. Der Hub kann den Client nicht aktualisieren und sieht eine Ablehnung nicht, die vor dem Senden passiert.

Du musst nicht jedes Modell aktualisieren und dich nicht nach jedem Hub-Release neu verbinden. Den Werkzeugcache hält die Client-App. Bei einer bekannten Änderung für eine ältere gespeicherte Verbindung zeigt Agenten ihrem Inhaber einen konkreten Hinweis und die Aktualisierungsanleitung. Andere im Team müssen ihre Verbindungen nicht ändern. Den Hinweis zu bestätigen blendet ihn aus; es prüft keinen Chat und widerruft keinen Schlüssel.

  1. Verschwindet ein bisher vorhandenes Werkzeug nach einem Hub-Update, oder lehnt der Client ein gültiges Argument nach alten Regeln ab, aktualisiere die Werkzeuge der bestehenden Verbindung. Für custom MCP in ChatGPT oder Work: Plugins → deine Hub-Verbindung → Refresh, dann ein neuer Chat. Die gespeicherte Autorisierung bleibt; ein Schlüssel pro Chat ist unnötig. Veröffentlichte Plugins können einen anderen Update-Weg haben.
  2. In lokalem Codex, Claude, Cursor oder einer anderen MCP-App aktualisiere die Werkzeugliste oder verbinde neu bzw. starte den Client neu, wie seine Anleitung es sagt, und behalte das bestehende Profil. Einen weiteren Schlüssel anzulegen aktualisiert die Werkzeugdaten nicht.
  • Werkzeuge fehlen: prüfe die gewählte Verbindung, das Konto und das Client-Profil. Einstellungen des lokalen Codex erbt ein gehosteter Chat nicht.
  • Fehler 401: prüfe die Autorisierung. Ist OAuth abgelaufen, melde dich wieder im vorgesehenen Konto und Team an; bei einem Schlüssel von Hand prüfe, dass er noch aktiv ist.
  • Fehler 403: prüfe den Zugriff der Person auf Team, Produkt und Aktion. Frag den Inhaber, wenn es nötig ist. Ein neuer Schlüssel erweitert die Rechte nicht.
  • Ungültige Argumente: prüfe zuerst die eingegebenen Daten und die Anleitung des Werkzeugs. Ein Validierungsfehler allein zeigt nicht, dass der Client ein altes Schema hat.

Was eine gelungene Prüfung zeigt

Im selben Client fang mit Lesen an: ruf get_status auf und prüfe Person und Team, dann get_task mit dem Schlüssel deiner erreichbaren Aufgabe. Änder nichts; next_task taugt nicht als Probe, weil es Arbeit an sich nehmen kann. Nach dem Aktualisieren der Metadaten wiederhole diese Leseaufrufe in einem neuen Chat mit der gespeicherten Verbindung.

Frische Antworten von get_status und get_task bestätigen das Lesen in diesem Client. Sie prüfen nicht das Bearbeiten, die zwischengespeicherten Werkzeuge eines anderen Chats oder jedes Modell. Eine echte vorgesehene Aktion prüfst du extra und liest das Ergebnis danach zurück. Eine alte Anfragezeit, eine geholte Werkzeugliste oder ein bestätigter Hinweis beweisen die Wiederherstellung nicht.

Der Hub weckt externe Apps derzeit nicht. Ein gestoppter Client oder einer ohne geplante Prüfungen kann still bleiben, auch wenn die Zuweisung auf dem Board stimmt.

Läuft ein Agentenschlüssel an mehreren Orten, etwa nach Plan und in einem offenen Chat, bearbeitet nur einer davon eine Aufgabe zur selben Zeit. Hat der Agent in den letzten 90 Minuten an seiner Aufgabe gehandelt, bekommt ein anderer Lauf desselben Schlüssels die Auskunft, dass die Aufgabe schon bearbeitet wird, und nichts Neues. Nach 90 Minuten ohne Aktivität setzt die nächste Prüfung diese Aufgabe fort.

Eine Aktion sicher wiederholen

Prüfe das Ergebnis des Werkzeugs selbst: auch eine erfolgreiche HTTP-Antwort kann isError: true enthalten. Nach einem Timeout oder einem unklaren Ergebnis lies zuerst die Aufgabe oder das andere betroffene Objekt zurück; die Schreibaktion kann schon gelungen sein. Wiederhole nur, wenn das Zurücklesen zeigt, dass die Änderung nicht angewendet wurde. Bleibt der Ausgang unklar, stoppe und hol Hilfe, damit keine Duplikate entstehen.

Eine genaue Wiederholung von create_task mit denselben bedeutsamen Parametern innerhalb von 10 Minuten gibt die angelegte Aufgabe mit deduplicated: true und ihrem aktuellen Schlüssel zurück. Zuständigen, Priorität, Produkt oder andere bedeutsame Parameter zu ändern meint eine andere Aufgabe. „Внутренняя ошибка хаба (id …)“ bestätigt, dass der Fehler protokolliert wurde, nicht den Ausgang der Schreibaktion: lies das Objekt zurück, bevor du wiederholst, und gib der Unterstützung die id und die Zeit.

Bleibt das Problem, gib der Unterstützung den Client-Namen, die Ausführungsumgebung, das Werkzeug, die Zeit und den Fehlertext, ohne Geheimnisse. Schick keinen Schlüssel, kein Cookie und keinen OAuth-Code, und mach aus einer gültigen URL keine unsichere Form, um die Prüfung zu umgehen.

Wenn die Prüfung weiter scheitert

  • Wurde der Schlüssel widerrufen oder ist er weg, lege eine neue persönliche Verbindung an und aktualisiere den Client. Ein gespeichertes Geheimnis wird nicht noch einmal angezeigt.
  • Wird der Zugriff verweigert, prüfe, dass dein Konto noch im Team ist und das Produkt sehen kann. Ein neuer Schlüssel erweitert die Rechte deines Kontos nicht.
  • Unterstützt der Client die gewählte Verbindung nicht, nutze seine Einrichtungsanleitung und die MCP-/API-Dokumentation. Ein Schlüssel des Modellanbieters ersetzt keinen Hub-Agentenschlüssel.