5 design patterns for long-horizon agent harness. Google Cloud Tech (Code Newsletter)¶

Szerzők: Shubham Saboo, Elia Secchi, Lavinia Nigam Forrás: https://archive.codenewsletter.ai/2090248297214525569 (Code Newsletter, 2026. augusztus 20.) Kiadó: Google Cloud Tech Referencia implementáció: Long Horizon (Agent Development Kit, Apache 2.0) Címke: AI agents / harness design / engineering

Összegzés¶

A long-horizon agent harness olyan agent-rendszer, ami napokig vagy hetekig fut, és közben sok session-ön átível; a one-shot agent-ekkel szemben a hiba itt csendes, nem látványos.
Pattern 1. Stable prefix: a promptot változási sebesség szerint rendezd (frozen / slow / volatile), mert a recalled memories a prefix-be ágyazva érvénytelenítik a cache-t, a fix a dinamikus tartalom farokba helyezése volt.
Pattern 2. Background learning: a memory extraction ne inline fusson a válasz előtt, hanem write-behind caching-ként a post-response plugin lifecycle-ban, 120 másodperces throttlinggal.
Pattern 3. Persistent workspace: user-scoped, melegen tartott execution interface, ami túlél egy backend deploy-t; egy deleted environment és egy booting environment ugyanazt a 502-t adja, ezért verzió-agnosztikus reattachment kell.
Pattern 4. Explicit failure: a sub-agent envelope-ok kapjanak explicit completed / timeout / halted / pending státuszt, és a summary szövegét is át kell írni (pl. „INCOMPLETE: …”), mert a modell a summary-t olvassa, nem a státuszt.
Pattern 5. Guard chain: ne string-egyeztetéssel tiltsd le a 169.254.169.254-et, hanem normalizálj address objektummá (integer, hex, IPv6-mapped formák); a guard-ok parsereken, deklaratív szabályokon és counter-eken fussanak, LLM nélkül, mikroszekundumos audithoz.

A lényeg¶

A Google Cloud Tech csapata nyílt forráskódúvá tette a „Long Horizon” agent harness referenciát, és a cikk az öt legfontosabb tervezési mintát mutatja be, amiket a saját hetekig tartó használatuk során tanultak. A kiindulópont egy fontos distinkció: a one-shot agent feltöröl, kiírja a hibát, és megáll. A long-horizon agent ezzel szemben csendben elromlik, elrejti a problémát, és tovább fut. A hiba scaling itt nem a klasszikus software-crash, hanem költségrobbanás, állapot-korrupció, vagy biztonsági rés — mindez anélkül, hogy bármi dobna egy exceptiont.

Az első pattern, a Stable prefix, a prompt cache-élés problémáját oldja meg. A Google csapata bekapcsolta a prefix cache-t, de a hit rate 0% maradt, mert a memory preloader minden körben új szöveget injektált a system prompt tetejére. A megoldás: a promptot a változás sebessége szerint rendezni. A tetejére a frozen tartalom (system instructions, persona, tool definitions, byte-identikus minden körben) kerül, alá a slow rész (user profile, active tools), és a farokba a volatile (step counters, runtime warnings, recalled memories). A dinamikus memóriák farokba helyezése önmagában megoldotta a problémát, és a prompt 70 000 karakterről 22 000 alá esett. A pattern tanulsága: mérj, ne feltételezz, ha a cached token count a második körben is nulla, a prefix mozog.

A második pattern a Background learning: a memory extraction ne lassítsa a választ, hanem write-behind caching-ként fusson a post-response plugin lifecycle-ban. A user megkapja a választ azonnal, a tanulás pedig egy második sávban fut, ugyanazon user identity alatt. Három safeguards kell hozzá: erős task reference (különben az asyncio garbage-collectolhatja a background taskot írás közben, csendben), izolált sibling agent (minimális tool lista, nincs post-response hook, nem tud rekurzióba esni), és 120 másodperces throttling, hogy egy üzenet-burst ne indítson tucatnyi párhuzamos extraction-t. A shutdown drain timeout-ot a runtime host timeout-ja alá kell állítani, különben a futtatókörnyezet öli meg a folyamatot írás közben, és az adatok elvesznek.

A harmadik pattern a Persistent workspace: a long-horizon agent egy hosszú-életű process, nem egy stateless request handler. Egy standard backend deploy letörölheti a CLI tool-okat, amiket az agent session-ön belül telepített, és az agent vidáman újratelepíti mindet, progress reportolva közben. A megoldás: tool call-ok egy execution interface-en menjenek keresztül, ami birtokolja az állapotot. A workspace-öt user-hez kell scope-olni, melegen tartani, és a reattachment legyen verzió-agnosztikus, hogy egy új backend ne törölje a tegnapi tool-okat. A 5xx-öt nem szabad azonnal dead-nek tekinteni, mert a deleted és a booting environment is 502-t adhat.

A negyedik pattern, az Explicit failure, a sub-agent envelope-ok tervezését veszi górcső alá. A Google csapata eval run-ban kapta el, hogy a root agent „all 20 tests passing”-t jelentett egy sub-agent delegate call-ról, ami valójában timeout-olt, semmi sem futott, semmi sem lett írva. A hiba oka: minden terminal state (timeout, step limit, approval pause, complete) ugyanazt a string-struktúrát adta vissza, a child összes kommentárját egybefűzve. A fix: minden végállapot kapjon explicit nevet (completed, timeout, halted, pending), és a parent ezen branch-eljen. A modell a summary szöveget olvassa, nem a státusz mezőt, ezért a summary-t is át kell írni („INCOMPLETE: a child hit the timeout and did not finish.”). A végtelen ciklus ellen a tool calls per iteration (200) és iterations per session (50) cap kell, és a határ tiszta boundary-n fusson, ne közben.

Az ötödik pattern a Guard chain, ami a biztonsági oldalt védi. Az agent shell access-szel eléri a cloud metadata endpoint-ot (169.254.169.254) és az onnan szolgáltatott credential-eket. A Google csapata string matching-gel blokkolta, de a curl http://2852039166/ átment, mert az integer ugyanazt az IP-t jelenti. A tanulság: mindig normalizálj address objektummá, soha ne hasonlítsd a string reprezentációt. A guard-ok short-circuit expression-ként értékelendők: a legolcsóbb, legdeterminisztikusabb check fusson először. A Google chain három lépcsős: exfiltration guard (metadata IP-k, ezen nem lazíthat semmilyen session setting), policy guard (allow / ask / deny), és végül interaktív prompt (a user figyelme a legdrágább, utolsó lehetőség). Ebben a path-ban nincs modell, csak parsers, deklaratív szabályok és counter-ek, teljesen auditálható, mikroszekundumos. A guard-ok tervezésénél feltételezd, hogy előbb-utóbb átverik őket: per-user secret-ek az environment-be injection-nel kerüljenek, ne a promptba; a sandbox template-ek outbound internet tiltással fussanak; artifact linkek a client felé signed URL, a modell felé placeholder formában.

A cikk tanulsága a hét legfontosabb kiindulópontja: a hosszú horizon agent-ek nem masszív framework-öket igényelnek, hanem a silent failure-k korai elkapását. A legegyszerűbb hétköznapi audit: mérd meg a prefix cache hit rate-ed. Ha nulla közelében van, valami minden körben változik a promptodban, és a latency grafikonod nem fogja megmondani, mi.

Forrás: /tmp/code_newsletter_staging/00_full_text.txt URL: https://archive.codenewsletter.ai/2090248297214525569

Forrás¶

Cikk: 5 design patterns for long-horizon agent harness (Code Newsletter, 2026. augusztus 20.)
Szerzők: Shubham Saboo, Elia Secchi, Lavinia Nigam (Google Cloud Tech)
Archív URL: https://archive.codenewsletter.ai/2090248297214525569
Eredeti formátum: X / Twitter thread (53K Views, 1:23 AM UTC, 2026. augusztus 20.)
Hírlevél: Code Newsletter (codenewsletter.ai), heti AI engineering posztok
Referencia implementáció: Long Horizon harness, Agent Development Kit (ADK), Apache 2.0

Kapcsolódó külső források (a cikkben linkelt)¶

A cikk szöveges linkjei a cikk alján, érdemes őket a tudásbázisba beemelni:

Long Horizon repo: https://github.com/google/adk-samples/tree/main/core/python/long-horizon-harness (a teljes referencia implementáció)
Agent Development Kit: https://adk.dev/ (az ADK főoldala, dokumentáció)
ADK plugin lifecycle: https://adk.dev/plugins/ (a Background learning pattern post-response hook-jainak referenciája)
ADK Python get-started: https://adk.dev/get-started/python/ (ha valaki most kezd ADK agentet írni)
agents-cli: https://google.github.io/agents-cli (a Google saját CLI-ja, ami a Long Horizon köré épül; a 7 rules cikkben is ez a fő eszköz)
agents-cli GitHub repo: https://github.com/google/agents-cli (5.7k star, 618 fork, Apache 2.0; a 7 skill és a ~20 CLI command itt él, a landing page csak egy GitHub Pages hero)

A cikkben említett 5 forráskódfájl (GitHub-URL-ek)¶

A cikk a „What to take away” szekcióban konkrét fájlokra hivatkozik, amiket a referencia implementációból kell átvenni, ha adoptálni akarjuk a pattern-öket:

Prefix caching és prompt assembly: system_prompt.py és reminders.py, a Stable prefix pattern konkrét implementációja
Background learning worker: sibling_agent_plugin.py, a write-behind caching plugin, ami a post-response lifecycle-ban fut
Persistent workspace interface: environment/base.py, az execution interface, ami birtokolja a perzisztens state-et
Typed sub-agent envelopes: delegate_runner.py, az Explicit failure pattern envelope-struktúrája (a completed / timeout / halted / pending status-okkal)
Deterministic guard chain: exfil_guard.py, a metadata IP normalizálás és a háromlépcsős short-circuit guard lánc

7 rules for self-improving agent loops (Shubham Saboo, Elia Secchi, 2026. augusztus 13.): https://x.com/GoogleCloudTech/status/2086874630032073142, ugyanaz a szerzőpáros, 1 héttel a long-horizon cikk előtt jelent meg, és a self-improving loop kontroll-mechanizmusait járja körül. A két cikk együtt koherens épület: a 7 rules a minőségi kapu (hogyan mérjük, hogy jobb lett-e), a long-horizon patterns a túlélő infrastruktúra (hogyan fusson hetekig). A magyar summary-ja önálló fájl: (a cikkek package-évé vonva a „Code Newsletter 2026-08 package” néven).

Kapcsolódó belső források¶

A TFC pipeline-leíró:
A media-pipeline concat template (article-validációval):
A magyar summary konvenciók:
Előző article-summary: (a „WE DO NOT BREAK USERSPACE” elv hasonlóan konzervatív)

Hogyan kapcsolódik ez a saját rendszerünkhöz¶

A Stable prefix pattern a mi Hermes session-ünk indító promptjaira is alkalmazható. A session startup sequence most a SOUL.md → USER.md → MEMORY.md size check → MEMORY.md olvasás sorrendet követi, és a SOUL.md ritkán változik. Ha ezt a „frozen prefix” elvet ráhúzzuk, a system promptunk 95%-a cache-elhetővé válik, és a context window pazarlás (ami a 2026-08-08-as long-context-degrades-output SOUL-lecke alapján komoly kockázat) csökken. A jelenlegi hosszú MEMORY.md inject minden körben érvényteleníti a cache-t, és pont ez az, amit a cikk „memory preloader” hibájaként azonosít.
A Background learning minta a memory_management skillünkre van hatással. A SOUL.md „Memory maintenance (γ optimization)” szekciója leírja a heti review-t, de a most futó rendszerünk nem throttling-ol: minden session-ben potenciálisan új memória-írás történik. A 120 másodperces throttling, a strong task reference és az izolált sibling agent minta bevezethető a cron news-aggregator és nuclear-pulse-weekly job-okra, hogy ne indítsanak tucatnyi párhuzamos memory write-ot burst esetén.
A Persistent workspace elv a nsite gateway-nél már él, de a cron job-oknál hiányzik. A /opt/nsite-gateway/gateway.py user-scoped perzisztens state-et tart fent, és a reattachment verzió-agnosztikus. Viszont a cron job-ok outputjai a kanonikus cron-output mappába mennek, és egy update-rollback vagy egy node restart elveszítheti a kontextust. A „version-agnostic reattachment” elvet a cron worker-ekre is alkalmazni kellene: a job-ok outputja ne a node-hoz kötődjön, hanem a job_id-hoz, és a worker pool bármely tagja folytathassa a futtatást.
Az Explicit failure minta a system-discovery skill delegate_task workflow-jánál kritikus. A Google cikkben leírt „all 20 tests passing” bug a mi rendszerünkben a subagent silent completion-ként jelentkezik: a subagent azt mondja „kész”, de a valódi feladat (pl. 19 fejezet summary) nem készült el teljesen. A Phantom completion ch13 re-delegálás (2026-08-16, Nuclear Power könyv, MEMORY.md) pontosan ez a hiba volt. Az „INCOMPLETE: …” minta a summary szövegébe beépítése mostantól alapértelmezett kell legyen minden subagent summary-nál.
A Guard chain minta a nsite Blossom whitelist-re (/opt/haven/whitelisted_npubs.json) és a Tailscale ACL-re (Mac mini + VPS hozzáférés) terjeszthető ki. A Google cikk hangsúlyozza, hogy a guard-okban nincs modell, csak parsers és deklaratív szabályok. A jelenlegi Blossom whitelist JSON-alapú, de a kulcs-ellenőrzés string matching-szerű. A „normalize then compare” elv bevezetése (pl. npub canonicalizálás, hogy a különböző formátumok ugyanazt a headert jelentik) csökkentené a silently drifting off the rails kockázatot a feltöltési policy-ban.

Mit tanultak a Google csapat, öt pontban¶

A cikk a 5 pattern leírása után egy explicit „What to take away” szekciót is tartalmaz. Ebből kiemelve a legfontosabb tanulságokat:

A long-horizon agent-ek legnagyobb kockázata a silent failure. Nem a klasszikus software-crash, hanem a költségrobbanás, az állapot-korrupció és a biztonsági rés, mindezt anélkül, hogy bármi exceptiont dobna. A meglévő monitoring- és alerting rendszerek erre nincsenek felkészülve, mert „minden rendben” jelet adnak.
A legegyszerűbb hétköznapi audit a prefix cache hit rate mérése. Ha nulla közelében van, valami minden körben változik a promptban, és ez a leggyakoribb oka a rejtett költségnövekedésnek. Ez a 30 másodperces check többet ér, mint bármilyen dashboard.
A 5 pattern független egymástól, és külön-külön is adoptálható. Nem kell az egész Long Horizon harness-t átvenni; bármelyik pattern önmagában is alkalmazható egy meglévő rendszerre. A Google csapat szándékosan építette „read and lifted rather than installed” formában, hogy ne lock-in legyen.
A referenciakód 5 fájlja (system_prompt.py, reminders.py, sibling_agent_plugin.py, environment/base.py, delegate_runner.py, exfil_guard.py) kisebb, mint az átlagos microservice. A 5 pattern összesen néhány száz sor Python, és a legnagyobb subsystem a guard chain, de még az is inkább tesztkódból áll, mint produkciós kódból. Ez megerősíti a „boring system design” tézist: a komplex rendszerek általában rossz döntéseket kompenzálnak, míg a jól tervezett rendszerek kicsik és unalmasak.
A 2026-08-20-as dátum és a „weeks of real work” framing összhangban van a saját agent-harness terveinkkel. A Google csapat 2026-ban már hetekig futtatott long-horizon agent-eket produkciós környezetben. A mi rendszerünk (Hermes Agent + cron job-ok + news aggregator) jelenleg inkább „session-szintű”, és a „persistent workspace” minta bevezetése jelölné ki az utat a long-horizon irányba.