Végre itt van, amire vártatok! Ralph TUI, a Ralph Loop vizualizációja

Korábban írtam egy oktatóanyagot a ralph-loop-ról, és sok barátom, miután lefuttatta, hasonló visszajelzést adott: Nagyon jó, a Claude Code végre hosszú ideig futhat. De néha úgy tűnik, mintha nem mozdulna, és az emberben felmerül a kérdés: "Valójában halad, vagy csak egy helyben toporog?"

Ez az oka annak, hogy mostanában a ralph-tui-val foglalkozom.

A ralph-tui nem kötelezően a Claude Code-hoz kötődik, hanem a ralph loop lényegét örökli és fejleszti tovább, és a feladatvégrehajtást és a folyamatot vizualizálja, jelentősen csökkentve a nagyméretű modellek hosszú távú működtetésének akadályait. Teljesen használhatsz más ügynököket, más modelleket, hazaiakat, olcsókat, olyanokat, amelyeket hosszú távon is megengedhetsz magadnak. A ralph-tui-val a hétköznapi emberek számára ez olyan, mintha kézi váltóról automata váltóra váltanánk, tempomattal.

Mi is ez valójában?

A ralph-tui-t úgy képzelheted el, mint egy "AI kódoló ügynök ciklikus szervezőjét", csak nem elégszik meg azzal, hogy "működik", hanem jobban érdekli, hogy "láthasd, irányíthasd és helyreállíthasd".

Az alapvető működési módja nagyon egyszerű:

• Adsz neki egy csomó feladatot (akár a PRD-ből, akár más feladatrendszerből)
• Kiválasztja a legmagasabb prioritásút
• Promptot állít össze
• Elindítja az ügynököt a végrehajtáshoz
• Megítéli, hogy a feladat befejezettnek számít-e
• Állapotot ír
• A következő körben folytatja

A lényeg az, hogy mindezt láthatod a terminálban, és bármikor leállíthatod, bármikor átveheted az irányítást. A hivatalos definíciója is nagyon egyértelmű: egy interaktív TUI-val rendelkező agent loop orchestrator, amely támogatja a TUI / headless / remote működést.

Miért mondom, hogy jobban megfelel a "hosszú távú futtatásra"?

A szkript loop futtatásának legnagyobb problémája nem az, hogy nem indul el, hanem az, hogy nem tudod, hol tart.

Látod, hogy a naplók gyorsan frissülnek, a ventilátor is boldogan pörög, de nem vagy biztos benne:

• Ugyanazt a hibát javítja újra és újra?
• Folyamatosan ugyanazt a kódrészletet módosítja, majd visszaállítja?
• Már befejezte, csak nem lépett ki?
• Valamelyik teszten akadt el egy végtelen ciklusban?

A ralph-tui megoldása nagyon "mérnöki" jellegű:

• Van session fogalma, az állapot lemezre kerül (.ralph-tui/session.json)
• Összeomlás esetén újraindítható (crash recovery)
• Van zármechanizmus, hogy elkerüld, hogy több példányt nyiss meg, és tönkretedd a könyvtárat
• Akár headless módban is futtatható CI-ben, vagy akár remote módban is elindítható egy listener a távoli oldalon, és a helyi TUI csatlakozhat hozzá

Egy szóval: Inkább olyan, mintha "egy kódot író munkást irányítanál", nem pedig "egy szkriptet figyelnél, ami megőrül".

Hogyan telepítsd?

A ralph-tui egy Bun/TypeScript ökoszisztéma, így a telepítése elég egyszerű. A hivatalos oldalon is van telepítési útmutató.

Először ellenőrizd, hogy van-e Bun a gépeden:

bun --versionmajd telepítsd a ralph-tui-t (itt egy tipikus telepítési módot mutatok, a részletekért nézd meg a hivatalos telepítési oldalt):

bun add -g ralph-tuiTelepítés után ellenőrizd:

ralph-tui --helpHa Node párti vagy, és nem akarsz Bun-hoz nyúlni, az is jó:

npm i -g ralph-tui

Ne csinálj rögtön nagy dolgokat, futtass egy minimális zárt hurkot

Javaslom, hogy első használatkor ne rögtön valami "teljes repo refaktorálást" csinálj. Csak egy dolgot tegyél: Futtass le egy elfogadható kis feladatot.

Inicializálás

Nyiss meg egy tetszőleges könyvtárat:

mkdir ralph-tui-demo && cd ralph-tui-demo ralph-tui setupEz egy interaktív varázslófolyamatot indít el, ami lényegében azt jelenti, hogy "telepíti a ralph-tui-t ebbe a tárolóba", és a következőket fogja tenni:

• Automatikusan felismeri, hogy milyen agentek vannak telepítve a gépeden (például Claude Code, OpenCode stb.)
• Létrehoz egy konfigurációs fájlt a projektben: .ralph-tui/config.toml
• Mellékesen telepíti a PRD generálással/feladat konvertálással kapcsolatos skilleket (így nem kell később kézzel bajlódnod vele)

Én személy szerint azt javaslom: első alkalommal ne légy lusta, a setup-ot mindenképpen futtasd le.

Projekt PRD generálása

A setup futtatása után a következő lépés a hivatalos oktatóanyag legfontosabb része, ami a legalkalmasabb egy nyilvános demo megírására: create-prd.

ralph-tui create-prd --chat parancs egy párbeszédes folyamatot indít el, amely úgy fog kérdezgetni, mint egy termékmenedzser a követelmények céljairól, a határokról és az elfogadási kritériumokról. A kérdések után két dolgot fog kiírni a projektbe (ez a lényeg):

• Egy PRD markdown fájlt: ./tasks/prd-feature.md
• Egy közvetlenül végrehajtható feladatfájlt: ./prd.json

Ezen a ponton lépsz be igazán a ralph-tui "standard zárt körébe":

Követelmény (PRD) → Feladat (prd.json) → Végrehajtás (run)

Futtatás

Ha van prd.json, akkor a futtatás már magától értetődő:

ralph-tui run --prd ./prd.json látni fogod, hogy a TUI elindul, és elkezdődik a loop: feladat kiválasztása → végrehajtás → befejezés megállapítása → állapot írása → befejezés vagy következő kör.

Első futtatáskor erősen javaslom, hogy adj meg egy iterációs korlátot, először zárd kalitkába:

ralph-tui run --prd ./prd.json --iterations 5 futtatás után nézd meg a változásokat, futtass teszteket, és nézd meg, hogy a PRD és a feladat megfelel-e az elvárásoknak. Ha megbizonyosodtál arról, hogy ez a lánc működik, akkor engedd el az iterációkat, és lépj át a headless/remote-ra, ez a megbízható ütem.

Ekkor alapvetően meg tudod erősíteni: ez a loop tényleg fut.

Milyen modellt/Agentet válasszunk? Az őszinteség a pénzmegtakarításban

Tudom, hogy sokakat az érdekel a legjobban: "Nem muszáj Claude Code-ot használnom? Használhatok olcsóbb modellt?"

A válasz: igen.

A ralph-tui alapból támogatja az agent és a model megadását (a hivatalos run dokumentációban vannak példák).

Például Claude Opus használata:

ralph-tui run --prd ./prd.json --agent claude --model opus de őszintén szólva, én magam nem használnám az Opust "tesztelésre, lint javításra", túl drága. Az én szokásom a rétegzés:

• Olcsó modellek: nagy mennyiségű ismétlődő munka futtatása (tesztek kiegészítése, kommentek kiegészítése, formázás javítása, határok hozzáadása)
• Drága modellek: csak a kulcsfontosságú csomópontokon jelennek meg (architektúra módosítás, nehéz hibák, alapvető logika)

Ha átlagos fejlesztő vagy, ez a gondolkodásmód még fontosabb. Mert nem egy nagyvállalat költségvetésével rendelkezel, a költségeket kordában kell tartanod, hogy sokáig tudj futni.

Szeretnél még jobban járni? Bízd az "PRD írást" is az agentre

A ralph-tui-nak van egy olyan kialakítása, ami nekem nagyon tetszik: támogatja a skilleket (ami lényegében egy agent külső parancskészlete).

A hivatalos telepítési mód az add-skill használata:

bunx add-skill subsy/ralph-tui --all vagy telepítsd egy adott agentre, például claude-code-ra:

bunx add-skill subsy/ralph-tui -a claude-code -g -y telepítés után slash parancsokat használhatsz az agent munkamenetben:

/ralph-tui-prd /ralph-tui-create-json /ralph-tui-create-beads Ez olyan, mintha egy plugint telepítettél volna az IDE-be, csak ez a plugin az agent számára készült. Ennek az a lényege, hogy csökkenti a "kézi követelmény-átviteli" időt, így a követelmény → feladat → végrehajtás jobban hasonlít egy futószalagra.

Mikor érdemes használni? Mikor ne?Nem igazán szeretem azt a narratívát, hogy "mindent meg lehet oldani AI-val", mert könnyen félrevezető. Az eszköz az eszköz, és csak a megfelelő helyzetben értékes.

Alkalmas helyzetek a ralph-tui használatára

Van egy csomó ilyen munkád:

• Tesztek pótlása (különösen régi projekteknél)
• Lint / format javítása
• Kis lépéses refaktorálás (ismétlődő kód összevonása)
• Típusok tömeges hozzáadása, határok pótlása
• A követelmények felbontása és a feladatok ütemezett végrehajtása

Ezeknek a munkáknak van egy közös pontja: sok feladat, magas ismétlődési arány, elfogadható, iteratívan fejleszthető.

Nem alkalmas helyzetek a ralph-tui erőltetésére

Ilyeneket akarsz csinálni:

• Egyszeri nagy refaktorálás, nem egyértelmű elfogadási kritériumokkal
• Maga a követelmény homályos, a fejedben lévő implicit tudásra támaszkodik
• Sok csapatközi kommunikációra/visszaigazolásra van szükség
• Termékkel kapcsolatos döntéseket kell hoznod

Ilyen feladatoknál az agent loop csak felerősíti a káoszt.

Mi a különbség a ralph-loop (ralph-claude-code) és a ralph-tui között?

A ralph-claude-code inkább egy "Claude Code önvezető kiegészítője": a szkript elindítja, futtatja a ciklust, a kilépésérzékelés, a sebességkorlátozás és a megszakító mind biztosítva van. Ha "gyorsaságra" van szükséged, akkor az gyors lesz.

A ralph-tui inkább egy "agent loop mérnöki vezérlőpultja": nem forrasztja rá magát egy adott modellre, és nem forrasztja rá magát egy adott feladatrendszerre sem. Azt akarja megoldani, hogy "hosszú távon fusson, megfigyelhető, irányítható, helyreállítható és távolról vezérelhető" legyen.

Szóval, ha megkérdezed, hogyan válasszak?

• Claude Code felhasználó vagy, és gyorsan el akarod indítani → ralph-claude-code
• Különböző modelleket akarsz csatlakoztatni, pénzt akarsz spórolni, és a loop-ot szolgáltatásként akarod kezelni → ralph-tui

Végül: Ne hagyd, hogy a raktáradat laboratóriumként használja

Nekem van néhány aranyszabályom az agent loop futtatásához, leírom ide, és ha követed őket, sokkal kisebb lesz a kudarc esélye:

• Ágon futtasd, ne a main-en kísérletezz.
• Az első futtatásnál mindenképpen add hozzá a --iterations paramétert, hogy megbizonyosodj arról, hogy nem fog megőrülni.
• A feladatnak elfogadhatónak kell lennie: vagy le tud futtatni teszteket, vagy le tud futtatni lint-et, vagy össze tudja hasonlítani a kimeneti fájlokat.
• Meg kell tanulnod megállni: ha látod, hogy körbe-körbe kezd járni, okosabb megállni, mint tovább égetni a pénzt.
• Olcsó modellekkel végezd a durva munkát, drága modellekkel a kritikus munkát: a költség az üzemeltetés eredménye, nem a könyörgésé.Projekt címe: https://github.com/subsy/ralph-tui