Agent local-first do prywatnej i opłacalnej pracy koncepcyjnej

Perplexity Portable Computer to agent działający w trybie local-first.

Cały stos działa lokalnie domyślnie. Model, środowisko wykonawcze (harness), konwersja i ścieżka znajdują się na maszynie użytkownika. Praca wymagająca kontaktu ze światem zewnętrznym, taka jak wyszukiwanie w sieci, łączniki lub eskalacja do silniejszego modelu doradczego w chmurze, jest wywoływana tylko w razie potrzeby i zawsze pod kontrolą użytkownika. Dzięki temu poufne dane nigdy nie opuszczają urządzenia bez zgody, a lokalne modele nie wiążą się z opłatami za wnioskowanie: system jest prywatny i opłacalny z założenia.

Skuteczny agent oparty na założeniu local-first wymaga, aby model i środowisko wykonawcze (harness) zostały zaprojektowane wspólnie. Uniwersalne środowiska wykonawcze zakładają istnienie modelu granicznego, który może przetwarzać długie konteksty, obsługiwać szeroki wachlarz narzędzi i planować w długiej perspektywie. Modele lokalne są mniej niezawodne przy takich wymaganiach. Zamiast prosić mały model o zarządzanie środowiskiem zbudowanym dla dużego, dostosowaliśmy je do siebie nawzajem: środowisko dopasowane do profilu capabilities modelu oraz model przeszkolony po zakończeniu wstępnego treningu (post-trained) tak, aby efektywnie z niego korzystać.

Wprowadzenie

Możliwości agentowe w ostatnich miesiącach szybko się rozwijały w szerokim zakresie zadań związanych z pracą koncepcyjną (knowledge-work). Chociaż te postępy przynoszą duże korzyści w zakresie produktywności i wydajności, stwarzają również dwa wyzwania.

Zużycie tokenów rośnie szybciej, a wraz z nim całkowite wydatki. Kiedy dostęp do inteligencji uzyskuje się za pośrednictwem interfejsów API modeli o zamkniętym kodzie źródłowym działających w zdalnych klastrach, prywatne informacje i własność intelektualna opuszczają urządzenie użytkownika przy każdym żądaniu. W miarę jak agenci skalują się w ramach poszczególnych przepływów pracy i całych organizacji, wydatki na tokeny i przepływ danych stają się coraz trudniejsze do kontrolowania.

Jednocześnie modele open-source poprawiają się w jeszcze szybszym tempie. Postęp jest najbardziej widoczny w bardzo małych i wydajnych modelach, takich jak NVIDIA Nemotron 3.5 Lightning (łącznie 30B parametrów), Qwen 3.6 (35B) i Qwen 3.8 (27B). Te małe modele oferują możliwości znacznie przewyższające ich wagę i są teraz zdolne do obsługi złożonych przepływów pracy opartych na agentach. Sprzęt do lokalnego wnioskowania rozwija się równolegle: systemy takie jak NVIDIA DGX Spark mogą teraz uruchamiać te modele lokalnie. Razem trendy te sprawiają, że w pełni lokalne działanie na urządzeniu staje się praktyczne, jednocześnie pozwalając użytkownikom na włączenie funkcji zewnętrznych w razie potrzeby, takich jak wyszukiwanie w sieci, łączniki czy eskalacja do modeli chmurowych.

To podejście oparte na zasadzie local-first umożliwia znaczne oszczędności kosztów, ponieważ lokalne wnioskowanie pozwala uniknąć opłat API za token. Naturalnie rozwiązuje ono również obawy dotyczące prywatności i własności intelektualnej: prywatne tokeny nigdy nie muszą być przesyłane do zdalnych klastrów i pozostają bezpiecznie w granicach urządzenia lokalnego.

W czerwcu przedstawiliśmy pierwszy hybrydowy lokalno-serwerowy orkiestrator wnioskowania, który decyduje, jakie zadania powinny być uruchamiane na urządzeniu, a jakie powinny trafiać do agentów w chmurze. Tutaj wyjaśniamy, jak zbudowaliśmy takiego agenta opartego na zasadzie local-first, w tym środowisko wykonawcze (harness) oraz modele zoptymalizowane pod kątem współpracy.

Przedstawiamy przegląd kluczowych decyzji projektowych, oceniamy Computer na tle popularnych uniwersalnych środowisk open-source (Hermes i Pi) w ramach trzech publicznych benchmarków oraz naszego wewnętrznego benchmarku Local Knowledge Work Bench. W naszym benchmarku, z modelem Qwen 3.8 27B uruchomionym na NVIDIA DGX Spark, Computer uzyskuje najwyższy wynik: 82,6% w porównaniu do 77,6% dla Pi i 74,0% dla Hermes. PPLX 27B, nasz model przeszkolony (post-trained) na bazie Qwen 3.8 27B, podnosi ten wynik do 85,4%.

Projektowanie środowiska wykonawczego (harness) wokół modelu lokalnego

Chociaż kompaktowe modele działające na urządzeniu są już dość wydajne, wciąż ustępują wydajnością większym modelom granicznym. Do skutecznego sterowania tymi modelami i niwelowania ich ograniczeń potrzebne jest starannie zaprojektowane środowisko wykonawcze (harness).

Popularne środowiska open-source, takie jak Pi i Hermes, okazały się uniwersalne: działają dobrze z szeroką gamą modeli o różnych rozmiarach i klasach. Nie są jednak zoptymalizowane pod kątem możliwości modeli uruchamianych na urządzeniu. Zaprojektowaliśmy lokalne środowisko wykonawcze (harness) specjalnie z myślą o tym scenariuszu, opierając się na kilku kluczowych zasadach.

Wydajność kontekstu

Głównym celem przy projektowaniu naszego środowiska wykonawczego (harness) było jak najlepsze wykorzystanie kontekstu modelu.

Mimo że modele uruchamiane na urządzeniu, takie jak Qwen 3.8 27B, oferują okna kontekstowe o wielkości 260 tys. tokenów, empirycznie zauważyliśmy, że zaczynają one napotykać trudności powyżej 100 tys. tokenów. Dlatego utrzymujemy podstawowe środowisko w zwięzłej formie: minimalny prompt systemowy i mały zestaw podstawowych narzędzi.

Wszystkie inne możliwości zostały zmodularyzowane w postaci umiejętności (skills) ładowanych i wyładowywanych w trakcie ścieżki działania. Zaprojektowaliśmy te umiejętności z myślą o typowych zadaniach związanych z pracą koncepcyjną: badaniach, nauce o danych (data science), wizualizacji danych, tworzeniu dokumentów, Inżynierii Oprogramowania i innych.

Środowisko obsługuje również kompresję kontekstu (context compaction), podsumowując przestarzały kontekst w przypadku wydłużenia się ścieżki działania, dzięki czemu model mieści się w swoim efektywnym oknie.

Łączniki jako narzędzia wiersza poleceń

Codzienna praca koncepcyjna często wymaga łączników, takich jak Gmail, GitHub, Outlook i Kalendarz Google. Zazwyczaj są one udostępniane w środowisku jako serwery MCP, których duże definicje narzędzi zużywają znaczną część kontekstu. Zamiast tego przekonwertowaliśmy najczęściej używane serwery MCP na kompaktowe, łatwe w użyciu narzędzia wiersza poleceń, uzupełnione o niestandardowe umiejętności (skills), które znacznie lepiej wykorzystują ograniczony efektywny kontekst.

Samoweryfikacja

Wydajność poprawia się również wtedy, gdy agent weryfikuje własną pracę. Weryfikacja dodaje dodatkowe kroki, ale znacznie poprawia ostateczne wyniki i istotnie zmniejsza dystans do modeli granicznych. Może być wyzwalana przez sam model lub przez zestaw mechanizmów kontrolnych (hooks), które monitorują poprawność ścieżki i żądają samoweryfikacji, gdy coś pójdzie nie tak.

Wykonanie w piaskownicy

Środowisko wykonawcze uruchamia narzędzia w piaskownicy na poziomie systemu operacyjnego na urządzeniu użytkownika. Granica ta ogranicza procesy, ścieżki systemów plików i dostęp do sieci zgodnie z określoną polityką. Ogranicza to zasięg potencjalnych szkód w przypadku błędnego polecenia. Jeśli piaskownica jest niedostępna, środowisko wyłącza się samo przed wywołaniem jakichkolwiek narzędzi, zamiast degradować działanie do wykonania poza piaskownicą.

Różni się to od środowisk open-source, takich jak Pi i Hermes, które domyślnie uruchamiają polecenia bezpośrednio z uprawnieniami użytkownika. W Computer izolacja jest zawsze włączona, nie wymaga konfiguracji, a narzędzia nie mogą działać bez niej.

Poniższy diagram pokazuje, jak te zasady współdziałają w pętli wykonawczej. Orkiestrator to deterministyczny kod środowiska, a nie model językowy (LLM): utrzymuje on pętlę, gromadzi kontekst i egzekwuje zasady. Model lokalny proponuje kolejne działanie; orkiestrator wykonuje zatwierdzone wywołania narzędzi w piaskownicy i zwraca ich wyniki do modelu. Wyszukiwanie w sieci, łączniki i wywołania doradcy przekraczają granicę urządzenia tylko wtedy, gdy są włączone i zatwierdzone.

Lokalne środowisko (harness) pozwala wycisnąć więcej z tego samego modelu

Używającego tego samego bazowego modelu na urządzeniu, porównujemy nasze lokalne środowisko wykonawcze z uniwersalnymi alternatywami pod kątem badań internetowych oraz multimodalnego zrozumienia dokumentów. Wszystkie środowiska używają modelu Qwen 3.8 27B ze średnim poziomem rozumowania, działającego na karcie NVIDIA DGX Spark. To porównanie pozwala odizolować możliwości wnoszone przez samo środowisko, jeszcze przed jakimkolwiek dodatkowym treningiem modelu.

Skupiamy się na tych dwóch możliwościach, ponieważ praca koncepcyjna często łączy prywatne dokumenty na urządzeniu użytkownika z publicznymi informacjami z sieci w celu wygenerowania ugruntowanego artefaktu. Wyszukiwanie w sieci wymaga łączności, ale wnioskowanie modelu i przetwarzanie prywatnych dokumentów pozostają lokalne. Pliki lokalne służą jako wiarygodne źródło, źródła publiczne dodają kontekst, a użytkownicy mogą całkowicie wyłączyć wyszukiwanie w sieci do pracy w trybie całkowicie offline.

Badania internetowe

Budujemy nasze lokalne środowisko (harness) obok wyszukiwarki Perplexity, która osiągnęła czołowe miejsca w niezależnych ocenach. Środowisko uzyskuje do niej dostęp za pośrednictwem interfejsu Search as Code.

Oceniamy jakość badań na 1266 zadaniach BrowseComp. Computer korzysta z infrastruktury wyszukiwania Perplexity wraz z naszym lokalnym środowiskiem, podczas gdy Pi i Hermes polegają na Brave, ich zalecanym dostawcy wyszukiwania. Computer osiąga dokładność na poziomie 66,7%, w porównaniu do 50,2% dla Pi i 43.9% dla Hermes.

Computer ma również najniższy średni zarejestrowany czas realizacji (wall time) i zużycie tokenów: 402,1 sekundy i 852 tys. tokenów na zadanie, w porównaniu do 1020,9 sekundy i 1,01 miliona tokenów dla Hermes oraz 826,0 sekund i 2,82 miliona tokenów dla Pi. Computer zużywa zatem o 61% mniej czasu realizacji i o 16% mniej tokenów niż Hermes oraz o 51% mniej czasu realizacji i o 70% mniej tokenów niż Pi.

Multimodalne rozumienie dokumentów na urządzeniu

Wiele dokumentów zawiera informacje w formie wizualnej i jest trudnych do sparsowania jako zwykły tekst: pliki PDF, zeskanowane strony, zrzuty ekranu, wykresy i prezentacje. Te przepływy pracy zależą od OCR oraz rozumienia obrazu i czerpią największe korzyści z natywnie multimodalnego modelu.

Środowisko przekazuje strony dokumentów i obrazy bezpośrednio do modelu, który je rozumie i łączy dowody wizualne z wyekstrahowanym tekstem. Przetwarzanie tych plików na urządzeniu zapewnia poufność wrażliwych dokumentów i wyekstrahowanych z nich treści.

Oceniamy multimodalne rozumienie dokumentów na ParseBench-100, 100-zadaniowym podzbiorze benchmarku ParseBench, obejmującym po 20 zadań dla wykresów, układu (layout), tabel, treści tekstowej oraz formatowania.

Computer osiąga średni wynik na poziomie 65,1%, w porównaniu do 34,6% dla Hermes i 13,9% dla Pi. Wykonuje również zadania w najkrótszym czasie i przy użyciu najmniejszej liczby tokenów: średnio 60,6 sekundy i 20,1 tys. tokenów na zadanie, w porównaniu do 108,3 sekundy i 32,1 tys. tokenów dla Hermes oraz 410,5 sekundy i 829,1 tys. tokenów dla Pi. Computer prowadzi we wszystkich pięciu kategoriach dokumentów, z największą przewagą w dziedzinie wykresów. Układ (layout) pozostaje trudny dla wszystkich trzech środowisk.

Tabela 1. Średni wynik ParseBench-100 według kategorii dokumentów dla środowisk Computer, Hermes i Pi z modelem Qwen 3.8 27B uruchomionym na urządzeniu. Computer prowadzi we wszystkich pięciu kategoriach.

Zmniejszanie dystansu do modeli granicznych za pomocą eskalacji do doradcy

Nawet przy starannie zaprojektowanym środowisku, najtrudniejsze zadania nadal przekraczają możliwości kompaktowego modelu na urządzeniu. W takich zadaniach środowisko udostępnia narzędzie doradcy: model lokalny może skonsultować się z silniejszym modelem granicznym, gdy potrzebuje pomocy w planowaniu, rozwiązywaniu niejednoznaczności, radzeniu sobie z powtarzającymi się błędami lub weryfikacji ostatecznego wyniku.

Model lokalny decyduje, kiedy poprosić o poradę, podczas gdy orkiestrator środowiska zachowuje uprawnienia do narzędzi i kontroluje, jaki kontekst jest wysyłany. Eskalacja jest opcjonalna. Użytkownik decyduje, czy ją włączyć oraz czy zatwierdzać każde wywołanie doradcy ręcznie, czy automatycznie.

Przed wywołaniem doradcy środowisko wybiera odpowiedni kontekst, stosuje klasyfikator PII w celu oznaczenia poufnych informacji i pokazuje użytkownikowi, co opuści urządzenie. Doradca otrzymuje tylko zatwierdzony kontekst i zwraca wskazówki tekstowe; nie ma bezpośredniego dostępu do plików, narzędzi ani konwersacji na urządzeniu. Poprawia to zarówno koszty, jak i prywatność, a w przyszłości planujemy dalsze zgłębianie tego kierunku.

Testujemy to podejście na wymagających zadaniach z zakresu Inżynierii Oprogramowania, które wymagają silnego rozumowania i w których model lokalny najczęściej sobie nie radzi. Do tego celu używamy Terminal Bench 2.1,popularnego benchmarku składającego się z 89 zadań dla agentów piszących kod.

Chcemy odpowiedzieć na dwa pytania: jaką część dystansu do modelu granicznego może zniwelować eskalacja do doradcy oraz jakim kosztem. Uruchomienie w pełni lokalnych modeli nic nie kosztuje, ponieważ wnioskowanie odbywa się na sprzęcie użytkownika. Jednakże gdy model zaczyna wywoływać doradcę, generuje koszty API.

Jako punkt odniesienia dla wydajności modeli granicznych stosujemy Claude Opus 5 działający w lokalnym środowisku; modelem lokalnym jest Qwen 3.8 27B. Wreszcie łączymy oba rozwiązania: Qwen 3.8 27B wykonuje zadanie i eskaluje problem do doradcy Claude Opus 5, gdy potrzebuje pomocy. Nie oceniamy eskalacji do doradcy z Pi lub Hermes, ponieważ żaden z nich nie zapewnia równoważnego narzędzia doradcy; dodanie takiego narzędzia wymagałoby modyfikacji powierzchni narzędzi i logiki orkiestracji, więc wynik nie reprezentowałby już gotowego środowiska.

Eskalacja do doradcy podnosi wynik Computer z 59,6% do 73,0%, co oznacza wzrost o 13,5 punktu procentowego, przy szacowanym koszcie API wynoszącym 0,415 USD na jedno uruchomienie (rollout). Uruchomienie samego Claude Opus 5 osiąga 82,4% przy koszcie 0,65 USD na uruchomienie. Eskalacja odzyskuje więc w przybliżeniu trzy piąte dystansu do modelu granicznego przy około dwóch trzecich jego kosztu, a użytkownik decyduje, czy ta wymiana jest tego warta.

Trening pooperacyjny (post-training) dla środowiska wykonawczego i pracy koncepcyjnej

Do tej pory utrzymywaliśmy model lokalny bez zmian, aby odizolować wkład samego środowiska. Po zaprojektowaniu środowiska wykonawczego największe pozostałe zyski pochodzą z dostosowania samego modelu. Dane o użyciu Perplexity Computer pokazują nam, co ludzie faktycznie robią w ramach pracy koncepcyjnej, i używamy ich do syntetyzowania danych treningowych. Przeprowadzamy trening pooperacyjny (post-train) modelu lokalnego wewnątrz środowiska Computer, kierując się rzeczywistym rozkładem zadań wykonywanych przez użytkowników.

Konkretnie identyfikujemy zróżnicowany zestaw przypadków użycia, które angażują różne zdolności modelu, narzędzia i łączniki. Na tej podstawie syntetyzujemy realistyczne środowiska uczenia ze wzmocieniem (reinforcement learning) i definiujemy wymagające, ale weryfikowalne zadania: każde zadanie składa się z instrukcji, środowiska oraz weryfikatora oceniającego ostateczny wynik, przy czym środowiskiem jest kontener Docker, w którym działa środowisko wykonawcze (harness). Co ważne, ponieważ zadania są syntetyczne, nie zawierają żadnych prawdziwych dokumentów ani informacji o użytkowniku.

Używamy tych środowisk do dwustopniowego treningu: dostrajania przez odrzucenie (rejection fine-tuning), po którym następuje uczenie ze wzmocieniem (reinforcement learning). W pierwszym etapie uruchamiamy model dla każdego zadania wielokrotnie, wybieramy najlepsze ścieżki na podstawie wyniku weryfikatora i trenujemy na nich metodą uczenia nadzorowanego. Ten etap inicjalizuje model dla konkretnego środowiska i rozkładu zadań. W drugim etapie uczenie ze wzmocieniem dodatkowo dostraja model, czyniąc go bardziej odpornym.

Podzbiór zadań jest wyłączany z treningu i używany do ostatecznej ewaluacji; nazywamy ten zestaw Local Knowledge Work Bench: 53 zadania obejmujące siedem kategorii codziennej pracy koncepcyjnej, od dogłębnych badań po tworzenie dokumentów. Wkrótce opublikujemy raport techniczny opisujący szczegółowo trening modelu i planujemy udostępnić ten benchmark ewaluacyjny jako open-source.

Przeprowadziliśmy trening pooperacyjny (post-train) modelu Qwen 3.8 27B za pomocą tego podejścia, tworząc model o nazwie PPLX 27B, i oceniliśmy go na Local Knowledge Work Bench. Z bazowym modelem Qwen 3.8 27B, Computer osiąga najwyższy wynik (82,6%, w porównaniu do 77,6% dla Pi i 74,0% dla Hermes) i zużywa najmniej tokenów (520 tys. wobec 681 tys. dla Pi i 634 tys. dla Hermes). Pi kończy zadania najszybciej, w 176 sekund na zadanie, w porównaniu do 218 sekund dla Computer i 292 sekund dla Hermes. PPLX 27B podnosi wynik Computer do 85,4% kosztem większej liczby tokenów (678 tys. w porównaniu do 520 tys.). Jego szacowany czas realizacji wynosi 250 sekund.

Tabela 2. Kategorie zadań w Local Knowledge Work Bench.

Wniosek

Nasze badania pokazują, że silny model open-source z wydajnym lokalnym sprzętem i dedykowanym dla nich środowiskiem wykonawczym (harness) poradzi sobie z prawdziwą pracą koncepcyjną przy niemal zerowym koszcie wnioskowania i bez konieczności opuszczania urządzenia przez poufne dane.

W różnych benchmarkach Computer dorównał lub przewyższył Hermes i Pi pod względem dokładności, uruchamiając Qwen 3.8 27B na karcie NVIDIA DGX Spark. Spośród trzech benchmarków raportujących opóźnienia i zużycie tokenów, Computer był najszybszy w BrowseComp i ParseBench-100 oraz zużył najmniej tokenów we wszystkich trzech; Pi był najszybszy w Local Knowledge Work Bench.

Zyski wynikają z podjętych przez nas decyzji. Zbudowaliśmy zwięzłe lokalne środowisko wykonawcze z umiejętnościami (skills), które ładują się na żądanie. Przekonwertowaliśmy łączniki na kompaktowe narzędzia CLI zamiast serwerów MCP. Wykonanie zostało zamknięte w piaskownicy ze względów bezpieczeństwa.

Wyniki pokazały również obszary, w których kompaktowe modele mają pole do popisu. Na przykład w wymagających zadaniach kodowania w Terminal Bench 2.1 model lokalny ustępuje modelowi granicznemu we wszystkich trzech środowiskach. Eskalacja do doradcy zwęża, ale nie zamyka całkowicie tej przepaści; w celu dalszego zwiększania wydajności wciąż potrzebne są ciągłe udoskonalenia możliwości modeli oraz sprzętu lokalnego.

Celem budowy środowiska wykonawczego (harness) i modelu z uwzględnieniem lokalnych ograniczeń jest zapewnienie użytkownikom wyraźnej kontroli nad tym, jakie informacje opuszczają ich maszyny. Dla użytkownika istnieją również korzyści kosztowe. Postrzegamy to jako część szerszej zmiany, w ramach której coraz bardziej zdolni agenci przenoszą się ze zdalnej infrastruktury na urządzenia indywidualne i lokalne. Oczekujemy, że postęp w dziedzinie chipów, modeli i urządzeń będzie stale poszerzał zakres pracy koncepcyjnej, z którą Portable Computer poradzi sobie lokalnie.