OpenCode CLI w praktyce: przepływy pracy, automatyzacja i pułapki

Interfejs wiersza poleceń OpenCode został zaprojektowany z myślą o skryptach, liniach CI oraz niekontrolowanych sesjach agentów. Ten artykuł to praktyczny przewodnik po jego codziennym wykorzystaniu.

W tle działania CLI znajduje się system modeli, narzędzi, uprawnień, agentów, umiejętności, poleceń, sesji, serwerów MCP oraz architektura klient/serwer. Agent może czytać i edytować pliki projektu, przeszukiwać repozytoria, wykonywać polecenia shell, wywoływać zewnętrzne narzędzia oraz delegować zadania do podagentów. To samo środowisko działa interaktywnie w TUI lub nieinteraktywnie ze skryptów.

W przypadku małych zadań wystarczy go zainstalować, podłączyć model i w ciągu kilku minut zacząć zadawać pytania. Przy poważnej pracy jakość doświadczenia zależy w dużej mierze od wyboru modelu, instrukcji repozytorium, granic uprawnień, zarządzania kontekstem oraz tego, jak agresywnie pozwalasz agentowi na działanie. Ten artykuł skupia się na tym drugim etapie, na poziomie wiersza poleceń: które przypadki użycia się opłacają, które automatyzowane przepływy pracy wytrzymują codzienne testy oraz jakie problemy pojawiają się, gdy nowość terminala opartego na AI przestaje działać. Artykuł ten jest częścią sekcji Narzędzia AI dla deweloperów na tej stronie.

Przedstawione tu obserwacje zostały zweryfikowane w odniesieniu do wersji OpenCode 1.18.9 i bieżącej dokumentacji w sierpniu 2026 roku. OpenCode zmienia się błyskawicznie, dlatego przykłady konfiguracji warto szybko zweryfikować w dokumentacji przed ich skopiowaniem do długoterminowej konfiguracji zespołowej. Jeśli jeszcze nie zainstalowałeś OpenCode, Szybki start OpenCode opisuje instalację, weryfikację i podłączanie dostawcy.

Czym faktycznie jest OpenCode: Środowisko agentowe, a nie czatbox

OpenCode to open-source’owy agent kodujący AI zaprojektowany wokół terminala. Uproszczony widok tego, co łączy w jedno, wygląda następująco:

Kluczowym elementem jest warstwa uprawnień między intencją modelu a działaniami, które OpenCode może podjąć. Świetny model z złymi uprawnieniami może być niebezpieczny. Słaby model z perfekcyjnymi uprawnieniami jest po prostu powolny i irytujący. Produktywne użycie OpenCode wymaga rozsądnego zarządzania obiema stronami równania.

To samo środowisko obsługuje dwa interfejsy: interaktywny TUI i nieinteraktywny wiersz poleceń. To właśnie to sprawia, że OpenCode jest skryptowalny w sposób, jaki nie jest możliwy przy czystym interfejsie czatu. Jeśli szukasz celowo minimalnego podejścia do tego samego pomysłu agenta terminalowego — cztery domyślne narzędzia, brak wbudowanej piaskownicy, wszystko inne przez rozszerzenia — recenzja Pi Coding Agent stanowi użyteczny kontrast.

Konfiguracja: Instalacja, połączenie i dlaczego niezależność dostawcy ma znaczenie

OpenCode instaluje się w jednym wierszu — oficjalnym skryptem instalacyjnym, npm lub Homebrewem — i startuje poleceniem opencode z katalogu repozytorium. Szybki start OpenCode opisuje pełną macierz instalacji (Arch, Windows, Docker), weryfikację i łączenie dostawcy (/connect i /models), dlatego ten artykuł nie powtarza tych kwestii.

Można korzystać z własnych usług modelowych OpenCode lub połączyć wspieranych zewnętrznych dostawców. OpenCode obecnie buduje dużą część swojego katalogu dostawców za pomocą Models.dev i obsługuje szeroki wachlarz konfiguracji modeli komercyjnych i lokalnych.

Niezależność od dostawcy to jedna z najbardziej użytecznych decyzji architektonicznych OpenCode. Twój przepływ pracy kodowania nie musi być trwale sprzężony z jednym producentem modeli: możesz używać jednego modelu do trudnych zadań architektonicznych, innego do tanich zadań implementacyjnych oraz modelu lokalnego do kodu, który nie powinien opuszczać Twojego środowiska.

Ta elastyczność jest realna, ale tworzy zmienną do zarządzania. Gdy OpenCode działa słabo, problemem może być szkielet (harness), podpowiedź (prompt), dostępny kontekst, wybrany model lub interakcja między wszystkimi czterema elementami.

Zainicjuj repozytorium plikiem AGENTS.md przed prośbą o kod

Jednym z pierwszych poleceń warty uruchomienia w nowym repozytorium jest:

/init

OpenCode analizuje projekt i tworzy plik AGENTS.md. Zatwierdź ten plik w repozytorium.

AGENTS.md to miejsce, w którym ograniczenia specyficzne dla repozytorium mogą stać się trwałym kontekstem dla każdej rozmowy — interaktywnej lub skryptowej — zamiast ręcznego powtarzania ich za każdym razem. Użyteczny plik jest wystarczająco krótki, aby pozostać istotnym, ale wystarczająco konkretny, aby zapobiec przewidywalnym błędom. Na przykład:

# Repository Instructions

## Architecture

- API handlers live under src/api.
- Business logic belongs under src/services.
- Database access belongs under src/repositories.
- Do not call database clients directly from HTTP handlers.

## Validation

After TypeScript changes run:

```bash
npm run typecheck
npm test
```

After frontend changes also run:

```bash
npm run lint
```

## Constraints

- Do not modify generated files.
- Do not change public API contracts without asking first.
- Do not create database migrations unless explicitly requested.
- Never run deployment commands.

To mniej ekscytujące niż instalowanie kolejnego serwera MCP, ale zazwyczaj daje większą wartość. Agenci kodujący zaskakująco często zawieszają się, ponieważ nie wiedzą, które ograniczenia są ważne. Krótki kontrakt repozytorium usuwa część tej niejednoznaczności przed pierwszym wywołaniem narzędzia.

Praca z wiersza poleceń za pomocą opencode run

Interfejs interaktywny przyciąga większość uwagi, ale tryb nieinteraktywny OpenCode znacząco rozszerza zakres użytecznych przepływów pracy:

opencode run "Explain the error handling strategy in this package"

Można korzystać z OpenCode ze skryptów shella, zadań CI, plików Make, menedżerów zadań lub lokalnej automatyzacji, bez ręcznego wejścia w TUI za każdym razem. Na przykład, recenzja różnic (diff) jako jednorazowe polecenie:

opencode run \
  "Review the current git diff for correctness and missing tests. Do not edit files."

Albo potok kontekstu bezpośrednio do uruchomienia:

git diff --name-only HEAD~1 |
  opencode run "Inspect the changed files and identify risky behavior changes."

W pliku Make to samo wywołanie staje się celem (targetem):

.PHONY: review
review:
	opencode run "Review the current git diff for correctness and missing tests. Do not edit files."

Ponieważ uruchomienie skryptowe nie ma człowieka przy konsoli, polityka uprawnień, którą skonfigurujesz, jest jedyną barierą między modelem a Twoim środowiskiem. Dlatego sekcja dotycząca uprawnień poniżej ma większe znaczenie dla automatyzacji niż dla użycia interaktywnego.

Ciekawym kierunkiem tutaj nie jest zastępowanie deterministycznych skryptów modelem LLM. Polega na wstawianiu rozumowania modelu w miejsca, gdzie tradycyjna logika shella staje się niezręczna, jednocześnie zachowując deterministyczną walidację wokół tych miejsc.

Najlepsze przypadki użycia CLI OpenCode

OpenCode może próbować rozwiązać prawie każde zadanie programistyczne, ale nie oznacza to, że każde zadanie powinno być delegowane w ten sam sposób. Najcenniejsze przepływy pracy mają zazwyczaj trzy cechy: pożądany wynik jest testowalny, istotny kontekst repozytorium można odkryć, a błędne zmiany są tanie do zbadania lub odwrócenia. Każda z poniższych podpowiedzi działa w TUI lub jako argument dla opencode run.

1. Eksploracja repozytorium

OpenCode jest świetny w odpowiadaniu na pytania, które wymagałyby otherwise sekwencji poleceń grep, wyszukiwania w edytorze, skoków między plikami i poleceń git log. Na przykład:

Explain how authentication works in this repository.

Trace a request from the HTTP middleware through token validation,
user loading, authorization, and the final handler.

Do not modify anything.

Dobry agent wyszuka punkty wejścia, podąży za referencjami, zbadza testy i zwróci coś bliższego przeglądowi architektury niż zwykłego wyszukiwania tekstowego. To jeden z najbezpieczniejszych sposobów na wprowadzenie OpenCode do istniejącej bazy kodu, ponieważ agent może dostarczać wartości bez pisania kodu.

2. Małe, dobrze ograniczone poprawki

Wąsko zakreślony bug jest bliski idealnemu zadaniu dla agenta kodującego. Na przykład:

The CLI exits with status 0 when config validation fails.

Find the code path responsible, add a regression test, implement
the smallest fix, and run the relevant tests.

Do not refactor unrelated code.

Kluczową frazą nie jest „popraw błąd”. To ograniczenia otaczające zadanie. OpenCode działa lepiej, gdy sukces można udowodnić testem, kompilatorem lub obserwowalnym poleceniem. Niejasne wymagania dają modelowi przestrzeń do tworzenia prawdopodobnie działającego kodu zamiast jednoznacznie poprawnego.

3. Generowanie testów po implementacji

Testy są użyteczną pracą dla agentów, ponieważ istniejąca implementacja daje OpenCode konkretny punkt odniesienia do rozumowania. Produktywna podpowiedź może wyglądać tak:

Review src/parser.ts and its existing tests.

Identify important edge cases that are currently uncovered.
Add tests only. Do not modify the implementation.

Run the parser test suite when finished.

Rozdzielenie generowania testów od implementacji jest ważne. Jeśli ten sam agent pisze zarówno funkcję, jak i testy w jednej nieograniczonej iteracji, może przypadkowo stworzyć testy, które walidują jego własną interpretację zamiast zamierzonego zachowania.

4. Mechaniczne refaktoryzacje

OpenCode jest bardzo dobry w powtarzalnych transformacjach, gdzie pożądany stan końcowy jest jasny. Przykłady obejmują:

• zastępowanie niedojrzałej (deprecated) API przez całe repozytorium;
• konwersję powtarzającego się kodu do wspólnego pomocnika;
• zmienianie nazwy pola konfiguracyjnego;
• migrację testów z jednego wzorca asercji na inny;
• aktualizowanie importów po przesunięciu pakietu;
• zastępowanie przestarzałej abstrakcji logowania.

Kompilator i testy repozytorium stają się pętlą sprzężenia zwrotnego dla agenta. Użytecznym wzorcem jest:

Replace uses of LegacyResult<T> with Result<T, AppError> in
packages/api only.

Preserve runtime behavior.

Work in small batches. After each batch run the package typecheck.
At the end run the package test suite and show me the final git diff
summary.

To często bywa bardziej niezawodne niż proszenie o całą migrację w jednym ogromnym kroku.

5. Recenzja kodu

OpenCode staje się znacznie bardziej użyteczny, gdy recenzja jest traktowana jako oddzielna rola agenta, a nie kolejna podpowiedź wysłana do tego samego kontekstu edycji. Możesz stworzyć agenta nastawionego na recenzję, który nie może edytować plików. Następnie daj mu instrukcje takie jak:

Review the current git diff.

Focus on:
- correctness;
- security;
- concurrency;
- missing tests;
- error handling;
- accidental API changes.

Do not summarize files that are unchanged.
Rank findings by severity.

Czytelnik (read-only reviewer) jest użyteczny nawet wtedy, gdy zmiany wykonał inny agent kodujący. Rozdzielenie jest cenne, ponieważ implementacja i krytyka to różne zadania: agent, który właśnie spędził kilka tysięcy tokenów na obronie jednego podejścia, często jest mniej sceptyczny wobec tego podejścia niż świeży recenzent.

Używaj trybu Plan i Build jako różnych trybów mentalnych

OpenCode dostarcza agentów głównych i podagentów, z wbudowanymi przepływami pracy, w tym zachowaniami nastawionymi na planowanie i implementację. Nawet gdy dokładna konfiguracja agentów zmienia się z czasem, koncepcyjne rozdzielenie pozostaje użyteczne.

Planowanie powinno odpowiadać na pytania takie jak:

• Które pliki są istotne?
• Jakie istniejące wzorce należy podążać?
• Co może się zepsuć?
• Jak zweryfikujemy zmianę?
• Czy żądana zmiana jest faktycznie lokalna?

Implementacja powinna następować tylko wtedy, gdy te pytania mają rozsądne odpowiedzi. Przy istotnych zadaniach wolę sekwencję podpowiedzi taką jak:

First investigate the request.

Do not edit files yet.

Return:
1. the relevant files;
2. the current behavior;
3. the proposed change;
4. risks;
5. the exact verification commands.

Ta sama sekwencja działa jako jednorazowe polecenie:

opencode run "First investigate the request. Do not edit files yet. Return: the relevant files; the current behavior; the proposed change; risks; the exact verification commands."

Następnie zbadaj plan przed zezwoleniem na edycje. To czuje się wolniej niż natychmiastowe polecanie agentowi „zaimplementuj to”, ale kosztowne porażki w agentowym kodowaniu zazwyczaj wynikają z błędnych założeń poczynionych przed pierwszą edycją.

To lekka, zadaniowa wersja tego samego instynktu, który stoi za rozwodem specyfikacyjnym (spec-driven development): uzgodnij plan, zanim agent zacznie edytować. Dla pracy obejmującej wiele plików, sesji lub współpracowników, spisana specyfikacja zwraca koszty nadwyżki w sposób, jakiego pojedyncza podpowiedź typu „najpierw zbadać” nie jest w stanie; porównanie GitHub Spec Kit vs Kiro vs Claude Code obejmuje strukturyzowane przepływy SDD, które idą dalej niż pojedyncza podpowiedź.

Podagenty są użyteczne, ale delegowanie nie jest darmowe

OpenCode może wywoływać specjalistyczne podagenty automatycznie lub przez wzmianki. Na przykład:

@general find where retry behavior is implemented

Można również zdefiniować dedykowane podagenty dla zadań takich jak recenzja bezpieczeństwa, analiza zależności, testowanie front-endu lub dokumentacja. Ten sam wzorzec działa w innych harnessach; przewodnik po podagentach Claude Code opisuje analogiczny design po stronie Anthropic.

To potężne, ponieważ praca podagenta może pozostać poza bezpośrednią ścieżką rozumowania głównej rozmowy. Główny agent może delegować eksplorację repozytorium i konsumować wynik, zamiast wypełniać swój własny kontekst każdym pośrednim wyszukiwaniem. Ale podagenty tworzą trzy mniej oczywiste koszty:

1. Konsumują tokeny. Drzewo agentów, z których każdy ponownie czyta repozytorium, może stać się zaskakująco drogie — mój raport z doświadczeń z Oh My Opencode dokumentuje, co się dzieje, gdy ten overhead jest pushowany do skrajności.
2. Tworzą złożoność polityki. Uprawnienia muszą być rozważane dla agenta delegowanego, nie tylko dla rodzica.
3. Delegowanie może ukrywać rozumowanie. Kiedy główny agent mówi „podagent znalazł X”, może być konieczne zbadanie sesji dziecka, aby zrozumieć, jak faktycznie wiarygodny jest ten wniosek.

Dla większości zadań kodujących dwa lub trzy celowe agenty są bardziej użyteczne niż złożona fikcyjna firma programistyczna żyjąca wewnątrz Twojego terminala.

Jeśli zadanie naprawdę potrzebuje pełnego orkiestratora delegującego do stałej rotacji specjalistów — równoległe tło, fazy planowania i badań, routing modelu per rola — to jest to inny produkt zbudowany na tych prymitywach, a nie większa podpowiedź. Szybki start Oh My Opencode obejmuje ten harness.

Używaj niestandardowych agentów jako granic uprawnień

Agenci OpenCode mogą mieć osobne podpowiedzi, modele i uprawnienia. To sprawia, że agenci są użyteczni jako granice bezpieczeństwa i przepływu pracy, a nie jedynie jako inne osobowości. Na przykład, agent recenzji lokalny w projekcie może być zdefiniowany jako plik Markdown:

---
description: Reviews code without modifying the repository
mode: subagent
permission:
  edit: deny
  bash:
    "*": ask
    "git diff *": allow
    "git status *": allow
    "git log *": allow
  webfetch: deny
---

Review code for correctness, security, maintainability,
unexpected behavior changes, and missing tests.

Do not modify files.

To znacznie lepsze niż pisanie „proszę, nie edytuj nic” w prozie. Instrukcje wpływają na model. Uprawnienia ograniczają narzędzie. To nie są równoważne kontrole.

Skonfiguruj uprawnienia OpenCode w pierwszym dniu

Jedną z najważniejszych praktycznych cech OpenCode jest to, że jego domyślne ustawienia są pobłażliwe. To wygodne podczas demo, ale niekoniecznie tego chcę na stacji roboczej zawierającej klucze SSH, poświadczenia produkcyjne, tokeny publikowania pakietów, konteksty Kubernetesa i dostęp do kilku kont chmurowych. Dla niekontrolowanych zadań opencode run stawka jest jeszcze wyższa: nic nie zatrzymuje uruchomienia, poza polityką, którą skonfigurujesz.

Bieżący model uprawnień OpenCode obsługuje:

allow
ask
deny

Reguły mogą być stosowane do dostępu do plików, edycji, poleceń shella, operacji sieciowych, podagentów, umiejętności, zewnętrznych katalogów i innych kategorii narzędzi. Konserwatywny punkt startowy mógłby wyglądać tak:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "*": "ask",
    "read": "allow",
    "grep": "allow",
    "glob": "allow",
    "edit": "ask",
    "bash": {
      "*": "ask",
      "git status *": "allow",
      "git diff *": "allow",
      "git log *": "allow",
      "git push *": "deny",
      "rm *": "deny"
    }
  }
}

Dokładne reguły powinny pasować do Twojego środowiska. Istotne jest, aby polityka była intencjonalna, a nie odkrywanie domyślności po tym, gdy agent już wykonał coś zaskakującego.

Nie myl promptów aprobaty z piaskownicą

Reguły uprawnień są użyteczne, ale nie są tym samym, co izolacja systemów operacyjnych. Jeśli OpenCode ma uprawnienie do wykonania dozwolonego polecenia shell, ten proces działa z dostępem dostępnym w Twoim środowisku. Agent kodujący może potencjalnie interaktywać z plikami, usługami sieciowymi, zmiennymi środowiskowymi, poświadczeniami, gniazdami, menedżerami pakietów i innymi narzędziami deweloperskimi. Szybki start OpenHands CLI jest odpowiednikiem w piaskownicy: przestrzeń robocza Docker, tryb headless, który zawsze akceptuje, i przekaz do Agent Canvas, które teraz dokumentuje projekt OpenHands.

Dla wrażliwych repozytoriów lub niekontrolowanych uruchomień, silniejsza izolacja jest warta rozważenia:

Git to rollback. Uprawnienia to polityka. Kontener lub VM to izolacja. To trzy różne warstwy.

Zamień powtarzalne podpowiedzi na niestandardowe polecenia

Jeśli wielokrotnie wpisujesz te same instrukcje, powinny prawdopodobnie przestać być historią czatu i stać się konfiguracją. OpenCode wspiera projektowe i globalne niestandardowe polecenia slash dla interfejsu interaktywnego. Na przykład, utwórz:

.opencode/commands/review.md

z treścią:

---
description: Review the current changes
agent: plan
---

Review the current git diff.

Look for:
- bugs;
- security issues;
- incomplete error handling;
- missing tests;
- accidental API changes.

Do not modify files.

Następnie użyj:

/review

To mała funkcja o nieproporcjonalnej wartości. Niezawodne przepływy pracy agenta kodującego wyłaniają się, gdy dobre podpowiedzi stają się współdzieloną infrastrukturą projektową zamiast osobistych fragmentów schowka. Innymi użytecznymi poleceniami projektowymi mogą być:

/test-changes
/review
/prepare-pr
/check-migration
/update-docs
/release-check

Używaj umiejętności (Skills) dla powtarzalnych przepływów pracy

OpenCode wspiera również pliki SKILL.md. Umiejętności są użyteczne, gdy przepływ pracy wymaga więcej niż pojedynczej podpowiedzi. Umiejętność może zawierać szczegółowe wytyczne operacyjne i pliki pomocnicze, pozostając niezaładowaną, aż agent faktycznie jej potrzebuje. Przydatni kandydaci obejmują:

• procedury migracji bazy danych;
• przepływy wydawania release’ów;
• badanie incydentów;
• recenzje kompatybilności API;
• publikowanie pakietów;
• walidację infrastruktury;
• wewnętrzne konwencje architektoniczne.

Na przykład:

.opencode/skills/database-migration/SKILL.md

Opis umiejętności może powiedzieć OpenCode, kiedy procedura ma zastosowanie, podczas gdy treść wyjaśnia, jak badać schematy, tworzyć migracje, walidować zachowanie rollbacku i uruchamiać testy integracyjne. Jeśli już używasz odpowiedniego konceptu w innym harnessie, przewodnik po Claude Skills dla deweloperów mapuje te same decyzje projektowe.

Zaletą jest dyscyplina kontekstu. Wylewanie każdej reguły organizacyjnej do AGENTS.md w końcu tworzy gigantyczny systemowy prompt, który jest drogi i coraz łatwiejszy do zignorowania przez model. Umiejętności pozwalają na wejście specjalistycznych instrukcji do kontekstu tylko wtedy, gdy są potrzebne.

MCP: Użyteczne, aż katalog narzędzi stanie się problemem

OpenCode wspiera lokalne i zdalne serwery MCP. To może wystawić śledzenie problemów, systemy dokumentacji, przeglądarki, platformy obserwowalności, bazy danych, API i inne narzędzia przed agentem kodującym. Typowa konfiguracja może dostarczyć serwer dokumentacji:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "context7": {
      "type": "remote",
      "url": "https://mcp.context7.com/mcp"
    }
  }
}

MCP to jedna z tych funkcji, które łatwo przesadzić. Każde narzędzie, które agent musi zrozumieć, konsumuje uwagę i często tokeny kontekstu. Setup z piętnastoma serwerami MCP może wyglądać potężnie na zrzucie ekranu konfiguracji, jednocześnie czyniąc faktyczne zachowanie modelu wolniejszym, droższym i mniej przewidywalnym.

Moja zasada jest prosta: jeśli narzędzie nie jest użyteczne w zwykłym tygodniu pracy, prawdopodobnie nie powinno być włączone globalnie. Ładuj narzędzia, ponieważ przepływ pracy ich wymaga, a nie dlatego, że integracja istnieje.

Modele lokalne w OpenCode: Realna opcja, a nie magiczna naprawa

Jednym z najsilniejszych przypadków użycia OpenCode jest jego zdolność do pracy z lokalnymi lub self-hosted końcowymi punktami modeli zgodnymi z OpenAI. Jest to atrakcyjne, gdy:

• kod źródłowy musi pozostać lokalny;
• koszty API są istotne;
• już operujesz infrastrukturą GPU;
• chcesz eksperymentować z otwartymi modelami;
• łączność internetowa jest niedostępna;
• routing modelu jest częścią Twojej platformy.

Niestandardowy dostawca może skierować OpenCode na lokalny endpoint, taki jak LM Studio, llama.cpp przez llama-server, vLLM, infrastrukturę zgodną z Ollama lub inny serwer zgodny z OpenAI.

Tu ważna są oczekiwania. Dobry harness kodujący nie może w pełni skompensować modelu, który jest słaby w użyciu narzędzi, planowaniu długoterminowym, rozumowaniu kodu lub retencji instrukcji. Dyskusje społeczności wokół lokalnych setupów OpenCode powtarzają się wokół tej samej obserwacji: modele lokalne mogą być świetne dla ograniczonych zadań, ale mniejsze z nich często potrzebują więcej nadzoru. Dla zmierzonych liczb na temat tego, jak konkretne modele faktycznie zachowują się wewnątrz OpenCode, zobacz moją praktyczną porównawcę LLM dla OpenCode.

Praktycznym rozwiązaniem jest routing modelu według złożoności zadania. Używaj tańszego lub lokalnego modelu do:

• wyszukiwania w repozytorium;
• dokumentacji;
• prostych testów;
• powtarzalnych edycji;
• zmian formatowania;
• prostych poprawek bugów.

Używaj silniejszego modelu do:

• zmian architektonicznych;
• niejednoznacznych bugów;
• refaktoryzacji między pakietami;
• współbieżności;
• kodu wrażliwego na bezpieczeństwo;
• trudnych migracji.

Niezależność od dostawcy sprawia, że ta strategia jest możliwa. Nie sprawia to, że jakość modelu staje się nieistotna.

Praktyczny codzienny przepływ pracy z OpenCode

Mój preferowany przepływ pracy jest celowo konserwatywny. Działa tak samo w TUI lub przez opencode run; tam, gdzie krokem jest podpowiedź, wariant wiersza poleceń jest pokazany obok.

Krok 1: Zacznij od czystego stanu Git

git status

Albo zatwierdź istniejące zmiany, albo celowo odnotuj, co jest już zmodyfikowane. Agent kodujący AI operujący w brudnym drzewie roboczym sprawia, że recenzja staje się znacznie trudniejsza, ponieważ zmiany ludzkie i agenta mieszają się ze sobą.

Krok 2: Poproś najpierw o badanie

Investigate issue #482.

Do not modify files.

Explain:
- the current behavior;
- likely root cause;
- relevant files;
- existing tests;
- proposed fix;
- verification commands.

Ta sama podpowiedź jako jednorazowe polecenie:

opencode run "Investigate issue #482. Do not modify files. Explain the current behavior, likely root cause, relevant files, existing tests, proposed fix, and verification commands."

Jeśli badanie jest błędne, jego skorygowanie jest tanie.

Krok 3: Zwęź implementację

Implement the proposed fix only.

Do not refactor unrelated code.
Add the regression test first.
Run the smallest relevant test suite after the change.

Lub nieinteraktywnie:

opencode run "Implement the proposed fix only. Do not refactor unrelated code. Add the regression test first. Run the smallest relevant test suite after the change."

Agent ma teraz mniejszą przestrzeń decyzyjną.

Krok 4: Zbadaj diff samodzielnie

git diff --stat
git diff

Nie deleguj tego kroku całkowicie do innego modelu. Sprawdzasz nie tylko, czy kod wygląda na prawdopodobny, ale również, czy agent zmienił pliki, których nie musiał dotykać.

Krok 5: Uruchom deterministyczną walidację

npm run typecheck
npm test
npm run lint

Używaj rzeczywistych poleceń projektu. „OpenCode mówi, że testy przechodzą” to nie silniejszy dowód niż Twój terminal wyświetlający udany proces testów.

Krok 6: Uruchom niezależną recenzję

Poproś agenta read-only:

Review the uncommitted diff as if it were a pull request written
by another engineer.

Try to find reasons this implementation is wrong.

Do not edit files.

Wariant wiersza poleceń:

opencode run "Review the uncommitted diff as if it were a pull request written by another engineer. Try to find reasons this implementation is wrong. Do not edit files."

Fraza „spróbuj znaleźć powody, dla których to jest błędne” jest intencjonalna. Modele są bardzo dobre w uprzejmym potwierdzaniu prawdopodobnej pracy. Podpowiedzi recenzji powinny zachęcać do falsyfikacji, a nie do oklasków.

Krok 7: Zatwierdź tylko wtedy, gdy diff ma sens

git add -p
git commit

Wciąż wolę interaktywne staging po zmianach wygenerowanych przez agenta. Wymusza to jedną ostatnią ludzką pętlę przez każdy hunk, który staje się częścią historii repozytorium.

Gdzie OpenCode staje się frustrujący: Częste pułapki

Ciekawe ograniczenia to zazwyczaj nie „AI zrobił błąd składniowy”. Kompilatory są dobre w wykrywaniu tych błędów. Trudne problemy pochodzą z autonomii, kontekstu, ukrytych założeń i konfiguracji.

Wyzwanie 1: Jakość modelu dominuje nad doświadczeniem

Ten sam przepływ pracy OpenCode może czuć się świetnie z jednym modelem i prawie nieużywalny z innym. To utrudnia recenzje produktowe, ponieważ użytkownicy często przypisują zachowanie modelu harnessowi agenta.

Jeśli OpenCode powtarzanie:

• ignoruje instrukcje;
• przepisuje za dużo kodu;
• błędnie wywołuje narzędzia;
• wpada w pętlę na tym samym nieudanym działaniu;
• traci z oczu ograniczenia;
• wymyśla API;

spróbuj innego modelu przed projektowaniem od nowa całej konfiguracji OpenCode. Terminal nagle nie stał się mądrzejszy. Model stał się inny.

Wyzwanie 2: Długie sesje akumulują zły kontekst

Sesje agenta kodującego stają się mniej wiarygodne, gdy akumulują się błędne założenia. Wczesny błąd, taki jak „ta usługa jest bezstanowa”, może wpływać na dziesiątki późniejszych decyzji, nawet po zmianie odpowiednich plików.

OpenCode wspiera kompresję (compaction) do zarządzania limitami kontekstu, ale kompresja tworzy własny trade-off. Podsumowanie koniecznie decyduje, które szczegóły przetrwają. Przy dużych przejściach między zadaniami, rozpoczęcie nowej sesji jest często czystsze niż kontynuowanie heroicznej 80 000-tokenowej rozmowy. Przy uruchomieniach skryptowych odpowiedź jest jeszcze prostsza: nowe opencode run startuje z czystym kontekstem za każdym razem, więc stan długoterminowy należy do plików, takich jak AGENTS.md, a nie do rozmowy.

Kontekst to nie darmowa pamięć. To stan roboczy, a stan roboczy staje się przeterminowany.

Wyzwanie 3: Uprawnienia mogą stać się oszukańczo złożone

Proste reguły są łatwe:

read -> allow
edit -> ask
git push -> deny

Złożone hierarchie agentów są trudniejsze. Kiedy główni agenci mogą wywoływać podagentów, niestandardowe narzędzia, serwery MCP i polecenia shell, musisz rozumować o efektywnych możliwościach całego przepływu pracy, a nie jednej linii konfiguracji.

Były również rzeczywiste dyskusje społeczności i na GitHubie dotyczące zachowania uprawnień podagentów i dziedziczenia uprawnień. Lekcja jest szersza niż jakikolwiek jeden bug: testuj założenia bezpieczeństwa w rzeczywistym, jednorazowym repozytorium — na przykład git init /tmp/opencode-perm-test i spróbuj skłonić agenta do wykonania polecenia, które tam zabroniłeś. Jeśli działanie absolutnie nie może nastąpić, nie polegaj wyłącznie na instrukcjach prozą.

Wyzwanie 4: OpenCode zmienia się szybko

OpenCode wydawał zaskakujące tempo. To dobre dla funkcji i mniej przyjemne dla trwałości dokumentacji. Szczególną łatwą pułapką w 2026 roku jest znajdowanie przykładów konfiguracji z innej generacji OpenCode. Bieżąca dokumentacja zawiera również osobne materiały V2, których schemat konfiguracji różni się od ugruntowanej składni 1.x. Na przykład, koncepcje uprawnień mogą pojawiać się pod różnymi nazwami pól w dokumentacji V2.

Nie łączy się przypadkowo przykładów z:

/docs/

i:

/v2/docs/

bez sprawdzenia, którego runtime’u faktycznie używasz. Gdy troubleshootujesz konfigurację skopiowaną z posta blogowego, sprawdź jego datę publikacji, zanim założysz, że OpenCode jest uszkodzony.

Wyzwanie 5: TUI może ukrywać skalę

Interfejs konwersacyjny sprawia, że zmiana dziesięciu plików czuje się mniejsza, niż faktycznie jest. Agent może raportować:

Implemented the new validation and updated the relevant tests.

To zdanie mogłoby reprezentować trzy linijki lub 600 linii. Trzymaj niezależne narzędzia shell blisko:

git status --short
git diff --stat
git diff --name-only
git diff

Agent kodujący nie powinien być jedynym interfejsem, przez który obserwujesz agenta kodującego.

Wyzwanie 6: MCP może zniszczyć efektywność kontekstu

Więcej integracji nie automatycznie produkuje lepszego agenta kodującego. Duże serwery MCP mogą wystawić wiele schematów narzędzi, każde z nich konsumuje kontekst modelu i zwiększa złożoność selekcji narzędzi. Jeśli OpenCode czuje się dziwnie niezdecydowany po zainstalowaniu połowy ekosystemu MCP, wyłącz większość z nich i porównaj. Mniejsza powierzchnia narzędzi często produkuje lepsze zachowanie agenta.

Wyzwanie 7: Lokalna prywatność wymaga weryfikacji całej ścieżki

Uruchamianie lokalnego modelu nie automatycznie gwarantuje, że każda część łańcucha narzędzi jest lokalna. Dyskusje społeczności na początku 2026 roku podniosły kwestie prywatności dotyczące zachowania modelu pomocniczego OpenCode i architektury interfejsu web. Niektóre z tych twierdzeń odnosiły się do starszych wersji, niektóre były zakwestionowane, a niektóre ścieżki kodu zmieniły się od tego czasu.

Trwałą lekcją nie jest „OpenCode wysyła wszystko gdzieś”. Trwałą lekcją jest: jeśli operacja tylko-lokalna jest twardym wymaganiem, zweryfikuj to. Używaj inspekcji sieciowej, czytaj bieżącą konfigurację, zrozum, którego interfejsu używasz, wyłącz niepotrzebne zdalne integracje i przetestuj dokładną wersję, którą zamierzasz wdrożyć. Wymagania bezpieczeństwa powinny być walidowane, a nie wnioskowane z kategorii produktu.

OpenCode vs Claude Code i Codex CLI

Najsilniejszy wyróżnik OpenCode to niekoniecznie jakość kodowania. Podlegający model wciąż mocno wpływa na jakość kodowania. Jego wyróżnikiem jest kontrola nad harness’em.

OpenCode jest przekonujący, gdy cenisz:

• implementację open-source;
• elastyczność dostawców;
• przepływy pracy terminal-first;
• konfigurowalnych agentów;
• granularne uprawnienia;
• wsparcie modeli lokalnych;
• MCP;
• powtarzalne polecenia i umiejętności;
• architekturę klient/serwer.

Claude Code jest przekonujący, gdy chcesz ściśle zintegrowane doświadczenie Anthropic z silnym pierwszym-party zachowaniem modelu i coraz bardziej wypolerowanymi wbudowanymi przepływami agentów. Codex CLI jest przekonujący, gdy Twoje preferowane modele i przepływ pracy są już scentrowane wokół stosu kodującego OpenAI.

Nie wybierałbym między nimi przez liczenie funkcji. Wybierz w oparciu o to, którą warstwę chcesz posiadać. Jeśli chcesz, aby dostawca podjął większość decyzji przepływu pracy, first-party agent kodujący może być atrakcyjny. Jeśli chcesz, aby harness pozostał zamienialny, podczas gdy eksperymentujesz z dostawcami i konfiguracjami agentów, OpenCode stawia silniejszą argumentację.

Co Reddit i Hacker News robią dobrze w kwestii OpenCode

Dyskusje społeczności wokół OpenCode są niezwykłe spolaryzowane. Niektórzy deweloperzy opisują go jako swój ulubiony harness kodujący, szczególnie w połączeniu z modelami Codex, modelami lokalnymi lub niestandardowymi setupami agentów. Inni skupiają się na zużyciu zasobów, zachowaniu uprawnień, kwestiach prywatności, zmianach uwierzytelniania dostawcy lub złożoności, która pojawia się, gdy pozornie prosta aplikacja terminalowa staje się infrastrukturą. Obie perspektywy są rozsądne.

OpenCode nie jest trudny, ponieważ wiersz poleceń jest trudny. Jest trudny, ponieważ autonomiczne środowisko kodowania ujawnia pytania, na które deweloperzy wcześniej nie musieli odpowiadać wprost:

• Który model powinien podjąć tę decyzję?
• Które pliki może czytać?
• Które polecenia może wykonywać?
• Jakie poświadczenia może zobaczyć proces?
• Które zadania powinny stać się podagentami?
• Ile kontekstu powinno przetrwać?
• Które narzędzia zasługują na stały kontekst?
• Który wynik musi zweryfikować człowiek?

Wypolerowany zamknięty produkt może podjąć wiele z tych decyzji za Ciebie. OpenCode czyni więcej z nich Twoimi. To właśnie dlatego zaawansowani użytkownicy go lubią.

Konfiguracja startowa, którą bym polecił

Odmówiłbym budowania złożonego setupu od razu. Zacznij z:

1. jednym silnym domyślnym modelem;
2. jednym plikiem AGENTS.md;
3. konserwatywnymi uprawnieniami shell i edycji;
4. agentem recenzji read-only;
5. dwoma lub trzema niestandardowymi poleceniami;
6. bez serwerów MCP, aż pojawi się realna potrzeba.

Proste środowisko jest łatwiejsze do debugowania. Gdy przepływ pracy staje się powtarzalny, promuj go do polecenia, umiejętności lub agenta. Gdy możliwość staje się ryzykowna, ogranicz ją uprawnieniami. Gdy kontekst staje się napęczniały, podziel przepływ pracy zamiast jedynie kupować większe okno kontekstu. To inkrementalne podejście jest mniej imponujące na zrzutach ekranu i znacznie przyjemniejsze w utrzymaniu.

Kto powinien używać OpenCode

OpenCode to szczególnie dobre dopasowanie dla deweloperów, którzy już żyją w terminalach i chcą, aby ich agent kodujący zachowywał się jak inne programowalne narzędzie deweloperskie. Zdecydowanie bym go rozważał, jeśli:

• pracujesz z wieloma dostawcami LLM;
• chcesz wsparcie modeli lokalnych;
• nie lubisz być zablokowanym do jednego dostawcy AI;
• potrzebujesz agentów specyficznych dla projektu;
• automatyzujesz zadania deweloperskie ze skryptów shell;
• chcesz badać lub modyfikować harness kodowania;
• już rozumiesz Git i normalne narzędzia CLI.

Jest mniej przekonujący, jeśli przede wszystkim chcesz niewidzialnej warstwy AI wewnątrz IDE. OpenCode oczekuje również więcej osądu operacyjnego niż tradycyjne narzędzie autouzupełniania. Jeśli recenzowanie diffów, rozumowanie poleceń shell i zarządzanie gałęziami Gitu sprawiają Ci już dyskomfort, danie autonomicznemu procesowi dostępu do tych narzędzi nie sprawi, że podstawowa złożoność zniknie.

Końcowy werdykt

OpenCode to jeden z bardziej przekonujących przykładów narzędzia kodowania AI stającego się infrastrukturą deweloperską zamiast jedynie interfejsem czatu. Jego najlepsze funkcje nie są błyszczące. Niezależność od dostawcy, jawne uprawnienia, powtarzalni agenci, nieinteraktywne wykonywanie, instrukcje repozytorium, polecenia, umiejętności i skomponowalne narzędzia sprawiają, że możliwe jest kształtowanie agenta wokół rzeczywistego przepływu inżynieryjnego.

Słabością jest zwierciadlane odbicie tej siły. OpenCode daje Ci wystarczającą kontrolę, aby stworzyć zdyscyplinowane środowisko kodowania, ale również daje wystarczającą kontrolę, aby stworzyć skomplikowany, drogi, słabo izolowany rój agentów z dwudziestoma serwerami MCP i bez jasnej granicy weryfikacji.

Nie optymalizowałbym OpenCode pod maksymalną autonomię. Optymalizowałbym go pod krótkie pętle informacyjne. Daj mu ograniczony problem, wystarczający kontekst, aby zrozumieć problem, uprawnienie do wykonania tylko niezbędnych działań i deterministyczne polecenia, które mogą udowodnić, czy rezultat działa. To mniej magiczne niż proszenie agenta o zbudowanie całej aplikacji podczas Twojego snu. Jest również znacznie bliższe temu, jak OpenCode staje się rzeczywiście użyteczny.

Odniesienia

• Dokumentacja OpenCode: https://opencode.ai/docs/
• Changelog OpenCode: https://opencode.ai/changelog
• Repozytorium GitHub OpenCode: https://github.com/anomalyco/opencode
• Katalog dostawców Models.dev: https://models.dev