Stateless MCP и stateful-сценарии AI-агента на Android
Что изменилось в MCP 2026-07-28, как работает stateless request lifecycle и где телефонный агент Android должен хранить состояние задачи, approval, device state и recovery.
- MCP 2026-07-28 делает core protocol stateless: запросы становятся самодостаточнее, могут маршрутизироваться на совместимый серверный экземпляр и не требуют обязательной скрытой transport session.
- Stateless MCP и stateful-сценарии AI-агента сочетаются естественно: протокол масштабируется без сессионной привязки, а приложение агента хранит conversation, task, device, approval, auth и audit state там, где ими можно управлять.
- MCP Tasks, MRTR, elicitation и explicit state handles помогают строить долгие операции и пользовательский ввод, но task handle не является user approval, разрешением Android или полной моделью аудита.
- Из текущего опыта FoneClaw мы видим, что надежный Android workflow требует host-side task continuity, permission recovery, idempotency, visible approval, device-state recheck и проверяемого результата.
Что изменилось в MCP 2026-07-28
Stateless MCP и stateful-сценарии AI-агента звучат как противоречие только на первом чтении. На практике это две разные области. Финальный релиз Model Context Protocol 2026-07-28 переводит core protocol к stateless-модели: запрос должен нести достаточно информации, чтобы совместимый серверный экземпляр мог обработать его без обязательной скрытой transport session. При этом приложение агента по-прежнему может хранить память, состояние задачи, approvals, audit и recovery на своем уровне.
Для нас в FoneClaw это важная архитектурная развилка. Телефонный агент Android работает с живым устройством: экран меняется, разрешения появляются и исчезают, пользователь останавливает действие, приложение показывает новый диалог, сеть падает, а результат нужно проверить. Такое состояние нельзя растворить в случайном MCP-сервере. Оно должно принадлежать host-side агенту, который понимает пользователя, устройство и текущую задачу.
SEP-2575, описанный как Make MCP Stateless, убирает обязательный initialization handshake для stateless-first lifecycle и переносит ожидания в per-request metadata. Релиз также включает MRTR, header routing, cacheable lists, authorization hardening и extensions framework. Для discovery и доверенных ресурсов рядом полезен наш материал Agentic Resource Discovery: ai-catalog.json, доверенные каталоги и полномочия phone agent, потому что stateless request все равно должен приходить к известной и проверяемой возможности.
Как работает stateless request lifecycle в MCP
В stateless request lifecycle клиент отправляет запрос так, чтобы сервер не полагался на неявное состояние прежней transport session. Идентичность, capabilities, версия протокола, routing headers, tool arguments и нужные ссылки на состояние передаются явно. Это облегчает балансировку нагрузки, serverless deployment, рестарты и обработку запросов любым совместимым экземпляром. Серверу не нужно помнить, что было согласовано в прошлой невидимой сессии, чтобы понять текущую просьбу.
При этом «самодостаточный запрос» не означает, что сложная функция всегда укладывается в один network call. Списки инструментов могут кэшироваться. Discovery может происходить отдельно. Long-running work может возвращать handle. Stateful application может хранить задачу, а в MCP передавать ссылку, которую сервер понимает. Главное — это явность: состояние не живет как неформальное ожидание в канале связи, а оформляется в metadata, handle или state store приложения.
SEP-2567, Sessionless MCP via Explicit State Handles, описывает путь, где implicit protocol session state заменяется explicit server-minted state handles. Такой handle можно передавать в последующих вызовах. Для телефонного агента это удобно, когда инструмент готовит долгую операцию или ожидает дополнительный ввод. Но handle остается технической ссылкой. Он не заменяет user approval, Android permission, device-state validation или audit trail.
Из опыта FoneClaw мы бы проектировали connector так: MCP-сервер без состояния обрабатывает конкретный запрос, а phone-agent host хранит задачу, approvals, idempotency keys, device snapshot, user intent и recovery plan. Тогда инфраструктура масштабируется, а пользовательская задача остается цельной.
Шесть видов состояния, которыми владеет телефонный агент
AI-агент с состоянием для телефона должен разделять несколько журналов состояния. Если все сложить в один «session object», восстановление быстро становится хрупким: непонятно, что можно повторить, что требует нового подтверждения, где истекла авторизация и какой экран нужно перечитать. Мы используем ментальную карту из шести ledger, чтобы задача оставалась управляемой поверх stateless transport.
| Состояние | Что хранит | Кто должен владеть | Что передается MCP-инструменту |
|---|---|---|---|
| Conversation state | Намерение, уточнения, контекст разговора | Агентский host | Сжатая цель и релевантные параметры |
| Task state | Текущий этап, expected result, статус waiting/running/done | Агентский host | Task id или explicit state reference |
| Device state | Текущий экран, приложение, доступность элемента, network/device status | Телефонный host с повторным чтением | Свежий snapshot или verified target |
| Approval state | Что пользователь подтвердил, для какого объекта и действия | Агентский host | Approval reference, scope и expiry |
| Auth state | Учетные данные, delegated access, token state | Auth subsystem и policy layer | Минимальный scoped credential или capability |
| Audit state | Кто запросил, что выполнено, чем завершилось, как восстановлено | Агентский host или audit service | Correlation id и result record |
Approval и auth особенно важно держать отдельно. Пользователь может быть авторизован в сервисе, но это не дает автоматического согласия отправить SMS или изменить настройку. И наоборот, пользователь может подтвердить действие, но отсутствующий Android permission остановит выполнение. Глубже этот дизайн раскрыт в материале Идентичность ИИ-агента: разрешения, аудит и подтверждение инструментов.
Device state требует повторного чтения. Экран, который был актуален пять секунд назад, мог измениться: приложение закрылось, всплыл системный диалог, сеть пропала, кнопка стала недоступной. Поэтому MCP-запрос может быть stateless, но телефонный workflow должен re-read и verify device state перед внешним эффектом.
MCP Tasks, MRTR, elicitation и подтверждения
MCP 2026-07-28 включает extensions framework, а Tasks описывается как formal extension. Это важный шаг для долгих операций: инструмент может вернуть task handle, а клиент — позже проверить состояние или продолжить работу. MRTR помогает маршрутизировать interaction, где модель, tool и пользователь могут обмениваться запросами, ответами и уточнениями. Elicitation дает способ запросить недостающий ввод у пользователя.
Для телефонного агента это полезно, когда задача не завершается сразу. Например, инструмент подготовил действие, но ждет выбора SIM-карты, подтверждения текста, выдачи разрешения или восстановления доступа. Task handle помогает связать последующие вызовы с серверной работой. Elicitation помогает получить недостающие данные. MRTR помогает не превращать каждое уточнение в новый неподконтрольный разговор.
Практическая граница остается ясной: task handle — это не authorization. Он указывает на работу или состояние инструмента, но не доказывает, что пользователь подтвердил действие на телефоне. Approval record должен хранить, что именно подтверждено: объект, действие, параметры, время, источник, scope и expiry. Для sensitive Android steps подтверждение остается видимым и привязанным к задаче.
Такой подход не возвращает hidden transport sessions. Он делает state явным: часть хранится в extension, часть в agent host, часть в auth layer, часть в audit. Именно так stateless MCP может поддерживать stateful application без смешивания протокольного соединения и пользовательской ответственности.
Stateful Android workflow поверх stateless MCP
Возьмем задачу: «Включи режим встречи на час, но оставь важные звонки». В FoneClaw-подходе первая часть живет в agent host: intent, пользовательские уточнения, текущий экран, ожидаемый результат, нужный Android permission и state id задачи. Если часть действий вызывается через внешний MCP connector, запрос получает per-request metadata, idempotency key, target capability и explicit reference на task state. MCP-сервер без состояния обрабатывает конкретный tool request, а host сохраняет долгую пользовательскую задачу.
Перед выполнением phone-agent host перечитывает device state: доступна ли настройка, активен ли текущий режим, нужен ли новый permission, не изменился ли экран. Затем пользователь видит approval: включить DND на час, оставить исключение для выбранных контактов, применить сейчас. Approval state хранится отдельно от auth. Если пользователь подтверждает, governed tool выполняет Android-действие. Если разрешение отсутствует, permission recovery открывает путь к настройке и возвращает пользователя к той же задаче.
После выполнения нужен verify step. Агент проверяет, что режим действительно включен и параметры совпадают. Если сетевой вызов или tool request повторяется, idempotency key помогает не применить действие дважды. Если серверный экземпляр упал, stateless MCP позволяет повторить запрос на другой instance, но host должен классифицировать retry: read-only, safe repeat, external effect, needs verification или requires new approval.
Та же схема работает для visible messaging, dialer, navigation и selected settings workflows. Для звонков отдельно полезен материал Телефонные звонки ИИ-агента: MCP-сервисы или Android-звонилка FoneClaw, потому что call task часто лучше отдавать native dialer path. А current-screen continuity на стороне FoneClaw host раскрыта в статье Плавающий ИИ-ассистент Android и текущий экран: контекст, действия и контроль.
По актуальной информации о продукте на момент обновления статьи, FoneClaw уже показывает host-side логику, которая нужна таким workflow: floating assistant, same-phone task continuity, permission recovery и quick actions. Актуальную сборку можно получить на странице загрузки FoneClaw, а текущие supported Android workflows описаны на странице функций FoneClaw.
Как масштабировать MCP-сервер без потери надежности телефонной задачи
MCP-сервер без состояния проще масштабировать. Load balancer может направить запрос на любой совместимый instance. Serverless process может стартовать без восстановления прежней session. Рестарт сервера не стирает протокольное соглашение, потому что нужная metadata приходит в каждом запросе. Официальный MCP Go SDK v1.7.0 показывает реализацию lifecycle для protocol 2026-07-28 с per-request metadata, server discovery и compatibility paths для legacy versions.
Надежность телефонной задачи при этом живет выше. Для каждого tool call нужен correlation id, idempotency key, retry class и result verification. Read-only запрос можно повторить проще. Запрос, который меняет состояние Android или внешнего сервиса, требует дедупликации и проверки результата. Если результат неизвестен, agent host должен не нажимать «еще раз» вслепую, а проверить device state, audit record или состояние внешней задачи.
Retries нужно классифицировать по последствиям. Безопасный repeat — перечитать экран, получить статус, обновить discovery. Осторожный repeat — восстановить черновик, если idempotency key подтверждает тот же intent. External effect — SMS, звонок, настройка, публикация, удаление — требует visible verification и иногда нового approval. Такая дисциплина защищает пользователя от двойной отправки, двойного изменения и скрытого сбоя.
Для recorder-to-action workflow это особенно заметно: встреча может создать задачу, задача вызвать tool, tool запросить approval, а телефон выполнить действие позже. Такой путь подробно раскрывает статья MCP для AI-диктофона: от заметок встречи к действиям. Stateless transport помогает инфраструктуре, а stateful host удерживает смысл и ответственность.
Границы безопасности и checklist миграции
Security boundary начинается с разделения auth и approval. Auth отвечает за то, что агент или connector имеет право обратиться к сервису. Approval отвечает за то, что пользователь подтвердил конкретное действие в текущей задаче. Explicit state handle помогает продолжить техническую работу, но не становится permission, consent или audit trail. MCP 2026-07-28 также включает authorization hardening, поэтому migration стоит делать вместе с пересмотром токенов, scopes, expiry и logging.
Legacy compatibility требует переговоров по версиям и fallback paths. MCP Go SDK v1.7.0 показывает, что новые lifecycle-механики могут сосуществовать с compatibility paths для старых protocol versions. В продукте это означает staged rollout: сначала discovery и metadata, затем explicit handles, затем Tasks, затем retries/idempotency policy, затем audit и observability. Каждая стадия должна иметь тесты на restart, duplicate request, expired approval и device-state drift.
Если бы мы проектировали FoneClaw connector к stateless MCP, checklist выглядел бы так:
- Передавать per-request identity, protocol version, capability и correlation id.
- Хранить task state в phone-agent host, а не в implicit transport session.
- Выдавать idempotency key для каждого действия с внешним эффектом.
- Разделять auth token, user approval, Android permission и task handle.
- Перечитывать device state перед выполнением sensitive step.
- Проверять результат после действия и записывать audit event.
- Поддерживать cancellation, expiry и recovery path.
- Тестировать legacy clients и новую stateless lifecycle отдельно.
Такой подход сохраняет сильную сторону MCP 2026-07-28 — масштабируемый stateless transport — и одновременно дает телефонному агенту то, что нужно пользователю: устойчивое состояние задачи, понятные разрешения, видимое подтверждение, восстановление и проверяемый результат.