OpenHands: a nyílt forráskódú coding agent, amit üzemeltetsz

Az OpenHands MIT-licencű platform coding agentek futtatására: Agent Canvas webes felület, CLI, headless mód, Python SDK és REST API, amelyek olyan agenteket vezérelnek, amelyek fájlokat szerkesztenek és parancsokat futtatnak egy sandboxban. Ennek az elemzésnek az álláspontja: ez a legteljesebb nyílt forráskódú választás azoknak a csapatoknak, amelyek a végrehajtási környezetet szeretnék birtokolni, és viselkedése inkább aktívan épülő platformé, mint kész terméké.

Ott helyezkedik el, ahol a Claude Code, a Codex CLI, az Aider és a felhős agentek, a modell és a repository között — de más szerződéssel: a modell cserélhető függőség, nem beépített, és a futtatókörnyezet a te infrastruktúrád, nem egy szállítóé. Az 1.25.0-as verzió 2026. október 6-án jelent meg.

Mi ez

Az OpenHands egyetlen repositoryként indult, ma négy: az Agent Canvas felület és a helyi orchestráció az OpenHands/OpenHands-ban, a Python agent server és SDK a software-agent-sdk-ban, egy TypeScript-kliens és külön automatisálási szolgáltatás. Ezt a felosztást érdemes érteni az adoptálás előtt.

• MIT licenc, a felhős szolgáltatást külön értékesíti az All Hands AI.
• 1.25.0-as verzió, 2026. október 6-án, az agent server és az SDK 1.53.0-ra rögzítve.
• Felületek: Agent Canvas webes UI, interaktív CLI, headless mód CI-hez, Python SDK, valamint REST API a beszélgetésekhez, eseményekhez és sandboxokhoz.
• Modellfüggetlen LiteLLM-en keresztül, profillal a modell váltásához a beszélgetés közben, helyi szerverekkel, például Ollammal és vLLM-mel.
• Sandbox-szolgáltatók: Docker ajánlottan, konténerizáció nélküli process mód, valamint távoli sandboxok a felhős telepítésekhez.
• Az Agent Client Protocol támogatásával a Canvas a Claude Code-ot, a Codexet vagy a Gemini CLI-t is képes backendként vezérelni.
• Az automatizálások időzítésre, GitHub-eseményekre vagy webhookokra futnak, előre elkészített issue-to-PR és PR-review sablonokkal.

Lentebb az agent server workspace-et és eszközkészletet kínál bash-hez, fájlszerkesztéshez, böngészőhöz és interaktív terminálhoz, plusz skills-eket, hookokat és MCP-szervereket. A canvas és az automatisálási szolgáltatás ennek az API-nak a kliense, ezért ugyanaz a beszélgetés gombból, cron-bejegyzésből vagy webhookból is indulhat.

Hogyan működik

A beszélgetés típusozott események folyama: az agent javasol egy műveletet, a művelet a sandboxban fut, az observation visszajön, és a hurok addig tart, amíg a modell le nem áll. Az érdekes döntések a határon ülnek: mely fájlokat teszi ki a workspace, mely parancsokat engedélyezi a szabály, és melyik modellprofil fizet a következő körért.

Mivel a hurok az agent serverben él és nem a felületen, ugyanaz a beszélgetés indulhat canvasból, CLI-ből, időzítésből vagy webhookból, és szüneteltethető, folytatható, elágaztatható vagy trajektóriaként exportálható. Ez a projekt architekturális érve: egy végrehajtási út, több belépési pont.

Első lépések

A dokumentált út a Docker: egy konténer a localhoston teszi közzé a canvast, felfigyel egy projektkönyvtárra, amelyhez az agent hozzáférhet, és állapotát egy home könyvtár volume-ben tartja.

# one container for the canvas, the agent server and a mounted workspace
export PROJECTS_PATH="$HOME/projects"
mkdir -p "$PROJECTS_PATH" "$HOME/.openhands"

docker run -it --rm \
  -p 127.0.0.1:8000:8000 \
  -e AGENT_CANVAS_ALLOW_LAN_SESSION_KEY=true \
  -v "$HOME/.openhands:/home/openhands/.openhands" \
  -v "${PROJECTS_PATH}:/projects" \
  ghcr.io/openhands/agent-canvas:1.25.0

# open http://localhost:8000, add a model key, start a conversation

Az npm-es út, a npm install -g @openhands/agent-canvas Node.js 24-et és uv-t igényel, és az agent servert közvetlenül a gazdagépen futtatja; a README figyelmeztet, hogy ezzel az agent teljes fájlhozzáférést kap. A konténeres út az, amelyet érdemes csapatba átültetni.

Sandbox és a hibahatósugár

A sandbox a biztonsági határ, és a dokumentáció őszinte a lehetőségekről: a Docker ajánlott, a process módot gyorsnak, de nem biztonságosnak jelölik, a távoli sandboxok a felhős telepítéseket szolgálják. A sandbox az, ahol a parancsok futnak és a fájlok szerződnek, így a konfigurációja dönti el, hogy mit tehet egy prompt a géppel.

• A Docker sandbox az agent servert konténerben futtatja, és ez az ajánlott szolgáltató munkaállomáson.
• A process sandbox normál folyamatként futtatja, konténerizáció nélkül: gyorsabb, és csak megbízható munkára.
• OH_CONVERSATION_RUNTIME=docker minden beszélgetésnek saját konténert ad, saját workspace-szel és állapottal.
• A hookok blokkolhatják a veszélyes parancsokat és kikényszeríthetnek ellenőrzéseket, mielőtt az agent leáll; a megerősítési szabály pedig jóváhagyást kérhet a műveletekhez.
• A workspace-ek egy felfüggesztett projektkönyvtárra korlátozódnak, így az alap konténer nem látja a gazdagép fájlrendszerének többi részét.

Automatizálások

Az automatizálások azok, amelyek miatt érdemes ezt választani a terminál agent helyett. Feladat fut időzítésre vagy eseményre — GitHub-issue, pull request, webhook —, beszélgetést indít az agent servernek, és az eredmény kommentként, pull requestként vagy Slack-üzenetként érkezik vissza.

• A beépített sablonok lefedik az issue-to-PR-t, a PR-review-t, a repository figyelését és a Slack-csatorna monitort.
• Az időzítések és az eseményindítók egyetlen irányítópulton osztoznak, lefutási előzményekkel és be-/kikapcsolással automatizálásonként.
• Az automatizálások exportálhatók, importálhatók és Git-repozitóriummal szinkronizálhatók, így fájlként szerkeszthetők és kódként megoszthatók.
• Az integrációk lefedik a Slacket, a GitHubot, a Lineart, a Notiont és a webhookokat; az automatisálási szolgáltatás saját repositoryként és folyamatként fut.
• Beszélgetésenkénti konténerrel a párhuzamos automatizálások nem harcolnak ugyanazért a workspace-ért.

Itt jelenik meg a üzemeltetési költség is: egy folyamatosan futó canvas, egy automatisálási szolgáltatás és beszélgetésenkénti konténerek három plusz dolog a terminál agenthez képest. A projekt saját használati oldalai négy automatizálásból álló pipelinet írnak le az issue-tól a merge-ig — tisztességes cél és becsületes mennyiségű mechanika.

Ahol megakad

Először a gyengeségek: az OpenHands gyorsan mozog, és a felülete ezt mutatja. A V1-ben a futtatókról sandboxokra váltott a terminológia, miközben a konfiguráció még RUNTIME-t olvas, a felület ma Agent Canvas, nem a régi webes UI, a kód pedig négy repositoryra oszlik, külön versionált részekkel. Aki semmit nem rögzít, a jegyeiben találja a frissítési híreket.

• API-stabilitás: az SDK és az agent server függetlenül versionálódik a canvastól, a 1.25.0-as noteok pedig 1.53.0-ra rögzítik őket.
• Az eredményt a modell határozza meg: a projekt saját OpenHands Indexe kicsi modellkülönbségeket talál az issue-megoldásban, és jóval nagyobbakat az ötfeladatos keverékben.
• Az önálló üzemeltetésű automatizálásokhoz folyamatosan bekapcsolt gép kell, plusz hitelesítőkezelés a GitHubhoz, a Slackhez és a modellszolgáltatóhoz.
• A GUI, a CLI és a canvas átfed, így a csapatnak választania kell egy belépési pontot, nem örökölheti.

A nagy része fegyelemmel kezelhető, nem elkerülhető: a három verziószámot együtt rögzítsd, csapatonként tarts egy belépési pontot, és olvasd el a release noteot, mielőtt az incidenst olvasnál benne.

Az összehasonlítás valójában az infrastruktúráról szól. Az OpenHands sandboxolt, ütemezhető, modellfüggetlen végrehajtást vásárol, és folyamatos szolgáltatásokkal fizet érte; a terminál agentek az egyszerűséget vásárolják, és lemondanak a vezérlési síkról.

Ítélet

Az OpenHands akkor érdemes, ha a munka felügyelet nélkül zajlik: issue-kból pull request lesz, review fut minden merge-nél, figyelés kíséri a repót. Interaktív munkához egyetlen repositoryban a terminál agent plusz egy amúgy is megbízható sandbox kevesebb mechanikával ugyanazt az eredményt adja.

1. Használd, ha a modellnek cserélhető függőségnek kell maradnia: a profilok, a LiteLLM-szolgáltatók és a helyi szerverek első osztályúak, egyetlen szállító sem kritikus.
2. Használd önálló üzemeltetéssel, ha a végrehajtási környezet birtoklása a lényeg; az MIT licenc és az út a Dockeren keresztül támogatott, nem kerülőútvonal.
3. Indíts a konténeres telepítéssel, a projekteket egy könyvtárból told fel, és a process módot debugging kényelemként kezeld.
4. Ne stabil API miatt vedd át: a canvast, az agent servert és az SDK-t együtt rögzítsd, és a frissítés előtt olvasd el a release noteokat.
5. Ne kapcsolj be olyan automatizálást, amit nem tudsz ellenőrizni: minden időzítés egy hitelesítőkkel rendelkező agent, ezért a megerősítési szabályok és a hookok alapból bekapcsoltak legyenek.

Az OpenHands nem egy eszköz, amit egy projektre engedsz. Egy kis platform, amely az agentjeidet futtatja, és a platform az a rész, amit be kell állítanod.

Források

1. OpenHands README
2. OpenHands licenc (MIT)
3. Agent Canvas 1.25.0 release notes
4. OpenHands: sandbox áttekintés
5. OpenHands: gyorsindítás
6. OpenHands árak
7. Az OpenHands Index bemutatása