Każde API zostanie przebudowane pod kątem agentów

MCP rozwiązuje problem połączenia. Nie rozwiązuje jednak luki czasownikowej.

Można opakować idealne API REST w MCP w jedno popołudnie. Nawet wtedy agent programistyczny będzie miał trudności. Wybierze niewłaściwy punkt końcowy. Wywoła trzy narzędzia, gdy wystarczyłoby jedno. Może nawet wykonać niszczącą operację zapisu bez pytania.

API nie jest zepsute. Jest po prostu zbudowane dla niewłaściwego odbiorcy.

Przez dwadzieścia lat API były budowane dla ludzi. Ludzie wnoszą intencję i model mentalny. Agenci nie wnoszą ani jednego, ani drugiego. Muszą odtworzyć oba te elementy na podstawie Twojego interfejsu.

Kiedy główny odbiorca zmienia się tak bardzo, interfejs również musi ulec zmianie.

Wierzę, że poważne interfejsy produktowe nie będą jedynie opakowywać istniejących API. Zostaną one przebudowane wokół operacji natywnych dla agentów.

Oznacza to przejście od API kształtowanych przez zasoby do kontraktów kształtowanych przez intencje. Musimy zaprojektować je na nowo, biorąc pod uwagę cele, stan, skutki uboczne, zatwierdzanie i odzyskiwanie danych.

MCP to świetny standard połączenia i transportu. Jednak w specyfikacji narzędzie to po prostu funkcja z nazwą i schematem. Nie decyduje ono o kolejności operacji ani o tym, które z nich są niebezpieczne.

To tworzy lukę czasownikową. API dostarczają agentom rzeczowniki i operacje CRUD. Agenci potrzebują czasowników, które niosą ze sobą intencję.

Spójrzmy na GitHub. Zawężają swój zestaw narzędzi, aby poprawić rozumowanie agentów. Uczą się, że mapowanie 1:1 z API produktu na narzędzia agenta nie działa.

Badania pokazują, że API może być poprawne strukturalnie, ale semantycznie bezużyteczne dla agenta. API natywne dla agentów odpowiada na więcej pytań niż tylko „co mam zwrócić”. Odpowiada na pytania:

  • Jaki jest cel?
  • W jakim stanie się znajduję?
  • Jakie są skutki uboczne?
  • Czy potrzebuję zatwierdzenia?
  • Jak przeprowadzić odzyskiwanie?

Zamiast surowego zapisu, potrzebujesz podziału na:

  • Podgląd akcji.
  • Uzyskanie wyraźnej zgody.
  • Zatwierdzenie zmiany.
  • Cofnięcie w przypadku niepowodzenia.

To nie jest tylko „wersja dla agentów”. To po prostu lepsze API. Deweloperzy również chcą podglądów, jasnych błędów uprawnień i możliwości wycofania zmian. Ostatecznie projektowanie natywne dla agentów zastąpi podejście skoncentrowane na człowieku.

Ta zmiana jest ogromna. Dotyczy API, CLI i logów. Musimy przejść od zrozumiałej dla człowieka prozy do stanu możliwego do przetworzenia przez maszynę.

Bezpieczeństwo to nie nakładka, którą dodaje się później. Bezpieczeństwo to cecha, którą projektuje się w samej operacji.

Źródło: https://dev.to/gyu07/every-api-will-be-rebuilt-for-agents-2hj4

Opcjonalna społeczność edukacyjna: https://t.me/GyaanSetuAi