Ce este un agent

La finalul capitolului poți inspecta un coding agent actual prin nouă capabilități recurente și poți compara felul în care două sisteme le implementează sau le asigură.

TL;DR

• Un coding agent e un model într-un harness. Cele nouă componente principale de mai jos formează un framework practic de inspecție, nu o teoremă despre anatomia universală a agenților.
• O capabilitate poate fi integrată, asigurată din exterior, absentă sau implementată diferit. Aceste diferențe, în primul rând cele de sandbox, schimbă controalele de care ai nevoie.
• Evaluează modelul și harness-ul împreună, pe task-urile tale. La orice agent nou, pune câte o întrebare pe componentă principală.

Ce este o componentă principală a unui coding agent?¶

Un agent înseamnă un model plus un harness, iar harness-ul e un set restrâns de părți care se repetă.

Agenții de cod actuali expun în mod repetat capabilitățile de mai jos, dar felul în care le împachetează și disponibilitatea lor diferă. Aici, „componentă principală” înseamnă o capabilitate pe care merită s-o inspectezi, nu obligația ca fiecare produs s-o livreze într-un pachet separat și configurabil. Fiecare card se încheie cu o întrebare; „absentă” și „asigurată din exterior” sunt răspunsuri valide.

Context window

Ce este: tot ce știe agentul chiar acum, într-un număr limitat de tokeni.

Conține system prompt-ul, conversația, rezultatele tool-urilor și fișierele citite - nu restul codebase-ului tău și nici ticketele. Cele mai multe decizii „evident greșite” se reduc la context lipsă: nu i-a spus nimeni agentului de noua bibliotecă de autentificare. Dimensiunile de fereastră din reclame depășesc ce folosește un model cu adevărat bine. Capitolul 6 tratează lucrul în limitele ferestrei.

Întreabă: Cât de mare e fereastra și cum o gestionează agentul sub presiune?

Tool-uri

Ce este: acțiunile pe care le poate face agentul - să citească, să scrie și să editeze fișiere, să ruleze comenzi de shell, să caute în codebase.

Fiecare tool call e un punct de decizie, un punct de audit și un punct de control: înregistrează apelurile ca să poți reconstitui ce s-a întâmplat, interceptează-le ca să guvernezi. „Nu șterge fișiere aici” funcționează oprind tool call-ul de Bash înainte să ruleze rm. Ține setul de tool-uri mereu vizibile mic, pentru că fiecare tool costă context înainte de primul tău cuvânt.

Întreabă: Ce tool-uri are și cum sunt constrânse?

Permisiuni / Sandbox¶

Ce este: două controale livrate ca pereche - regulile agentului însuși și enforcement-ul sistemului de operare.

Stratul de decizie al agentului verifică cererile către tool-urile pe care le acoperă față de regulile allow / ask / deny. Unele moduri adaugă un clasificator bazat pe model pentru acțiunile eligibile, după aplicarea regulilor explicite. Injecția poate induce în eroare clasificatorul sau poate exploata acțiuni permise și lipsuri de acoperire; nu poate convinge pur și simplu o regulă de deny aplicată corect să dispară. Stratul de OS refuză syscall-urile interzise ale proceselor pe care le izolează efectiv, indiferent de raționamentul agentului. Verifică ce tool-uri și subprocese sunt în interiorul acestei limite. Niciuna dintre jumătăți nu e suficientă singură.

Întreabă: Ce model de permisiuni livrează și ce sandbox de OS are by default?

Skill-uri

Ce este: instrucțiuni împachetate, pe care agentul le încarcă doar când un task are nevoie de ele.

Un skill e o bucată de markdown - felul în care scrie echipa un serviciu de Spring Boot, de exemplu - încărcată când task-ul are nevoie de ea. Descrierile pot ocupa context înainte de invocare; instrucțiunile complete intră când sunt folosite și pot rămâne în sesiune. Ține trigger-ele specifice. Cunoștințele specializate pot ajuta; o procedură generală pe care agentul o urmează deja poate adăuga cost fără să îmbunătățească rezultatul.

Întreabă: Skill-urile se încarcă la detecție sau sunt always-loaded?

Plugin-uri

Ce este: un pachet de skill-uri, tool-uri, hook-uri și comenzi, instalabil printr-o singură comandă.

Plugin-ul e unitatea de distribuție: workflow-ul de review de PR-uri al unei echipe devine pentru altă echipă o instalare cu o singură comandă. Pornește cu agentul nativ; adaugă un plugin pentru o capabilitate necesară sau pentru o îmbunătățire măsurată. Marketplace-ul e și o suprafață de supply chain, npm-ul programării cu agenți. Anexa B.10 verifică atât încrederea, cât și utilitatea.

Întreabă: Există un marketplace de plugin-uri și cum verifici ce conține?

Ce este MCP?¶

Ce este: Model Context Protocol, o specificație pentru felul în care agenții vorbesc cu sistemele externe - Jira, Postgres, GitHub, data warehouse-ul tău.

O integrare MCP poate fi reutilizată în clienți compatibili. Verifică versiunea de protocol negociată, capabilitățile, transportul și autentificarea: faptul că două produse suportă MCP nu înseamnă că orice server va funcționa neschimbat cu ambele.

Întreabă: Vorbește MCP și cât de bună e integrarea?

Memory¶

Ce este: ce se păstrează de la o sesiune la alta, în două jumătăți.

Prima o scrie echipa: fișiere de instrucțiuni ale proiectului, cum ar fi AGENTS.md. Descoperirea, aria de aplicare și precedența depind de client; unele cer configurare sau încărcare explicită (Capitolul 6). A doua o scrie agentul pentru sine: preferințe, corecturi și decizii pe care nu le poate reconstitui din cod.

Întreabă: Citește un fișier de memorie partajat de echipă la începutul sesiunii și își ține și o memorie proprie?

Effort¶

Ce este: cât de mult gândește modelul înainte să acționeze - cea mai nouă componentă principală, care își câștigă locul prin levier.

Unde modelul și clientul oferă controale de effort, compară setările disponibile pe task-uri reprezentative. Mișcă și costul, și calitatea, în ambele direcții: prea jos, și agentul sare peste research-ul de care avea nevoie task-ul; prea sus, și plătești raționament pe care task-ul nu l-a cerut niciodată. Numele nu se transferă între modele, așa că orice migrare de model începe cu un sweep de effort (Anexa B.9). Setează-l per fază, nu per sesiune: fazele de Research și de Plan merită effort mare, un task mecanic din faza de Execute, de regulă, nu.

Întreabă: Ce niveluri de effort expune și supraviețuiește raționamentul de la o tură la alta?

Subagenți

Ce este: instanțe-copil constrânse ale agentului însuși.

Orchestratorul îi dă subagentului un task bine delimitat, cu tool-uri limitate la scopul lui, și primește un rezultat. Un context proaspăt izolează munca; un fork poate prelua istoricul agentului principal. Fiecare worker adaugă consum, timp de pornire și coordonare, influențate parțial de cache. Deleagă munca amplă și independentă când beneficiul estimat justifică aceste costuri; păstrează în agentul principal editările rapide și pașii strâns legați. Capitolele 4, 5 și 7 arată unde poate ajuta delegarea.

Întreabă: Cum expune subagenții - e dispatch-ul în paralel o operație de primă clasă?

Harness-ul

Modelul determină plafonul; harness-ul determină dacă îl atingi.

Harness-ul e runtime-ul din jurul modelului: îți formatează cererea, gestionează fereastra, trimite spre execuție tool call-urile, întoarce rezultatele și decide când s-a terminat treaba. Bucla în sine e simplă; contează controalele din jur. Inspectează potrivirea pentru limbaj, licența, ecosistemul de plugin-uri, enforcement-ul de sandbox și postura de audit, apoi evaluează împreună modelul și harness-ul pe munca ta.

Compară implementările

Framework-ul face diferențele vizibile; două implementări nu demonstrează o arhitectură universală.

Demonstrație: un prompt, doi agenți. În timp ce pregăteam manualul, am pus Claude Code să citească codul sursă a doi alți coding agents, în două panouri de terminal: Codex CLI (Rust, întreținut de OpenAI) și opencode (TypeScript, o echipă independentă). Amândoi sunt open source și nu au nicio linie de cod în comun. Același prompt în fiecare: mapează bucla agentului, tool-urile, gate-urile de permisiuni, sandbox-ul și modelul de plugin-uri, citând fișiere și numere de linie.

Cam patru minute mai târziu, fără nicio corecție umană, amândoi au întors aceeași formă: o buclă de agent, un registru de tool-uri, un gate de permisiuni, un sandbox, un model de plugin-uri, suport MCP, o cale de dispatch pentru subagenți. Alte limbaje, alte fișiere, alte nume. Cea mai clară divergență a fost sandbox-ul: Codex implementează izolare reală la nivel de OS, deci kernelul însuși refuză ceea ce agentul nu e autorizat să facă; opencode implementează o îngrădire soft, validare de căi și prompt-uri de permisiune, fără nicio graniță impusă de kernel.

Limitări: comparația autorului între două repository-uri ilustrează framework-ul. Nu stabilește că fiecare agent are toate cele nouă capabilități sau că implementările sunt la fel de eficiente.

Postura sandbox-ului e o alegere de guvernanță

Alegerile unui vendor în privința componentelor principale sunt alegeri de guvernanță.

Codul sursă și probele rulate în mediul real pot arăta ce acoperă efectiv un sandbox. Codex CLI impune un sandbox de OS by default pe Linux și macOS; Claude Code oferă un sandbox de shell opt-in; opencode are nevoie de izolare la nivel de OS asigurată din exterior. Default-urile depind de versiune, deci verifică-le pe ale tale.

Contează ce acoperă sandbox-ul în realitate, nu ce a intenționat vendorul. Tu alegi, iar Capitolul 2 transformă alegerea în cinci straturi.

Când se strică

• O regulă pe care o consultă agentul nu e un zid. Injecția poate induce în eroare judecata modelului și poate exploata acțiuni permise sau lipsuri de acoperire. Regulile de deny aplicate efectiv și izolarea la nivel de OS protejează operațiunile pe care le acoperă (Capitolul 2).
• Un sandbox din documentație nu e un sandbox în kernel. Confirmă că stratul de OS e pornit.
• Un plugin e cod pe care nu l-ai scris tu. O instalare neverificată e un risc de supply chain, iar un hook care rulează în afara sandbox-ului nu e mărginit de nimic.

De făcut luni

• [ ] Pune agentului pe care îl folosești zilnic câte o întrebare pentru fiecare componentă principală (rândurile cu „Întreabă”), notează răspunsurile și evaluează fiecare componentă drept basic, intermediate sau advanced.
• [ ] Verifică dacă sandbox-ul lui de OS e pornit și notează nivelul de effort.
• [ ] Deschide repository-ul unui agent open source și găsește fișierul care implementează bucla agentului (douăzeci de minute: o să-i prinzi forma, nu fiecare linie). Apoi localizează unde stă fiecare dintre cele nouă componente principale.

Mai departe

• Template-uri: Anexa B.10, verificarea plugin-urilor; B.11, parcurgerea sursei a doi agenți; B.9, sweep-ul de effort.
• Deep dive: Anexa D, Capitolul 1 - cifre despre context window și numărul de tool-uri, decodarea strictă pentru schemele de tool-uri custom, posturile și cronologiile de sandbox ale vendorilor, dovezile despre effort, orchestrarea scriptată a subagenților.
• Surse: Anexa C.