pystone — это такой синтетический тест, искусственная трасса без ям и светофоров. Он замеряет «чистую» скорость выполнения питоновских операций: создание объектов, вызовы функций, простые циклы, работа со строками и списками. Именно здесь интерпретатор CPython теряет больше всего времени на разбор байт-кода, проверки типов и прочую бюрократию. Nuitka всю эту бюрократию убирает — отсюда и впечатляющие +335% (или 3.35-кратное ускорение). По сути, машина едет по идеальной трассе без единого препятствия. Но реальный проект — это не трасса, а городской трафик. Там есть другие машины, светофоры, пешеходы. Ускорение от Nuitka зависит от того, на чём именно ваш код тратит время. И вот тут начинаются нюансы.
Доложу честно: Не Gemini, но ИИ выступал в роли чернорабочего на подхвате — помог причесать черновик, пока я воевал с таблицами в Markdown и вспоминал, на каком же всё-таки фреймворке споткнулся в прошлый вторник. Но изучение инструментом, сарказм и отсылки к холодному кофе — ручной работы, выращенные на бессонных дедлайнах и личных шишках.
Новые обзоры обязательно будут — AI-зоопарк в 2026 году плодится быстрее, чем кролики весной. Как только накопаю что-нибудь стоящее (или эпично провальное — такой контент мы тоже любим), сразу пойду писать.
А если есть конкретный инструмент — кидайте названия. Обещать не обещаю, но здоровая инженерная любознательность обычно берет вверх.
Пока мы воспринимаем агентов как «коллег в Slack», мы обречены наблюдать бесконечный созвон. Как только переключаем тумблер в голове на «микросервисы с чёткими контрактами», магия заканчивается и начинается нормальная инженерия. Ну и да, после этого опыта я стал ценить продактов, которые рисуют BPMN-схемы — оказывается, они всё это время были правы, просто мы не умели их слушать :)
Да, TIOBE — это такой себе барометр: если смотреть на него каждый день, можно решить, что главный язык человечества — это Scratch, а COBOL скоро обгонит JavaScript.
Но есть нюанс. Методология TIOBE построена на подсчёте поисковых запросов вида +"<language> programming". Scratch генерит тонны трафика от школьников и учителей, которые гуглят «как сделать игру про котика». Это завышает его позицию и обесценивает рейтинг как инструмент для выбора промышленного стека.
К сожалению, других публичных, глобальных и столь же медийных метрик популярности языков просто нет. PYPL (GitHub pulls) или RedMonk (Stack Overflow + GitHub) для Фортрана показывают ещё более грустную картину (потому что научные репозитории с 40-летним кодом лежат не на GitHub, а на закрытых серверах Министерства энергетики США).
Но если хочется более честной метрики «экспертности», давайте посмотрим на:
Топ-500 суперкомпьютеров. По данным последних отчетов, Fortran используется в научных нагрузках более чем на 20% систем из списка (особенно в верхушке, где экзафлопсные машины вроде Frontier). Scratch, при всём уважении, там ноль.
Бюджеты NSF и DOE. Если взять грантовые заявки по вычислительной физике, климату и астрономии, там требование «Experience with Fortran 90+ and MPI» стоит почти в каждой второй.
Задача может быть из тех, где наличие единственного владельца не есть свойство предметной области.
В точку. Именно поэтому в научных кодах до сих пор царят глобальные массивы в общих блоках или модулях. Модель владения Rust там смотрится как слон в посудной лавке. А что такое «критически важная безопасность памяти»? В HPC это часто означает: «чтобы уборщица не споткнулась о провод и не вырубила ноду кластера», а не «чтобы хакер не прочитал куки». Тут да, вы правы, для числодробилок главное — детерминизм и отсутствие алиасинга, а не защита от переполнения буфера (хотя и она не лишняя).
Я сам бы непременно начал с границ реальной области применимости... И это было бы, как видно по статье, ошибкой. У Fortran есть сильно вырвавшаяся вперёд козырная область...
Да, структура статьи — это сознательная попытка пройти по грани между «хайпом возрождения» и «технической правдой». Если бы я начал с главы «Кому не нужен Fortran», статью бы просто не открыли, потому что 90% Хабра сразу прошли мимо. Моя задача была зацепить «шок-контентом» из заголовка, а уже в середине и особенно в таблице сравнения и заключении расставить точки над i. Соглашусь, что акцент стоило сместить ещё сильнее на «козырную область», возможно, в ущерб перечислению фишек. Учту в следующей статье, если буду писать про COBOL (шутка).
Про Fortran могу добавить результат моего наивного теста... apt search <subj> в Termux. Fortran прошёл.
Гениально). Если пакет есть в Termux на Android, то язык официально жив.
Это не больно, это в худшем случае препятствует постижению через копипасту... У Rust есть фундаментальная проблема — кто способен хорошо понять Rust, тот и первый кандидат на измену с С++
Согласен на 100%, формулировка про «боль» — это действительно упрощение. Но давайте поместим её в контекст аудитории. Это не системные программисты, пишущие ядро ОС. Это расчётчик-гидродинамик, который видит уравнение Навье-Стокса и хочет превратить его в код с минимальным когнитивным зазором. Для него борьба с Borrow Checker при реализации простого метода конечных разностей — это действительно лишнее трение. Ему не нужна измена ни с Rust, ни с C++. Ему нужно, чтобы A = B + C работало быстро и без сюрпризов с памятью. Поэтому в тексте я и оставил эту легкую провокацию — не чтобы принизить Rust, а чтобы подсветить разницу в пороге входа для конкретной профессии.
Ещё раз спасибо за комментарий. Ради такого стоит писать на Хабр, а не в закрытый чаты.
С точки зрения исполнителя это сказка. Три года ты пишешь новый код, тебя носят на руках за то, что ты «спас компанию от легаси». Но как только этот код встаёт в прод, и из-за ошибки округления в новой реализации (потому что Rust гарантирует безопасность памяти, но не гарантирует математическую корректность) у тебя падает модель прогноза погоды или лопается виртуальная турбина — всё, прощай 5кк. Виновным назначат именно того, кто сказал «давайте всё перепишем».
150к ковырять Fortran на поддержке
Сходить на сайты вакансий. Ключевое слово не просто Fortran, а Fortran HPC или Computational Scientist. Да, в региональном НИИ, который перебивается грантами, много не заплатят. Но если мы говорим о поддержке легаси в крупных конторах, там зарплаты совсем другого порядка. Просто эти вакансии не висят на HeadHunter с пометкой «удалёнка из Урюпинска». CUDA Fortran развивает целая NVIDIA.
Так что да, директора аэрокосмических агентств на Хабре, возможно, и не сидят. А вот их тимлиды и ведущие инженеры-расчетчики — очень даже заглядывают. И им, поверьте, плевать, на чём написан решатель, лишь бы он считал быстро и правильно. А Rust, при всём уважении, пока не даёт той предсказуемости IEEE-совместимой математики на векторизованных тензорах, которую даёт Fortran.
Да, я не скрываю, что использовал LLM для помощи с формулировками и черновиками. разжёвывание очевидных вещей и красивые обороты помогал накидывать ИИ. Итоговый текст вычитывал вручную, но «стиль нейронки» местами всё равно пробивается.
Статья задумывалась как вводный туториал для разработчиков, которые вообще не работали с MCP. Если читатель уже собрал десяток агентов и сам пишет SKILL.md, статья ему вряд ли откроет что-то новое. Но для того, кто только смотрит в сторону MCP и хочет понять «как это вообще склеивается в коде», такой уровень детализации в полне себе оправдан.
спасибо за развёрнутую критику. Если будет желание обсудить что-то из затронутого подробнее - я открыт к диалогу.
для одной задачи в пет-проекте CLI действительно проще. Но когда таких интеграций становится хотя бы десяток и они начинают жить в разных проекта?
MCP - это единый стандарт для подключения любых инструментов. Без него каждый скилл или функция превращается в уникальную интеграцию:
Где-то агент вызывает subprocess.run(['gh', 'issue', 'create']) и парсит stdout.
Где-то - дергает REST API.
Где-то - подключается к базе данных через SQL.
Когда таких инструментов 30, а моделей/агентов — 3, выходит30 × 3 = 90 уникальных связок, каждую из которых нужно писать, тестировать и поддерживать. MCP превращает это в 30 + 3 = 33 связки: каждый инструмент описывается один раз, и любой агент может его использовать по стандартной схеме.
подходы MCP и CLI не исключают друг друга. Для локальной разработки и быстрых итераций CLI бывает эффективнее (меньше накладных расходов). А для корпоративных систем, где на первый план выходят безопасность, аудит и переиспользование, MCP - это безальтернативный вариант.
В решении используется поле reasoning из словаря dict. Однако вы сами цитируете комментарий разработчиков о том, что разные провайдеры называют это поле по-разному (reasoningcontent, reasoning, reasoning_details). Гарантирует ли предложенный патч работоспособность с vLLM (который перешел на reasoning) или с xAI, или же код жестко завязан на специфику stepfun/step-3.5-flash и polza.ai?
Про «молодость протокола» и прод. Я специально вынес это в минусы - чтобы сразу подсветить риски. Статья не инструкция «внедрять завтра в продакшен», а туториал для знакомства с подходом. Идея MCP (стандартный интерфейс агента с инструментами) выглядит перспективной, но самому протоколу ещё взрослеть и взрослеть.
Про LangChain.
В статье намеренно использовал langchain-mcp-adapters (официальную библиотеку) и LangGraph вместо старого AgentExecutor. Сейчас это «рекомендованный путь», и ломают его не так часто, как ранние версии LangChain. Ну и фиксация версий в requirements.txt.
«Видно, что AI писал».
Есть такое. Статья - результат совместной работы: структуру и логику выстраивал я, код тестировал руками, а черновики текста помогал готовить AI. Считаю такой подход рабочим: LLM берёт на себя рутину с формулировками и docstring'ами, а живой разработчик отвечает за то, чтобы всё было корректно и не галлюцинировало. В 2026-м я считаю это нормальным.
Python 3.11+.
Я написал «3.11+» по инерции, потому что многие консервативные проекты до сих пор сидят на 3.11 из-за старых зависимостей. Но для нового кода рекомендовать нужно минимум 3.12.
Если после прочтения ты такой «ну его в пень, пусть полежит годик» - значит, я свою задачу выполнил: предупредил о рисках. А когда протокол устаканится (а судя по тому, как Anthropic и другие его форсят, это вопрос времени), у тебя уже будет готовая ментальная модель.
Абсолютно согласен. В статье я сознательно сделал акцент на бесплатном тарифе, потому что целевая аудитория туториала — разработчики, которые только начинают щупать Gemini API, пишут pet-проекты или внутренние утилиты для команды. Для них 5 RPM — уже проблема, о которой они узнают постфактум. Платный тариф, конечно, снимает большинство ограничений, но и там есть потолок, и rate limiter на стороне бота не помешает (хотя бы для защиты от случайных флудов). В корпоративной среде, как верно замечено, экономия на токенах через кэш и очереди — это не про халяву, а про архитектурную гигиену и снижение счетов на круглых цифрах.
2. Function Calling vs Команды
И снова правда. Команды (/schedule, /book) — более надёжный и детерминированный способ. Function Calling я включил как демонстрацию возможностей API и как мостик к более сложным агентным сценариям, где пользователь формулирует запрос свободным текстом. В реальном проекте я бы делал гибрид:
Команды для критичных действий с чёткими параметрами.
Function Calling как fallback для «поговорить с ботом как с секретарём» с обязательной валидацией аргументов и подтверждением от пользователя перед вызовом реального сервиса. Так и «от дурака» защита, и UX приятнее.
3. Rate Limiter и ошибка 429
Тут позволю себе уточнить, потому что мы, кажется, немного о разном.
"Решение проблемы - это использование другой модели при ошибках типа 'нет доступа'"
Переключение на другую модель — это стратегия fallback, а не rate limiting. Rate limiter на стороне бота нужен, чтобы не доводить до 429 вообще. Он ограничивает поток запросов к API, соблюдая заявленный RPM (например, не чаще 10 запросов в секунду для платной Gemini 3 Flash). Если лимит всё же превысили (скажем, из-за пиковой нагрузки или сбоя самого Google), то fallback-стратегия — следующий эшелон: другая модель, кэшированный ответ, или "извините, повторите позже".
В статье я описал именно rate limiter для профилактики 429. Fallback-стратегии заслуживают отдельной статьи, и в комментарии отлично подсвечено, что о них нельзя забывать.
4. Таймауты Telegram и Streaming
Здесь самый сочный момент. Попробую разложить по полочкам.
"Получили ВЕСЬ ответ от нейросети, сохранили, переслали сохранённое"
Да, это идеальный сценарий. Именно так и надо делать в production: сначала дождаться полного ответа от LLM, потом обработать (разрезать, экранировать Markdown/HTML), потом отправлять.
Проблема, которую я решал стримингом — не техническая, а UX-психологическая. Пользователь жмёт кнопку «Отправить» и ждёт. Если ответ генерируется 15 секунд, а бот молчит, пользователь:
Начинает долбить кнопку повторно (создавая каскад запросов).
Думает, что бот сломался, и уходит.
Streaming + промежуточное редактирование сообщения (метод edit_message_text) — это способ сказать пользователю: «Я работаю, видишь? Буквы бегут». Это не решение таймаута, а маскировка задержки под активную работу.
Что касается обхода блокировок и нестабильного соединения — вы абсолютно правы: в таких условиях стриминг может стать источником проблем. Поэтому я всегда комбинирую:
Стриминг для визуального фидбека.
Параллельное накопление полного ответа в памяти.
По завершении генерации — финальное редактирование сообщения целиком (или отправка частями, если длинное).
Если стрим оборвался — у меня есть полный ответ, и я могу отправить его обычным методом. Aiogram, кстати, предоставляет удобные декораторы для обработки ошибок редактирования (например, если сообщение было удалено), но основная логика резервирования ложится на плечи разработчика.
"длинные сообщения не зажимайте лимитами, а режьте на куски с валидацией"
Здесь +100500. В коде статьи я как раз привёл примитивный пример разрезания строки на куски по 4000 символов. Для MarkdownV2 это, конечно, недостаточно — нужно умное разрезание с учётом открытых/закрытых тегов, иначе сообщение не отправится.
Если кратко:
По тарифам — согласен, статья скорее для тех, кто только начинает. В проде — только платные модели и нормальный мониторинг.
По Function Calling — да, команды надёжнее. В гибридном подходе им самое место.
По rate limiter'у — вы правы, он именно профилактический. Fallback на другие модели — следующий уровень защиты, о котором стоило упомянуть.
По стримингу и таймаутам — тут мы говорим про одно и то же, но с разных углов. Я про UX-иллюзию, вы про надёжность инфраструктуры. Истина как всегда в комбинации: стримим для души, а сохраняем и режем — для гарантии доставки.
Про очереди — святая правда. Без них любое сетевое взаимодействие в асинхронном боте превращается в гонки.
В первой таблице скорость не в мбит/с, а в кбит/с. Если бы у E1 была скорость 2048 мбит/с, то и коммутация пакетов, наверное, не была бы нужна нам.
Полностью согласен, это было сказано)
Спасибо за поправку!
Доложу честно: Не Gemini, но ИИ выступал в роли чернорабочего на подхвате — помог причесать черновик, пока я воевал с таблицами в Markdown и вспоминал, на каком же всё-таки фреймворке споткнулся в прошлый вторник. Но изучение инструментом, сарказм и отсылки к холодному кофе — ручной работы, выращенные на бессонных дедлайнах и личных шишках.
Новые обзоры обязательно будут — AI-зоопарк в 2026 году плодится быстрее, чем кролики весной. Как только накопаю что-нибудь стоящее (или эпично провальное — такой контент мы тоже любим), сразу пойду писать.
А если есть конкретный инструмент — кидайте названия. Обещать не обещаю, но здоровая инженерная любознательность обычно берет вверх.
Пока мы воспринимаем агентов как «коллег в Slack», мы обречены наблюдать бесконечный созвон. Как только переключаем тумблер в голове на «микросервисы с чёткими контрактами», магия заканчивается и начинается нормальная инженерия. Ну и да, после этого опыта я стал ценить продактов, которые рисуют BPMN-схемы — оказывается, они всё это время были правы, просто мы не умели их слушать :)
Да, TIOBE — это такой себе барометр: если смотреть на него каждый день, можно решить, что главный язык человечества — это Scratch, а COBOL скоро обгонит JavaScript.
Но есть нюанс. Методология TIOBE построена на подсчёте поисковых запросов вида
+"<language> programming". Scratch генерит тонны трафика от школьников и учителей, которые гуглят «как сделать игру про котика». Это завышает его позицию и обесценивает рейтинг как инструмент для выбора промышленного стека.К сожалению, других публичных, глобальных и столь же медийных метрик популярности языков просто нет. PYPL (GitHub pulls) или RedMonk (Stack Overflow + GitHub) для Фортрана показывают ещё более грустную картину (потому что научные репозитории с 40-летним кодом лежат не на GitHub, а на закрытых серверах Министерства энергетики США).
Но если хочется более честной метрики «экспертности», давайте посмотрим на:
Топ-500 суперкомпьютеров. По данным последних отчетов, Fortran используется в научных нагрузках более чем на 20% систем из списка (особенно в верхушке, где экзафлопсные машины вроде Frontier). Scratch, при всём уважении, там ноль.
Бюджеты NSF и DOE. Если взять грантовые заявки по вычислительной физике, климату и астрономии, там требование «Experience with Fortran 90+ and MPI» стоит почти в каждой второй.
Спасибо за подробный комментарий.
В точку. Именно поэтому в научных кодах до сих пор царят глобальные массивы в общих блоках или модулях. Модель владения Rust там смотрится как слон в посудной лавке. А что такое «критически важная безопасность памяти»? В HPC это часто означает: «чтобы уборщица не споткнулась о провод и не вырубила ноду кластера», а не «чтобы хакер не прочитал куки». Тут да, вы правы, для числодробилок главное — детерминизм и отсутствие алиасинга, а не защита от переполнения буфера (хотя и она не лишняя).
Да, структура статьи — это сознательная попытка пройти по грани между «хайпом возрождения» и «технической правдой». Если бы я начал с главы «Кому не нужен Fortran», статью бы просто не открыли, потому что 90% Хабра сразу прошли мимо. Моя задача была зацепить «шок-контентом» из заголовка, а уже в середине и особенно в таблице сравнения и заключении расставить точки над i. Соглашусь, что акцент стоило сместить ещё сильнее на «козырную область», возможно, в ущерб перечислению фишек. Учту в следующей статье, если буду писать про COBOL (шутка).
Гениально). Если пакет есть в Termux на Android, то язык официально жив.
Согласен на 100%, формулировка про «боль» — это действительно упрощение. Но давайте поместим её в контекст аудитории. Это не системные программисты, пишущие ядро ОС. Это расчётчик-гидродинамик, который видит уравнение Навье-Стокса и хочет превратить его в код с минимальным когнитивным зазором. Для него борьба с Borrow Checker при реализации простого метода конечных разностей — это действительно лишнее трение. Ему не нужна измена ни с Rust, ни с C++. Ему нужно, чтобы
A = B + Cработало быстро и без сюрпризов с памятью. Поэтому в тексте я и оставил эту легкую провокацию — не чтобы принизить Rust, а чтобы подсветить разницу в пороге входа для конкретной профессии.Ещё раз спасибо за комментарий. Ради такого стоит писать на Хабр, а не в закрытый чаты.
С точки зрения исполнителя это сказка. Три года ты пишешь новый код, тебя носят на руках за то, что ты «спас компанию от легаси». Но как только этот код встаёт в прод, и из-за ошибки округления в новой реализации (потому что Rust гарантирует безопасность памяти, но не гарантирует математическую корректность) у тебя падает модель прогноза погоды или лопается виртуальная турбина — всё, прощай 5кк. Виновным назначат именно того, кто сказал «давайте всё перепишем».
Сходить на сайты вакансий. Ключевое слово не просто Fortran, а Fortran HPC или Computational Scientist. Да, в региональном НИИ, который перебивается грантами, много не заплатят. Но если мы говорим о поддержке легаси в крупных конторах, там зарплаты совсем другого порядка. Просто эти вакансии не висят на HeadHunter с пометкой «удалёнка из Урюпинска». CUDA Fortran развивает целая NVIDIA.
Так что да, директора аэрокосмических агентств на Хабре, возможно, и не сидят. А вот их тимлиды и ведущие инженеры-расчетчики — очень даже заглядывают. И им, поверьте, плевать, на чём написан решатель, лишь бы он считал быстро и правильно. А Rust, при всём уважении, пока не даёт той предсказуемости IEEE-совместимой математики на векторизованных тензорах, которую даёт Fortran.
Да, я не скрываю, что использовал LLM для помощи с формулировками и черновиками. разжёвывание очевидных вещей и красивые обороты помогал накидывать ИИ. Итоговый текст вычитывал вручную, но «стиль нейронки» местами всё равно пробивается.
Статья задумывалась как вводный туториал для разработчиков, которые вообще не работали с MCP. Если читатель уже собрал десяток агентов и сам пишет SKILL.md, статья ему вряд ли откроет что-то новое. Но для того, кто только смотрит в сторону MCP и хочет понять «как это вообще склеивается в коде», такой уровень детализации в полне себе оправдан.
спасибо за развёрнутую критику. Если будет желание обсудить что-то из затронутого подробнее - я открыт к диалогу.
для одной задачи в пет-проекте CLI действительно проще. Но когда таких интеграций становится хотя бы десяток и они начинают жить в разных проекта?
MCP - это единый стандарт для подключения любых инструментов. Без него каждый скилл или функция превращается в уникальную интеграцию:
Где-то агент вызывает
subprocess.run(['gh', 'issue', 'create'])и парсит stdout.Где-то - дергает REST API.
Где-то - подключается к базе данных через SQL.
Когда таких инструментов 30, а моделей/агентов — 3, выходит
30 × 3 = 90уникальных связок, каждую из которых нужно писать, тестировать и поддерживать. MCP превращает это в30 + 3 = 33связки: каждый инструмент описывается один раз, и любой агент может его использовать по стандартной схеме.подходы MCP и CLI не исключают друг друга. Для локальной разработки и быстрых итераций CLI бывает эффективнее (меньше накладных расходов). А для корпоративных систем, где на первый план выходят безопасность, аудит и переиспользование, MCP - это безальтернативный вариант.
В решении используется поле
reasoningиз словаряdict. Однако вы сами цитируете комментарий разработчиков о том, что разные провайдеры называют это поле по-разному (reasoningcontent,reasoning,reasoning_details). Гарантирует ли предложенный патч работоспособность сvLLM(который перешел наreasoning) или сxAI, или же код жестко завязан на спецификуstepfun/step-3.5-flashиpolza.ai?Про «молодость протокола» и прод. Я специально вынес это в минусы - чтобы сразу подсветить риски. Статья не инструкция «внедрять завтра в продакшен», а туториал для знакомства с подходом. Идея MCP (стандартный интерфейс агента с инструментами) выглядит перспективной, но самому протоколу ещё взрослеть и взрослеть.
Про LangChain.
В статье намеренно использовал
langchain-mcp-adapters(официальную библиотеку) и LangGraph вместо старогоAgentExecutor. Сейчас это «рекомендованный путь», и ломают его не так часто, как ранние версии LangChain. Ну и фиксация версий вrequirements.txt.Есть такое. Статья - результат совместной работы: структуру и логику выстраивал я, код тестировал руками, а черновики текста помогал готовить AI. Считаю такой подход рабочим: LLM берёт на себя рутину с формулировками и docstring'ами, а живой разработчик отвечает за то, чтобы всё было корректно и не галлюцинировало. В 2026-м я считаю это нормальным.
Python 3.11+.
Я написал «3.11+» по инерции, потому что многие консервативные проекты до сих пор сидят на 3.11 из-за старых зависимостей. Но для нового кода рекомендовать нужно минимум 3.12.
Если после прочтения ты такой «ну его в пень, пусть полежит годик» - значит, я свою задачу выполнил: предупредил о рисках. А когда протокол устаканится (а судя по тому, как Anthropic и другие его форсят, это вопрос времени), у тебя уже будет готовая ментальная модель.
1. Про бесплатные тарифы и коммерцию
Абсолютно согласен. В статье я сознательно сделал акцент на бесплатном тарифе, потому что целевая аудитория туториала — разработчики, которые только начинают щупать Gemini API, пишут pet-проекты или внутренние утилиты для команды. Для них 5 RPM — уже проблема, о которой они узнают постфактум. Платный тариф, конечно, снимает большинство ограничений, но и там есть потолок, и rate limiter на стороне бота не помешает (хотя бы для защиты от случайных флудов). В корпоративной среде, как верно замечено, экономия на токенах через кэш и очереди — это не про халяву, а про архитектурную гигиену и снижение счетов на круглых цифрах.
2. Function Calling vs Команды
И снова правда. Команды (
/schedule,/book) — более надёжный и детерминированный способ. Function Calling я включил как демонстрацию возможностей API и как мостик к более сложным агентным сценариям, где пользователь формулирует запрос свободным текстом. В реальном проекте я бы делал гибрид:Команды для критичных действий с чёткими параметрами.
Function Calling как fallback для «поговорить с ботом как с секретарём» с обязательной валидацией аргументов и подтверждением от пользователя перед вызовом реального сервиса.
Так и «от дурака» защита, и UX приятнее.
3. Rate Limiter и ошибка 429
Тут позволю себе уточнить, потому что мы, кажется, немного о разном.
Переключение на другую модель — это стратегия fallback, а не rate limiting. Rate limiter на стороне бота нужен, чтобы не доводить до 429 вообще. Он ограничивает поток запросов к API, соблюдая заявленный RPM (например, не чаще 10 запросов в секунду для платной Gemini 3 Flash). Если лимит всё же превысили (скажем, из-за пиковой нагрузки или сбоя самого Google), то fallback-стратегия — следующий эшелон: другая модель, кэшированный ответ, или "извините, повторите позже".
В статье я описал именно rate limiter для профилактики 429. Fallback-стратегии заслуживают отдельной статьи, и в комментарии отлично подсвечено, что о них нельзя забывать.
4. Таймауты Telegram и Streaming
Здесь самый сочный момент. Попробую разложить по полочкам.
Да, это идеальный сценарий. Именно так и надо делать в production: сначала дождаться полного ответа от LLM, потом обработать (разрезать, экранировать Markdown/HTML), потом отправлять.
Проблема, которую я решал стримингом — не техническая, а UX-психологическая. Пользователь жмёт кнопку «Отправить» и ждёт. Если ответ генерируется 15 секунд, а бот молчит, пользователь:
Начинает долбить кнопку повторно (создавая каскад запросов).
Думает, что бот сломался, и уходит.
Streaming + промежуточное редактирование сообщения (метод
edit_message_text) — это способ сказать пользователю: «Я работаю, видишь? Буквы бегут». Это не решение таймаута, а маскировка задержки под активную работу.Что касается обхода блокировок и нестабильного соединения — вы абсолютно правы: в таких условиях стриминг может стать источником проблем. Поэтому я всегда комбинирую:
Стриминг для визуального фидбека.
Параллельное накопление полного ответа в памяти.
По завершении генерации — финальное редактирование сообщения целиком (или отправка частями, если длинное).
Если стрим оборвался — у меня есть полный ответ, и я могу отправить его обычным методом. Aiogram, кстати, предоставляет удобные декораторы для обработки ошибок редактирования (например, если сообщение было удалено), но основная логика резервирования ложится на плечи разработчика.
Здесь +100500. В коде статьи я как раз привёл примитивный пример разрезания строки на куски по 4000 символов. Для MarkdownV2 это, конечно, недостаточно — нужно умное разрезание с учётом открытых/закрытых тегов, иначе сообщение не отправится.
Если кратко:
По тарифам — согласен, статья скорее для тех, кто только начинает. В проде — только платные модели и нормальный мониторинг.
По Function Calling — да, команды надёжнее. В гибридном подходе им самое место.
По rate limiter'у — вы правы, он именно профилактический. Fallback на другие модели — следующий уровень защиты, о котором стоило упомянуть.
По стримингу и таймаутам — тут мы говорим про одно и то же, но с разных углов. Я про UX-иллюзию, вы про надёжность инфраструктуры. Истина как всегда в комбинации: стримим для души, а сохраняем и режем — для гарантии доставки.
Про очереди — святая правда. Без них любое сетевое взаимодействие в асинхронном боте превращается в гонки.
Cпасибо, утащил несколько идей для доработки.