Глава 6: Принципы проектирования

Дизайн TP строится вокруг пяти основных принципов. Эти принципы не только направляют техническое проектирование самого протокола, но и определяют стандарты поведения, которым должны следовать все участники экосистемы TP.

6.1 Разделяемое познание вместо передачи сообщений

Основной принцип проектирования TP: когда это возможно, отдавать приоритет установлению общего когнитивного пространства перед сериализованной передачей сообщений. Модель передачи сообщений вносит потери кодирования, задержку передачи и семантическую неоднозначность в каждом раунде взаимодействия; модель разделяемого познания позволяет сотрудничающим сторонам напрямую обращаться к одним и тем же когнитивным ресурсам, фундаментально устраняя трение передачи информации. Этот принцип не отрицает ценность передачи сообщений — установление самого общего пространства требует переговоров через сообщения — но чётко определяет направление проектирования TP: минимизировать ненужную сериализацию и десериализацию.

Практический пример: Два Fay совместно обрабатывают страховой случай ДТП. При модели передачи сообщений страховой Fay должен отправить полный отчёт об аварии, фотографии, информацию о транспортном средстве и детали полиса оценочному Fay... каждый раунд коммуникации включает упаковку и передачу больших объёмов данных. При модели разделяемого познания обе стороны устанавливают общий контекст, где отчёт об аварии, фотографии и информация о полисе смонтированы в общем пространстве. Оценочный Fay просматривает и аннотирует непосредственно в общем пространстве, а страховой Fay видит результаты аннотации в реальном времени — весь процесс подобен двум оценщикам убытков, сидящим за одним столом и просматривающим одно и то же дело.

6.2 Транспортный агностицизм

TP фокусируется на семантическом уровне, а не на транспортном уровне. Сообщения TP могут доставляться через JSON-RPC A2A, tool call MCP, традиционные REST API или даже Prompts на естественном языке. Этот принцип гарантирует, что TP не привязан к какому-либо одному базовому протоколу; когда появляются новые методы транспорта, TP нужно лишь добавить транспортный адаптер без изменения собственных семантических определений протокола. Транспортный агностицизм также означает, что TP изначально обладает прямой совместимостью — он может адаптироваться к транспортным протоколам, которые ещё не изобретены.

Практический пример: Корпоративный Fay, работающий в облаке, должен общаться с Fay, работающим на граничном устройстве (таком как шлюз датчиков завода). Облачный Fay нативно поддерживает A2A, но граничное устройство имеет только простой REST API. Транспортный агностицизм TP позволяет обеим сторонам общаться, не беспокоясь о транспортных возможностях друг друга — TP адаптируется автоматически, и intent, отправленный облачным Fay через A2A, прозрачно транслируется в вызов REST API, доставляемый на граничное устройство.

6.3 Адаптивное согласование протоколов

В гетерогенной экосистеме AI различные Fay могут «говорить» на разных протокольных языках. TP не требует от всех участников использования единого транспортного протокола; вместо этого через адаптивный механизм согласования и трансляции он позволяет Fay с разными «родными языками» беспрепятственно общаться. Процесс согласования включает три шага — зондирование возможностей, согласование контракта и семантическое отображение — гарантируя, что намерение не теряется при межпротокольной трансляции. Этот принцип снижает барьер входа в экосистему TP — любой Fay, поддерживающий хотя бы один метод транспорта, может участвовать в коммуникации TP.

Практический пример: HR-Fay транснациональной компании должен взаимодействовать с coFay социального страхования в разных странах. CoFay социального страхования США использует A2A, японский использует MCP tool call, а европейский использует REST API. HR-Fay не нужно писать разный интеграционный код для каждой страны — TP автоматически зондирует протокольные возможности контрагента при установлении сессии, согласовывает метод транспорта, поддерживаемый обеими сторонами, и вся последующая коммуникация полностью прозрачна.

6.4 Суверенитет Host над конфиденциальностью

В мировоззрении iFay каждый Fay действует от имени Host. Поэтому Host имеет абсолютный суверенитет над своими данными. Fay не может в одностороннем порядке решать, какие когнитивные ресурсы разделять — каждое раскрытие данных должно происходить в рамках, предварительно авторизованных Host. TP обеспечивает постоянную защиту данных конфиденциальности Host при передаче и доступе через тройной механизм сквозного шифрования, выборочного раскрытия (SelectiveDisclosure) и ограниченных по времени callback credentials (CallbackCredential). Host может отозвать авторизацию в любой момент, прекращая обмен данными.

Практический пример: iFay пользователя подаёт заявку на кредит в банковский coFay от его имени. Банку необходимо проверить подтверждение дохода и кредитную историю пользователя, но пользователь не хочет, чтобы банк видел его детали расходов и инвестиционный портфель. Пользователь явно указывает при авторизации, что «могут быть раскрыты только зарплатные ведомости за последние 12 месяцев и кредитный рейтинг», и iFay раскрывает только эти два элемента через механизм выборочного раскрытия. После завершения одобрения кредита callback credential автоматически истекает, и банковский coFay больше не может получить доступ к каким-либо данным пользователя. Если пользователь передумает на полпути, он может отозвать авторизацию в любой момент, немедленно прекращая обмен данными.

6.5 Аудируемые границы доверия

Доверие не слепо — оно должно строиться на проверяемой основе. TP требует, чтобы все операции, связанные с доступом к данным конфиденциальности, использованием credentials и межфайной коммуникацией, были аудируемыми. Записи аудита содержат тип операции, идентичности участников, временные метки и объём доступа, но не включают фактическое содержание данных или открытый текст токенов credentials. Host может просмотреть журнал аудита в любое время, чтобы понять, кто получил доступ к его данным, в какое время и с какой целью. Этот принцип гарантирует, что доверие в экосистеме TP является прозрачным и отслеживаемым.

Практический пример: iFay пациента взаимодействовал с медицинским coFay, страховым coFay и аптечным coFay несколько раз за последний месяц. Пациент может открыть журнал аудита и увидеть записи вроде: «3 апреля, 14:23 — Медицинский coFay получил доступ к вашей истории аллергий (авторизованный объём: данные, связанные с диагнозом)», «5 апреля, 09:15 — Страховой coFay получил доступ к кодам диагнозов и разбивке расходов через callback credential (credential истёк 5 апреля, 17:00)». Это подобно просмотру истории транзакций банковского счёта — каждая «транзакция данных» задокументирована.