Результаты ожидаемые, но, тем не менее, разочаровывающие. Надо что-то придумать. Видимо, нужно поднимать CDN в России.

Заботливое начальство в лице РКН — спонсор того, что я стал лучше разбираться в различных аббревиатурах. Настроил родным аббревиатуры. Себе тоже настроил аббревиатуры — ведь половина сайтов в России так же не открывается из-за рубежа.

Сейчас вот ещё разберусь с CDN.

Следите за выводом консоли при использовании AI-агентов

Я не видел, чтобы кто-то писал об этом, но мне кажется, что это важно, если AI-агенты вызывают CLI утилиты за вас.

Обычно CLI утилиты выводят информацию в консоль. Например, вы внесли изменения в проект с помощью агента, и теперь просите агента выполнить команды вроде npm build или dotnet test.

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

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

- ANSI escape-символы, которые задают цвета в консоли или Unicode-символы, делающие вывод консоли красивым. Всё это раздувает контекст без добавления какой-либо пользы. Агентам всё равно на цвет текста, прогресс-бары или результаты в виде ASCII-таблиц.

Почему это плохо для LLM?

Производительность LLM не равномерна при длинных контекстах. Есть такое явление под названием "lost-in-the-middle". Его суть в том, что производительность LLM ухудшается, когда релевантная информация размещена в середине контекста. Иногда такой эффект ещё называют "гниением контекста" (context rot). Есть несколько статей на эту тему, например "Lost in the Middle: How Language Models Use Long Contexts".

Для агентов это явление часто приводит к следующим проблемам:

- Агент тратит время на "размышления" о предупреждениях и что с ними делать, вместо решения задачи.

- Длинный вывод консоли может вытеснить важную информацию из контекста, или информация может быть суммирована (summarization) таким образом, что часть важных деталей потеряется.

- Суммирование также может занять несколько минут в зависимости от модели, что дополнительно замедляет работу агента.

Решение

Если вы видите предупреждения компилятора или линтера, в идеале вам нужно их исправить. Однако это может занять приличное количество времени, особенно если вы работаете с каким-то легаси проектом.

Другой вариант -- отключить их. Например, в dotnet можно использовать флаг --verbosity quiet В целом, я бы не рекомендовал это делать, но иногда можно, если нужно срочно выполнить задачу.

Если вы разрабатываете CLI утилиту, подумайте над созданием флага, который настраивает вывод специально для агентов. К примеру, разработчики Microsoft Dev Proxy недавно обсуждали добавление флага --log-for human|machine для более эффективного вывода для LLM.

Заключение

Если вы работаете с AI-агентами, то вывод в консоль перестаёт быть просто логами. Это уже часть промпта. Предупреждения, прогресс-бары и вывод результатов в виде таблиц, ANSI escape-символы занимают контекст LLM. Вывод CLI должен быть минимальным и структурированным, тогда результаты при работе с AI будут более надёжными.

Читать то же самое на сайте, но с картинками (нужен VPN).

P.S. Следующий пост будет не про ИИ, обещаю.

Коллеги, чем будем пользоваться в скором времени? Продолжаем использовать Telegram, но с использованием специальных технических средств связи?

Или на примете есть что-то ещё? Вообще, я довольно продолжительное время сижу на Reddit, но формат там, конечно, совершенно другой.

Только Макс не предлагайте 😬

Поднимаем свой MTProxy

Заботливое начальство вынуждает прокачивать технические скиллы. Разберёмся, как поднять MTProxy для Telegram на VPS. Нам понадобится:

1. VPS.

Покупайте самый дешёвый сервер. Сильное железо не требуется, главное чтобы не было ограничений по трафику. Характеристики моего сервера: 1 vCPU, 1 GB RAM, 15 GB SSD.

У меня сервер иностранный. На Хабре некоторые пишут, что сервер в России, возможно, будет лучше работать, так как трафик внутри страны не проверяется. Так это или нет – не знаю.

2. Docker Engine.

Прокси будет запускаться в Docker, поэтому просто установите его, используя официальную документацию для вашей операционной системы.

3. Домен.

Домен нужен для Fake TLS. Наш MTProxy будет прикидываться обычным HTTPS-трафиком.

Если у вас есть домен — отлично. Просто добавляете A-запись с IP-адресом вашего сервера.

Если домена нет, то можно зарегистрироваться на FreeDNS и взять домен третьего уровня на любом понравившемся бесплатном домене. Я в своё время пользовался такими доменами для удобства доступа к своим self-hosted приложениям.

Запускаем прокси

Есть несколько Docker-образов для запуска MTProxy. Я использую nineseconds/mtg:2, так как это самый простой способ запустить прокси с Fake TLS. Запускается всё следующим образом:

1. Генерируем секрет (начинается на ee) из вашего домена

docker run --rm \
    nineseconds/mtg:2 \
    generate-secret \ 
    --hex your.domain.com

Результат будет выглядить примерно так:

ee...

2. Кладём секрет в config.toml:

secret = "ee..."
bind-to = "0.0.0.0:443"

3. Создаём Docker Compose файл с содержимым ниже и запускаем прокси командой docker compose up -d

services:
  mtg-proxy:
    image: nineseconds/mtg:2
    container_name: mtg-proxy
    restart: unless-stopped
    ports:
      - "443:443/tcp"
    volumes:
      - ./config.toml:/config.toml:ro

Проверьте логи через docker compose logs. Если логов нет, значит всё хорошо.

Теперь можно сделать ссылку в формате:

tg://proxy?server=<your.domain.com>&port=443&secret=<secret>

И поделиться ею друзьями и родными.

Telegram добавит ваш прокси при нажатии на ссылку.

---

Я хотел сделать гайд максимально простым, поэтому не стал упоминать кое-какие аспекты администрирования серверов: защита SSH, отключение root, файрвол и так далее. Если интересно, могу сделать отдельный пост.

Telega или Telegram?

Ещё до того, как я написал предыдущий пост, я заметил, что в Telegram и во многих каналах начала появляться реклама некой альтернативе Telegram под названием Telega. Я бы прошёл мимо, но есть странность: Telegra агрессивно рекламируется, а разработчики Telega заявляют, что она работает без VPN – даже когда Telegram в России блокируют.

Вообще, сторонние клиенты для Telegram – это нормально. Протокол MTProto позволяет писать альтернативные приложения. Например, уже много лет существуют Nekogram или Forkgram.

Но Telega выделяется тем, что её разработала отечественная компания АО «ТЕЛЕГА». Компания зарегистрирована чуть больше года назад. Её уставной капитал 10 тыс. рублей. Приложение Telega зарегистрировано в реестре отечественного ПО.

У компании также есть Telegram канал, зарегистрированный в реестре Роскомнадзора. Канал этот был создан в апреле прошлого года. До октября там было менее 100 тысяч подписчиков. К началу 2026 года он вырос до 500 тысяч. Сейчас аудитория составляет почти 4 млн подписчиков.

Интересным образом, скачки упоминаний мессенджера Telega и канала совпадают с публикациями в СМИ информации о «масштабных сбоях в Telegram»:

- 20 октября 2025 года;
- 1 января 2026 года;
- 10 февраля 2026 года – настоящее время.

График упоминаний этого мессенджера 👇

Данные собрал через поиск в Telegram. Можете проверить сами. Но для этого нужен Telegram Premium, покупка которого, возможно, скоро станет экстремизмом.

Наверняка это просто грамотная работа маркетологов. Они видели упоминания о блокировке Telegram, поэтому закупали рекламу.

Но как Telega может работать, если Telegram блокируют? У них свои MTProxy? Это не будет считаться обходом блокировок?

В процессе исследования, я наткнулся на статью на Хабре. В ней рассказывалось о связях Telega с VK и наличии функционала для фильтрации контента.

Статья ссылается на Android-разработчика, работавшего в Telegram. Во время последней блокировки Telegram, в своём канале он опубликовал технические подробности про инфраструктуру Telega.

Он рассказал, что у Telegram есть региональные дата центры. Их называют DC: DC1, DC2 и так далее. Например, в Европе используется DC2 и все жители европейской части России используют его.

Есть также MTProxy, о которых я писал в предыдущем посте. Это просто промежуточный сервер, который помогает достучаться до сервера Telegram, если напрямую не получается. Важно, что такой прокси не видит ваши переписки — он просто занимается пересылкой зашифрованного трафика.

Но у Telega на каждый дата центр Telegram есть свой собственный дата центр. Тут важно понять, что это не просто MTProxy, а полноценный дата центр, который притворяется дата центром Telegram.

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

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

Вы спросите что делать? Если важна приватность, то я бы использовал только официальный клиент Telegram.

Последние несколько недель изучаю как добиться от PostgreSQL более высокой производительности в аналитических запросах. В процессе поисков наткнулся на TimescaleDB и выяснил, что это расширение обеспечивает лучшую производительность на 15 – 28% при низкой кардинальности (до ~10 тыс. уникальных ресурсов), но может замедлить запросы на 45 – 165% при высокой кардинальности.

Полная статья тут 👇