Telegram-бот

Происхождение и история термина

24 июня 2015 года команда Telegram объявила о запуске Bot API и платформы для сторонних разработчиков. В анонсе боты описаны как аккаунты, которыми управляет программное обеспечение. Среди тогдашних примеров названы опросы, напоминания и отслеживание обновлений GitHub. Это исторические примеры из публикации о запуске, а не подтверждение доступности перечисленных ботов сегодня. ^[6]

Так возникло конкретное платформенное значение термина: Telegram-бот отличается от общего понятия чат-бота привязкой к аккаунту и программным интерфейсам Telegram. Чат-бот описывает способ взаимодействия через диалог, а Telegram-бот — способ предоставления программного сервиса в определённом мессенджере. Бот может выполнять действие по команде, не изображая человеческого собеседника. Такое разграничение следует из определения аккаунтов и примеров платформы. ^{[1, 6]}

Возможности продолжают расширяться. Например, в журнале Bot API за 8 мая 2026 года появились гостевой режим и получение некоторых сообщений других ботов. Поэтому старую формулу «боты никогда не видят сообщения ботов» нельзя применять ко всем современным режимам. ^[3] Сохраняется главное: поведение конкретного сервиса определяется его программой и предоставленными возможностями доступа.

Суть и механизм

API, или программный интерфейс, — набор правил, по которым одна программа обращается к другой. В данном случае Bot API связывает код разработчика с Telegram. Сервер — компьютер или предоставленная вычислительная среда, где этот код работает. Пользователю не нужно держать программу разработчика на своём телефоне: он взаимодействует с её аккаунтом через приложение. ^[1]

Событие, передаваемое боту, называется обновлением — Update. Это может быть новое сообщение или другое поддерживаемое действие. Обновления поступают двумя взаимоисключающими способами: программа запрашивает их методом getUpdates, либо Telegram посылает их на указанный разработчиком адрес — webhook. В первом случае получатель забирает события, во втором отправитель доставляет их сам. Очередь Telegram хранит неполученные обновления не более 24 часов. ^[3]

В учебном сервисе приёма замечаний последовательность будет такой: читатель отправляет ссылку, программа проверяет её, запрашивает описание ошибки, создаёт обращение и возвращает его номер. Система заявок здесь — отдельное хранилище, в котором редактор позже найдёт сообщение. Она может находиться рядом с программой бота или быть внешним сервисом; для разбора примера это несущественно.

Ключевой переход — от полученного текста к сохранённому обращению. Если программа отправляет «заявка зарегистрирована» до успешной записи, читатель получает неверное подтверждение при отказе хранилища. В предлагаемом сценарии сначала сохраняют обращение, затем сообщают его номер. Если отправка подтверждения не удалась, уже созданная заявка всё равно должна остаться доступной редактору.

Повторная доставка требует внимания: документация webhook предусматривает повтор запроса при неуспешном ответе сервера. Поле update_id идентифицирует обновление и помогает распознавать повторы. ^[3] Для нашего примера разумное проектное правило — один и тот же подтверждённый запрос не создаёт вторую заявку.

Близкий принцип формализован для HTTP — протокола обмена запросами и ответами между программами. В RFC 9110, § 9.2.2, метод называется идемпотентным, если несколько одинаковых запросов имеют тот же предусмотренный эффект на сервере, что и один. Ответы при этом могут различаться. ^[11] В нашем учебном сервисе применим аналогичный принцип к прикладной операции: повтор подтверждения оставляет одну зарегистрированную заявку. Сообщение «заявка уже зарегистрирована» может отличаться от первого ответа «заявка зарегистрирована», но вторая запись не появляется. Это требование к программе нашего бота; сам по себе обмен через Bot API не обеспечивает его выполнение.

Виды и классификации

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

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

Способ взаимодействия — отдельное основание классификации. В личном диалоге человек обращается к самому боту. В режиме inline он запрашивает материал из строки ввода другого чата и выбирает результат для отправки. Гостевой режим позволяет вызвать бота упоминанием или ответом и получить его ответ в чате без добавления в участники; при этом история чата ему не открывается. ^[7]

Мини-приложение, или Mini App, — дополнительный интерфейс на JavaScript, который может открываться через бота. Он полезен там, где предусмотрены формы или более сложное управление, но не обязателен для обычного обмена сообщениями. ^[1] В учебном сервисе ниже достаточно последовательных вопросов: отдельную форму можно обсуждать после проверки этого сценария.

Как применяется на практике

Рассмотрим учебный пример, а не описание действующего российского издания. Городская редакция хочет принимать замечания к публикациям. Она выбирает узкую задачу: собрать ссылку и описание, зарегистрировать обращение и сообщить читателю номер. Автоматическое сообщение подтверждает получение, но не означает, что ошибка уже признана или исправлена.

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

Далее описывают состояния диалога: ожидание ссылки, ожидание пояснения, проверка перед отправкой и завершение. Состояние означает, какой ответ программа ждёт сейчас. Это помогает избежать ситуации, когда слово «отмена» оказывается записано как описание ошибки, а повторная ссылка — как новое обращение. Для каждого шага заранее выбирают понятное поведение при неподходящем вводе.

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

Для подключения разработчик регистрирует аккаунт через BotFather — инструмент Telegram для управления ботами — и получает токен. Токен удостоверяет бота при обращении к API, а не заменяет пароль личного аккаунта человека. Его можно отозвать через BotFather. ^[8] Поэтому в передаваемых коллегам схемах и снимках экрана достаточно условного обозначения: значение секрета для объяснения работы не нужно.

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

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

Завершает проект передача ответственности. В учебной редакции назначают сотрудника, который видит обращения, и человека, который восстанавливает программу после отказа. Они согласуют текст сообщения о временной недоступности и порядок обработки накопленных заявок. Это организационные решения примера, а не гарантии Telegram: автоматизация регистрации не заменяет работу редактора.

Как измерить или проверить

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

Пусть за учебную неделю начаты 200 обращений, а 150 зарегистрированы с подтверждением пользователю. Формула имеет вид:

Знаменатель включает все 200 начатых обращений, в том числе незавершённые. Числитель включает только 150, которые удовлетворяют обоим условиям. Результат означает, что завершились три четверти начатых сценариев. Он не показывает, сколько ошибок в публикациях подтвердилось и насколько качественно редакция ответила людям.

Теперь усложним тот же учебный пример. Допустим, ещё 10 заявок записались, но подтверждение не было отправлено. Тогда сохранённых обращений 160, доля регистрации составляет 80%, а доля полного завершения остаётся 75%. Разница в пять процентных пунктов указывает на незавершённый этап подтверждения. Нельзя получить более высокий показатель, молча заменив им первоначальное определение результата.

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

Отдельный набор испытаний проверяет отмену, неверный ввод, повторную доставку, двойное нажатие и восстановление после недоступности хранилища. Для каждого случая нужен ожидаемый результат до запуска теста. Иначе любое поведение можно задним числом назвать правильным. При нулевом числе начатых обращений процент не вычисляют: данных для отношения нет, а запись «0%» ошибочно изображала бы измеренный результат.

Ошибки, ограничения и спорные вопросы

Режим приватности ограничивает сообщения, которые бот получает в группе. Например, при включённом режиме ему доступны адресованные команды и ответы на его сообщения; административные права меняют доступ. ^[2] Поэтому проверку группового сценария проводят в той конфигурации, которая будет использоваться в работе. Тест в личном диалоге не подтверждает, что бот увидит обычную реплику в группе.

В современных режимах общение ботов между собой допускается при предусмотренных настройках. Оно требует защиты от бесконечного обмена ответами. ^[7] Для учебного приёмщика обращений такое взаимодействие вообще не требуется: добавлять его только из-за наличия функции нет причины. Новая возможность платформы не становится автоматически потребностью проекта.

Другая ошибка — принимать аккаунт в Telegram за услугу самой платформы. Условия разработчиков описывают сторонние приложения как самостоятельные сервисы; даже отметка подлинности не означает одобрения их содержания Telegram. ^[4] Поэтому в нашем примере читателю сообщают название редакции и назначение приёмной, а не создают впечатление обращения в поддержку мессенджера.

Наконец, испытание одной успешной заявки проверяет лишь одну ветку. Оно не показывает, что случится при остановке внешнего сервиса или одновременной отправке множества обращений. Для учебного проекта результаты проверки записывают вместе с условиями: какая версия сценария работала, какие отказы воспроизводили и какие случаи ещё не испытывали. Это позволяет обсуждать ограничения конкретно, без обещания абсолютной надёжности.

Правовой аспект

Для российского проекта применимость законодательства о персональных данных оценивают по фактической обработке. Персональные данные — сведения, относящиеся к человеку, которого можно определить прямо или косвенно; оператор определяет цели, состав данных и действия с ними. Отсутствие поля «паспорт» само по себе не исключает обработку персональных данных. ^[5]

Статья 5 № 152-ФЗ требует определённых законных целей, соответствующего им объёма данных и ограниченного целями хранения, с установленными законом исключениями. В учебной приёмной цель — рассмотреть замечание; запрос даты рождения потребовал бы отдельного объяснения необходимости. Эти принципы приведены по редакции закона от 26.07.2026; они не заменяют оценки законности конкретного сервиса. ^[5]

Правила Telegram дополнительно требуют доступной пользователю политики приватности. Если стандартная политика не описывает обработку конкретного сервиса, нужна собственная. Ответственность за соответствие реальной работе остаётся у разработчика. ^[4] Основание обработки, размещение баз и передача данных между участниками проекта требуют отдельной юридической проверки до публикации и запуска.

Частые вопросы

Связанные термины

• Чат-бот
• Бот для розыгрышей
• SMM-специалист
• Персональные данные
• Оператор персональных данных
• Согласие на обработку персональных данных