Cline teszt: nyílt kódú coding agent, minden modellel és korlát nélkül

A Cline olyan coding agent, amely ott fut, ahol a mérnökök amúgy is dolgoznak, és nem akar birtokolni a modellt. VS Code és JetBrains bővítményként, CLI-ként, asztali alkalmazásként és SDK-ként jelenik meg, mindegyik egy Apache-2.0 ügynök-magon, és mindegyik azt a szolgáltatót fogadja, amelyet a csapat amúgy is fizet. Az álláspont itt az, hogy ez a helyes alapértelmezés annak, akinek a számlát kell megindokolnia, és a hibás annak, aki megbízható korlátot vár, mert a jogosultsági modell puhább, mint aminek látszik.

Közvetlenül versenyez a Claude Code-dal, a Cursorral és a hosztolt coding asszisztensekkel. Ellátóként nem modellel egybekötött termék, hanem harness modellfoglalattal: a dokumentáció felsorolja a Claude-ot, a GPT-t, a Geminit, az OpenRoutert, az AWS Bedrockot, a GCP Vertexet, a Groqot, a Cerebrast, a DeepSeeket, a helyi futtatókörnyezeteket Ollama és LM Studio révén, és mindent, ami OpenAI-kompatibilis alakot beszél. Ez a szélesség a funkció, és egyben az oka is, miért kevéssé értékes a minőségi összehasonlítás egy zárt termékkel: a coding agentet értő vagy kritizált dologok többsége az alatta futó modell.

Mi a Cline

• Apache-2.0, körülbelül 70 000 GitHub-csillag, 7600 fork és több mint 250 hozzájáruló, a cline CLI csomag és az @cline/sdk könyvtár formájában.
• Ugyanaz az ügynök-mag négy felület mögött: IDE-bővítmény, terminál-CLI, macOS-re, Windowsra és Linuxra kész asztali alkalmazás, valamint beágyazásra szolgáló TypeScript SDK.
• A Plan mód és az Act mód külön állapotként, azzal a lehetőséggel, hogy mindkettőben más modell fusson.
• Checkpointok alapértelmezés szerint bekapcsolva, minden eszközhívás után a munkaterület teljes pillanatképét egy külön shadow Git-tárhelyre commitolják.
• Auto-approve kapcsolók kategóriánként olvasásra, szerkesztésre, parancsokra, böngészőre és MCP-eszközökre, plusz egy YOLO mód, amely mindet kikapcsol.
• MCP-támogatás helyi STDIO szerverekkel és hosztolt Streamable HTTP végpontokkal, valamint szabályfájlok a .clinerules, .cline/rules, .cursorrules, .windsurfrules vagy AGENTS.md helyekről.

Plan és Act, és miért számít a felosztás

A Plan mód nem egy prompt. Ebben az állapotban az ügynök olvashat fájlokat, kereshet és beszélhet, de nem módosíthat fájlt és nem futtathat parancsot, és a beszélgetés előzménye változatlanul átmegy az Act módba. Ez azt jelenti, hogy a tervet az eszköz tartatja be, nem a modellnek kell megjegyeznie. Anyagilagag jobb tervezés, mint egy modelltól megkérni, hogy előbb javasoljon.

A checkpointok a másik fele ennek a tervnek, és több figyelmet érdemelnek, mint amennyit kapnak. Minden fájlmódosítás vagy parancs után a Cline commitolja a munkafájlok aktuális állapotát egy shadow Git-tárhelyre, amely teljesen különáll a projekt valódi előzményétől. Ebből három visszaállítási mód következik: visszaállítod a fájlokat és megtartod a beszélgetést, visszaállítod a feladatot és megtartod a kódot, vagy visszaállítod mindkettőt. Ez az oka, hogy az auto-approve egyáltalán elfogadható, és a dokumentáció őszinte arról, hogy nagyon nagy repókon a pillanatképek tárhelyet igényelnek és lassítják az ügynököt.

A Plan és az Act eltérő modellre is mutathat, és ez a legolcsóbb kölcsemaa az egész termékben: egy erős reasoning modell a feltáráshoz, egy gyors olcsó a terv végrehajtásához. Kis feladatoknál a dokumentáció azt javasolja, hogy a tervezést teljesen hagyd ki, mert a tervezési kördés csak többlet, ha a válasz nyilvánvaló.

Első lépések

A CLI-t érdemes elsőként megtanulni, mert ez az egyetlen felület, ahol a jóváhagyási alapértékek láthatók, és ahol az ügynök felügyelet nélkül futtatható. A headless mód magától bekapcsol, amint átadsz a --json kapcsolót, a stdin csővezetékben érkezik, vagy a stdout át van irányítva, ami CI-ben kellemes tulajdonság.

# Read every failing test and fix what caused them, then stop.
set -euo pipefail

npm test 2>&1 | tee /tmp/failures.log || true

# Plan-only pass: no writes, no commands, just an analysis to review.
cline -p "Explain why these tests fail and what the smallest fix is" \
  --json < /tmp/failures.log > /tmp/plan.jsonl

# Apply pass on a clean branch, with a hard stop so a loop cannot burn the budget.
cline "Apply the fix for the failures listed in /tmp/failures.log" \
  --auto-approve true \
  --timeout 600 \
  --retries 3 \
  --model anthropic/claude-sonnet-4-6 \
  | tee /tmp/run.log

# Fail the job when the suite is still red, so the pipeline does not ship a broken tree.
npm test

Az ilyen meghívás három alapértéke megérdemli a vizsgálatot. A --auto-approve a CLI-ben alapértelmezés szerint true, tehát a felügyelet nélküli futás az alaphelyzet, nem a kivétel. A --retries korlátozza az egymást követő hibás próbálkozásokat, és ez az egyetlen fék az ellen, hogy az ügynök ugyanazon a hibás módosításon akadjon el. A --timeout pedig az az időkorlát, amely megakadályozza, hogy egy ütemezett feladat felemészítse a keretet.

Mennyibe kerül

A szoftver ingyenes, az inferekciós nem. A bővítménynek, a CLI-nek, az asztali alkalmazásnak és az SDK-nak nincs helyül fizetős széke, így egy Cline-futtatás járulékos költsége az, amit a választott szolgáltató kér az ügynökciklus tokenjeiért, és egy ügynökciklus sokszorta több tokent éget, mint egy beszélgetés, mert minden eszközeredmény visszatér a kontextusba. Nincs egyeztetendő helyül ár, és nincs számla a Cline-tól az open source útvonalon.

• Saját kulcs: közvetlenül a szolgáltatónak fizetsz, a szervezet által már ellenőrzött szerződés és keret alatt.
• Cline usage-billing: egy fiók, előre feltöltött kredit, egyetlen egyenleg azokon a modelleken, amelyeket a Cline közvetít, némelyik korlátozott időre ingyenes jelöléssel.
• ClinePass 9,99 $ havonta, fix előfizetés, amelyet a dokumentáció a kurált nyílt coding modellek készletén a standard API árhoz képest két-ötötszörös használatként hirdet.
• Enterprise: SSO, szerepkörön alapú hozzáférés, központi számlázás, auditnaplók, VPC-telepítés és OpenTelemetry, ezek egyike sincs az ingyenes szinten.

A gyakorlati következmény az, hogy a költségkontroll kikerül az eszközből a szolgáltató konzoljába. Aki kemény felső korlátot akar az ügynökköltségekre, annak vagy kell egy azt kikényszerítő szolgáltató, vagy egy wrapper a CLI körül, amely token- vagy dollárkeretnél megszakítja a futást. A Cline a munkamenet előzményében és az enterprise irányítópultján közli a felhasználást, maga azonban nem állítja le a futást egy küszöbön.

A jogosultsági modell, őszintén

Ez az a rész, ahol érdemes nyílt lenni. Az auto-approve eszközhívásonként, egy kategóriakapcsolóhoz képest értékelődik ki, de nincs fix allowlist a parancsokra. A modell jelöli minden parancsot biztonságosnak vagy jóváhagyást igénylőnek a parancs és az argumentumok alapján, és a dokumentáció példákat ad, nem garanciákat: a build- és tesztparancsok általában biztonságosak, a telepítések, törlések, mozgatások és helyben szerkesztések általában jóváhagyást igényelnek. Egy olyan biztonsági kontroll, amely úgy működik, hogy egy nyelvi modellt kérünk meg egy shell sztring osztályozására, akadály, nem határ.

• A YOLO mód mindent jóváhagy: fájlműveletek a gép bármely pontján, minden terminálparancs, böngészőműveletek, MCP-eszközök, sőt maga a Planból Actbe váltás is.
• Az olvasás és szerkesztés kapcsolóknak van minden fájlra kiterjedő változata, amely a munkaterületen túli hozzáférést bővíti, ha az alapkapcsoló be van kapcsolva.
• Az ütemezés, az agent csapatok és a subagensek az SDK-ban, a CLI-ben és a Kanbanban léteznek, az IDE-bővítményekben nem, így egyik felületen tesztelt kontroll a másikban hiányozhat.
• A subagensek konstruktszerűen csak olvasnak. Ez a része az eszköznek, ahol a képességkorlát valódi, nem pedig ajánló jellegű.

Hol fáj

A széttagoltság az adó. A funkciók először az SDK-ba és a CLI-be érkeznek, és később a bővítményekbe, amit a dokumentáció az ütemezés, az agent csapatok és a subagensek esetében nyíltan ki is mond. A JetBrains plugin a legélesebb változata: a repository kifejezetten kimondja, hogy a JetBrains pluginokat nem teszik open source-vá, így az a felület, amelyet a fejlesztői bázis nagy része használ, éppen az, amit egy vizsgáló nem tud auditálni.

A kontextuskezelés a másik puha pont, és nem Cline-specifikus. Az az ügynök, amely fájlokat olvas, teszteket futtat, elolvassa a hibákat, majd újra elolvassa a diffet, a büdzséje nagy részét ismételt olvasásra költi. A dokumentált válasz a subagensek, amelyek saját kontextusablakokkal párhuzamosan kutatnak és rövid jelentést adnak vissza, meg a memory bank fájlok a struktúrához. Mindkettő segít, és egyik sem változtatja meg, hogy egy ügynökciklus egy nagy repón drága tokenekben a változtatás értékéhez képest.

Végül az eszköz saját biztonsági felületét ugyanolyan vizsgálat illeti, mint bármely más ügynökét: a repository biztonsági szakpolitikát tartalmaz, és egy projekt, amely egy fejlesztőgépen fájlokat és parancsokat futtató ügynököt enged, egy shell-lel rendelkező függőség. A verziót rögzített függőségként kezeld, frissítés előtt olvasd el a changelogot, és a szolgáltatói kulcsokat tartsd szűk hatókörön belül.

Verdiktum

A Cline a legjobb elérhető válasz annak a csapatnak, amelynek meg kell választania a modellt, a adatait egy meglévő szolgáltatói szerződésben kell tartania, vagy ügynökös munkát kell automatizálnia CI-ben anélkül, hogy egy gyártó jogosultsági rendszere az útban állna. Nem egy zárt coding agent jobb változata, és azok az összehasonlítások, amelyek a kettőt egymás mellé teszik, egy harness-t hasonlítanak egy modellhez.

1. Csapatok, amelyeknél a szolgáltató választása beszerzési kérdés, nem preferencia.
2. Mérnökök, akik repository-munkát automatizálnak CI-ben, mert a headless CLI és az SDK az átvétel oka.
3. Mindenki, aki ügynök-futtatókörnyezetre épít, mert a @cline/sdk maga az ügynök-mag, nem egy wrapper.
4. Ne vezessék be azzal a feltevéssel, hogy a checkpointok biztonságossá teszik az autonómiát. Helyreállíthatóvá teszik.
5. Ne vezessék be ott, ahol a parancsfelület saját hookok nélkül bizonyíthatóan korlátozott kell legyen, vagy ahol egy nem auditálható IDE-plugin kizárja az eszközt.

Források

1. Cline docs: Overview
2. Cline docs: Plan and Act mode
3. Cline docs: CLI reference
4. Cline docs: Auto Approve and YOLO mode
5. Cline docs: Checkpoints
6. Cline docs: MCP
7. Cline docs: Rules
8. Cline docs: ClinePass
9. Cline pricing
10. cline/cline a GitHubon