Agenți¶

Un agent (ai.agent) descrie cum se comportă un coleg AI. Nu este același lucru cu contul de utilizator Odoo ca care poate rula.

Două forme¶

Persona de chat (fără utilizator asociat)¶

Exemplu: Jarvis, livrat implicit.

Folosit atunci când un om deschide chatul AI.
Rulează ca utilizatorul care conversează (ACL-urile sale, calitatea sa de membru în politica AI).
Prompt de sistem, suprascrierile de model și capabilitățile modelează sesiunea.
Nu este necesar un supervizor.
Limitat la grupuri poate restrânge cine poate invoca această persona.

Coleg autonom (utilizator asociat)¶

Utilizator indică un res.users dedicat.
Rulează cu drepturile acelui utilizator (ca un angajat uman).
Supervizor este obligatoriu — autorizează munca și aprobă propunerile de scriere.
Regulile de canal decid cine se poate adresa agentului și cu ce domeniu de capabilități.
Apare ca is_ai_agent pe utilizator (indicator doar în citire).

Pericol

Asocierea unui utilizator cu privilegii extinse unui agent echivalează cu acordarea acelui privilegiu unui lucrător vulnerabil la prompt injection. Creați întotdeauna un utilizator restrâns pentru agent. Nu folosiți niciodată superutilizatorul, utilizatorii de portal, conturile Settings sau AI Administrator.

Câmpurile formularului agentului¶

AI ‣ Configurare ‣ Comportament ‣ Agenți

Câmp	Scop
Nume	Nume afișat (de ex. Support Assistant).
Activ	Agenții inactivi nu rulează.
Model	Suprascriere opțională a modelului; în caz contrar, modelul principal / valorile implicite.
Temperatură	Suprascriere de eșantionare pentru turele proprii ale acestui agent, reținută pentru modelele care nu o acceptă.
Tokeni maximi (0 = fără suprascriere)	`0`, valoarea implicită, nu trimite nicio limită: se aplică limita proprie de ieșire a modelului. O valoare pozitivă limitează în schimb completările acestui agent — consultați nota de mai jos.
Prompt de sistem	Adăugat după straturile globale de prompt.
Capabilități	Plafonul claselor de instrumente pentru acest agent.
Limitat la grupuri	Cine poate invoca ca persona de chat.
Utilizator	Utilizator intern asociat, opțional (unic).
Supervizor	Obligatoriu dacă este setat Utilizator; trebuie să fie AI: User.
Reguli canal	Liste de permisiuni cu refuz implicit, pe canal.
Agent implicit	Marchează persona folosită implicit în chat.

Notă

Un plafon are efect numai acolo unde înregistrarea modelului publică propria limită de ieșire și se comportă diferit în funcție de furnizor. Ambele reguli, precum și ce face o actualizare agenților care au deja o valoare, sunt descrise o singură dată în Plafoane de completare.

Reguli de canal¶

AI ‣ Configurare ‣ Comportament ‣ Agenți → reguli de canal (sau vizualizări dedicate ale regulilor de canal).

Canale:

Mesaj direct Discuss
@mențiune în chatter
Activitate (activitate atribuită)
Atribuire (de ex. persoana căreia i se atribuie o sarcină de proiect) — esențial: fără aceasta, oricine poate atribui o sarcină nu ar putea fi deosebit de o poartă Discuss
E-mail / panou de chat AI — rezervate / conectare progresivă; refuzul implicit se aplică în continuare

Câmpurile regulii:

Grupuri permise / Utilizatori permiși — audiența. O audiență goală nu se potrivește cu nimeni (nu cu toată lumea).
Poate solicita — audiența poate declanșa o rulare ad-hoc.
Mod de domeniu:
- Drepturi agent ∩ drepturi solicitant (intersect, implicit) — clasele de capabilități pe care le dețin ambii. Datele sunt în continuare citite/scrise ca agent.
- Drepturile complete ale agentului (agent_full) — doar pentru o audiență de încredere.

Important

intersect nu înseamnă „rulează ca solicitantul”. Restrânge doar clasele de instrumente (citire/scriere/web/…). Vizibilitatea înregistrărilor rămâne cea a agentului. Adăugați în lista de permise doar persoane în care aveți încredere pentru tot ce poate vedea agentul.

Flux de intrare (simplificat)¶

Mesajul / atribuirea / activitatea vizează agentul.
Dacă solicitantul este blocat → refuz (fără LLM).
Se rezolvă regula de canal (refuz implicit) → altfel refuz + încălcare / avertisment.
Se pune în coadă cererea de intrare; cron-ul de golire se trezește.
Un triaj opțional poate doar să scadă autoritatea.
Se creează sarcina / rularea sub domeniul supervizorului; se execută ca utilizator agent, cu plafonul de capabilități angajat.
Scrierile urmează Mod de scriere al sarcinii (implicit: propuneri în așteptare pentru supervizor; consultați Modul de scriere al sarcinii (doar pentru rulările agentului)).
Agentul postează note / ciorne pe fir ca el însuși — textul clientului nu devine niciodată o acordare tacită de privilegii.

Sarcini și rulări¶

Meniuri operaționale (AI: User, în domeniul supervizorului):

AI ‣ Agenți ‣ Sarcini — sarcini permanente și programate.
AI ‣ Agenți ‣ Elemente de lucru — coadă pe înregistrare, golită în rulări copil izolate (consultați Elemente de lucru pe înregistrare).
AI ‣ Agenți ‣ Rulări — registrul de execuție și pașii.

Supervizorii le folosesc pentru a vedea ce a încercat agentul, ce instrumente au rulat și ce propuneri așteaptă.

Elemente de lucru pe înregistrare¶

O sarcină permanentă care procesează multe documente (facturi furnizor și similare) nu trebuie să încarce toate atașamentele într-o singură conversație: fereastra de context a modelului se umple, iar o singură eroare a furnizorului anulează întregul lot.

Puneți două texte pe sarcină:

Instrucțiune — scout-ul. Căutați ID-urile candidate, apelați queue_work_items, apoi opriți-vă. Nu citiți PDF-uri aici.
Instrucțiune element de lucru — copilul. Substituenți {model} și {id}. Fiecare înregistrare pusă în coadă rulează aceasta într-o conversație nouă. Dacă este goală, se folosește un prompt generic pentru o singură înregistrare, care interzice în continuare punerea în coadă.

Acțiunea programată AI: drain agent work items (în fiecare minut) pornește cel mult opt elemente în așteptare pe tick, în continuare limitate de același buget de dispecerizare ca celelalte sarcini programate. Rulările copil lasă gol câmpul Rulare părinte — acel câmp marchează o reluare după aprobare, nu o ramificare — și nu se iau în calcul pentru plafonul zilnic al sarcinii sau pentru întrerupătorul de siguranță.

queue_work_items necesită capabilitatea write. Funcționează doar pe o rulare a unei sarcini permanente (nu pe o rulare din inbox, nu pe una copil) și pune în coadă numai înregistrările pe care agentul le poate citi. ID-urile aflate încă în așteptare sau în execuție sunt omise; elementele finalizate sau eșuate pot fi puse din nou în coadă. Cel mult 200 de ID-uri pe apel.

Modul de scriere al sarcinii (doar pentru rulările agentului)¶

Fiecare sarcină are un Mod de scriere. Se aplică doar rulărilor agentului dispecerizate pentru acea sarcină — nu și chatului interactiv (chatul folosește setarea globală din AI ‣ Configurare ‣ Setări).

Valoare	Efect asupra rulărilor sarcinii respective
Solicită întotdeauna confirmare (`confirm`, implicit)	Fiecare creare / scriere / ștergere / atașare de fișier devine un `ai.pending.write` pentru supervizor.
Creare automată, confirmare pentru actualizări (`hybrid`)	Creările se aplică imediat; actualizările, ștergerile și atașările de fișiere necesită în continuare aprobare.
Aplică imediat (`auto`)	Modificările permise se aplică imediat, cu drepturile utilizatorului agent și în limita plafonului de capabilități al rulării.

Parametrul global ai.write_mode nu suprascrie niciodată o sarcină: un administrator nu poate trece toți agenții nesupravegheați pe automat cu o singură setare. hybrid / auto sunt opțiuni deliberate, per sarcină, pentru lucrări de încredere și cu risc redus — de exemplu o sarcină permanentă de datorii furnizori care completează ciorne de facturi furnizor și a cărei aptitudine nu postează niciodată facturi. Preferați confirm ori de câte ori o rulare ar putea posta, plăti, șterge sau atinge date orientate către clienți.

Când se creează o propunere, platforma plasează și o activitate To-Do (și, de obicei, o notă în chatter) pe înregistrarea comercială țintă, dacă există una (de ex. factura furnizor care se actualizează), revenind la sarcina agentului pentru creările care nu au încă un id. Confirmarea și Anularea rămân în AI ‣ Propuneri de scriere; activitatea este doar o notificare în systray, astfel încât supervizorul să ajungă la factură sau la partener, nu doar la lista abstractă de propuneri. Formularul Propuneri de scriere are Deschide înregistrarea pentru același salt. Activitatea se închide când propunerea este aplicată, anulată sau expirată.

Sfat

Pragul de refuz absolut blochează instrumentele AI brute pe fiecare model de platformă ai.*. Prin urmare, agenții nu își pot „gestiona” propria coadă de aprobări sau configurația AI prin instrumente — și nu ar trebui să încerce. Notificările platformei și activitățile de verificare conduse de aptitudini pe documentele comerciale folosesc căi controlate; instruiți agenții să nu inventeze apeluri de instrumente de configurare AI, altfel vor consuma refuzuri și avertismente.

Rândul din registru al unei rulări devine vizibil pentru alți utilizatori abia după ce încercarea s-a încheiat sau a fost suspendată pentru aprobare: rândul este scris și finalizat în tranzacția proprie a worker-ului, deci nimic nu este comis cât timp agentul încă lucrează. Lista de rulări afișează, prin urmare, lucrările finalizate, nu o vedere în timp real a ceea ce se execută chiar acum.

Rulările eșuate au un Tip de eroare pe formularul rulării, care arată ce fel de eroare a fost — consultați Monitorizare pentru valorile care merită urmărite.

Oprirea unei rulări¶

Deschideți rularea și folosiți Anulare cerere. Butonul apare cât timp rularea este În desfășurare sau În așteptarea aprobării, iar cererea poate fi făcută doar de supervizorul agentului sau de un administrator AI.

Important

Acest buton nu este un control general de tip „oprește agentul acum”, din cauza comportamentului registrului descris mai sus: o rulare care se execută normal nu are încă un rând, deci nu există nimic de deschis. În practică îl folosiți pe o rulare suspendată în În așteptarea aprobării sau pe una rămasă în În desfășurare după un incident anterior al serverului. Pentru a opri din timp lucrările nedorite, păstrați Termen (secunde) al sarcinii suficient de scurt încât o rulare să se încheie singură și debifați Activ pe sarcină, pentru a nu mai fi dispecerizată.

Anularea unei rulări suspendate în În așteptarea aprobării retrage propunerile de scriere deschise ale acesteia, apoi închide rularea: ca Efectuat, dacă o propunere a acelei rulări fusese deja aplicată, altfel ca Eșuat, cu Tip de eroare waiting_approval_empty, deoarece nimic din ce a propus nu a fost aprobat.

Anularea unei rulări care chiar se mai execută este cooperativă, niciodată imediată. Cererea este citită la începutul fiecărei runde a furnizorului și din nou înainte de fiecare apel de instrument, deci are efect doar după încheierea ciclului cerere-răspuns aflat deja în curs — socotiți până la aproximativ două minute cu valorile implicite livrate, și niciodată în mijlocul unui apel către furnizor. O astfel de rulare se închide apoi ca Eșuat, cu Tip de eroare cancelled; nu există o stare separată Anulat. Pașii pe care i-a executat rămân în fila Pași, răspunsul rulării consemnează anularea în loc de un răspuns parțial, iar orice propuneri de scriere deschise de ea sunt anulate odată cu ea, astfel încât nimic nu rămâne aprobabil. O anulare este neutră pentru dezactivarea automată a sarcinii: nu se numără ca eșec și nu șterge o serie existentă.

Notă

Dacă nu mai există niciun worker care să audă cererea, butonul răspunde Nimic în curs de anulat în loc să confirme. Nimic nu este defect — cel mai probabil rularea s-a încheiat deja sau worker-ul ei s-a oprit — dar niciun worker nu va vedea cererea, iar rularea nu se va opri din această cauză. Reîncărcați înregistrarea pentru a vedea unde se află de fapt; rularea unui worker oprit este închisă de reaperul de rulări blocate de mai jos.

Rulări al căror worker s-a oprit¶

Dacă procesul de server care gestionează o rulare este oprit forțat (repornire, lipsă de memorie, oprire bruscă), nu mai rămâne nimeni care să încheie rularea. O acțiune programată, AI: reap stuck agent runs, rulează la fiecare 15 minute și le închide: rularea este înregistrată ca Eșuat cu Tip de eroare reaped_stuck, se postează o notă pe sarcină, iar orice propuneri de scriere încă în așteptare pe ea sunt expirate, astfel încât nimic să nu poată fi aprobat în numele unei rulări oprite. Dacă defecțiunea a luat cu ea și rândul din registru, jobul de întreținere reconstruiește unul din înregistrarea lăsată de dispecerizare — cu condiția ca acea înregistrare să fi fost scrisă; o oprire suficient de timpurie încât să împiedice chiar și aceasta nu lasă nimic din care să se reconstruiască.

Nu vă așteptați la acea închidere în 15 minute. Rularea trebuie să depășească propria limită de timp plus o perioadă de grație (10 minute implicit — consultați Configurare) înainte ca o trecere să o atingă, iar trecerile sunt la 15 minute distanță, deci cazul cel mai defavorabil este de aproximativ jumătate de oră. O trecere închide cel mult 200 de rulări, începând cu cele mai vechi; o acumulare mare după o furtună de reporniri se golește în trecerile următoare.

Aceeași acțiune programată eliberează și rulările suspendate în În așteptarea aprobării care nu mai au nicio propunere deschisă — de exemplu când ultima propunere a expirat în timp ce supervizorul încă o confirma — astfel încât o astfel de rulare să nu rămână cu un memento de activitate pentru o propunere care nu mai există.

Sfat

Fiecare încercare de dispecerizare poartă un Token de expediere, afișat pe formularul rulării. Este cheia care leagă o rulare de înregistrarea de scurtă durată scrisă la pornirea rulării, pe care o caută atât reaperul, cât și Anulare cerere — deci este și valoarea de citat atunci când corelați o rulare cu jurnalul serverului.

Verificarea instrucțiunii înainte de rulare¶

Rulările programate și cele pornite cu Rulează acum execută direct instrucțiunea permanentă a sarcinii. Bifați Triere la expediere pe o sarcină pentru a rula aceeași verificare de etapa 1 pe care o primește un agent adresat din chat. Verificarea poate doar să restrângă ce acordă deja sarcina — nu extinde niciodată nimic.

De luat în considerare înainte de a o activa:

costă un apel suplimentar de model pe rulare (timp și tokeni), iar planificatorul rezervă aproximativ 30 de secunde din propriul buget de tick pentru acel apel. O sarcină al cărei Termen (secunde) este deja aproape de limita de timp a worker-ului poate fi, prin urmare, omisă în loc să fie dispecerizată;
verificarea are propriul termen scurt de 15 secunde și este fail-closed: un model de triere lent, inaccesibil sau care răspunde în afara schemei se consideră un refuz;
un refuz înseamnă că agentul nu pornește niciodată. Rularea este înregistrată ca Eșuat cu Tip de eroare triage_denied, se postează o notă pe sarcină și se creează o activitate De făcut pentru supervizor — astfel încât niciun refuz nu este silențios;
refuzurile se iau în calcul pentru dezactivarea automată a sarcinii. Sarcina este arhivată după ce cinci rulări consecutive au eșuat și seria are mai mult de șapte zile, iar supervizorul ei este notificat. Deoarece un eșec al trierii este un refuz, o pană lungă a furnizorului poate arhiva o sarcină care nu a fost niciodată configurată greșit; de aceea opțiunea este per sarcină și dezactivată implicit;
ceea ce a decis verificarea este consemnat pe rulare ca Verdict triere, în fila Instantaneu, și este gol la fiecare rulare a unei sarcini care nu a optat. Este telemetrie, nu o limită: restrângerea pe care o descrie este deja consemnată în Capacități permise ale rulării, pe care le citește poarta de acces.

Comutatorul global de oprire pentru trierea de etapa 1 — atât adresarea de intrare, cât și această verificare înainte de rulare — este parametrul de sistem ai.triage_enabled, în Setări ‣ Tehnic ‣ Parametri ‣ Parametri sistem (care necesită modul dezvoltator).

Etapele proiectului AI Ops¶

Modulul livrează o categorie de proiect AI, un șablon de proiect AI Agent și un pachet comun de etape:

Etape: Inbox → Review → Ready → Doing → Waiting → Done / Cancelled

Utilizare sugerată:

constatările de audit automate ajung în Inbox fără persoană responsabilă;
managerii le rafinează în Review;
atribuiți utilizatorul agent doar de la Ready;
Waiting pentru intervenție sau aprobare umană;
nu aplicați niciodată automat aptitudini/politici dintr-un audit fără un om.

Pachetul Support Assistant¶

Agentul Support Assistant, livrat inactiv, cu capabilități ask+read și reguli de canal ale căror audiențe sunt goale până când le configurați. Se activează prin:

Crearea unui utilizator intern restrâns (citire helpdesk/proiect, după nevoie).
Asocierea lui pe agent; setarea supervizorului.
Completarea audiențelor canalelor (grupurile/utilizatorii care pot trimite DM / atribui / @menționa).
Setarea Activ.
Reglarea regulilor de acces AI pentru modelele de tichete.

Constrângeri de identitate (rezumat)¶

La momentul asocierii, modulul respinge utilizatorii agent care sunt:

superutilizator (uid 1);
utilizator share/portal;
administrator Settings / de sistem;
utilizator AI Administrator;
deținători de chei API (risc de autentificare neinteractivă).

Aceste verificări se fac la un moment dat pe formularul agentului — nu „promovați” ulterior utilizatorul din meniul Utilizatori.

Urmează: rețete practice în Rețete pentru agenți.