Diagnostichează un agent

Acest ghid îți arată cum să afli de ce un agent nu produce rulări.

Lucrează de sus în jos: mai întâi rulările agentului însuși, apoi backendul lui, apoi serverul, apoi gazda.

1. Verifică istoricul rulărilor agentului

Setări → Spațiu de lucru → Agenți → selectează agentul → Jurnale.

Fiecare rulare afișează o insignă de stare, o durată („Running…” cât timp este în curs), orele de început și de final, PID-ul și adaptorul folosit. Vizualizează deschide fluxul brut de evenimente al acelei rulări. Oprește ucide un proces aflat în rulare și marchează rularea ca „Killed by user”; Oprește forțat ce rulează din antet face același lucru pentru fiecare rulare în curs a acelui agent.

Citește-le astfel:

Nicio rulare — trimiterea nu a avut loc niciodată. Mențiunile din compozitor sunt @ plus caractere de cuvânt (litere, cifre, liniuță de subliniere). Rezolvarea este o potrivire exactă sau de prefix pe numele agentului, așa că @code-reviewer este interpretat ca code și poate totuși trezi un agent numit code-reviewer. Un nume care conține un spațiu nu poate fi menționat ca un singur token. Apoi treci la pasul 2.
O rulare care s-a încheiat imediat cu eroare — deschide Vizualizează. O eroare de lansare a backendului apare aici ca eroare de proces.
O rulare blocată pe „Running…” — oprește-o, apoi verifică Timeout de tăcere al agentului în tab-ul Setări. Un timeout nesetat folosește implicitul modului.
O rulare încheiată fără rezultat util — starea din jurnalul de rulare rămâne completed pentru o rulare care s-a încheiat fără livrabilul declarat; semnalul onest este textul rezumatului, nu insigna.

Tab-ul Jurnale nu arată niciun cost. Pentru cheltuieli, folosește tabelul pe agent din Observabilitate → Insights.

2. Verifică backendul agentului

Setări → Server → Provideri de modele (/settings/server/providers).

Lista Runnere detectate arată fiecare adaptor cu rezultatul verificării sale — o versiune instalată, „Se verifică…” sau „Negăsit” — plus calea rezolvată și etichetele de capabilități pentru un CLI găsit. Dă clic pe Reîmprospătează în antetul paginii ca să reverifici.

Verificarea rulează pe mașina care găzduiește cc_server, nu pe mașina la care te uiți. Dacă ești pe clientul web sau pe un dispozitiv asociat, „Negăsit” înseamnă că CLI-ul lipsește pe gazda serverului.

Două lucruri de confirmat:

Agentul are măcar un adaptor setat. Un agent cu adaptorul gol este trimis către Control Center (built-in), iar jurnalul de rulare înregistrează cc-harness, așa că transcrierea numește ce a rulat. Fără model de asemenea, cere implicitul de la Anthropic — ceea ce eșuează cu No credential for provider "anthropic" dacă nu ai conectat un cont Anthropic. Specialiștii predefiniți vin fără adaptor.
Adaptorul încorporat are un model. Lista lui de modele vine în direct de la providerii conectați mai jos pe aceeași pagină, deci un provider fără date de autentificare stocate nu contribuie cu niciun model.

Catalogul de adaptoare în sine este fix — nu există nicio cale de a înregistra un adaptor nou. Ce poți schimba aici pentru fiecare adaptor sunt argumentele de lansare și variabilele de mediu. Reține că o suprascriere de mediu la nivel de adaptor bate în tăcere un cont de provider conectat atunci când se rezolvă datele de autentificare.

3. Verifică serverul

Setări → Server → Conexiune și stare (/settings/server/connection) arată cu ce server vorbește acest client și ce raportează el.

Pentru un server headless, GET /healthz oferă aceleași informații fără un client. Este neautentificat și deschis la CORS prin concepție:

curl http://localhost:9030/healthz

Returnează starea serverului, timpul de funcționare în secunde, numărul de conexiuni active, portul de ascultare, versiunea de build și SHA-ul git, versiunea schemei spațiului de lucru, versiunea catalogului RPC, id-ul, numele și amprenta de identitate ale serverului, dacă legarea la rețea este nesigură și un bloc codeGraph cu contoarele watching / indexing / pending. Când un cache a văzut trafic, include și un bloc caches; un server demo adaugă demo: true.

Două lucruri care merită știute când o modificare „merge în teste, dar nu în aplicație”:

Aplicația desktop lansează cu prioritate un binar cc_server precompilat în locul surselor. O nouă operație RPC sau un nou instrument MCP nu apare până când binarul nu este recompilat, iar jurnalul de pornire emite un avertisment când SHA-ul git al procesului copil diferă de cel al aplicației.
Aplicația desktop ucide un server pornit care nu și-a afișat bannerul de disponibilitate în 20 de secunde și trece pe un ecran de eroare.

4. Verifică gazda

Setări → Server → Diagnosticări și confidențialitate (/settings/server/diagnostics) este pagina la nivel de gazdă. Conține:

Sandboxing — comutatorul principal, backendul detectat și un indiciu de instalare. Doar backendul detectat vine de la server; vezi atenționarea de mai jos. Nu există niciun control de resetare.
Căutare semantică — ciclul de viață al modelului de embedding de pe dispozitiv: instalat, în curs de descărcare cu un procent, neinstalat sau o eroare de instalare. Până când este instalat, memoria și căutarea în cod rămân doar pe cuvinte-cheie.
Comportament sistem — menține computerul treaz cât timp rulează agenții.
Nivel jurnal — ridică-l înainte de a reproduce o defecțiune.
Confidențialitate — dacă conținutul brut al diff-urilor poate fi transmis modelului agentului și dacă se trimit rapoarte de eroare.

Detectarea și aplicarea sunt acum în acord: acolo unde detectorul raportează un backend nativ, rulările agenților de pe acea gazdă sunt într-adevăr înfășurate în el. Dar detectorul este singurul lucru activ din această secțiune. Comutatorul principal și selectorul de backend sunt preferințe stocate pe dispozitivul tău, iar serverul nu citește niciuna dintre ele — comutatorul propriu al serverului este --sandbox (on implicit, off pentru a renunța).

Deci un avertisment de aici merită tratat, dar de obicei nu este motivul pentru care eșuează un agent. Ca să confirmi în ce stare este serverul, citește jurnalul lui de pornire: afișează agent sandbox ON cu nota despre backend, no OS-native agent sandbox on this host cu un indiciu de instalare sau agent sandbox DISABLED by --sandbox off. GET /healthz nu conține niciun câmp de sandbox.

Acolo unde nu există backend — pe Windows întotdeauna, pe Linux sau WSL2 fără bwrap și socat — rulările nu sunt izolate, iar ce le limitează este checkout-ul propriu al conversației, tokenul de forge doar pentru citire și gateway-ul de push, guardrail-urile de acțiune, sanitizarea mediului și suprafața de instrumente pe care o permite modul său.

Eșecuri frecvente

Rularea nu pornește niciodată, iar adaptorul afișează „Negăsit”

Instalează CLI-ul pe gazda serverului, apoi dă clic pe Reîmprospătează în pagina Provideri de modele. Sau comută agentul pe adaptorul încorporat, care nu are nevoie de niciun CLI, și conectează un provider pe aceeași pagină.

Agentul nu poate face push și nu poate deschide un pull request

Citește ce au afișat git sau agentul. Control Center policy: … înseamnă că o regulă de acțiune a refuzat sau că o aprobare a rămas fără răspuns: verifică Push către un remote și Deschide un pull request în Setări → Spațiu de lucru → Permisiuni agent. Dacă git spune că Control Center nu are nicio credențială GitHub care poate face push, instalează GitHub App pe acel depozit sau conectează GitHub.

Căutarea semantică nu returnează nimic util

Verifică Setări → Server → Diagnosticări și confidențialitate → Căutare semantică. Până când modelul de embedding este instalat, căutarea este doar pe cuvinte-cheie. Rândurile scrise înainte de instalarea modelului nu sunt niciodată completate retroactiv, așa că rămân doar pe cuvinte-cheie chiar și după aceea.

Serverul nu pornește deloc

Bibliotecile native sunt obligatorii și nu există mod degradat. O dylib lipsă face cc_server să refuze pornirea și numește vinovatul în eroare. Pregătește bibliotecile native cu scripts/natives/build_natives.sh și recompilează binarul serverului.

O acțiune este refuzată în tăcere

O decizie prompt de guardrail fără niciun aprobator conectat este refuzată, prin concepție. Verifică regulile spațiului de lucru în Setări → Spațiu de lucru → Permisiuni agent.