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

Ciclul de viață al trimiterii agenților

Ce este o trimitere

Secțiune intitulată „Ce este o trimitere”

O trimitere este o rulare a unui agent, într-o conversație, pe un adaptor. Tot ce ține de ea se întâmplă pe cc_server: clientul trimite un mesaj și apoi urmărește cum vin evenimentele înapoi. Nu există nicio cale de trimitere în vreun client.

Agenții sunt treziți din șase motive, pe care rularea le poartă drept context de trezire, ca agentul să știe de ce este treaz:

Motiv de trezire Declanșator
userMessage Cineva a trimis un mesaj într-un spațiu sau a menționat agentul
assignment Un tichet a fost atribuit agentului
pipelineStep Un pas de pipeline l-a trimis
childCompleted Un tichet copil s-a terminat
followUp Un puls de urmărire programat
recovery Calea de recuperare a retrimis după o eroare

Contextul de trezire poartă identificatorii care însoțesc motivul — tichet, spațiu, mesaj, rulare de pipeline — iar aceștia sunt injectați în mediul și în promptul agentului.

Asamblarea promptului

Secțiune intitulată „Asamblarea promptului”

Promptul este construit pe straturi, fiecare fiind o secțiune etichetată:

  • Identitate — id-ul, numele și id-ul spațiului de lucru ale agentului, cu instrucțiunea explicită de a transmite acele UUID-uri exacte instrumentelor limitate la spațiul de lucru. Spațiul de lucru este intrinsec agentului, așa că este mereu prezent.
  • Catalogul de instrumente și protocoalele de resurse, apoi structura spațiului de lucru.
  • Suprascrierea promptului de sistem, dacă agentul are una, apoi persona (parametrizată după rol) și prezentarea echipei.
  • Skill-urile — numele atașate agentului.
  • Contractul de execuție și procedura pentru modul curent.
  • Contextul de trezire și contextul de mențiune: cine a convocat agentul și lista celor din jurul lui.
  • Blocul de mod — generat din profilul de capabilități al modului și din lista lui de instrumente materializate, așa că un prompt nu poate numi niciodată un instrument pe care rularea nu îl are de fapt.
  • Contextul de memorie — fapte recuperate pentru sarcină.
  • Contextul conversației — istoricul recent al spațiului, plafonat la o fereastră verbatim de 50.000 de caractere, indiferent de dimensiunea contextului configurată pentru agent. Istoricul mai vechi nu este eliminat: agentul îl recuperează la cerere cu get_messages, iar mesajele mai vechi relevante semantic ies în continuare la suprafață.

Comenzile sunt împărțite în două locuri. /todo și /compact sunt interceptate în composer și, în mod deliberat, nu sunt niciodată salvate ca mesaje și nici trimise agentului — salvarea /compact ar împinge tăietura de compactare înapoi cu un tur și ar polua transcrierea. /plan este gestionată în ambele: composerul comută modul spațiului, ceea ce face ca suprafața de instrumente, presetarea de guardrail-uri și promptul să fie de acord pentru acest tur și pentru fiecare tur de după el. /goal, /loop și /skill:<name> sunt gestionate în interiorul rulării înseși și doar pe harnessul încorporat — /goal și /loop pornesc muncă autonomă cu un buget de cost, iar un nume prefixat cu skill: este căutat ca skill al cărui corp din SKILL.md devine directiva turului. Spațiul de nume este cel care ține cele două vocabularuri separate: rezolvarea unui nume simplu împotriva skill-urilor însemna că un skill numit plan sau compact era umbrit permanent de cel încorporat. Un nume simplu care nu este încorporat se rezolvă în continuare, pentru mesajele scrise înainte să existe spațiul de nume. Un nume nerecunoscut pur și simplu trece mai departe ca text simplu.

Provisionarea worktree-ului

Secțiune intitulată „Provisionarea worktree-ului”

Înainte ca ceva să ruleze, conversația primește propria rădăcină de lucru, cu un worktree izolat copy-on-write pentru fiecare repo dedesubt. Implicit, aceasta înseamnă fiecare repo legat de spațiul de lucru; un spațiu PR — sau un spațiu creat cu o selecție explicită — provisionează doar repo-urile din lista permisă, iar o conversație de revizuire PR fixează singurul ei repo pe head ref-ul pull request-ului, în timp ce celelalte rămân pe ramura lor implicită. Checkout-ul sursă nu este niciodată modificat, iar întregul director al conversației este recuperat când spațiul este șters.

Copy-on-write este singura implementare oriunde rift este livrat, susținută de binarul nativ inclus. Un sistem de fișiere care nu poate face reflink — sau un director de date aflat pe alt volum decât repo-ul — face ca provisionarea să eșueze, în loc să revină la altă variantă. git worktree este backendul pe Windows, unde nu există niciun backend copy-on-write de construit, și nu este o degradare silențioasă pe alte gazde. Un rift lipsă pe o platformă care îl livrează înseamnă o instalare defectă — serverul refuză să pornească în loc să revină silențios, pentru că o revenire silențioasă ascunde defectul în spatele unei căi mai lente pentru totdeauna.

Identitate și date de autentificare

Secțiune intitulată „Identitate și date de autentificare”

Două identități sunt rezolvate pentru fiecare rulare, înainte de lansarea oricărui proces.

Paternitatea Git. Commit-urile făcute de un agent sunt scrise ca agentul — <Name> (agent) <agentId@agents.control-center.local> atât în GIT_AUTHOR_*, cât și în GIT_COMMITTER_* — fără a se da vreodată drept o persoană. Partea locală este UUID-ul agentului, nu slug-ul numelui lui. Persoanei care a solicitat i se acordă credit printr-un trailer Co-Authored-By:, purtat în mediu și indicat în promptul de sistem. O identitate stabilită explicit de apelant câștigă mereu în fața ambelor.

Identitatea pe hostul de cod. Datele de autentificare GitHub ale rulării sunt mereu doar ale brokerului — un token de instalare App limitat la depozit sau revenirea lui la PAT din mediu — niciodată tokenul stocat al membrului care solicită. actingUserId limitează revenirea la PAT, astfel încât un membru care nu este proprietarul serverului să nu moștenească anvergura serverului; nu suprapune un token personal peste mediul agentului.

Datele de autentificare ale furnizorului de model se rezolvă într-o ordine fixă, iar ordinea contează:

  1. o suprascriere de mediu per adaptor,
  2. mediul apelantului,
  3. depozitul de date de autentificare al serverului (reîmprospătând un token OAuth dacă este aproape de expirare),
  4. mediul procesului.

Deoarece suprascrierea per adaptor vine prima, ea învinge în mod silențios un cont de furnizor conectat în aplicație. Dacă o rulare facturează pe contul greșit, acea suprascriere este primul loc de căutat. Datele de autentificare ale furnizorului sunt globale la nivel de gazdă — partajate între toate spațiile de lucru de pe instalare.

Tokenul GitHub al rulării vine de la brokerul de date de autentificare: un token doar pentru citire, limitat la depozitul worktree-ului. Un push trece prin gateway-ul rulărilor de agenți, care întreabă regula Push către un remote înainte de a-l transmite, și nu este injectată nicio cheie de tichete. Vezi Sandbox și securitate.

Lansare

Secțiune intitulată „Lansare”

Rularea este pornită cu worktree-ul ei ca director de lucru și — pentru Claude Code — cu o configurație MCP generată, ca agentul să poată ajunge la suprafața de instrumente a Control Center. ACP și bash din harness primesc un mediu sanitizat; Claude Code prin NoSandboxAdapter moștenește mediul gazdă.

Transmiterea în flux

Secțiune intitulată „Transmiterea în flux”

Rularea transmite înapoi o secvență tipizată de evenimente, pe care procesorul de flux o persistă ca delta-uri de mesaje, o pliază în segmente de transcriere și o transformă în evenimente de mesagerie:

Eveniment Ce transportă
thinking Ieșire de raționament, redată inline
text Ieșire vizibilă
toolCall O invocare de instrument, cu id-ul și argumentele ei structurate
toolResult Rezultatul corespunzător, marcat când a eșuat sau este un flux parțial
usage Număr de tokeni și cost pentru o fereastră de măsurare
error O eroare, cu codul structurat al adaptorului când acesta a raportat unul
sandboxViolation Sistemul de operare a refuzat un apel de sistem. Emis doar acolo unde un sandbox învelește efectiv procesul — vezi nota de mai sus
debug Diagnostice de rulare (marcaje de lansare, decizii de gardă, îndemnuri de contract)
done Rularea s-a terminat

Ce limitează o rulare

Secțiune intitulată „Ce limitează o rulare”

Nu există în mod deliberat niciun plafon de tururi nicăieri. Un număr fix de iterații ucide munca lungă legitimă (migrări, curățare de tip fan-out) și nu prinde nimic ce gardurile de mai jos nu prind mai devreme. O rulare se termină când:

  • modelul se oprește de la sine;
  • un om o oprește sau preia conversația (ceea ce pune pe pauză harnessul încorporat la următoarea limită de tur curată — o rulare Claude Code, care nu are o limită sigură, este oprită în schimb);
  • se declanșează supraveghetorul de tăcere. Fără nicio ieșire pe durata pragului, iar sesiunea este terminată cu o eroare silentRun. Valoarea implicită este de 15 minute, coborând la 10 în modurile predominant de citire (revizuire și plan); un agent o poate suprascrie între 1 și 240 de minute. Supraveghetorul este armat când un proces copil își raportează PID-ul, așa că acoperă CLI-ul Claude Code — nu harnessul încorporat, care nu generează niciun proces;
  • intervine un plafon de cost — dar doar pentru comenzile autonome.

Gardul împotriva buclei fatale nu este un terminator: trei apeluri identice de instrument la rând și bucla direcționează agentul să schimbe abordarea.

Puse împreună, un tur interactiv obișnuit pe harnessul încorporat nu are plafon de tururi, plafon de cost sau supraveghetor de tăcere. Se termină când modelul se oprește sau când îl oprești tu. Acesta este un compromis deliberat — alternativele ucid toate munca lungă legitimă — dar înseamnă că o rulare interactivă nesupravegheată nu este limitată de nimic altceva decât de judecata modelului însuși.

La mijlocul rulării, un mesaj trimis unui agent aflat în rulare este pus în coadă ca direcționare și consumat la următoarea limită de tur, așa că poți îndrepta o rulare fără să o omori. Direcționarea, pauzarea, subagenții și contractul de finalizare sunt funcții ale harnessului încorporat; Claude Code nu are niciuna dintre ele.

Cum este înregistrată o rulare

Secțiune intitulată „Cum este înregistrată o rulare”

Fiecare trimitere scrie un AgentRunLog: ora de început și de sfârșit, rezumat, număr de tokeni și cost estimat (inclusiv costul cumulat din subagenți), adaptor și model, id de proces și cale de jurnal, conversația și orice tichet sau rulare de pipeline din care face parte, plus două câmpuri de clasificare care poartă cea mai mare parte a adevărului.

  • Starea este grosieră: pending, running, completed, error.
  • Vitalitatea este citirea mai fină: alive, productive, completed, blocked, empty, looping, failed, stalled, dead.
  • Familia de erori grupează util eșecurile: transientUpstream, sandboxInfrastructure, budgetExceeded, processLost, silentRun, unknown.

Închiderea rulării publică AgentRunCompleted și multe depind de el: cumulul de cost al pipeline-ului, reluarea unui pas de pipeline care aștepta rularea, finalizarea tichetului suport, maparea unei orchestrări către o stare terminală, decizia de continuare sau oprire a supraveghetorului de obiective, rolul de verificator și evaluarea bugetului de după rulare. Lista de prezență urmează separat, urmărind jurnalele de rulare recente, nu evenimentul. Notificarea „Agentul a terminat” nu se află pe această listă: evenimentul se declanșează când se încheie fluxul procesului, înainte ca răspunsul să fie scris, așa că notificarea este MessageReceived al turei, publicat după ce mesajul este persistat.

Bugete, după fapt

Secțiune intitulată „Bugete, după fapt”

Aplicarea bugetului este o reacție, nu o poartă. Când o rulare se încheie, evaluatorul compară cheltuiala agentului de la începutul lunii cu plafonul lui efectiv (o politică de buget legată, dacă există, altfel cifra lunară proprie a agentului; zero înseamnă nelimitat). Depășirea pragului soft înregistrează un incident de avertizare; epuizarea bugetului înregistrează un incident sever și comută starea ciclului de viață al agentului în paused pe organigramă. Trimiterea acceptă în continuare lucru de la acel agent. Un trigger de pipeline BudgetThresholdCrossed poate porni muncă de continuare din același eveniment.

Descendența reîncercărilor

Secțiune intitulată „Descendența reîncercărilor”

Fiecare jurnal de rulare poate purta descendența reîncercărilor — un id de rulare părinte, un contor de încercări și un rezumat de continuare. Arborele de rulări al conversației afișează numărul încercării când acesta este diferit de zero. Un „mai încearcă” din chat este o trimitere nouă, cu un jurnal de rulare nou.

Concepte conexe

Secțiune intitulată „Concepte conexe”

Preferințe documentație

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