Foundation Models w iOS 27: kontrola wywoływania narzędzi

iOS 26 dał aplikacji duży model językowy działający na urządzeniu, sposób uzyskiwania wyników o bezpiecznych typach dzięki @Generable oraz protokół Tool, który pozwalał modelowi wywoływać kod aplikacji w trakcie generowania¹. To model decydował, kiedy sięgnąć po narzędzie, a narzędzie pisał programista. Jedyne, czego nie dało się zrobić, to sterować samym zachowaniem wywołań, a jedyne, co trzeba było robić zawsze, to pisać każde narzędzie ręcznie, łącznie z tymi, których potrzebuje każda aplikacja. iOS 27 wypełnia obie te luki. GenerationOptions.ToolCallingMode pozwala kontrolować, jak model współdziała z narzędziami w obrębie pojedynczego żądania², a framework Vision dostarcza teraz dwa gotowe narzędzia, OCRTool i BarcodeReaderTool, które podpina się do sesji bez samodzielnego pisania kodu rozpoznawania³⁴. Razem domykają pętlę agentową, którą framework zapoczątkował: model decyduje, co zrobić, programista decyduje, jak stanowczo wolno mu to robić, a Apple dostarcza narzędzia percepcji odczytujące świat fizyczny.

Dalsza część to warstwa iOS 27 nałożona na dokumentację frameworka. Jeśli nie miałeś jeszcze do czynienia z LanguageModelSession, protokołem Tool ani z generowaniem sterowanym, zacznij od omówienia frameworka Foundation Models i wróć tutaj.

W skrócie

• GenerationOptions.ToolCallingMode to nowa w iOS 27 struktura, która opisuje zachowanie modelu w zakresie korzystania z narzędzi i którą ustawia się dla każdego żądania poprzez GenerationOptions². Apple dokumentuje trzy tryby.
• Framework może zmienić tryb po pierwszym wywołaniu narzędzia, dzięki czemu model przestaje wywoływać narzędzia i tworzy odpowiedź końcową, co ogranicza aktywność narzędziową pojedynczego żądania².
• OCRTool rozpoznaje tekst na obrazie i zwraca łańcuch zawierający wszystko, co odczytał. Włącza się je, konfigurując LanguageModelSession instancją OCRTool³.
• BarcodeReaderTool skanuje kody odczytywane maszynowo i zwraca tablicę wyników Barcode, z których każdy niesie zdekodowaną treść oraz typ symboliki. Włącza się je tak samo, konfigurując sesję instancją⁴.
• Oba narzędzia Vision pozwalają nadpisać domyślną nazwę i opis, dzięki czemu to programista decyduje, jak model rozpoznaje każde z nich i kiedy je wykorzystuje³⁴.
• Wszystko, co tu opisano, dotyczy bety iOS 27 (oraz odpowiadających jej bet iPadOS, macOS, visionOS, a dla dwóch z trzech symboli także watchOS)²³⁴.

Co zmieniło się między iOS 26 a iOS 27

Framework iOS 26 traktował wywoływanie narzędzi na powierzchni API zerojedynkowo. Przekazywało się sesji zestaw narzędzi i odtąd to wyłącznie model decydował, czy i jak często je wywoła. Sprawdza się to przy pojedynczym sprawdzeniu. Robi się niezręcznie w chwili, gdy chce się różnego zachowania w poszczególnych żądaniach w obrębie jednej sesji: jednego promptu, w którym model musi sięgnąć po narzędzie, i drugiego, w którym wolałbyś, żeby odpowiedział z kontekstu i pominął dodatkową rundę.

iOS 27 oddaje tę decyzję w ręce programisty. ToolCallingMode to wartość przekazywana poprzez GenerationOptions, ten sam obiekt opcji, który steruje już dekodowaniem²⁵, a tryb jest właściwością żądania, nie sesji. Wbudowane narzędzia Vision zmieniają drugą stronę równania: zamiast pisać potok OCR czy czytnik kodów kreskowych i opakowywać go we własną zgodność z Tool, podpina się implementację Apple, a wysiłek kieruje na prompt.

GenerationOptions.ToolCallingMode: sterowanie wywołaniami

ToolCallingMode to struktura w obrębie GenerationOptions, dostępna w betach iOS 27, iPadOS 27, Mac Catalyst 27, macOS 27, visionOS 27 i watchOS 27². Streszczenie Apple mieści się w jednym zdaniu: to wartość służąca do opisania zachowania modelu, gdy w grę wchodzi korzystanie z narzędzi². Deklaracja jest tak prosta, jak to tylko możliwe:

// iOS 27 beta
struct ToolCallingMode

Dokumentacja Apple podaje, że tryb wywoływania narzędzi obsługuje trzy tryby². Tekst opisowy, który nazwałby każdy z nich, jest w chwili pisania częściowo pominięty w dokumentacji, więc zamiast zgadywać identyfikatory, opiszę to, co framework dokumentuje o samym zachowaniu, bo to ta część naprawdę kształtuje projekt.

Zachowanie, które Apple wprost opisuje, brzmi tak: framework może zmienić tryb po pierwszym wywołaniu narzędzia, co pozwala modelowi utworzyć odpowiedź końcową². To jedno zdanie jest elementem nośnym. Oznacza, że żądanie może zacząć się w postawie, w której model ma swobodę wywołania narzędzia (lub jest do tego zobowiązany), a gdy to pierwsze wywołanie powróci, framework przełącza tryb, by model przestał sięgać po narzędzia i zdecydował się na odpowiedź. Praktyczny skutek to ograniczenie aktywności narzędziowej pojedynczego żądania: nie jesteś zdany na model, który w pętli wywołuje narzędzia, dopóki nie wyczerpie okna kontekstu.

Tryb ustawia się poprzez obiekt opcji, który i tak przekazujesz do respond(to:):

import FoundationModels

let session = LanguageModelSession(tools: [FindContacts()])

// A request where you want to govern tool-calling behavior explicitly.
var options = GenerationOptions()
options.toolCallingMode = .someMode   // one of the three documented modes
let response = try await session.respond(
    to: "Draft a dinner invite to three of my contacts.",
    options: options
)

Dokładna pisownia .someMode pochodzi z trzech udokumentowanych przypadków; liczy się mechanizm, a mechanizm polega na tym, że zachowanie obowiązuje dla każdego żądania i jest niesione przez GenerationOptions. Ten obiekt to ta sama struktura z iOS 26, która rządzi strategią dekodowania, sposobem wybierania przez model tokenów wyjściowych oraz opcjonalnym limitem tokenów odpowiedzi, po który sięgasz wyłącznie wtedy, gdy chronisz się przed rozhukaną rozwlekłością⁵. Tryb wywoływania narzędzi to nowy wymiar na powierzchni sterowania, której już używasz, a nie nowy obiekt, który trzeba przeprowadzać przez kod.

Sterowanie znajduje się na poziomie żądania, a nie sesji, ponieważ potrzeba narzędzia jest właściwością pytania, nie rozmowy. Sesja czatu może obsłużyć jedną turę, która naprawdę wymaga sprawdzenia kontaktów, i kolejną, która jest czystym przeformułowaniem, jakie model wykona z tego, co już posiada. Wymuszenie wywołania narzędzia w drugiej turze marnuje dodatkową rundę i spala tokeny, na które współdzielone okno kontekstu nie może sobie pozwolić⁵. Tryb na żądanie pozwala każdej turze zadeklarować własną postawę.

Wbudowane narzędzia Vision: OCRTool i BarcodeReaderTool

Druga połowa historii iOS 27 pochodzi z frameworka Vision, udostępnionego jako narzędzia Foundation Models. Apple dostarcza teraz dwa narzędzia, które podpina się do LanguageModelSession tak samo jak własne, z tą różnicą, że nie pisze się żadnego kodu rozpoznawania.

W sesji 241 Apple przedstawia BarcodeReaderTool i OCRTool jako wbudowane narzędzia systemowe, które wzmacniają zdolność modelu do wnioskowania o informacji wizualnej w sposób, jakiego nie potrafi natywnie.⁷

OCRTool

OCRTool rozpoznaje tekst na obrazie. Streszczenie Apple mówi dokładnie to, a opis precyzyjnie określa kontrakt: narzędzie zwraca łańcuch zawierający cały rozpoznany tekst z obrazu³. Aby je włączyć, konfigurujesz LanguageModelSession instancją OCRTool³. Deklaracja:

// iOS 27 beta, Vision framework
struct OCRTool

Podpięcie wygląda tak samo jak w przypadku dowolnego narzędzia, bo dla sesji to po prostu kolejny Tool:

import FoundationModels
import Vision

// Configure the session with an OCRTool instance to enable it.
let session = LanguageModelSession(tools: [OCRTool()])

let response = try await session.respond(
    to: "Pull the total and the date off this receipt image and summarize them."
)

Model decyduje, kiedy prompt wymaga tekstu z obrazu, wywołuje OCRTool, odbiera łańcuch ze wszystkim, co narzędzie odczytało, i wplata ten łańcuch w odpowiedź tak samo, jak wplótłby wynik narzędzia napisanego przez ciebie³. Nie napisałeś żadnego żądania Vision ani kodu obsługi. Podpiąłeś narzędzie i opisałeś zadanie.

Apple pozwala nadpisać domyślną nazwę i opis, by dostosować, jak model rozpoznaje i wykorzystuje narzędzie³. Ten zaczep to jedyna dźwignia, jaką masz nad tym, kiedy model sięga po OCR. Jeśli aplikacja odczytuje paragony, sformułowanie opisu narzędzia językiem paragonów skłania model do wywoływania go przy promptach przypominających paragony, a odwodzi od promptów, w których obraz jest jedynie ozdobą. Opis to dokumentacja funkcji, którą model czyta, więc napisz go właśnie tak.

BarcodeReaderTool

BarcodeReaderTool skanuje kody odczytywane maszynowo na obrazie⁴. Tam gdzie OCRTool zwraca płaski łańcuch, narzędzie kodów kreskowych zwraca strukturę: gdy model natrafi na obraz zawierający kody odczytywane maszynowo, może wywołać to narzędzie, aby je zdekodować, a narzędzie zwraca tablicę wyników Barcode, z których każdy zawiera zdekodowaną treść oraz typ symboliki⁴. Deklaracja i podpięcie odzwierciedlają OCRTool:

// iOS 27 beta, Vision framework
struct BarcodeReaderTool

// Configure the session with a BarcodeReaderTool instance to enable it.
let session = LanguageModelSession(tools: [BarcodeReaderTool()])

let response = try await session.respond(
    to: "Scan this label and tell me what product it is and which standard the code uses."
)

Typ symboliki zawarty w każdym wyniku Barcode to szczegół, który uzasadnia strukturalny zwrot⁴. Kod QR, sklepowy kod kreskowy EAN-13 i PDF417 na prawie jazdy to wszystko kody odczytywane maszynowo, ale dla twojej aplikacji znaczą co innego. Ponieważ narzędzie zwraca symbolikę obok zdekodowanego ładunku, model (a także twój dalszy kod) może rozgałęziać się według rodzaju kodu, a nie tylko bajtów w jego wnętrzu. Tak jak w OCRTool, możesz nadpisać domyślną nazwę i opis, by sterować tym, jak model rozpoznaje i wykorzystuje narzędzie⁴.

Oba narzędzia mają taką samą dostępność w wersji beta: iOS 27, iPadOS 27, Mac Catalyst 27, macOS 27 i visionOS 27 dla obu, przy czym BarcodeReaderTool figuruje dodatkowo dla watchOS 27³⁴.

Składanie pętli: percepcja i kontrolowane wywołania

Obie funkcje są ciekawe same w sobie, a razem są lepsze, bo siedzą na przeciwnych końcach jednego agentowego żądania. Narzędzia Vision to percepcja, oczy modelu na obrazie. ToolCallingMode to nadzór, twoja ręka na tym, jak mocno model opiera się na tych oczach.

Wyobraź sobie funkcję uzupełniania spiżarni. Użytkownik fotografuje półkę. Sesja ma podpięte oba narzędzia Vision oraz jedno własne, LookUpProduct, które odpytuje katalog aplikacji. Pojedyncze żądanie prosi model o zidentyfikowanie pozycji i zbudowanie listy zamówień. Model wywołuje BarcodeReaderTool, by zdekodować widoczne etykiety, odczytuje za pomocą OCRTool nadrukowany tekst przy pozycjach bez czytelnego kodu i wywołuje twoje LookUpProduct, by rozwiązać każdy zdekodowany ładunek do wpisu w katalogu. Trzy narzędzia, jeden prompt, jedna spójna odpowiedź.

import FoundationModels
import Vision

let session = LanguageModelSession(tools: [
    OCRTool(),
    BarcodeReaderTool(),
    LookUpProduct(),     // your own Tool conformance over the app catalog
])

var options = GenerationOptions()
options.toolCallingMode = .someMode   // govern how the model sequences the calls
let response = try await session.respond(
    to: "Identify everything on this shelf and build a reorder list.",
    options: options
)

To właśnie pętla, ku której framework zmierzał. iOS 26 dostarczył model uruchomieniowy, generowanie sterowane i protokół Tool, który pozwala modelowi na urządzeniu wywoływać twój kod bez parsowania swobodnego tekstu¹. Artykuł architektoniczny z tego zbioru wytyczył granicę między tym modelem uruchomieniowym a narzędziowym LLM, który programista uruchamia w Claude Code, by napisać aplikację, i argumentował za jedną swiftową funkcją dziedzinową stojącą za narzędziem Tool Foundation Models, App Intentem i narzędziem MCP poprzez trzy cienkie adaptery⁶. iOS 27 wpasowuje się w uruchomieniową stronę tego obrazu: wbudowane narzędzia Vision to funkcje dziedzinowe napisane przez Apple, które montujesz, LookUpProduct to funkcja dziedzinowa napisana przez ciebie, model orkiestruje je wszystkie, a ToolCallingMode jest przepustnicą tej orkiestracji.

Granica zaufania nie drgnie. OCRTool i BarcodeReaderTool działają wewnątrz procesu aplikacji na urządzeniu, na obrazie użytkownika, w tej samej piaskownicy i z tą samą postawą wobec prywatności co narzędzie napisane przez ciebie. To, że Apple dostarcza implementację, zmienia, kto utrzymuje kod rozpoznawania, a nie to, kto odpowiada za funkcję. Nadal należą do ciebie prompt, sesja, sprawdzenie dostępności oraz decyzja, by postawić aparat przed użytkownikiem.

Kiedy stosować każdy tryb i każde narzędzie

Kilka reguł wynikających z powyższych kontraktów.

Po ToolCallingMode sięgaj, gdy potrzeba narzędzia zmienia się w poszczególnych żądaniach. Jeśli każda tura w sesji wymaga tego samego zachowania narzędziowego, wartość domyślna wystarcza, a tryb jest tylko szumem. Tryb zarabia na swoje miejsce, gdy jedno żądanie musi sięgnąć po narzędzie, a inne powinno odpowiedzieć z kontekstu, albo gdy chcesz, by przełączenie frameworka po pierwszym wywołaniu ograniczyło żądanie, które inaczej mogłoby wejść w pętlę². Ustaw go na żądaniu, a nie raz dla sesji, bo właśnie tam mieści się sterowanie².

Po OCRTool sięgaj, gdy odpowiedź to tekst uwięziony w obrazie. Paragony, znaki, odręczne notatki, zrzuty ekranu z tekstem. Narzędzie zwraca jeden łańcuch ze wszystkim, co odczytało³, więc pasuje do promptów, w których chcesz, by model wnioskował o słowach, a nie o układzie. Jeśli potrzebujesz ramek ograniczających albo pewności w podziale na wiersze, to żądanie Vision niższego poziomu, a nie to narzędzie.

Po BarcodeReaderTool sięgaj, gdy obraz niesie kody odczytywane maszynowo i liczy się rodzaj kodu. Etykiety produktów, bilety, dokumenty tożsamości, znaczniki inwentarzowe. Strukturalny zwrot, zdekodowana treść wraz z symboliką⁴, to powód, by przedłożyć go nad traktowanie kodu kreskowego jak zwykłego tekstu. Rozgałęziaj się według symboliki we własnym narzędziu lub w obróbce końcowej.

Nadpisuj nazwę i opis za każdym razem, gdy aplikacja powierza ogólnemu narzędziu konkretne zadanie. Oba narzędzia Vision mają domyślnie ogólną tożsamość, a model częściowo dobiera narzędzia po ich opisach³⁴. Aplikacja, która odczytuje wyłącznie paragony, powinna to napisać w opisie narzędzia OCR, by model nie wywoływał go przy każdym zdjęciu, na którym przypadkiem znajdzie się jakieś słowo.

Najczęściej zadawane pytania

Czym jest GenerationOptions.ToolCallingMode w iOS 27?

To struktura, nowa w becie iOS 27, która opisuje zachowanie modelu w zakresie korzystania z narzędzi dla danego żądania. Ustawia się ją poprzez GenerationOptions przekazywane do respond(to:), dzięki czemu zachowanie wywołań narzędzi jest właściwością każdego żądania, a nie całej sesji. Apple dokumentuje trzy tryby².

Ile trybów wywoływania narzędzi dokumentuje Apple i jak się nazywają?

Dokumentacja Apple podaje, że tryb wywoływania narzędzi obsługuje trzy tryby². Tekst dokumentacji, który nazywałby każdy tryb z osobna, jest w chwili pisania częściowo pominięty, więc opisuję udokumentowane zachowanie, zamiast zgadywać identyfikatory. Zachowanie, które Apple opisuje wprost: framework może zmienić tryb po pierwszym wywołaniu narzędzia, by model utworzył odpowiedź końcową, co ogranicza aktywność narzędziową pojedynczego żądania².

Jak włączyć wbudowane narzędzie OCR od Apple?

Skonfiguruj LanguageModelSession instancją OCRTool, tak samo jak podpinasz dowolne narzędzie³. Model wywoła je wtedy, gdy prompt potrzebuje tekstu z obrazu, a narzędzie zwróci łańcuch zawierający cały rozpoznany tekst. OCRTool znajduje się we frameworku Vision i jest dostępne w becie iOS 27³.

Co zwraca BarcodeReaderTool?

Zwraca tablicę wyników Barcode, z których każdy zawiera zdekodowaną treść oraz typ symboliki⁴. Symbolika pozwala odróżnić kod QR od EAN-13 i od PDF417 oraz rozgałęziać się według rodzaju kodu, a nie tylko jego ładunku. Włączasz je, konfigurując LanguageModelSession instancją BarcodeReaderTool⁴.

Czy mogę zmienić to, jak model decyduje o użyciu wbudowanych narzędzi Vision?

Tak. Zarówno OCRTool, jak i BarcodeReaderTool pozwalają nadpisać domyślną nazwę i opis, by dostosować, jak model rozpoznaje i wykorzystuje narzędzie³⁴. Opis jest dźwignią nad tym, kiedy model sięga po narzędzie, więc sformułowanie go językiem własnej aplikacji skłania model ku właściwym wywołaniom.

Czy wbudowane narzędzia Vision wysyłają obrazy poza urządzenie?

Nie. OCRTool i BarcodeReaderTool to narzędzia Foundation Models, które działają wewnątrz procesu aplikacji na urządzeniu, w tej samej piaskownicy i z tą samą postawą wobec prywatności co narzędzie napisane przez ciebie¹³⁴. To, że Apple dostarcza kod rozpoznawania, zmienia, kto go utrzymuje, a nie to, gdzie działa ani kto odpowiada za funkcję.

Pełny zbiór Apple Ecosystem: omówienie frameworka Foundation Models; LLM na urządzeniu; rozróżnienie między LLM uruchomieniowym a narzędziowym; adaptery niestandardowe; typowane App Intents; nowe wykonywanie w tle i synchronizacja App Intents w iOS 27; kwestia routingu wobec narzędzi MCP; framework Vision; wnioskowanie z Core ML; trzy powierzchnie. Centrum znajduje się w serii Apple Ecosystem. Szerszy kontekst iOS z agentami AI znajdziesz w przewodniku po tworzeniu agentów iOS.