Суть. Раньше каждое подключение источника данных к помощнику писалось отдельно под конкретную связку. Единый протокол описывает, как приложение объявляет доступные инструменты и данные, а модель их вызывает. Практический эффект — интеграция пишется один раз и работает с разными помощниками.
Что это меняет
| Своя интеграция под каждую пару | Общий протокол | |
|---|---|---|
| Стоимость | Растёт как произведение источников на приложения | Растёт как сумма |
| Смена помощника | Переписывать всё | Переподключить |
| Безопасность | Права описаны в каждой интеграции по-своему | Единая точка описания доступных действий |
| Аудит | Журналы разрозненные | Один слой, где видно все обращения |
Что важно для пресейла
Ключевой вопрос при обсуждении с заказчиком — не «поддерживает ли протокол», а «какие действия открыты и кто это решает». Открытый набор инструментов означает, что помощник может не только читать, но и менять состояние систем. Это переводит разговор в плоскость прав и журналирования.
Какую задачу это решает
Модель сама по себе умеет только рассуждать над текстом. Полезной она становится, когда получает доступ к почте, документам, базе или системе учёта. Без общего протокола каждое такое подключение пишется отдельно: пять моделей и десять систем дают пятьдесят интеграций. Единый протокол превращает это в пятнадцать.
| Без протокола | С протоколом |
|---|---|
| Интеграция под конкретную модель | Интеграция один раз, работает с любой моделью |
| Смена поставщика модели — переписывание | Смена поставщика — смена настройки |
| Права и журналирование в каждой связке свои | Единая точка контроля доступа |
Что важно решить до подключения
- Какие данные вообще допустимо отдавать модели. Это решение бизнеса и безопасности, не разработки.
- От чьего имени действует агент: своя учётная запись с ограниченными правами, а не права пользователя целиком.
- Что журналируется: какой инструмент вызван, с какими параметрами, что вернул. Без журнала разбор инцидента невозможен.
- Где стоит граница между чтением и действием. Чтение можно разрешать широко, действия — по списку.
Где ломается
Открывают слишком много. Подключение всей системы «на всякий случай» вместо конкретных операций.
Нет журнала намерений. Видно, что вызвано, не видно почему — разбор инцидента становится гаданием.
Считают, что протокол решает вопрос качества. Он решает вопрос подключения; качество ответов остаётся отдельной задачей.
Права выдают «пока широко, потом сузим». Не сужают никогда. Первая же ошибка модели становится ошибкой с полными правами.
Подключают всё подряд. Чем больше доступных инструментов, тем хуже модель выбирает нужный. Десять точных инструментов работают лучше пятидесяти.
Забывают про стоимость. Каждый вызов инструмента — это дополнительный контекст и дополнительные деньги. Без ограничений расход растёт незаметно.
Первый вопрос при подключении не технический: что произойдёт, если модель вызовет этот инструмент неправильно. Если ответ «ничего страшного» — подключайте. Если «испортит данные клиента» — нужна подтверждающая ступень.
Частые вопросы
Связанное
Ценность не в самом протоколе, а в том, что решение о правах и журналировании принимается один раз, а не заново на каждой интеграции.