Sari la conținut
Control Center
Adaugă o stea depozitului5Descarcă
Meniu

Modelul agenților

Ce este un agent?

Secțiune intitulată „Ce este un agent?”

Un agent este un actor numit, cu o persona, un set de skill-uri și un adaptor pe care să ruleze. Agenții sunt actori cu drepturi depline în același sens în care sunt și oamenii: redactează mesaje, dețin tichete, lasă revizuiri și apar în aceeași listă. Ei sunt cei care fac munca.

Fiecare agent aparține exact unui singur spațiu de lucru. Acesta este un invariant strict — agent.workspaceId nu este niciodată nul, spațiul de lucru al agentului este cel care alege fișierul de bază de date în care ajung rândurile lui, iar crearea unui agent fără spațiu de lucru este refuzată.

Un agent este și un director. Definiția lui se află la agents/<slug>/AGENTS.md, sub directorul de date al spațiului de lucru, iar skill-urile pe care le deține sunt legate simbolic în agents/<slug>/.agents/skills. Rândul din baza de date și fișierul sunt scrise împreună. Popularea este idempotentă: dacă rândul agentului există deja, fișierele de pe disc și legăturile de skill-uri sunt rescrise oricum. Apelantul din producție este crearea spațiului de lucru, nu fiecare pornire a serverului.

Ce poartă un agent

Secțiune intitulată „Ce poartă un agent”
Atribut Ce face
name Identificator scurt, de tip slug (architect, qa). Este și numele față de care se rezolvă @mentions
title Titlu de post lizibil pentru oameni
persona Instrucțiuni de personalitate și comportament în text liber, injectate ca secțiune de prompt
systemPrompt Instrucțiuni suplimentare opționale, injectate ca secțiune „Agent instructions” — nu înlocuiesc restul promptului asamblat
skills Set de nume de skill-uri insensibil la majuscule și minuscule, oglindit pe disc ca legături de skill-uri
adapterId Runner-ul către care trimite agentul. O valoare nulă retombe pe bucla încorporată
modelId Modelul din cadrul acelui adaptor
effort Nivel de raționament, preluat din vocabularul propriu al modelului selectat
contextSize Suprascrierea ferestrei de context
silenceTimeoutMinutes Suprascriere per agent (1–240) pentru monitorizarea tăcerii
reportsTo Id-ul agentului părinte — lanțul ierarhic pe care îl desenează organigrama

Toate acestea se editează în Setări → Spațiu de lucru → Agenți. Agent nou creează un agent fără nume pe care îl completezi apoi.

Skill-uri

Secțiune intitulată „Skill-uri”

Skill-urile sunt nume insensibile la majuscule și minuscule atașate entității de agent. Cu ele se întâmplă două lucruri distincte:

  • Numele sunt listate în promptul asamblat sub un titlu „Skills”. Atât face setul entității de unul singur — nu există o bibliotecă de prompturi per skill care să depindă de el.
  • Directorul fiecărui skill numit (skills/<slug>/SKILL.md din spațiul de lucru) este legat în dosarul propriu al agentului. Pe harness-ul încorporat, frontmatter-ul skill-urilor legate este încărcat automat în promptul de sistem, iar agentul citește un corp la cerere; tastarea /skill:<name> într-o conversație încarcă acel corp ca directivă pentru tura respectivă.

Skill-urile aduse din exterior trec printr-o scanare a lanțului de aprovizionare cu eșec închis, între descărcare și scriere — niciun conținut de skill nu ajunge pe disc sau într-un prompt fără un verdict. Exteriorul înseamnă repo-uri GitHub pe care le înregistrezi singur ca surse de skill-uri: nu există un magazin curatoriat, așa că metadatele proprii ale repo-ului (descrierea lui, numărul de stele, numele skill-ului) sunt date de afișare neîncrezute, iar verdictul scanării este singurul semnal de siguranță. O instalare aduce întregul director al skill-ului, îl fixează la commit-ul din care provine în skills-lock.json, iar o actualizare ulterioară trece din nou prin poartă înainte de a înlocui ceva. Ghidul practic se află în instalează și gestionează skill-uri.

Skill-uri limitate la repo

Secțiune intitulată „Skill-uri limitate la repo”

Un repo își poate livra propriile skill-uri, în oricare dintre locurile convenționale (.agents/skills/, .claude/skills/, .opencode/skills/). Un spațiu extrage fiecare repo legat unul lângă altul, sub repos/<name>/, dar un agent lucrează într-un singur repo o dată — așa că poartă doar skill-urile acelui repo, iar acestea se schimbă când se mută.

Repo-ul activ este dedus din fișierele pe care le atinge agentul: scrierea unui fișier sub repos/<name>/ face din acesta repo-ul activ, în timp ce simpla citire dintr-un repo în altul nu, așa că urmărirea unui simbol până într-un serviciu vecin nu schimbă niciodată setul de sub o sarcină. Într-un spațiu cu un singur repo, răspunsul este cunoscut înainte de prima tură.

Limitarea este o decizie de buget de context. Indexul de skill-uri stă în prompt la fiecare tură, în timp ce corpurile nu, așa că listarea deodată a skill-urilor tuturor repo-urilor costă tokenuri în mod continuu — iar un skill testing dintr-un serviciu induce activ în eroare când munca se desfășoară în altul. Același raționament explică de ce indexul unui agent conține un singur repo, dar compozitorul nu este limitat la fel: numirea unui skill de către tine este un act explicit, așa că /skill:<repo>:<name> ajunge la orice repo din spațiu.

Skill-urile de repo sunt încărcate pentru fiecare adaptor, nu doar pentru harness-ul încorporat. Skill-urile repo-ului activ sunt materializate în directorul de lucru al agentului, care este calea pe care Claude Code o scanează deja; același index este compus în AGENTS.md, pe care îl citește harness-ul încorporat. Skill-urile unui repo trec prin aceeași scanare cu eșec închis ca un skill instalat, înainte să se întâmple oricare dintre acestea — un repo extras este conținut clonat, iar frontmatter-ul lui ajunge într-un prompt.

Permisiuni

Secțiune intitulată „Permisiuni”

Un agent nu are indicatori de permisiune proprii. Dacă poate crea un commit, face push, deschide un pull request, scrie într-un tracker sau ajunge la rețea decid guardrail-urile de acțiune — permite, întreabă întâi sau refuză, la nivelul spațiului de lucru, al agentului sau al spațiului — iar aceleași reguli se aplică indiferent de adaptorul care îl rulează.

Ce primește o rulare nu se schimbă odată cu aceste reguli. O rulare într-un worktree GitHub primește întotdeauna un token GitHub doar pentru citire, iar despre un push se întreabă în momentul în care are loc: configurația git a agentului trimite fiecare push către GitHub prin Control Center, care aplică regula Push către un remote înainte de a-l transmite mai departe.

Vezi Sandbox și securitate pentru cum funcționează asta, inclusiv ce se impune și ce nu la nivel de sistem de fișiere.

Adaptorul decide ce poate fi impus

Secțiune intitulată „Adaptorul decide ce poate fi impus”

Cel mai important câmp al unui agent este adaptorul, pentru că transportul adaptorului determină cât din politica Control Center poate fi impusă efectiv.

Transport Adaptoare Ce impune Control Center
Harness încorporat Control Center (built-in) Totul. Suprafața de instrumente este construită din mod, așa că un instrument nepermis este invizibil, nu doar refuzat; fiecare apel trece prin poarta de aprobare și prin guardrail-urile de acțiune; contractul de finalizare poate îndemna și apoi poate marca drept eșuată o rulare care se termină fără livrabilul ei
Claude CLI Claude Code Instrumentele mcp__* care îi sunt puse la dispoziție, plus comenzile lui Bash, pe care un hook le trimite politicii de acțiuni înainte să ruleze. Instrumentele proprii de citire, scriere și editare ale Claude trăiesc în procesul lui și rulează nevăzute — iar el este lansat cu --dangerously-skip-permissions, pentru că un claude -p neinteractiv s-ar bloca altfel la nesfârșit pe propriul prompt

Concret, doar harness-ul încorporat suportă subagenți, dirijare pe parcursul rulării, pauză și reluare (și, prin urmare, preluarea controlului) și impunerea structurală a modului. Claude Code nu beneficiază de nimic din toate acestea.

Un agent fără niciun adaptor retombe pe Control Center (built-in) — bucla din interiorul serverului, așa că nu există niciun CLI de instalat — iar jurnalul lui de rulare consemnează cc-harness. Fiecare agent populat este creat fără adaptor și fără model, așa că cei cinci agenți ai unui spațiu de lucru nou rulează cu toții acolo, pe modelul implicit al Anthropic, până când setezi un adaptor și un model pentru fiecare agent. Alegerea „adaptor implicit” din asistentul de început este o preferință de client pe care serverul nu o citește niciodată și nu se aplică retroactiv agenților deja creați.

De unde vin agenții

Secțiune intitulată „De unde vin agenții”
  • Populare odată cu spațiul de lucru. Fiecare spațiu de lucru — nu doar primul — primește un CEO plus patru specialiști (qa, architect, engineer, librarian) care raportează acestuia, creați idempotent în fundal la crearea spațiului de lucru. Vezi Spații de lucru și izolare.
  • Adăugare manuală din Setări → Spațiu de lucru → Agenți. Faptul că ceri unui agent să angajeze un coleg nu creează un rând; folosește acel ecran.

Stare în timp real

Secțiune intitulată „Stare în timp real”

Un agent nu are o coloană de stare stocată. Starea lui în timp real este derivată din cele mai recente jurnale de rulare de fiecare dată când este citit:

Stare Semnificație
neverRun Nu există niciun jurnal de rulare
running Cel puțin o rulare este în curs
failed Ultima rulare a dat eroare, sau starea ei de funcționare este eșuată ori moartă
blocked Starea de funcționare a ultimei rulări este blocată, împotmolită sau în buclă
idle Orice altceva — agentul a rulat înainte și nu are nimic în desfășurare

Încă două stări, queued și succeeded, există pentru rulările individuale din arborele de rulări al conversației; lista nu le produce niciodată, pentru că faptul că o rulare încheiată este verde este un lucru despre rulare, nu despre agent.

Lista de prezență arată o imagine paralelă, mai grosieră, sintetizată pe server din evenimentele de rulare în direct — se gândește, rulează, blocat la aprobare, gata — și tocmai de aceea agenții apar alături de oameni. Vezi Multiplayer.

Concepte conexe

Secțiune intitulată „Concepte conexe”

Preferințe documentație

Aspect
Limbă
Română (România)