Ügynökök¶

Egy agent (ai.agent) azt írja le, hogyan viselkedik egy MI-kolléga. Ez not ugyanaz, mint a Odoo felhasználói fiók, amelyen futhat.

Két forma¶

Csevegés személyiség (nincs kapcsolt felhasználó)¶

Példa: kiszállítás alapértelmezés szerint Jarvis.

Akkor használják, amikor egy ember megnyitja az AI-csevegést.
A as the chatting user fut (az ACL-jeik, az AI-irányelv-tagságuk).
A munkamenetet a Rendszer prompt, a modell felülírásai és a képességek alakítják.
Nincs szükség felügyelőre.
A Csoportokra korlátozva mezővel korlátozható, hogy ki hívhatja meg ezt a personát.

Autonóm kolléga (kapcsolt felhasználó)¶

Felhasználó pont egy dedikált res.users-nél.
that user’s jogokkal fut (mint egy emberi alkalmazott).
Felügyelő kötelező – engedélyezi a munkát és jóváhagyja a javaslatok írását.
A csatornaszabályok határozzák meg, hogy ki és milyen képességekkel szólíthatja meg az ügynököt.
is_ai_agent-ként jelenik meg a felhasználónál (csak olvasható jelző).

Veszély

A széles körű jogosultságokkal rendelkező felhasználó összekapcsolása egy ügynökkel egyenértékű azzal, mintha ezt a jogosultságot egy azonnali beadható dolgozónak adná. Mindig hozzon létre egy narrow felhasználót az ügynök számára. Soha ne használja a szuperfelhasználói, portálfelhasználói, Beállítások- vagy AI-rendszergazdai fiókokat.

Ügynök űrlap mezői¶

AI ‣ Konfiguráció ‣ Viselkedés ‣ Ügynökök

Mező	Cél
Név	Megjelenítési név (pl. Support Assistant).
Aktív	Az inaktív ügynökök nem futnak.
Modell	Opcionális modell felülbírálása; else main / defaults.
Hőmérséklet	Mintavételezés felülbírálása ennek az ügynöknek a saját köreiben; azoknak a modelleknek nem küldjük el, amelyek nem fogadják el.
Max. token (0 = nincs felülírás)	A `0` az alapértelmezés: egyáltalán nem küld korlátot, a modell saját kimeneti korlátja érvényes. Pozitív érték ehelyett ennek az ügynöknek a válaszait korlátozza — lásd az alábbi megjegyzést.
Rendszer prompt	Hozzáfűzve a globális prompt rétegek után.
Képességek	A szerszámosztályok felső határa ehhez az ügynökhöz.
Csoportokra korlátozva	Ki hívhat meg chat-személyként.
Felhasználó	Opcionális kapcsolódó belső felhasználó (egyedi).
Felügyelő	Kötelező, ha a Felhasználó be van állítva; AI: Felhasználónak kell lennie.
Csatornaszabályok	Alapértelmezett-megtagadó engedélyezési listák csatornánként.
Alapértelmezett ügynök	A csevegésben alapértelmezettként használt személyt jelöli meg.

Megjegyzés

A korlát csak ott érvényesül, ahol a modell rekordja saját kimeneti korlátot közöl, és szolgáltatónként másképp viselkedik. Mindkét szabályt, valamint azt, hogy egy frissítés mit tesz a már értékkel rendelkező ügynökökkel, egy helyen írjuk le: Válaszhossz-korlátok.

Csatornaszabályok¶

AI ‣ Konfiguráció ‣ Viselkedés ‣ Ügynökök → csatornaszabályok (vagy dedikált csatornaszabályok nézetei).

Csatornák:

Discuss közvetlen üzenet
Üzenetfolyam @említés
Tevékenység (hozzárendelt tevékenység)
Hozzárendelés (pl. projektfeladat megbízottja) – kritikus: e nélkül senkit, aki tud feladatot kijelölni, nem lehetne megkülönböztetni a Discuss kaputól
Email / AI csevegőpanel — fenntartott / progresszív vezetékezés; default-deny továbbra is érvényes

Szabálymezők:

Engedélyezett csoportok / Engedélyezett felhasználók — közönség. Empty audience matches nobody (nem mindenki).
Kérelmezhet — a közönség ad-hoc futtatást indíthat el.
Hatókör mód:
- Ügynöki jogok ∩ kérelmező jogai (intersect, alapértelmezett) — a képesség osztályai mindketten érvényesek. Az adatok olvasása/írása továbbra is agent-ként történik.
- Az ügynök teljes jogköre (agent_full) – csak megbízható közönség.

Fontos

intersect a not „futtatás kérőként”. Csak az eszközosztályokat szűkíti (olvasás/írás/web/…). A rekord láthatósága az ügynöké marad. Csak azokat a listákat engedélyezze, akikben megbízik, amit az ügynök láthat.

Bejövő folyamat (egyszerűsítve)¶

Az üzenet/megbízás/tevékenység az ügynököt célozza.
Ha a kérelmező banned → elutasítás (nem LLM).
Csatornaszabály feloldása (alapértelmezett megtagadás) → különben elutasítás + megsértés / figyelmeztetés.
Bejövő kérés sorba állítása; drain cron felébred.
Az opcionális osztályozás csak a jogosultságot vonhatja le.
Feladat létrehozása / futtatása felügyelői hatókörben; végrehajtani ügynök felhasználóként, lekötött képességplafonnal.
Az írások az adott feladat Write Mode beállítását követik (alap: függő javaslatok a felügyelőnek; lásd Feladat írási mód (csak ügynök-futtatások)).
Az ügynök saját magaként tesz közzé megjegyzéseket/piszkozatokat a szálon – az ügyfél szövege soha nem válik csendes kiváltságtá.

Feladatok és futtatások¶

Működési menük (AI: Felhasználó, felügyelői hatókörű):

AI ‣ Ügynökök ‣ Feladatok — standing és ütemezett feladatok.
AI ‣ Ügynökök ‣ Munkatételek — rekordonkénti sor, izolált child futtatásokra ürítve (lásd Rekordonkénti munkatételek).
AI ‣ Ügynökök ‣ Futtatások — végrehajtási főkönyv és lépések.

A felügyelők ebből látják, mit próbált az ügynök, mely eszközök futottak, és mely javaslatok várnak.

Rekordonkénti munkatételek¶

Egy standing feladat, amely sok dokumentumot dolgoz fel (szállítói számlák és hasonlók), nem tölthet minden mellékletet egy beszélgetésbe: a modell kontextusablaka megtelik, és egy szolgáltatói hiba az egész köteget megállítja.

Két szöveget tegyen a feladatra:

Utasítás — a felderítő. Keresőjelölt azonosítók, queue_work_items, majd megáll. Itt ne olvasson PDF-et.
Munkatétel-utasítás — a child. Helykitöltők: {model} és {id}. Minden sorba rakott rekord ezt új beszélgetésben futtatja. Üresen egy általános, egy rekordra szóló promptot kap, amely továbbra is tiltja a további sorba rakást.

Az AI: ügynök munkatételek ürítése ütemezett művelet (percenként) tickenként legfeljebb nyolc pending tételt indít, ugyanazzal a dispatch költségvetéssel, mint a többi ütemezett feladat. A child futtatások Szülő futtatás mezője üres marad — az egy jóváhagyási újrajátszás jele, nem fan-out — és nem számítanak a feladat napi korlátjába vagy a megszakítóba.

A queue_work_items write képességet igényel. Csak standing-feladat futtatásán működik (nem inbox, nem child), és csak olyan rekordokat rak sorba, amelyeket az ügynök olvashat. A még pending vagy running azonosítókat kihagyja; a done vagy failed tételek újra sorba rakhatók. Hívásonként legfeljebb 200 azonosító.

Feladat írási mód (csak ügynök-futtatások)¶

Minden feladatnak van Write Mode beállítása. Ez csak az adott feladathoz indított ügynök-futtatásokra vonatkozik — az interaktív chatre nem (a chat a AI ‣ Konfiguráció ‣ Beállítások alatti globális beállítást használja).

Érték	Hatás az adott feladat futtatásaira
Mindig kérjen megerősítést (`confirm`, alapértelmezett)	Minden létrehozás / írás / törlés / fájlcsatolás `ai.pending.write` javaslat lesz a felügyelőnek.
Automatikus létrehozás, frissítések megerősítéssel (`hybrid`)	A létrehozások azonnal érvényesülnek; a frissítések, törlések és fájlcsatolások továbbra is jóváhagyást igényelnek.
Azonnali alkalmazás (`auto`)	Az engedélyezett módosítások azonnal érvényesülnek az ügynök-felhasználó jogai és a futtatás képességkorlátja alatt.

A globális ai.write_mode paraméter soha nem írja felül a feladatot: egy adminisztrátor nem tud egyetlen beállítással minden felügyelet nélküli ügynököt auto-ra állítani. A hybrid / auto tudatos, feladatonkénti opt-in megbízható, alacsony kockázatú munkára — például egy olyan állandó, szállítói kötelezettségeket kezelő feladatra, amely piszkozat szállítói számlákat tölt ki, és amelynek skillje soha nem könyveli le a számlákat. Maradjon confirm, ha a futtatás lekönyvelhet, fizethet, törölhet vagy ügyfél-látható adatot érinthet.

Javaslat létrehozásakor a platform To-Do tevékenységet (és általában chatter megjegyzést) is elhelyez a cél üzleti rekordon, ha az létezik (pl. a frissítendő szállítói számla); létrehozásnál, ahol még nincs id, az ügynök-feladatra esik vissza. A Jóváhagyás és Mégse továbbra is a AI ‣ Írási javaslatok menüben van; a tevékenység csak systray emlékeztető, hogy a felügyelő a számlán vagy partneren landoljon, ne csak az absztrakt javaslatlistán. Az Írási javaslatok űrlapon a Rekord megnyitása ugyanezt a ugrást adja. A tevékenység a javaslat alkalmazásakor, visszavonásakor vagy lejáratakor lezárul.

Javaslat

A hard-deny padló minden ai.* platformmodellen blokkolja a nyers AI-eszközöket. Az ügynökök ezért nem „kezelhetik” eszközökkel a saját jóváhagyási sorukat vagy az AI konfigurációját — és ne is próbálkozzanak vele. A platform emlékeztetői és a skill-vezérelt ellenőrző tevékenységek az üzleti dokumentumokon kontrollált útvonalakon mennek; utasítsa az ügynököket, hogy ne találjanak ki AI-konfigurációs eszközhívásokat, különben elutasításokat és figyelmeztetéseket gyűjtenek.

Egy futás nyilvántartási sora csak akkor válik láthatóvá a többi felhasználó számára, ha a kísérlet befejeződött, vagy jóváhagyásra várakozik: a sort a kiszolgálófolyamat a saját tranzakciójában írja meg és zárja le, így semmi nem véglegesül, amíg az ügynök még dolgozik. A futások listája ezért az elvégzett munkát mutatja, nem élő képet arról, ami éppen fut.

A sikertelen futások a futás űrlapján Meghiúsulás típusa értéket kapnak, amely megmondja, milyen jellegű volt a hiba — a figyelemre méltó értékeket lásd: Monitoring.

Futás leállítása¶

Nyissa meg a futást, és használja a Megszakítás kérése gombot. A gomb addig látható, amíg a futás Folyamatban vagy Jóváhagyásra vár állapotban van, és csak az ügynök felügyelője vagy egy AI-adminisztrátor kérheti.

Fontos

Ez a gomb a fenti nyilvántartási viselkedés miatt nem általános „állítsd le most az ügynököt” eszköz: a normálisan futó futásnak még nincs sora, így nincs mit megnyitni. A gyakorlatban a Jóváhagyásra vár állapotban várakozó futáson használja, vagy olyanon, amely egy korábbi kiszolgálóhiba miatt maradt Folyamatban állapotban. A nem kívánt munkát inkább előre állítsa le: tartsa a feladat Határidő (másodperc) értékét annyira rövidre, hogy a futás magától véget érjen, és vegye ki a feladaton az Aktív jelölést, hogy ne induljon el újra.

A Jóváhagyásra vár állapotban várakozó futás megszakítása visszavonja a nyitott írási javaslatait, majd lezárja a futást: Kész állapottal, ha a futás egyik javaslatát már alkalmazták, egyébként Sikertelen állapottal és waiting_approval_empty Meghiúsulás típusa értékkel, mivel az általa javasoltak közül semmit nem hagytak jóvá.

Egy valóban még futó futás megszakítása együttműködő, soha nem azonnali. A rendszer a kérést minden szolgáltatói kör elején, majd minden eszközhívás előtt újra beolvassa, így az csak a már folyamatban lévő oda-vissza fordulat befejezése után lép érvénybe — a gyári alapértelmezésekkel számoljon körülbelül két percet, és soha nem egy szolgáltatói hívás közepén érvényesül. Az ilyen futás ezután Sikertelen állapottal és cancelled Meghiúsulás típusa értékkel zárul; nincs külön Megszakítva állapot. A már végrehajtott lépések a Lépések fülön maradnak, a futás válasza a megszakítást rögzíti, nem egy részleges feleletet, a már megnyitott írási javaslatait pedig vele együtt megszakítja a rendszer, így semmi nem marad jóváhagyhatóként. A megszakítás semleges a feladat automatikus deaktiválása szempontjából: nem számít hibának, de a meglévő sorozatot sem törli.

Megjegyzés

Ha már nem maradt kiszolgálófolyamat, amely meghallja a kérést, a gomb megerősítés helyett a Nincs megszakítható futás üzenetet adja. Semmi nem hibás — a futás nagy valószínűséggel már befejeződött, vagy a kiszolgálófolyamata megszakadt —, de a kérést egyetlen kiszolgálófolyamat sem fogja látni, és a futás emiatt nem áll le. Töltse be újra a rekordot, hogy lássa, valójában hol áll; a megszakadt kiszolgálófolyamatú futást az alább leírt, elakadt futásokat begyűjtő művelet zárja le.

Megszakadt kiszolgálófolyamatú futások¶

Ha a futást kezelő kiszolgálófolyamat leáll (újraindítás, memóriahiány, kilövés), nem marad senki, aki befejezze a futást. Az AI: elakadt ügynökfutások begyűjtése ütemezett művelet 15 percenként lefut, és lezárja ezeket: a futás Sikertelen állapotban rögzül, a Meghiúsulás típusa reaped_stuck lesz, a feladatra megjegyzés kerül, a rá váró írási javaslatok pedig lejárttá válnak, így egy halott futás nevében semmit nem lehet jóváhagyni. Ha az összeomlás a naplósort is magával vitte, a háttértakarító feladat újraépíti azt abból a rekordból, amelyet az indítás hátrahagyott — feltéve, hogy ez a rekord megíródott; egy olyan korai leállítás, amely még ezt is megelőzi, semmit nem hagy, amiből újra lehetne építeni.

Ne várja ezt a lezárást 15 percen belül. A futásnak túl kell lépnie a saját időkorlátján és egy türelmi időn (alapértelmezés szerint 10 percen — lásd: Konfiguráció), mielőtt egy lefutás hozzáér, a lefutások pedig 15 perces távolságra vannak egymástól, így a legrosszabb eset körülbelül fél óra. Egy lefutás legfeljebb 200 futást zár le, a legrégebbiekkel kezdve; egy újraindítási vihar után felgyűlt nagy hátralék a következő lefutások során ürül ki.

Ugyanez az ütemezett művelet felszabadítja azokat a Jóváhagyásra vár állapotban várakozó futásokat is, amelyeknek már nincs nyitott javaslata — például amikor az utolsó javaslat lejárt, miközben a felügyelő még megerősítette volna —, így az ilyen futás nem marad ott egy tevékenység-emlékeztetővel egy már nem létező javaslathoz.

Javaslat

Minden indítási kísérlet kap egy Indítási token értéket, amely a futás űrlapján látható. Ez a kulcs kapcsolja össze a futást azzal a rövid életű rekorddal, amely a futás indulásakor jött létre, és amelyet mind a begyűjtő művelet, mind a Megszakítás kérése keres — így ez az az érték is, amelyre hivatkozni kell, ha egy futást a kiszolgálónaplóval vet össze.

Utasítás ellenőrzése futás előtt¶

Az ütemezett és a Futtatás most futások közvetlenül a feladat állandó utasítását hajtják végre. Jelölje be a feladaton a Triázs indításkor beállítást, hogy lefusson ugyanaz az első fázisú ellenőrzés, amelyet a csevegésből megszólított ügynök is kap. Az ellenőrzés csak szűkíteni tudja azt, amit a feladat már megad — soha nem bővít.

Bekapcsolás előtt vegye figyelembe:

futásonként egy extra modellhívásba kerül (idő és tokenek), és az ütemező körülbelül 30 másodpercet tart fenn a saját ciklusidő-költségvetéséből erre a hívásra. Ezért az a feladat, amelynek a Határidő (másodperc) értéke már közel van a kiszolgálófolyamat időkorlátjához, elindítás helyett kimaradhat;
az ellenőrzésnek saját, rövid, 15 másodperces határideje van, és hiba esetén elutasít (fail-closed): a lassú, elérhetetlen vagy a sémától eltérően válaszoló triázsmodell elutasításnak számít;
az elutasítás azt jelenti, hogy az ügynök el sem indul. A futás Sikertelen állapottal és triage_denied Meghiúsulás típusa értékkel rögzül, a feladatra megjegyzés kerül, a felügyelő számára pedig Teendő tevékenység jön létre — így egyetlen elutasítás sem csendes;
az elutasítások beleszámítanak a feladat automatikus deaktiválásába. A rendszer archiválja a feladatot, ha öt egymást követő futás meghiúsult, és a sorozat hét napnál régebbi, a felügyelőt pedig értesíti. Mivel a triázshiba elutasításnak számít, egy hosszú szolgáltatókimaradás olyan feladatot is archiválhat, amely soha nem volt hibásan beállítva; ezért a beállítás feladatonként külön adható meg, és alapértelmezés szerint ki van kapcsolva;
az ellenőrzés döntése a futáson a Pillanatkép fülön, a Triázs döntése mezőben rögzül, és üres minden olyan feladat futásán, amelynél ezt nem kapcsolták be. Ez telemetria, nem határ: a benne leírt szűkítés már véglegesült a futás Engedélyezett képességek értékében, és a hozzáférési kapu ezt olvassa.

Az első fázisú triázs — mind a bejövő megszólítás, mind ez az indítás előtti ellenőrzés — globális kikapcsolója az ai.triage_enabled rendszerparaméter a Beállítások ‣ Technikai ‣ Paraméterek ‣ Rendszerparaméterek menüpont alatt (amihez fejlesztői mód kell).

AI Ops projekt szakaszok¶

A modul egy AI projektkategóriát, egy AI ügynök projektsablont és egy megosztott szakaszcsomagot szállít:

Inbox → Review → Ready → Doing → Waiting → Kész / Visszavont

Javasolt felhasználás:

az automatizált ellenőrzési megállapítások Inbox-ben landolnak megbízott nélkül;
a vezetők finomítanak a Review alatt;
csak Ready-ből rendelje hozzá az ügynök felhasználót;
Waiting emberi hozzájáruláshoz vagy jóváhagyáshoz;
soha ne alkalmazza automatikusan a készségeket/irányelveket egy audit során ember nélkül.

Support asszisztens csomag¶

Inaktív Support asszisztens ügynököt szállítunk kérdezés+olvasási képességekkel és csatornaszabályokkal, amelyek közönségei üresek, amíg be nem állítja őket. Aktiválás:

Szűk belső felhasználó létrehozása (a helpdesk/projekt szükség szerint olvasható).
Kapcsolás az ügynökhöz; felügyelő beállítása.
Csatorna közönségeinek kitöltése (csoportok/felhasználók, akik DM-et küldhetnek / hozzárendelhetnek / @megemlíthetnek).
Beállítás Aktív.
Az AI-hozzáférési szabályok hangolása jegymodellekhez.

Identitás-korlátok (összefoglaló)¶

A link időpontjában a modul elutasítja a következő ügynökfelhasználókat:

szuperfelhasználó (uid 1);
megosztás/portál;
Beállítások / rendszergazda;
AI rendszergazda;
API kulcs lenyomva tartásával (nem interaktív bejelentkezési kockázat).

Ezek az ellenőrzések az ügyintézői űrlapon pont-időben történnek – ne „frissítse” a felhasználót később a Felhasználók menüből.

Következő: gyakorlati receptek itt: Ügynök-receptek.