Háttérben futó kódoló ügynökök: PR-ek, sorok és review

A kódoló ügynök régen olyasmi volt, amit néztél. Beírtál egy kérést, jóváhagytál minden parancsot, és vártál a diffre. A mai felhős ügynökök megváltoztatták ezt: egy feladatot átadsz egy sornak, bezárod a laptopot, és egy branchre vagy pull requestre térsz vissza. Az OpenAI Codex Cloud, a GitHub Copilot Cloud Agent, a Claude Code felhős sessionjei és a Google Jules ugyanezt a mintát követik, eltérő limitekkel és eltérő elképzeléssel arról, mihez nyúlhat az ügynök.

Ez kényelmi funkciónak hangzik. Valójában a munkaegység változik meg. Az aszinkron ügynök olyan artefaktumokat termel, amiket másoknak review-zniuk kell, és a repó workflow minden gyenge pontja gépi sebességgel láthatóvá válik: homályos issue-k, lassú CI, hiányzó branch protection, olvasatlan backlog. A DORA 2025-ös felmérése szerint a technológiai szakemberek 90%-a használ AI-t munkában, miközben 30% kevés vagy semmilyen bizalmat nem érez az AI-generált kód iránt; ugyanez a jelentés a magasabb adoptációt nagyobb áteresztőképességgel és nagyobb instabilitással is összeköti. Ez a cikk a workflow-ról szól: sor, sandbox, CI-kapu, emberi review, költségmérés és hibamódok.

Miért változik meg az aszinkron munkával a munkaegység

A szinkron ügynök rád vár, így az áteresztőképessége a figyelmed. Az aszinkron ügynök felügyelet nélkül fut, budgetet fogyaszt, és olyan munkát ad, ami ugyanabba a review-pipeline-ba kerül, mint egy kolléga branch-e. A csere párhuzamos próbálkozások verifikációs munkáért — és csak a géppel ellenőrizhető „kész” definíciójú feladatok tartoznak ebbe a cserébe.

Egy aszinkron PR-pipeline felépítése

A brandinget lehúzva a pipeline mindenhol ugyanaz. A feladat bekerül egy sorba; egy worker környezetet készít; az ügynök szerkeszt és parancsokat futtat; az eredmény branch és pull request lesz; fut a CI; egy ember review-z; a merge vagy megtörténik, vagy visszaküldi a feladatot. Az érdekes különbségek az egyes szakaszok limitjeiben vannak, nem a diagramban.

Két tulajdonság különbözteti meg a feladatot a chattől: az ügynöknek kell egy ellenőrizhető kész-definíció, és a környezetnek elég reprodukálhatónak kell lennie ahhoz, hogy a zöld futás jelentsen valamit. Az az ügynök, amelyik nem tudja futtatni a tesztjeidet, tippel, és a tippelésekkel teli PR rosszabb, mint a semmilyen PR. A hurok mechanikáját az agent loop magyarázata tárgyalja.

Ezek alapértékek, nem plafonok. A saját runner, az egyedi környezetek és a nagyobb runnerok elmozdítanak belőlük. Ami nem mozdul, az a forma: sor, szűk végrehajtási környezet, branch, kapu és reviewer.

A sor maga a termék

Az aszinkron ügynök nem tudja megkérdezni, mire gondoltál — vagy igen, de a válasz órák múlva érkezik. Ezért a sorba állított feladat a specifikáció: egy megfigyelhető cél, az azt bizonyító parancs, az engedélyezett útvonalak és a nem-célok. Ha az issue-sablon nem tudja ezt kifejezni, a feladat nem kész az ügynökre.

A duplikátumok a sorprobléma legvilágosabb jelei. 600 elutasított ügynök-PR kézzel kódolt mintájában 142 — 23% — azért záródott be, mert a munka már máshol létezett. Az ügynök nem rossz kódot írt, hanem olyat, amire senkinek nem volt szüksége. Sorba állítás előtt deduplikálj, ne a PR megnyitása után.

type AgentTask = {
  id: string;                 // dedupe key: repo + issue + base commit
  repo: string;
  base: string;
  goal: string;               // one sentence, testable
  acceptance: string[];       // observable outcomes
  testCommand: string;        // the agent must run this
  allowedPaths: string[];     // everything else is out of scope
  maxMinutes: number;
  maxCiRetries: number;
};

A borítékot a feladattal együtt tárold, és az id legyen a dedupe-kulcs: repó, issue és bázis-commit. Ha a bázisbranch elmozdul, ellene futtasd újra, ne nyiss második PR-t. A WIP-limit nélküli sor PR-generátor; én reviewerenként korlátozom a feladatokat, nem ügynökönként.

Sandboxok: mihez nyúlhat az ügynök

Három határ dönti el a blast radius-t: mit írhat az ügynök, mit ér el a hálózaton, és milyen credentialöket költhet. A hosztolt termékek másképp döntenek, és a különbségek fontosabbak, mint a modell neve a feladatborítékban.

A GitHub Copilot Cloud Agent ephemeral GitHub Actions környezetben fut, alapból bekapcsolt firewall-lal, csak egyetlen branchre pusholhat, és a git push parancsot nem tudja közvetlenül futtatni. A Codex Cloud a setup-szkripteket internet-hozzáféréssel futtatja, majd az ügynök internetét alapból kikapcsolja; a secretek csak setup közben érhetők el, és az ügynökfázis előtt törlődnek. A Claude Code Cloud a git credentialöket és signing keyeket a sandboxon kívül tartja, és proxyn keresztül csatolja.

A hiba, hogy a sandboxot tekintjük a teljes biztonsági modellnek. Az egy réteg. Az a branch, amelyen a CI repository-secretekkel fut, végrehajtási út, és az az ügynök, amelyik szerkesztheti a .github/workflows fájlt, megváltoztathatja ezt az utat. A Copilot alapértelmezése tanulságos: a PR-jeiből induló workflow-k addig nem futnak, amíg egy írási jogú felhasználó jóvá nem hagyja őket. Ez külön kontroll a firewall mellett, és mindkettő kell.

Hosszú futások, timeoutok és újraindíthatóság

Az aszinkron nem végtelen. A Copilot sessionönként 59 percre korlátoz, és nem engedi meghosszabbítani. A Claude Code csak akkor cache-eli a setup-szkriptet, ha körülbelül öt percen belül végez, az idle felhős sessionök pedig visszakerülnek. A Codex a konténer állapotát legfeljebb 12 óráig cache-eli — ez teljesítményjellemző, nem ígéret arra, hogy egy feladat ennyi ideig futhat.

Megszakításra tervezz: commitolj checkpointokat a branchre, írd a tervet fájlba a repóban, és a következő futást az utolsó zöld commitról indítsd. Az a feladat, amelyik nem él túl egy timeoutot, félkész PR-t és egy második takarítófeladatot hagy maga után.

// Lease longer than the longest allowed run; heartbeat while the agent works.
const lease = await queue.claim({ visibilityTimeout: 90 * 60 });
try {
  const run = await sandbox.start({
    task: lease.task,
    network: "allowlist",
  });
  const result = await run.wait({ timeoutMs: lease.task.maxMinutes * 60_000 });
  if (result.exitCode !== 0) throw new Error(result.summary);
  await git.pushBranch(result.branch);
  await github.openDraftPr({ branch: result.branch, task: lease.task });
  await queue.ack(lease.id);
} catch (error) {
  await queue.nack(lease.id, { reason: String(error) });
}

A sor szemantikája fontosabb, mint a termék: a maximális futásnál hosszabb visibility timeout, heartbeat, ack csak a PR után, és dead-letter út. A GitHub Actions, az SQS vagy a Temporal mind kifejezi ezt; a lease nélküli cron job nem.

A CI az első reviewer

A branch protection kapuvá teszi a pull requestet. A required checkek lehetnek szigorúak (a branchnek naprakésznek kell lennie) vagy lazák (most mergelj, kockáztasd a törött bázist). A merge queue a PR-t a legfrissebb bázis és az előtte álló PR-ek ellen teszteli, így a zöld valóban arra vonatkozik, ami mergelődni fog.

name: ci
on:
  pull_request:
  merge_group:

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: npm }
      - run: npm ci
      - run: npm test -- --run

Az ügynök-PR idegen hozzájárulás megbízhatónak tűnő szerzőnévvel. Ezért a workflow-jóváhagyás, a minimális permissions és a branch protection a design része, nem utólagos takarítás. Ugyanez az elv áll a coding agentek harness engineeringjében: a guide-ok megmondják az ügynöknek, milyen a jó, a szenzorok megmondják neki — és neked —, amikor elhibázta.

Egy piros pipeline nem csak az újrafuttatásba kerül. A 33 596 PR-t vizsgáló tanulmányban minden további elbukott CI-check körülbelül 15%-kal alacsonyabb merge-eséllyel járt. A bukó check elutasítási jel, ami halmozódik. Tedd gyorssá és determinisztikussá a suite-ot, mielőtt ügynököket skálázol; különben retry-ket vásárolsz, nem áteresztőképességet.

Az emberi review a szűk keresztmetszet

Az empirikus kép érdekesebb az anekdotánál. Ehsani és munkatársai öt kódoló ügynöktől származó 33 596 pull requestet elemeztek: 71,48% mergelődött. 600 elutasított PR kézzel kódolt mintájában a reviewer-magára hagyás volt a legnagyobb kategória 38%-kal, majd a duplikátumok 23%-kal és a CI- vagy teszthibák 17%-kal. Csak 2% számított ügynökszintű problémának. Peralta és munkatársai 11 048 zárt ügynök-PR-t vizsgáltak, és azt találták, hogy az elutasításoknak csak 35,7%-a volt egyértelmű ügynökhiba; 31,2% workflow-korlát, 33,1% pedig nem mutatott megfigyelhető indokot.

A következtetés nem az, hogy az ügynökök jók vagy rosszak. A merge-eredmény a workflow-t méri legalább annyira, mint a modellt. A duplikált PR és az elhagyott PR sorehiba. A piros CI gyakran környezethiba. Ha csak az ügynök kódját instrumentálod, mindhármat modellminőségként olvasod.

• Nyisd a pull requestet draftként, a feladattal, a tesztparanccsal és a változás rövid összefoglalójával. A reviewernek ne a diffből kelljen rekonstruálnia a kérést.
• Csak zöld required checkek után lehessen a PR-t ready állapotba tenni. A draft, amelyik zölddé válik, jel; a draft, amelyik azért zöld, mert a CI soha nem futott, csapda.
• A teszteket külön változásként review-zni. Kérdezd meg, hogy a teszt a produkciós változás nélkül elbukna-e, és hogy gyengült-e valamelyik assertion.
• Egy reviewer legyen felelős feladatonként, korlátozd a draftjait, és soha ne a kérő legyen az egyetlen approver. A Copilot az utolsó szabályt kikényszeríti; branch protectionnel minden más ügynökre is kikényszeríthető.

Ez ugyanaz a kapacitásprobléma, amit az AI code review szűk keresztmetszetéről szóló cikk leír, és ugyanaz a designkérdés, mint a human in the loop AI-ügynököknél: hol kell egy embernek ránéznie, és miért felel? Egy ügynök-PR-nél ez a diff, a tesztek és a rollout-kockázat — nem az ügynök összefoglalója.

Feladatonkénti költségszabályozás, nem tokenenként

Egy aszinkron ügynöknek négy mérője van: modelltokenek, CI-percek, sandbox-idő és emberi review. Az első három látszik a számlán. A negyedik dönti el, hogy a workflow megéri-e egyáltalán.

A szolgáltatók másképp mérnek. A GitHub 2026. június 1-jén a Copilotot használatalapú számlázásra állította: a modellhasználat AI creditben, az ügynök infrastruktúrája Actions-percekben számlázódik. A Codex Cloud feladatai a helyi üzenetekkel közös csomagkeretet használják, és az OpenAI egy tipikus GPT-5.6 Sol feladatot 2–15 creditre becsül. A Claude Code felhős sessionjei a csomag limitjébe számítanak, külön VM-díj nélkül. A Jules feladatszámot és párhuzamosságot ad el: 15/3 a belépőn, 100/15 Pro-n, 300/60 Ultra-n.

A mergelt pull requestre jutó költséget mérd, ne a sessionre jutót: tokenek plusz CI plusz sandbox plusz review-percek, osztva a mergelt PR-ekkel. Az olcsó feladat, ami soha nem mergelődik, drága; a drága feladat, ami egy hét munkát spórol meg, olcsó. A párhuzamosságot korlátozd, mielőtt a promptokat optimalizálod.

Hibamódok és a hozzájuk tartozó védőkorlát

A hibamódok elég kiszámíthatók ahhoz, hogy tervezz ellenük. A százalékok az elutasított ügynök-PR-ek kézzel kódolt mintájából származnak, tehát azt írják le, hogyan néz ki az elutasítás, nem az összes feladatra vonatkozó alaprátát.

Egy további hibamódot könnyű kihagyni, mert sikernek látszik: az ügynök úgy javítja a CI-hibát, hogy megváltoztatja a tesztet. A zöld pipeline csak akkor bizonyíték, ha a teszt megtalálta volna a bugot. A teszt-diffet a produkciós diff előtt olvasd, és bugfixnél kérj egy bukó tesztet, ami reprodukálja az issue-t.

Bevezetés anélkül, hogy PR-ekbe fulladnánk

Olyan munkával kezdj, ahol a siker géppel ellenőrizhető és a blast radius kicsi. A 33k PR-t vizsgáló tanulmány a legmagasabb merge-arányt a dokumentációnál (84%), a CI-nál (79%) és a buildnél (74%) találta, a legalacsonyabbat a performance-nál (55%) és a bugfixeknél (64%). Ez a sorrend ésszerű bevezetési terv.

1. Válassz egy repót és két feladattípust: a dokumentáció és a tesztlefedettség a legbiztonságosabb kezdés.
2. Írd meg a feladatsablont céllal, elfogadási kritériumokkal, tesztparanccsal, engedélyezett útvonalakkal és nem-célokkal.
3. Kérj draft PR-t, zöld checkeket és egy emberi jóváhagyást a merge előtt. Először a branch protectiont kapcsold be.
4. Korlátozd a párhuzamos munkát reviewerenként és ügynökönként. A sort mérd, ne az ügynök tokenfogyasztását.
5. Négy hétig kövesd a merge-arányt, a review-időt, a CI-hibaarányt és a mergelt PR-re jutó költséget, mielőtt bővítesz.
6. Bugfixet csak akkor adj hozzá, ha a tesztkészlet elég megbízható ahhoz, hogy a zöld futás jelentsen valamit.

Az aszinkron ügynök szorzó azon a workflow-n, amelybe kerül. Gyors CI-vel, világos felelősséggel és kis PR-ekkel eltünteti a rutinmunkát. Flaky tesztekkel és review-kapacitás nélkül backlogot gyárt, jobb commit üzenetekkel.

Források

1. GitHub Docs: About GitHub Copilot cloud agent
2. GitHub Docs: Risks and mitigations for Copilot cloud agent
3. OpenAI Developers: Codex cloud environments
4. Anthropic: Use Claude Code in the cloud
5. Google Jules: Limits and plans
6. Google Jules: Getting started
7. GitHub Docs: About protected branches
8. GitHub Docs: Models and pricing for GitHub Copilot
9. OpenAI Developers: Codex pricing
10. Ehsani et al.: Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub (MSR 2026, arXiv 2601.15195)
11. Peralta et al.: Why Are Agentic Pull Requests Merged or Rejected? An Empirical Study (MSR 2026, arXiv 2605.22534)
12. DORA: State of AI-assisted Software Development 2025