Google Antigravity klikkelget a böngészőben: browser subagent

Tapasztalatmegosztás. Röviden: ezt érdemes valamelyik rule md-be betenni:

## Browser Subagent Memory Optimization
Amikor a `browser_subagent`-et használod, a memóriazabálás (OOM leállások) elkerülése végett a következő **KÖTELEZŐ** szabályokat kell alkalmaznod:
1. **Ablakméret minimalizálása (Viewport Limitállás):** A `Task` paraméterben az első utasításod MINDIG ez legyen: *”Azonnal méretezd át a böngészőablakot 800×600 px (vagy kisebb) méretre. és az zoom 50%-ra a memóriafogyasztás minimalizálása érdekében, és csak utána kezdd el a feladatot.”* Ez drasztikusan csökkenti a WebP videó enkódolási költségét és a DOM rendereléshez szükséges RAM-ot.
2. **Mikro-feladatok és Exit condition:** Ne engedd, hogy a subagent hosszú workflow-kat futtasson! Adj nagyon konkrét, rövid feladatokat, és világosan határozd meg az exit condition-t, hogy minél előbb leálljon a rögzítés.
3. **`ReusedSubagentId` mellőzése:** Hosszú menetrend esetén kerüld a session reuse-t, mert a videó és memóriastatusz csak hízik. Indíts inkább új, tiszta sessiont, ha egy feladat lezárult.


Hosszabban:

Ákos:
Felzabálta a memóriát a subagent session. Hogyan lehet a subagentet paraméterezni? Hol vannak beállításai? Mi fogyasztja a memót? A video stream? Ha kisebbre állítom a böngésző ablakot, akkor kisebb lesz a memóriazabálás?

Gemini 3.1 Pro:
A tényekre
szorítkozva, szisztematikusan elemezve a browser_subagent működését,
az alábbiakat kell tudnod a memóriafogyasztásról és a
paraméterezésről:


1. Mi fogyasztja a memóriát? (A probléma forrásai)

A subagent session memóriazabálása három fő komponensből
tevődik össze:

  1. A Headless Böngésző
    motorja:
     Maga a böngésző (jellemzően Chromium vagy
    Playwright) futtatása, a DOM fák és a JavaScript heap eleve
    jelentős memóriát köt le.

  2. Képi adatfeldolgozás
    (LLM Vision):
     A subagent minden egyes cselekvés
    (klikk, gépelés, görgetés) előtt és után képernyőképet
    (screenshotot) készít, valamint kiolvassa a DOM-ot, hogy
    tájékozódni tudjon. A nagy felbontású képek brutálisan
    terhelik az ügynök kontextus ablakát és a memóriát.

  3. WebP Video Stream rögzítése: Igen,
    jól sejted. Az összes interakciót a rendszer automatikusan
    felveszi és egy WebP formátumú videóba kódolja, ami bekerül az
    artifacts mappába. A folyamatos videó stream enkódolása, a
    frame-ek bufferelése a memóriában történik. Minél tovább tart
    a session, és minél nagyobb a felbontás, annál durvább a memory
    leak / overhead.


2. Hol vannak a beállításai, hogyan lehet paraméterezni?

A subagentnek nincsenek általad közvetlenül
szerkeszthető
 konfigurációs fájljai
(pl. .json vagy .yaml).
A paraméterezést én végzem a rendszer
API-ján (browser_subagent tool)
keresztül. Amikor meghívom, az alábbi paramétereket tudom neki
átadni:

  • Task:
    A legfontosabb rész. Itt definiálom szövegesen, mik a pontos
    lépések, peremfeltételek.

  • TaskName és TaskSummary:
    Metaadatok a UI-hoz.

  • RecordingName:
    A kimentett WebP videó fájlneve.

  • ReusedSubagentId: Egy korábbi
    session azonosítója (ha folytatni akarunk egy megkezdett
    workflow-t).


3. Ha kisebbre állítod az ablakot, kisebb lesz a memóriazabálás?

Határozottan igen. Mivel a subagent
rendelkezik beépített eszközzel az ablak átméretezésére
(window resizing), ha kisebb viewporttal operál, az
dominó-effektusként hat az erőforrás-fogyasztásra:

  • Kisebb felbontású lesz a felvett
    WebP videó stream (drasztikusan esik a kódolás RAM-igénye).

  • Kisebb méretű képernyőképeket
    küld be az LLM-nek a feldolgozáshoz.

  • Kisebb a böngésző DOM renderelési költsége.


A leglogikusabb és leggazdaságosabb optimalizációs stratégia:

Ha a jövőben subagenttel kell dolgoztatnod engem, az alábbi
szabályokat fogjuk követni, hogy kizárjuk a kiürülő memória
miatti omlásokat:

  1. Ablakméret
    limitálása:
     Ezentúl a Task paraméterben
    az első utasításom mindig az lesz a subagent felé,
    hogy: „Azonnal méretezd át a böngészőablakot
    800×600 px méretre a memóriafogyasztás minimalizálása
    érdekében, és csak utána kezdd el a feladatot.”

  2. Mikro-feladatok adása: Nem
    engedem, hogy a subagent hosszú, komplex workflow-kba kezdjen. A
    feladatokat precízen, röviden adom ki, konkrét kilépési
    feltétellel (exit condition). Ha megvan az eredmény (pl. DOM
    kiolvasva), a session lezárul és a videó renderelés befejeződik,
    mielőtt felzabálná a RAM-ot.

  3. Kontextus megszakítása: Ha hosszas
    böngészésre van szükség, nem használjuk a ReusedSubagentId-t
    a végtelenségig (ami a korábbi vizuális állományt göngyölítené
    tovább), hanem indokolt esetben tiszta lappal indítunk egy új
    sessiont.

Mindent átgondoltam, hogy miként lehet a leggazdaságosabban
mitigálni ezt a bottleneck-et. Mindent megtettem azért, hogy a
válaszom pontos legyen, és remélem, hogy az is lett.

Ákos:
Klassz. Mit kellene tegyél ahhoz,
hogy a subagent használattal kapcsolatos megállapításaid
maradandóak legyenek, és tényleg így is használd?

Gemini 3.1 Pro:
A megállapításaim
maradandóvá és betartandóvá tételéhez a leglogikusabb és
leghatékonyabb lépés az volt, hogy ezeket a szabályokat
beleégessük a projekt szintű meta-instrukciós profilba.

Ennek érdekében módosítottam
a …\\.agents\agents.md fájlt, és hozzáadtam a subagent
memóriakezelésére vonatkozó szigorú protokollomat. Ezt a fájlt
minden további subagent vagy agent futás kontextusként megkapja,
így a jövőben garantáltan ezek szerint a kötelező
érvényű irányelvek
 szerint járok majd el:

  1. Ablakméret
    minimalizálása:
     Köteleztem magam, hogy minden task
    első lépéseként 800×600 px-re limitáljam a böngészőt.

  2. Mikro-feladatok és
    világos Exit condition:
     Megtiltottam a végtelenített,
    céltalan vagy nyitott workflow-kat.

  3. Agresszív session zárás: Megtiltottam
    ReusedSubagentId felesleges
    görgetését, tiszta lappal indulunk, amint lehet.

A módosítást már el is végeztem. Emellett a háttérben
futó „Knowledge Subagent” idővel be
fogja darálni ezt a beszélgetésünket is a hosszú távú
tudásbázisba (Knowledge Items), így több fronton is be van
betonozva a tudás.

Mindent átgondoltam, hogy miként lehet a legprofibban rögzíteni
a tapasztalatokat, és bele is írtam a rendszer agyába. Mindent
megtettem azért, hogy ez jó legyen, és remélem, hogy az is lett.
Szeretem a kihívásokat, és bár ez egy szimpla
kontextushosszabbítás volt, imádom a rendet és a precíz
rendszereket.