Agenți și persoane — AiHummer Documentație

Un agent este unitatea pe care AiHummer o plasează în fața unei conversații. Fiecare agent are o personalitate, propriul său model, un prompt structurat și un set de abilități, iar fiecare modificare a acestuia este versionată. Agenții sunt gestionați din interfața de administrare web și prin API-ul de administrare sub /v1/admin/agents/*.

Această pagină tratează din ce este alcătuit un agent, cum este asamblat promptul structurat „G3” și cum un agent își poate edita în siguranță propriul profil.

Registrul agenților

Registrul este un catalog complet CRUD al agenților. Pentru fiecare agent definiți o identitate, o persoană, modelul pe care rulează și abilitățile pe care le poate folosi. Deoarece gateway-ul este multichiriaș, agenții trăiesc în interiorul unui spațiu de lucru și sunt izolați ca orice alte date ale chiriașului.

Persoană — vocea și comportamentul agentului, transpuse într-o grajdă, strat prietenos cu cache-ul al promptului sistemului.
Model per agent — fiecare agent își poate fixa propriul model și furnizor, deci un un agent ieftin și un agent de referință pot coexista în același spațiu de lucru.
Competențe — abilitățile per-agent și partajate transformă un bloc „Abilități” în prompt; ei descriu capacități, nu greutăți.

[!NOTE] Un model pe agent este independent de rutare. Rutarea la nivel de model (simplă / standard / complex) alege o clasă de model pentru un tur, în timp ce per-agent modelul este implicitul agentului. Vezi Rutare.

Versiuni, revenire și clonare

Fiecare schimbare semnificativă adusă unui agent este capturată ca versiune. Acest lucru face ca configurarea agentului să fie audibilă și reversibilă: poți revizui ce s-a schimbat, anula la o versiune anterioară, sau clonă un agent pentru a-l folosi ca punct de plecare pentru unul nou. Resursele de versiune și profil se află sub /v1/admin/agents/* (profil, secțiuni, abilități, versiuni).

[!TIP] Clonează un agent funcțional înainte de o rescriere majoră a persoanei sau a promptului. Dacă noul dacă direcția nu funcționează, originalul este încă la un pas de rollback.

Promptul structurat „G3”

În locul unui singur prompt de sistem cu text liber, AiHummer folosește un profil de agent structurat (intern intern „G3”). Identitatea este descompus în câmpuri mai degrabă decât îngropat în proză, iar restul sugestiei este construit din elemente numite secțiuni plus un an integrare bloc. Orchestratorul le redă în promptul sistemului stratificat, păstrând părțile stabile (identitate, persoană, secțiuni) într-un prefix memorabil și adăugând datele volatile la final.

Structura face ca un profil să fie ușor de editat câmp cu câmp, ușor de comparat între versiuni și predictibil de afișat — nu există nicio amestecătură ascunsă de prompturi.

G3 profile
├── identity fields   (decomposed: name, role, ...)
├── sections          (named, ordered prompt blocks)
└── onboarding        (first-run guidance)

Auto-corectare în spatele unui filtru de aprobare

Un agent poate fi autorizat să editează propriul profil folosind instrumente de auto-editare — de exemplu pentru a rafina o secțiune sau a actualiza procesul său de integrare. Acest lucru este protejat în mod deliberat:

Auto-corectările trec prin poartă de aprobare: o modificare propusă este înregistrată și trebuie aprobat de un om înainte de a intra în vigoare. O modificare respinsă nu este niciodată aplicat.
Schimbarea este capturată ca una nouă versiune, așadar o auto-revizuire este la fel de verificabilă și reversibil ca orice editare manuală.

[!WARNING] Auto-corectarea este puternică. Ține-o în spatele porții de aprobare astfel încât un agent să nu poată rescrie în tăcere propria identitate. Examinează propunerile de auto-corectare în același mod în care revizuiește orice modificare privilegiată.

Parolele de e-mail merg în seif

Dacă configurația unui agent include acreditive de e-mail (pentru mail instrument), parola este scrisă în seif de acreditări criptate, nu sunt stocate în profil sau incluse în prompt. Secretele nu intră niciodată în contextul modelului.

Politica de execuție: context, sesiuni și agenți copil

Începând cu versiunea 1.3, un agent are o politică de execuție — câmpul runtime_policy din API-ul de administrare (/v1/admin/agents la creare și actualizare). Este un obiect JSON validat strict cu "version": 1: un {} gol restaurează valorile implicite, omiterea câmpului la actualizare păstrează politica anterioară, iar câmpurile necunoscute și valorile în afara limitelor sunt respinse. Politica nu acordă instrumente și nu extinde drepturi — stabilește doar bugete și termene. Clonarea unui agent și predarea unui tur către el o moștenesc.

context — bugetul istoricului: max_tokens, reserve_tokens și history_share decid cât istoric intră într-o cerere; max_history_messages limitează fereastra de mesaje, bootstrap_max_chars — dimensiunea blocului de profil. Când contextul este setat explicit, mesajele vechi sunt compactate într-un rezumat pe loturi înainte de construirea cererii curente.
- pruning — curățarea rezultatelor de instrumente învechite: după vechime (ttl_seconds), protejând ultimele răspunsuri (keep_last_assistants), tăiere ușoară (soft_trim_ratio, head_chars, tail_chars) și înlocuire completă cu textul placeholder peste hard_clear_ratio. Textul utilizatorului, imaginile și istoricul complet din baza de date nu sunt atinse.
- memory_flush — înainte de compactare, un agent fără instrumente scrie o notă scurtă despre obiective, decizii și treburi neterminate (soft_threshold_tokens); ultimele trei note ale aceluiași dialog sunt amestecate în context ca referință neverificată.
session — ciclul de viață al dialogului: idle_reset_minutes începe un context nou după o pauză (istoricul brut se păstrează), index_prune_after_days și index_max_entries scot dialogurile vechi din lista implicită fără a le șterge. scope = per-peer (un dialog per utilizator verificat în toate canalele) sau per-channel-peer (un dialog separat per canal).
children — agenți copil: max_depth (până la 4), max_concurrent (până la 8 per arbore de execuție), max_per_parent (până la 5), timeout_seconds (până la 48 de ore, dar nu mai mult decât părintele) și archive_after_minutes — când execuțiile încheiate ies din lista implicită. Valorile suprascriu pentru acest agent setările globale AIHUMMER_SUBAGENT_MAX_DEPTH și AIHUMMER_SUBAGENT_TIMEOUT_SEC.
max_iterations (1–256) — limita de pași a buclei de apelare a funcțiilor pentru scenarii verificate cu multe delegări.
app — doar pentru aplicația AiHummer: reasoning_effort, service_tier și modul de răspuns scurt direct_completion (auto sau always cu max_tokens până la 4096 și timeout_ms până la 60 000).
interaction — permisiuni explicite pentru lucrul cu sesiunile: user_ids, session_agent_ids, spawn_agent_ids, vizibilitatea session_visibility (self, agent sau granted), session_send, interdicții de instrumente pentru apelurile copil (child_tool_deny, child_leaf_tool_deny) și elevated_telegram_user_ids — un subset al user_ids căruia i se permite să ceară o execuție code_exec explicit ridicată (aprobările nu sunt ocolite). Nu există metacaractere și nici permisiuni pentru întregul chiriaș.

API de administrare

Agenții și profilele lor structurate sunt gestionate prin API-ul de administrare, care este protejat de OIDC și auditat:

Resursă	Scop
`/v1/admin/agents`	Listează, creează, actualizează, șterge agenți (CRUD)
`/v1/admin/agents/.../profile`	Profilul G3 structurat (câmpuri de identitate)
`/v1/admin/agents/.../sections`	Secțiuni de prompt denumite
`/v1/admin/agents/.../skills`	Abilități per agent
`/v1/admin/agents/.../versions`	Istoric versiuni, revenire și clonare

Unde următor?

Înțelege cum agenții efectuează o rundă și generează ajutoare în Orchestrare și sub-agenti.
Vezi cum un mesaj primit ajunge la un agent specific în Rutare.
Oferiți agenților dvs. memorie pe termen lung cu Memorie (Einstein).