Bob V2: szybszy, lepszy, mądrzejszy

Bob V2 jest ogólnie dostępny od 24 czerwca i to naprawdę odczuwalna zmiana w codziennej pracy: działa szybciej, może kontynuować zadania w tle, gdy zajmujesz się czymś innym, i opiera się na jednym agencie, który zachowuje się identycznie we wszystkich klientach. Ten agent trafia najpierw do Bob IDE, a Bob Shell pojawi się wkrótce po nim. Jedynym krokiem aktualizacyjnym jest zainstalowanie nowej wersji — istniejące ustawienia, pliki reguł i serwery MCP przenoszą się automatycznie.

Co znajdziesz w tym wpisie:

• Czym jest nowa architektura
• Zmiany odczuwalne w codziennej pracy: wydajność, nowe tryby, zadania w tle, rollback, praca z dokumentami oraz subagenty
• Workflows — framework do powtarzalnego wykonywania dużych, wieloetapowych zmian

Najpierw przetestowane na IBM

Pierwszym klientem Boba jest samo IBM, gdzie onboarding przeszło ponad sto tysięcy deweloperów pracujących na wszystkim — od systemów mainframe po usługi cloud-native. V2 trafił do dużej wewnętrznej grupy użytkowników na długo przed GA. Opisane tutaj funkcje były wdrażane stopniowo od początku maja, więc każda z nich miała za sobą prawdziwe użycie produkcyjne, zanim trafiła na zewnątrz.

Jeden agent, jeden harness, wiele klientów

Rozszerzenie IDE i shell w Bob V1 były zbudowane na dwóch osobnych podstawach. To była świadoma decyzja, żeby jak najszybciej dostarczyć Boba deweloperom — ale oznaczała, że każde ulepszenie trzeba było implementować dwa razy. A właśnie takie zmiany, jak te opisane powyżej, są najtrudniejsze do szybkiego dostarczenia w rozdzielonym kodzie.

V2 zastępuje to trójwarstwową architekturą, która wyraźnie oddziela logikę od infrastruktury i interfejsu:

Co zmienia się w codziennej pracy

Zanim przejdziemy do poszczególnych funkcji — zmieniła się sama powierzchnia, na której działają. Chat w V2 jest celowo spokojniejszy: pośrednie wywołania narzędzi i martwe ślady eksploracji zwijają się i znikają z widoku, więc na pierwszym planie zostaje praca i jej wyniki, a nie maszyneria za nią.

Subagenty: czyste utrzymanie kontekstu

Gdy Bob pracuje nad złożonym zadaniem, konwersacja zapełnia się odczytami plików, wyszukiwaniami i porzuconymi ścieżkami eksploracji. Większość tych szczegółów nie ma znaczenia dla głównego zadania, ale i tak pochłania okno kontekstu.

Subagenty rozwiązują ten problem. Gdy Bob musi zrobić coś samowystarczalnego — na przykład „rozgryź, jak działa uwierzytelnianie w tym kodzie" — uruchamia subagenta z własnym, czystym kontekstem. Subagent czyta pliki, śledzi wywołania i rozgryza wzorzec; do głównego agenta wraca tylko podsumowanie, a kroki pośrednie są odrzucane.

Równoległe, natywne wywołania narzędzi

W V1 wywołania narzędzi wykonywały się jedno po drugim: poproś o odczyt pliku, poczekaj na wynik, potem kolejne. Przy zadaniu rozchodzącym się na pięć odczytów plików i trzy wyszukiwania to oczekiwanie błyskawicznie się kumuluje. V2 pozwala modelowi poprosić o kilka narzędzi w jednej turze i uruchamia je równolegle. Zadanie, które w V1 zajmowało około 30 sekund, często kończy się poniżej 10.

Natywne wywołania narzędzi eliminują też pełne XML-a opakowania, którymi V1 otaczał każde żądanie narzędzia — to samo zadanie zużywa teraz mniej tokenów. Okno kontekstu jest również większe — wzrosło z 200k do 270k tokenów — więc dłuższe zadania biegną dalej, zanim uruchomi się kompakcja.

Trzy tryby: Agent, Plan, Ask

V2 łączy pięć starych trybów Boba w trzy:

• Agent — Bob podejmuje działania i kończy zadanie, z pełnymi możliwościami agentycznymi.
• Plan — Bob przechodzi przez opinionated proces planowania — zbiera wymagania, odkrywa kontekst, weryfikuje swoje rozumienie — i produkuje gotowy do działania plan do przekazania do Agenta.
• Ask — tylko do odczytu. Bob wyjaśnia architekturę i logikę bez ingerowania w kod.

Rada się nie zmieniła: przy nieznanym kodzie albo zmianie z dużym surface area zacznij od Ask lub Plan, a przełącz się na Agent, gdy praca jest już jasna.

Mniej przerw, ta sama kontrola

Operacje odczytu — czytanie plików, listowanie katalogów, przeszukiwanie kodu — są teraz domyślnie zatwierdzane, więc Bob może zbierać kontekst bez przerywania z pytaniem. Wszystko, co zmienia stan, nadal wymaga jawnego zatwierdzenia: edycje plików, wykonywanie poleceń, wywołania narzędzi MCP, wywołania skilli. Zatwierdzanie to jedna z kilku warstw — obok rollbacku, niestandardowych reguł i plików ignore — i można ją dostroić na poziomie klasy narzędzia.

Zadania w tle

Bob nie blokuje już sesji do jednej konwersacji. Deweloper może uruchomić kilka zadań jednocześnie, zostawić je w tle i dalej pracować. Każde zadanie ma własny wątek i kontekst, więc przełączanie między nimi zachowuje miejsce, w którym skończyłeś. Panel zadań pokazuje, co się wykonuje, co jest gotowe i co wymaga uwagi; zakończone zadania sprzątają po sobie. Bob nie wchodzi ci w drogę, gdy zadania działają — zadanie kończące się w tle nie odrywa twojej uwagi ani nie przełącza zakładki, nad którą pracujesz.

Rollback, przebudowany

W V1 ta funkcja nazywała się checkpoints i była zbudowana na git, co ją ograniczało: repozytorium bez git nie miało żadnych checkpointów, a bardzo duża historia spowalniała wszystko. V2 upraszcza całość i zmienia nazwę na rollback. Teraz śledzi stan plików bezpośrednio — per zadanie, per tura konwersacji, per pojedyncze wywołanie narzędzia — i każdy z tych punktów można przywrócić. Ponieważ rollback żyje w agencie, a nie w kliencie, działa tak samo niezależnie od tego, gdzie agent działa.

Praca z dokumentami

Wiele kontekstu do zadania żyje poza kodem — dokument projektowy, napisana specyfikacja, arkusz kalkulacyjny z przypadkami testowymi. V2 natywnie czyta pliki .docx, .pdf i .xlsx: wrzuć jeden do konwersacji, a Bob pracuje z nim bezpośrednio, bez kopiowania czy osobnego kroku ekstrakcji.

To samo dotyczy wyników. Na końcu zadania analitycznego Bob może wyprodukować pojedyncze, samowystarczalne podsumowanie HTML tego, co znalazł — jedna strona, otwiera się w każdej przeglądarce, nie wymaga żadnych narzędzi do odczytu. Wynik badania staje się czymś, co możesz przekazać komuś, kto nie był w sesji.

Istniejące konfiguracje przenoszą się

Wysiłek włożony w konfigurację innego AI narzędzia do kodowania powinien się przenieść, a nie zaczynać od zera. V2 odczytuje istniejące konwencje, pliki reguł, polecenia i serwery MCP, a dodatkowo obsługuje format pluginów, który stał się de-facto standardem w ekosystemie — popularne kolekcje narzędzi działają w Bobie bezpośrednio. Serwery MCP miały już własną zakładkę ustawień w V1; V2 dodaje obok niej dedykowaną zakładkę skilli, dzięki czemu skille można dodawać, konfigurować i usuwać w ten sam sposób, bez ręcznego edytowania plików.

Workflows: powtarzalne wykonywanie wieloetapowych zmian

AI świetnie radzi sobie z otwartymi problemami, ale słabo z robieniem tego samego dwa razy. Poproś go o „migrację do Java 21" w dwa różne dni, a możesz dostać dwa różne podejścia i dwa różne wyniki. Przy jednorazowym zadaniu to nie problem. Przy dużej pracy enterprise — modernizacji aplikacji mainframe, refaktoringu tysięcy plików, wszystkim, co przebiega w fazach — ta zmienność jest właśnie głównym problemem.

Workflows dają takiej pracy kręgosłup. Punktem wyjścia jest to, że nie każdy krok potrzebuje AI i nie każdy krok powinien być w pełni zautomatyzowany:

• Niektóre kroki to czysta automatyzacja — skanowanie zależności, uruchamianie testów.
• Niektóre potrzebują AI — złożone transformacje kodu, analiza wzorców.
• Niektóre potrzebują człowieka — zatwierdzenie strategii, przegląd diffów przed commitem.

Workflow definiuje, gdzie należy każdy krok. Silnik uruchamia kroki po kolei, przechowuje stan, obsługuje błędy i sprawia, że cały proces jest powtarzalny.

Tu wchodzą w grę pakiety premium IBM. Każdy zawiera przetestowane, opinionated workflows zbudowane na dziesiątkach lat pracy IBM w swojej dziedzinie, a każdy jest osobną ofertą z własnym wpisem, który nadejdzie: IBM Bob Premium Package for Java Modernization, Premium Package for IBM i oraz Premium Package for IBM Z. Przy GA dostępne workflows to te, które są dostarczane z Bobem i tymi pakietami; szersze możliwości tworzenia własnych otworzą się, gdy surface API ustabilizuje się z pierwszymi użytkownikami.

Co dalej

Ta sama architektura otwiera kierunki, które po prostu nie były możliwe na starej podstawie. Celowo nie przypisujemy do tego żadnych dat ani zobowiązań, ale szersze obszary, które eksplorujemy, to: zdalne uruchamianie agentów i dostęp do nich z dowolnego klienta, koordynacja wielu agentów przy jednym zadaniu oraz przenoszenie Boba na kolejne klienty. To, gdzie to faktycznie wyląduje, zostanie ukształtowane przez to, czego pierwsi użytkownicy potrzebują najbardziej.

Aktualizacja 24 czerwca

Bob V2 pojawia się 24 czerwca jako zwykła aktualizacja wersji. Zaktualizowanie rozszerzenia IDE przełącza je na nową architekturę; Bob Shell pojawi się wkrótce. Nie ma żadnych kroków migracyjnych; ustawienia, pliki reguł i serwery MCP przenoszą się automatycznie.

Jedna rzecz warta wypróbowania w pierwszym tygodniu: zacznij zadanie w trybie Plan, przekaż plan do Agenta i pozwól mu działać w tle obok innej pracy.

Linki

• Zainstaluj IBM Bob
• Dokumentacja
• Bob Shell
• Dobre praktyki
• Społeczność ↗