AI и грабли

MCP → CLI Я только собирался написать, почему CLI сосут, и на что их заменять, как понял, что у меня даже нет поста, почему сосут MCP (от которых мы и ушли к CLI). Исправляю! Сначала напомню в двух словах зачем эти ребята нам вообще нужны: агент сам по себе мало что умеет в мире, где наши данные разбросаны по десяткам веб-приложений, начиная от почты и календаря, заканчивая транскрибаторами звонков, джирами и сервисами электронного документооборота Нужно его к ним как-то коннектить. И на заре агентных систем ребята придумали подсовывать ему новые инструменты как tools (то, что агент может вызывать в цикле перед тем как дать итоговый ответ). Назвали это MCP (model-context-protocol) У стандарта MCP было много исторических болячек: невнятная аутентификация, загромождение контекста всеми методами всех mcp'шек, , отсутствие строгого следования схеме, stateful логика 🥴 Сейчас они по большей части вылечены. Но есть одна главная проблема – это все еще лишний слой абстракции поверх обычного API. То есть, вместо того, чтобы сразу дернуть API нашего условного гитхаба, обвязка агента (она выполняет роль MCP клиента) отправляет это в какой-то MCP сервер (в случае с гитхаб он удаленный, но может быть и локальным), а он уже отправляет это в API Вместо этого, любой агент, у которого есть вызов терминала может либо просто написать скрипт, который будет обращаться к API напрямую, либо вызвать уже сто лет существующую cli-команду gh с нужными параметрами. Всё! И вот какие у этого плюсы: 1. Жрет меньше токенов (потому что не verbose json) 2. Можно стакать вызовы команд в любой последовательности 3. Не обязательно засирать контекст модели всем выводом. Перенаправляем и фильтруем вывод терминальной команды как душе угодно 4. Обычно сильно больше комбинаций параметров 5. Если какой-то функции или параметра нет, агент все так же может написать кастомный скрипт, который сходит в API и сделает то, что нужно Но надо признать, кое-где MCP все-таки нужны – когда у вас есть эфимерн

CLI → SDK Выше я писал про то, почему с MCP переходят на CLI (кроме некоторых ситуаций). Сегодня – про еще один переход, которы у меня случился пару недель назад Рассмотрим на примере коннектора к тг У меня самописный CLI тул, куда я понемногу добавляю разные функции. Сначала я его использовал просто для того, чтобы агент отправлял текстовые нотификашки ботиком в чат. Потом добавил туда поддержку медиа. Потом отправку в другие чаты. Потом – чтение предыдущих сообщений в любом чате и парсинг каналов (тут понадобилось перенести с урезанного Bot API на полноценный телеграмный MTProto) И каждый раз когда я прошу сделать что-то, чего в моем CLI нет – агент идет его переписывать. Как результат – я по сути воссоздаю весь интерфейс библиотеки mtcute, но в виде CLI команды. Что уже как бы попахивает лишним слоем Так еще и интерфейс текстовой команды сильно беднее чем интерфейс SDK – нет честной типизации, объектов и т.д. Если я хочу сделать какое-то действие в цикле, или хитро обработать вывод, то агент все равно пишет bash-скрипт поверх CLI Так что пару недель назад, я полностью выпиливаю CLI и просто прописываю агенту, как ему использовать SDK напрямую. То есть он пишет код под задачу и сразу его запускает. А если у меня есть какие-то повторяющиеся задачи – я оставляю их в виде импортируемых TS модулей. Теперь агент может делать что угодно, что можно делать ботом в тг. Мне не нужно заранее продумывать сценарии и постоянно обновлять код. Он сам соберет его точно под задачу из исходных модулей библиотеки, либо моих скриптов. Тут правда я натыкаюсь на пару проблем. Основная – это то, что агент постоянно пишет временные скрипты, что убивает всю легкость, которая была у запуска CLI команды раньше. Да, он может писать код inline прям в команде, но внешние библиотеки так не установятся Решается это достаточно просто – нужен раннер с поддержкой autoinstall Для TS – это bun/deno, а для python – uv Тогда команда агента выглядит примерно так: bun --install=force run - <<

Много скептицизма прилетело в комменты и даже мне в лс по посту про агентов, которые пишут код ad-hoc вместо использования готовых CLI На самом деле очень рад – это значит, что подписчики вдумчиво читают посты и готовы делиться своим мнением. Ну и я так получаю перспективу, которую сам раньше не замечал, спасибо А теперь еще один аргументом в сторону моей позиции, который вам может понравиться: Понятно, что доверять какому-то экспериментальному подходу от Коли сложнее, чем официальному подходу от топовых ИИ-лаб. Так что просто посмотрите на встроенные скиллы того же кодекса. Подход, про который я пишу уже используется в большинстве из них: Browser/Chrome – inline JS через Node REPL и browser-client Computer Use – inline JS с @oai/sky presentations, spreadsheets — генерируют .mjs с @oai/artifact-tool documents – код через python-docx (но: есть готовые CLI-хелперы) pdf – Python с reportlab/pypdf/pdfplumber Понятно, что не нужно все переводить на этот подход Но вот скинуть агенту мой прошлый пост и спросить, какие из ваших скиллов могут выиграть от этого подхода так же как выигрывают скиллы кодекса из этого поста – может оказаться полезным упражнением

Если вы давно в этом канале, то знаете, что я люблю делать диванные прогнозы на будущее. Один из новых прогнозов: Скоро у openai появится агентная модель уровня sol+ с нативным audio инпутом как у gemini (ставлю на до конца года) Что это будет значить для нас: Для всех, кто работает с генераторами музыки, диалоговыми аудио ботами, монтажем подкастов и т.д. – это огромное подспорье. Как нативное понимание image когда-то позволило сильно прокачать возможности агентов во фронтенде, дизайне и любом другом визуале – если агент "видит" результат работы, он сразу может найти косяки и исправить их. Тот самый feedback loop, где feedback – это сам результат работы Так же будет и с аудио. Сейчас я работаю с локальными генераторами аудио и voice cloning, и этого прям жестко не хватает. Поэтому приходится использовать самодельную версию агента с модельками gemini по API. Из альтернатив есть Antigravity – они добавили это к себе буквально через пару недель после моего эксперимента, причем сразу и с поддержкой видео (это, кстати, единственная причина использовать Antigravity, которую я знаю) Если кому интересно, на чем основывается предсказание про появление омни модельки от openai: Примерно месяц назад я расковырял новый коммит в codex-cli, который добавляет audio как валидный тип результата для tool_calls (наравне с text и image). Так же они добавляют это в поддержку MCP. И даже в dynamic_tools (это тулы, которые можно инжектить в codex извне. Например, codex desktop, который под капотом запускает codex, инжектит туда тулы для управления встроенным браузером и соседними чатами. Короче, раз поддержка добавлена в харнес, то и модели должны быть на подходе Ваш диванный предсказатель, @ai_grably