Diagnostiser en agent

Denne guiden viser deg hvordan du finner ut hvorfor en agent ikke produserer kjøringer.

Arbeid ovenfra og ned: først agentens egne kjøringer, deretter backenden, deretter serveren, deretter verten.

1. Sjekk kjørehistorikken til agenten

Innstillinger → Arbeidsområde → Agenter → velg agenten → Logger.

Hver kjøring viser en statusmerkelapp, en varighet («Running…» mens den pågår), start- og sluttidspunktet, PID-en og adapteren den brukte. Vis åpner den rå hendelsesstrømmen for kjøringen. Stopp dreper en kjørende prosess og merker kjøringen «Killed by user»; Avslutt kjørende i toppteksten gjør det samme for alle kjøringer av agenten som pågår.

Les det slik:

Ingen kjøringer i det hele tatt — utsendingen skjedde aldri. Nevninger i skrivefeltet er @ pluss ordtegn (bokstaver, sifre, understrek). Oppslaget er et eksakt samsvar eller et prefikssamsvar på agentnavnet, så @code-reviewer tolkes som code og kan fortsatt vekke en agent som heter code-reviewer. Et navn med mellomrom kan ikke nevnes som én token. Gå deretter til steg 2.
En kjøring som avsluttet umiddelbart med feil — åpne Vis. En feil ved oppstart av backenden vises her som en prosessfeil.
En kjøring som står fast på «Running…» — stopp den, og sjekk deretter agentens Stillhetstidsavbrudd i Innstillinger-fanen. Et tidsavbrudd som ikke er angitt, bruker standarden for modusen.
En fullført kjøring uten nyttige data — statusen i kjøreloggen forblir completed for en kjøring som avsluttet uten leveransen den erklærte; det ærlige signalet er sammendragsteksten, ikke merkelappen.

Logger-fanen viser ingen kostnad. For forbruk bruker du tabellen per agent i Observabilitet → Innsikt.

2. Sjekk backenden til agenten

Innstillinger → Server → Modellleverandører (/settings/server/providers).

Listen Oppdagede kjørere viser hver adapter med sonderingsresultatet — en installert versjon, «Sjekker…» eller «Ikke funnet» — i tillegg til den oppløste stien og kapasitetsmerkene for en CLI som ble funnet. Klikk Oppdater i sidetoppteksten for å sondere på nytt.

Sonderingen kjører på maskinen som er vert for cc_server, ikke på maskinen du ser på. Hvis du bruker webklienten eller en sammenkoblet enhet, betyr «Ikke funnet» at CLI-en mangler på serververten.

To ting å bekrefte:

Agenten har i det hele tatt en adapter angitt. En agent med tom adapter sendes til Control Center (built-in), og kjøreloggen registrerer cc-harness, slik at transkripsjonen navngir det som kjørte. Uten modell i tillegg ber den Anthropic om standardmodellen — noe som mislykkes med No credential for provider "anthropic" med mindre du har koblet til en Anthropic-konto. De forhåndsseedede spesialistene leveres uten adapter.
Den innebygde adapteren har en modell. Modellisten hentes live fra leverandørene som er koblet til lenger ned på samme side, så en leverandør uten lagret påloggingsinformasjon bidrar med null modeller.

Selve adapterkatalogen er fast — det finnes ingen måte å registrere en ny adapter. Det du kan endre per adapter her, er oppstartsargumentene og miljøvariablene. Vær oppmerksom på at en miljøoverstyring per adapter vinner stille over en tilkoblet leverandørkonto når påloggingsinformasjon løses opp.

3. Sjekk serveren

Innstillinger → Server → Tilkobling og status (/settings/server/connection) viser hvilken server denne klienten snakker med, og hva den rapporterer.

For en headless server er GET /healthz den samme informasjonen uten en klient. Det er uautentisert og CORS-åpent med vilje:

curl http://localhost:9030/healthz

Det returnerer serverens status, oppetid i sekunder, antall aktive tilkoblinger, bundet port, byggeversjon og git-SHA, skjemaversjon for arbeidsområdet, RPC-katalogversjon, server-ID, navn og identitetsfingeravtrykk, om bindingen er usikker, og en codeGraph-blokk med antallene watching / indexing / pending. Når en cache har sett trafikk, inneholder det også en caches-blokk; en demoserver legger til demo: true.

To ting det er verdt å vite når en endring «fungerer i tester, men ikke i appen»:

Skrivebordsappen starter en forhåndsbygd cc_server-binærfil i stedet for kildekoden. En ny RPC-operasjon eller et nytt MCP-verktøy vises ikke før binærfilen er bygd på nytt, og oppstartsloggen varsler når barnets git-SHA avviker fra appens.
Skrivebordsappen dreper en server den selv har startet, som ikke har skrevet ut klar-meldingen innen 20 sekunder, og går over til en feilskjerm.

4. Sjekk verten

Innstillinger → Server → Diagnostikk og personvern (/settings/server/diagnostics) er siden på vertsnivå. Den inneholder:

Sandkasse — hovedbryteren, den oppdagede backenden og et installasjonstips. Bare den oppdagede backenden kommer fra serveren; se advarselen nedenfor. Det finnes ingen nullstillingskontroll.
Semantisk søk — livssyklusen til embedding-modellen på enheten: installert, laster ned med en prosentandel, ikke installert eller en installasjonsfeil. Inntil den er installert, holder minne- og kodesøk seg til kun nøkkelord.
Systematferd — hold datamaskinen våken mens agenter kjører.
Loggnivå — øk det før du reproduserer en feil.
Personvern — om rå diff-innhold kan videresendes til agentens modell, og om krasjrapporter sendes.

Deteksjon og håndheving stemmer nå overens: der detektoren rapporterer en innebygd backend, er agentkjøringer på den verten faktisk pakket inn i den. Men detektoren er det eneste levende i denne delen. Hovedbryteren og backend-velgeren er innstillinger som lagres på enheten din, og serveren leser ingen av dem — serverens egen bryter er --sandbox (on som standard, off for å velge det bort).

Så en advarsel her er verdt å handle på, men den er vanligvis ikke grunnen til at en agent feiler. For å bekrefte hvilken tilstand serveren er i, leser du oppstartsloggen: den skriver ut agent sandbox ON med backend-merknaden, no OS-native agent sandbox on this host med et installasjonstips, eller agent sandbox DISABLED by --sandbox off. GET /healthz inneholder ingen sandkasse-felt.

Der det ikke finnes noen backend — alltid på Windows, og på Linux eller WSL2 uten bwrap og socat — er kjøringer ikke sandkasset, og det som avgrenser dem, er samtalens egen checkout, kodeverttokenet som bare kan lese, og push-gatewayen, tillatelsesreglene for handlinger, sanering av miljøet og verktøyflaten modusen tillater.

Vanlige feil

Kjøringen starter aldri, og adapteren viser «Ikke funnet»

Installer CLI-en på serververten, og klikk deretter Oppdater på siden Modellleverandører. Eller bytt agenten til den innebygde adapteren, som ikke trenger noen CLI, og koble til en leverandør på samme side.

Agenten kan ikke pushe eller åpne en pull request

Les hva git eller agenten skrev ut. Control Center policy: … betyr at en handlingsregel nektet det, eller at en godkjenning ikke ble besvart: sjekk Push til en remote og Åpne en pull request under Innstillinger → Arbeidsområde → Agenttillatelser. Hvis git sier at Control Center ikke har noen GitHub-legitimasjon som kan pushe, installerer du GitHub App-en på det repoet eller kobler til GitHub.

Semantisk søk gir ingenting nyttig

Sjekk Innstillinger → Server → Diagnostikk og personvern → Semantisk søk. Inntil embedding-modellen er installert, er søket kun nøkkelord. Rader som ble skrevet før modellen ble installert, etterfylles aldri, så de forblir kun nøkkelord selv etterpå.

Serveren starter ikke i det hele tatt

Native biblioteker kreves, og det finnes ingen redusert modus. En manglende dylib gjør at cc_server nekter å starte og navngir synderen i feilen. Klargjør de native bibliotekene med scripts/natives/build_natives.sh og bygg serverbinærfilen på nytt.

En handling avvises i stillhet

Et prompt-vedtak i tillatelsesreglene avvises når ingen godkjenner er tilkoblet, med vilje. Sjekk reglene for arbeidsområdet under Innstillinger → Arbeidsområde → Agenttillatelser.