App Intents kontra MCP: kwestia routingu

Gatunek: frontier-essay. Tekst formułuje regułę routingu dla agentowego rozwoju na platformie Apple. Dwa protokoły (App Intents oraz MCP) pozwalają zewnętrznemu agentowi operować na domenie aplikacji. Nie zlewają się w jeden. Pytanie brzmi: który dokąd prowadzi i dlaczego każdy z nich jest właściwą odpowiedzią dla swojego wywołującego.

Apple udostępniło App Intents, aby zapewnić Apple Intelligence typowaną, deklaratywną powierzchnię do operowania aplikacjami firm trzecich bez ingerowania w ich UI.¹ Anthropic udostępnił Model Context Protocol, aby zapewnić każdemu LLM typowaną, pośredniczoną przez serwer powierzchnię do operowania dowolnym narzędziem bez ingerowania w jego UI.² Kształty są podobne. Wywołujący — nie. Traktowanie ich jako jednej powierzchni prowadzi do architektury, która nie spełnia oczekiwań żadnej ze stron.

Dwa wcześniejsze posty w tym klastrze omawiały każdy protokół z osobna: App Intents w App Intents to nowe API Apple do Pańskiej aplikacji, MCP w Dwa ekosystemy agentów, jedna lista zakupów. Niniejszy tekst dotyczy kwestii routingu. Kiedy dana funkcja powinna otrzymać AppIntent, kiedy narzędzie MCP, kiedy oba, a co powinno pozostać dostępne wyłącznie wewnątrz aplikacji?

TL;DR

• App Intents to jedyna ścieżka do Apple Intelligence, Siri, Shortcuts oraz systemowego stosu sugestii. System udostępnia je od momentu instalacji oraz poprzez aktualizacje aplikacji, przy czym donacja i indeksowanie App Shortcuts wprowadzają je do sugestii Spotlight i Siri.
• Narzędzia MCP to ścieżka do każdego LLM spoza Apple (Claude, ChatGPT, Gemini, modele lokalne). Transportem jest stdio lub Streamable HTTP, a .mcpb to format pakowania, który zwykle dostarcza lokalny serwer stdio; host ładuje narzędzia w trakcie sesji.
• Oba protokoły zbiegają się w typowanym schemacie, kształcie entity → action → result oraz rozwiązywaniu parametrów. Rozchodzą się w kwestii tożsamości, trwałości, opóźnienia oraz powierzchni renderowania.
• Reguła routingu: jeśli funkcja jest tym, o co użytkownik mógłby zapytać Siri lub przywołać ze Spotlight — App Intents. Jeśli funkcja jest tym, co programista mógłby podpiąć do sesji Claude Code lub uruchomienia agenta zewnętrznego — MCP. Większość aplikacji potrzebuje obu rozwiązań dla tej samej domeny.

Dwa protokoły, ten sam kształt

Oba protokoły definiują kontrakt operacyjny pomiędzy zewnętrznym wywołującym a domeną aplikacji. Kontrakt składa się z trzech części: schematu (o co wywołujący może poprosić), rozwiązywacza (jak aplikacja znajduje encje wymienione w schemacie) oraz akcji (co się wykonuje i co wraca).

App Intents wyrażają kontrakt w Swifcie. Powierzchnię protokołu stanowią AppIntent, AppEntity, AppEnum, przy czym makra @Parameter napędzają schemat, a func perform() zwraca wynik.³ Schemat jest generowany w czasie kompilacji i dołączany do aplikacji przy instalacji. Apple Intelligence, Siri, Shortcuts oraz Spotlight czytają ten sam schemat i kierują typowane żądanie przez ten sam punkt wejścia perform().

MCP wyraża kontrakt w JSON-RPC poprzez stdio lub Streamable HTTP. Powierzchnię protokołu stanowią metody tools/list oraz tools/call, a każde narzędzie deklaruje nazwę, opis oraz inputSchema (przy czym specyfikacja 2025-06-18 dodaje opcjonalny outputSchema dla strukturalnych zwrotów).⁴ Host MCP (Claude Desktop, Claude Code, Cursor, aplikacja desktopowa ChatGPT) odkrywa narzędzia na początku sesji i wywołuje je po nazwie z ładunkiem JSON. Host uruchamia model; serwer uruchamia narzędzie.

Kształt jest ten sam: schemat, rozwiązywacz, akcja. Różnica polega na tym, kto uruchamia każdy element i gdzie znajduje się granica zaufania. App Intents działają wewnątrz procesu aplikacji, na urządzeniu użytkownika, pod uprawnieniami aplikacji, przy czym system pośredniczy w routingu wywołań. Serwery MCP działają tam, gdzie programista zdecydował się je uruchomić (lokalne stdio, hostowane HTTP, osadzony pakiet), przy czym host LLM pośredniczy w routingu wywołań w nieograniczonym zbiorze narzędzi.

Gdzie oba protokoły się różnią

Poza powierzchownym kształtem dla routingu istotne są cztery różnice operacyjne:

Tożsamość i trwałość. App Intents posługują się typami AppEntity, które system może zapisać, prezentować i ponownie rozwiązywać później. Wpis dotyczący wody, który zapiszę dziś poprzez Hej Siri, zapisz 250 ml w Water, przetrwa restarty, synchronizuje się przez NSUbiquitousKeyValueStore i może być przywoływany przez inne intencje (Pokaż wpisy o wodzie z wczoraj). System śledzi identyfikator encji we wszystkich tych wywołaniach.³ MCP jest sam w sobie protokołem stanowym z zarządzaniem cyklem życia, a Streamable HTTP wspiera identyfikatory sesji dla ciągłości połączenia, lecz trwała tożsamość domenowa to kwestia leżąca po stronie serwera; nie istnieje analog na poziomie protokołu do identyfikatorów AppEntity, na którym model hosta mógłby polegać między sesjami. MCP wspiera resources dla trwałych danych referencyjnych, lecz tożsamość pozostaje odpowiedzialnością po stronie serwera, a nie pierwszorzędnym kontraktem protokołu.⁴

Opóźnienie i bateria. Ciało perform() w App Intent wykonuje się w kontekście aplikacji lub jej rozszerzenia na urządzeniu. Każde użycie sieci pochodzi z własnego kodu aplikacji lub otaczającej warstwy Apple Intelligence/Siri, a nie z samego kontraktu intencji. Typowana, lokalna akcja zwracająca typowany wynik jest w typowym przypadku szybka. Narzędzia MCP, nawet lokalne, przechodzą przez ramowanie stdio JSON-RPC z odrębną granicą procesu, a zdalne narzędzia MCP niosą koszt podróży HTTP. Budżet opóźnień jest inny. App Intent zapisz 250 ml może zakończyć się w oknie wymiany Siri. Zdalne narzędzie MCP może być wąskim gardłem sesji Claude Code.

Powierzchnia renderowania. App Intents zwracają wyniki, które Apple Intelligence renderuje w systemowym UI: baner na ekranie blokady, odpowiedź Siri, wynik Shortcuts, wynik Spotlight. Aplikacja nie kontroluje sposobu prezentacji wyniku. Narzędzia MCP zwracają bloki treści (tekst, obrazy, audio, osadzone zasoby lub strukturalną treść), które model hosta odczytuje i sam decyduje, jak je przedstawić. Sesja Claude Code może zacytować wynik z powrotem programiście, podsumować go lub przekazać do kolejnego wywołania. Decyzja renderowania zapada na warstwie modelu.

Możliwość odkrycia. Apple Intelligence udostępnia App Intents od momentu instalacji, przy czym donacja i indeksowanie App Shortcuts wprowadzają intencje do wyszukiwań Spotlight oraz sugestii Siri w oparciu o zachowanie użytkownika; aktualizacje aplikacji oraz dynamiczne encje modyfikują tę powierzchnię w czasie. Użytkownik nigdy nie wpisuje nazwy narzędzia. Hosty MCP czytają narzędzia na początku sesji; użytkownik (lub prompt systemowy) decyduje, które narzędzia model może zobaczyć. Odkrywanie jest jawną konfiguracją po stronie MCP i niejawną wnioskowaną przez system po stronie App Intents.

Oba protokoły rozchodzą się w kwestii tożsamości, opóźnienia, renderowania i odkrywania: cztery właściwości wynikające z jednego źródłowego rozróżnienia. App Intents obsługują agenta na poziomie systemu, którego użytkownik nie konfigurował. MCP obsługuje agenta na poziomie sesji, którego konfigurował programista. Różni wywołujący, różne zobowiązania.

Reguła routingu

Mapa funkcji dla aplikacji z oboma protokołami wygląda następująco:

                    ┌──────────────────────────────────────────┐
                    │           App's domain capabilities       │
                    │                                            │
                    │  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
                    │  │  CRUD   │  │ Queries │  │ Actions │    │
                    │  └─────────┘  └─────────┘  └─────────┘    │
                    └────┬────────────┬────────────┬────────────┘
                         │            │            │
              ┌──────────┴──────┐    │   ┌────────┴──────────┐
              │                 │    │   │                   │
              ▼                 ▼    ▼   ▼                   ▼
       ┌────────────┐    ┌─────────────────────┐    ┌──────────────┐
       │ App Intents │    │ Both (AppIntent +   │    │  MCP tools   │
       │   only      │    │  MCP tool wrapper)  │    │    only      │
       └────────────┘    └─────────────────────┘    └──────────────┘
            │                       │                       │
       Siri / Spotlight       Cross-protocol           Claude Code,
       Shortcuts              capabilities             external agents,
       Apple Intelligence     where both callers       LLM tooling,
       proactive surfaces     should reach the         dev workflows
                              same domain

Reguła routingu to trzy pytania w określonej kolejności.

Czy funkcja jest tym, o co użytkownik zapytałby Siri lub co przywołałby ze Shortcuts? Jeśli tak, funkcja wymaga App Intent. Zapisz 250 ml wody, Rozpocznij medytację, Dodaj banany do listy, Ile ważyłem wczoraj są intencjami, ponieważ użytkownik mógłby wypowiedzieć je na głos, wpisać do Spotlight lub powiązać w Shortcuts. App Intent jest dla takich funkcji nieopcjonalny; nic innego nie zaprowadzi do pierwszorzędnej powierzchni agentowej Apple Intelligence.

Czy funkcja jest tym, co zewnętrzny agent powinien móc napędzać? Jeśli tak, funkcja wymaga narzędzia MCP. Dodaj pozycję do listy zakupów z sesji Claude Code, Wczytaj stan Get Bananas do kontekstu agenta Cursor, Wyzwól workflow ze zdalnego LLM używającego narzędzi to narzędzia MCP, ponieważ wywołującym nie jest Apple Intelligence; wywołującym jest dowolny LLM, który programista podłączył. Narzędzie MCP może opakowywać tę samą funkcję Swift z warstwy domenowej, co App Intent, lecz powierzchnią protokołu jest JSON-RPC poprzez wybrany przez programistę transport.

Czy funkcja musi przetrwać pojedynczą sesję ze stabilną, znaną systemowi tożsamością? Jeśli tak, ścieżka App Intent jest naturalnym dopasowaniem, ponieważ system zapewnia tożsamość AppEntity, wsparcie zapytań i semantykę trwałości za darmo. Jeśli nie, narzędzie MCP może zwrócić blok treści, pozostawić trwałą tożsamość uznaniu serwera i pominąć koszt modelowania encji.

Większość nietrywialnych funkcji aplikacji mieści się w kolumnie oba. Funkcja zapisywania wody w aplikacji Water ma AppIntent (aby Siri mogła przyjmować dyktando) oraz narzędzie MCP (aby sesja Claude Code mogła uzupełnić dane wstecznie z eksportowanego dziennika). Obie ścieżki współdzielą funkcję Swift; funkcja nie wie, który wywołujący ją uruchomił.⁵

Kształt w kodzie wygląda jak jedna metoda domenowa i dwa adaptery, które obie ją wywołują:

// Domain layer (Swift, no protocol assumptions)
func logWater(amount: Measurement<UnitVolume>, at: Date, caller: Caller) throws -> WaterEntry {
    try guards.requireWritePermission(caller)
    let entry = WaterEntry(amount: amount, timestamp: at)
    try store.insert(entry)
    return entry
}

// Adapter 1: App Intent (Apple Intelligence / Siri / Shortcuts)
struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    @Parameter(title: "Amount") var amount: Measurement<UnitVolume>

    func perform() async throws -> some IntentResult & ReturnsValue<WaterEntry> {
        let entry = try domain.logWater(amount: amount, at: .now, caller: .siri)
        return .result(value: entry)
    }
}

// Adapter 2: MCP tool (Claude Desktop / Code / external agent)
// Tool name "log_water" with inputSchema {amount_ml: number}
// Handler:
let entry = try domain.logWater(
    amount: .init(value: ml, unit: .milliliters),
    at: .now,
    caller: .mcp(host: hostName)
)
return .text("Logged \(entry.amount) at \(entry.timestamp)")

Oba adaptery wyglądają inaczej, ponieważ ich wywołujący są różni. Funkcja, którą wywołują, jest ta sama.

Co pozostaje w aplikacji

Niewielki, lecz istotny zbiór funkcji powinien pozostać prywatny dla aplikacji. Skierowanie ich do któregoś z protokołów to błąd.

Funkcje stanu UI. „Otwórz trzecią zakładkę”, „przewiń na dół”, „podświetl ten wiersz” nie są operacjami domenowymi. To prymitywy interakcji. App Intents wspierają część tego poprzez OpensIntent i Shortcuts, lecz dopasowanie gatunkowe jest słabe; użytkownik zwykle chce wyniku, a nie nawigacji. Wsparcie MCP dla nawigacji UI jest jeszcze słabsze: model nie napędza ekranu, on napędza narzędzie.

Funkcje wymagające ciała człowieka w pętli. Robienie zdjęć, uwierzytelnianie biometryczne, wprowadzanie wrażliwych danych osobowych, każdy przepływ wymagający, by użytkownik patrzył na ekran i dotykał. Apple posiada CameraCaptureIntent dla przepływów aparatu, lecz intencją projektową jest uruchomienie aktywności robienia zdjęć na pierwszym planie, a nie udostępnienie agentowi dostępu do aparatu w tle. Uczciwa reguła dla obu protokołów: przepływy aparatu, biometrii i wprowadzania wrażliwych danych powinny działać jako UI na pierwszym planie z jawnym potwierdzeniem użytkownika, a nie jako ciche wywołania intencji lub narzędzia. Należy trzymać te funkcje za UI aplikacji i pozwolić agentowi kierować użytkownika do ekranu, a nie przez niego.

Długo działające zadania w tle. App Intents zawierają ProgressReportingIntent do przedstawiania postępu, a MCP obejmuje powiadomienia o postępie i prymitywy zadań, lecz warstwa renderowania żadnego z protokołów nie jest zbudowana pod długotrwały postęp w przepływach konsumenckich. Model hosta w sesji MCP zwykle przekracza limit czasu łańcuchów rozumowania na długo przed zakończeniem wielominutowego narzędzia. Dla konsumenckich zadań długotrwałych operację należy udostępniać poprzez własne UI aplikacji; niech protokoły zwracają żądanie zostało zakolejkowane i prowadzą do ekranu statusu.

Cokolwiek dotykającego danych innego użytkownika. Granica zaufania w obu protokołach to wywołujący agent. Apple Intelligence działa pod kontem iCloud użytkownika. MCP działa pod jakimikolwiek poświadczeniami, które programista podłączył. Operacje obejmujące wielu użytkowników (udostępnianie, dostęp wielokontowy, działania administracyjne) nie są bezpieczne przez żaden z protokołów, ponieważ wywołująca tożsamość jest niewłaściwą tożsamością.

Co zbudowałbym inaczej

Znając powyższą regułę routingu, zaprojektowałbym warstwę domenową w aplikacji Swift tak, jak teraz projektuję API na granicy usługi. Metody domenowe przyjmują typowane wejścia i zwracają typowane wyjścia, bez wbudowanych założeń protokołowych. App Intents cienko opakowują metody domenowe schematem @Parameter i klejem perform(). Narzędzia MCP cienko opakowują te same metody domenowe schematem JSON i ramowaniem stdio. Oba protokoły są cienkimi adapterami; praca dzieje się w domenie.

Wynikają z tego dwie konsekwencje.

Tożsamość wywołującego to sprawa domeny, a nie protokołu. Ciało App Intent otrzymuje parametry rozwiązane przez system i działa w kontekście, w którym użytkownik przeszedł przez systemowy przepływ wywoływania intencji. Ciało narzędzia MCP otrzymuje wszelkie poświadczenia, jakie host ułożył. Oba przekazują je do metody domenowej jako jawny argument caller. Metoda domenowa egzekwuje autoryzację, monity potwierdzeń i wszelkie inne niezmienniki domeny. Żaden z protokołów nie udaje, że wywołującym jest użytkownik.

Oba adaptery udostępniają ten sam zbiór możliwości. Decyzja, które funkcje udostępnić któremu wywołującemu, jest uchwycona w dwóch manifestach, a nie rozproszona w kodzie protokołu. Dodanie nowej funkcji to jedna metoda domenowa, dwa adaptery, dwa wpisy manifestu. Usunięcie funkcji jest symetryczne. Powyższa macierz staje się rzeczywistym plikiem.

Granica platformy Apple na najbliższe kilka lat nie polega na wybraniu jednego protokołu. Granicą jest traktowanie obu jako ortogonalnych kontraktów, które komponują się na tej samej warstwie domenowej. Agenci Apple Intelligence mają jeden zestaw zobowiązań wobec użytkownika (działają na urządzeniu, mówią Siri, renderują przez system). Zewnętrzni agenci LLM mają inny zestaw zobowiązań wobec programisty (działają gdziekolwiek, mówią JSON-RPC, renderują przez dowolny model wybrany przez programistę). Oba zasługują na typowaną powierzchnię w aplikacji. Żaden nie zasługuje na bycie jedyną powierzchnią.

Kiedy nie budować obu

Argument tnie w obie strony. Niektóre aplikacje potrzebują jednego protokołu, a nie drugiego.

Czyste narzędzia konsumenckie bez powierzchni dla programistów. Latarka. Identyfikator ptasich nawoływań. Miarka rzeczywistości rozszerzonej. Użytkownik mógłby chcieć wywołać to przez Siri (App Intents są przydatne), lecz żaden programista nie podłącza tego do workflow LLM (MCP byłby kosmetyczny).

Czyste narzędzia programistyczne bez powierzchni dla użytkownika końcowego. Serwer MCP formatujący kod. Narzędzie wyszukujące w repozytorium. Inspektor wersji pakietów. Użytkownikiem jest programista w sesji Claude Code; Siri i Apple Intelligence nie odgrywają tu roli.

Aplikacje, które źle służą obu klasom agentów. Wysoce interaktywne gry, aplikacje multiplayer w czasie rzeczywistym, aplikacje, których wartość polega na byciu w aplikacji i na ekranie. Żaden z protokołów nie pasuje; właściwą odpowiedzią jest świetna aplikacja i brak kontraktu agentowego.

Decyzja nie brzmi jeden lub oba domyślnie. Decyzja brzmi do czego ta aplikacja służy i kto jeszcze mógłby chcieć operować na jej domenie. Odpowiedzią może być żaden, jeden lub oba. Koszt zbudowania jednego jest mały, jeśli warstwa domenowa jest dobrze ukształtowana. Koszt zbudowania obu na tej warstwie domenowej jest również mały. Koszt niezbudowania jednego, gdy przypadek użycia tego wymaga, to całkowita nieobecność funkcji na tej powierzchni agentowej.

Co ten wzorzec oznacza dla stosu Apple na iOS 26+

Dwa wnioski.

1. Należy traktować App Intents i MCP jako ortogonalne kontrakty na tej samej domenie, a nie konkurujące protokoły. Apple Intelligence, Siri, Shortcuts oraz Spotlight to jedna klasa wywołujących z zobowiązaniami na poziomie systemu. Claude, Cursor, ChatGPT i pozostałe to druga klasa wywołujących z zobowiązaniami na poziomie sesji. Oba zasługują na typowany dostęp. Warstwa domenowa pod nimi się nie zmienia.

2. Reguła routingu dotyczy kto wywołuje, a nie co się uruchamia. App Intent i narzędzie MCP mogą wywoływać tę samą funkcję Swift. Różnią się zobowiązaniami niesionymi przez wywołującego, renderowaniem, jakie otrzymują z powrotem, i trwałością, jakiej oczekują. Należy poprawnie zaprojektować funkcję; warstwy protokołów niech będą cienkie.

Pełny klaster Apple Ecosystem: typowane App Intents dla Apple Intelligence, serwery MCP dla agentów wieloplatformowych z różnych LLM, Live Activities dla maszyny stanów ekranu blokady, wzorce Liquid Glass dla warstwy wizualnej oraz wieloplatformowa dystrybucja dla zasięgu między urządzeniami. Centrum znajduje się w serii Apple Ecosystem. Szerszy kontekst iOS-z-agentami-AI znajduje się w przewodniku iOS Agent Development.

FAQ

Kiedy warto zbudować App Intent, a kiedy narzędzie MCP dla tej samej funkcji?

App Intent warto zbudować, gdy funkcja powinna sięgać do Apple Intelligence, Siri, Shortcuts lub Spotlight. Narzędzie MCP warto zbudować, gdy funkcja powinna sięgać do zewnętrznych LLM (Claude, ChatGPT, agenci w Claude Code lub Cursor). Dla funkcji domenowych, które powinny obsługiwać obie klasy wywołujących, należy zbudować oba jako cienkie adaptery nad współdzieloną metodą domenową w Swift.

Czy App Intents i serwery MCP konkurują ze sobą?

Nie. App Intents to ścieżka do pierwszorzędnego stosu agentowego Apple; MCP to ścieżka do każdego innego LLM. Apple Intelligence nie wywołuje narzędzi MCP, a zewnętrzni agenci LLM nie mogą bezpośrednio wywoływać App Intents (przechodzą przez system). Oba protokoły obsługują różne klasy wywołujących z różnymi modelami zaufania, różnymi budżetami opóźnień i różnymi powierzchniami renderowania.

Czy pojedyncza aplikacja może udostępniać swoją domenę przez oba protokoły?

Tak, i większość nietrywialnych aplikacji, które chcą pełnego zasięgu agentowego, powinna to zrobić. Get Bananas (omówione w poście o serwerze MCP) i Water (omówione w poście o App Intents) to wczesne przykłady. Wzorzec to warstwa domenowa od spodu, z adapterami App Intent i adapterami narzędzi MCP powyżej. Oba adaptery wywołują te same funkcje Swift.

Jaki stan śledzi Apple Intelligence, którego nie śledzi MCP?

Apple Intelligence śledzi tożsamość AppEntity między wywołaniami, sesjami i restartami. Model encji zapewnia systemowi trwałe odniesienia, które użytkownik może łączyć między intencjami. MCP samo w sobie jest protokołem stanowym z zarządzaniem cyklem życia i identyfikatorami sesji w Streamable HTTP, lecz trwała tożsamość domenowa to odpowiedzialność po stronie serwera, a nie pierwszorzędny kontrakt protokołu; model hosta nie otrzymuje z powierzchni protokołu identyfikatora odpowiadającego AppEntity. Koncepcja resources w MCP wspiera trwałe dane referencyjne, lecz operuje na tej samej warstwie należącej do serwera.

Czy są funkcje, których nie powinno się udostępniać przez żaden z protokołów?

Tak. Funkcje stanu UI (otwórz tę zakładkę, przewiń tutaj), funkcje wymagające ciała człowieka w pętli (robienie zdjęć, uwierzytelnianie biometryczne, wprowadzanie wrażliwych danych), długo działające zadania w tle oraz operacje obejmujące dane wielu użytkowników powinny pozostać za UI aplikacji. Oba protokoły mają słabe prymitywy dla tych zadań, a żaden nie niesie sygnałów zaufania wymaganych do bezpiecznego operowania między użytkownikami.

Bibliografia