Felsök en agent

Den här guiden visar hur du tar reda på varför en agent inte producerar några körningar.

Arbeta uppifrån och ned: agentens egna körningar först, sedan dess backend, sedan servern och till sist värden.

1. Kontrollera agentens körningshistorik

Inställningar → Arbetsyta → Agenter → välj agenten → Loggar.

Varje körning visar ett statusmärke, en varaktighet (“Running…” medan den pågår), dess start- och sluttider, dess PID och adaptern den använde. Visa öppnar körningens råa händelseström. Stoppa dödar en körande process och markerar körningen “Killed by user”; Avsluta körning i sidhuvudet gör samma sak för varje pågående körning av den agenten.

Läs den så här:

Inga körningar alls — dispatchningen skedde aldrig. Omnämnanden i skrivfältet är @ plus ordtecken (bokstäver, siffror, understreck). Uppslagningen är en exakt eller prefixmatchning mot agentnamnet, så @code-reviewer tolkas som code och kan ändå väcka en agent med namnet code-reviewer. Ett namn med ett mellanslag kan inte nämnas som en enda token. Gå sedan vidare till steg 2.
En körning som slutade omedelbart med fel — öppna Visa. Ett misslyckande med att starta backenden visas här som ett processfel.
En körning som fastnat på “Running…” — stoppa den och kontrollera sedan agentens Tystnadstimeout på fliken Inställningar. En timeout som inte är angiven använder standardvärdet per läge.
En slutförd körning utan användbara utdata — körningsloggens status står kvar som completed för en körning som avslutades utan sin deklarerade leverans; den ärliga signalen är sammanfattningstexten, inte märket.

Fliken Loggar visar ingen kostnad. För utgifter, använd tabellen per agent i Observability → Insikter.

2. Kontrollera agentens backend

Inställningar → Server → Modellleverantörer (/settings/server/providers).

Listan Upptäckta körare visar varje adapter med dess probe-resultat — en installerad version, “Kontrollerar…” eller “Hittades inte” — plus den upplösta sökvägen och kapacitetstaggarna för en hittad CLI. Klicka på Uppdatera i sidhuvudet för att köra proben igen.

Proben körs på maskinen som kör cc_server, inte på maskinen du tittar på. Om du är på webbklienten eller en parkopplad enhet betyder “Hittades inte” att CLI:t saknas på servervärden.

Två saker att bekräfta:

Att agenten över huvud taget har en adapter angiven. En agent med tom adapter skickas till Control Center (inbyggd) och körningsloggen registrerar cc-harness, så transkriptet namnger vad som kördes. Har den inte heller någon modell frågar den Anthropic efter sin standardmodell — vilket misslyckas med No credential for provider "anthropic" om du inte har anslutit ett Anthropic-konto. De seedade specialisterna levereras utan adapter.
Att den inbyggda adaptern har en modell. Dess modellista kommer live från leverantörerna som ansluts längre ned på samma sida, så en leverantör utan lagrade inloggningsuppgifter bidrar med noll modeller.

Själva adapterkatalogen är fast — det finns inget sätt att registrera en ny adapter. Det du kan ändra per adapter här är dess startargument och miljövariabler. Observera att en överstyrning av miljön per adapter tyst slår ett anslutet leverantörskonto när inloggningsuppgifter löses upp.

3. Kontrollera servern

Inställningar → Server → Anslutning och status (/settings/server/connection) visar vilken server klienten pratar med och vad den rapporterar.

För en headless-server är GET /healthz samma information utan en klient. Den är oautentiserad och CORS-öppen med avsikt:

curl http://localhost:9030/healthz

Den returnerar serverns status, drifttid i sekunder, antalet aktiva anslutningar, bunden port, byggversion och git-SHA, arbetsytans schemaversion, RPC-katalogversion, server-id, namn och identitetsfingeravtryck, huruvida bindningen är osäker samt ett codeGraph-block med antalen watching / indexing / pending. När en cache har sett trafik innehåller den även ett caches-block; en demoserver lägger till demo: true.

Två saker värda att känna till när en ändring “fungerar i tester men inte i appen”:

Skrivbordsappen startar en förbyggd cc_server-binär i stället för källkoden. En ny RPC-op eller ett MCP-verktyg dyker inte upp förrän binären har byggts om, och startloggen varnar när barnets git-SHA skiljer sig från appens.
Skrivbordsappen dödar en startad server som inte har skrivit ut sin redo-banner inom 20 sekunder och hamnar på en felskärm.

4. Kontrollera värden

Inställningar → Server → Diagnostik och integritet (/settings/server/diagnostics) är värdnivåsidan. Den innehåller:

Sandlåda — huvudväxeln, den upptäckta backenden och ett installationstips. Endast den upptäckta backenden kommer från servern; se varningen nedan. Det finns ingen återställningskontroll.
Semantisk sökning — inbäddningsmodellen på enheten och dess livscykel: installerad, laddar ned med en procentandel, inte installerad eller ett installationsfel. Tills den är installerad förblir minnes- och kodsökning enbart nyckelordsbaserad.
Systembeteende — håll datorn vaken medan agenter körs.
Loggnivå — höj den innan du återskapar ett fel.
Integritet — huruvida rå diff-innehåll får vidarebefordras till agentens modell och huruvida kraschrapporter skickas.

Detektion och verkställighet stämmer nu överens: där detektorn rapporterar en nativ backend är agentkörningar på den värden verkligen inpackade i den. Men detektorn är det enda levande i det här avsnittet. Huvudväxeln och backendväljaren är inställningar som lagras på din enhet, och servern läser ingen av dem — serverns egen växel är --sandbox (on som standard, off för att avstå).

Så en varning här är värd att agera på, men den är oftast inte orsaken till att en agent misslyckas. För att bekräfta vilket läge servern är i, läs dess startlogg: den skriver ut agent sandbox ON med backendanteckningen, no OS-native agent sandbox on this host med ett installationstips eller agent sandbox DISABLED by --sandbox off. GET /healthz innehåller inget sandlådefält.

Där det inte finns någon backend — Windows alltid, Linux eller WSL2 utan bwrap och socat — är körningar inte sandlådade, och det som begränsar dem är samtalets egen checkout, dess kodvärdstoken som bara kan läsa och pushgatewayen, räckena för åtgärder, miljösaneringen och den verktygsyta som dess läge tillåter.

Vanliga fel

Körningen startar aldrig och adaptern visar “Hittades inte”

Installera CLI:t på servervärden och klicka sedan på Uppdatera på sidan Modellleverantörer. Eller byt agenten till den inbyggda adaptern, som inte behöver något CLI, och anslut en leverantör på samma sida.

Agenten kan inte pusha eller öppna en pull request

Läs vad git eller agenten skrev ut. Control Center policy: … betyder att en åtgärdsregel nekade det eller att ett godkännande blev obesvarat: kontrollera Pusha till en remote och Öppna en pull request under Inställningar → Arbetsyta → Agentbehörigheter. Om git säger att Control Center saknar en GitHub-inloggningsuppgift som kan pusha, installera GitHub-appen på det repot eller anslut GitHub.

Semantisk sökning ger inget användbart

Kontrollera Inställningar → Server → Diagnostik och integritet → Semantisk sökning. Tills inbäddningsmodellen är installerad är sökningen enbart nyckelordsbaserad. Rader som skrivits innan modellen installerades efterfylls aldrig, så de förblir enbart nyckelordsbaserade även efteråt.

Servern startar inte alls

Nativa bibliotek krävs och det finns inget degraderat läge. En saknad dylib gör att cc_server vägrar starta och namnger förövaren i felet. Lägg de nativa biblioteken på plats med scripts/natives/build_natives.sh och bygg om serverbinären.

En åtgärd nekas tyst

Ett prompt-beslut i ett räcke utan ansluten godkännare nekas, med avsikt. Kontrollera arbetsytans regler under Inställningar → Arbetsyta → Agentbehörigheter.