Ce transformă un model într-un agent

Ați schimbat modelul prin /model, ați repetat sarcina, iar răspunsul a fost diferit. În schimb, agentul a citit CLAUDE.md la fel, a cerut permisiunea înainte de comandă tot la fel, iar hook-ul a funcționat ca înainte. Așadar, toate acestea țin de altceva decât de model.

Să vedem unde se termină modelul și unde începe programul din jurul lui. Astfel veți ști ce să verificați atunci când agentul greșește.

Modelul și harness-ul

Modelul procesează contextul primit și formulează un răspuns sau o solicitare către un instrument. De exemplu, alege ce fișier să citească și ce comandă să ruleze. Pentru a executa aceste acțiuni, este nevoie de un program în jurul modelului: acesta accesează fișierele, rulează comenzile și îi întoarce modelului rezultatele.

În materialele în limba engleză, un astfel de program se numește harness. Înseamnă literal "ham" (da, cel pentru cal), dar în română se păstrează de obicei cuvântul englezesc: harness. Documentația Anthropic spune clar: Claude Code este harness-ul, iar Claude este modelul din interior. Veți întâlni termenul și în articole despre agenți în general, așa că merită reținut.

Bucla de lucru: solicitare către instrument, rezultat, pasul următor

În schemă, harness-ul adună contextul, verifică permisiunile și execută solicitările modelului către instrumente. Săgeata de sub model reprezintă bucla: rezultatul instrumentului revine în context, iar modelul alege pasul următor sau își încheie răspunsul. Un răspuns încheiat nu dovedește că sarcina a fost rezolvată. Rezultatul trebuie verificat.

Ce ați configurat deja

Iată cum se văd componentele harness-ului în Claude Code. Fișierele și comenzile din coloana din dreapta vă ajută să găsiți fiecare mecanism în proiect sau în sesiune.

Componentă a harness-ului	Ce face	Unde o găsiți
Instrucțiuni de sistem	Claude Code le adaugă în context înainte de primul dvs. mesaj: cum să lucreze, ce instrumente are și în ce folder rulează sesiunea	rândul System prompt din ieșirea comenzii `/context`
`CLAUDE.md`	regulile proiectului, pe care agentul le citește la începutul sesiunii	fișierul din rădăcina proiectului
Instrumente	citirea și editarea fișierelor, căutarea, comenzile din terminal	rânduri precum `Read(...)` și `Bash(...)` în timpul lucrului
Skills	instrucțiuni pe care modelul le poate alege pentru o sarcină sau pe care le puteți invoca explicit	`.claude/skills/`, `/skills`
MCP	o punte către servicii externe și date actuale	`/mcp`
Subagenți	un executor separat, cu propriul context	`.claude/agents/`
Solicitări de permisiune	harness-ul verifică dacă o acțiune este permisă și, la nevoie, vă cere acordul	o întrebare în terminal înainte de o comandă sau o editare
Hooks	comenzile dvs. declanșate de evenimentele sesiunii; rulează fără ca modelul să decidă	`/hooks`
Context și sesiune	ce vede modelul chiar acum și la ce punct vă puteți întoarce	`/context`, `/clear`, `/rewind`
Bucla agentică	îi întoarce modelului rezultatele instrumentelor, ca să aleagă pasul următor	mai multe acțiuni succesive ca răspuns la o singură solicitare

CLAUDE.md și skills îi oferă modelului instrucțiuni. Modelul poate înțelege greșit sau poate omite o regulă. Verificarea permisiunilor și comenzile din hooks configurate rulează programatic: rezultatul lor depinde de condițiile stabilite și de comenzile în sine.

Plugins nu apar în tabel, fiindcă nu sunt o componentă separată, ci un pachet: mai multe skills, comenzi sau hooks instalate dintr-o singură mișcare.

Același model, comportament diferit

Să luăm un chat web care nu este conectat la proiectul și terminalul dvs. Are propriul harness: istoricul conversației, interfața, uneori căutare pe internet sau încărcare de fișiere. Într-un astfel de chat, modelul vă poate explica o editare și vă poate arăta codul, pe când Claude Code, având acces la proiect, o poate face chiar în fișier. Modelul e același, dar posibilitățile diferă, fiindcă programul din jur e altul.

Cu /model se întâmplă invers. Modelul se schimbă, harness-ul rămâne același, deci regulile, instrumentele și solicitările de permisiune nu dispar.

De model depinde cum înțelege sarcina, ce instrumente alege și cum le evaluează rezultatele. Harness-ul adună contextul, pune instrumentele la dispoziție și verifică permisiunile. De exemplu, modelul poate solicita un fișier care îi lipsește, iar harness-ul îl citește și îi întoarce conținutul.

Cum se vede asta în Claude Code

Agentul raționează cu toată încrederea despre o funcție care nu mai există de mult în proiect? Mai întâi verificați dacă versiunea actuală a codului a ajuns în context. O puteți include prin @ urmat de calea fișierului, o puteți insera în mesaj sau agentul o poate obține cu instrumentul de citire. În primele două cazuri este posibil să nu existe un apel separat de citire. Dacă instrumentul a fost apelat, vedeți ce a returnat: conținutul fișierului sau o eroare de acces ori de cale. Dacă codul nu se află în context, trimiteți-l sau cereți citirea fișierului. Dacă este deja acolo, dar concluzia e greșită, verificați raționamentul comparându-l cu rândurile concrete. Aici poate ajuta și un alt model.

Ce să ajustați când agentul greșește

O greșeală izolată se corectează cel mai ușor cu un mesaj scurt: "nu e fișierul ăsta, uită-te în src/utils.js". Dacă aceeași greșeală revine de la o sesiune la alta, merită să verificați instrucțiunile și datele la care are acces agentul. Poate că trebuie să explicați aceeași regulă de fiecare dată.

În practică, situația arată cam așa:

agentul uită regula proiectului în fiecare sesiune, de exemplu că testele se rulează cu npm test - notați regula în CLAUDE.md. E mai sigur să o păstrați explicit în acest fișier decât să vă bazați pe o reamintire în conversație;
explicați aceeași procedură pentru a treia oară - e momentul să o mutați într-un skill. Agentul va putea încărca instrucțiunea pentru sarcina respectivă. Verificați în timpul lucrului dacă skill-ul a fost invocat; dacă nu, invocați-l chiar dvs. prin /skill-name, folosind numele lui real;
agentul ghicește date pe care nu le are - furnizați-i datele necesare: adăugați fișierul în context prin @ sau conectați un serviciu extern prin MCP. Insistența nu rezolvă ghicitul;
agentul spune "gata" fără să ruleze verificarea - un hook pentru evenimentul Stop poate rula testele automat, fără ca modelul să decidă. Tot dvs. acceptați lucrul, pe baza ieșirii comenzii, nu a raportului;
datele necesare sunt disponibile și au fost citite, dar agentul se încurcă într-un raționament complex - încercați alt model prin /model și comparați rezultatul pentru aceeași sarcină.

Verificați cauza

Mai întâi verificați dacă datele și instrumentele necesare sunt disponibile. Dacă problema ține de raționament, puteți încerca imediat alt model. Comparați calitatea rezultatului și consumul afișat în /usage: încercările nereușite repetate vă consumă și ele limita și timpul.