Skip to main content
Diese Dokumentation gilt für föderale Deployments von Devin. Zurück zur Devin-Dokumentation
Wenn die CLI oder Desktop nicht startet, kein Modell erreicht oder einen Fehlercode anzeigt, sollten Sie zuerst devin airgap doctor ausführen. Der Befehl führt alle lokalen und Netzwerkprüfungen aus, auf die der Agent angewiesen ist, gibt pro Prüfung eine Zeile aus und beendet sich mit einem Exit-Code ungleich null, sobald eine Prüfung fehlschlägt. Auf dieser Seite werden die einzelnen Prüfungen und die jeweils erforderlichen Maßnahmen erläutert. Anschließend erfahren Sie, welche Informationen Sie für eine Support-Anfrage zusammenstellen sollten.

doctor ausführen

Führen Sie den Befehl als der Nutzer aus, der Devin verwenden wird, und zwar in derselben Umgebung (die Umgebungsvariablen für den API-Schlüssel müssen in dieser Shell gesetzt sein):
Jede Zeile hat das Format <status> <check> <detail>. Bei Fehlschlägen und Warnungen mit Code wird dem Detail der Fehlercode vorangestellt, zum Beispiel FAIL model 'llama-3.3-70b': endpoint reachability NET003: .... Für Automatisierungen gibt --json die Ausgabe {"ok": <bool>, "checks": [...]} aus. Jede Prüfung enthält dabei check, status (pass, warn, fail) und detail, bei Warnungen und Fehlschlägen mit Code zusätzlich code und bei einem erfolgreichen Inferenztest latency_ms:
Desktop verwendet dieselbe mitgelieferte CLI. Führen Sie doctor daher in einem Terminal auf dem Desktop-Host aus, um auch Probleme mit Desktop zu diagnostizieren.

Referenz der Prüfungen

Die Prüfungen werden in der unten aufgeführten Reihenfolge ausgeführt. Spätere Prüfungen, die von einem vorherigen Fehler abhängen, werden übersprungen statt wiederholt: Wird die Modelldatei nicht gefunden, gibt es weder eine Zeile models file parse noch Endpunktprüfungen.

license

Lädt die Lizenzdatei und prüft sie (siehe Lizenz).

models file path

Ermittelt den Speicherort der Modelldatei (/etc/devin/models.json, unter Windows C:\ProgramData\Devin\models.json, oder DEVIN_MODELS_FILE) und prüft, ob dort eine Datei vorhanden ist.

config dir writable and data dir writable

Erstellt bei Bedarf die Konfigurations- und Datenverzeichnisse des Produkts und schreibt jeweils eine Testdatei hinein.

CA bundle

Gibt an, ob DEVIN_CA_BUNDLE gesetzt ist, und lädt die Datei.

models file parse and model '<name>': API key env var

Parst die Modelldatei mit demselben Validator wie devin models validate und prüft anschließend, ob die Variable api_key.env jedes Modells in der aktuellen Umgebung gesetzt ist.

custom subagent profiles

Listet benutzerdefinierte Subagent-Definitionen aus agents/**/AGENT.md auf. Bei none configured oder <n> profile(s) loaded ist die Prüfung bestanden; CFG005 nennt eine Definition, die nicht geparst werden konnte. Diese Prüfung ist auch Teil des Standardbefehls devin doctor und hat nichts mit der air-gapped Konfiguration zu tun.

model '<name>': endpoint reachability

Sendet GET {base_url}/models mit dem API-Schlüssel des Modells – mit einem Timeout von 10 Sekunden und derselben TLS-Konfiguration, die auch für die Inferenz verwendet wird.

model '<name>': inference conformance

Wird übersprungen, wenn die Erreichbarkeitsprüfung auf Transport-Ebene fehlgeschlagen ist. Sendet eine Anfrage mit einem einzigen Token, um nachzuweisen, dass der Endpunkt die konfigurierte API unterstützt: POST {base_url}/chat/completions mit max_tokens: 1 für chat_completions oder POST {base_url}/responses mit max_output_tokens: 16 für responses.

Häufige Probleme

Was Sie an den Support senden sollten

Sammeln Sie die folgenden Informationen auf der betroffenen Workstation. Prüfen Sie jede Datei, bevor Sie sie senden – keine davon wird automatisch hochgeladen.
  1. Die Ausgabe von doctor:
    Die Detail-Strings enthalten Ihre Endpunkt-URLs und Hostnamen, aber niemals die Werte von API-Schlüsseln.
  2. Der bereinigte Diagnosebericht:
    Der Bericht enthält die Versionen, Angaben dazu, ob die einzelnen Konfigurationsdateien vorhanden sind und fehlerfrei geparst werden können, die Modellnamen, Angaben dazu, ob die einzelnen API-Schlüsselvariablen gesetzt sind, sowie Statistiken zum Audit-Protokoll. Er enthält niemals Prompts, Code, Dateiinhalte, geheime Werte, Endpunkt-URLs oder Werte von Umgebungsvariablen.
  3. Die genaue Fehlermeldung, die dem Nutzer angezeigt wurde, einschließlich des Fehlercodes, sowie die Ausgabe von devin --version.
  4. Bei SSO-Problemen die relevanten auth-Ereignisse aus dem Audit-Protokoll (Felder error_code und action) sowie die zugehörigen Einträge aus den Logs Ihres IdP.
Senden Sie weder die Lizenzdatei noch die API-Schlüsselwerte, sso_tokens.toml oder sessions.db.