Лонгрид к неделе 5 · без кода
Пять страниц о том, как сервис объявляет модели свои возможности и границы, почему это продолжение обычного API — и почему решение о том, какое поле не отдавать машине, всегда социальное.
MCP здесь — не тема сама по себе, а повод разобрать понятие двойного интерфейса на живом примере. Если через год стандарт назовут иначе, устройство вопроса не изменится: кто-то решает, что сервис рассказывает о себе машине, и это решение имеет последствия для людей.
Пока модель только отвечала текстом, ей ничего не требовалось от внешнего мира. Как только она стала действовать — искать, читать файлы, отправлять, записывать, — понадобился способ объяснить ей, что вокруг вообще есть.
Первое решение было кустарным: под каждый сервис писали отдельную обвязку. Модель подключали к почте одним способом, к календарю другим, к базе третьим. Каждое подключение — своя работа, свои допущения, свои поломки при обновлении. Умножьте на количество моделей и количество сервисов — получите известную инженерную проблему: связей больше, чем участников.
MCP — способ сервису объявить модели, что у него можно спросить, что можно сделать и в каком виде придёт ответ.
Model Context Protocol. По сути — тот же договор из недели 4, только выписанный специально под ИИ-агентов и в едином для всех формате. Сервис описывает себя один раз, а подключиться к нему может любая модель, которая понимает этот формат.
Стандарт предложила Anthropic и открыла его, то есть отдала спецификацию всем желающим. Мотив у такого шага обычно двойной: избавиться от возни с обвязками и одновременно сделать свой формат общим. Это нормальная логика — то же самое происходило со всеми стандартами в истории техники, от ширины железнодорожной колеи до розетки.
Без деталей реализации объявление сводится к трём вещам.
Какие сведения сервис готов отдать: перечень документов, статус заявки, расписание, содержимое папки. Не «все данные», а конкретный список.
Какие действия разрешены: создать запись, отправить письмо, изменить статус. Здесь же оговаривается, какие из них необратимы, — и это ровно то различение, которое понадобится на неделе 9.
Границы. Самая содержательная часть объявления и самая часто пустующая. Если границы не объявлены явно, агент достроит их сам — обычно неверно, и мы увидим последствия на практикуме недели 8.
Представьте, что ваш университет объявляет свои возможности для ИИ-агентов. Что бы вы разрешили узнавать, что делать и что запретили бы категорически?
Теперь главное понятие недели.
Двойной интерфейс — намеренно спроектированные слои одной и той же информации: для человека и для программы.
Человеку нужны заголовки, порядок чтения, цвет и умолчания. Программе нужны поля, типы и однозначность. Двойной интерфейс — это когда обе версии сделаны специально, а не когда одна досталась второму читателю случайно.
Слово «намеренно» здесь несущее. У большинства сервисов второй слой существует по случайности: агент вытаскивает смысл из вёрстки, из порядка блоков, из подписей к кнопкам. Пока шаблон не менялся, всё работает. Поменяли шаблон — агент начинает ошибаться и не сообщает об этом, потому что формально он ничего не нарушил.
Аналогия, которая помогает: книга и аудиокнига. История одна, носители разные, и для каждого принимались отдельные решения — где сделать паузу, что вынести в заголовок. Никто не считает аудиокнигу побочным продуктом печати.
Кажется, что бот — это и есть интерфейс для машины: с ним же разговаривает программа. На самом деле он теряет оба слоя сразу.
Машине он отдаёт свободный текст вместо полей. Той приходится разбирать формулировки и угадывать, что означает «в целом да, но с оговорками».
Человеку он отдаёт имитацию разговора вместо формы, в которой было бы три поля и кнопка. Человек вынужден описывать словами то, что быстрее выбрать из списка.
Оговорка, без которой тезис становится глупостью: речь не о том, что чат-боты плохи вообще. Речь о том, что они плохи там, где задача структурирована. А в корпоративном контуре таких задач большинство. Разбираться с этим будем на воркшопе недели 12.
Когда команда решает, что уйдёт в машинный слой, она принимает решение о том, что можно будет автоматизировать, что будет посчитано и что останется на усмотрение человека. Ниже — три типичных поля и настоящие причины, по которым их не отдают.
| Поле | Почему хочется отдать | Почему не отдают |
|---|---|---|
| Персональные данные | Без них агент не свяжет заявку с человеком | Правовой режим и риск утечки. Обычно отдают идентификатор вместо самих сведений |
| Основание решения | Позволило бы автоматически объяснять отказы | По машиночитаемому основанию можно собрать статистику отказов. Не всякая организация этого хочет |
| Внутренний приоритет | Помог бы правильно ранжировать обращения | Делает видимой неформальную иерархию клиентов, которую не принято обсуждать вслух |
Вторая строка — центральная для курса. Если основание отказа не выведено отдельным полем, статистику по причинам отказов физически не собрать, и жалобе не на что опереться. Непрозрачность здесь возникает не из сложности модели, а из архитектуры данных.
Возьмите сервис, где вам однажды отказали. Какое поле должно было бы существовать, чтобы вы могли этот отказ оспорить? Существует ли оно?
Может показаться, что это разговор об архитектуре данных. Он и есть об архитектуре данных — и именно поэтому он социологический.
Решение о том, какие поля существуют, принимается один раз, обычно техническими людьми, обычно без обсуждения. Дальше оно определяет, что организация о себе знает: какую отчётность может построить, какие закономерности заметит, на какие жалобы сможет ответить по существу. Проектирование полей — это проектирование того, что будет видимо.
Отсюда рабочая формулировка для итогового проекта: выбор интерфейса — не только дизайнерское решение. Если вы можете развернуть этот тезис на своём кейсе, вы закрыли половину критерия «архитектура» на защите.
Чем спроектированный машинный слой отличается от случайно доставшегося?
Почему пустой список границ — недосмотр, а не свобода агента?
Почему чат-бот теряет оба слоя сразу и в чём здесь необходимая оговорка?
Приведите поле, которого нет в знакомом вам сервисе, и скажите, что из-за этого нельзя посчитать.
Кто в организации принимает решение о составе полей и обсуждается ли оно вообще?
Что произойдёт с агентом, если завтра поменять вёрстку страницы, из которой он читал?
Для привычного сервиса — доставки, такси, расписания университета — представьте, как выглядел бы машинный слой. Без деталей реализации, на уровне идеи. Обязательное требование: назовите одно поле, которое вы решили не отдавать, и объясните почему. Именно это превращает задание из технического упражнения в социологическое.
На семинаре недели 5 смотрим один сайт глазами человека и глазами машины, затем воркшоп «Раздвоение»: два листа на один экран. Неделя 6 — защита кейсов, первая оценочная точка курса весом 25 %.