> Hogyan sorakoztatnak feladatokba az aszinkron kódoló ügynökök, hogyan futnak sandboxban, nyitnak draft PR-t és mennek át a CI-n. Limitek, költségek, review.
>
> Web page: https://balazscsorba.com/hu/blog/background-agents-async-pr-workflow · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/background-agents-async-pr-workflow.md) · [Deutsch](https://balazscsorba.com/de/blog/background-agents-async-pr-workflow.md)
> Author: Balázs Csorba · Published: 2026-10-17 · Keywords: background coding agent, async coding agent, cloud coding agent pull request, copilot coding agent limits, codex cloud tasks, claude code cloud sessions, jules coding agent limits, agent pull request review, coding agent sandbox, agent CI gating, cost per merged pull request

[Blog](https://balazscsorba.com/hu/blog)/MI-ágensek

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

Hogyan sorakoztatnak feladatokba az aszinkron kódoló ügynökök, hogyan futnak sandboxban, nyitnak draft PR-t és mennek át a CI-n. Limitek, költségek, review.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 17.·12 perc olvasás

-   Coding agents
-   Pull requests
-   CI
-   Code review
-   Automation

![Egy kártya a tálcán öt mezőre ágazik, a nyilak egy kapu mögötti laphoz vezetnek.](https://balazscsorba.com/images/blog/background-agents-async-pr-workflow/cover.webp?v=3ffd1f8c72)

## A lényeg röviden

-   Az aszinkron kódoló ügynök a szűk keresztmetszetet a kódírástól a feladat meghatározása, a CI futtatása és az eredmény review-ja felé tolja.
-   A sorba állított feladat a specifikáció: egy megfigyelhető cél, egy tesztparancs, engedélyezett útvonalak és kimondott nem-célok.
-   A sandbox, a branch protection, a workflow-jóváhagyás és a kötelező checkek külön kontrollok; a sandbox a hostot védi, nem a repót.
-   Minden futást időkorlátozz, minden feladatot budgetálj; a hasznos költségmetrika a mergelt pull requestre jutó költség.
-   Az elutasított ügynök-PR-ek többsége koordinációs, CI- és review-kapacitás-probléma, nem modellképesség.

Ezen az oldalon

1.  [Miért változik meg az aszinkron munkával a munkaegység](https://balazscsorba.com/#why-async-agents)
2.  [Egy aszinkron PR-pipeline felépítése](https://balazscsorba.com/#anatomy)
3.  [A sor maga a termék](https://balazscsorba.com/#task-queue)
4.  [Sandboxok: mihez nyúlhat az ügynök](https://balazscsorba.com/#sandbox)
5.  [Hosszú futások, timeoutok és újraindíthatóság](https://balazscsorba.com/#long-runs)
6.  [A CI az első reviewer](https://balazscsorba.com/#ci-gating)
7.  [Az emberi review a szűk keresztmetszet](https://balazscsorba.com/#human-review)
8.  [Feladatonkénti költségszabályozás, nem tokenenként](https://balazscsorba.com/#cost-control)
9.  [Hibamódok és a hozzájuk tartozó védőkorlát](https://balazscsorba.com/#failure-modes)
10.  [Bevezetés anélkül, hogy PR-ekbe fulladnánk](https://balazscsorba.com/#rollout)
11.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

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.

A hurok a fontos rész. Az a pipeline, amelyik nem küldi vissza kontextussal a sikertelen futást, minden CI-hibából új feladatot csinál.

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](https://balazscsorba.com/hu/blog/agent-loop-explained) tárgyalja.

Rendszer

Hogyan kerül be

Izoláció és hálózat

Publikált limitek

GitHub Copilot Cloud Agent

Issue hozzárendelése, `@copilot` említése vagy indítás az agents panelről

Ephemeral GitHub Actions környezet; alapból bekapcsolt firewall

59 perc sessionönként; egy branch és egy PR feladatonként; nem approve-olhat és nem mergelhet

OpenAI Codex Cloud

Feladat a Codex Cloudban vagy GitHubról, Linearról, Slackből

Feladatonkénti konténer; az ügynök internet alapból ki; a setup secretjei az ügynökfázis előtt törlődnek

Konténer akár 12 óráig cache-elve; PR kérésre

Claude Code Cloud

`claude.ai/code`, `claude --cloud` vagy routine

Anthropic-kezelt VM; korlátozott hálózat; git credentialök a sandboxon kívül

A csomag limitjébe számít; az idle sessionök lejárnak

Google Jules

Prompt, `jules` label vagy API-session

Google Cloud VM internet-hozzáféréssel

15, 100 vagy 300 feladat naponta; 3, 15 vagy 60 párhuzamosan

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.

**A sandbox a hostot védi, nem a repót**

Az izoláció megakadályozza, hogy az ügynök a laptopodat vagy a szomszédok adatait olvassa. Nem akadályozza meg a rossz commitot, a felhígított tesztet vagy a később secreteket kapó workflow szerkesztését. Kezeld minden ügynök-branchet idegen hozzájárulásként: védd a default branchet, kérj checkeket és review-t, korlátozd, ki hagyhatja jóvá a workflow-futásokat, és tégy `CODEOWNERS`\-t a CI- és tesztfájlokra. Az [AI agent sandbox checklist](https://balazscsorba.com/hu/blog/sandboxing-coding-agents-ci-checklist) sorban végigmegy a rétegeken.

## 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](https://balazscsorba.com/hu/blog/harness-engineering-coding-agents): 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](https://balazscsorba.com/hu/blog/ai-generated-pr-review-bottleneck) leír, és ugyanaz a designkérdés, mint a [human in the loop AI-ügynököknél](https://balazscsorba.com/hu/blog/human-in-the-loop-ai-agents): 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.

Mérő

Mit fogyaszt

Kar

Modelltokenek

Input-kontextus, thinking, tool callok és output minden körben

Szűkebb feladat, kisebb modell ahol elég, maximális körök

CI-percek

Minden push, minden újrafuttatás és a merge queue

Fail fast, elavult futások megszakítása, flaky tesztek javítása

Sandbox-idő

VM- vagy konténerpercek, a setuppal együtt

Dependency cache, wall clock korlát, idle sessionök leállítása

Emberi review

A legszűkebb és legkevésbé instrumentált erőforrás

Kis diffek, WIP-limit reviewerenként, draft először

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.

Hiba

Tünet

Védőkorlát

Duplikált munka

Két PR ugyanarra az issue-ra; az egyiket elavultként zárják (a minta 23%-a)

Dedupe-kulcs, claim label, nyitott és nemrég zárt PR-ek keresése sorba állítás előtt

Érkezéskor piros

Az ügynök olyan PR-t nyit, amelyik azonnal elbukik a CI-n (17%)

Tesztparancs futtatása a sandboxban; ready for review csak zöld checkek után

Reviewer elhagyása

A PR érdemi emberi review nélkül marad, majd elavultan zárják (38%)

Reviewer kijelölése nyitáskor, SLA, elavult draftok automatikus zárása

Gyengített tesztek

A diff úgy teszi át a tesztet, hogy töröl vagy lazít assertionöket

CODEOWNERS a teszteken, a teszt-diff külön review-ja, először bukó teszt kérése

Prompt injection

Rejtett utasítások issue-ban, README-ben vagy dependency-oldalon irányítják az ügynököt

Az issue-szöveg nem megbízható, rejtett karakterek szűrése, secret nélküli ügynökfázis, hálózati allowlist

Scope creep

Egy kis feladatból többfájlos átírás lesz, amit senki nem tud review-zni

Útvonal-allowlist és diff-budget; a feladatot bontsd, ne bővítsd

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](https://docs.github.com/en/copilot/concepts/agents/coding-agent/about-coding-agent)
2.  [GitHub Docs: Risks and mitigations for Copilot cloud agent](https://docs.github.com/en/copilot/concepts/agents/cloud-agent/risks-and-mitigations)
3.  [OpenAI Developers: Codex cloud environments](https://developers.openai.com/codex/cloud/environments)
4.  [Anthropic: Use Claude Code in the cloud](https://code.claude.com/docs/en/claude-code-on-the-web)
5.  [Google Jules: Limits and plans](https://jules.google/docs/usage-limits/)
6.  [Google Jules: Getting started](https://jules.google/docs/)
7.  [GitHub Docs: About protected branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)
8.  [GitHub Docs: Models and pricing for GitHub Copilot](https://docs.github.com/en/copilot/reference/copilot-billing/models-and-pricing)
9.  [OpenAI Developers: Codex pricing](https://developers.openai.com/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)](https://arxiv.org/abs/2601.15195)
11.  [Peralta et al.: Why Are Agentic Pull Requests Merged or Rejected? An Empirical Study (MSR 2026, arXiv 2605.22534)](https://arxiv.org/abs/2605.22534)
12.  [DORA: State of AI-assisted Software Development 2025](https://dora.dev/dora-report-2025)

## Gyakori kérdések

Mi az a háttérben futó kódoló ügynök?

Olyan kódoló ügynök, amely aszinkron módon, távoli infrastruktúrán fut az editor helyett. Átadsz egy feladatot, ő a saját sandboxában dolgozik, branchre pushol, és általában pull requestet nyit. A Codex Cloud, a Copilot Cloud Agent, a Claude Code felhős sessionjei és a Jules így működik.

Mergelheti az ügynök a saját pull requestjét?

Az itt leírt hosztolt termékeknél nem. A Copilot Cloud Agent nem tudja a pull requestet ready for review állapotba tenni, jóváhagyni vagy mergelni, és a változást kérő személy sem hagyhatja jóvá. A branch protectionnek ugyanezt a szabályt kell kikényszerítenie minden más ügynöknél.

Meddig futhat egy háttérfeladat?

Addig, hogy egy sikertelen futás olcsó legyen. A Copilot sessionönként kemény 59 perces limitet kényszerít ki. A Claude Code visszaveszi az idle felhős sessionöket, és csak akkor cache-eli a setup-szkriptet, ha körülbelül öt percen belül végez. Ha egy feladat egy óránál tovább tartana, bontsd szakaszokra commitokkal vagy tervfájllal a szakaszok között.

Hogyan akadályozom meg a duplikált ügynök-PR-eket?

Sorba állítás előtt deduplikálj. Használj repóból, issue-ból és bázis-commitból képzett kulcsot, keress rá a nyitott és nemrég zárt pull requestekre, és adj a feladatnak claim labelt. Az elutasított ügynök-PR-ek egy mintájában 23% volt már létező munka duplikátuma.

Kell saját runner a háttérügynökökhöz?

Nem feltétlenül. A hosztolt termékek kezelt VM-eket vagy GitHub Actions környezeteket adnak. A saját runner és a saját környezet akkor számít, ha az ügynöknek privát hálózati hozzáférésre, adott hardverre vagy a compliance csapat által előírt adathatárra van szüksége.

Miért záródik be sok ügynök-PR review nélkül?

Mert a review-kapacitás, nem az ügynökkapacitás a szűk keresztmetszet. Egy 600 elutasított ügynök-PR-t vizsgáló tanulmányban 38% érdemi emberi részvétel nélkül maradt. Többet ér, ha a PR megnyitásakor kijelölsz egy reviewert és korlátozod a párhuzamos munkát, mint a következő prompt-finomítás.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Eszközök tervezése AI-ágenseknek: nevek, leírások, sémák és hibaüzenetek](https://balazscsorba.com/hu/blog/agent-tool-design-descriptions-errors)
-   [Legacy kódbázis migrálása coding agentekkel: strangler fig playbook](https://balazscsorba.com/hu/blog/coding-agents-legacy-codebase-migration)
-   [Kontextusromlás hosszan futó ügynököknél: törlés, tömörítés, memória és al-ügynökök](https://balazscsorba.com/hu/blog/context-rot-compaction-long-running-agents)
-   [Böngészőágensek E2E-teszteléshez: írják az ágensek a Playwright-teszteket, ne futtassák](https://balazscsorba.com/hu/blog/browser-agents-e2e-testing-playwright)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)