Fred Schott — az Astro webkeretrendszer alkotója, aki januárban a Cloudflare-hez került — kiadta a Flue keretrendszer 2.0-s verzióját, amely stabil kiadásként vezeti be a React-stílusú „Agent Hookok” fogalmát. A Flue-t idén mutatta be először, és a most megjelent Flue 2 az első stabil kiadás a szerző szerint.
Mire jók az Agent Hookok?
A Flue-ban az ügynök (agent) egy JavaScript függvényként van reprezentálva, amely „minden fordulóban újrarenderelődik”, azaz minden modellhívás előtt újra lefut. Schott azután vezetett be hookokat, hogy rájött: a React komponálhatósága jól illik az ügynökök fejlesztéséhez. A hookok TypeScriptben készülnek, és lehetővé teszik dinamikus ügynökök építését, amelyek saját állapotukat kezelik, figyelik az ügynök életciklus eseményeit, és futásidőben dinamikusan csatolhatnak erőforrásokat vagy képességeket.
A Flue 2 dokumentációja szerint a kiadás 16 beépített hookot tartalmaz, például useSkill(), useTool(), useSubagent(), továbbá támogat egyedi hookok létrehozását is. A hookok használatával az ügynök konfigurációja a beszélgetés vagy munkafolyamat előrehaladtával változhat, ami különösen fontos olyan feladatokhoz, mint a valós ügyfélszolgálati vagy triázs botok, amelyek nem állíthatók teljesen előre.
Például egy ügyféltámogatási ügynök először hitelesítheti a felhasználót, majd dinamikusan bekapcsolhat egy fiókkezelő eszközt.
A fájl-alapú megközelítés kritikája és a komponálhatóság felé fordulás
Schott korai elképzeléseiben a webes keretrendszerek egyes ötleteit próbálta átültetni Flue-ba, például a fájl-alapú routingot. Tapasztalatai szerint azonban sok nagyobb felhasználó esetében a szervezet „egy ügynök”, és nem érdekli őket a routing: nincs öt külön ügynökfájl, csak egyetlen komplex ügynök. A korai felhasználói visszajelzés hatására a komponálhatóság vált központi szemponttá, ami visszavezette Schottot a React mintára.
A Flue 2 API-ja inkább a React filozófiájára épít, azaz kevesebb hangsúly a weboldalak routingján és több a különböző komponensekből (képességek, alügynökök stb.) történő ügynökösszeállításon.
A harness szerepe: mi az, és miért lényeges
A Flue egyik központi koncepciója, hogy egy ügynöknek „harness”-re (hámra) van szüksége — egy környezetre, amely biztosítja a kontextust és képességeket a feladatok elvégzéséhez. Schott szerint nem a kódból és parancsszkriptekből a fejlesztő vezeti az LLM-et, hanem az ügynök maga képes a harness-en keresztül önállóan problémákat megoldani.
Flue a Pi nevű, nyílt forráskódú minimális harnessre épül; Flue erre egy véleményvezérelt réteget ad, olyan fejlesztői kényelmi funkciókkal, amelyeket Schott hasznosnak tart. A Flue 2 hosted agentjei mostantól Vite-t használnak a buildfolyamatnál.
Schott állítása szerint a harness nem pusztán egy funkció, hanem alapvető része annak, amit egy ügynök jelent: „nincs ügynök harness nélkül”.
Hogyan indult a Flue és hogyan használják fejlesztők
A Flue projekt az Astro repozitóriumon belül indult idén, kezdetben egy issue-triage automatikaként. Kezdetben LLM-vezérelt munkafolyamatként működött, később képessé vált műveletek végrehajtására a repóban, és onnan alakult át hostolható, headless megoldássá — Schott a korai verziót úgy írta le, mint „Claude Code, de 100% headless és programozható”.
Schott szerint sok fejlesztő jelenleg AI-kódoló ügynökökkel (például Claude Code-dal) épít Flue ügynököket: az onboarding folyamata gyakran egy prompt átadásából áll, amely végigvezeti a felhasználót az ügynök létrehozásán, és a dokumentáció Markdown-támogatással készült.
Hol helyezkedik el a Flue a piacon?
A legközelebbi összehasonlítás Vercel eve nevű projektje, amely szintén a harness-t alapvető elemként kezeli. Schott elismeri az eve-t, mint közvetlen versenytársat; mindkettő hasonló időben jelent meg, és hasonló alapelveket követ. Schott említette továbbá az úgynevezett „OG agent frameworköket” — Vercel AI SDK, Cloudflare Agents SDK és Mastra — amelyek korábban jelentek meg és mostanra szintén harness-szerű funkciókat adnak hozzá, de szerinte ezek esetében a harness inkább későbbi, ráépített funkció.
Schott úgy fogalmazott, hogy Flue és a harness nagyon szorosan összekapcsolódnak: Flue meghatározza, hogyan működnek a skillek és a subagentek a saját ökoszisztémájában, és nem szeretné, ha egy „meta-harness” API elmosná ezt a történetet. Ugyanakkor érdeklődéssel figyeli a meta-harnessekről (például Databricks Omnigent vagy Exo) folyó beszélgetést, és kipróbálta Exo-t is, bár szerinte az más érdeklődési szcenáriókat szolgál.
Cloudflare és host-portabilitás
Schott folyamatosan hivatkozott arra, hogy Cloudflare-nél szerzett munkaeszközöket és infrastruktúrát tud hasznosítani, ugyanakkor hangsúlyozta, hogy a Flue nyílt forráskódú, „minden host számára” szánt keretrendszer marad. Szerinte a legjobb eszközök azok, amelyek „a host fölött lebegnek”, mert ez szélesebb fejlesztői elfogadást és innovációt tesz lehetővé.
A host-portabilitás a Flue egyik meghatározó elve, és ez az egyik alapvető különbség Vercel eve megközelítéséhez képest: bár eve is önhostolható, optimalizálva van Vercel szolgáltatásainak kihasználására, míg Flue célja a függetlenség.
Ütemterv és jövő
Schott elmondta, hogy jelenleg nincs tervben menedzselt (hostolt) ügynök-szolgáltatás a Flue számára; a csapat most a „legjobb harness” megépítésére koncentrál. A Flue 2 tehát elsősorban a keretrendszerre, a hookokra és a harness beágyazására fókuszál.
Összegzés
A Flue 2 stabil kiadása és a React-stílusú Agent Hookok bevezetése egyértelműen azt a törekvést tükrözi, hogy az ügynökfejlesztésben nagyobb komponálhatóságot és dinamikus viselkedést tegyen lehetővé. A Pi-re épülő, Vite-t használó Flue 2 célja, hogy nyílt forráskódú, hosztfüggetlen eszközként szolgáljon fejlesztőknek, miközben a harness mint alapvető fogalom köré szervezi az ügynökök működését.
(Nevezetek említve a cikkben: Fred Schott, Cloudflare, Astro, Flue, Pi, Vite, Vercel, eve, Vercel AI SDK, Cloudflare Agents SDK, Mastra, Claude Code, Databricks Omnigent, Exo.)
