# Jak Postman zaprojektował Agent Mode do pracy z API

- Source: MechNext — https://mechnext.eu/pl/article/36-how-postman-designed-agent-mode-for-api-work
- Published: 2026-10-11
- Updated: 2026-10-11
- Category: Industry News
- Language: pl (Markdown in other languages: ?lang=en, ?lang=de, ?lang=sk, ?lang=zh, ?lang=ru)

> Artykuł AWS opisuje, jak Agent Mode łączy pracę z API z doborem narzędzi, obsługą kontekstu i zatwierdzaniem zmian. Według Postmana usługa działa na Amazon Bedrock.

9 października 2026 r. AWS Machine Learning Blog opublikował artykuł o tym, jak Postman uruchamia Agent Mode na Amazon Bedrock. Według artykułu Postman stworzył Agent Mode jako sposób pracy zaprojektowany z myślą o AI, obejmujący testowanie API, dokumentację, odkrywanie API oraz implementację. Opis skupia się na tym, jak agent wpisuje się w pracę z API i jak jego konstrukcja uwzględnia sytuacje, w których dostępnych jest wiele narzędzi i rodzajów kontekstu.

Postman podaje, że Agent Mode działa na Amazon Bedrock i korzysta z niego w celu zarządzanego dostępu do modeli bazowych. Są to informacje o architekturze przedstawione w artykule AWS; opis projektu i testów należy rozumieć jako relację Postmana zamieszczoną w tym artykule. To rozróżnienie ma znaczenie przy interpretacji liczb: artykuł przedstawia wzorce opisane przez Postmana, ale nie stanowi ich niezależnego potwierdzenia.

### Dobór narzędzi jako element projektu

Jednym z omawianych problemów jest rozmiar zestawu narzędzi dostępnego dla agenta. W testach Postmana błędy doboru narzędzi zwiększały się, gdy widoczny zestaw przekraczał około 40 narzędzi. Artykuł opisuje proces, który zawęża ponad 170 narzędzi do około 15 związanych z daną prośbą, a następnie przekazuje je podagentowi z odizolowanym kontekstem.

Praktyczny sens tego podejścia polega na tym, że agent nie musi przy każdej prośbie korzystać z pełnego katalogu. Najpierw ogranicza się dostępne możliwości, a następnie podagent otrzymuje mniejszy zestaw narzędzi dopasowany do zadania. Artykuł łączy wielkość widocznego zestawu z trafnością wyboru w testach opisanych przez Postmana. Podane wartości są przybliżone i odzwierciedlają wyniki raportowane przez firmę; nie należy traktować ich jako uniwersalnego progu dla każdego systemu agentowego.

Postman opisuje także zmianę sposobu udostępniania API Catalog. Wiele wąskich widoków katalogu połączono w jedno narzędzie zapytań. Agent może tworzyć zapytania na podstawie schematów bazowych tabel ClickHouse. Według artykułu pozwala mu to pracować z danymi katalogowymi za pomocą zapytań, a narzędzie udostępnia te dane zgodnie ze schematami tabel.

### Kontekst przygotowany dla agenta

Kolejną zmianą jest zastosowanie dedykowanych handlerów kontekstu. Postman twierdzi, że dotychczasowy model danych interfejsu był przygotowany do renderowania i przesyłania danych, a nie do rozumowania agenta. Dedykowane handlery przygotowują więc kontekst w formie przeznaczonej dla Agent Mode. Pomaga to wyjaśnić, dlaczego agent może potrzebować osobnej ścieżki kontekstu, nawet jeśli produkt ma już interfejs i ustalony model danych.

Interfejs i agent mogą korzystać z tych samych obszarów produktu, a mimo to wymagać innego uporządkowania informacji. W opisie Postmana obsługa kontekstu jest zatem częścią projektu Agent Mode, a nie tylko inną nazwą istniejącego przesyłania danych. Artykuł przedstawia to rozwiązanie jako odpowiedź na różne cele renderowania interfejsu i rozumowania agenta.

### Zatwierdzanie i żądania w tle

Artykuł podaje, że Agent Mode wymaga zatwierdzenia przez użytkownika przed działaniami zmieniającymi stan aplikacji. Może także wysyłać żądania w tle, gdy żadna karta nie jest otwarta, nadal wymagając zatwierdzenia. Są to dwa odrębne aspekty działania: żądanie może być obsługiwane bez otwartej karty, ale działanie zmieniające stan aplikacji wciąż podlega opisanej w artykule zgodzie użytkownika.

Do kierowania żądań Postman wykorzystuje, według artykułu, wnioskowanie międzyregionalne Amazon Bedrock. Żądania są kierowane między regionami docelowymi określonymi przez profil wnioskowania. Artykuł opisuje to kierowanie regionalne jako część działania Agent Mode. Zestaw regionów docelowych określa profil; opis nie mówi, że każde żądanie może trafić do dowolnego regionu.

Postman informuje również o skonfigurowaniu zerowej retencji danych dla obsługiwanych modeli Agent Mode, z parametrem `data_retention_mode` ustawionym na `none`. Dostępność i zachowanie zależą od modelu. Stwierdzenie dotyczy więc modeli obsługujących to ustawienie i nie powinno być rozszerzane na każdy model wykorzystywany przez Agent Mode.

### Ponowne wykorzystanie kontekstu promptu

Według artykułu Agent Mode korzysta z buforowania promptów Amazon Bedrock: dla niemal niezmiennej podstawowej treści promptu stosuje godzinny punkt kontrolny, a dla bardziej zmiennego kontekstu punkt pięciominutowy. Opis rozróżnia stabilniejszą część promptu od informacji, które zmieniają się częściej. Są to interwały podane dla konfiguracji Postmana, a nie twierdzenie, że takie same okresy pasują do każdej aplikacji.

Łącznie te szczegóły przedstawiają Agent Mode jako system, w którym Postman deklaruje obsługę doboru narzędzi, przygotowania kontekstu, zatwierdzania zmian i dostępu do modeli. Artykuł AWS pokazuje, jak Postman wyjaśnia swój projekt do pracy z API: agent otrzymuje zawężony zestaw odpowiednich narzędzi, kontekst jest przygotowywany do rozumowania, żądania działające w tle zachowują wymóg zatwierdzania, a Bedrock zapewnia dostęp do modeli i kierowanie między regionami. Wszystkie te szczegóły pozostają relacją firmy przedstawioną w artykule.