Zrozumienie agentów AI: wywoływanie narzędzi, MCP i pętla agenta

Gdy ludzie zaczynają badać agenty AI, wciąż pojawiają się te same kilka terminów we wszystkim:

Agenci. Narzędzia. Wywoływanie funkcji. MCP. Kontekst. Pamięć.

Na pierwszy rzut oka wyglądają one jak zbiór niespowiązanych technologii.

Jednak poświęcając wystarczająco dużo czasu na zbadanie sposobu budowy rzeczywistych systemów agentowych, szczególnie analizując opracowania inżynieryjne Anthropic na temat agentów i MCP, zaczyna wyłaniać się znacznie prostsza architektura podstawowa.

Ten artykuł omawia tę architekturę z praktycznej perspektywy skierowanej do programistów.

Czym właściwie jest agent w systemie AI?

Typowe aplikacje oparte na LLM można przedstawić w ten sposób:

User
  ↓
LLM
  ↓
Response

Tutaj model po prostu przyjmuje dane wejściowe i wytwarza wynik.

Jednak wiele rzeczywistych zadań nie da się rozwiązać wyłącznie poprzez generowanie tekstu.

Weźmy jako przykład tę prośbę:

„Przejrzyj ten repozytorium GitHub w poszukiwaniu otwartych problemów, skup się na tym, który jest najważniejszy, i przedstaw streszczenie tego, co nadal wymaga naprawy.”

Aby poradzić sobie z czymś takim, system musi:

1. Zrozumieć żądanie.
2. Decydować, jakie informacje są potrzebne.
3. Wybrać odpowiedni narzędzie.
4. Zapisać to narzędzie w działaniu.
5. Przeanalizować wynik.
6. Decydować, co robić dalej.
7. Potencjalnie wywołać inne narzędzie.
8. Stworzyć ostateczną odpowiedź.

Dokładnie tutaj pojęcie systemu agentowego okazuje swoją przydatność.

Anthropic wyznacza użyteczną granicę pomiędzy przepływami pracy a agentami.

Przepływ pracy przebiega według ustalonej sekwencji kroków:

LLM → Step 1 → Step 2 → Step 3 → Answer

Z kolei agent sam decyduje, jakie działania i narzędzia należy użyć:

             ┌──────────────┐
             │     LLM      │
             └──────┬───────┘
                    │
               choose action
                    ↓
                 Tool
                    ↓
                Result
                    │
                    └──────────→ LLM
                                  │
                             choose next action

Kluczowym elementem nie jest tylko to, że w jakimś momencie procesu bierze udział LLM.

Jest to fakt, że sam LLM ma wpływ na kształtowanie tego procesu.

Anthropic przedstawia agenty jako systemy, w których LLM aktywnie kieruje swoim własnym tokiem pracy oraz wykorzystaniem narzędzi, podczas gdy standardowe procesy opierają się na logice orkiestracji zdefiniowanej wcześniej przez programistę.

Zwielokrotniony LLM

Jedną z szczególnie przydatnych koncepcji przedstawionych przez Anthropic jest pojęcie zwielokrotnionego LLM.

Zamiast postrzegać LLM jedynie jako:

LLM → Text

można je postrzegać jako:

             ┌─────────────┐
             │     LLM     │
             └──────┬──────┘
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
    Retrieval     Tools        Memory

Zgodnie z tą koncepcją LLM uzyskuje możliwość wykraczania poza swoje własne ustawione parametry i interakcji z informacjami oraz zasobami pochodzącymi z zewnątrz.

Anthropic określa funkcje pobierania informacji, dostępu do narzędzi oraz pamięci jako formy wzmocnienia, które przekształcają zwykły model LLM w podstawowy element do budowania bardziej zaawansowanych systemów agentowych.

To ma znaczenie, ponieważ wyjaśnia, że sam model nie przemienia się magicznie w kompletny system oprogramowania.

To aplikacja otaczająca model dostarcza te dodatkowe możliwości.

Czym więc jest wywoływanie narzędzi?

Zanim przejdziemy do MCP, przydatne jest przyjrzenie się czemuś prostszemu.

Załóżmy, że dajemy modelowi LLM dostęp do narzędzia takiego jak:

get_weather(city)

Następnie użytkownik pyta:

">Jaka jest pogoda w Kolombo?"

Zamiast odpowiadać od razu, model może zwrócić się z prośbą o wywołanie funkcji:

{
  "name": "get_weather",
  "arguments": {
    "city": "Colombo"
  }
}

To otaczająca aplikacja faktycznie uruchamia tę funkcję.

Ta eksploatacja może zwrócić coś w rodzaju:

{
  "temperature": 29,
  "condition": "Partly cloudy"
}

To wynik jest ponownie wprowadzany do okna kontekstowego modelu.

Stamtąd model może wygenerować odpowiedź taką jak:

"Obecnie w Kolombo temperatura wynosi 29°C i jest częściowo pochmurno."

Kluczowym szczegółem jest tutaj:

LLM jedynie decyduje, że należy wywołać narzędzie. To aplikacja faktycznie je uruchamia.

Model nigdy nie nawiązuje bezpośredniego połączenia z samym serwisem pogodowym.

Wywoływanie narzędzi to nie MCP

To jest chyba najważniejsza różnica, którą trzeba zrozumieć w całej tej dziedzinie.

Wywoływanie narzędzi i MCP rozwiązują dwa różne problemy.

Wywoływanie narzędzi dotyczy zasadniczo wymiany informacji pomiędzy:

LLM
 ↓
Tool request
 ↓
Application
 ↓
Tool result

MCP natomiast to protokół zaprojektowany w celu standaryzacji sposobu, w jaki aplikacje AI łączą się z zewnętrznymi narzędziami, źródłami danych i kontekstem.

Anthropic opublikował MCP w listopadzie 2024 roku jako standard otwarty, mający na celu połączenie asystentów AI z systemami, w których znajdują się rzeczywiste dane i narzędzia.

Zgodnie z własną dokumentacją Anthropic, MCP standaryzuje sposób, w jaki aplikacje dostarczają kontekst do modeli LLM, a porównanie, jakiego używają, brzmi, że funkcjonuje on jak port USB-C dla aplikacji AI.

Podsumowując:

Tool Calling
     ↓
How an LLM requests an action

MCP
     ↓
How AI applications can standardize connections
to external tools and data

Innymi słowy, te dwa podejścia uzupełniają się wzajemnie, zamiast konkurować.

Co faktycznie dodaje MCP

Wyobraźmy sobie aplikację AI, która musi uzyskać dostęp do:

• GitHub
• PostgreSQL
• Google Drive
• Slack
• lokalnego systemu plików
• wewnętrznych API firmy

systemy monitoringu

Bez wspólnego protokołu każde z tych połączeń mogłoby wymagać własnego, dostosowanego do siebie układu przewodów. Można łatwo znaleźć się w sytuacji podobnej do tej:

AI Application
 ├── Custom GitHub integration
 ├── Custom Slack integration
 ├── Custom PostgreSQL integration
 ├── Custom filesystem integration
 └── Custom internal API integration

MCP interweniuje, definiując standaryzowany protokół, który znajduje się pomiędzy aplikacją AI a wszelkimi zewnętrznymi systemami dostarczającymi określone funkcje. Koncepcyjnie wygląda to mniej więcej tak:

                AI Application
                       │
                 MCP Client(s)
                       │
       ┌───────────────┼────────────────┐
       ↓               ↓                ↓
   MCP Server      MCP Server       MCP Server
    GitHub          Database          Files
       │               │                │
       ↓               ↓                ↓
    GitHub API      PostgreSQL       Filesystem

Dzięki takiemu rozwiązaniu aplikacja AI nie musi już posiadać dogłębnej, indywidualnej wiedzy o każdym systemie backendowym. Zamiast tego serwery MCP udostępniają swoje funkcje za pośrednictwem wspólnego warstwy protokołowej.

Architektura MCP

MCP jest zbudowany w oparciu o model klient-serwer-host. Na wyższym poziomie wygląda to tak:

┌─────────────────────────────────────┐
│              HOST                   │
│                                     │
│        AI Application               │
│                                     │
│    ┌──────────────────────────┐     │
│    │       MCP Client         │     │
│    └────────────┬─────────────┘     │
└─────────────────┼───────────────────┘
                  │
                  │ MCP
                  ↓
        ┌──────────────────┐
        │    MCP Server    │
        │                  │
        │  Tools           │
        │  Resources       │
        │  Prompts         │
        └────────┬─────────┘
                 │
                 ↓
        External System

Główne role w tej architekturze są opisane poniżej.

Host

Host to aplikacja AI odpowiedzialna za koordynację całej interakcji. Może to być coś takiego jak:

• asystent do programowania AI
• aplikacja AI dla komputera stacjonarnego
• narzędzie dla programistów
• aplikacja agenta stworzona na zamówienie

Klient MCP

Klient MCP znajduje się wewnątrz hosta i jest odpowiedzialny za utrzymanie żywej oraz sprawnej połączenia z serwerem MCP.

Server MCP

Server MCP to po prostu program, który udostępnia określone funkcje poprzez protokół MCP. Może on udostępniać możliwości związane na przykład z:

GitHub
Databases
Files
Cloud services
Internal systems
Development environments

Ważne jest to, że sam server MCP nie musi być agentem ani zawierać żadnego procesu rozumowania AI. Jego zadaniem jest jedynie udostępnienie określonych funkcji.

MCP to coś więcej niż tylko narzędzia

Jednym z elementów, które mogą łatwo wprowadzić ludzi w błąd, jest założenie, że MCP to nic więcej niż „protokół wywoływania narzędzi”. W rzeczywistości MCP definiuje kilka odrębnych elementów poza samymi narzędziami.

Narzędzia

Są to działania, które model może wykonać, na przykład:

create_issue()
search_repository()
query_database()
send_message()

Zasoby

Zasoby to informacje, które aplikacja może pobrać i przekazać modelowi jako kontekst, na przykład:

file://project/README.md
database://schema

Zapytania

MCP może również udostępniać wielokrotnie używalne szablony zapytań jako odrębny element.

Dokumentacja MCP firmy Anthropic wyraźnie rozróżnia, kto kontroluje każdy z tych elementów: narzędzia są kontrolowane przez model, zasoby przez aplikację, a zapytania przez użytkownika. To właśnie takie warstwowe zarządzanie sprawia, że MCP to coś więcej niż zwykły mechanizm wywoływania funkcji.

Pełny przykład

Weźmy na przykład takie zapytanie:

„Pokaż mi otwarte problemy w tym repozytorium GitHub.”

Społeczna wersja powstałego procesu mogłaby wyglądać w ten sposób:

User
  │
  │ "Show me the open issues"
  ↓
AI Application
  │
  ↓
LLM
  │
  │ decides a GitHub tool is needed
  ↓
Tool Call
  │
  ↓
MCP Client
  │
  │ MCP
  ↓
GitHub MCP Server
  │
  ↓
GitHub API
  │
  ↓
Issue Data
  │
  ↓
MCP Client
  │
  ↓
LLM
  │
  ↓
Final Answer

Zauważ, ile różnych warstw jest tu zaangażowanych. Model analizuje, jakie informacje są mu potrzebne. Aplikacja zajmuje się orkiestracją i wykonywaniem zadań. MCP dostarcza standaryzowany kanał do komunikacji z zewnętrznymi funkcjami. Sam usługę zewnętrzna wykonuje faktyczną pracę. To cztery odrębne obowiązki, a nie jeden połączony krok.

Gdzie mieści się Docker?

Często można zobaczyć serwery MCP pakowane i dostarczane jako kontenery Docker, na przykład:

AI Application
      │
      │ stdio
      ↓
Docker Container
      │
      ↓
MCP Server
      │
      ↓
External Service

Należy jasno zaznaczyć, że sam Docker nie jest MCP. Docker to po prostu jeden wygodny sposób na pakietowanie i uruchamianie serwera MCP. Ten sam serwer może równie łatwo działać jako zwykły lokalny proces lub być hostowany zdalnie jako usługa. Sam protokół jest całkowicie niezależny od sposobu, w jaki decydujesz się go wdrożyć.

STDIO vs Streamable HTTP

MCP funkcjonuje za pośrednictwem więcej niż jednego mechanizmu transportu.

Gdy integracja jest lokalna, klient MCP może uruchomić serwer MCP jako własny proces i komunikować się z nim za pomocą STDIO.

Koncepcyjnie:

AI Application
      │
      │ stdin/stdout
      ↓
MCP Server Process

W scenariuszach, w których serwer znajduje się zdalnie, MCP polega zamiast tego na Streamable HTTP.

AI Application
      │
      │ HTTP
      ↓
Remote MCP Server

Dzięki temu MCP sprawdza się zarówno wtedy, gdy narzędzia znajdują się na komputerze programisty, jak i wtedy, gdy działają jako usługa hostowana gdzie indziej.

MCP vs REST API

Kolejną różnicą, którą warto podkreślić, jest to, w jaki sposób MCP różni się od zwykłego API REST.

Interakcja z API REST wygląda w ten sposób:

Application
     │
     │ HTTP request
     ↓
REST API
     │
     ↓
Data

Interakcja z MCP wygląda w ten sposób:

AI Application
      │
      │ MCP
      ↓
MCP Server
      │
      ↓
REST API / Database / Filesystem / Other system

Ciekawe jest to, że serwer MCP może swobodnie korzystać z API REST w tle.

Zatem MCP nie ma na celu zastąpienia REST-u.

Lepiej go rozumieć jako warstwę przyjazną AI, umieszczoną na wierzchu istniejących już systemów.

Dlaczego MCP stał się interesujący

Rozmiar problemu integracji staje się oczywisty, gdy wyobrazi się sobie kilka aplikacji AI, z których każda musi komunikować się z kilkoma zewnętrznymi narzędziami.

Bez wspólnego protokołu otrzymuje się coś w rodzaju tego:

AI App A ───── Custom ───── GitHub
AI App A ───── Custom ───── Slack
AI App A ───── Custom ───── Database

AI App B ───── Custom ───── GitHub
AI App B ───── Custom ───── Slack
AI App B ───── Custom ───── Database

Każde nowe połączenie aplikacji z narzędziem może oznaczać konieczność pisania nowego kodu integracyjnego.

Wspólny protokół całkowicie zmienia tę sytuację:

MCP
                     │
        ┌────────────┼────────────┐
        ↓            ↓            ↓
     GitHub        Slack       Database
      MCP           MCP           MCP
     Server        Server        Server

To właśnie jest głównym powodem, dla którego Anthropic opublikował MCP jako standard otwarty, zamiast traktować go jako coś stworzonego wyłącznie dla Claude.

Od tamtej pory Anthropic rozszerzył MCP, aby obsługiwał serwery zdalne, oraz włączył bezpośrednią łączność MCP do swojego API i produktów.

Ale większa liczba narzędzi nie automatycznie czyni agenta lepszym

Tutaj późniejsze prace inżynieryjne Anthropic stają się naprawdę interesujące.

Latwo założyć:

Więcej narzędzi = bardziej zdolny agent.

To założenie w praktyce nie sprawdza się dobrze.

Badania Anthropic nad projektowaniem narzędzi pokazują, że agenci mogą w rzeczywistości wykonywać gorsze zadania, gdy otrzymują zbyt wiele narzędzi, które się nakładają lub nie zostały starannie zaprojektowane.

Dobrze zaprojektowany narzędzie powinno mieć jeden jasny cel i dostarczać przydatnych informacji, unikając jednocześnie niepotrzebnego obciążenia okna kontekstowego modelu.

Jako przykład, zamiast wykonywać trzy oddzielne wezwania w ten sposób:

list_users()
list_transactions()
list_notes()

bardziej skuteczne może być zapewnienie agentowi jednej połączonej funkcji, na przykład:

get_customer_context()

przy założeniu, że to lepiej odpowiada temu, co agent faktycznie próbuje osiągnąć.

Innymi słowy, sama interfejs narzędzia staje się częścią środowiska, w którym agent działa.

Narzędzia to interfejs dla agenta

To spostrzeżenie wskazuje na szerszą koncepcję, którą warto podkreślić:

Narzędzia powinny być tworzone z myślą o agencie, a nie tylko przerabiane na podstawie istniejącego API.

Konwencjonalne API może funkcjonować doskonale, gdy wywołuje je program deterministyczny.

Agenctwo napędzane LLM podlega jednak innym ograniczeniom.

Musi radzić sobie z:

• ograniczonym oknem kontekstowym
• wyjściami probabilistycznymi
• okazjonalnymi błędami przy wyborze odpowiedniego narzędzia
• okazjonalnymi błędami przy generowaniu poprawnych parametrów
• niejednoznacznością w tym, o co faktycznie chodzi

Z tego powodu sposób opisu narzędzia ma naprawdę duże znaczenie.

Rozważmy, jak niejasne jest to stwierdzenie:

search(id)

w porównaniu z tym, jak znacznie jaśniejsze jest to:

search_github_issues(
    repository,
    query,
    state
)

Aby model mógł dobrze używać narzędzia, musi wiedzieć:

• co narzędzie faktycznie robi
• kiedy jest to odpowiednie narzędzie do użycia
• co oznacza każdy parametr wejściowy
• w jakiej formie pojawia się wynik
• czego narzędzie nie potrafi zrobić

Wskazówki Anthropic dotyczące projektowania narzędzi kładą nacisk na precyzyjne nazewnictwo, jasne opisy, dobrze określone parametry, przydatne wyniki oraz ciągłą ocenę.

Kontekst staje się kluczową częścią projektowania agentów

Anthropic ostatnio podkreślił również koncepcję kontekstu w momencie potrzeby.

Naiwny sposób obsługi kontekstu wygląda następująco:

Load everything
      ↓
Put everything into context
      ↓
Ask the LLM to reason

Taki podejście szybko napotyka problemy z skalowalnością.

Bardziej trwały model wygląda tak:

Small amount of initial context
          ↓
Agent identifies what it needs
          ↓
Tool retrieves relevant information
          ↓
Relevant information enters context
          ↓
Agent continues

Zamiast wcześniej załadowywać wszystko, czego model może potrzebować, agent pobiera informacje dopiero wtedy, gdy stwierdzi, że są one rzeczywiście konieczne.

Anthropic przedstawił to jako krok w kierunku obsługi kontekstu „w momencie potrzeby” w systemach agentowych.

To bezpośrednio łączy się z MCP.

MCP zapewnia standaryzowaną ścieżkę do zasobów zewnętrznych, podczas gdy sam agent decyduje kiedy co pobrać i dokładnie co.

Pętla agenta

Gdy połączysz wszystkie te elementy, cała architektura zaczyna mieć znacznie większy sens.

Społeczna wersja pętli agenta wygląda tak:

              ┌──────────────┐
              │     User     │
              └──────┬───────┘
                     ↓
              ┌──────────────┐
              │     LLM      │
              └──────┬───────┘
                     ↓
              Need a tool?
                /       \
              No         Yes
              ↓           ↓
           Answer      Tool Call
                          ↓
                     Tool/MCP
                          ↓
                     Tool Result
                          │
                          └─────────┐
                                    ↓
                                   LLM
                                    │
                         ┌──────────┴──────────┐
                         ↓                     ↓
                      Continue              Answer

Ta pętla znajduje się w centrum dużej liczby obecnie używanych systemów agentowych.

Anthropic przedstawia to w niezwykle prosty sposób: agent to w istocie LLM, które w pętli wywołuje różne narzędzia, a informacje zwrotne z otoczenia kształtują jego dalsze działania.

System otaczający tę pętlę może stać się dość złożony, ale podstawowy mechanizm pozostaje prosty.

A co z frameworkami?

Frameworki takie jak LangGraph mogą ułatwić budowę takich systemów, dostarczając struktury, w ramach której można pracować.

Mimo to istnieje ważna uwaga, którą warto mieć na uwadze.

Zalecenie firmy Anthropic polega na zrozumieniu tego, co dzieje się pod spodem frameworku: surowych wywołań modeli językowych, definicji narzędzi, logiki orkiestracji oraz odpowiedzi, zamiast traktowania frameworku jako czarnej skrzynki.

Framework zazwyczaj udostępnia coś w rodzaju:

Agent
 ├── State
 ├── Nodes
 ├── Tools
 ├── Routing
 └── Execution

Lecz pod tą abstrakcją rzeczywista mechanika wygląda nadal tak:

LLM
 ↓
Messages
 ↓
Tool calls
 ↓
Tool execution
 ↓
Tool results
 ↓
LLM

Zrozumienie tego niższego poziomu procesów znacznie ułatwia rozumienie samego frameworku, ponieważ można zobaczyć, co on automatyzuje, zamiast po prostu ufać temu, że funkcjonuje poprawnie.

MCP nie zastępuje frameworków agentów

Należy jasno podkreślić, że są to różne warstwy systemu, a nie konkurencyjne opcje.

Społeczność uproszczona może wyglądać tak:

┌─────────────────────────────┐
│        User Interface       │
├─────────────────────────────┤
│       Agent / Workflow      │
├─────────────────────────────┤
│      LLM / Model API        │
├─────────────────────────────┤
│        Tool Calling         │
├─────────────────────────────┤
│             MCP             │
├─────────────────────────────┤
│   External Tools / Systems  │
└─────────────────────────────┘

Ramka agenta zazwyczaj zarządza takimi elementami jak:

• stan
• przepływ wykonywania
• drogowanie
• pętle
• próby ponowne
• wykonywanie narzędzi

Z drugiej strony MCP standaryzuje sposób łączenia się z zewnętrznymi funkcjami.

Wezwanie narzędzia daje modelowi mechanizm do żądania wykonywania określonej czynności.

Żaden z tych trzech elementów nie może zastąpić pozostałych.

Kilka powszechnych błędnych przekonań

"MCP to model AI."

To nieprawda.

MCP to protokół, nic więcej.

Nie ma on zdolności do generowania tekstu ani samodzielnego rozumowania.

"MCP zastępuje wywoływanie funkcji."

Również to nieprawda.

W rzeczywistości serwer MCP może udostępniać narzędzia, a aplikacja AI następnie prezentuje te narzędzia modelowi za pośrednictwem jego istniejącego mechanizmu wykorzystywania narzędzi.

"LLM bezpośrednio łączy się z GitHubem."

Zazwyczaj nie.

Model generuje jedynie żądanie dotyczące użycia narzędzia.

To aplikacja oraz otaczająca ją infrastruktura narzędzi faktycznie wykonują tę operację.

">Każdy serwer MCP wymaga Dockera."

Błędne.

Docker to tylko jeden z możliwych sposobów wdrażania serwera.

MCP dotyczy komunikacji i udostępniania funkcjonalności, a nie sposobu kontenerizacji czegoś.

">Serwer MCP to agent AI."

Niekoniecznie.

Serwer MCP może po prostu udostępniać proste, deterministyczne operacje, takie jak:

search()
read()
create()
update()
delete()

">MCP jest przydatny tylko dla GitHuba."

Daleka prawda.

MCP został stworzony jako protokół uniwersalny służący do łączenia aplikacji AI z zewnętrznymi danymi i możliwościami. Pierwotne ogłoszenie firmy Anthropic wskazywało już na integracje z systemami takimi jak GitHub, Slack, Google Drive, bazami danych oraz różnymi środowiskami programistycznymi.

Ważniejsza lekcja: inżynieria agentów to nie tylko inżynieria promptów

To bez wątpienia najważniejsza zmiana perspektywy wynikająca z analizy tych materiałów.

Budowa naprawdę przydatnych systemów agentowych to nie tylko kwestia:

Write a clever prompt
        ↓
Use a powerful model
        ↓
Get a smart agent

Zaangażowane są kilka odrębnych warstw inżynieryjnych:

Model
               ↓
        Tool Selection
               ↓
        Tool Definitions
               ↓
        Tool Execution
               ↓
        Context Management
               ↓
          State / Memory
               ↓
       Control / Guardrails
               ↓
          Evaluation

Sam tekst inżynieryjny firmy Anthropic coraz częściej podkreśla tę szerszą, na poziomie systemu, wizję tego, co faktycznie jest potrzebne do stworzenia agenta.

Jako przykład można podać ich najnowsze prace nad oceną agentów, które koncentrują się na analizie zachowań wieloetapowych, wykorzystania narzędzi, zmian w stanie oraz adaptacji z upływem czasu, zamiast oceniać jakość wyłącznie na podstawie końcowego fragmentu wygenerowanego tekstu.

To stanowi znacząco inny sposób podejścia do projektowania aplikacji AI.

Część, która wydaje mi się najciekawsza

Przejście, które ma tu znaczenie, nie polega właściwie na:

Chatbot → Agent

Dokładniej mówiąc:

LLM
 ↓
LLM + Tools
 ↓
LLM + Tools + External Context
 ↓
LLM + Tools + Context + Control Loop
 ↓
Agentic System

MCP wpisuje się w ten proces, zapewniając aplikacjom AI standaryzowany sposób na uzyskiwanie dostępu do zasobów zewnętrznych.

Model dostarcza inteligencję.

Aplikacja zapewnia kontrolę.

Narzędzia dostarczają działań.

Zewnętrzne systemy dostarczają informacji i możliwości z rzeczywistego świata.

MCP stanowi standaryzowaną warstwę łączącą aplikacje AI z tymi możliwościami.

Mój obecny model mentalny

Po przestudiowaniu mechanizmów wywoływania narzędzi, MCP oraz szerszych opracowań Anthropic na temat systemów agentowych, oto najprostszy obraz architektoniczny pokazujący, jak te elementy ze sobą współpracują:

USER
                           │
                           ↓
                    ┌─────────────┐
                    │     LLM     │
                    │             │
                    │ Reasoning   │
                    │ Decision    │
                    └──────┬──────┘
                           │
                    Tool request
                           │
                           ↓
                  ┌─────────────────┐
                  │ Agent Runtime   │
                  │                 │
                  │ State           │
                  │ Control Flow    │
                  │ Tool Execution  │
                  └────────┬────────┘
                           │
                           ↓
                     MCP / Tools
                           │
              ┌────────────┼────────────┐
              ↓            ↓            ↓
           GitHub       Database      Files
              │            │            │
              └────────────┼────────────┘
                           ↓
                    Tool Results
                           │
                           ↓
                          LLM
                           │
                           ↓
                         USER

Sam model nie stanowi całego agenta.

Również pojedyncze narzędzie nie wystarcza.

MCP również nie jest wystarczające.

To, co faktycznie otrzymujemy jako „agenta”, powstaje w ramach systemu otaczającego model – części, która umożliwia mu rozumowanie, podejmowanie działań, obserwację tego, co się dzieje, oraz dalszą pracę w kierunku celu.

Ostateczny wniosek

Jeśli zamierzasz budować agenty AI, warto dogłębnie opanować cztery kluczowe koncepcje:

1. Wywoływanie narzędzi

Model może poprosić aplikację o uruchomienie określonego narzędzia.

2. Pętle agenta

System może wielokrotnie analizować daną sytuację, podejmować wobec niej działania, obserwować rezultaty i kontynuować pracę od tamtego miejsca.

3. MCP

Standaryzowany protokół służący do łączenia aplikacji AI z zewnętrznymi narzędziami, zasobami i kontekstem.

4. Inżynieria narzędzi

Jakość twoich narzędzi, ich opisy, parametry, kontekst, który zwracają, oraz stopień ich oceny mogą w znacznym stopniu wpłynąć na efektywność działania agenta.

Pośrednio najcenniejszą lekcją płynącą z praktyki inżynieryjnej Anthropic jest następująca:

Nie dodawaj złożoności tylko dlatego, że możesz to zrobić.

Zacznij od najprostszej architektury, która jest w stanie rozwiązać przedstawiony problem. Wprowadzaj procesy pracy, dodatkowe agenty, kolejne narzędzia, pamięć, serwery MCP oraz inne komponenty tylko wtedy, gdy przynoszą one konkretną korzyść.

Celem nigdy nie było stworzenie najbardziej skomplikowanego możliwego agenta.

Celem jest stworzenie systemu, który niezawodnie wykona zadanie.

Powiązane materiały

• Zrozumienie agentów AI: cele, narzędzia, pamięć i pętla agenta — Przystępne dla początkujących wyjaśnienie różnic między agentami AI a chatbotami, obejmujące podstawowe komponenty, pętlę decyzyjną, poziomy autonomii oraz praktyczne zastosowania w rzeczywistym świecie.
• Ręcznie stworzona pętla narzędzi LangChain do porównywania aktualnych wskaźników giełdowych — Krok po kroku stwórz małego asystenta do porównywania cen akcji przy użyciu LangChain i dowiedz się o pętli tworzenia, powiązywania, wywoływania i wykonawania, która umożliwia modelom językowym żądanie aktualnych danych zamiast domyślania się ich wartości.