NAME
codex-multi-agent-workflows — Codex és többügynök munkafolyamat: dolgozzon az ügynökökkel anélkül, hogy elveszítené az irányítást
SYNOPSIS
cat codex-multi-agent-workflows.md
DESCRIPTION
Amikor egy kódoló ágens először javít ki egy hibát, a reakció szinte mindig ugyanaz: lelkesedés és gyanakvás keveréke. Szép, persze. De aztán ránézel a diff-re, és megkérdezed magadtól: "Oké, de pontosan mit nyúlt? Megbízhatok benne? Holnap ugyanígy csinálja?".
Szerintem itt kezdődik az érdekes rész. Nem akkor, amikor az ügynök ír egy függvényt, hanem akkor, amikor eléggé képessé válik arra, hogy teljes munkát vállaljon: olvassa el a tárat, hozzon létre egy javítást, futtasson teszteket, nyissa meg a PR-t, és térjen vissza egy felülvizsgálati megjegyzés után. A Codex pontosan ebbe az irányba halad: háttérmunka, különálló munkafák, integrált böngésző, automatizálás, bővítmények, memória és egyértelműbb engedélyek ellenőrzése.
A lényeg, hogy ne képzeljünk el egy olyan jövőt, ahol már senki sem olvas kódot. Szörnyű jövő lenne, ráadásul elég naiv is. A lényeg az, hogy kitaláljuk, hogyan dolgozhatunk olyan ügynökökkel, akik sokat tehetnek anélkül, hogy mindent megengednének nekik.
A szokásváltás
A hagyományos automatikus kiegészítéssel mindig Ön volt a kormánynál. Az AI javasolt egy sort, te döntöttél. Egy ügynökkel viszont megváltozik a kapcsolat: adsz neki egy célt, és több lépésen megy keresztül egyedül.
Ez erős, de áthelyezi a problémát. A kérdés már nem csak az, hogy "tud-e programozni a modell?". A kérdés a következő:
- Elég kicsi mozgásteret adtam neki?
- tudod, hogyan kell ellenőrizni az eredményt?
- Elszigetelt környezetben dolgozom?
- A végső áttekintés továbbra is humánus és körültekintő?
Egy egészséges munkafolyamat inkább így néz ki, mint egy varázspálca:
Kevésbé hangzik romantikusan, mint "az ügynök mindent épít", de sokkal jobban működik. Az emberekkel jól bánó csapatok is így dolgoznak: világos feladatok, gyors visszajelzés, kifejezett elszámoltathatóság.
A jó felszólítás szinte jó jegy
A legveszélyesebb a homályos, de magabiztos felszólítás: "javítsa ki a számlák oldalát", "javítsa az architektúrát", "tisztítsa ki az auth modult". Ezek olyan kérések, amelyek eredményesen hangzanak, és hatalmas különbségeket generálnak. De aztán azon kapod magad, hogy régészettel foglalkozol.
Egy segítőkész felszólítás unalmasabb. Például: valósítsa meg a CSV-exportálást a számlák oldalon, tudva, hogy a tábla a app/(dashboard)/invoices/page.tsx-ban, a lekérdezések a src/server/invoices.ts-ban vannak, és már van hasonló minta a app/(dashboard)/reports-ban.
Ezután adjunk hozzá egyértelmű megkötéseket: ne változtassuk meg az adatbázissémát, ne adjunk hozzá függőséget, ha elég egy kis segédprogram, tartsuk meg a meglévő UI stílust. És zárja le az ellenőrzést: npm test -- invoices és npm run build.
Ez a fajta összefoglaló nem arra szolgál, hogy "jobban elmagyarázza az MI-nek". Ez mindenekelőtt azt szolgálja, hogy egyértelműbbé tegye, mit delegál. Ha nem tudja konkrétan leírni, lehet, hogy a feladat még nem áll készen egy ügynök számára.
Három munka, amelyeket szívesen delegálok
Az első az ismétlődő, de ellenőrizhető munka: tesztek hozzáadása, hívások áttelepítése egy új belső API-ra, importálás frissítése, elavult összetevők cseréje, TypeScript hibák javítása. Itt az ügynök órákat takaríthat meg, és a kockázat ellenőrizhető.
A második a feltáró munka: „keresse meg, hol számítják ki ezt az összeget”, „magyarázza meg, miért törékeny ez a teszt”, „reprodukálja a hibát, és mondja meg, mely fájlokat tűnik érintettnek”. Még akkor is hasznos felderítést végezhet, ha nem készít azonnal foltot.
A harmadik az ismétlődő karbantartási munkák: kisebb függőségi frissítések, régi funkciójelzők tisztítása, blokkolt PR-ok összefoglalása, elfelejtett TODO-k ellenőrzése. Nem elbűvölő, de pontosan az a fajta munka, ami felhalmozódik.
Három munka, amit embernek tartok
A termékekkel kapcsolatos döntések emberiek maradnak. Ha egy változás megváltoztatja a felhasználó fizetési módját, törli az adatokat, látja az árakat vagy megérti az engedélyt, akkor felelős személyt szeretnék.
A biztonsági határok is megérdemlik az emberi figyelmet: hitelesítés, szerepek, tokenek, érzékeny adatok naplózása, adatbázis-migráció. Egy ügynök segíthet a megvalósításban, de nem kell egyedüli döntéshozónak lennie.
Végül mindent embernek tartok, ami építészeti ízlést kíván. Egy ügynök javasolhat egy refaktort, de annak megértése, hogy valóban szükség van-e az absztrakcióra, vagy csak egy nem létező problémát csiszolunk, az továbbra is feladat marad.
Az áttekintés nem kötelező
Ha egy ügynök jó, a kísértés az, hogy bízunk a CI zöldjében. Ez érthető. Ekkor kezdődnek a problémák is.
Mindig legalább öt dolgot nézek meg:
- A javítás csak a kért feladatot oldja meg?
- Olyan fájlokhoz nyúlt, amelyeknek semmi közük hozzá?
- A tesztek új viselkedésre vonatkoznak, vagy csak a boldog véletlenre?
- A kód a helyi mintákat követi?
- A hibákat ugyanúgy kezelik, mint a projekt többi részében?
Ha valami nincs rendben, a visszajelzésnek konkrétnak kell lennie. A „javítani” lusta. Jobb: ez a segédprogram a parseMoney-t a src/lib/money.ts-ba duplikálja; használja újra ezt a funkciót, adjon hozzá egy tesztet az EUR esethez, és ne módosítsa a számlázási modul nyilvános API-ját.
Az ügynökök sokkal jobban reagálnak az apró, ellenőrizhető megjegyzésekre. Érdekes módon az emberek is így tesznek.
A védőkorlátok megérik az erőfeszítést
Ha egy ügynök tud fájlokat olvasni, kódot írni és parancsokat végrehajtani, akkor azt hatékony folyamatként kell kezelni. Nincs szükség paranoiára, higiéniára van szükség.
Használjon különálló munkafákat vagy ágakat. Így összehasonlíthatja a különbséget, eldobhatja a sikertelen kísérleteket, és nem keverheti össze az ügynök munkáját azzal, amit csinált.
Engedélyek korlátozása. Az olyan parancsok, mint a rg, git diff, npm test és npm run build, meglehetősen ingyenesek lehetnek. A telepítéseknek, az adatbázis-áttelepítéseknek, a titkokhoz való hozzáférésnek és a pusztító parancsoknak egyértelműnek kell maradniuk.
Csökkentse a hálózati hozzáférést, ha nincs rá szüksége. Számos feladathoz elegendő a hivatalos dokumentáció, a csomagnyilvántartás és a konkrét belső szolgáltatások. Kevesebb felület, kevesebb meglepetés.
A műveletek nyomon követése. Amikor egy javítás megérkezik a felülvizsgálatba, képesnek kell lennie a promptok, a végrehajtott parancsok, a sikeres tesztek és a módosított fájlok rekonstruálására. Nem azért, hogy bürokráciát teremtsünk, hanem azért, hogy megértsük, mi történt, ha valami elromlik.
Egy egyszerű módja annak, hogy elkezdj csapatként
Ha ügynököket vezetnék be egy kis csapatba, nagyobb forradalmak nélkül kezdenék.
Létrehoznék egy agent-ready címkét az egyértelmű hatókörű problémákhoz. Hozzáadnék egy sablont kontextussal, megszorításokkal és ellenőrző parancsokkal. Kis PR-t kérnék, ideális esetben pár száz sor alatt. Tesztelést vagy képernyőképeket kérnék a látható változásokhoz. És mindenekelőtt egy személyt tartanék felelősnek az összevonásért.
Két hét elteltével megnézném az adatokat: mely feladatok gyorsultak fel igazán, melyek voltak nehézkesek az áttekintések, melyek voltak zavaróak, a kódbázis mely részei túl törékenyek ahhoz, hogy delegálják.
Ez kevésbé látványos megközelítés, mint a "mától mindent az ügynökökkel csinálunk", de ez az, amivel megbánás nélkül eljuthatsz a harmadik hétig.
A legemberibb része
A vicces az, hogy minél autonómabbak lesznek az ügynökök, annál fontosabbá válnak ismét a klasszikus készségek: jó jegyet írni, apróbb vágásokat készíteni, teszteket készíteni, különbségeket olvasni, kompromisszumokat kommunikálni. Az ügynök felgyorsítja azokat, akik már tudják, hogyan kell jól dolgozni. A rosszul delegálók káoszát is felerősíti.
Tehát nem, nem látom a többügynökös munkafolyamatokat parancsikonnak a tervezés abbahagyására. Úgy tekintek rájuk, mint arra, hogy több energiát fordítsanak azokra a részekre, amelyek számítanak: eldönteni, mit építsünk, megbizonyosodni arról, hogy működik, a rendszer érthetően tartása.
Az ügynökök nagyszerű aszinkron kollégákká válhatnak. De egy aszinkron kollégának ahhoz, hogy hasznos legyen, kontextusra, határokra és áttekintésre van szüksége. Akárcsak mindenki más.
Hasznos források
METADATA
- date: 2026-05-24
- reading: 6 min
- author: Filippo Spinella
- tags: AI, Developer Tools, Productivity, Software Engineering