Irányított agentikus workflow. Így használunk AI-ügynököket

Egy AI-ügynök képes elolvasni a repozitóriumot, tervet készíteni, kódot módosítani és teszteket futtatni. Ettől még nem jön létre megbízható fejlesztési folyamat. A produkciós csapatnak tudnia kell, ki hagyta jóvá a célt, milyen jogosultságot kapott az ügynök, mit ellenőrzött, és ki fogadta el a módosítást.

A Rise ezért review-gated Shadow modellt használ. Az ügynök elkülönített worktree-ben készíti elő a változtatást, de a V1 indítása kézi. Ember hagyja jóvá a tervet, a kivételt, a merge-et és a telepítést. A rendszer az ismételhető munkát és a bizonyítékok gyűjtését automatizálja.

Ez a modell olyan csapatoknak való, amelyek gyorsabb megvalósítást szeretnének, de nem mondanak le a hatókör, a biztonság és a kiadás ellenőrzéséről. Nem minden kísérletnél ez a leggyorsabb út. Kis, visszafordítható feladatnál egy ad hoc kérés olcsóbb lehet.

1. Ad hoc prompting

   Gyors kezdés kis, visszafordítható feladathoz. A kontextus, a jogosultságok és a bizonyítékok minden alkalommal a kezelőtől függenek.

2. Review-gated Shadow

   Olyan produkciós csapatnak való, amely mérhető kapukat, korlátozott javítást és ember által vezérelt merge-et igényel.

3. Autonóm ügynökgyár

   Erős izolációt, megfigyelhetőséget, vészleállítást és a nagyobb hatású automatikus módosításokba vetett bizalmat igényel.

Mit jelent a review-gated Shadow

A Shadow nem azt jelenti, hogy az ügynök csak megfigyeli a fejlesztőt. Valós fejlesztési folyamatban dolgozik, de nem kap jogosultságot a közös alap vagy a produkció módosítására.

A munka WorkOrderrel indul. Ez rögzíti a célt, az engedélyezett fájlhatókört, a kockázatot, a kötelező ellenőrzést és a tiltott műveleteket. Az ügynök ebből készít tervet. A megvalósítás csak emberi jóváhagyás után indulhat.

Ezután egy writer saját worktree-t kap. Az elkülönítés csökkenti annak esélyét, hogy két munkamenet felülírja egymás fájljait vagy érvénytelenítse a teszteredményeket. Ugyanezt az elvet követik a Codex és a Claude Code worktree ajánlásai.

1. Jóváhagyott WorkOrder

   A hatókör, a kockázat, a jogosultságok és a szükséges bizonyítékok előre ismertek.

2. Terv és emberi jóváhagyás

   Az ügynök előbb leírja a megközelítést, az érintett határokat és az ellenőrzést.

3. Elkülönített megvalósítás

   Egy writer elkülönített worktree-ben dolgozik, korlátozott számú javítási kísérlettel.

4. Pontos ellenőrzések

   Determinisztikus parancsok ellenőrzik az elfogadott hatókört és megismételhető eredményt adnak.

5. Független review és átadás

   Friss kontextus vizsgálja felül a módosítást. Az evidence manifest ahhoz kerül, aki a merge-ről és a telepítésről dönt.

A sikertelen ellenőrzés visszavisz a megvalósításhoz. A review észrevétele visszavisz a tervezéshez.

Az ellenőrzés pontos projektparancs, nem általános kérés a tesztelésre. Sikertelen eredmény után a writer csak előre meghatározott számú javítást végezhet. Ezután a folyamat megáll és új döntésre vár.

A kész módosítást friss kontextussal dolgozó reviewer olvassa el. Nem javítja csendben a writer munkáját. Az észrevételt visszaküldi a tervezéshez, vagy indokolt állásfoglalást ad. Az evidence manifest rögzíti a hatókört, a parancsokat, az eredményeket, az ismert kockázatokat és a nyitott kérdéseket.

Az utolsó kapu emberi. Az ügynök nem merge-el és nem telepít. A GitHub rulesets technikailag megkövetelheti a pull requestet, a review-t és a sikeres status checket. A kockázat elfogadásáért továbbra is a csapat felel.

Mit automatizálunk és miről dönt ember

Az automatizálás ott hasznos, ahol ugyanaz a bemenet ugyanahhoz az ellenőrizhető döntéshez vezet. Emberi kapu kell az üzleti kontextus, a kivétel vagy az üzemeltetési következmény megítéléséhez.

1. Automatizált lépések

   Szerződés-ellenőrzés, dry-run, állapotszabályok, hooks, CI-ellenőrzések és a bizonyítékok összeállítása.

2. Emberi döntések

   Tervjóváhagyás, hatóköri kivételek, kockázatelfogadás, merge, kiadás és telepítés.

A modellünk a következő részeket automatizálja.

• A szerződés-ellenőrzés vizsgálja a WorkOrder és a workflow kötelező mezőit és engedélyezett parancsait.
• A dry-run inicializálás megmutatja a tervezett fájlokat és változtatásokat a célprojekt írása nélkül.
• A YouTrack állapot- és jogosultsági szabályai őrzik az engedélyezett átmeneteket és szerepköröket. A YouTrack workflows ilyen szabályokra készült. A YouTrack MCP irányított eszközöket ad az ügynöknek.
• A hooks megállítja a tiltott parancsot vagy a meghatározott pillanatban ellenőrzést indít. A Claude Code hooks jó példa a modell körüli determinisztikus rétegre.
• A CI tiszta környezetben ismétli meg a megbízható ellenőrzést.
• Az evidence manifest egyetlen átadásba rendezi a bemenetet, az eredményt és a review-t.

Ember hagyja jóvá a célt, a hatókör változását, a biztonsági kivételt, a kockázat elfogadását, a merge-et, a kiadást és a telepítést. Ez a határ megfelel az OWASP ajánlásainak is. Ide tartozik a minimális jogosultság, az érzékeny művelet emberi jóváhagyása, a validáció, az auditnyom és az erőforráskorlát.

Hét workflow eltérő szabályt igényel

Egyetlen sablon egyszerűnek tűnik, de egy hotfix célja nem azonos egy kutatási spike céljával. 2026. július 24-én szerződésszinten hét workflow-típus validált. Az élő integrációt és a jogosultságot minden projektben külön ellenőrizzük.

A limit nem a fejlesztő gondolkodását korlátozza. Azt akadályozza meg, hogy az ügynök új döntés nélkül ugyanazt a stratégiát ismételje.

Miért kevés önmagában a prompting vagy a CI

Az ad hoc prompting kis és könnyen visszafordítható feladathoz megfelelő. Gyenge pontja a folyamatmemória. A kezelő minden munkamenetben újra összeállítja a hatókört, a jogosultságot és az ellenőrzést.

A CI más réteget vizsgál. Elutasítja a teszten megbukó módosítást, de általában nem tudja, hogy az ügynök szerkeszthette-e az adott modult, jóváhagyták-e a tervet, vagy gazdaságos-e még egy javítási kísérlet.

A review-gated Shadow szerződést tesz a megvalósítás elé és bizonyítékot utána. Ez jobb egy produkciós csapatnak, amelynek később meg kell indokolnia a döntést. Az ára a WorkOrder előkészítése és az emberi kapuk ideje.

Egy teljesen autonóm gyár várakozás nélkül több független feladatot kezelhet. Erősebb izolációt, megfigyelhetőséget, vészleállítást, identitáskezelést és az automatikus merge-be vagy telepítésbe vetett bizalmat igényel. Kis csapatnál ez önálló rendszer, nem promptbeállítás.

Értékmérés reklámszázalék nélkül

Nem adunk meg általános megtakarítási arányt. Az eredmény függ a repozitórium, a tesztek, a feladatleírás és a reviewer minőségétől. A bevezetés előtti és utáni elfogadott módosításokat érdemes összehasonlítani.

Mérhető a jóváhagyott feladattól az elfogadott módosításig eltelt idő, a tiszta review-idő, a javítások száma, a kiadás utáni regresszió, a blokkolt jogosulatlan művelet és az elfogadott módosítás költsége. Az elutasított vagy használhatatlan javaslat költsége is a teljes eredmény része.

Az első hetek alapértéket adnak. Csak ezután érdemes limitet módosítani, új workflow-t felvenni vagy további kaput automatizálni.

Hol érdemes kezdeni

Kezdje egy ismétlődő változtatástípussal, egy repozitóriummal és kézi indítással. Határozza meg a WorkOrdert, az engedélyezett parancsokat, a jóváhagyás felelősét és az átadáshoz szükséges bizonyítékokat. Először dry-run készüljön.

Korábbi cikkünk az ember szerepéről az AI-fejlesztésben megmutatja, miért marad szükség szakmai ítéletre. Az AI-ügynök governance checklist az adatokkal, eszközökkel és vészleállítással bővíti a témát.

Ha még a megfelelő folyamatot keresi, nézze meg az AI automatizálás szolgáltatást. Az irányított agentikus workflow akkor hasznos, ha a csapat meg tudja nevezni a felelőst, a tiltott műveleteket és a kész módosítás elfogadási útját.