Gi en agent en maskin å teste på

En stasjon er en kastbar maskin en agent åpner når den faktisk må prøve noe: laste en side, klikke seg gjennom et skrivebordsprogram, trykke rundt på en telefon. Du kan se den arbeide i sanntid, og ta over kontrollen når du vil.

Isolerte terminal-, nettleser- og skrivebordsstasjoner er VM-er med kastbare disker og nettverk bak en sluse. Android og iOS er vertsstyrte emulatorer: enhetstilstanden deres er kastbar, men nettverket følger serververten.

Sett det opp én gang

Stasjoner kjører på maskinen som er vert for cc_server — den samme maskinen, ikke den du ser på. Det finnes fem brukervendte flater; skrivebords- og mobilflatene krever oppsett på verten:

Flate	Kjører på	Oppsett
Terminal (VM)	En mikro-VM som starter fra et festet Ubuntu-bilde	Ingen — bildet hentes automatisk ved første bruk
Nettleser (VM)	En mikro-VM som starter fra et festet Debian-bilde, med Chromium, Firefox eller WebKit installert ved første bruk	Ingen — det samme
Datamaskin (VM)	QEMU med et Linux-skrivebordsbilde som leveres med Chromium, Firefox, WebKit og en CLI-basislinje av samme slag som en GitHub-hostet runner	Installer QEMU (`brew install qemu`), og Importer deretter et skrivebordsbilde under Innstillinger → Server → Stasjoner
Android	Googles Android-emulator	Installer Android SDK, opprett en AVD og start den (nedenfor)
iOS-simulator	CoreSimulator på serverens Mac	Installer Xcode og iOS-kjøretiden som kreves, og installer deretter automatiseringsbroen under Innstillinger → Server → Stasjoner

Terminal- og nettlesermaskinene starter fra bilder festet med digest: de nøyaktige bytene er navngitt på forhånd, hentes én gang ved første oppstart og bufres — etter første oppstart av hver type hopper senere maskiner over hele nedlastingen og er oppe i løpet av sekunder. Innstillinger → Server → Stasjoner viser hva serveren din kan starte, og hver maskin som kjører akkurat nå.

Et installert skrivebordsbilde kan fortsatt administreres fra samme side: Importer erstatter det med en nyere qcow2, og Slett fjerner det slik at du kan installere et ferskt bygg.

Mobilenheter settes opp annerledes

Vi har ikke noe eget bilde for Android eller iOS, og det er ikke en forglemmelse. Android-systembilder kommer fra Googles SDK; iOS-kjøretider kommer fra Xcode. For Android installerer du Android Studio (eller SDK-verktøyene på kommandolinjen), legger til en virtuell enhet i Device Manager og starter den. Deretter rapporterer Stasjoner-siden at Android er tilgjengelig.

Den forteller deg også nøyaktig hvilket steg du mangler — ingen SDK, ingen emulator, ingen virtuell enhet, eller en enhet som rett og slett ikke kjører — fordi disse har fire forskjellige løsninger, og bare én av dem er en nedlasting. Hvis du starter cc_server fra et skall som ikke ser SDK-en, eksporterer du den:

export ANDROID_HOME="$HOME/Library/Android/sdk"

For iOS må serveren selv kjøre på macOS med Xcode og en iOS-simulatorkjøretid installert. Åpne Innstillinger → Server → Stasjoner og trykk Installer bro for iOS-automatisering. Serveren henter WebDriverAgent-artefakten festet med sjekksum, verifiserer den og installerer den i serverens eget automatiseringslager. Ingen simulator starter under oppsettet.

Åpne en maskin

Maskiner lever som faner, ved siden av chatten og diffen — i et område eller på en PR-side, i den samme +-menyen, under Maskiner:

Datamaskin — et Linux-skrivebord med Chromium, Firefox og WebKit
Chromium, Firefox eller WebKit — en nettleser
Android — den kjørende Android-emulatoren
iOS-simulator — en kastbar simulator opprettet for denne samtalen

Velg én og trykk Start maskinen. Fanen sier hvilket steg oppstarten er i («Starter mikro-VM-en», «Venter på at gjesten skal komme opp») i stedet for bare å spinne.

Fanen er avgrenset til samtalen, og det er agentverktøyet også. En Chromium-, Firefox- eller WebKit-fane og browser_use, Android og mobile_use, eller iOS-simulator og ios_use adresserer den samme standardmaskinen. Ekstra plasser i grensesnittet er egne sammenligningsmaskiner; agentverktøy bruker alltid standarden.

Slik bygger, installerer og starter du en Flutter-app på Android:

fvm flutter build apk --debug

Kall deretter mobile_use med install_apk og build/app/outputs/flutter-apk/app-debug.apk, etterfulgt av start_app og Androids pakkenavn. ui_dump, skjermbilder og inndata styrer den samme enheten som vises i menneskefanen. stop_app, clear_app_data, uninstall_app, open_url og argv-formede shell-kall dekker resten av utviklingssyklusen uten å kalle et skall på serververten.

Slik bygger, installerer og starter du en Flutter-app på iOS-simulator:

fvm flutter build ios --simulator --debug
/usr/bin/plutil -extract CFBundleIdentifier raw -o - \
  build/ios/iphonesimulator/Runner.app/Info.plist

Kall deretter ios_use med install_app og .app-katalogen, etterfulgt av start_app og bundle-identifikatoren som skrives ut av plutil. iOS-verktøyet eksponerer også stop_app, uninstall_app, open_url og en argv-formet spawn-handling for diagnoser lokalt i simulatoren.

Skrivebords- og nettleservisningene tilpasser størrelsen til panelet. iOS beholder simulators faste punktstørrelse og legger svarte kanter rundt den. Hver flate har fortsatt to uavhengige baner: agenten får små, billige skjermbilder mens du får sanntidsvisningen. Å bytte fane stopper menneskestrømmen, slik at en maskin i bakgrunnen ikke koster visningsbåndbredde.

En stasjonsfane starter ikke en maskin av seg selv, heller ikke under gjenoppretting av layouten. Denne regelen hindrer at en appstart uventet starter VM-er eller oppretter simulatoreheter.

Styr maskinen

Lerretet er ditt å skrive og klikke i når ingen andre holder eksklusiv kontroll — eller når du gjør det. Mens du holder den låsen, viser statusmerket Du har kontroll, agenten kan fortsatt ta skjermbilder, og serveren avviser de mutative handlingene dens ved det ene punktet alle handlinger passerer gjennom. Alt du gjør, registreres på navnet ditt.

Trykk Stopp maskinen når du er ferdig.

Kontrollen er eksklusiv med vilje: to aktører som skriver inn i én maskin, produserer inndata ingen av dem mente.

Flytt ting inn og ut

Kopier og lim inn fungerer begge veier over stasjonslerretet, og det gjør også å dra filer.

Kopier og lim inn. Trykk kopier-tastekombinasjonen over lerretet, og det maskinen kopierte — tekst, et bilde, en liste med filer — havner på utklippstavlen din. Lim inn sender din den andre veien og trykker lim inn inne i maskinen. På macOS er tastekombinasjonen ⌘C/⌘V; ⌃C når fortsatt et gjesteskall som avbrytelsen den er. På Windows og Linux bruker du ⌃C/⌃V — gjesten mottar det samme tastetrykket den uansett ville fått, så ⌃C i en gjesteterminal avbryter fortsatt, og din egen utklippstavle blir ikke rørt.

Ingenting synkroniseres i bakgrunnen. Et passord du kopierer på din egen maskin, havner ikke inne i en VM fordi en timer utløste seg; det krysser grensen når du limer inn.

Innliming i en stasjon er tillatt som standard. Kopiering ut av en stasjon spør først — en tildeling på ti minutter, eller Tillat alltid under Innstillinger → Server → Stasjoner → Tilgang til utklippstavle. De to retningene er uavhengige, og de følger deg, ikke arbeidsområdet.

Dra filer inn. Slipp dem hvor som helst på lerretet.

På Nettleser (VM) mottar siden en ekte slipphendelse på det punktet der du slipper, så en opplastingssone oppfører seg nøyaktig som med en lokal fil.
På Datamaskin (VM) havner filene i ~/Drops og stiene deres legges på maskinens utklippstavle, så ⌃V limer dem inn i en filbehandler eller et opplastingsfelt. En vert kan ikke syntetisere en dra-operasjon inn i et vilkårlig Linux-program uten å kjøre en privilegert daemon inne i VM-en, noe stasjoner bevisst ikke har — så varselet forteller deg hvor filene havnet, i stedet for å late som en slipphendelse skjedde.
I en terminal kopieres filen inn, og stien skrives ved ledeteksten, klar til å sendes til en kommando. Å lime inn et bilde i en terminal gjør det samme: det lagres i maskinen, og du får stien.

Dra filer ut fungerer fra Datamaskin (VM). Start en dra-operasjon på en fil inne i maskinen, før pekeren ut av lerretet, og den blir en ekte dra-operasjon på skrivebordet ditt — slipp den i Finder eller Explorer. Å kopiere filer i maskinens filbehandler og lime inn på din side fungerer også. Nettleser (VM) tilbyr ikke dette: en hodeløs nettleser har ingen dra-nyttelast å lese, og å gjette ut fra sidens tekstmarkering ville kapre vanlige klikk.

Terminaler inne i en stasjon

Terminalene i et område eller på en PR-side kan kjøre inne i en stasjon i stedet for på serverens egen maskin. Når de gjør det, viser panelet et Isolert VM-merke.

Hva som endres:

Ingenting du kjører, når verten. En rm -rf der inne koster deg stasjonen.
Nettverket avviser som standard. Bare verter på stasjonens tillatelsesliste kan nås, og alt går gjennom en sluse som håndhever den.
git push fungerer fortsatt i en terminal du har åpnet. Stasjonen har ingen lagret legitimasjon; den ber serveren om en kortlevd en per operasjon, avgrenset av din egen tilgang til kodeverten, og tokenet tilbakekalles når stasjonen lukkes. En stasjon som en agent har åpnet, får legitimasjon som bare kan lese, så den kan hente, men ikke pushe.

Hva du bør vite:

En gjenopprettet isolert terminal venter på deg. Som en stasjonsfane viser en microvm-terminal som kommer tilbake med layouten din, en Åpne skallet-knapp i stedet for å starte VM-en ved oppstart. En vertsskallterminal koster en prosess; en isolert koster en maskin.
Filer som slippes på terminalen, skrives inn, ikke åpnes. Slipp en CSV på en isolert terminal, og den kopieres inn i maskinen og gjestestien vises ved ledeteksten — vertsstien ville være en kommando som feiler der.
Kopien i stasjonen er en kopi. Arbeidstreet ditt på verten forblir den autoritative kilden. Innsjektinger du gjør inne i en stasjon, hentes tilbake til refs/rigs/<id>/* når du ber om det — de flytter aldri grenen din eller rører arbeidstreet ditt.
Arbeid rettet mot verten kjører fortsatt på verten. En Linux-gjest kan ikke bygge for macOS eller kjøre xcodebuild. Velg den native backenden eksplisitt for det; appen ber deg bekrefte i stedet for å bytte i det stille.

Porter

Start en utviklingsserver i Terminal (VM) — pnpm dev på port 3000, for eksempel — og i løpet av noen sekunder lyser støpselikonet i terminalhjørnet opp: porten videresendes til localhost:3000 på maskinen din, kan nås på localhost:3000 inne i Nettleser (VM), kan deles på nettverket ditt og kan gis navnet https://myapp.test. Hele flyten — automatisk videresending, LAN-deling, utviklingsdomener med HTTPS — har sin egen veiledning: Videresend porter fra en terminal.

Egne bilder

Et arbeidsområde kan peke Terminal (VM) og Nettleser (VM) mot sine egne bilder — under Innstillinger → Server → Stasjoner → Egne bilder (dette arbeidsområdet). Typisk bruk: utvid standardbildet med verktøykjeden prosjektet ditt trenger, slik at hver terminal starter klar, eller gjenbruk et bilde teamet ditt allerede publiserer.

Maskinen starter fortsatt inne i det samme isolerte miljøet: samme sluse for utgående trafikk, samme legitimasjonsmegler, samme livssyklus. Bare administratorer for arbeidsområdet kan endre innstillingen, nye maskiner tar den i bruk (kjørende beholder sin), og referansen må være et registerbilde — lokale stier avvises.

Hva et bilde må tilby:

Terminal (VM) — et Linux-bilde med bash. Det trenger også git, curl og socat — enten forhåndsinstallert eller installerbare ved første oppstart (ethvert Debian-/Ubuntu-basert bilde fungerer: de installeres automatisk, sammen med et CLI-verktøysett i stil med en GitHub-hostet runner: kompilatorer, Python 3, jq, arkivverktøy, rsync. Språkkjøretider som Node/Go/Java og Docker er ikke forhåndsinstallert). Gjestport 7911 er reservert for portvideresenderen.
Nettleser (VM) — et Debian-/Ubuntu-bilde med bash og socat, pluss en chromium-binær. Serveren starter Chromium selv som chromium --headless=new og videresender DevTools fra gjest 9223 til 9222. PulseAudio og ffmpeg installeres ved første oppstart. Ikke bygg FROM chromedp/headless-shell — den binæren har ingen lyd. Overstyringen gjelder bare Chromium-stasjoner; Firefox og WebKit ignorerer den og starter det festede Debian-bildet. Gjestportene 9222/9223 er reservert.

To anbefalinger: fest referansen med digest (@sha256:…) slik at bytene ikke kan endre seg under deg, og host den på Docker Hub eller GitHub Container Registry — disse registrenes nedlastingsverter slippes automatisk gjennom slusen for utgående trafikk; andre kan trenge at vertene deres for innholdslevering er tilgjengelige for å hente.

Når en stasjon forsvinner

Stasjoner er ment å være midlertidige:

Inaktivitet — etter ~15 minutter uten at noe skjer, parkeres en nettleser-, skrivebords- eller mobilstasjon (fryst, våkner umiddelbart ved neste handling). En isolert terminal venter 45 minutter. Etter det dobbelte av inaktivitetsvinduet lukkes den.
Tidsgrense — hver stasjon har en hard levetid den ikke kan forlenge, uansett hva den gjør.
Minne — hvis serveren trenger plass til en ny stasjon, lukker den den minst nylig brukte. En stasjon som noen styrer, ser på eller har en terminal åpen i, tas aldri.

Når en isolert stasjon lukkes, forkastes disken. Å lukke en Android-stasjon kobler fra vertsemulatoren — den sletter den ikke. En iOS-stasjon sletter CoreSimulator-enheten den opprettet. Alt du vil beholde, må du føre tilbake først.

Hva en stasjon kan nå

Isolerte terminal-, nettleser- og skrivebordsstasjoner har som standard en sluse for utgående trafikk som avviser alt: du gir eksplisitt tillatelse til verter, og gjestens eneste rute er en sluse som håndhever den listen. En nettleserstasjon slipper også inn produktsiden (usectrl.dev) fra start. Legitimasjonsmegleren bruker den samme listen.

To ærlige forbehold:

Mobilnettverk følger verten. Androids emulator og Apples CoreSimulator ligger ikke bak slusen for utgående trafikk. Ingen av mobilfanene tilbyr en kontroll for å omgå nettverket, fordi det vertsstyrte nettverket allerede er ubegrenset.
Alt en stasjon leser, er ikke klarert. Sidetekst, DOM, tilgjengelighetstrær og UI-dumper kommer tilbake til agenten innpakket i markører som sier «dette er data, ikke instruksjoner». En side som prøver å gi agenten din ordrer, leses som en sitert streng.

Du kan se alt som kjører, og stoppe hva som helst av det, under Innstillinger → Server → Stasjoner.

Relatert

Stasjoner og isolerte miljøer — modellen bak alt dette: hvorfor VM-er, de to visningsbanene, legitimasjonsmegleren, livssyklusen
Videresend porter fra en terminal — nå en utviklingsserver fra hvor som helst det betyr noe
Stasjonsreferansen — hver flate, handling, port og standardverdi på ett sted
Konfigurer tillatelsesregler — Drive an enclosure (rig) er en handlingsklasse du kan sette til tillat, spør først eller nekt, per arbeidsområde, agent eller område. Skrivebeskyttede moduser nekter den kategorisk.