# Jak 76-krotnie obniżyliśmy koszty związane z agentem przeglądarki i sprawiliśmy, że działa on 5 razy szybciej, zachowując nienaruszoną pamięć podręczną > How Asana cut a browser agent’s cost 76x and made it 5x faster — by caching the full conversation history and pruning screenshots in batches instead of one at a time. Source: https://asana.com/inside-asana/cut-browsers-agent-cost ## Jak 76-krotnie obniżyliśmy koszty związane z agentem przeglądarki i sprawiliśmy, że działa on 5 razy szybciej, pozostawiając jego pamięć podręczną nienaruszoną _Badanie z wykorzystaniem GPT-6 Astra w Codex na czterech modelach, od analizy kodu po pomiar wyników_ ## **Dlaczego przeprowadziliśmy badanie** Asana wprowadza na swoją platformę automatyzację przepływów pracy agentów za pośrednictwem[StackAI](https://www.stackai.com/), a na skalę Asany nawet niewielkie niedociągnięcia mogą się kumulować. Naszym celem było sprawienie, aby jeden agent przeglądarki był tańszy i szybszy, bez obniżania jakości odpowiedzi. _„Tak właśnie wyglądają w praktyce zespoły ludzi i agentów. Inżynier wyznaczył kierunek, agent przeprowadził eksperymenty, a wyniki zostały przekazane przez Command do środowiska produkcyjnego. To pokazuje, w jaki sposób Asana tworzy zespoły złożone z ludzi i agentów”. –_**Arnab Bose, dyrektor ds. produktu w Asanie** ## **Co było nie tak** Agent przeglądarki przy każdym wywołaniu ponownie wysyła swoje narzędzia, monit systemowy oraz rosnącą historię tekstu strony i zrzutów ekranu. Buforowanie monitów obniża koszt powtarzających się danych wejściowych: w testowanych przez nas modelach odczyty z pamięci podręcznej kosztują od 0,05x do 0,1x standardowej ceny danych wejściowych. Jednak pamięć podręczna ponownie wykorzystuje tylko najdłuższy niezmieniony prefiks zlecenia. Nasz agent zapisywał w pamięci podręcznej swoje narzędzia i monit systemowy, ale nie historię, a samo zapisywanie historii w pamięci podręcznej nie pomogłoby: agent usuwał poprzedni zrzut ekranu na każdym etapie i skracał starszy tekst, aby zmieścił się w limicie historii. Każda edycja zmieniała wcześniejszą część żądania, więc ponowne użycie nie działało przy prawie każdym wywołaniu. ## **Rozwiązanie** Najpierw należy również zapisać w pamięci podręcznej historię, dodając znacznik pamięci podręcznej do najnowszego wyniku działania narzędzia. Po drugie, przestań edytować historię przy każdym wywołaniu. Usuwanie partiami polega na zachowywaniu zrzutów ekranu i usuwaniu ich partiami: przy proporcji 20:1 agent zachowuje do 20 zrzutów, a następnie redukuje ich liczbę do 1, więc podczas około 19 kolejnych wywołań ponownie wykorzystywana jest historia zapisana w pamięci podręcznej. Zwiększyliśmy również limit znaków w historii z 120 000 do 480 000, dzięki czemu stary tekst nie był już przycinany. Rysunek 2. Usuwanie zrzutów ekranu dla każdego kroku uniemożliwia ponowne użycie podczas każdej rozmowy; usuwanie zbiorcze pozostawia historię niezmienioną między krokami usuwania. ## **Jak to przeprowadziliśmy** GPT-6 Astra, działający w środowisku Codex, wykonał większość pracy: przeprowadził audyt kodu, instrumentował każde żądanie, przeprowadził szybkie testy w celu zidentyfikowania istotnych zmiennych, zrefaktorował kod, aby umożliwić równoległe wykonywanie przepływów pracy, uruchomił wykonania i przeanalizował ślady. Ludzie wyznaczyli cel i standardy oraz zweryfikowali wnioski.[Command](https://asana.com/product/command), platforma Asany do dostarczania oprogramowania, pełniła rolę systemu dokumentacji: rejestrowano w niej żądania, ślady i wyniki każdej sesji, dzięki czemu mogliśmy później przeanalizować całe badanie, a ustalenia stały się zgłoszeniami, pull requestami i zweryfikowanymi zmianami, które zostały wdrożone. **Nigdy nie przyszło mi do głowy, żeby zrobić to ręcznie, ponieważ prawdopodobnie zajęłoby mi to miesiące. Dzięki Codexowi zajęło to około tygodnia: przed pójściem spać wyznaczałem /cel, a rano przeglądałem wyniki.** **Teraz każda noc, w której nasze agenty nie działają, wydaje się być zmarnowaną nocą.** Przetestowaliśmy sześć zasad dotyczących buforowania i historii przy dwóch budżetach na modelu GPT-6.1 Sol oraz na trzech innych modelach najnowszej generacji – modelach A, B i C (tabela poniżej), przeprowadzając po trzy uruchomienia dla każdego warunku: 144 uruchomienia plus 12 uruchomień w ramach działań uzupełniających. Koszty obliczyliśmy na podstawie liczników tokenów każdego dostawcy, a każdą odpowiedź oceniliśmy w odniesieniu do niezależnie przygotowanego wzorca. **Model** **Co to jest** **Cena** **Model A** Mniejszy, tańszy model z innego laboratorium zajmującego się badaniami przełamującymi granice, wydany jesienią 2025 r. Połowa ceny GPT-6.1 Sol **Model B** Model pierwotnie używany w środowisku produkcyjnym, pochodzący z tego samego laboratorium co model A, wydany latem 2026 roku Taka sama jak GPT-6.1 Sol **Model C** Nowsza wersja modelu B, wydana jesienią 2026 roku Taki sam jak GPT-6.1 Sol **GPT-6.1 Sol** Model OpenAI Odniesienie ## **Wyniki** Rysunek 4. Koszt i czas na uruchomienie: pierwotna konfiguracja w modelu B w porównaniu z zoptymalizowanym agentem w modelach B i C oraz GPT-6.1 Sol. Średnie z trzech uruchomień; ograniczone uruchomienia bazowe sprawiają, że te wartości zmniejszenia są doW przypadku modelu B najlepszy warunek obniżył koszt na uruchomienie 29-krotnie i zapewnił 4-krotnie szybsze działanie w porównaniu z pierwotną konfiguracją produkcyjną. W przypadku modelu GPT-6.1 Sol ten sam agent kosztował 76 razy mniej i działał 5 razy szybciej, odczytując 89% danych wejściowych z pamięci podręcznej. W przypadku każdego modelu każde uruchomienie w najlepszych warunkach kosztowało mniej niż każde uruchomienie w warunkach bazowych i obejmowało wszystkie 192 fakty. ## **Wnioski** - **Budżet musi być dopasowany do modelu**. Nowsze modele szybciej wyczerpywały mniejszy budżet: model C po raz pierwszy skrócił swoją historię przy wywołaniu nr 10, a model A – przy wywołaniu nr 64. Przy 120 000 znaków model C nie udzielił odpowiedzi w żadnym z 18 uruchomień, a model Sol – w 3 uruchomieniach, przy czym w większości przypadków osiągnięto limit kroków; przy 480 000 znaków oba modele udzieliły odpowiedzi w każdym uruchomieniu. - **Samo buforowanie nie wystarcza**. Bez przycinania partii buforowanie historii przy większym budżecie kosztowało więcej niż jego brak w przypadku trzech z czterech modeli: pamięć podręczna była stale nadpisywana i rzadko odczytywana. ### **Czy w ogóle potrzebne jest przycinanie?** Dane dotyczące poszczególnych wywołań sugerowały, że w tym przypadku usuwanie może nie być konieczne, dlatego w ramach dalszych działań zachowano każdy zrzut ekranu. Koszt na wywołanie był 1,2 raza niższy niż w najlepszym warunku w przypadku modelu B i Sol oraz około 5% niższy w przypadku modelu C. Usuwanie nadal ma znaczenie w przypadku długich zadań, małych okien kontekstowych i droższych operacji odczytu z pamięci podręcznej. Przy trzech lub czterech uruchomieniach na warunek i liczbie wywołań różniącej się między uruchomieniami badanie to pokazuje ogólne wzorce, a nie rozróżnia warunków różniących się od siebie tylko o kilka procent. ### **Ograniczenia nadal mają znaczenie** Żadne uruchomienie nie osiągnęło limitu 480 000 znaków, więc nie stanowiło to ograniczenia dla tych uruchomień. Limity nadal mają znaczenie: agent, który się rozjeżdża, zbliża się do limitu kontekstu, a jeśli pamięć podręczna przestanie działać, każde wywołanie będzie wiązało się z pełną opłatą. Limity dotyczące kroków, tokenów i kosztu na uruchomienie ograniczają koszt nieudanego uruchomienia. Kompaktowanie to kolejna opcja, wykraczająca poza zakres niniejszego badania. ## **Od ustaleń do wdrożenia** Niektóre ustalenia pojawiły się później, gdy inne agenty przeanalizowały każdy ślad zarejestrowany w Command. Jest to trudne do wykonania w ramach jednej sesji, w przypadku której nie można mieć pewności, że wszystkie dane zostały zapisane. Przechowywanie wszystkich informacji w Command, do którego nasi agenci mieli dostęp za pośrednictwem MCP, oznaczało, że nigdy nie musieliśmy powtarzać eksperymentu w celu odzyskania brakujących danych, co przyspieszyło pracę. Ustalenia stały się zgłoszeniami dla ludzi i agentów kodujących, tam też sprawdzano pull requesty, a zmiany były wysyłane do StackAI. Po zakończeniu badania wykonaliśmy również to samo zadanie przy użyciu Codexa, który porównał swoje podejście z podejściem agenta StackAI i zasugerował drugą rundę ulepszeń, teraz w postaci zgłoszeń w Command. ## **Czego się nauczyliśmy** - Przechowuj w pamięci podręcznej rosnącą historię, a nie tylko monit systemowy. - Utrzymuj historię w trybie tylko dołączania; gdy konieczne jest usuwanie danych, rób to w dużych partiach. - Ustaw budżet historii odpowiednio do modelu. - Mierz liczbę odczytów z pamięci podręcznej na każde wywołanie, korzystając z własnych liczników dostawcy. - Prowadź pełny rejestr każdej sesji, aby analiza i dalsze prace opierały się na tym samym rejestrze. Asana tworzy narzędzia, dzięki którym takie eksperymenty staną się rutyną. [Pełne badanie](https://assets.asana.biz/asset/fb86cc8e-6611-4404-b7c6-172692a724bb/How-Asana-used-Codex-to-optimize-browser-agent-costs-and-runtime.pdf) obejmuje metody, wyniki i ograniczenia. **Szybkość dostawy nie jest już wąskim gardłem; takim wąskim gardłem jest ludzka uwaga. Myślę, że jesteśmy blisko świata, w którym każdy inżynier jest kierownikiem projektu zarządzającym zespołem agentów.** - [Mikroframeworki w Konsoli administratora](/pl/inside-asana/microframeworks-admin-console) inżynieria Każde wdrożenie Asany ma konsolę administratora. To właśnie w niej administratorzy IT konfigurują sposób, w jaki ich firma korzysta z Asany, na przykład dostosowując wymagania dot ... - [Rozwój oparty na specyfikacjach: pozytywne aspekty – i czego nauczyliśmy się po trzech miesiącach](/pl/inside-asana/spec-driven-development) inżynieria #### Inżynier oprogramowania – personel Po trzech miesiącach mieliśmy jaśniejszy obraz tego, kiedy dodana struktura była pomocna, a kiedy przeszkadzała.Jeden z naszych inżynierów przygotowywał migrację danych i zdecydow ... - [Przeprowadziliśmy migrację z Enzyme w 2 tygodnie. Powinno to zająć pięć lat.](/pl/inside-asana/migrating-off-enzyme-2-weeks) inżynieria Niedawno użyliśmy AI, aby ukończyć lata pracy inżynieryjnej w czasie około jednego sprintu. Oto, jak to zrobiliśmy i dlaczego zmieniło to nasze myślenie o tym, co jest możliwe.Pro ... - [Przełamanie śmiertelnej trójki: jak Asana myśli o bezpieczeństwie agentycznej sztucznej inteligencji](/pl/inside-asana/how-asana-thinks-about-agentic-ai-security) inżynieria #### Inżynier ds. bezpieczeństwa personelu Agentic AI wprowadza klasę zagrożeń bezpieczeństwa, których branża nie rozwiązała. Oto jak postrzegamy to w Asanie i jakie niezmienne zasady bezpieczeństwa stosujemy w odniesieniu ... - [W jaki sposób Asana wykorzystała Astra, Codex i Command, aby obniżyć koszty związane z agentem przeglądarki](/pl/inside-asana/cut-browsers-agent-cost) inżynieria Sztuczna inteligencja (AI) - [Dyrektor techniczny StackAI](/author/frank-hidalgo) Badanie z wykorzystaniem GPT-6 Astra w Codex na czterech modelach, od analizy kodu po pomiar wynikówDlaczego przeprowadziliśmy badanieAsana wprowadza na swoją platformę automatyza ... - [inżynieria](/inside-asana/engineering-spotlight)