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

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

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

W przypadku małych zadań można go zainstalować, połączyć z modelem i zacząć zadawać pytania w kilka minut. Przy poważniejszej 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 działać. Ten artykuł koncentruje się na tym drugim etapie, z poziomu wiersza poleceń: które przypadki użycia się opłacają, które przepływy automatyzacji sprawdzają się w codziennym użytkowaniu i jakie problemy pojawiają się po tym, jak minie ekscytacja związana z AI w terminalu. Jest to część sekcji Narzędzia dla deweloperów AI na tej stronie.

Obserwacje przedstawione tutaj zostały zweryfikowane względem wersji OpenCode 1.18.9 i aktualnej dokumentacji z sierpnia 2026 roku. OpenCode zmienia się szybko, dlatego przykłady konfiguracji warto szybko zweryfikować w dokumentacji przed skopiowaniem ich do długoterminowej konfiguracji zespołu. Jeśli jeszcze nie zainstalowałeś OpenCode, szybki start OpenCode obejmuje instalację, weryfikację i połączenie z dostawcą.

Czym tak naprawdę jest OpenCode: Środowisko agenta, a nie okno czatu

OpenCode to open-source’owy agent AI do kodowania zaprojektowany wokół terminala. Uproszczony widok tego, co ze sobą łączy, wygląda następująco:

Kluczową częścią jest warstwa uprawnień między intencją modelu a działaniami, które OpenCode może wykonać. Doskonały model z złymi uprawnieniami może być niebezpieczny. Słaby model z idealnymi uprawnieniami jest po prostu wolny i irytujący. Produktywne wykorzystanie OpenCode wymaga rozsądnego dopasowania obu stron.

To samo środowisko służy obu interfejsom: interaktywnemu TUI i nieinteraktywnemu wierszowi poleceń. To właśnie sprawia, że OpenCode jest skryptowalny w sposób, w jaki czysty interfejs czatu nie jest. Jeśli chcesz świadomie minimalistycznego podejścia do tego samego pomysłu terminalowego agenta — cztery domyślne narzędzia, brak wbudowanego sandboxu, wszystko inne przez rozszerzenia — recenzja Pi Coding Agent stanowi użyteczny kontrast.

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

OpenCode instaluje się w jednej linii — oficjalny skrypt instalacyjny, npm lub Homebrew — i uruchamia się komendą opencode z katalogu repozytorium. Szybki start OpenCode obejmuje pełną macierz instalacji (Arch, Windows, Docker), weryfikację i połączenie z dostawcą (/connect i /models), więc ten artykuł nie powtarza tych treści.

Możesz korzystać z własnych usług modeli OpenCode lub połączyć się z obsługiwanych dostawców zewnętrznych. OpenCode obecnie buduje większość swojego katalogu dostawców za pomocą Models.dev i obsługuje szeroki zakres konfiguracji modeli komercyjnych i lokalnych.

Niezależność od dostawcy to jedna z najprzydatniejszych decyzji architektonicznych OpenCode. Twój przepływ pracy z kodowaniem nie musi być trwale związany z jednym dostawcą modeli: możesz używać jednego modelu do trudnych zadań architektonicznych, innego do tanich zadań implementacyjnych, a modelu lokalnego do kodu, który nie powinien opuszczać Twojego środowiska.

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

Zainicjalizuj repozytorium z AGENTS.md przed proszeniem o kod

Jedną z pierwszych komend, które warto wykonać w nowym repozytorium, jest:

/init

OpenCode analizuje projekt i tworzy plik AGENTS.md. Zacommituj ten plik.

AGENTS.md to miejsce, gdzie specyficzne dla repozytorium ograniczenia mogą stać się trwałym kontekstem dla każdej rozmowy — interaktywnej lub skryptowej — zamiast być powtarzanymi ręcznie. Przydatny plik jest wystarczająco krótki, aby pozostać aktualny, ale wystarczająco konkretny, aby zapobiec przewidywalnym błędom. Na przykład:

# Instrukcje Repozytorium

## Architektura

- Obsługiwane API znajdują się pod src/api.
- Logika biznesowa należy pod src/services.
- Dostęp do bazy danych należy pod src/repositories.
- Nie wywołuj klientów bazy danych bezpośrednio z obsługi HTTP.

## Walidacja

Po zmianach w TypeScript uruchom:

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

Po zmianach na froncie uruchom również:

```bash
npm run lint
```

## Ograniczenia

- Nie modyfikuj plików generowanych.
- Nie zmieniaj kontraktów publicznego API bez wcześniejszego pytania.
- Nie twórz migracji bazy danych, chyba że zostanie to wyraźnie zażądane.
- Nigdy nie uruchamiaj komend wdrożeniowych.

To jest mniej ekscytujące niż instalowanie kolejnego serwera MCP, ale zwykle dostarcza więcej wartości. Agenci kodujący często zawodzi, ponieważ nie wiedzą, które ograniczenia są ważne. Krótka umowa repozytorium usuwa część tej dwuznaczności przed pierwszym wywołaniem narzędzia.

Praca z wiersza poleceń za pomocą opencode run

Interfejs interaktywny przyciąga najwięcej uwagi, ale tryb nieinteraktywny OpenCode znacząco zmienia zakres przydatnych przepływów pracy:

opencode run "Wyjaśnij strategię obsługi błędów w tym pakiecie"

Możesz korzystać z OpenCode ze skryptów powłoki, zadań CI, plików Make, menedżerów zadań lub lokalnej automatyzacji, bez ręcznego wejścia do TUI za każdym razem. Na przykład, przegląd diffa jako jednorazowa komenda:

opencode run \
  "Przeglądaj bieżący git diff pod kątem poprawności i brakujących testów. Nie edytuj plików."

Albo potocz kontekst bezpośrednio do uruchomienia:

git diff --name-only HEAD~1 |
  opencode run "Zbadaj zmienione pliki i zidentyfikuj ryzykowne zmiany w zachowaniu."

W pliku Makefile to samo wywołanie staje się celem:

.PHONY: review
review:
	opencode run "Przeglądaj bieżący git diff pod kątem poprawności i brakujących testów. Nie edytuj plików."

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

Ciekawym kierunkiem tutaj nie jest zastępowanie deterministycznych skryptów LLM. Chodzi o wstawienie rozumowania modelu w miejsca, gdzie tradycyjna logika powłoki staje się nieporęczna, zachowując przy tym deterministyczną walidację wokół tego.

Najlepsze przypadki użycia CLI OpenCode

OpenCode może podejmować się prawie każdego zadania programistycznego, ale nie oznacza to, że każde zadanie powinno być delegowane w ten sam sposób. Najbardziej wartościowe przepływy pracy mają zwykle trzy cechy: oczekiwany wynik jest testowalny, odpowiedni kontekst repozytorium może zostać odkryty, a błędne zmiany są tanie do zbadania lub cofnięcia. Każdy z poniższych promptów działa w TUI lub jako argument do opencode run.

1. Eksploracja repozytorium

OpenCode jest doskonały w odpowiadaniu na pytania, które w przeciwnym razie wymagałyby sekwencji komend grep, wyszukiwania w edytorze, skakania między plikami i git log. Na przykład:

Wyjaśnij, jak działa uwierzytelnianie w tym repozytorium.

Śledź żądanie od middleware HTTP przez walidację tokenów,
ładowanie użytkownika, autoryzację i końcową obsługę.

Nie modyfikuj niczego.

Dobry agent wyszuka punkty wejścia, prześledzi odwołania, zbada testy i zwróci coś bliższego przeglądowi architektury niż zwykłe wyszukiwanie tekstu. To jedna z najbezpieczniejszych sposobów wprowadzenia OpenCode do istniejącej bazy kodu, ponieważ agent może dostarczać wartości bez pisania kodu.

2. Małe, dobrze ograniczone poprawki

Wąsko określony błąd jest bliski idealnemu zadaniu dla agenta kodującego. Na przykład:

CLI kończy się ze statusem 0, gdy walidacja konfiguracji nie powiedzie się.

Znajdź odpowiedzialną ścieżkę kodu, dodaj test regresyjny, zaimplementuj
najmniejszą możliwą poprawkę i uruchom odpowiednie testy.

Nie refactoruj niezwiązanego kodu.

Kluczową frazą nie jest “popraw błąd”. To ograniczenia otaczające zadanie. OpenCode działa lepiej, gdy sukces można udowodnić testem, kompilatorem lub obserwowalną komendą. Niejasne wymagania dają modelowi przestrzeń do tworzenia prawdopodobnego kodu zamiast demonstracyjnie poprawnego kodu.

3. Generowanie testów po implementacji

Testy są przydatną pracą dla agenta, ponieważ istniejąca implementacja daje OpenCode coś konkretnego, nad czym może rozmyślać. Produktywny prompt mógłby brzmieć:

Przeglądaj src/parser.ts i jego istniejące testy.

Zidentyfikuj ważne przypadki brzegowe, które obecnie nie są pokryte.
Dodaj tylko testy. Nie modyfikuj implementacji.

Uruchom zestaw testów parsera po zakończeniu.

Oddzielenie generowania testów od implementacji jest ważne. Jeśli ten sam agent pisze zarówno funkcję, jak i testy w jednej nieograniczonej sesji, 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 nieaktualnego API w całym repozytorium;
• konwertowanie powtarzającego się kodu do współdzielonej funkcji pomocniczej;
• zmienianie nazwy pola konfiguracji;
• migrację testów z jednego wzorca asercji na inny;
• aktualizowanie importów po przeniesieniu pakietu;
• zastępowanie przestarzałego abstrakcji logowania.

Kompilator i testy repozytorium stają się pętlą informacyjną agenta. Przydatnym wzorcem jest:

Zastąp użycia LegacyResult<T> na Result<T, AppError> tylko w
packages/api.

Zachowaj zachowanie w czasie wykonania.

Pracuj w małych partiach. Po każdej partii uruchom typecheck pakietu.
Na końcu uruchom zestaw testów pakietu i pokaż mi podsumowanie końcowego git diff.

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

5. Przegląd kodu

OpenCode staje się znacznie przydatniejszy, gdy przegląd jest traktowany jako osobna rola agenta, a nie kolejny prompt wysłany do tego samego kontekstu edycji. Możesz stworzyć agenta nastawionego na przegląd, który nie może edytować plików. Następnie daj mu instrukcje takie jak:

Przeglądaj bieżący git diff.

Skup się na:
- poprawności;
- bezpieczeństwie;
- współbieżności;
- brakujących testach;
- obsłudze błędów;
- przypadkowych zmianach API.

Nie podsumowuj plików, które nie uległy zmianie.
Ułóż ustalenia według ciężkości.

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

Używaj trybów Plan i Build jako różnych trybów myślenia

OpenCode oferuje agentów głównych i podagentów, z wbudowanymi przepływami pracy obejmującymi planowanie i zachowanie orientowane na implementację. Nawet gdy dokładna konfiguracja agentów zmienia się z czasem, koncepcyjna separacja pozostaje przydatna.

Planowanie powinno odpowiadać na pytania takie jak:

• Które pliki są ważne?
• Jakie istniejące wzorce powinny być podążane?
• 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. Dla istotnych zadań preferuję sekwencję promptów taką jak:

Najpierw zbadać żądanie.

Nie edytuj plików jeszcze.

Zwróć:
1. odpowiednie pliki;
2. bieżące zachowanie;
3. proponowaną zmianę;
4. ryzyka;
5. dokładne komendy weryfikacyjne.

Ta sama sekwencja działa jako jednorazowa komenda:

opencode run "Najpierw zbadać żądanie. Nie edytuj plików jeszcze. Zwróć: odpowiednie pliki; bieżące zachowanie; proponowaną zmianę; ryzyka; dokładne komendy weryfikacyjne."

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

To jest lekka, zadaniowa wersja tego samego instynktu, który stoi za rozwijaniem napędzanym specyfikacjami: uzgodnij plan, zanim agent zacznie edytować. Dla pracy, która obejmuje wiele plików, sesji lub współpracowników, spisana specyfikacja zwraca swój koszt w sposób, w jaki pojedynczy prompt “najpierw badaj” nie może; porównanie GitHub Spec Kit vs Kiro vs Claude Code obejmuje strukturalne przepływy SDD, które idą dalej niż pojedynczy prompt.

Podagenci są przydatni, ale delegacja nie jest darmowa

OpenCode może wywoływać wyspecjalizowanych podagentów automatycznie lub przez jawne wspomnienia. Na przykład:

@general znajdź, gdzie zaimplementowano zachowanie ponowienia

Możesz również zdefiniować dedykowanych podagentów dla zadań takich jak przegląd bezpieczeństwa, analiza zależności, testowanie frontendu lub dokumentacja. Ten sam wzorzec działa w innych szkieletach; przewodnik po podagentach Claude Code obejmuje analogiczny projekt po stronie Anthropic.

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

1. Konsumują tokeny. Drzewo agentów, które każde ponownie odczytuje repozytorium, może stać się zaskakująco drogie — mój raport z doświadczeń z Oh My Opencode dokumentuje, co się dzieje, gdy ten nadmiar jest doprowadzony do skrajności.
2. Tworzą złożoność polityki. Uprawnienia muszą być rozważane dla delegowanego agenta, nie tylko dla rodzica.
3. Delegacja może ukrywać rozumowanie. Kiedy główny agent mówi “podagent znalazł X”, może być konieczne zbadanie sesji dziecka, aby zrozumieć, jak wiarygodne jest to wnioskowanie.

Dla większości zadań kodujących dwa lub trzy celowe agenci są bardziej przydatne niż skomplikowana fikcyjna firma programistyczna żyjąca w Twoim terminalu.

Jeśli zadanie naprawdę wymaga pełnego orkiestratora delegującego do stałej listy specjalistów — równoległe wykonywanie w tle, fazy planowania i badań, routowanie modeli per rola — to jest inny produkt zbudowany na tych pierwotnych elementach, a nie większy prompt. Szybki start Oh My Opencode obejmuje ten szkielet.

Używaj niestandardowych agentów jako granic uprawnień

Agenci OpenCode mogą mieć osobne prompty, modele i uprawnienia. To sprawia, że agenci są przydatni jako granice bezpieczeństwa i przepływów pracy, a nie tylko jako różne osobowości. Na przykład, lokalny dla projektu agent przeglądu może być zdefiniowany jako plik Markdown:

---
description: Przegląda kod bez modyfikowania repozytorium
mode: subagent
permission:
  edit: deny
  bash:
    "*": ask
    "git diff *": allow
    "git status *": allow
    "git log *": allow
  webfetch: deny
---

Przeglądaj kod pod kątem poprawności, bezpieczeństwa, utrzymywalności,
nieoczekiwanych zmian zachowania i brakujących testów.

Nie modyfikuj plików.

To jest znacznie lepsze niż pisanie “proszę nie edytować niczego” w prozie. Instrukcje wpływają na model. Uprawnienia ograniczają narzędzie. To nie są równoważne mechanizmy kontroli.

Skonfiguruj uprawnienia OpenCode od pierwszego dnia

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

Aktualny model uprawnień OpenCode obsługuje:

allow
ask
deny

Zasady mogą być stosowane do dostępu do plików, edycji, komend powłoki, operacji webowych, podagentów, umiejętności, zewnętrznych katalogów i innych kategorii narzędzi. Konserwatywnym punktem startowym może być:

{
  "$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 zasady powinny pasować do Twojego środowiska. Ważne jest, aby uczynić politykę intencjonalną, a nie odkrywać domyślne ustawienia po tym, jak agent już wykonał coś zaskakującego.

Nie myl promptów zatwierdzania z sandboxingiem

Zasady uprawnień są przydatne, ale nie są tym samym co izolacja systemu operacyjnego. Jeśli OpenCode ma uprawnienie do wykonania dozwolonej komendy powłoki, ten proces działa z dostępem dostępnym w Twoim środowisku. Agent kodujący może potencjalnie wchodzić w interakcję z plikami, usługami sieciowymi, zmiennymi środowiskowymi, poświadczeniami, gniazdami, menedżerami pakietów i innymi narzędziami deweloperskimi.

Dla wrażliwych repozytoriów lub nieprzerywanych uruchomień warto rozważyć silniejszą izolację:

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

Zamień powtarzalne prompty na niestandardowe komendy

Jeśli powtarzasz te same instrukcje, powinny one prawdopodobnie przestać być historią czatu i stać się konfiguracją. OpenCode obsługuje niestandardowe komendy slash dla interfejsu interaktywnego, zarówno projektowe, jak i globalne. Na przykład, utwórz:

.opencode/commands/review.md

z:

---
description: Przeglądaj bieżące zmiany
agent: plan
---

Przeglądaj bieżący git diff.

Szukaj:
- błędów;
- problemów z bezpieczeństwem;
- niekompletnej obsługi błędów;
- brakujących testów;
- przypadkowych zmian API.

Nie modyfikuj plików.

Następnie użyj:

/review

To jest mała funkcja o nieproporcjonalnej wartości. Niezawodne przepływy pracy agenta kodującego pojawiają się, gdy dobre prompty stają się współdzieloną infrastrukturą projektu, a nie osobistymi fragmentami schowka. Inne przydatne komendy projektowe mogą obejmować:

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

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

OpenCode obsługuje również pliki SKILL.md. Umiejętności są przydatne, gdy przepływ pracy wymaga więcej niż pojedynczy prompt. Umiejętność może zawierać szczegółowe wytyczne operacyjne i pliki pomocnicze, pozostając niezładowaną, dopóki agent jej faktycznie nie potrzebuje. Przydatnymi kandydatami są:

• procedury migracji bazy danych;
• przepływy wydawania;
• badanie incydentów;
• przeglądy kompatybilności API;
• publikowanie pakietów;
• walidacja 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 cofania i uruchamiać testy integracyjne. Jeśli już używasz odpowiedniego konceptu w innym szkielecie, przewodnik po umiejętnościach Claude dla deweloperów mapuje te same decyzje projektowe.

Zaletą jest dyscyplina kontekstu. Wylewanie każdej zasady organizacyjnej do AGENTS.md w końcu tworzy gigantyczny prompt systemowy, który jest drogi i coraz łatwiejszy dla modelu do zignorowania. Umiejętności pozwalają wyspecjalizowanym instrukcjom wejść w kontekst tylko wtedy, gdy są potrzebne.

MCP: Przydatne, dopóki katalog narzędzi nie staje się problemem

OpenCode obsługuje 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 do dyspozycji agenta kodującego. Typowa konfiguracja może dostarczać 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 nadużyć. Każde narzędzie, które agent musi zrozumieć, konsumuje uwagę i często tokeny kontekstu. Konfiguracja z piętnastoma serwerami MCP może wyglądać potężnie na zrzucie ekranu konfiguracji, podczas gdy rzeczywiste zachowanie modelu staje się wolniejsze, droższe i mniej przewidywalne.

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

Lokalne modele 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ńcami modeli kompatybilnymi z OpenAI. To jest atrakcyjne, gdy:

• kod źródłowy musi pozostać lokalny;
• koszty API są znaczące;
• już operujesz infrastrukturą GPU;
• chcesz eksperymentować z otwartymi modelami;
• łączność internetowa jest niezawodna;
• routowanie modeli jest częścią Twojej platformy.

Niestandardowy dostawca może wskazać OpenCode na lokalny punkt końcowy, taki jak LM Studio, llama.cpp przez llama-server, vLLM, infrastrukturę kompatybilną z Ollama lub inny serwer kompatybilny z OpenAI.

Tu liczą się oczekiwania. Dobry szkielet kodujący nie może całkowicie skompensować modelu, który jest słaby w używaniu narzędzi, planowaniu długoterminowym, rozumowaniu kodu lub retencji instrukcji. Społeczne dyskusje wokół lokalnych konfiguracji OpenCode wielokrotnie zbiegają się w tej samej obserwacji: lokalne modele mogą być doskonałe do ograniczonych zadań, ale mniejsze często wymagają więcej nadzoru. Dla zmierzonych liczb na temat tego, jak konkretne modele faktycznie zachowują się wewnątrz OpenCode, zobacz moje praktyczne porównanie LLM dla OpenCode.

Praktycznym rozwiązaniem jest routowanie modeli 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 błędów.

Używaj silniejszego modelu do:

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

Niezależność od dostawcy umożliwia tę strategię. Nie sprawia, że jakość modelu jest bez znaczenia.

Praktyczny codzienny przepływ pracy z OpenCode

Mój preferowany przepływ pracy jest świadomie konserwatywny. Działa tak samo w TUI jak i przez opencode run; tam, gdzie krok jest promptem, wariant wiersza poleceń jest pokazany obok.

Krok 1: Zacznij od czystego stanu Git

git status

Albo zacommituj istniejące zmiany, albo świadomie zanotuj, co jest już zmodyfikowane. Agent AI kodujący działający w brudnym drzewie roboczym utrudnia przegląd, ponieważ zmiany ludzkie i zmiany agenta mieszają się ze sobą.

Krok 2: Poproś o badanie najpierw

Zbadaj problem #482.

Nie modyfikuj plików.

Wyjaśnij:
- bieżące zachowanie;
- prawdopodobną przyczynę;
- odpowiednie pliki;
- istniejące testy;
- proponowaną poprawkę;
- komendy weryfikacyjne.

Ten sam prompt jako jednorazowa komenda:

opencode run "Zbadaj problem #482. Nie modyfikuj plików. Wyjaśnij bieżące zachowanie, prawdopodobną przyczynę, odpowiednie pliki, istniejące testy, proponowaną poprawkę i komendy weryfikacyjne."

Jeśli badanie jest błędne, jego korekta jest tania.

Krok 3: Zwęź implementację

Zaimplementuj tylko proponowaną poprawkę.

Nie refactoruj niezwiązanego kodu.
Dodaj test regresyjny najpierw.
Uruchom najmniejszy odpowiedni zestaw testów po zmianie.

Lub nieinteraktywnie:

opencode run "Zaimplementuj tylko proponowaną poprawkę. Nie refactoruj niezwiązanego kodu. Dodaj test regresyjny najpierw. Uruchom najmniejszy odpowiedni zestaw testów po zmianie."

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 wiarygodnie, ale czy agent zmienił pliki, których nie musiał dotykać.

Krok 5: Uruchom deterministyczną weryfikację

npm run typecheck
npm test
npm run lint

Używaj rzeczywistych komend projektu. “OpenCode mówi, że testy przechodzą” to nie silniejszy dowód niż Twój terminal wyświetlający pomyślny proces testowy.

Krok 6: Uruchom niezależny przegląd

Poproś agenta read-only:

Przeglądaj niezacommitowany diff tak, jakby to był pull request napisany
przez innego inżyniera.

Spróbuj znaleźć powody, dla których ta implementacja jest błędna.

Nie edytuj plików.

Wariant wiersza poleceń:

opencode run "Przeglądaj niezacommitowany diff tak, jakby to był pull request napisany przez innego inżyniera. Spróbuj znaleźć powody, dla których ta implementacja jest błędna. Nie edytuj plików."

Fraza “spróbuj znaleźć powody, dla których to jest błędne” jest intencjonalna. Modele są bardzo dobre w uprzejmym potwierdzaniu wiarygodnej pracy. Prompty przeglądu powinny zachęcać do falsyfikacji, a nie do braw.

Krok 7: Commituj tylko wtedy, gdy diff ma sens

git add -p
git commit

Wciąż preferuję interaktywne staging po zmianach generowanych przez agenta. Wymusza to jeden ostatni ludzki przegląd każdego hunka, który staje się częścią historii repozytorium.

Gdzie OpenCode staje się frustrujący: Częste błędy

Ciekawe ograniczenia to zwykle nie “AI zrobił błąd składniowy”. Kompilatory są dobre w łapaniu tych. Trudne problemy wynikają z autonomii, kontekstu, ukrytych założeń i konfiguracji.

Wyzwanie 1: Jakość modelu dominuje doświadczenie

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

Jeśli OpenCode powtarza:

• ignorowanie instrukcji;
• przepisywanie zbyt dużo kodu;
• błędne wywoływanie narzędzi;
• zapętlanie się na tej samej nieudanej akcji;
• gubienie tropu ograniczeń;
• wymyślanie API;

spróbuj innego modelu, zanim przebudujesz całą konfigurację OpenCode. Terminal nagle nie stał się mądrzejszy. To model.

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 tym, jak odpowiednie pliki się zmieniły.

OpenCode obsługuje kompaktowanie, aby zarządzać limitami kontekstu, ale kompresja tworzy własne kompromisy. Podsumowanie nieuchronnie decyduje, które szczegóły przetrwają. Dla dużych przejść między zadaniami, rozpoczęcie nowej sesji jest często czystsze niż kontynuowanie heroicznego 80 000-tokenowego rozmowy. Przy skryptowych uruchomieniach odpowiedź jest jeszcze prostsza: nowe opencode run zaczyna z czystym kontekstem za każdym razem, więc długoterminowy stan 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ę przestarzały.

Wyzwanie 3: Uprawnienia mogą stać się podstępnie skomplikowane

Proste zasady są łatwe:

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

Złożone hierarchie agentów są trudniejsze. Kiedy agenci główni mogą wywoływać podagentów, niestandardowe narzędzia, serwery MCP i komendy powłoki, 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 GitHub dotyczące zachowania uprawnień podagentów i dziedziczenia uprawnień. Lekcja jest szersza niż jakikolwiek jeden błąd: 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 tam komendy, której zakazałeś. Jeśli akcja absolutnie nie powinna wystąpić, nie polegaj tylko na instrukcjach w prozie.

Wyzwanie 4: OpenCode zmienia się szybko

OpenCode był wydawany w zaskakującym tempie. To jest dobre dla funkcji i mniej przyjemne dla trwałości dokumentacji. Szczególnie łatwą pułapką w 2026 roku jest znajdowanie przykładów konfiguracji z innej generacji OpenCode. Aktualna 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 łącz przypadkowo przykładów z:

/docs/

i:

/v2/docs/

bez sprawdzenia, który runtime faktycznie używasz. Podczas rozwiązywania problemów z konfiguracją skopiowaną z bloga, sprawdź datę publikacji, zanim założysz, że OpenCode jest zepsuty.

Wyzwanie 5: TUI może ukrywać skalę

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

Zaimplementowano nową walidację i zaktualizowano odpowiednie testy.

To zdanie może oznaczać trzy linie lub 600 linii. Trzymaj niezależne narzędzia powłoki 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 produkuje automatycznie lepszego agenta kodującego. Duże serwery MCP mogą wystawić wiele schematów narzędzi, z których każde 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 gwarantuje automatycznie, że każda część łańcucha narzędzi jest lokalna. Społeczne dyskusje na początku 2026 roku podniosły pytania o prywatność dotyczące zachowania pomocniczego modelu OpenCode i architektury interfejsu web. Niektóre z tych twierdzeń odnosiły się do starszych wersji, niektóre były kwestionowane, a niektóre ścieżki kodu zmieniły się od tamtej pory.

Trwała lekcja nie brzmi “OpenCode wysyła wszystko gdzieś”. Trwała lekcia brzmi: jeśli operacja wyłącznie lokalna jest twardym wymaganiem, zweryfikuj to. Używaj inspekcji sieci, czytaj aktualną konfigurację, zrozum, który interfejs 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

Najsilniejszym wyróżnikiem OpenCode nie jest koniecznie jakość kodowania. Podstawowy model nadal wnosi duży wkład w jakość kodowania. Jego wyróżnikiem jest kontrola nad szkieletem.

OpenCode jest przekonujący, gdy cenisz:

• implementację open-source;
• elastyczność dostawców;
• przepływy pracy terminal-first;
• konfigurowalnych agentów;
• granularne uprawnienia;
• obsługę modeli lokalnych;
• MCP;
• ponownie używalne komendy i umiejętności;
• architekturę klient/serwer.

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

Nie wybierałbym między nimi przez liczenie funkcji. Wybieraj na podstawie, którą warstwą chcesz władać. Jeśli chcesz, aby dostawca podejmował większość decyzji o przepływie pracy, first-party agent kodujący może być atrakcyjny. Jeśli chcesz, aby szkielet pozostał wymienny, podczas gdy eksperymentujesz z dostawcami i konfiguracjami agentów, OpenCode robi silniejszy argument.

Co Reddit i Hacker News robią dobrze w kwestii OpenCode

Społeczne dyskusje wokół OpenCode są niezwykło spolaryzowane. Niektórzy deweloperzy opisują go jako swój ulubiony szkielet kodowania, szczególnie w połączeniu z modelami Codex, modelami lokalnymi lub niestandardowymi konfiguracjami agentów. Inni skupiają się na zużyciu zasobów, zachowaniu uprawnień, pytaniach o prywatność, zmianach uwierzytelniania dostawców lub złożoności, która pojawia się, gdy pozornie prosta aplikacja terminalowa staje się infrastrukturą. Oba punkty widzenia 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ć?
• Jakie komendy 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 podejmować 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ł

Opierałbym się budowaniu skomplikowanej konfiguracji od razu. Zacznij od:

1. jednego silnego domyślnego modelu;
2. jednego AGENTS.md;
3. konserwatywnych uprawnień shell i edycji;
4. agenta przeglądu read-only;
5. dwóch lub trzech niestandardowych komend;
6. brak serwerów MCP, dopóki nie pojawi się realna potrzeba.

Proste środowisko jest łatwiejsze do debugowania. Kiedy przepływ pracy staje się powtarzalny, promuj go do komendy, umiejętności lub agenta. Kiedy możliwość staje się ryzykowna, ogranicz ją uprawnieniami. Kiedy kontekst staje się rozdmuchany, podziel przepływ pracy zamiast po prostu 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 jest szczególnie dobrym dopasowaniem dla deweloperów, którzy już żyją w terminalach i chcą, aby ich agent kodowania zachowywał się jak inne programowalne narzędzie deweloperskie. Rozważyłbym go zdecydowanie, jeśli:

• pracujesz z wieloma dostawcami LLM;
• chcesz obsługi modeli lokalnych;
• nie lubisz być zablokowanym do jednego dostawcy AI;
• potrzebujesz projektowych agentów;
• automatyzujesz zadania deweloperskie ze skryptów powłoki;
• chcesz badać lub modyfikować szkielet kodowania;
• już rozumiesz Git i normalne narzędzia CLI.

Jest mniej przekonujący, jeśli głównie chcesz niewidocznej warstwy AI wewnątrz IDE. OpenCode również oczekuje więcej osądu operacyjnego niż tradycyjne narzędzie autozupełniania. Jeśli przeglądanie diffów, rozumienie komend powłoki i zarządzanie gałęziami Git już sprawiają dyskomfort, udzielenie autonomicznemu procesowi dostępu do tych narzędzi nie sprawi, że podstawowa złożoność zniknie.

Ostateczny werdykt

OpenCode jest jednym z bardziej przekonujących przykładów narzędzia AI do kodowania stającego się infrastrukturą deweloperską, a nie tylko interfejsem czatu. Jego najlepsze funkcje nie są błyszczące. Niezależność od dostawcy, jawne uprawnienia, ponownie używalni agenci, nieinteraktywne uruchamianie, instrukcje repozytorium, komendy, umiejętności i kompozycyjne narzędzia sprawiają, że możliwe jest kształtowanie agenta wokół rzeczywistego przepływu pracy inżynierskiej.

Słabością jest lustro tej siły. OpenCode daje Ci wystarczająco dużo kontroli, aby stworzyć dyscyplinowane środowisko kodowania, ale również daje Ci wystarczająco dużo kontroli, 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 kątem maksymalnej autonomii. Optymalizowałbym go pod kątem krótkich pętli informacyjnych. Daj mu ograniczony problem, wystarczający kontekst, aby zrozumieć problem, uprawnienie do wykonania tylko niezbędnych akcji i deterministyczne komendy, które mogą udowodnić, czy wynik działa. To jest mniej magiczne niż proszenie agenta o zbudowanie całej aplikacji, podczas gdy śpisz. Jest też znacznie bliższe temu, w jaki sposób OpenCode staje się naprawdę użyteczny.

Referencje

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