Tag: Cursor SDK

  • Qwen-Code v0.19.10 z pełnym wsparciem wieloobszarowym i odświeżoną powłoką webową

    Qwen-Code v0.19.10 z pełnym wsparciem wieloobszarowym i odświeżoną powłoką webową

    Zespół Qwen opublikował 14 lipca 2026 roku wersję v0.19.10 swojego narzędzia Qwen-Code, zaledwie trzy dni po poprzednim wydaniu. Głównym celem aktualizacji jest rozszerzenie obsługi wielu obszarów roboczych na wszystkie warstwy systemu – od demona i SDK po interfejs webowy i transport ACP. Dodatkowo zmodernizowano powłokę Web Shell, wprowadzając nowy panel artefaktów, lepszą obsługę sesji oraz zwiększoną widoczność działań podagentów.

    Kluczowe informacje

    • Data wydania: 14 lipca 2026 roku, trzy dni po wersji v0.19.9
    • Główny cel: wieloobszarowe przepływy pracy obejmujące demona, SDK, Web Shell i zarządzanie sesjami
    • Nowy panel artefaktów w Web Shellu do przeglądania wygenerowanych plików i zadań
    • Ulepszone odzyskiwanie sesji po błędach strumieni, wygaśnięciu tokenów OAuth i restartach demona
    • Więcej kontroli w SDK nad wysiłkiem wnioskowania, wyborem modeli i zużyciem zasobów

    Wieloobszarowość na każdym poziomie

    Do tej pory praca z wieloma projektami w Qwen-Code wymagała ręcznego przełączania kontekstu. Wersja v0.19.10 wprowadza wiązanie sesji z konkretnym obszarem roboczym na poziomie demona i endpointów ACP. Dzięki temu klienci SDK i Web Shell mogą otwierać sesje przypisane do wybranego workspace’u bez ryzyka pomieszania kontekstów.

    Rejestracje obszarów roboczych przetrwają restart demona, co eliminuje konieczność ponownej konfiguracji środowiska. Workspace’y są dodawane dynamicznie i można je usuwać bez restartowania serwera. Split-view w Web Shellu koduje każdy panel kolorem przypisanym do workspace’u, co ułatwia identyfikację aktywnego projektu.

    Web Shell z nowym panelem artefaktów

    Interfejs webowy przeszedł istotne zmiany w tej serii wydań. Przeprojektowano pasek boczny, dodano nowy panel ustawień i stronę zarządzania rozszerzeniami. Zmodernizowany selektor modeli pokazuje jaśniejsze informacje i pozwala szybciej przełączać się między opcjami. Diagramy Mermaid zyskały możliwość powiększania, przesuwania i przeciągania.

    Najważniejszym dodatkiem jest panel artefaktów – dedykowane miejsce do przeglądania wygenerowanych plików, diffów i zaplanowanych zadań. Panel działa w ramach sesji, co pozwala na zachowanie orientacji przy pracy z wieloma zadaniami jednocześnie. Całość wykorzystuje bibliotekę shadcn jako wspólną podstawę komponentów UI.

    Sesje i modele – odporność na awarie

    Sesje i modele – odporność na awarie

    Wersja v0.19.10 usuwa kilka problemów związanych z utratą stanu sesji. Naprawiono wycieki tur protokołu, obsługę nieprawidłowych strumieni modeli oraz odzyskiwanie po wygaśnięciu tokenów OAuth. Dzięki tym zmianom przerwany strumień czy restart demona są obsługiwane bez konieczności ręcznego odtwarzania całej rozmowy z agentem.

    Wprowadzono ujednolicony plan odzyskiwania sesji dla wszystkich punktów wejścia, który obsługuje przerwane prompty, zawieszone wywołania narzędzi i zdegradowaną historię. Działa to spójnie, niezależnie od tego, czy korzystamy z CLI, SDK czy Web Shell.

    Śledzenie podagentów i CLI

    Śledzenie podagentów i CLI

    Dla zespołów debugujących złożone zadania agentów istotne są nowe możliwości obserwowalności. Podagenty pokazują teraz nieobcięte polecenia na żywo, ścieżki transkryptów i chronologiczną oś czasu zdarzeń. Dodatkowo dziedziczą modele Explore, co ułatwia analizę ich zachowania w trakcie wykonywania zadań.

    W linii poleceń pojawiły się projektowe schowki promptów – Ctrl+S zapisuje prompt dla bieżącego projektu i przywraca go przy następnym uruchomieniu. Aktywna gałąź Gita jest teraz widoczna bezpośrednio w CLI, a timeouty poleceń powłoki można konfigurować. Poprawiono również reakcję na presję pamięci.

    SDK z precyzyjną kontrolą

    Deweloperzy osadzający Qwen-Code we własnych narzędziach zyskują drobnoziarnistą kontrolę nad działaniem agentów. SDK pozwala teraz na sterowanie wysiłkiem wnioskowania, wybieranie modeli, sprawdzanie limitów użycia i konfigurowanie opcji transportu na poziomie pojedynczej sesji. Metody SDK hostowanych agentów przekazują odpowiedzi użytkownika z powrotem do modelu, co umożliwia interaktywne przepływy pytań w TypeScript i Python.

    Co to oznacza w praktyce

    Qwen-Code v0.19.10 to wydanie infrastrukturalne, które koncentruje się na problemach operacyjnych związanych z agentami pracującymi w monorepozytoriach, projektach wielousługowych czy środowiskach hostowanych. Sesje nie gubią przypisań do workspace’ów, podagenty pozostawiają czytelne ślady, a Web Shell zapewnia przejrzysty wgląd w artefakty. W tygodniu premiery scalono ponad 160 pull requestów w trzech wydaniach – v0.19.9, v0.19.10 i v0.19.11, a sam Web Shell doczekał się ponad 15 PR-ów.


    Źródła

  • Cline 4.0.0 przechodzi na architekturę SDK – wspólny runtime dla rozszerzenia i CLI

    Cline 4.0.0 przechodzi na architekturę SDK – wspólny runtime dla rozszerzenia i CLI

    Cline wypuściło wersję 4.0.0, która przenosi całą logikę działania z rozszerzenia VS Code do współdzielonego środowiska SDK. To znacząca aktualizacja, która stanowi fundament dla nowego modelu rozwoju narzędzia. Od teraz tury agenta, wykonanie narzędzi, koordynacja Plan/Act, serwery MCP, checkpointy, telemetria oraz historia zadań przechodzą przez tę samą warstwę bazową, niezależnie od tego, czy korzystasz z edytora, CLI, czy integrujesz SDK w swojej aplikacji.

    Zmiana eliminuje powielanie kodu między różnymi frontendami. Dla osób pracujących w nurcie vibe codingu i agentowego developmentu oznacza to przewidywalność. Zachowanie agenta w VS Code ma być identyczne jak w terminalu, ponieważ za obydwoma stoi ten sam runtime.

    Co niesie nowa architektura – kluczowe fakty

    • Współdzielone SDK (@cline/sdk, @cline/core, @cline/agents, @cline/llms, @cline/shared) zastępuje logikę wbudowaną dotąd bezpośrednio w rozszerzenie VS Code – warstwy są rozdzielone, a zależności płyną w dół od core do shared.
    • Nowy panel Customize wewnątrz rozszerzenia pozwala przeglądać i instalować wtyczki, serwery MCP oraz umiejętności (Skills) bez potrzeby edytowania plików konfiguracyjnych.
    • Kolejkowanie promptów w czacie sprawia, że wiadomości wysłane, gdy agent jest zajęty, nie przepadają – czekają w kolejce i można je anulować przed wykonaniem.
    • Konfiguracja providerów została scentralizowana wokół ustawień SDK, zamiast być rozproszona w opcjach dostępnych tylko z poziomu rozszerzenia.
    • Wydanie zawiera również łatki stabilizujące terminal, budżetowanie outputu narzędzi oraz uwierzytelnianie, ale wersja 4.0.1 szybko przywróciła kod rozszerzenia do stanu sprzed migracji (4.0.0), wycofując zmiany z powodu regresji – prace nad SDK są kontynuowane osobno.

    Marketplace i wtyczki – ekosystem, który zaczyna oddychać

    Rynek narzędzi dla AI-asystentów kodowania rozwija się, ale mało który edytor pozwala na tak swobodne rozbudowywanie funkcji bez pisania wrapperów. Cline wprowadza teraz panel Customize bezpośrednio w rozszerzeniu.

    Znajdziesz tam trzy kategorie: Skills, serwery MCP i Plugins. Te ostatnie to mechanizm rozszerzania Cline o własne narzędzia i przepływy pracy – w tym takie oparte o MCP. Pakiety wtyczek spod ~/.agents/plugins/* są automatycznie wykrywane, a ich umiejętności udostępniane jako plugin-name:skill-name. Całe zarządzanie włączaniem i wyłączaniem odbywa się teraz w ustawieniach huba, więc klient nie potrzebuje już własnego loadera ani osobnego przechowywania stanu.

    Co istotne, katalog .agents/plugins wewnątrz repozytorium roboczego jest celowo ignorowany. Otwarcie cudzego projektu nie uruchomi automatycznie kontrolowanych przez niego serwerów MCP – bezpieczeństwo jest priorytetem.

    To jeden z tych ruchów, które od razu widać w codziennej pracy. Koniec z ręcznym edytowaniem cline_mcp_settings.json, gdy chcesz podłączyć nowe źródło danych czy narzędzie.

    SDK jako warstwa integracyjna – nie tylko dla edytora

    SDK jako warstwa integracyjna – nie tylko dla edytora

    Opublikowana dokumentacja SDK opisuje je jako framework open source do budowania aplikacji agentowych. To ten sam kod, na którym działają rozszerzenia IDE i CLI. Architektura została rozbita na pakiety warstwowe – zależności idą od core w dół do agents, llms i shared, co wymusza czysty rozdział odpowiedzialności.

    Dla zespołów DevOps i osób automatyzujących przepływy pracy ma to konkretne zalety. Ten sam runtime agenta można teraz wykorzystać w integracjach CI/CD, skryptach czy własnych narzędziach bez przechodzenia przez edytor. Jest również RemoteEnvironmentService – nowy komponent SDK do uruchamiania sesji na zdalnym hoście przez SSH. Helper binarny ląduje na maszynie zdalnej, hub odpala się lokalnie, a tunel SSH łączy oba końce. Żadne hasła nie przechodzą przez połączenie – tylko klucze, a profil trzymany jest z uprawnieniami 0600.

    Nie jest to jeszcze podpięte pod GUI czy komendę CLI, ale jako klocek SDK już działa. Kto buduje własne narzędzia, zyskuje gotową ścieżkę do zdalnego wykonywania agenta na Linuksie i macOS (x64/arm64).

    Stabilność i regresje – cena ambitnej migracji

    Wydanie 4.0.0 pojawiło się 26 czerwca 2026 i niemal natychmiast ujawniło problemy. Na tyle poważne, że wersja 4.0.1 wycofała rozszerzenie do kodu sprzed migracji (4.0.0). To klasyczny scenariusz przy tak głębokiej przebudowie – nowa ścieżka runtime'u dotyka wszystkiego: od checkpointów po kompaktowanie historii i logowanie zdarzeń.

    Mimo to kierunek jest jasny. Zespół pracuje nad stabilnością SDK – obejmuje to m.in. retry modeli z exponential backoff, zmiany w indeksowaniu checkpointów, poprawki dla run_commands oraz zabezpieczenia w apply_patch. Szczegóły konkretnych wydań SDK nie zostały jednak potwierdzone w weryfikowalnych notach.

    To wszystko detale, które przy masowej migracji mają znaczenie między stabilnym narzędziem a frustracją. Na razie historia wersji mówi wprost: jeśli potrzebujesz niezawodności, korzystaj ze stabilnego kanału. Jeśli chcesz testować nową architekturę, SDK rozwija się równolegle, ale rozszerzenie VS Code wróciło tymczasowo do sprawdzonej bazy.


    Źródła

  • Claude SDKs zyskują trwały REPL: nowa era wykonywania kodu przez agentów AI

    Claude SDKs zyskują trwały REPL: nowa era wykonywania kodu przez agentów AI

    Anthropic zaktualizował wszystkie główne SDK Claude’a, wprowadzając narzędzie code_execution_20260120 jako nowy standard dla programistycznego wywoływania kodu przez agentów. Zmiana obejmuje Pythona, TypeScript, Go, Javę, a także Ruby, PHP i C#. Co istotne, nie wymaga już nagłówka beta na wspieranych modelach, chociaż dotychczasowe nagłówki beta pozostają dostępne.

    Najważniejsze fakty

    • code_execution_20260120 staje się minimalną wersją dla programmatic tool calling we wszystkich głównych SDK Claude’a.
    • Trwałość stanu REPL pozwala zachować zmienne i importy między komórkami wykonawczymi w ramach jednej sesji.
    • Brak wymaganego nagłówka beta – deweloperzy aktywują narzędzie, ustawiając type na code_execution_20260120; starsze nagłówki beta wciąż są akceptowane.
    • Wsparcie modeli obejmuje Claude Opus 3.5 i nowsze oraz Claude Sonnet 3.5 i nowsze.
    • Aktualizacja dotyczy również Ruby, PHP i C#, co czyni ją platformową zmianą.

    Koniec z resetowaniem stanu – REPL, który pamięta

    Dotychczasowe wykonywanie kodu przez Claude’a przypominało serię odizolowanych skryptów: każda komórka startowała z czystym środowiskiem, bez dostępu do zmiennych czy importów zdefiniowanych wcześniej. code_execution_20260120 zmienia to.

    Nowe narzędzie wprowadza trwałość stanu REPL (Read-Eval-Print Loop). Oznacza to, że gdy Claude tworzy zmienną w jednej komórce, może jej użyć w kolejnej – bez redeklaracji czy ponownego importowania bibliotek. Dla osób, które iteracyjnie debuguje kod, analizują dane lub budują wieloetapową automatyzację, to znaczna oszczędność czasu i zasobów.

    Szczególnie istotne jest to w przepływach agentowych, gdzie model sam planuje kolejne kroki. Claude może teraz najpierw wczytać dane, potem je przeanalizować, a na końcu wygenerować wizualizację – wszystko w jednej sesji REPL, bez potrzeby ponownego definiowania kontekstu przez użytkownika.

    Prostsza integracja, szerszy zasięg

    Prostsza integracja, szerszy zasięg

    Anthropic stawia na ujednolicenie ścieżek programistycznych. code_execution_20260120 nie jest już eksperymentalną funkcją schowaną za obowiązkowym nagłówkiem beta – to jedna z trzech wersji narzędzia do wykonywania kodu, wspierana przez SDK.

    Konfiguracja sprowadza się do jednego pola: type: "code_execution_20260120". Żadnych dodatkowych nagłówków ani warunkowych przełączników między wersjami. Deweloperzy w Pythonie, TypeScript, Go czy Javie mają identyczny interfejs, co ułatwia przenoszenie logiki agentów między językami i środowiskami.

    Warto również zauważyć, że lista wspieranych modeli jest precyzyjnie określona. Narzędzie działa na Claude Opus 3.5 i nowszych oraz Claude Sonnet 3.5 i nowszych. Starsze modele nie są wspierane, co sugeruje, że Anthropic traktuje code execution jako kluczową funkcjonalność w nowszych wersjach Claude’a.

    Co to znaczy dla web developmentu i DevOps

    Co to znaczy dla web developmentu i DevOps

    Dla zespołów budujących aplikacje webowe i potoki CI/CD ta zmiana ma kilka praktycznych konsekwencji. Persistent REPL umożliwia agentom Claude’a przeprowadzanie wieloetapowych analiz bez obaw o utratę kontekstu między krokami. Agent może na przykład pobrać logi z serwera, przefiltrować je, zbudować dashboard w Streamlit i zapisać wyniki – wszystko w jednym ciągłym przepływie.

    W kontekście vibe codingu, gdzie coraz więcej kodu powstaje w interakcji z AI, trwałość stanu REPL redukuje frustrację związaną z powtarzaniem tych samych instrukcji. Agent pamięta, co już zostało zrobione.

    Z perspektywy hostingu i środowisk uruchomieniowych nowe narzędzie jest lepiej przystosowane do sandboksów produkcyjnych. Standaryzacja wokół jednej wersji code_execution_20260120 ułatwia konfigurację polityk bezpieczeństwa, eliminując potrzebę obsługi wielu wariantów narzędzia z różnymi ograniczeniami.

    To nie izolowana funkcja – to kierunek platformy

    Anthropic nie przedstawia tej zmiany jako poprawki w pojedynczym SDK. Release notes mówią o aktualizacji platformowej, obejmującej cały ekosystem SDK – od Pythona po PHP. To sygnał, że code execution staje się fundamentem programistycznego interfejsu Claude’a.

    W połączeniu z Agent SDK (dostępnym dla Pythona i TypeScriptu), które udostępnia pętlę agentową Claude Code jako bibliotekę, code_execution_20260120 wpisuje się w szerszy trend: Anthropic buduje warstwę narzędziową, na której deweloperzy mogą tworzyć własne systemy agentowe – bez konieczności implementowania pętli narzędziowej od zera i bez problemów z nietrwałym stanem wykonania.

    Dla branży AI-assisted development to wyraźny krok w stronę produkcyjnej dojrzałości. Mniej boilerplate’u, więcej ciągłości i prostsza konfiguracja – to kluczowe elementy, których potrzebują zespoły wdrażające agentów AI w realnych projektach.


    Źródła

  • Aktualizacja Cursor SDK: własne narzędzia, automatyczny przegląd i zagnieżdżeni podagenci

    Aktualizacja Cursor SDK: własne narzędzia, automatyczny przegląd i zagnieżdżeni podagenci

    Cursor wprowadził w czerwcu 2026 roku znaczącą aktualizację swojego Cursor SDK, ogłoszoną w changelogu z 4 czerwca 2026. Nowa wersja dodaje trzy istotne funkcje dla zespołów pracujących z agentami poza IDE: możliwość definiowania własnych narzędzi w kodzie, konfigurowalny system automatycznego przeglądu dla wywołań lokalnych oraz wsparcie dla zagnieżdżonych podagentów. Te zmiany sprawiają, że Cursor SDK staje się istotnym narzędziem w automatyzacji CI/CD oraz w środowiskach produkcyjnych. Aktualizacja obejmuje zarówno TypeScript, jak i Pythona, a także wprowadza elastyczne opcje przechowywania metadanych agentów.

    Co nowego w pigułce

    • Własne narzędzia można teraz przekazywać jako definicje funkcji przez local.customTools, zamiast stawiać osobny serwer MCP.
    • Auto-review przekierowuje lokalne wywołania narzędzi przez klasyfikator, który decyduje o automatycznym wykonaniu lub wstrzymaniu do recenzji.
    • Zagnieżdżeni podagenci tworzą drzewa delegowanej pracy – recenzent może uruchomić pisarza testów, który uruchomi kolejnego agenta.
    • Opcje storage obejmują SQLite, JSONL oraz własne implementacje LocalAgentStore (Redis, Postgres, w pamięci).
    • TypeScript i Python – Cursor SDK działa w skryptach, pipeline'ach CI, backendach i botach.

    Własne narzędzia bez dodatkowej infrastruktury

    Do tej pory, aby dać agentowi dostęp do własnej funkcji, konieczne było uruchomienie serwera MCP. Aktualizacja to zmienia. Teraz wystarczy przekazać definicje funkcji przez local.customTools przy Agent.create() lub per wywołanie send().

    Cursor udostępnia te narzędzia przez wbudowany serwer MCP o nazwie custom-user-tools. Dzięki temu wykonanie podlega tej samej ścieżce uprawnień, co inne narzędzia MCP, eliminując potrzebę budowania osobnej warstwy integracyjnej. Narzędzia zdefiniowane raz są widoczne dla wszystkich podagentów rodzica. Definiujesz funkcję dla głównego agenta, a każdy podagent w drzewie może z niej korzystać bez dodatkowej konfiguracji.

    To znaczne ułatwienie dla zespołów web dev i DevOps. Przykładowo, w pipeline CI, gdzie agent potrzebuje dostępu do wewnętrznego API, systemu deploymentu lub narzędzia do migracji bazy danych, wystarczy zdefiniować funkcję raz i przekazać ją agentowi.

    Auto-review – kontrolowane zaufanie w trybie bezgłowym

    Gdy agenci Cursor SDK działają w trybie bezgłowym, normalnie wykonują wywołania narzędzi bez pytania o zgodę. Choć jest to wygodne, może być ryzykowne, zwłaszcza w środowiskach produkcyjnych.

    Flaga local.autoReview zmienia tę dynamikę. Zamiast bezwarunkowo ufać każdemu wywołaniu, Cursor przepuszcza je przez system recenzji. Klasyfikator decyduje, które wywołania są bezpieczne i mogą przejść automatycznie, a które wymagają zatrzymania i wglądu człowieka.

    Zachowanie klasyfikatora można dostosować instrukcjami w języku naturalnym w pliku permissions.json. Dwa kluczowe pola to autoRun.allow_instructions oraz autoRun.block_instructions. Można opisać, jakie operacje agent może wykonywać bez pytania, a które zawsze powinny trafić do recenzji.

    Dla zespołów CI/CD to bardzo praktyczne rozwiązanie. Agent zyskuje autonomię tam, gdzie jest to bezpieczne, ale w przypadku wrażliwych operacji, takich jak zmiany w produkcji czy operacje na bazie danych, system wstrzymuje akcję i czeka na decyzję.

    Zagnieżdżeni podagenci – drzewa zamiast list

    Zagnieżdżeni podagenci – drzewa zamiast list

    Do tej pory podagenci działali w sposób płaski – agent główny delegował zadania, ale same podagenty nie mogły delegować dalej. Teraz struktura może być bardziej złożona. Podagent może uruchomić własnego podagenta, a ten kolejnego.

    Cursor dokumentuje limity zagnieżdżeń, ale sama możliwość otwiera nowe wzorce. Recenzent kodu może delegować zadania do pisarza testów, który uruchamia agenta do generowania mocków, a ten z kolei do formatowania. Każdy poziom działa w swoim kontekście, ale dziedziczy dostęp do narzędzi rodzica.

    W praktyce to idealnie pasuje do skomplikowanych workflow: generowanie dokumentacji, wieloetapowe przeglądy kodu czy zadania operacyjne, gdzie każdy krok wymaga innego zestawu umiejętności.

    Gdzie to wszystko przechowywać

    Gdzie to wszystko przechowywać

    Cursor SDK oferuje teraz trzy opcje dla przechowywania metadanych agentów. SqliteLocalAgentStore zapisuje dane w SQLite w katalogu roboczym, co jest dobre dla lokalnych środowisk deweloperskich. JsonlLocalAgentStore tworzy przenośne pliki JSON (newline-delimited) w wybranym katalogu, co jest idealne do ephemeralnych jobów CI, gdzie nie ma potrzeby korzystania z bazy danych.

    Istnieje również LocalAgentStore jako interfejs, który można zaimplementować samodzielnie. Można użyć Redis, Postgres lub przechowywania w pamięci – wszystko, co pasuje do danej architektury.

    Co dalej z Cursor SDK

    Cursor SDK weszło do publicznej bety pod koniec kwietnia 2026, a już w maju pojawiło się wsparcie dla Pythona. Czerwcowa aktualizacja to kolejny krok w kierunku, który Cursor określa jako "agentami jako systemem" – autonomicznymi jednostkami, które budują i dostarczają oprogramowanie bez ciągłej interwencji człowieka.

    Dla zespołów AI, web dev i DevOps oznacza to mniej pracy związanej z integracją, większą kontrolę nad tym, co agenci robią w tle, oraz możliwość budowania wieloetapowych workflow, które wcześniej wymagały znacznej ręcznej orkiestracji. Cursor SDK działa w skryptach, pipeline'ach, backendach i botach – nie tylko w IDE.


    Źródła