W pracy z agentami AI najcenniejsze są ścieżki, które już raz przeszliśmy. Problem w tym, że bez ewaluacji każdy kolejny raz wygląda jak pierwszy. Trzy kroki, które zamieniają jednorazową pracę agenta w trwałe narzędzia MCP — i realnie tną zużycie tokenów.
Dlaczego wtórność to problem
W pracy agentowej — nieważne, czy programistycznej, czy biurowej — wielokrotnie wykonujemy wtórne zadania. Agent za każdym razem od zera rozwiązuje problem, który już raz rozwiązał. Odczyt plików PDF, opublikowanie artykułu, zbudowanie struktury aplikacji, raport z danych. Każde takie zadanie, zamiast być chwilą, jest pełnym cyklem: analiza → pisanie kodu → testy → debugowanie → sprzątanie.
Błąd: brak ewaluacji po zadaniu
Dużo osób popełnia ten sam błąd — po wykonaniu zadania nie ewaluuje procesu. Dostajemy wynik, zamykamy temat i idziemy dalej. To trochę tak, jakby napisać funkcję i nigdy nie wyciągnąć jej do osobnego modułu, żeby użyć jej ponownie w innym miejscu. Agent zapomina, my zapominamy — a następnym razem cała ścieżka zaczyna się od zera.
Dobra ewaluacja w trzech krokach
Jak zrobić ewaluację, żeby naprawdę nie powielać pracy?
- Poproś agenta, żeby prześledził cały swój proces i powiedział, na co poświęcił najwięcej czasu. To od razu pokazuje, gdzie pali się tokeny i gdzie leżą wąskie gardła.
- Poproś, żeby wypisał rzeczy, które są wtórne i które można zamienić w narzędzia. Agent sam najlepiej widzi, co wielokrotnie pisał od nowa.
- Poproś, żeby zbudował podręczny serwer MCP i dodał do niego te narzędzia. To ten moment, w którym wiedza przestaje być rozmową, a staje się kodem.
Czym jest narzędzie
Narzędzie rozumiemy tutaj jako już opracowaną przez agenta ścieżkę, która została utrwalona w jakimś kodzie. Na przykład agent miał zadanie, do którego napisał kod pozwalający odczytywać pliki PDF.
Nie chcemy, żeby agent za każdym razem pisał ten kod od nowa. Prosimy go więc, żeby utworzył z tego narzędzie w naszym podręcznym serwerze MCP. Od tego momentu odczyt PDF-a to jedno wywołanie, a nie dwadzieścia minut pracy.
Co to zmienia
Przebyta przez agenta ścieżka przestaje być jednorazowa — staje się utrwalonym, powtarzalnym rozwiązaniem. Następnym razem agent nie pisze kodu i nie liczy, tylko po prostu wykonuje narzędzie i odczytuje wynik. Mniej błędów, szybsze odpowiedzi, bardziej przewidywalne rezultaty.
Oszczędność tokenów
W szerszej perspektywie prowadzi to do zbudowania pakietu rzeczy, które ograniczają wykorzystanie tokenów przez agenta ekstremalnie mocno. Zamiast kilku tysięcy tokenów na analizę, kod i poprawki — kilkaset na samo wywołanie narzędzia. A mniej tokenów to też szybsza i tańsza praca, oraz mniejsza szansa na błąd po drodze.
I to się kumuluje: każde kolejne narzędzie sprawia, że następne zadanie jest prostsze. To efekt złożonego procentu.
Przykład z praktyki
Wrzucenie artykułu na tę stronę też kiedyś było wieloetapową robotą: poznawanie formatu API, składanie treści, deploy, regeneracja sitemapy. Dziś to jedno narzędzie — podajesz tytuł, treść i tagi, a cała reszta dzieje się pod spodem. Dokładnie ten sam mechanizm działa dla dowolnego powtarzalnego zadania agenta.
Zasady dobrych narzędzi
Kilka rzeczy, których nauczyło mnie budowanie własnego zestawu narzędzi:
- Jedno narzędzie = jedna odpowiedzialność. Lepiej dziesięć prostych narzędzi niż jedno rozbudowane, które robi „trochę wszystkiego”.
- Opis to połowa sukcesu. Agent decyduje, czy użyć narzędzia, na podstawie jego opisu. Dobry opis mówi, kiedy użyć, czego nie użyć i co zwraca.
- Parametry zamiast twardych wartości. Narzędzie bez parametrów to makro na jedną okazję; z parametrami staje się rozwiązaniem na całą klasę problemów.
- Testy i selfcheck. Narzędzie, którego nie można szybko zweryfikować, po cichu przestaje działać i agent wraca do pisania kodu od zera.
Pułapki
Nie wszystko, co wtórne, powinno stać się narzędziem. Uważaj na:
- Narzędzia bez dobrych opisów — agent ich nie użyje, bo nie będzie wiedział, kiedy sięgają.
- Przesadę — sto narzędzi to szum i koszt kontekstu. Lepiej dziesięć używanych.
- Zbyt wąskie narzędzia — rozwiązanie na dokładnie jedno zadanie, które się nie powtórzy.
- Zapominanie o utrzymaniu — narzędzie to kod, a kod wymaga czasem poprawki.
To nie tylko oszczędność — to pamięć
Narzędzia w serwerze MCP to też forma pamięci organizacji. Utrwalają know-how niezależnie od tego, który agent pracuje i czy rozmowa się zachowała. To wiedza, która zostaje w systemie, a nie w czyjejś głowie.
Podsumowanie
Każde powtórzenie w pracy agenta to sygnał, że rodzi się narzędzie. Ewaluuj proces po zadaniu, wyciągaj ścieżki do kodu, pakuj je w MCP — i obserwuj, jak kolejne projekty robią się coraz szybsze.
Budujcie i skalujcie ^^