Skip to main content
Questa documentazione riguarda le distribuzioni di Devin per il governo federale. Torna alla documentazione di Devin
devin airgap doctor è il primo comando da eseguire quando la CLI o Desktop non si avvia, non riesce a raggiungere un modello o mostra un codice di errore. Esegue tutti i controlli locali e di rete da cui dipende l’agente, stampa una riga per ciascun controllo e restituisce un codice di uscita diverso da zero se un controllo non va a buon fine. Questa pagina illustra ciascun controllo e come intervenire, quindi descrive cosa raccogliere per una richiesta di supporto.

Eseguire doctor

Eseguilo con lo stesso utente che userà Devin e nello stesso ambiente (le variabili della chiave API devono essere impostate in quella shell):
Ogni riga ha il formato <status> <check> <detail>. Per gli errori e gli avvisi associati a un codice, il dettaglio è preceduto dal codice di errore, ad esempio FAIL model 'llama-3.3-70b': endpoint reachability NET003: .... Per l’automazione, --json stampa {"ok": <bool>, "checks": [...]}, dove ogni controllo contiene check, status (pass, warn, fail) e detail, oltre a code per avvisi ed errori associati a un codice e latency_ms per una verifica di inferenza riuscita:
Desktop usa la stessa CLI inclusa nel bundle, quindi per diagnosticare anche i problemi di Desktop esegui doctor da un terminale sull’host di Desktop.

Riferimento dei controlli

I controlli vengono eseguiti nell’ordine indicato di seguito. I controlli successivi che dipendono da un errore precedente vengono saltati anziché ripetuti: se il file dei modelli non viene trovato, non compare la riga models file parse e non vengono eseguite le probe degli endpoint.

license

Carica e verifica il file di licenza (vedi Licenza).

models file path

Determina il percorso del file dei modelli (/etc/devin/models.json, C:\ProgramData\Devin\models.json su Windows, oppure DEVIN_MODELS_FILE) e verifica che il file esista in quella posizione.

config dir writable e data dir writable

Crea, se necessario, le directory di configurazione e dei dati del prodotto e scrive un file di prova in ciascuna.

CA bundle

Indica se DEVIN_CA_BUNDLE è impostato e lo carica.

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

Analizza il file dei modelli con lo stesso validatore usato da devin models validate, quindi verifica che la variabile api_key.env di ciascun modello sia impostata nell’ambiente attuale.

custom subagent profiles

Elenca le definizioni dei sottoagenti personalizzati presenti in agents/**/AGENT.md. Il controllo ha esito positivo con none configured o <n> profile(s) loaded; CFG005 indica una definizione che non è stato possibile analizzare. Questo controllo è condiviso con il comando standard devin doctor e non riguarda la configurazione air-gapped.

model '<name>': endpoint reachability

Invia GET {base_url}/models con la chiave API del modello, con un timeout di 10 secondi e la stessa configurazione TLS usata per l’inferenza.

model '<name>': inference conformance

Viene saltato se il controllo di raggiungibilità non è riuscito a livello di trasporto. Invia una richiesta da un solo token per verificare che l’endpoint supporti l’API configurata: POST {base_url}/chat/completions con max_tokens: 1 per chat_completions, oppure POST {base_url}/responses con max_output_tokens: 16 per responses.

Problemi comuni

Cosa inviare al supporto

Raccogli quanto segue sulla workstation interessata. Controlla ogni file prima di inviarlo: nessuno di essi viene caricato automaticamente.
  1. L’output di doctor:
    Le stringhe di dettaglio contengono gli URL dei tuoi endpoint e i nomi host, ma mai i valori delle chiavi API.
  2. Il report dei dati diagnostici, con i dati sensibili oscurati:
    Il report riporta le versioni, se ciascun file di configurazione esiste e viene analizzato correttamente, i nomi dei modelli, se ciascuna variabile della chiave API è impostata e le statistiche del registro di audit. Non contiene mai prompt, codice, contenuti dei file, valori segreti, URL degli endpoint o valori delle variabili d’ambiente.
  3. Il messaggio di errore esatto mostrato all’utente, compreso il relativo codice, e l’output di devin --version.
  4. Per i problemi di SSO, gli eventi auth pertinenti del registro di audit (campi error_code e action) e le voci corrispondenti nei log del tuo IdP.
Non inviare il file di licenza, i valori delle chiavi API, sso_tokens.toml né sessions.db.