Endelig er den her! Ralph TUI, visualisering af Ralph Loop

Jeg har tidligere skrevet en tutorial om ralph-loop, og mange venner har givet enslydende feedback efter at have kørt den: Det er fedt, Claude Code kan endelig køre i lang tid. Men nogle gange observerer du, at den tilsyneladende ikke bevæger sig, og du bliver uundgåeligt usikker: "Er den i gang med at arbejde, eller spinder den bare rundt i ring?"

Dette er grunden til, at jeg for nylig har rodet med ralph-tui.

ralph-tui er ikke tvunget til at binde sig til Claude Code, den arver og udvikler essensen af ralph loop og visualiserer opgaveudførelsen og processen, hvilket i høj grad reducerer barrieren for at få store modeller til at arbejde i lang tid. Du kan sagtens tilslutte andre agenter, andre modeller, indenlandske, billige, dem du har råd til at køre i lang tid. Med ralph-tui er det for os almindelige mennesker lige så vigtigt som at skifte fra manuelt gear til automatgear med fartpilot.

Hvad er det egentlig?

Du kan tænke på ralph-tui som en "AI coding agents loop-orkestrator", men den er ikke tilfreds med bare at "kunne køre", den er mere interesseret i "du kan se, du kan kontrollere, du kan gendanne".

Dens grundlæggende arbejdsmetode er meget simpel:

• Du giver den en masse opgaver (fra PRD eller fra et andet opgavesystem)
• Den vælger den med den højeste prioritet
• Samler prompten
• Starter agenten for at udføre
• Vurderer om opgaven er fuldført
• Skriver status
• Fortsætter til næste runde

Vigtigst af alt: Du kan se alt dette i terminalen, og du kan stoppe og overtage når som helst. Den officielle positionering er også meget ligefrem: en agent loop orchestrator med interaktiv TUI, der understøtter TUI / headless / remote.

Hvorfor siger jeg, at den er mere velegnet til "langvarig kørsel"?

Det største problem med at køre et script i en loop er ikke, at det ikke kan køre, men at du ikke ved, hvor langt det er kommet.

Du ser logfilerne rulle hurtigt, og ventilatoren kører også glad, men du er usikker:

• Er den ved at rette den samme fejl gentagne gange?
• Er den ved at ændre den samme kode og derefter ændre den tilbage?
• Er den allerede færdig, men har bare ikke afsluttet?
• Er den gået i stå i en eller anden test og kører i en uendelig loop?

ralph-tui's løsning er meget "ingeniørmæssig":

• Har et sessionskoncept, status gemmes på disken (.ralph-tui/session.json)
• Kan gendannes efter et nedbrud (crash recovery)
• Har en låsemekanisme for at undgå, at du åbner flere instanser og roder kataloget til
• Kan også køres headless i CI, eller endda remote med en listener åben på en fjernserver, og den lokale TUI forbinder til den

Kort sagt: Det er mere som "du styrer en arbejder, der kan kode", end "du overvåger et script, der går amok".

Hvordan installeres den

ralph-tui er et Bun/TypeScript-økosystem, så det er ret nemt at installere. Den officielle side har også en installationsvejledning.

Kontroller først, at du har bun på din maskine:

bun --versionInstaller derefter ralph-tui (jeg giver her en typisk installation, se den officielle installationsside for detaljer):

bun add -g ralph-tuiKontroller installationen:

ralph-tui --helpHvis du er Node-bruger og ikke vil røre bun, er det også fint:

npm i -g ralph-tui

Lad være med at lave store ting endnu, kør en minimal lukket loop

Jeg anbefaler, at du ikke starter med at "omstrukturere hele repoet" første gang, du bruger den. Gør kun én ting: Få den til at køre en lille, acceptabel opgave igennem.

Initialisering

Åbn et vilkårligt katalog:

mkdir ralph-tui-demo && cd ralph-tui-demo ralph-tui setupDette vil starte en interaktiv guide, som grundlæggende er "installer ralph-tui i dette lager", den vil:

• Automatisk registrering af hvilke agenter der er installeret på din maskine (f.eks. Claude Code, OpenCode osv.)
• Generering af en konfigurationsfil i projektet: .ralph-tui/config.toml
• Installation af PRD-generering/opgavekonverteringsrelaterede skills (så du ikke behøver at gøre det manuelt senere)

Jeg anbefaler personligt: Vær ikke doven første gang, setup skal køres igennem.

Generering af projekt PRD

Når setup er kørt, er næste trin det mest centrale i den officielle tutorial, og også det mest velegnede til at skrive en demo til en offentlig konto: create-prd.

ralph-tui create-prd --chat kommandoen vil starte en dialogbaseret proces, hvor den vil stille dig spørgsmål som en produktchef om dine krav, mål, grænsebetingelser og acceptkriterier. Når den er færdig med at spørge, vil den direkte udskrive to ting i projektet (dette er det vigtigste):

• En PRD markdown-fil: ./tasks/prd-feature.md
• En eksekverbar opgavefil: ./prd.json

På dette tidspunkt er du virkelig kommet ind i ralph-tui's "standard lukkede kredsløb":

Krav (PRD) → Opgave (prd.json) → Udførelse (run)

Kør det

Med prd.json er det naturligt at køre:

ralph-tui run --prd ./prd.json Du vil se TUI starte og begynde at loope: vælg opgave → udfør → vurder fuldførelse → skriv status → afslut eller næste runde.

Første gang du kører det, anbefaler jeg kraftigt at tilføje en iterationsgrænse, og først lukke det inde i et bur:

ralph-tui run --prd ./prd.json --iterations 5 Når det er kørt, kan du se ændringerne, køre tests og se om PRD og opgaver er som forventet. Bekræft at denne kæde er åben, før du frigiver iterationerne og går videre til headless/remote, det er den pålidelige rytme.

På dette tidspunkt kan du grundlæggende bekræfte: Dette loop kører virkelig.

Hvordan vælger man model/Agent? Ærlighed om at spare penge

Jeg ved, at mange mennesker er mest bekymrede over: "Kan jeg undgå at bruge Claude Code? Kan jeg bruge billigere modeller?"

Svaret er: Ja.

ralph-tui understøtter dig selv i at specificere agent og model (der er eksempler i den officielle run-dokumentation).

For eksempel ved hjælp af Claude Opus:

ralph-tui run --prd ./prd.json --agent claude --model opus Men ærligt talt, ville jeg ikke bruge Opus til at lave "supplerende tests, rette lint" slags arbejde, det er for dyrt. Min vane er at opdele det i lag:

• Billige modeller: Kør masser af gentagne opgaver (supplerende tests, supplerende kommentarer, ret formatering, tilføj grænser)
• Dyrt modeller: Kun til stede ved vigtige knudepunkter (arkitekturjusteringer, vanskelige fejl, kerne logik)

Hvis du er en almindelig udvikler, er denne tankegang endnu vigtigere. Fordi du ikke har et stort virksomhedsbudget, skal du gøre omkostningerne kontrollerbare for at kunne køre det i lang tid.

Vil du have det endnu bedre? Overlad også "skriv PRD" til agenten

ralph-tui har et design, jeg virkelig kan lide: det understøtter skills (dybest set et sæt agent-plugins).

Den officielle måde at installere det på er ved hjælp af add-skill:

bunx add-skill subsy/ralph-tui --all Eller installer det til en bestemt agent, f.eks. claude-code:

bunx add-skill subsy/ralph-tui -a claude-code -g -y Når du er færdig med at installere det, kan du bruge slash-kommandoer i agent-sessionen:

/ralph-tui-prd /ralph-tui-create-json /ralph-tui-create-beads Dette er meget ligesom at installere et plugin i IDE, bortset fra at dette plugin er til agenten. Dens betydning er at reducere tiden for "manuel flytning af krav", hvilket gør krav → opgave → udførelse mere som en samlebånd.

Hvornår skal man bruge det? Hvornår skal man ikke bruge det?Jeg er ikke så vild med den der fortælling om, at "AI kan klare alt", det er nemt at blive vildledt. Værktøjer er bare værktøjer, de er kun værdifulde i de rigtige situationer.

Scenarier, hvor ralph-tui er velegnet

Du har en masse af denne slags opgaver:

• Supplerende test (især gamle projekter)
• Ret lint / format
• Småtrinsrefaktorering (saml gentagen kode)
• Tilføj typer i batch, suppler grænser
• Opdel krav og skub dem langsomt fremad i opgavekøen

Disse opgaver har én ting til fælles: Mange opgaver, høj grad af gentagelse, kan accepteres, kan fremmes iterativt.

Scenarier, hvor det ikke er egnet at tvinge ralph-tui igennem

Du skal lave denne slags:

• Engangs stor refaktorering, uklare acceptkriterier
• Selve kravene er vage, afhængige af din implicitte viden
• Kræver en masse kommunikation/bekræftelse på tværs af teams
• Kræver, at du træffer produktbeslutninger

I denne type opgaver vil agent loop kun forstørre forvirringen.

Hvad er forskellen mellem den og ralph-loop (ralph-claude-code)?

ralph-claude-code er mere som en "Claude Code autopilot-plugin": scriptet starter den, kører loopet, udgangsdetektion, hastighedsbegrænsning og afbrydere er alle dækket for dig. Du vil have "hurtig", og den er hurtig.

ralph-tui er mere som en "agent loop engineering konsol": den er ikke fastlåst til en bestemt model eller et bestemt opgavesystem. Den forsøger at løse de tekniske problemer med "langvarig kørsel, observerbarhed, kontrol, genoprettelighed og fjernbetjening".

Så du spørger mig, hvordan man vælger?

• Du er Claude Code-bruger og vil hurtigt få den til at køre → ralph-claude-code
• Du vil tilslutte forskellige modeller, spare penge og administrere loopet som en tjeneste → ralph-tui

Til sidst: Lad den ikke behandle dit lager som et laboratorium

Jeg har et par jernregler for at køre agent loop, jeg skriver dem her, så du kan følge dem, og sandsynligheden for at fejle vil være meget mindre:

• Kør på en branch, lad være med at lege vildt på main.
• Første gang du kører, skal du tilføje --iterations for at bekræfte, at den ikke går amok.
• Opgaver skal kunne accepteres: enten kan de køre tests, eller de kan køre lint, eller de kan sammenligne outputfiler.
• Du skal lære at stoppe: det er klogere at pause end at fortsætte med at brænde penge af, når du ser den begynde at køre i ring.
• Billige modeller laver det grove arbejde, dyre modeller laver det vigtige arbejde: omkostningerne kommer fra driften, ikke fra bønner.Projektadresse: https://github.com/subsy/ralph-tui