Workflow agentowy Foundation Models: LLM w aplikacji a LLM jako narzędzie

Aplikacja Swift na iOS 26 ma dwie LLM, które jej dotykają, na bardzo różnych warstwach. Pierwszą jest model na urządzeniu, który użytkownik uruchamia za pośrednictwem LanguageModelSession aplikacji. Drugą jest agent, którego programista uruchomił przez Claude Code, Cursor lub Codex CLI, aby w ogóle napisać aplikację. Mylenie tych dwóch LLM to powracający błąd architektoniczny w agentowym tworzeniu rozwiązań Apple. To nie jest ten sam problem; nie współdzielą modelu bezpieczeństwa; nie współdzielą historii wdrożenia; a wzorce, które działają dla jednej, aktywnie zawodzą w przypadku drugiej.

LLM uruchomieniowa to funkcja dostarczana użytkownikowi. LLM jako narzędzie to rysik, który trzyma programista. Model uruchomieniowy działa za oczekiwaniami prywatności użytkownika, kontrolami dostępności systemu i recenzją App Store. Model narzędziowy działa za kluczem API programisty, uprawnieniami systemu plików IDE oraz recenzją kodu, za którą odpowiada programista. Te dwa stosy rzadko się przecinają, a kiedy już to robią (serwer MCP, którego programista używa do operowania na domenie aplikacji podczas rozwoju, a który aplikacja uruchomieniowa również mogłaby udostępnić do automatyzacji dla użytkownika końcowego), granica zaufania się przesuwa, a architektura musi to uwzględnić.

Niniejszy wpis nazywa to rozróżnienie oraz wynikające z niego pytanie o routing: która LLM powinna obsługiwać daną zdolność i co każda z nich jest winna użytkownikowi.

TL;DR

• LLM uruchomieniowa to Foundation Models (SystemLanguageModel.default plus protokół Tool). Inferencja odbywa się lokalnie, model dostarczany jest z systemem operacyjnym, aplikacja wykonuje wywołanie w imieniu użytkownika.¹
• LLM jako narzędzie to cokolwiek, co wybrał programista: Claude w Claude Code, GPT w Cursorze, Codex CLI dla Swifta. Inferencja jest zdalna (infrastruktura Anthropic lub skonfigurowanego dostawcy Claude, OpenAI itp.), model jest tam, gdzie umieścił go host, a programista kieruje agentem.
• Te dwie LLM nie współdzielą bezpieczeństwa, wdrożenia, budżetów czasowych ani odpowiedzialności. Zdolność, która ma sens na jednej warstwie, często ma niewłaściwy kształt na drugiej.
• Ten sam serwer MCP, którego programista używa podczas sesji Claude Code, nie jest automatycznie odpowiednią powierzchnią dla automatyzacji agentowej dla użytkownika końcowego. Granica zaufania się zmienia; to, co było narzędziem kontrolowanym przez programistę, staje się narzędziem kontrolowanym przez użytkownika (lub przez system).

Dwa stosy, to samo słowo „LLM”

Kolizja zdarza się w rozmowach takich jak ta. Ktoś mówi „powinniśmy dodać LLM do aplikacji”. Czy oznacza to funkcję wywoływaną przez użytkownika (napisz mi podsumowanie medytacji, dopracuj ten szkic, sklasyfikuj to zdjęcie), czy też narzędzie, które programista włącza we własną pętlę iteracji (niech Claude Code napisze migrację, niech Cursor zrefaktoryzuje widok), nie wynika jasno ze zdania. Oba są dodaniami LLM. Żaden z nich nie jest tą samą decyzją inżynierską.

Foundation Models to jeden stos. Model żyje w SystemLanguageModel.default, ma stałe okno kontekstu, działa na układach Apple silicon, nigdy nie opuszcza urządzenia i jest gatekowany przez kwalifikację użytkownika do Apple Intelligence.¹ Programista aplikacji ogranicza dane wejściowe za pomocą typów @Generable, udostępnia możliwości aplikacji przez protokół Tool i dostarcza binarkę, która wywołuje model, gdy funkcja zostaje uruchomiona. Użytkownik wywołuje funkcję; system operacyjny dostarcza model; aplikacja je ze sobą zszywa.

Claude Code, Cursor, Codex CLI i każde inne agentowe IDE tworzą inny stos. Model żyje tam, gdzie uruchamia go dostawca LLM hosta (serwery Anthropic dla Claude, OpenAI dla GPT itp.). IDE jest hostem. Serwery MCP to narzędzia, które może wywołać model hosta. Maszyna programisty ma dostęp do systemu plików, dostęp do powłoki i wszystko inne, co IDE zdecydowało się wystawić. Programista wywołuje agenta; agent sięga do systemu plików programisty; wynik trafia do projektu programisty.²

To samo słowo „LLM”, bardzo różne promienie rażenia.

Sześć osi, na których oba stosy się rozchodzą

Sześć właściwości czyni tę rozbieżność konkretną:

Granica zaufania to wiersz nośny. LLM uruchomieniowa działa wewnątrz piaskownicy aplikacji w ramach oczekiwań prywatności użytkownika; LLM narzędziowa działa wewnątrz maszyny programisty, w ramach uprawnień programisty. Wzorzec typu niech LLM uruchomi polecenie powłoki jest normalny w narzędziach (Claude Code robi to ciągle przez swoje narzędzie Bash)³ i nie wchodzi w grę w środowisku uruchomieniowym: Foundation Models nie ma narzędzia Bash, a protokół Tool to typowana funkcja Swift, którą programista aplikacji napisał i przegląda.¹

Wiersz kosztu nadużycia jest konsekwencją błędnego ustawienia granicy zaufania. LLM uruchomieniowa, która eksfiltruje dane użytkownika na serwer, to naruszenie prywatności i odrzucenie wytycznych. LLM narzędziowa, która eksfiltruje kod źródłowy programisty do dostawcy LLM, jest, w zależności od umowy programisty, albo oczekiwanym zachowaniem, albo wyciekiem. Oba przypadki mają znaczenie; mają znaczenie z różnych powodów.

Serwer MCP, który stoi pomiędzy

Najczystsze miejsce, w którym widać ruchomą granicę, to sytuacja, gdy jeden serwer MCP jest używany przez oba stosy. Get Bananas dostarcza serwer MCP, który udostępnia operacje na liście zakupów: odczyt elementów, dodawanie elementów, oznaczanie jako wykonane. Ten sam serwer działa w dwóch miejscach.⁴

W sesji Claude Code programisty podczas iteracji serwer MCP to narzędzie, które agent programisty wywołuje w celu manipulowania własną listą programisty. Serwer działa na pliku JSON w iCloud Drive. Programista wpiął serwer w konfigurację hosta MCP; host wie, że ma go wywoływać; agent czyta/zapisuje elementy listy zakupów jako część większych zadań programistycznych.

Na powierzchni agentowej dla użytkownika końcowego (na przykład zewnętrzny użytkownik Claude Desktop wskazujący na współdzieloną listę) ten sam serwer MCP ma inne zobowiązania. Wywołującym nie jest już Blake-programista z pełnym zaufaniem do systemu plików; wywołującym jest użytkownik końcowy, którego uwierzytelnianie, autoryzacja i weryfikacja intencji nie są odpowiedzialnością programisty. Serwer MCP musi egzekwować te zabezpieczenia (lub odmówić udostępnienia siebie), zanim ta powierzchnia stanie się bezpieczna.

Ta sama metoda JSON-RPC, add_item, serwowana programiście przez lokalny transport stdio bez uwierzytelniania, ma odpowiedni kształt. Serwowana hostowi dostępnemu w internecie w imieniu dowolnego użytkownika końcowego bez uwierzytelniania, jest zagrożeniem dla integralności danych. Serwer MCP to ten sam kod; wszystko zmienia otaczające go wdrożenie.

Taka jest reguła routingu dla serwerów MCP w agentowym tworzeniu rozwiązań Apple. Serwer to typowany kontrakt nad domeną. To, gdzie znajduje się w stosie (narzędzie programisty czy powierzchnia użytkownika końcowego), jest decyzją wdrożeniową, a nie decyzją protokołu. Należy wykonać code review wdrożenia; nie wolno zakładać, że permisywne wartości domyślne protokołu są właściwymi wartościami domyślnymi wdrożenia.

Protokół Tool na urządzeniu nie jest serwerem MCP

Częste nieporozumienie: Foundation Models ma protokół Tool, a MCP ma wywołania narzędzi. Czy to to samo? Nie, a różnica ma znaczenie dla routingu.

Protokół Tool Foundation Models to API Swift, które programista aplikacji implementuje:¹

struct WaterEntryLookup: Tool {
    let name = "lookup_water_entries"
    let description = "Look up water intake entries for a given date range."
    @Generable struct Arguments { ... }
    func call(arguments: Arguments) async throws -> String { ... }
}

Narzędzie działa wewnątrz procesu aplikacji. Modelem, który narzędzie obsługuje, jest SystemLanguageModel urządzenia. Argumenty i wyjścia to typy Swift. Programista przegląda implementację, App Store przegląda aplikację. Użytkownik wywołuje funkcję; sesja aplikacji wywołuje narzędzie; model lokalny używa wyniku.

Narzędzie MCP to metoda JSON-RPC udostępniana przez serwer MCP, czyli oddzielny proces, do którego łączy się LLM hosta (Claude, GPT itp.):²

{
  "name": "add_item",
  "description": "Add an item to the shopping list.",
  "inputSchema": {"type": "object", "properties": {"name": {"type": "string"}}}
}

Narzędzie działa poza procesem agenta, w dowolnym języku wybranym przez programistę, komunikując się przez JSON za pomocą stdio lub Streamable HTTP. Model jest tam, gdzie umieścił go host. Argumenty to JSON walidowany względem schematu. Odpowiedzialność leży po stronie tego, kto wdrożył serwer MCP.

Te dwa protokoły rozwiązują nakładające się problemy o różnych zakresach:

Reguła routingu jest prosta: jeśli zdolność obsługuje własne funkcje LLM aplikacji dla użytkowników końcowych, idzie do Tool Foundation Models. Jeśli zdolność obsługuje zewnętrznego agenta (programistę lub użytkownika końcowego) działającego między procesami, idzie do narzędzia MCP. Niektóre aplikacje potrzebują obu; ta sama funkcja Swift może stać za oboma adapterami, ale adaptery żyją na różnych warstwach stosu i są dostarczane przez różne cykle wydawnicze.⁵

Hooki to miejsce, w którym LLM narzędziowa zarabia na swoje miejsce

Promień rażenia LLM narzędziowej sprawia, że hooki są nośnym prymitywem bezpieczeństwa. System hooków Claude Code uruchamia skrypty na zdarzeniach cyklu życia (PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, Stop).⁶ Programista iOS używający Claude Code konfiguruje hooki nie dlatego, że agent jest złośliwy, lecz dlatego, że uprawnienia agenta są szerokie: zapis do systemu plików, wykonywanie powłoki, commity git, push.

Wzorce, które zarabiają na swoje miejsce w hookach w agentowej pracy z Apple:

Blokada PreToolUse na poleceniach Bash dopasowujących xcodebuild lub xcrun bez wyraźnej zgody. Claude Code może uruchamiać kompilacje, kasować symulatory, wywoływać kroki podpisywania lub eksportu, albo modyfikować wygenerowany stan projektu, jeśli mu się na to pozwoli. Hook zamienia „agent uruchomił kompilację” w „agent poprosił o uruchomienie kompilacji i otrzymał zgodę”. Spowalnianie agenta w przypadku działań nieodwracalnych to właściwy kompromis dla pewności programisty.

Walidator PostToolUse na każdym wywołaniu narzędzia Edit lub Write na plikach .pbxproj. Plik projektu Xcode jest edytowalny przez ludzi, ale toksyczny dla agenta; jedna błędna linia po cichu psuje kompilację każdemu programiście w zespole. Hook uruchamiający plutil -lint (lub podobną kontrolę strukturalną) na każdym zapisie .pbxproj przed commitowaniem to różnica między „agent napisał migrację w pięć minut” a „agent napisał migrację i czterdzieści pięć minut bisecta git”.

Hook Stop, który uruchamia swift build (lub odpowiednie polecenie kompilacji), zanim pozwoli agentowi ogłosić zadanie ukończone. Agenci są trenowani na tym, jak ukończenie wygląda w rozmowie. Hook sprawia, że „ukończone” oznacza „kompilacja nadal się kompiluje”, co jest jedyną definicją mającą znaczenie dla wysyłki.

LLM uruchomieniowa nie potrzebuje niczego z tego. Foundation Models nie ma powłoki, gita, pliku projektu ani konfiguracji serwera MCP. Tool na urządzeniu to dowolna funkcja Swift, którą napisał programista aplikacji; użytkownik wywołuje funkcję; nic nie wymyka się z piaskownicy aplikacji ani uprawnień, chyba że sama implementacja Tool aplikacji to robi.

Asymetria jest sednem sprawy. LLM narzędziowa ma większe uprawnienia i potrzebuje większych zabezpieczeń. LLM uruchomieniowa ma mniejsze uprawnienia z definicji. Apple wykonało pracę uczynienia LLM uruchomieniowej bezpieczną; programista wykonuje pracę uczynienia LLM narzędziowej bezpieczną.

Zasady architektoniczne

Z rozróżnienia uruchomieniowy/narzędziowy wynikają trzy zasady architektoniczne.

Wybierz warstwę dla danej zdolności, a nie dla całej aplikacji. Aplikacja medytacyjna może używać Foundation Models do podsumowywania w aplikacji (LLM uruchomieniowa, na urządzeniu, dostarczana z aplikacją) oraz udostępniać serwer MCP, którego programista używa z Claude Code do masowego importu historii sesji podczas iteracji. Te dwie LLM obsługują różne zadania na różnych warstwach. Traktowanie ich jako jednej decyzji prowadzi do gorszego wyniku na obu warstwach niż traktowanie ich jako dwóch.

Zrób code review zasięgu LLM narzędziowej. Sesja Claude Code z pełnym dostępem do systemu plików i zdalnymi serwerami MCP jest potężnym środowiskiem programistycznym i hojną powierzchnią ataku. Środkiem zaradczym nie jest „zaufaj agentowi”; środkiem zaradczym są hooki, ograniczone uprawnienia oraz programista, który czyta diff. Agent pracuje dla Pana/Pani; agent nim/nią nie jest.

Dostarczaj zestaw Tool LLM uruchomieniowej jako stabilne API. Narzędzia Foundation Models są częścią binarnego kontraktu aplikacji. Usunięcie lub zmiana nazwy narzędzia między wydaniami to zmiana behawioralna dla użytkowników, którzy polegali na funkcji. Definicje narzędzi należy traktować jak elementy interfejsu użytkownika, a nie jak wewnętrznych pomocników.

Co zbudowałbym inaczej w moim stosie

Dwa wzorce, które aplikacje z klastra albo dostarczają, albo żałują, że ich nie dostarczyły.

Najpierw zbuduj warstwę domeny; pozwól, by narzędzia uruchomieniowe i serwery MCP narzędziowe opakowywały te same funkcje Swift. Wzorzec dual-adapter z App Intents kontra MCP naturalnie rozszerza się na narzędzia LLM uruchomieniowej. Metoda domenowa logWater(amount:caller:) jest opakowana przez AppIntent (powierzchnia Apple Intelligence), narzędzie MCP (powierzchnia agenta zewnętrznego) oraz Tool Foundation Models (powierzchnia LLM uruchomieniowej w aplikacji). Trzy adaptery protokołu, jedna funkcja domenowa, trzy klasy wywołujących (agent systemowy, agent zewnętrzny, model na urządzeniu) z trzema różnymi zobowiązaniami. Funkcja nie wie, który wywołujący ją wywołał; adaptery niosą ze sobą sygnały zaufania.

Traktuj serwery MCP agenta jak kod, a nie jak konfigurację. Plik .mcp.json przywoływany w projekcie iOS to powierzchnia zaufania o zakresie i pierwszeństwie (omówiona w Repozytorium nie powinno głosować nad swoim własnym zaufaniem). Claude Code rozwiązuje zakres serwera MCP jako lokalny > projekt > użytkownik, a serwery o zakresie projektu proszą programistę o zatwierdzenie przed użyciem. Agent czyta konfigurację i łączy się z serwerami zatwierdzonymi przez programistę; programista przegląda konfigurację i serwery. Dodanie serwera MCP do projektu to code review, a nie modyfikacja konfiguracji.

Kiedy Foundation Models jest właściwy, a kiedy LLM narzędziowa jest właściwa

Drzewo decyzyjne, do którego zbiegają się posty z klastra:

Is the capability a feature an end user invokes inside your app?
├── Yes → Runtime LLM (Foundation Models or cloud LLM behind an Apple Intelligence-aware surface)
│         Use the Tool protocol for app-internal tool calls.
│         Use App Intents for capabilities the system agent should reach.
└── No → It is part of the developer's iteration loop.
          ├── Is the capability local to one developer's machine? → Tooling LLM
          │     Use Claude Code, Cursor, or Codex CLI directly.
          │     Wrap shared utilities as MCP servers behind hooks.
          └── Is the capability shared across the team? → Tooling LLM with shared MCP servers
                Deploy the MCP server somewhere the team can reach.
                Code review the server like production code; gate dangerous tools behind explicit approval.

Decyzja rzadko prowadzi do remisu. Kiedy już prowadzi (ta sama zdolność może legalnie obsługiwać zarówno użytkowników końcowych, jak i programistów), odpowiedzią są dwa adaptery, a nie jedna współdzielona powierzchnia, ponieważ postawy zaufania i rytmy aktualizacji są na tyle różne, że jedna powierzchnia próbująca obsłużyć oba warianty pójdzie na kompromis w obu.

Co ten wzorzec oznacza dla aplikacji dostarczanych na iOS 26+

Trzy wnioski.

1. Dwie LLM, dwa stosy. LLM uruchomieniowa (Foundation Models, na urządzeniu) to agent użytkownika operujący na jego danych wewnątrz Pana/Pani aplikacji. LLM narzędziowa (Claude Code, Cursor, Codex CLI) to agent programisty operujący na maszynie programisty w celu zbudowania aplikacji. Dzielą słowo „LLM” i prawie nic więcej.

2. Granica zaufania to architektura. Gdzie działa model, kto go uruchamia i czego dotyka, definiuje zobowiązania. Wzorce, które pasują do jednej granicy, aktywnie zawodzą na drugiej.

3. Serwery MCP niosą granicę. Ten sam serwer w jednym wdrożeniu jest narzędziem programisty, a w innym powierzchnią użytkownika końcowego. Protokół się nie zmienia; zmienia się wdrożenie i to wdrożenie jest tą częścią, która wymaga uwagi inżynierskiej.

Pełny klaster Apple Ecosystem: typowane App Intents dla Apple Intelligence; serwery MCP dla agentów między-LLM; pytanie o routing między nimi; Foundation Models jako LLM na urządzeniu i protokół Tool, z przypadkami użycia i niestandardowymi adapterami jako rodzeństwem dopasowania workloadu i specjalizacji; Live Activities dla automatu stanów Lock Screen w iOS; kontrakt środowiska uruchomieniowego watchOS na Apple Watch; wnętrzności SwiftUI jako substrat frameworka; model mentalny przestrzeni RealityKit dla scen visionOS; dyscyplina schematu SwiftData dla persystencji; wzorce Liquid Glass dla warstwy wizualnej; dostawa multi-platform dla zasięgu między urządzeniami. Hub znajduje się w Apple Ecosystem Series. Dla szerszego kontekstu iOS-z-agentami-AI, zobacz iOS Agent Development guide.

FAQ

Jaka jest różnica między Foundation Models a Claude Code z punktu widzenia architektury?

Foundation Models to funkcja uruchomieniowa: LLM jest dostarczana z iOS 26, działa na urządzeniu użytkownika przez SystemLanguageModel.default i jest wywoływana, gdy uruchomi się LanguageModelSession aplikacji. Aplikacja wykonuje wywołanie w imieniu użytkownika. Claude Code to narzędzie programistyczne: LLM działa na infrastrukturze Anthropic (lub skonfigurowanego dostawcy Claude), maszyna programisty hostuje IDE, a agent ma dostęp do systemu plików programisty, powłoki i serwerów MCP. Programista kieruje agentem; agent pomaga zbudować aplikację.

Czy ten sam serwer MCP powinien obsługiwać zarówno mojego agenta, jak i moich użytkowników końcowych?

Prawdopodobnie nie. Ten sam kontrakt JSON-RPC może mieć właściwy kształt dla obu, ale wdrożenia są różne: stdio po stronie programisty bez uwierzytelniania jest normalne dla narzędzia programisty i jest zagrożeniem dla powierzchni użytkownika końcowego. Protokół jest reużywalny; wdrożenie nie jest. Jeśli już udostępnia się Pan/Pani ten sam serwer obu stronom, należy traktować to jako dwa wdrożenia za jednym kodem, a nie jedną powierzchnię dla obu odbiorców.

Dlaczego LLM narzędziowa potrzebuje hooków, a LLM uruchomieniowa nie?

LLM narzędziowa ma dostęp do systemu plików, dostęp do powłoki, serwery MCP i dowolne uprawnienia do wykonywania kodu na maszynie programisty. LLM uruchomieniowa (Foundation Models) ma cokolwiek udostępniają implementacje Tool aplikacji, wewnątrz piaskownicy aplikacji, bez powłoki. Promień rażenia jest asymetryczny. Hooki dają programiście recenzję przed wykonaniem i walidację po wykonaniu na szerokim zakresie uprawnień. LLM uruchomieniowa ich nie potrzebuje, ponieważ jej uprawnienia są ograniczone z konstrukcji.

Czy pojedyncza funkcja domenowa Swift może obsługiwać zarówno przypadki użycia LLM uruchomieniowej, jak i narzędziowej?

Tak, i to jest właściwy wzorzec. Podejście dual-adapter (jedna funkcja Swift, wiele opakowań protokołu) rozszerza się z App Intents kontra MCP na włączenie narzędzi Foundation Models. Funkcja nie wie, który wywołujący ją wywołał; adaptery niosą schemat, sygnały zaufania i zobowiązania specyficzne dla protokołu. Trzy adaptery, jedna metoda domenowa.

Gdzie w tym obrazie pasują hostowane chmurowe LLM (OpenAI, Anthropic API bezpośrednio)?

Chmurowe LLM wywoływane z wnętrza aplikacji w środowisku uruchomieniowym to trzecia kategoria: LLM uruchomieniowa z inferencją poza urządzeniem. Dzielą postawę zaufania Foundation Models „aplikacja wykonuje wywołanie w imieniu użytkownika”, ale tracą historię prywatności na urządzeniu i historię dostępności dostarczaną przez system operacyjny. Drzewo decyzyjne się rozszerza: chmurowe LLM uruchomieniowe są odpowiednie dla zdolności, które rzeczywiście przekraczają możliwości modelu na urządzeniu (duży kontekst, rozumowanie na granicy, multimodalność na skalę) i akceptowalne wobec oczekiwań prywatności użytkownika (z przejrzystym ujawnieniem). Foundation Models jest wartością domyślną, gdy workload pasuje; chmura jest eskalacją, gdy nie pasuje.

Bibliografia