Strona główna / Artykuły / Zrozumienie agentów sztucznej inteligencji poprzez analogię mózg-palec

Zrozumienie agentów sztucznej inteligencji poprzez analogię mózg-palec

Dowiedz się, jak modele językowe wielkich modeli, narzędzia oraz ich wykonywacze współpracują, mapując architekturę agenta na analogię zamawiania jedzenia, a następnie stwórz minimalną implementację agenta.

1513 słów

Przegląd

Prawdopodobnie spotkałeś się z takimi terminami jak „wywoływanie narzędzi” lub koncepcją, że agenci to po prostu modele językowe zintegrowane z narzędziami. Zamiast od razu przechodzić do definicji, ten tekst wykorzystuje znajomy codzienny scenariusz, aby wyjaśnić, co tak naprawdę dzieje się wewnątrz agenta AI. W trakcie przeczytania zobaczysz, jak modele językowe, narzędzia oraz element zwany wykonywaczem narzędzi współpracują ze sobą. Tekst ten jest skierowany do programistów, którzy chcą naprawdę zrozumieć mechanizmy działania agenta, a nie tylko powtarzać terminologię; później przejdziemy przez proces tworzenia minimalnego agenta, aby zobaczyć jego implementację w praktyce.

Analogia

Wyobraź sobie, że zamawiasz jedzenie przez aplikację dostawową. Przeanalizowanie tej zwyczajnej czynności pokaże, jak twój mózg i palec współpracują z aplikacją, aby zamówić posiłek, a następnie przełożymy każdy krok na terminologię związaną z agentami.

Zaczyna się od tego, że twój mózg poleca palcu uruchomić aplikację do zamawiania jedzenia abyś mógł przeglądać restauracje w pobliżu. Palec naciska ikonę, a na ekranie pojawia się lista restauracji.

Następnie twój mózg przejmuje się nazwami restauracji pokazanymi na ekranie i kieruje palec, by nacisnął konkretną restaurację i otworzył jej menu. Potem mózg przejrzuwa pozycje z menu i każe palcu nacisnąć przycisk „Dodaj” obok tych dań, które chcesz, umieszczając je w koszyku.

Gdy to zostanie zrobione, mózg sprawdza wszystko, co znajduje się w koszyku, aby upewnić się, że nic nie brakuje, a następnie poleca palcu nacisnąć „Zamówić”.

W końcu mózg rozpoznaje, że cel został osiągnięty, gdy tylko widzi ekran potwierdzenia zamówienia, a w tym momencie wzajemna komunikacja między mózgiem a palcem się kończy.

Analogia w języku agentowym

Zauważ coś ważnego w całej tej sekwencji: sam mózg nigdy nie wykonał bezpośrednio żadnej czynności — jedynie interpretował przychodzące informacje i mówił palcowi, co ma robić dalej. To odpowiada niemal dokładnie sposobowi działania agenta AI. LLM pełni rolę mózgu; czynności takie jak przeglądanie restauracji, otwieranie menu, dodawanie pozycji do koszyka i składanie zamówienia to narzędzia, których mózg potrafi używać; natomiast paliec odpowiada wykonawcy narzędzia, komponentowi, który faktycznie realizuje daną czynność.

Gdy tworzysz agenta do określonego celu, definiuj zestaw narzędzi i przekazuj tę listę LLM, który pełni rolę mózgu podejmującego decyzje. (Od teraz -> oznacza jeden krok przenoszący kontrolę do następnego.) Gdy użytkownik zadaje agentowi zadanie do wykonania, proces wygląda następująco: LLM analizuje bieżący krok lub pracę, która jeszcze pozostała, i wybiera najbardziej odpowiednie narzędzie –> przekazuje je wykonawcy narzędzia, prosząc go o uruchomienie i zgłoszenie wyniku –> LLM czyta ten wynik i sprawdza, czy spełnia on wymagania użytkownika. Jeśli tak, proces się tam kończy; w przeciwnym razie LLM wybiera następne odpowiednie narzędzie na podstawie najnowszego rezultatu, a pętla się powtarza, aż LLM stwierdzi, że zadanie zostało w pełni wykonane i nie są już potrzebne żadne dodatkowe wywołania narzędzi.

Wdrożenie

Gdy koncepcja jest już ustalona, kolejnym krokiem jest stworzenie małego agenta zdolnego do składania zamówień na jedzenie na podstawie żądań użytkownika. Poniższe fragmenty kodu pokazują rzeczywistą ścieżkę wykonywania przez agenta, a na końcu znajduje się link do pełnego repozytorium.

Narzędzia

get_restaurants() {
    // In production, replace with an API call such as GET /api/v1/restaurants
  return list of restaurants;
}

get_menu(restaurantName) {
    // In production, replace with an API call such as GET /api/v1/restaurants/${restaurantName or restaurantId}/menu
  return menuItems;
}

add_to_cart(sessionId, menuItemId) {
  // In production, replace with an API call such as POST /api/v1/cart
  return updatedCart;
}

place_order(sessionId) {
  // In production, replace with an API call such as POST /api/v1/order
  return orderDetails;
}

Zauważ, że te narzędzia to nic więcej niż zwykłe funkcje typu tych, które pisze się w codziennym kodzie aplikacji — nie zawierają one żadnej specjalnej ramy dla agentów ani logiki specyficznej dla LLM. W rzeczywistym środowisku produkcyjnym każde narzędzie miałoby dodatkowo nazwę, opis oraz zdefiniowany schemat wejściowy opisujący dane, których oczekuje. To właśnie nazwa i opis są wykorzystywane przez LLM do określenia, które narzędzie najlepiej pasuje do żądań użytkownika.

Egzekutor narzędzi

toolExecutor(toolCall) {
  const tool = toolNameMap[toolCall.name];

  return tool.execute(toolCall.arguments);
}

Sam wykonywacz narzędzia to po prostu kolejna zwykła funkcja. Jego argument toolCall zawiera informacje o wywoływanym narzędziu — jego nazwę oraz argumenty — a te różnią się w zależności od tego, które narzędzie jest wywoływane, czy to nazwa restauracji, ID pozycji z menu, czy coś zupełnie innego. Kluczowym punktem jest to, że gdy LLM podaje wykonywaczowi, jakie narzędzie ma uruchomić, przekazuje precyzyjne, ustrukturyzowane dane, takie jak nazwa narzędzia get_menu z argumentem {restaurantName: "Spicy Pizza"}. Nie ma potrzeby ręcznego wydobywania lub analizowania tych informacji z surowego tekstu wyjściowego LLM.

Agent

// Give all the tools to the LLM
llm = OpenAILLM.bindTools([get_restaurants, get_menu, add_to_cart, place_order])

// Take the user query to run the agent loop
reactAgent(userInput) {
  while (true) {
    response = llm(userInput);

    if (response.isFinalAnswer) {
      return response.answer;
    }

    result = toolExecutor(response.toolCall);

    userInput = response + result;
  }
}

Rzeczy do zauważenia w pseudokodzie

  1. Nazwa reactAgent odnosi się do wzorca promptowania ReAct (Reason and Act), w którym LLM decyduje, jakie narzędzie wywołać, obserwuje wynik tego wywołania, a następnie określa, czy konieczne jest uruchomienie innego narzędzia, czy też zadanie jest zakończone i pętla może zostać przerwana.
  2. Zwróć uwagę na pętlę while(true). To właśnie tutaj agenci różnią się od logiki warunkowej, którą zwykle pisze się w językach takich jak Java czy Python. Zamiast kodować bezpośrednio wywołania funkcji w gałęziach if-else lub pętlach for, udostępnia się LLM zestaw narzędzi — każde z nazwą i opisem — i pozwala samemu LLM podczas wykonywania decydować, które narzędzie wywołać dalej, jakie argumenty przekazać oraz kiedy praca jest zakończona i pętla powinna zostać zamknięta.
  • Mimo to systemy produkcyjne w rzeczywistości nie polegają na surowym pętli while(true); jest ona tutaj używana wyłącznie w celu zilustrowania podstawowego zachowania agenta w prostym kodzie. W praktyce należy skorzystać z frameworku orkiestracji, takiego jak LangGraph. Nawet przy użyciu takiego frameworku standardową praktyką jest ograniczenie głębokości rekurencji, aby model językowy nie mógł być wywoływany nieskończenie – pętla bez ograniczeń niesie ryzyko błędów, marnowania tokenów oraz niepotrzebnych kosztów.
  • Sprawdzenie response.isFinalAnswer w pseudokodzie sygnalizuje, że agent doszedł do pełnej odpowiedzi poprzez rozumowanie i nie są już potrzebne żadne dodatkowe wywołania narzędzi. Gdy to nastąpi, agent zwraca użytkownikowi streszczoną odpowiedź zamiast uruchamiać kolejne narzędzie.
  • Pewnie zauważyłeś również wiersz userInput = response + result, w którym połączony wynik jest ponownie wprowadzany do LLM jako response = llm(userInput) w kolejnej iteracji. Dzieje się tak, ponieważ każde wezwanie LLM jest bezstanowe — nie przechowuje żadnej pamięci o poprzednich krokach, nawet w ramach tej samej sesji lub interakcji z użytkownikiem. W rezultacie za każdym razem, gdy narzędzie kończy wykonywanie zadania, musisz ponownie wysłać całą historię rozmowy: instrukcje systemowe opisujące, jak agent powinien się zachować, oryginalne zapytanie użytkownika, wcześniejszą odpowiedź AI proponującą wywołanie narzędzia oraz wynik uzyskany przez to narzędzie. Następnie LLM przetwarza całą tę sekwencję, aby ocenić, czy cel został osiągnięty, czy potrzebne są dodatkowe wywołania narzędzi.
  • Diagram sekwencji wykonywania LLM i narzędzi

    Poniższy diagram pokazuje, w jaki sposób LLM wybiera następne narzędzie, jak jego wykonawca je uruchamia oraz jak ten cykl się powtarza, aż LLM stwierdzi, że zadanie zostało zakończone i nie ma potrzeby dalszego uruchamiania narzędzi.

    Opisany proces jasno ukazuje wzajemną wymianę informacji: LLM proponuje wywołanie, wykonawca je realizuje, wynik wraca do LLM, który albo proponuje kolejne wywołanie, albo zamyka pętlę podając ostateczną odpowiedź.

    Kod na GitHubie

    Dostępny jest repositorium z kodem początkowym, jeśli chcesz sam przetestować ten przykład i zobaczyć, jak agent działa w praktyce.

    Literatura pokrewna

  • Postępowe odkrywanie narzędzi dla agentów AI w skali przemysłowej — Wyjaśnia, dlaczego duże katalogi narzędzi pogarszają wydajność agentów AI oraz jak postępowe odkrywanie narzędzi przy użyciu manifestów i schematów typu just-in-time rozwiązuje ten problem.
  • Wywoływanie Claude, GPT i Gemini za pośrednictwem punktów końcowych kompatybilnych z OpenAI — Dowiedz się, jakie funkcje obsługują warstwy kompatybilne z OpenAI od Anthropic i Gemini, gdzie są one cicho pomijane oraz kiedy sensowne jest kierowanie ruchu do wszystkich trzech za pośrednictwem jednego bramy.