Mapa protokołów agentowych — MCP, A2A, WebMCP, NLWeb i gdzie każdy pasuje

Mapa protokołów agentowych — MCP, A2A, WebMCP, NLWeb i gdzie każdy pasuje

przez Łukasz | cze 5, 2026

Przejdź do Strefy Agent-Readiness
Sprawdź inne narzędzia AI

MCP. A2A. WebMCP. NLWeb. ANP. AP2.

Jeśli śledzisz Agentic Web od kilku miesięcy, te skróty pojawiają się coraz częściej i coraz bardziej przeplatają się w jednym akapicie. Brzmi jak ekosystem który urósł szybciej niż dokumentacja.

Ten artykuł rysuje mapę. Nie tłumaczy każdego protokołu od zera — do tego służą wcześniejsze artykuły serii i Słownik Agentic Web. Tłumaczy relacje: który protokół rozwiązuje który problem, gdzie się pokrywają, gdzie się uzupełniają, i co wdrożyć w jakiej kolejności.

Cztery pytania które porządkują mapę

Zanim porównania — cztery pytania które każdy protokół musi odpowiedzieć:

Kto komunikuje się z kim? Agent z narzędziem? Agent z agentem? Agent ze stroną? Strona z agentem?

Gdzie działa połączenie? Po stronie serwera, w przeglądarce, przez sieć między organizacjami?

Co jest jednostką wymiany? Wywołanie funkcji, zadanie, pytanie w języku naturalnym, manifest?

Kto to zdefiniował i kto adoptował? Anthropic, Google, Microsoft, W3C — każdy ze swoją społecznością i tempem adopcji.

MCP — warstwa narzędziowa

Kto z kim: agent ↔ narzędzie / serwis zewnętrzny

Problem który rozwiązuje: agent chce użyć zewnętrznego narzędzia (baza danych, API, system plików, kalkulator) bez pisania osobnego konektora dla każdego narzędzia.

Jak: serwer MCP wystawia Tools, Resources i Prompts przez JSON-RPC. Klient MCP (agent) wywołuje narzędzia przez standardowy protokół. Jeden klient działa ze wszystkimi serwerami. Jeden serwer działa z wszystkimi klientami.

Transport: stdio (lokalnie) lub Streamable HTTP (przez sieć).

Kto stworzył: Anthropic. Pod Linux Foundation od grudnia 2025. Adoptowany przez OpenAI, Google, Microsoft.

Stan adopcji: 97 milionów pobrań SDK miesięcznie. Ponad 5800 serwerów w ekosystemie. Claude Desktop, ChatGPT, Gemini, Cursor, VS Code — wszystkie obsługują MCP po stronie klienta.

Gdzie nie działa: między agentami (do tego A2A). W przeglądarce dla konkretnej strony (do tego WebMCP).

A2A — warstwa orkiestracji

Kto z kim: agent ↔ agent

Problem który rozwiązuje: masz wiele agentów AI — jeden do obsługi klientów, drugi do analizy danych, trzeci do raportowania. Jak delegują sobie zadania bez custom kodu dla każdej pary?

Jak: każdy agent publikuje AgentCard pod /.well-known/agent.json — plik JSON który opisuje co agent potrafi, jak się z nim komunikować, jakich danych potrzebuje. Orkiestrator czyta AgentCards i deleguje Task — ustrukturyzowane zlecenie z wejściem, oczekiwanym wyjściem i statusem. Zadania mogą być synchroniczne lub asynchroniczne (agent pracuje godzinami, orkiestrator sprawdza status i odbiera wynik).

Transport: HTTP, standard request-response lub long polling dla async.

Kto stworzył: Google. Pod Linux Foundation. Ponad 50 partnerów przy premierze (Salesforce, SAP, Workday, Atlassian i inni).

Stan adopcji: wczesna faza. Integracje enterprise dostępne od połowy 2025. Shopify, Stripe ogłosiły wsparcie. W ekosystemie enterprise szybko rosnące.

Relacja z MCP: komplementarne. A2A koordynuje pracę między agentami. Każdy z tych agentów używa MCP do połączenia z narzędziami. Stos pełny = MCP + A2A.

Gdzie nie działa: dla narzędzi zewnętrznych (to MCP). W przeglądarce (to WebMCP).

WebMCP — warstwa przeglądarkowa

Kto z kim: agent ↔ strona internetowa w przeglądarce

Problem który rozwiązuje: agent który chce coś zrobić na stronie internetowej musi dziś klikać w piksele przez Playwright — kruche, wolne, kosztowne. WebMCP pozwala stronie zadeklarować co potrafi zrobić jako zestaw narzędzi.

Jak: dwa API przeglądarkowe.

Declarative: dodajesz atrybuty do formularzy HTML:

html
<form toolname="search_flights"
      tooldescription="Wyszukaj loty">
  <input name="origin">
  <input name="destination">
</form>

Imperative: JavaScript rejestruje narzędzie przez navigator.modelContext.registerTool(...). Agent wywołuje navigator.modelContext.getTools() żeby zobaczyć co strona potrafi, potem wywołuje narzędzia jak funkcje.

Transport: przeglądarkowy — działa tylko gdy użytkownik ma stronę otwartą w Chrome/Edge z obsługą WebMCP.

Kto stworzył: Google (inicjatywa), wspólnie z Microsoftem. Inkubowane przez W3C Web Machine Learning Community Group. Chrome 146 Canary (za flagą), Edge 147.

Stan adopcji: eksperymentalny. Brak stable release. Firefox i Safari — bez ogłoszonych planów. Cloudflare udostępnił WebMCP w Browser Run. Produkcyjne wdrożenia: 2026 Q3-Q4 jako najwcześniejsza realistyczna data.

Kluczowa różnica od MCP: WebMCP działa TYLKO w przeglądarce, TYLKO gdy użytkownik ogląda stronę. MCP działa niezależnie od przeglądarki, przez sieć, 24 godziny. Google opisuje to tak: „MCP to infolinia firmy. WebMCP to ekspert w sklepie.”

Gdzie nie działa: po stronie serwera (to MCP). Między agentami (to A2A).

NLWeb — warstwa konwersacyjna strony

Kto z kim: agent → strona (pytanie w języku naturalnym)

Problem który rozwiązuje: agent chce wiedzieć co strona oferuje, ale nie chce parsować HTML ani czekać na WebMCP. NLWeb wystawia endpoint /ask — agent pyta po polsku lub angielsku, strona odpowiada JSON-em.

Jak: strona wystawia endpoint /ask?q=pytanie. Używa Schema.org jako bazy wiedzy (to co już masz dla SEO). Odpowiada w naturalnym języku lub JSON. Opcjonalnie: /mcp endpoint — każda instancja NLWeb jest też serwerem MCP.

Transport: standardowy HTTP GET/POST. Brak specjalnego klienta.

Kto stworzył: Microsoft (R.V. Guha, ten sam który stworzył RSS i Schema.org). Ogłoszony na Build 2025.

Stan adopcji: produkcyjny. Shopify, Eventbrite, TripAdvisor — wdrożone. Yoast SEO — integracja w nowych wersjach. WordPress: wdrożenie przez plugin lub REST API.

Relacja z MCP: każda instancja NLWeb jest jednocześnie serwerem MCP przez endpoint /mcp. Jedno wdrożenie, dwa protokoły.

Relacja z WebMCP: komplementarne z innej strony. NLWeb obsługuje pytania informacyjne (co tu jest, jakie masz produkty). WebMCP obsługuje akcje (dodaj do koszyka, zarezerwuj termin). Razem pokrywają pełen zakres agent-readiness strony.

ANP — warstwa sieciowa (przyszłość)

Kto z kim: agent ↔ agent (między organizacjami, zdecentralizowane)

Problem który rozwiązuje: A2A zakłada że agenty znają się nawzajem (masz AgentCard). ANP rozwiązuje problem discovery — jak agent Twojej firmy może znaleźć i nawiązać kontakt z agentem innej firmy bez wcześniejszej konfiguracji.

Kto stworzył: GoDaddy i W3C. Wczesna propozycja, nie standard.

Stan adopcji: bardzo wczesny. Standard do śledzenia, nie do wdrażania produkcyjnie.

Mapa protokołów agentowych — MCP, A2A, WebMCP, NLWeb i gdzie każdy pasuje

Mapa protokołów agentowych — MCP, A2A, WebMCP, NLWeb i gdzie każdy pasuje

Mapa relacji

                    ┌─────────────────────────────┐
                    │   UŻYTKOWNIK / CZŁOWIEK      │
                    └──────────────┬──────────────┘
                                   │ interakcja
                    ┌──────────────▼──────────────┐
                    │     HOST / APLIKACJA AI      │
                    │  (Claude Desktop, ChatGPT)   │
                    └──┬──────────────────────┬───┘
                       │ MCP                  │ A2A
          ┌────────────▼─────────┐  ┌─────────▼──────────┐
          │  SERWERY NARZĘDZI    │  │  INNE AGENTY AI     │
          │  (GitHub, Postgres,  │  │  (agent analizy,    │
          │   Webflux Słownik)   │  │   agent raportu)    │
          └──────────────────────┘  └────────────────────┘

                    Strona internetowa
                         │
              ┌──────────┼──────────────┐
              │          │              │
          WebMCP       NLWeb          MCP
        (w przeg-    (/ask, Schema)  (/mcp endpoint)
         lądarce)

Praktyczna tabela: który protokół dla jakiego przypadku

Chcę… Protokół
Agent ma wywołać bazę danych / API / system plików MCP
Agent ma podzielić zadanie między inne agenty A2A
Strona ma odpowiadać na pytania agentów przez sieć NLWeb
Strona ma umożliwić agentowi akcje w przeglądarce WebMCP
Agenty różnych firm mają się odkryć bez konfiguracji ANP
Agent ma zapłacić za coś autonomicznie AP2

Co implementować dziś, co obserwować

Implementuj dziś:

MCP — jeśli budujesz agentów lub narzędzia. Pełna produkcja, kompletna dokumentacja, ogromna społeczność. Artykuły 1-6 tej serii dają wszystko co potrzebujesz.

NLWeb — jeśli masz stronę na WordPress z Yoastem. Aktualizacja pluginu + endpoint /ask. Produkcyjne wdrożenia istnieją. Wzrost agent-readiness bez zmiany architektury.

Obserwuj i eksperymentuj:

A2A — jeśli planujesz systemy multi-agent. Adopcja w enterprise rośnie szybko. Dla stron WWW staje się widoczne gdy agenty zakupowe zaczną delegować między sobą. SDK stabilne, warto zacząć.

WebMCP — jeśli budujesz strony transakcyjne (sklepy, rezerwacje, formularze). Eksperymentalne, ale kierunek jest jasny. Deklaratywne API (atrybuty HTML) można wdrożyć teraz — nie złamie nic, a gdy Chrome stable zaadoptuje, strona będzie gotowa.

Śledź, ale nie wdrażaj produkcyjnie:

ANP — zbyt wczesne stadium. Architektura ma sens ale standard nie jest ustabilizowany.

Jeden organizm, wiele warstw

Najważniejszy wniosek z tej mapy: te protokoły nie konkurują — obsługują różne warstwy tej samej architektury.

Pełny stos agentowy dla organizacji która serio traktuje Agentic Web wygląda tak: agenty komunikują się przez A2A (orkiestracja). Każdy agent używa MCP do połączenia z narzędziami (narzędziowa). Strony firmowe mają NLWeb żeby agenty mogły je pytać (konwersacyjna). Formularze i akcje na stronach implementują WebMCP żeby agenty mogły działać (przeglądarkowa).

To nie jest jeden protokół do wyboru. To są cztery warstwy które można wdrażać niezależnie i w dowolnej kolejności — każda dodaje wartość bez blokowania pozostałych.

Zamknięcie serii

Seria „MCP na części pierwsze” zaczęła się od pytania: co tak naprawdę dzieje się w „kablu” między agentem a narzędziem?

Siedem artykułów później masz pełną odpowiedź: trzy role i capability negotiation, trzy prymitywy i ich schematy, JSON-RPC 2.0 jako fundament, ewolucja transportu od stdio przez SSE do Streamable HTTP, OAuth i least privilege, działający serwer PHP który możesz wdrożyć jutro, i mapa protokołów która pokazuje gdzie MCP kończy a inne standardy zaczynają.

USB dla modeli AI to metafora. Mamy nadzieję że teraz wiesz co jest w środku kabla.

Słownik — wszystkie pojęcia z serii: MCP · A2A · WebMCP · NLWeb · ANP · JSON-RPC · Streamable HTTP · SSE · OAuth dla agentów · Agent manifest · AP2

Agentic Web · Analiza

Agent wprowadza się do systemu. Microsoft to zapowiada — Google zrobił to po cichu

Na Build 2026 Microsoft pokazał Aion 1.0 — rodzinę modeli, która ma wstawić w pełni agentowe workflow bezpośrednio w Windows. To ten sam ruch, który Google wykonał kilka tygodni wcześniej, tyle że bez zapowiedzi. Dwie strategie dystrybucji agenta. Jeden kierunek: agent przestaje być aplikacją, a staje się warstwą systemu.

webflux.pl · hub Agentic Web · 6 czerwca 2026

W skrócie: Microsoft zapowiedział Aion 1.0 Plan — lokalny model 14B z 32K kontekstu, który ma wywoływać narzędzia, zarządzać plikami i orkiestrować sub-agentów wewnątrz Windows. To deklaracja, nie wydany produkt: trafi „w nadchodzących miesiącach", a wymagania sprzętowe nie zostały ujawnione.

Google nie zapowiadał — po prostu dociągnął lokalny model Gemini Nano do milionów instalacji Chrome między 20 a 29 kwietnia 2026. Przy okazji porządkujemy zamieszanie wokół protokołów: MCP i ACP nie są konkurentami — działają na różnych warstwach, a pytanie „czy Microsoft wpycha swój standard" jest źle postawione.

Co Microsoft faktycznie pokazał

2 czerwca 2026, na otwarciu Build, Microsoft przedstawił rodzinę modeli on-device o nazwie Aion 1.0. Pod marketingowym hasłem „unmetered intelligence" — inteligencja bez licznika — kryje się prosta idea: część pracy agenta przenieść z chmury na urządzenie, żeby nie płacić za każdy token i nie zależeć od połączenia. Rodzina ma dwa warianty, każdy pomyślany pod inną klasę sprzętu.

wariant lekki

Aion 1.0 Instruct

Mały model językowy (SLM) następnej generacji — szybszy i wydajniejszy od dotychczasowego systemowego SLM-a Windows. Pomyślany pod codzienną „inteligencję tekstową".

  • Streszczanie, przepisywanie, wykrywanie intencji, dostępność
  • Integracja z przeglądarką Edge
  • Preview już dziś w kanałach Edge Insider
  • Open weights na Hugging Face w lipcu 2026
wariant agentowy

Aion 1.0 Plan

Model reasoningu i tool-callingu 14 mld parametrów, 32K kontekstu. To on robi z Windows platformę agentową — ma dostarczać „w pełni agentowe workflow" lokalnie.

  • Rozumowanie nad intencją użytkownika
  • Wywoływanie narzędzi i zarządzanie plikami
  • Orkiestracja sub-agentów
  • Ships in-box z Windows „w nadchodzących miesiącach"

Różnica jest istotna i celowa. Instruct to koń pociągowy do drobnych zadań tekstowych, który ma działać wszędzie — Microsoft rozszerzył przy okazji Windows AI APIs poza NPU, także na CPU i GPU. Plan to coś zupełnie innego: to agent z prawdziwego zdarzenia, zaszyty w systemie operacyjnym, zdolny planować, sięgać po narzędzia i rozdzielać zadania na mniejsze podzadania. W kategoriach, których używamy w anatomii agenta AI, Aion 1.0 Plan to praktycznie podręcznikowy agent — pętla rozumowanie → wywołanie narzędzia → obserwacja → działanie — tyle że zamiast siedzieć w aplikacji w chmurze, mieszka w warstwie OS.

Sprawdź źródła — co jest faktem, a co zapowiedzią Oficjalny blog Windows Developer nie podaje minimalnych wymagań sprzętowych dla Aion 1.0 Plan. Krążąca w mediach liczba „NPU 40 TOPS" dotyczy rozszerzenia Windows AI APIs w ogóle, a nie samego modelu Plan. Open weights na Hugging Face dotyczą wyłącznie wariantu Instruct (lipiec 2026), nie Plan. I — co ważne dla dalszej części — Microsoft nigdzie nie potwierdził, że Aion używa MCP do tool-callingu. Traktujmy „in-box w Windows" jako zapowiedź z terminem „w nadchodzących miesiącach", nie jako produkt, który możesz dziś uruchomić.

Google zrobił to wcześniej — i nikogo nie pytał

Najciekawsze w ogłoszeniu Microsoftu nie jest to, co powiedział, tylko to, że ktoś inny zrobił to już w praktyce. Kilka tygodni przed Build, między 20 a 29 kwietnia 2026, Chrome dociągnął lokalny model Gemini Nano do dużej części uprawnionych urządzeń. Plik weights.bin wylądował w katalogu OptGuideOnDeviceModel w profilu użytkownika Chrome — bez pytania, bez fanfar. Model zasila przeglądarkowe funkcje AI: „Help me write" w polach tekstowych, wykrywanie scamów, streszczenia stron, sugestie grup kart.

To jest sedno kontrastu. Microsoft ogłasza z dużej sceny coś, co dopiero nadejdzie. Google po cichu wgrał wielkie modele na miliony maszyn i poinformował o tym dopiero, gdy deweloperzy sami znaleźli pliki. Dwie filozofie dystrybucji tej samej rzeczy: agenta w warstwie klienta.

A na Google I/O 2026 padła część druga tej układanki — Gemini Spark, opisany jako osobisty agent działający 24/7 w tle, podejmujący akcje w imieniu użytkownika, także poza samym urządzeniem. Do tego „information agents" w Search, które działają nieprzerwanie w tle i monitorują to, co dla Ciebie ważne. Jeśli zestawić to z tym, co pisaliśmy o Google I/O 2026 jako oficjalnej strategii Agentic Web, obraz robi się spójny: agent przestaje być czymś, co otwierasz. Staje się czymś, co jest zawsze włączone i zawsze obecne — w przeglądarce, w wyszukiwarce, w systemie.

Pytanie nie brzmi już „czy uruchomię agenta", tylko „co agent, który już działa na moim urządzeniu, jest w stanie zrozumieć i zrobić na mojej stronie". — i to jest pytanie o agent-readiness

MCP kontra ACP — czy Microsoft wpycha własny standard?

Przy Aion 1.0 pojawia się naturalne pytanie: jak ten lokalny agent wywołuje narzędzia? Tu trzeba uważać, bo łatwo o przekłamanie. W ogłoszeniu Intelligent Terminal — osobnej nowości z Build — Microsoft wprost wymienia protokół o nazwie ACP (Agent Communication Protocol), którym terminal dostarcza kontekst agentom. To kusi, żeby od razu ogłosić „Microsoft porzuca MCP na rzecz własnego ACP". Tylko że to byłby błąd kategorii.

MCP i ACP rozwiązują różne warstwy

Najprostsze ujęcie: MCP łączy agenta z narzędziami i danymi (integracja wertykalna — agent sięga w dół po API, bazę, plik), natomiast ACP łączy agentów ze sobą (integracja horyzontalna — agenci rozmawiają jak równy z równym). To nie są konkurenci o ten sam kawałek. W dojrzałym systemie wieloagentowym obie warstwy działają jednocześnie, na różnych granicach interakcji.

Protokół Twórca Warstwa Do czego służy Transport
MCP Anthropic wertykalna Agent → narzędzia, dane, API. „USB-C dla aplikacji AI". Standaryzuje dostęp do zasobów i pozwala przełączać dostawców modeli. JSON-RPC 2.0
A2A Google horyzontalna Agent ↔ agent między dostawcami i organizacjami. Bezpieczna współpraca i delegowanie zadań ponad frameworkami. JSON-RPC w HTTP POST
ACP IBM Research horyzontalna Agent ↔ agent wewnątrz organizacji. REST-natywna warstwa komunikatów, nacisk na prostotę i brak ciężkiego SDK. REST / HTTP

Z tego zestawienia wynika rzecz, której nie znajdziesz w nagłówkach: „ACP" to nie jeden byt. Klasyczne ACP pochodzi z IBM Research i dotyczy komunikacji agent–agent. Sam twórca IBM-owego ACP, Kate Blair, opisuje cel jako „zbudowanie HTTP komunikacji agentów" — i podkreśla, że ACP działa obok MCP, tak jak HTTP działa obok TCP/IP. To nie zastępstwo, to inna warstwa stosu.

Więc co właściwie robi Microsoft?

I tu uczciwa odpowiedź brzmi: nie wiemy jeszcze do końca — i to jest najważniejsza linia tego wpisu. Microsoft użył skrótu „ACP" w kontekście dostarczania kontekstu agentom w terminalu, co opisowo wygląda bliżej warstwy narzędziowej niż klasycznej komunikacji agent–agent w stylu IBM. Czy to to samo ACP, czy zbieżność nazw przy własnej implementacji Microsoftu? Oficjalne materiały tego nie rozstrzygają. Podobnie nie wiadomo, czy tool-calling Aion 1.0 Plan pójdzie przez MCP, przez wewnętrzny mechanizm Windows, czy przez jedno i drugie.

Dlatego pytanie „czy Microsoft na siłę wprowadza swój standard zamiast MCP" jest źle postawione. MCP i ACP nie rywalizują o to samo miejsce. Realne, sensowne pytania brzmią inaczej:

Po pierwsze — czy Microsoft w ogóle wystawi Aiona przez MCP, czy zbuduje zamkniętą, systemową warstwę tool-callingu, do której deweloperzy będą musieli się podłączać po jego stronie? Po drugie — jeśli ACP w wydaniu Microsoftu okaże się jednak osobną, firmową warstwą komunikacji, to czy to konsolidacja ekosystemu wokół otwartych standardów, czy raczej grodzenie własnego ogródka? Konsensus branżowy na połowę 2026 jest dość zgodny: MCP do narzędzi, ACP lub A2A do współpracy agentów — a najwięcej systemów produkcyjnych użyje kilku protokołów naraz. Plus warstwa narzędziowa. Plus tożsamość. Wojna „jeden protokół zwycięży" to wygodny nagłówek, ale rzeczywistość jest warstwowa, nie plemienna.

Czego tu świadomie nie przesądzamy Nie twierdzimy, że Aion 1.0 Plan używa MCP — Microsoft tego nie potwierdził. Nie zrównujemy też „ACP" z bloga Microsoftu z ACP od IBM Research; zbieżność nazwy nie przesądza o zbieżności protokołu. To są otwarte pytania, do których wrócimy, gdy pojawi się dokumentacja techniczna. Mapę wszystkich tych protokołów rozkładamy szczegółowo w osobnym wpisie.

Co to zmienia dla agent-readiness

Wszystkie te ruchy — Aion w Windows, Gemini Nano w Chrome, Spark w tle — prowadzą do jednego wniosku, który leży w samym sercu tego, czym zajmuje się webflux.pl. Dopóki agent był usługą w chmurze, „strona zrozumiała dla agenta" brzmiała trochę jak ćwiczenie teoretyczne. Gdy agent siedzi w systemie operacyjnym i działa nawet offline, ta sama teza staje się kwestią dystrybucji: agent, który czyta Twoją stronę, może być częścią systemu na milionach maszyn — nie jednym botem z jednego centrum danych, tylko domyślnym składnikiem każdego nowego laptopa.

To podnosi stawkę dwóch rzeczy, o których piszemy od miesięcy. Pierwsza to struktura: semantyczny HTML, schema.org, llms.txt, czytelne ścieżki akcji. Nasz własny eksperyment z Claude in Chrome pokazał, że agent radzi sobie o 40–60% lepiej na stronie zoptymalizowanej pod AI niż na identycznej wizualnie, ale „nieczytelnej" maszynowo. Druga to context engineering: model lokalny z oknem 32K nie ma luksusu wielkiego kontekstu chmurowego. Jeśli Twoja strona zmusza agenta do mielenia tysięcy linijek śmieciowego DOM-u, żeby dotrzeć do sedna, przegrywa z konkurentem, który podaje to samo zwięźle i czysto. Na urządzeniu każdy token kosztuje pamięć i czas, nie pieniądze — ale kosztuje.

Świadomie zostawiamy na boku jeden wielki wątek: bezpieczeństwo. Lokalny agent z dostępem do plików i tool-callingu to nowa, gruba powierzchnia ataku — Microsoft sam poświęcił temu sporą część Build, wprowadzając warstwę izolacji i tożsamości dla agentów. To temat na tyle obszerny, że rozłożymy go osobno na cyberflux.pl. Tu wystarczy zapamiętać jedno zdanie, które padło wprost z ust Microsoftu: problemem nie jest sam agent, tylko cały system, w którym agent działa — bo każda interakcja między agentem, człowiekiem, narzędziami i innymi agentami otwiera nową powierzchnię ataku. Trudno o lepszą walidację tezy, którą powtarzamy od początku istnienia cyberflux.

Agent przestał być produktem, który wybierasz. Stał się warstwą, która już tam jest. Pytanie brzmi tylko, czy Twoja strona jest dla niej widoczna.
Pytania i odpowiedzi

FAQ — Aion 1.0 i agent w systemie operacyjnym

Czym jest Aion 1.0 i czym różnią się jego dwa warianty?

Aion 1.0 to rodzina modeli AI działających lokalnie na urządzeniu, zaprezentowana przez Microsoft na Build 2026. Aion 1.0 Instruct to mały, szybki model językowy do codziennych zadań tekstowych, takich jak streszczanie, przepisywanie i wykrywanie intencji, dostępny w preview w Edge i jako open weights na Hugging Face od lipca 2026. Aion 1.0 Plan to model 14 miliardów parametrów z oknem kontekstu 32K, przeznaczony do rozumowania i wywoływania narzędzi, który ma trafić bezpośrednio do Windows i umożliwić w pełni agentowe workflow na urządzeniu.

Czy Aion 1.0 jest już dostępny do pobrania?

Tylko częściowo. Aion 1.0 Instruct jest dostępny w preview w kanałach Edge Insider już teraz, a jako model open weights na Hugging Face ma pojawić się w lipcu 2026. Aion 1.0 Plan został na razie jedynie zapowiedziany — ma trafić „w nadchodzących miesiącach" jako wbudowany element Windows na zdolnych urządzeniach, a Microsoft nie ujawnił jeszcze minimalnych wymagań sprzętowych tego modelu.

Jaka jest różnica między protokołami MCP i ACP?

MCP (Model Context Protocol, stworzony przez Anthropic) łączy agenta AI z narzędziami, danymi i API — to integracja wertykalna, czyli dostęp agenta „w dół" do zasobów. ACP (Agent Communication Protocol, rozwijany przez IBM Research) służy do komunikacji między agentami — to integracja horyzontalna. Nie są to konkurujące standardy, lecz protokoły działające na różnych warstwach stosu agentowego; w dojrzałych systemach wieloagentowych używa się ich równocześnie, często razem z protokołem A2A od Google do współpracy agentów między organizacjami.

Czy Microsoft porzuca MCP na rzecz własnego standardu?

Nie ma na to dowodów. Microsoft użył nazwy „ACP" w kontekście narzędzia Intelligent Terminal, ale nie potwierdził, że jest to ten sam protokół co ACP od IBM Research, ani nie ujawnił, jakim protokołem Aion 1.0 Plan będzie wywoływać narzędzia. Ponieważ MCP i ACP rozwiązują różne warstwy problemu, pytanie o „porzucenie MCP na rzecz ACP" jest źle postawione — to nie są wymienne standardy.

Dlaczego agent działający w systemie operacyjnym ma znaczenie dla mojej strony?

Gdy agent AI jest wbudowany w system operacyjny lub przeglądarkę i działa nawet bez połączenia z internetem, staje się domyślnym składnikiem milionów urządzeń. Oznacza to, że gotowość Twojej strony na odczyt przez agenta — czyli agent-readiness — przestaje być kwestią teoretyczną i zaczyna realnie decydować o widoczności. Strony z czytelną strukturą semantyczną, danymi schema.org i zwięzłą treścią są dla lokalnych agentów łatwiejsze do zrozumienia i obsłużenia, zwłaszcza że modele on-device pracują na ograniczonym oknie kontekstu.

Czytaj dalej w hubie Agentic Web

Sprawdź słownik pojęć Agentic-Web
Przejdź do Strefy Divi