Лонгрид к неделе 4 · без единой строчки кода
Пять страниц о договоре между программами: кто его пишет, что в нём нельзя заказать, почему лимит запросов — социальное решение и как всё это определяет, что ИИ-агенту вообще разрешено делать.
Если вы с Разработки — большую часть вы знаете. Читайте ради последнего раздела: там шесть вопросов, которые социолог задаёт к API и которые в техническом обсуждении обычно не звучат. Если вы с Бизнеса или Дизайна — читайте целиком, кода не будет.
Интерфейс — это место, где две разные вещи соприкасаются и должны договориться. Розетка — интерфейс между электросетью и чайником. Обе стороны согласились на форму вилки, напряжение и частоту. Пока согласие держится, чайник можно купить в одном месте, а включить в другом.
Интерфейс всегда содержит запрет. В розетку нельзя воткнуть что попало — и это не недостаток, а условие работы. Согласие о форме — это и согласие о том, чего не будет.
API — договор между двумя программами.
Что можно спросить, чего спросить нельзя, в каком виде придёт ответ, как часто можно спрашивать и кому вообще разрешено обращаться.
Представьте меню в кафе. В нём перечислено, что есть, в каком виде и по какой цене. Вы не можете заказать то, чего в меню нет, — не потому что повар не умеет, а потому что договорённости об этом не существует. Официант не станет вести с вами переговоры о новом блюде.
API устроен так же. Он перечисляет доступные запросы. Каждый запрос описан: что нужно передать, что вернётся, какие бывают ошибки. Всё, чего в списке нет, недоступно, даже если система технически это умеет.
Это и есть первый социологический вывод. Список возможностей — не свойство технологии, а решение организации. Кто-то посчитал, что вот это отдавать наружу можно, а вот это — нет; вот за это берём деньги, а вот это даём бесплатно, чтобы привязать к себе.
Вспомните сервис, где вам не хватало какой-то возможности, хотя было очевидно, что система её умеет: выгрузить свои данные, отменить действие, посмотреть историю. Как вы думаете, почему её не дали?
Прежде чем спросить, нужно представиться. У каждого обращающегося есть ключ, и к ключу привязано, что именно ему разрешено. Один и тот же запрос от разных ключей может дать разный ответ или отказ. Права выдаёт не программа, а человек с полномочиями — обычно после спора со службой безопасности.
Договор почти всегда ограничивает, как часто можно спрашивать: столько-то запросов в минуту. Формально это защита от перегрузки. Фактически это распределение ресурса: у кого лимит выше, тот успевает больше. Лимиты продают, и это отдельная строка в бизнес-модели.
Ответ приходит в оговорённом виде: перечень полей с определёнными типами значений. Это и есть тот самый «слой для машины», о котором пойдёт речь на неделе 5. Поле, которого в ответе нет, для машины не существует.
Договор нельзя менять молча. Если поставщик уберёт поле или переименует его, у всех, кто на это поле опирался, что-нибудь сломается. Поэтому существуют версии: старая продолжает работать, новая живёт рядом, а на переход даётся срок.
Здесь прячется важное социальное обстоятельство. Обратная совместимость — это обещание, которое сильная сторона даёт слабой. Крупный поставщик может позволить себе объявить, что старая версия отключается через полгода, и десятки компаний будут срочно переписывать свои системы. Обратное невозможно.
Облако — это чужие серверы, сданные в аренду. Ничего воздушного в нём нет: это здания с машинами, которые кому-то принадлежат, стоят на чьей-то территории и подчиняются чьим-то законам.
Отсюда три вопроса, которые стоит задавать, даже не будучи инженером:
Третий вопрос — прямое продолжение темы недели: инфраструктура становится видимой в момент отказа. Пока договор действует, никто о нём не думает.
Назовите сервис, от которого зависит ваша учёба или работа, и ответьте: чьи это машины, где они и что вы будете делать, если завтра доступа не станет?
Теперь соберём тему недели. ИИ-агент действует в мире не напрямую. Он действует через договоры: чтобы что-то узнать или сделать, он обращается к API — поиску, файловому хранилищу, почте, базе, платёжной системе.
Значит, границы агента — это сумма договоров, которые ему доступны:
| Элемент договора | Что он определяет у агента |
|---|---|
| Список запросов | Что агент в принципе способен сделать. Всё остальное для него невозможно, как бы он ни «хотел» |
| Права ключа | Чьими полномочиями он действует и чья подпись стоит под его действиями |
| Лимит обращений | Сколько попыток у него есть, прежде чем он начнёт получать отказы и зацикливаться |
| Формат ответа | Что он вообще может узнать о ситуации — и чего не узнает никогда |
| Журнал обращений | Останется ли след, по которому потом можно восстановить, что произошло |
Последняя строка — заготовка Блока 3. На неделе 8 мы будем разбирать записи сессий, и там выяснится: восстановить можно только то, что кто-то заранее решил записывать.
В компаниях говорят «нужно интегрировать две системы», как будто речь о технической работе. На практике интеграция — это переговоры.
Чтобы две системы обменивались данными, кто-то должен договориться: какие поля отдаём, кто отвечает за качество данных, что делать при расхождении, кто платит за нагрузку, кого будить, когда сломается в три ночи. Эти вопросы решаются не кодом. Они решаются между отделами, и решаются медленно.
Поэтому фраза «у них плохой API» часто означает «мы не смогли договориться». А фраза «база не отдаёт данные», которую вы услышите на ролевой игре недели 13, почти никогда не про базу.
Кто составил список доступных запросов и по какому принципу что-то в него не попало?
Кто выдаёт ключи и с кем это согласуется?
Кому лимит выше остальных и почему именно ему?
Какое поле отсутствует в ответе — и что из-за этого нельзя посчитать или оспорить?
Кто может изменить договор в одностороннем порядке и в какой срок?
Что остаётся в журнале и кто имеет к нему доступ?
Четвёртый вопрос стоит выделить. Если в ответе нет поля «основание решения», то статистику по причинам отказов физически невозможно собрать. Не потому что кто-то её прячет, а потому что её нечем считать. Отсутствие поля — это тихая форма непрозрачности, к которой мы вернёмся на неделе 5.
Почему список возможностей API — решение организации, а не свойство технологии?
Что общего у розетки и API и в чём заключается запрет, который несёт любой интерфейс?
Почему обратная совместимость — обещание сильной стороны слабой?
Как договоры определяют границы вольера ИИ-агента?
Что означает отсутствие поля в ответе с точки зрения возможности возразить?
Почему «база не отдаёт данные» чаще всего не про базу?
Найдите инфраструктуру своей жизни, которая стала видна в момент отказа: упал мессенджер, лёг сайт университета, не сработала транспортная карта. Опишите, что именно проступило, кто это чинил и за чей счёт, и что вы делали, пока не работало. Описания неудобства недостаточно.
На семинаре недели 4 разбираем скриншот рекомендации, считаем участвовавшие системы и рисуем «дом ИИ» — квартиру одного агента с границами и правами. Прочитайте также выдержку из Susan Leigh Star: навигатор по ней — в материале «Как читать первоисточники курса».