Bezgłowy pętla kodowania z dwoma agentami przy użyciu OpenCode i Ollama

Większość demonstracji kodowania przy użyciu sztucznej inteligencji robi wrażenie aż do chwili, gdy ktoś zadaje banalne pytanie inżynieryjne: co dokładnie się stało, kto to sprawdził, jakie testy zostały przeprowadzone i czy całość da się odtworzyć jutro?

Poniższy proces pracy ma na celu udzielenie na to odpowiedzi. Zamiast okna czatu, które od czasu do czasu tworzy dobry patch, traktuje kodowanie za pomocą sztucznej inteligencji jako mały cykl inżynieryjny:

• jeden agent planuje i wdraża
• drugi agent sprawdza i zatwierdza
• każde zapytanie ma własną lokalną folder sesji
• każde uruchomienie pozostawia ślady logów oraz dowód przeprowadzenia testów
• człowiek, a nie agent, decyduje, kiedy kod zostanie zamieszczony lub wysłany
• prywatne zapytania i wyniki sesji pozostają prywatne

Rozdział pracy: MiniMax opracowuje plany i pisze kod, GLM je sprawdza i zatwierdza, OpenCode zarządza procesem pracy, a Ollama kieruje żądania do modeli. To nie jest żadna magiczna autonomia – to powtarzalny cykl, który wytwarza plany, przeprowadza przeglądy, testy, robocze zrzuty ekranu, sprawdzenia bezpieczeństwa, a także dokonuje komitów kontrolowanych przez człowieka.

Jeśli chodzi o narzędzia, OpenCode oferuje niinteraktywny tryb opencode run, możliwość tworzenia agentów, wyboru modeli, flagę --dir oraz funkcję przypinania procesu do instancji opencode serve bez interfejsu graficznego. Sesje można eksportować za pomocą flagi --sanitize. Ollama dokumentuje integrację z OpenCode za pomocą polecenia ollama launch opencode, a OpenCode odczytuje konfigurację na poziomie projektu, informacje o agentach, uprawnieniach, umiejętnościach oraz serwery MCP.

Przykładowa konfiguracja nazywa swoje modele Ollama Cloud minimax-m3:cloud oraz glm-5.1:cloud; MiniMax jest przeznaczony do programowania i pracy z agentami, natomiast GLM opisany jest jako flagowy model do inżynierii agentów. Sam wzorzec nie zależy od tych konkretnych modeli. Traktuj nazwy modeli jako przykłady i sprawdź aktualny katalog Ollama przed ich skopiowaniem. Surowe prompty, wyniki sesji, lokalne ścieżki, klucze oraz zrzuty ekranu z oryginalnego projektu nie są tutaj udostępniane – tylko metoda.

Przestań traktować programowanie przy użyciu AI jak zwykłą rozmowę

Samotny agent do programowania ma tę samą słabość co programista pracujący sam pod presją: może przekonać samego siebie, że skończył pracę. Ponowne zapytanie tego samego modelu tego nie naprawi. Rozwiązaniem jest proces:

Prompt -> Plan -> Review -> Implement -> Test -> Review -> Fix -> Signoff -> Human commit

Układ wygląda tak:

control-workspace/
  AGENTS.md
  opencode.json
  .opencode/
    agents/
      minimax-builder.md
      glm-reviewer.md
    skills/
      opencode-ollama-agent-guardrails/
        SKILL.md
  agent-sessions/
    project-slug/
      promptNN/
        PROMPTNN_CODER.md
        PROMPTNN_REVIEWER.md
        PROMPTNN_PLAN.md
        PROMPTNN_PLAN_REVIEW.md
        PROMPTNN_IMPLEMENTATION.md
        PROMPTNN_TEST_RESULTS.md
        PROMPTNN_IMPLEMENTATION_REVIEW.md
        PROMPTNN_SIGNOFF.md
        redacted logs
        screenshot references
  product-repo/

Dlaczego zaczynać od przestrzeni roboczej kontroli nadrzędnej? Samo w repozytorium produktu agent może nie mieć dostępu do plików instrukcji, plików sesji, wspólnych reguł ani do szerszego przepływu pracy. Natomiast ścieżki bezwzględne mogą zawierać informacje specyficzne dla danego urządzenia w logach. Stąd zasada: uruchamiaj OpenCode z poziomu kontroli nadrzędnej, używaj ścieżek względnych, przechowuj edycje produktu w jego repozytorium, a wyniki sesji poza nim. Brzmi to nudno, ale właśnie dlatego to działa.

Dwa agenty o oddzielnych zadaniach

Kluczowym wyborem projektowym nie jest dokładny model, lecz rozdzielenie zadań.

Budowniczy

minimax-builder może planować, edytować kod, wykonywać polecenia oraz pisać notatki dotyczące implementacji. Jego obowiązkami są odczytanie zapytania oraz pliku AGENTS.md, opracowanie planu, uwzględnienie uwag recenzenta, implementacja wyłącznie zatwierdzonego zakresu, przeprowadzenie weryfikacji, zapisanie tego, co zostało zmienione i co zawiodło, oraz zatrzymanie się w oczekiwaniu na zatwierdzenie przez człowieka każdej zmiany. Zabronione jest: dokonywanie komitów, wysyłanie zmian, rebasing, force-pushing, przechodzenie do kolejnego zapytania, łagodzenie testów oraz edytowanie plików przeznaczonych wyłącznie dla recenzenta.

Recenzent

glm-reviewer jest z natury rygorystyczny. Jego lista kontrolna obejmuje: czy plan odpowiada zapytaniu, czy implementacja pozostała w ramach zakresu, czy testy są sensowne, czy pliki utworzone zostały zmienione celowo, czy zrzuty ekranu z przeglądarki potwierdzają twierdzenia, czy obsługa danych poufnych jest prawidłowa, oraz czy narzędzie nie przesadza ze swoimi wynikami?

Jego słownictwo decyzyjne jest bardzo ograniczone:

APPROVED
CHANGES_REQUESTED
SIGNED_OFF
NOT_SIGNED_OFF

Niewielki zasób słownictwa pozostawia niewiele możliwości manewru. „Wygląda dobrze ogólnie” nie jest akceptacją.

Konfiguracja OpenCode

Oto struktura konfiguracji:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "ollama/minimax-m3:cloud",
  "default_agent": "minimax-builder",
  "share": "disabled",
  "instructions": ["AGENTS.md"],
  "enabled_providers": ["ollama"],
  "permission": {
    "read": {
      "*": "allow",
      "*.env": "deny",
      "*.env.*": "deny",
      "*.env.example": "allow"
    },
    "glob": "allow",
    "grep": "allow",
    "webfetch": "ask",
    "websearch": "ask",
    "external_directory": "deny",
    "skill": {
      "*": "allow"
    }
  },
  "agent": {
    "minimax-builder": {
      "description": "Main planning and implementation agent.",
      "mode": "primary",
      "model": "ollama/minimax-m3:cloud",
      "temperature": 0.2,
      "permission": {
        "edit": {
          "*": "deny",
          "product-repo/**": "allow",
          "agent-sessions/project-slug/**": "allow"
        },
        "bash": {
          "*": "ask",
          "cd product-repo && *": "ask",
          "git status *": "allow",
          "git diff *": "allow",
          "git log *": "allow",
          "git commit *": "deny",
          "git push *": "deny",
          "git rebase *": "deny",
          "rm *": "deny"
        }
      }
    },
    "glm-reviewer": {
      "description": "Strict reviewer. Must not edit product code.",
      "mode": "primary",
      "model": "ollama/glm-5.1:cloud",
      "temperature": 0.1,
      "permission": {
        "edit": {
          "*": "deny",
          "agent-sessions/project-slug/**": "allow"
        },
        "bash": {
          "*": "ask",
          "git status *": "allow",
          "git diff *": "allow",
          "git log *": "allow",
          "grep *": "allow",
          "rg *": "allow",
          "git commit *": "deny",
          "git push *": "deny",
          "git rebase *": "deny",
          "rm *": "deny"
        },
        "task": "deny"
      }
    }
  }
}

Dwa szczegóły wymagają uwagi. Dzielenie się jest wyłączone domyślnie, a ponieważ OpenCode posiada opcję share, ustawienie jej na "disabled" blokuje tę możliwość i zapobiega przypadkowemu wyciekom danych. Recenzent nie ma również szerokich uprawnień edytorskich: może tworzyć pliki z recenzją i zatwierdzeniem w folderze sesji, ale nie powinien modyfikować kodu produkcyjnego. OpenCode oferuje szczegółowe zasady uprawnień dla operacji edit, bash, read, grep, glob, skill i innych, więc sama konfiguracja powinna egzekwować określony proces pracy.

Ustaw odpowiednie ścieżki dla swojego repozytorium. Zasada pozostaje niezmienna:

builder can edit product code;
reviewer can write review notes;
neither agent can commit or push;
external directories are denied;
dangerous shell commands ask or deny.

Umiejętności jako przenośna bariera ochronna

Najczęściej wykorzystywanym elementem nie jest tylko plik konfiguracyjny – to umiejętność. Umiejętności OpenCode to wielokrotnie używalne definicje w formacie SKILL.md przechowywane w folderach umiejętności projektowych lub globalnych. Kanoniczna lokalizacja na poziomie projektu to:

.opencode/skills/<skill-name>/SKILL.md

Istnieją również ścieżki umiejętności kompatybilne z Claude oraz z agentami, ale w tym przypadku rozsądne jest zachowanie prostoty. Umieść tutaj umiejętność zabezpieczającą:

.opencode/
  skills/
    opencode-ollama-agent-guardrails/
      SKILL.md

Każdy plik SKILL.md musi zawierać metadane przynajmniej z polami name i description. Nazwa musi być pisana małymi literami, oddzielona myślnikami i musi być identyczna z nazwą folderu. Umiejętność typu guardrail może określać dla agentów zasady takie jak:

- Do not publish raw prompts.
- Do not publish raw session logs.
- Do not use absolute local paths.
- Do not edit outside the approved product directory.
- Do not claim success without test output.
- Do not weaken tests to make validation pass.
- Do not commit, push, rebase, or force-push.
- Store review notes separately from production code.
- Treat screenshots as sensitive evidence.
- Stop for human approval after signoff.

Zasady wydają się proste, ale zapobiegają prawdziwym błędom. Jeśli znajdują się jedynie w pliku AGENTS.md danego repozytorium, pozostają tam. Gdy są spakowane jako umiejętność, towarzyszą ci wszędzie.

Tryb bez głowy ułatwia powtarzalność

Kodowanie interaktywne nadaje się do eksploracji. Tryb bez głowy jest lepszy do wykonywania zadań w sposób powtarzalny. Parametr builder wygląda tak:

opencode run \
  --model ollama/minimax-m3:cloud \
  --agent minimax-builder \
  --dir . \
  "$(cat agent-sessions/project-slug/promptNN/PROMPTNN_CODER.md)"

A ocena recenzenta brzmi:

opencode run \
  --model ollama/glm-5.1:cloud \
  --agent glm-reviewer \
  --dir . \
  "$(cat agent-sessions/project-slug/promptNN/PROMPTNN_REVIEWER.md)"

Dla bardziej zaawansowanych konfiguracji z serwerami MCP należy raz uruchomić lokalny serwer OpenCode, a późniejsze uruchomienia do niego dołączyć, unikając w ten sposób powtarzających się początkowych procesów uruchamiania:

opencode serve --hostname 127.0.0.1 --port 4096

opencode run \
  --attach http://localhost:4096 \
  --agent minimax-builder \
  --dir . \
  "$(cat agent-sessions/project-slug/promptNN/PROMPTNN_CODER.md)"

Przypnij serwer do 127.0.0.1. Każdy, kto udostępnia go innemu komputerowi, powinien ustawić OPENCODE_SERVER_PASSWORD i uruchamiać go jak prawdziwą usługę rozwojową, ponieważ dokumentacja CLI opisuje autoryzację HTTP basic poprzez tę zmienną. Model nie stał się mądrzejszy – tylko trudniej go oszukać.

Zachowaj polecenia i wyniki bez wycieku informacji

Przechowywanie lokalnie plików z poleceniami oraz wyników sesji jest przydatne do debugowania zachowania agenta. Publikowanie surowych poleczeń lub surowych wyjść nie ma sensu. Łogi agentów mogą zawierać lokalne ścieżki, polecenia w terminalu, nazwy gałęzi, wewnętrzne zadania do wykonania, sekrety implementacji, nazwy środowisk, ścieżki do zrzutów ekranu, przypadkowe dane uwierzytelniające oraz sformułowania polecenia, które wolałbyś wykorzystać tylko prywatnie.

Zasada brzmi: przechowuj wszystko lokalnie i publikuj tylko zredagowane streszczenia oraz szablony wielokrotnego użycia. Funkcja opencode export [sessionID] w OpenCode z opcją --sanitize pomaga przy wewnętrznej weryfikacji, ale należy ją traktować jako pierwszy etap, a nie jako przycisk publikacji. Wszystko, co ma być publiczne, musi przejść drugą weryfikację redakcyjną.

Dla repozytorium publicznego zapisz następujące elementy:

AGENTS.md
opencode.json
.opencode/agents/*.md
.opencode/skills/*/SKILL.md
templates/*.md
scripts/*.zsh
scripts/redact_sessions.py
docs/publication-redaction-checklist.md

i zignoruj te pliki:

agent-sessions/**
screenshots/**
.env
project.local.env
*.raw.log
*.events.jsonl
opencode-session-*.json

Wynikiem są raporty, które można udostępniać, bez konieczności przekształcania repozytorium w źródło wycieków.

Gdzie przydały się narzędzia MCP

Modele stanowią jedynie część systemu, a interfejs narzędzi ma ogromne znaczenie. Przydatnym sposobem na postrzeganie MCP i wbudowanych narzędzi jest myślenie o nich jako o specjalistycznych zmysłach i rękach:

| Workflow stage   | Useful tool or MCP category                             | What it helped with                                |
| ---------------- | ------------------------------------------------------- | -------------------------------------------------- |
| Planning         | repo search, docs lookup, issue/context reader          | understand current architecture before changing it |
| Coding           | filesystem, shell, language server, package manager     | edit code, inspect symbols, run targeted commands  |
| Review           | git diff, grep, test reports, generated artifact reader | catch scope creep and weak tests                   |
| Unit tests       | test runner, coverage                                   | prove the patch did not only compile               |
| Browser tests    | Playwright/browser automation                           | validate real UI routes and flows                  |
| Security tests   | secret scan, dependency audit, SAST                     | catch obvious unsafe output before publish         |
| Docs/site checks | static-site build, route checks, smoke tests            | catch generated-output drift                       |

Najlepsza konfiguracja MCP nie włącza wszystkiego. Dostarcza agencie tylko te narzędzia, których potrzebuje, i zmusza te ryzykowne do uprzedniego zapytania. OpenCode definiuje serwery MCP pod kluczem mcp w pliku opencode.json i oferuje polecenia CLI do ich zarządzania. Traktuj te definicje jak zależności produkcyjne: ustal ich konkretne wersje, przejrzyj je i usuń te niewykorzystywane.

Dlaczego obrazy ekranu znalazły swoje miejsce

Testy przeglądarki zwracają wynik „przejdź” lub „nieprzejdź”. Obrazy ekranu dostarczają wizualnych dowodów. Pomogły osobie sprawdzającej dostrzec to, czego nie wykrywają testy jednostkowe: uszkodzoną strukturę po poprawnym zbudowaniu, błędny treść na danej ścieżce, puste strony wygenerowane przez system, regresje w nawigacji, baner z błędem, na który żaden test się nie odnosił, oraz potwierdzenie, że ścieżka strony statycznej istnieje i jest renderowana.

One również niosą ze sobą ryzyko: nazwy profili przeglądarki, prywatne karty, ścieżki localhost, tytuły problemów, tokeny URL oraz wyniki narzędzi deweloperskich mogą trafić do ramki. Zasada polega na robieniu zrzutów ekranu wyłącznie interfejsu localhost, ich dokładnym przycięciu, sprawdzeniu przed publikacją oraz na nieprzechwytywaniu stron autoryzacyjnych, paneli produkcyjnych, prywatnych kart ani terminali wyświetlających wartości środowiskowe. Zrzut ekranu stanowi dowód i domyślnie nie jest uważany za artefakt publiczny.

Przypadek studium projektu wiki prywatnego

Autor zastosował to w prywatnej witrynie typu LLM wiki oraz projekcie statycznego strony internetowej i opublikował jedynie wstępnie przetworzony raport. W końcowych notatkach walidacyjnych odnotowano 977 przeprowadzonych z powodzeniem testów w Pythonie, ponowną budowę strony statycznej z odświeżeniem, weryfikację funkcjonalności smoke-site oraz domeny, utworzenie dokumentacji, sprawdzenie tras oraz 150 przeprowadzonych z powodzeniem testów Playwright. W przypadku ukończonych, określonych funkcji autor miał wysoką pewność co do ich jakości – około 8 do 9 na 10 – wspartą powtarzalnymi testami, weryfikacją utworzonej strony, sprawdzeniem tras oraz weryfikacją w przeglądarce. Ta ocena jest subiektywna i nie powinna być stosowana poza tym projektem.

Słabym punktem nie był kod produktu. Jeden skrypt automatyzacji bez interfejsu użytkownika nie zadziałał poprawnie, ponieważ nazwy agentów zostały błędnie skonfigurowane. Wykorzystywał on nazwy ogólne:

planner
coder
tester
reviewer

podczas gdy skonfigurowani agenci byli w rzeczywistości:

minimax-builder
glm-reviewer

Niespójność spowodowała, że proces powrócił do niewłaściwego zachowania, w związku z czym zamierzony proces zatwierdzenia przez kilka agentów nie został ukończony. Ten błąd okazał się przydatny, ponieważ pokazał wartość prostych nazw, dokładnej konfiguracji, ścieżek względnych oraz konieczność sprawdzania folderu sesji. Poprawiony wzorzec wygląda następująco:

opencode run \
  --model ollama/minimax-m3:cloud \
  --agent minimax-builder \
  --dir . \
  "$(cat agent-sessions/project-slug/promptNN/PROMPTNN_CODER.md)"

opencode run \
  --model ollama/glm-5.1:cloud \
  --agent glm-reviewer \
  --dir . \
  "$(cat agent-sessions/project-slug/promptNN/PROMPTNN_REVIEWER.md)"

To oznacza brak ścieżek absolutnych, brak wymyślonych nazw agentów oraz brak plików instrukcji ukrytych poza zakresem pracy.

Jak blisko jest to przepływu pracy typu Frontier?

Tutaj łatwo przesadzać z opisami. Konfiguracja MiniMax w połączeniu z GLM na OpenCode i Ollama nie jest tym samym co bezpośrednie uruchomienie najlepszego modelu programistycznego typu Frontier. Modele Frontier nadal charakteryzują się silniejszym rozumowaniem, lepszym radzeniem sobie z długimi kontekstami oraz lepszym przestrzeganiem instrukcji domyślnych, więc porównywanie modelu z modelu nie byłoby sprawiedliwe. Istotne jest porównanie jakości przepływu pracy: planowanie, przegląd, testy, zrzuty ekranu, sprawdzenia bezpieczeństwa oraz zatwierdzenie przez człowieka.

Proces pracy ma duże znaczenie. W przypadku zadań o określonym zakresie, wspieranych dobrze napisanymi testami, takie podejście może przypominać silny model typu Frontier, ponieważ obejmuje oddzielne role, wstępne planowanie, przeglądy po obu stronach implementacji, obowiązkowe bramy walidacyjne, lokalną pamięć sesji, dowody w postaci zrzutów ekranu, kontrole bezpieczeństwa oraz komitowane przez człowieka zmiany.

Blisko tego podejścia jest przy deterministycznej pracy nad funkcjonalnościami, generowaniu statycznych stron, mechanizmach wyszukiwania i pobierania danych, zadaniami wymagającym intensywnych testów, przeglądaniu wygenerowanych wyników, wykrywaniu rozszerzania zakresu prac oraz zmuszaniu osób odpowiedzialnych do dokumentowania błędów. Modele typu Frontier wciąż przewyższają je w przypadku niejednoznacznych decyzji architektonicznych, głębokich refaktoryzacji w słabo przetestowanym kodzie, oceny estetycznej i jakości produktu, samokorekty na dłuższym horyzoncie czasowym, potrzeby mniejszej liczby prób, automatycznego przestrzegania instrukcji oraz analizy złożonych zrzutów ekranu.

Model zagrożeń

W ramach tego procesu zmniejsza się liczba znanych zagrożeń związanych z kodowaniem przy użyciu sztucznej inteligencji: niepotwierdzone twierdzenia o sukcesie, twórcy, którzy działają poza przeznaczonym repozytorium, recenzenci, którzy stają się osobami realizującymi kod, surowe polecenia trafiające do publicznych repozytoriów, logi ujawniające ścieżki lub tajne dane, zrzuty ekranu pokazujące prywatne karty lub tokeny, bezgłośne modyfikacje plików wygenerowanych przez AI oraz agenci dokonujący komitów lub pushów, zanim ktokolwiek to sprawdzi.

Kontrola przez człowieka pozostaje konieczna. Pełna autonomia nie jest celem – celem jest bardziej ścisły cykl, w którym każde twierdzenie jest poparte dowodami, a każda ryzykowna akcja ma określone ograniczenia.

Zalety i wady

Zalety

• Możliwość odtworzenia. Polecenia generują foldery, wykonywania zadań pozostawiają notatki, a akceptacje można prześledzić.
• Zarządzanie. Twórca nie może po cichu pominąć testów, jeśli recenzent musi zablokować akceptację bez dowodów walidacji.

Elastyczność modeli. Możesz wymieniać modele w miarę rozwoju wsparcia Ollamy i OpenCode, a ten proces przetrwa zmiany.

Szybkość. Gdy już istnieją prompty i skrypty, wykonywanie kolejnego zadań jest szybkie.

Wady

• Więcej formalności. Jest to bardziej skomplikowane niż zwykły prompt do czatu, i to jest cena tej elastyczności.
• Wymagana konfiguracja do egzekwowania zasad. Prośba o nieedytowanie kodu produkcyjnego jest mniej skuteczna niż jego egzekwowanie za pomocą uprawnień i kontrol CI.
• Złe prompty nadal dają złe wyniki. Pętla zmniejsza chaos, ale nie zastępuje jasno określonego zakresu zadań.
• Uprawnienia wymagają ostrożności. Serwery MCP i dostęp do wiersza poleceń są potężne, więc należy je traktować jak dostęp do środowiska produkcyjnego.
• Logi są wrażliwe. Im bardziej szczegółowe są logi, tym staranniejsza musi być ich edycja.

Twierdzenie, które się sprawdza

To rozwiązanie nie przekształci MiniMax ani GLM w modele najwyższej klasy. Zamiast tego sprawia, że tańszy kodowanie agentywne obsługiwane przez Ollamę staje się bardziej zdyscyplinowane, poddawalne audytowi i przydatne w projektowaniu w określonych ramach. To jedyne twierdzenie, które można w tym przypadku uczciwie sformułować.