10 dni z OpenClaw, Opus 4.6 i GLM 4.7 - AI rozwija się szybciej niż Twój zespół

TL;DR

• Przełomem nie są “lepsze odpowiedzi”, tylko autonomiczne pętle wykonawcze: plan -> delegowanie -> implementacja -> testy -> raport.
• Z OpenClaw moja rola przesunęła się z “nadzorcy” na pomysłodawcę dającego feedback. Stałem się wąskim gardłem, bo nie jestem w stanie robić code review w tempie agentów.
• Claude Opus 4.6 to realny skok w autonomii, a nowe Taski i SubAgenci w Claude Code pozwalają na zarządzanie "rojem" agentów
• Anthropic deklaruje 1M tokenów kontekstu i lepsze wyszukiwanie w długim kontekście - 76% w MRCR v2 przy 1M tokenów (Anthropic).
• Ekonomia ma znaczenie: tani model GLM-4.7 do orkiestracji + droższe modele “wykonawcze” to praktyczna architektura.
• OpenClaw nadal nie jest “enterprise-ready”. Ryzyka są realne: uprawnienia, prompt injection, nadużycia narzędzi, zgodność (zwłaszcza GDPR) i niejasności prawne.

EDIT 16.02.2026: OpenAI właśnie "kupiło" OpenClaw - jego twórca, Peter Steinberger, dołączy do zespołu Codex i będzie odpowiedzialny za rozwój autonomicznych agentów. Natomiast OpenClaw zostanie fundacją, wspieraną przez OpenAI. Miejmy nadzieję, że ten ruch przyspieszy adopcję projektu do wymagań większych firm i podniesie standardy bezpieczeństwa.
Oby Peter znalazł czas na rozwój wizji OpenClaw po dołączeniu do Codex!

Anthropic chyba żałuje, że zmusiło Petera do zmiany nazwy z ClawdBot na MoltBot (bo niby Clawd jest podobne do Claude), bo stał się on wtedy ambasadorem Codex CLI i zbliżył się do OpenAI co chyba zaowocowało zmianą nazwy z MoltBot na OpenClaw ;)

Niewygodna prawda: żywotność modeli AI to 2 miesiące

1-2 lata temu “AI w programowaniu” oznaczało głównie autouzupełnianie i czat w IDE. Agenci często marnowali nasz czas i popełniali głupie błędy. Pod koniec 2025 roku nastąpił przełom i nowe modele (Opus 4.5, GPT-5.2, GLM-4.7 i do pewnego stopnia Gemini 3 Pro) zaczęły być dużo bardziej niezawodne w programowaniu agencyjnym. Czego chcieć więcej?

W lutym 2026 te modele wydają się już przestarzałe...
Opus 4.6 z OpenClaw czy Claude Code to sprawny system, który:

1. czyta Twoją listę zadań,
2. wybiera to, co da radę zrobić autonomicznie,
3. planuje (nie na 5 minut, ale nawet 5 godzin pracy),
4. deleguje zadania do sub-agentów,
5. zarządza, sprawdza, daje feedback,
6. uruchamia testy, robi PR, sprawdza wynik CI/CD,
7. pinguje Cię na WhatsApp "Zrobione, CR pls. To teraz issue ED-943, ok?" ;)

Dokładnie taki workflow skonfigurowałem w ostatnich 10 dniach.

Ktoś powie, że to nic nowego, WebSocket, Cron, prompty. I faktycznie, samemu 2-3 lata temu robiłem zespoły agentów (architekt, designer, dev, QA, copywrighter) w CrewAI, LangChain, potem LangGraph. Tylko agenci tworzyli wtedy stronę-koszmar rodem z lat 90tych. A teraz... na CR do 3 PR mialem tylko bardzo drobne uwagi, do 1 spore poprawki UI bo mój eBoy nie miał dostępu do przeglądarki (dla bezpieczeństwa), ale logika biznesowa była poprawna i wcale nie prosta.

Nie twierdzę, że to “jedyny słuszny” sposób budowania software’u. Twierdzę, że tempo zmian jest tak duże, że jeśli jesteś CTO, tech leadem albo seniorem, nie da się tego po prostu zignorować. Największa zmiana to nie IQ modelu - to autonomia.

A autonomia zmienia wszystko: workflow zespołów, rodzaj kompetencji, wybór narzędzi, podejście do bezpieczeństwa i mierzenia produktywności. Bo ile tysięcy linii kodu jesteśmy w stanie sprawdzić? I czy zawsze musimy? ;)

Największa lekcja: stałem się wąskim gardłem

Zdanie, które pewnie przestraszy niejednego developera, ale dobrze znane managerom:

“Nie jestem już osobą, która pisze kod. Jestem wąskim gardłem.”

Gdy agenci potrafią bardzo szybko produkować “wystarczająco dobry” kod, szybkość naszego podejmowania decyzji i robienia review staje się limitem. To przesuwa optymalizacje z pisania kodu na:

• lepsze zarządzanie projektami,
• lepsze cięcie zadań i PR-ów na mniejsze kawałki,
• mocniejszy test suite,
• bardziej deterministyczne CI,
• jaśniejsze kryteria akceptacji, definition of done,
• jasny zakres uprawnień dla agentów (poziom autonomii),
• pełną automatyzację, włącznie z AI robiącym CR, testy security, a może... deploy?

Innymi słowy: autonomia AI wymusza lepsze przemyślenie i poprawienie fundamentów inżynieryjnych. A gdy już je mamy, powstaje pytanie: Czy na pewno musimy przeczytać każdą linię kodu? Kiedy automatyzacja wystarczy? Nie znam na nie odpowiedzi, póki co czytam, ale z bólem, bo jestem wąskim gardłem... Blokuję pracę mojego agenta, zarówno na wejściu (decyzje, dostępy), jak i na wyjściu (CR, akceptacja). Jak... manager? :D

OpenClaw jako workflow, a nie zabawka

OpenClaw to framework autonomicznych agentów, którzy w standardzie mają dostęp do:

• kanałów komunikacji (WhatsApp, Slack, Teams, Telegram, itd.),
• wyszukiwania i czytania kontekstu (plany, dokumentacja, stan repo, taski, wbudowana pamięć z lokalnym RAG, wyszukiwarka Perplexity lub Grok),
• narzędzi, MCP i skills (nieograniczone możliwości integracji),
• zadań cyklicznych (custom cron + heartbeats np. co 1h).

Do pełnego działania wymaga dostępu do systemu (jest też tryb sandbox), ale daje to mu możliwość m.in.:

• instalowania dowolnych narzędzi i programów,
• dostępu do potrzebnych mu do pracy plików,
• dostępu do wielu różnych projektów,
• kompilacji kodu, czy nawet dodania binary do PATH,
• używania przeglądarki, klikania, wypełniania formularzy,
• używania dowolnych CLI a nawet TUI,
• w zasadzie robienia niemal wszystkiego, co potrafi na komputerze zrobić człowiek.

Nasza rola sprowadza się wtedy do wymyślania pomysłów, delegowania, i sprawdzania. Oraz układania i optymalizacji workflow (mój agent chętnie w tym pomaga, może przecież zmieniać swoje pliki konfiguracyjne, prompty, czy pisać sobie Skills - pełna elastyczność).

Całą resztę zrobi za nas agent. I robi to w tempie, jakie nam się może tylko pomarzyć, przy jednoczesnym zachowaniu wysokiej jakości (po dobrej optymalizacji workflow, daniu mu narzędzi do testowania i poprawiania swojej pracy).

Najbardziej zaskakująca była jednak nie szybkość, tylko odkrywanie zadań: większości z nich nie zlecałem wprost. Agent sam je podjął z mojej listy i był w stanie ocenić, kiedy ma wszystko aby zacząć pracę, a kiedy musi mnie dopytać, prosić o pomoc lub decyzję. I zadaje trafne pytania.

Twarde liczby: jak wyglądało 10 dni pracy agentów

Śledziłem 10-dniowe okno (2 lutego -> 12 lutego). Podsumowanie z dashboardu Usage dla tego okresu pokazuje:

• 893,4M tokenów (in/out/cache łącznie)
• 431,41 USD kosztu
• • szacunki OpenClaw po cenie API od dostawców
  • realny koszt około $40 (używałem subskrypcji Claude Pro, Google AI Pro, ChatGPT Plus i GLM/Z.ai - o tym więcej przy ryzykach)
• 227 sesji, 11 297 wiadomości, 8 499 wywołań narzędzi
• 5,23% błędów (591) - głównie przez eksperymenty i... Gemini

OpenClaw stworzył w tym czasie m.in.:

• 5 custom Skills dla siebie (instrukcje workflow + skrypty python i JS + szablony):
• • Blogger - Research, analiza pamięci (nasze doświadczenia), propozycja tematów, generowanie draftów, odpalanie skryptów do sprawdzania jakości (unikanie =, ilość znaków itp.), generowanie zdjęcia, dodanie draftu do CMS, powiadomienie.
  • Dobór szablonu maila do tematu z templatkami i skryptem Python który poda poprawny szablon zaleźnie od tematu
  • Routing notifikacji, na jakie kanały zależnie od osób
  • System monitor - ponieważ robi buildy, odpala linting itp. musi wiedzieć czy zasoby systemu na to w danej chwili pozwalają
  • Wywiad z użytkownikiem - zebranie informacji aby dopasować bota do każðej osoby w firmie
• 9 aplikacji i narzędzi, m.in.:
• • CLI w Rust do liczenia liczby tokenów w plikach, do optymalizacji i monitorowania okna kontekstu (zrobił build do binary i dodał do PATH! - o tym więcej za chwilę)
  • CLI do RAG (robienia bazy wiedzy i embedingów własnych oraz wyszukiwania semantycznego)
  • Notatnik w Tauri z Rust, TypeScript i React - dla mnie, oparty o Markdown
• Przebudował mocno projekt Codex Monitor (open source w Taur, podobny do Codex App ale dostępny na Linux i Windows), dodając obsługę Gemini CLI i Claude Code (WIP)
• 10 Pull Requestów do repo Edukey - zrobiłby dużo więcej, ale jestem wąskim gardłem, blokuję mu pracę na wejściu i na wyjściu... musiałem zmienić Heartbeat (częstość wywołań agenta) z 30m na 1h bo się nie wyrabiałem jak brał taski co 30m. Zrobił m.in.:
• • Wiele nowych funkcjonalności lub znacznych poprawek na stronie Edukey i w naszym CRM
  • Poprawiony system Ról i Uprawnień (RBAC) - pod niego samego (aby np. nie mógł nic kasować i miał ograniczone dostępy)
  • Liczne optymalizacje pod SEO i GEO (Generative Engine Optimization = narzędzia AI)

Koszty i tokeny w.g. modelu:

• gemini-3-pro-high - koszt: $104.52, tokeny: 193.3M, wiadomości: 571
• gpt-5.2-codex - koszt: $96.98, tokeny: 343.0M, wiadomości: 2887
• claude-opus-4-6 - koszt: $76.34, tokeny: 94.4M, wiadomości: 2084
• claude-opus-4-5-thinking - koszt: $62.01, tokeny: 62.7M, wiadomości: 1151
• glm-4.7 - koszt: $46.80, tokeny: 170.9M, wiadomości: 2664

Rodzaj zużytych tokenów:

• Output: 2,7M
• Input: 133,1M
• Cache read: 770,4M
• Cache write: 3,8M
• Cache hit rate: 85,3%

To znaczy, że system zużył dużo więcej tokenów na obsługę kontekstu i cache niż na generowanie tekstu/kodu.

Dlatego “context engineering”, projektowanie orkiestracji, przepływów i promptów są ważniejsze, niż wielu zespołom się wydaje. Ale agent chętnie w tym pomoże i poprawi swoje prompty :)

Samo-optymalizacja i ulepszanie

Open Claw to "Agent-as-a-Code". Całość plików konfiguracyjnych żyje w jednym folderze, a każdy agent ma w nim swój wydzielony workspace (pod-folder). Do tego większość umiejętności agenta to łatwe do edycji tzw. Skills (pliki markdown z instrukacjami + opcjonalne assety i skrypty np. w bash, python czy JS do powtarzalnej logiki, np. połączeń z API, obróbki danych). Dzięki temu autonomiczne systemy potrafią optymalizować same siebie, jeśli im na to pozwolimy.

W moim setupie trafiłem na problem: Opus jest drogi, a dostarczany kontekst (7 głównych plików Markdown) powiela wiele informacji i jest rozwlekle napisany. Poprosiłem więc agenta o optymalizację kontekstu (skrócenie plików) przy zachowaniu informacji.

To, co zrobił potem, jest jednocześnie genialne i przerażające:

• stworzył plan,
• napisał narzędzie CLI w Rust do liczenia tokenów w plikach workspace,
• skompilował je i dodał binary do PATH,
• użył go do liczenia wielkości kontekstu w trakcie optymalizacji,
• ograniczył kontekst o 48% bez utraty jakości.

To spore oszczędności. A jednocześnie ogromne ryzyka.

Ryzyka autonomii w masowej skali

Agent, który potrafi kompilować i instalować binarki, może też zrobić znacznie gorsze rzeczy. Nie wolno go uruchomić i zostawić bez licznych ograniczeń, sanbox, tuneli ssh, Tailscale, logów, automatycznych "bezpieczników", itd.

Ale wystarczy chwila na Discord OpenClaw aby się przekonać, że wśród 14 tysięcy członków, większość to osoby nietechniczne...

Open Claw daje tak wiele możliwości, że w ciągu 2 miesięcy (powstał w listopadzie 2025) stał się najszybciej rosnącym projektem w historii GitHub (obecnie ponad 180 000 gwiazdek). A to oznacza masowe używanie produktu niedojrzałego, z błędami i lukami bezpieczeństwa, przez osoby bez żadnej wiedzy o zagrożeniach i zabezpieczeniach. A nie jest to notatnik...

Oczywiście pojawiły się już masowe oszustwa, czy niebezpieczne Skills we ClawHub marketplace, zawierające np. prompt injection (techniki promptowania łamiące zabezpieczenia modelu LLM, np. wyłudzające informacje albo nakłaniające agenta do wykonania niebezpiecznych czynności, np. przysłowiowe rm -rf / do usuwania plików, czy pobieranie wirusów).

W ciągu 2 lat przeszliśmy od "Nie dawajcie AI dostępu do Internetu" do "Dajcie AI dostęp do wszystkiego!" - Szaleństwo!

To, że nie doszło jeszcze do tragedii zawdzięczamy chyba głównie coraz lepszej jakości modeli LLM, które coraz mniej są skłonne do robienia głupich rzeczy (ale nadal je robią).

Dlaczego Opus 4.6 jest skokiem jakościowym

Gdy ktoś mówi “nowa wersja modelu”, domyślne oczekiwanie brzmi: trochę lepsze odpowiedzi. Opus 4.6 jest jednak nie tylko mądrzejszy. Przede wszystkim dużo stabilniej utrzymuje wieloetapową pracę z narzędziami (przy tysiącach wywołań narzędzi nawet niewielki % błędów potrafi doprowadzić do kaskadowych problemów w workflow), lepiej planuje skomplikowane zadania na dużych code base, oraz świetnie deleguje pracę do innych agentów.

Kilka punktów, które Anthropic komunikuje publicznie:

• Opus 4.6 ma okno kontekstu 1M tokenów (beta) co pozwala na pamiętanie na raz całego średniej wielkości projektu (Anthropic).
• W benchmarku MRCR v2 “needle-in-a-haystack” (skuteczność wyszukania ukrytej informacji) przy 1M tokenów Anthropic raportuje 76% dla Opus 4.6 (vs 18,5% dla Sonnet 4.5).
• Agent Teams i Tasks: Wieloetapowa praca przez 2 tygodnie, autonomicznie, z delegowaniem pracy do 16 sub-agentów. W ten sposób Opus 4.6 zbudował działający Kompilator kodu C w Rust, samemu, pisząc 100k lini kodu i kosztując tylko $20 000 dolarów (projekt wart wcześniej miliony). Skompilował kernel Linuxa w 3 architekturach.
• Ocena zadań i delegowanie: Opus 4.6 autonomicznie zamknął 13 issue i przypisał 12 do właściwych osób w jeden dzień w organizacji ok. 50 osób w 6 repozytoriach. Na podstawie opisów osób i zadań.
• Bezpieczeństwo: Bez żadnych instrukcji Opus 4.6 znalazł ponad 500 luk bezpieczeństwa w dużym projekcie open source, używanym przez miliony ludzi, który poprzednio przeszedł audyty bezpieczeństwa robione przez ekspertów (ludzi).

Polecam obejrzeć analizę Nate’a B. Jonesa, który odnosi się do bloga Anthropic i tłumaczy dlaczego jest to tak ważna zmiana: Nate B. Jones YT

GLM-4.7: tani orkiestrator + mocni wykonawcy

Najbardziej praktyczny wniosek z tego eksperymentu to wzorzec:

1. Użyj taniego i stabilnego modelu jako control plane (selekcja zadań, tool calling, streszczenia, koordynacja, zadania wymagajace dobrych umiejętności wywoływania funkcji ale bez dużej wiedzy).
2. Deleguj ciężkie zadania, kodowanie, architekturę i trudniejsze rozumowanie do droższych modeli wykonawczych.

W moim przypadku wyglądało to często tak:

• “Architekt / planista”: Opus 4.6 (duże okno kontekstu, rozumienie całości na raz)
• “Developer / wykonawca”: GPT-5.3 Codex (bardzo mocny w implementacji)
• "Copywriter / pisaż": Sonnet 4.5 (naturalnie brzmiące teksty, artykuły)
• “Control plane / runner”: GLM-4.7 (zaskakująco dobry w wywoływaniu funkcji, miał najmniej błędów, <1% w moich testach. Najgorzej tu mi się sprawdzał Gemini)

To ważne, bo wiele zespołów próbuje robić “jednym modelem wszystko”, a potem zderza się z kosztami albo niezawodnością. GLM kosztował mnie śmieszne $2.5 za miesiąc (w promocji na Święta) w pakiecie Coding Plan Lite (link daje +10% rabatu), a nie udało mi się do tej pory dobić do 5-godzinnego okna limitu (max 36% osiągnąłem). Na planie Lite jest on nieco za wolny do pracy z agentem w trybie pair-programmer, ale w przypadku Agentów autonomicznych, pracujących w tle, nie jest to duży problem (nie czekam na jego pracę).

Jeśli chcesz punkt odniesienia dla cen GLM (pay-per-use), Z.ai publikuje pricing tokenów i cached input w swojej dokumentacji (Z.ai pricing API).

Właśnie wczoraj wyszedł też nowy GLM-5, podobno na poziomie Opus 4.5, ale z umiejętnością pracy nad zadaniem przez godzinę, czyli poszli w kierunku zbliżonym do Opus 4.6 (uzupełnię artykuł jak go już przetestuję).

Problemem z GLM jest jednak lokalizacja serwerów w Chinach na Coding Plan od Z.ai (choć to model Open Source, istnieją alternatywy). Rodzi to problemy z danymi osobowymi / GDPR i bezpieczeństwem.

Czy to jest "Enterprise-ready”?

Oceniając sam Opus 4.6 oraz Claude Code (ze złożonymi taskami, delegowaniem do sub-agentów) jak najbardziej jest to już stosowane w dużych firmach z sukcesami.

Natomiast uniwersalni autonomiczni agenci tacy jak OpenClaw łączą się z masą dodatkowych ryzyk dla większych firm (które często są do akceptacji w małych firmach i w startupach).

1) Ryzyko uprawnień (klasa problemów “rm -rf”)

Jeśli agent może uruchamiać narzędzia, może też uruchamiać destrukcyjne komendy. Nawet jeśli model jest “bezpieczny”, może zostać wprowadzony w błąd przez niejednoznaczne polecenia albo prompt injection.

Minimum: uruchamiaj agentów na osobnej maszynie/VPS, z ograniczonymi dostępami i odzyskiwalnym systemem plików (buckups).

2) Nadużycia narzędzi i “halucynowane” akcje

W testach zdarzył się moment, kiedy agent próbował wysłać wiadomość WhatsApp na nieistniejący numer. Blokady to zatrzymały, ale intencja ma znaczenie: agent potrafi z dużą "pewnością siebie" próbować akcji, które brzmią rozsądnie, ale są niebezpieczne.

Minimum: dawaj tylko niezbędne narzędzia, ustaw środowisko sandbox, monitoruj użycie narzędzi, stosuj filtry na niebezpieczne komendy.

3) Regulaminy dostawców usług (ToS)

Subskrypcje konsumenckie i “frameworki agentowe” to nadal szara strefa. Możesz w OpenClaw wybrać jako providerów Claude Code, Codex CLI, Gemini CLI i Antigravity. Jest do tego dokumentacja. Jednak dla Google i Anthropic wygląda to jak nadużycie. W moim przypadku po około tygodniu używania Gemini CLI wewnątrz OpenClaw, dostęp do usługi Google AI Assist został zablokowany za naruszenie Terms of Services - niestety bez podania jasnej przyczyny. Czekam na ich odpowiedź na maila. Wiem, że to samo robi Anthropic.

Wniosek: jeśli budujesz workflow pod produkcję, potrzebujesz tokenów płatnych przez API providerów (najlepiej w UE), nie przez subskrypcje dla programistów.

4) GDPR i dane osobowe w UE

Jeśli używasz LLM w UE jako firma lub pracownik, załóż, że “po prostu nie wklejaj wrażliwych danych” nie jest strategią zgodności.

• prawdziwa anonimizacja jest trudna,
• logi i trace’y często zawierają identyfikatory,
• a plany konsumenckie nie dają gwarancji prawnych, których potrzebuje firma.

Jeśli chcesz wdrażać agentów w firmie, potrzebujesz realnego modelu przetwarzania danych: Region w UE, umowa o powierzeniu danych, retencja i kontrola dostępu. Oferują to wszyscy duzi providerzy, np. Azure (GPT i Anthropic) i GCP (Gemini i Anthropic).

Co zrobić w najbliższe 90 dni (dla CTO i tech leadów)

Jeśli prowadzisz zespół, nie zaczynaj od wdrożenia “agenta”. Zacznij od przygotowania środowiska tak, żeby agent pracował bezpiecznie.

1. Wybierz jeden workflow, który jest bezpieczny i mierzalny (np. aktualizacja dokumentacji wewnętrznej, małe refaktory z testami, automatyczne code review).
2. Zbuduj siatkę bezpieczeństwa testów (unit + lint + bramki CI). Agenci zwiększają wartość testów.
3. Rozdziel system na role i dobierz do nich modele LLM:

• • orkiestrator (tani, stabilny)
  • wykonawcy (mocni, drożsi)

4. Zaimplementuj model uprawnień:

• • brak dostępów produkcyjnych dla agenta!
  • osobne środowisko, Docker, VPS, sandbox (ludzie masowo kupują Mac Mini pod OpenClaw)
  • ograniczony i monitorowany dostęp do sieci,
  • allowlista narzędzi,
  • logowanie i audyt.

5. Przeszkol ludzi w nowej kompetencji (samo promptowanie nie wystarczy). Zespół developerski musi zdobyć kompetencje managerskie:

• • robić jasną specifikację wymagań dla zadań,
  • dzielić pracę na mniejsze fragmenty i je delegować (choć tu Opus 4.6 częściowo nas już wyręcza),
  • weryfikować wyniki i dawać feedback,
  • analizować błędy i poprawiać workflow,
  • zarządzać wieloma agentami na raz, lokalnie i w chmurze.

W Edukey dokładnie to widzimy na szkoleniach AI dla developerów: mniej “jak używać Cursor czy Copilot”, a więcej “jak budować workflow, któremu można zaufać”.

FAQ

Czy OpenClaw jest gotowy dla enterprise już dziś?

Nie domyślnie. Może być potężny w kontrolowanym środowisku, ale uprawnienia, bezpieczeństwo i governance wymagają realnej pracy. Problemem jest też performance przy większej skali. To jeszcze niedojrzały projekt. Świetny jako Executive Assistant dla CTO, czy eksperyment dla doświadczonego programisty, pozwoli "zobaczyć przyszłość". Jednak nie do masowych wdrożeń (ale to kwestia kilku miesięcy i pojawią się podobne rozwiązania enterprise).

Co jest największym wąskim gardłem w workflow agentowym?

Review i weryfikacja. Oraz szybkie delegowanie i usuwanie przeszkód dla agenta (np. dostępy, konfiguracja narzędzi). Gdy agenty piszą szybciej, niż ludzie są w stanie przeglądać czy delegować, stajemy się wąskim gardłem dla agentów.

Czy potrzebuję jednego “frontier” modelu (Opus) do wszystkiego?

Zwykle nie. Tani orkiestrator + mocni wykonawcy często wychodzą lepiej kosztowo i operacyjnie.

Czy 1M tokenów kontekstu rozwiązuje “context rot”?

Pomaga, ale nadal potrzebujesz dobrego zarządzania informacją jaką dostarczasz modelowi. Nawet wyniki MRCR v2 raportowane przez Anthropic są gorsze przy 1M niż przy krótszych kontekstach (Anthropic).

Jak najbezpieczniej zacząć z autonomicznymi agentami?

Osobna maszyna lub sandbox, ograniczone uprawnienia, pełne logowanie danych i backupy, start od zadań niskiego ryzyka.