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):<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:
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 rigamodels 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.-
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.
-
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.
-
Il messaggio di errore esatto mostrato all’utente, compreso il relativo codice, e l’output di
devin --version. -
Per i problemi di SSO, gli eventi
authpertinenti del registro di audit (campierror_codeeaction) e le voci corrispondenti nei log del tuo IdP.
sso_tokens.toml né sessions.db.
