Один из самых секси кейсов с нашего марафона по агентам – создание рабочих веб аппок с бэкендом на гугл таблицах и деплоем в одну строку без гитхабов, докеров, vps

Ребятам, которые не хотят заморачиваться с техничкой – очень нравится. Большинство сразу нашли где это использовать в своей работе

Так вот, теперь не нужно использовать внешние сервисы – openai встроили такую штуку к себе в codex

Причем реализация очень крутая – все поверх легковесных Cloudflare Workers и их же R2 storage

P.s. в claude code такого нет, их Artifacts – это тупо static page на их же домене

Разрушать систему

Недавно хайпанула волна постов, мол, раз в несколько месяцев надо полностью сносить все настройки агентов, удалять все скиллы. MCP и т.д. И пересобирать все заново. Типа, старые уже не работают и их нужно перестраивать с нуля на новых моделях

Звучит секси, но

а) 99% людей не будут этим заниматься, потому что нам всем и так есть чем заняться
б) Оказывается, что 80% того что ты переделал почти полностью повторяет то, что уже было (если до этого подходил с умом и вовремя обновлял)

Я процентов 20 своего времени трачу на эксперименты с разными подходами и инструментами, и только сейчас более-менее стал доволен тем, как оно работает и для технических задач, и для операционки. Причем, я уверен, что выстроенная система переживет еще несколько новых поколений моделей почти без изменений

Я собрал всё действительно важное в пошаговый роадмап по настройке и освоению ИИ-агентов на конец лета 2026 года

Во вторник 18.08 в 18:00 GMT+3 проведу бесплатный эфир с разбором

Еще на эфире расскажу кому и почему будет полезно поучаствовать в нашем платном марафоне, где мы за ручку проводим по этому роадмапу (доходимость на прошлом – 85%!). А кому – нет. Для таких постараюсь сделать эфир+роадмап полезными сами по себе

→ Записаться на бесплатный эфир 18 августа

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 там не подходит по одной причине – авторизация происходит внутри сэндбокса и на каждый новый чат придется делать ее заново

Пример: gh отлично работает у вас на ноуте, но в ChatGPT Work вы задолбаетесь каждый раз проходить авторизацию, а вот GitHub MCP подключите один раз и он будет работать всегда

В разговорах слышал еще такие аргументы за MCP (но мне они не нравятся):

1. Проще раскатывать на команду и обновлять (хз, автообновление cli делается тривиально)
2. MCP сразу поддерживает инструкции, а про CLI тул агент еще должен как-то узнать (скиллы наш бро)
3. В MCP есть функции, которых нет в API (это вообще извращение, не делайте так. но если пользуетесь чужим сервисом таким, то да, тут придется страдать)

А у вас в команде используют MCP? Почему?

(напоминаю, что скоро будет пост о том, почему CLI тоже не самый лучший выбор)

@ai_grably

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 - <<'TS'
import { Api } from 'grammy'
// используем Bot API либу вместо MTProto для простоты

const { botToken } = await Bun.file(`${process.env.HOME}/.tg-agent-bot/config.json`).json()

const api = new Api(botToken)
console.log('sent:', (await api.sendMessage(373021550, 'Привет через grammY')).message_id)
TS

Проблема номер два – где хранить всякие полезные данные. Например, известные id-шники с описанием или helper-скрипты. Тут все по классике как с CLI – создаем ~/.tg-agent-bot и храним там config.json и папку со скриптами. Там же и токен бота (либо в keychain системы)

Получается, из конфигурации skill+cli мы убираем cli и просто описываем все тонким скиллом. Агент сам пишет скрипт прям в момент вызова

———

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

Тема экспериментальная, пользуюсь ей несколько недель, мб чего-то не замечаю – интересно, что думаете

Много скептицизма прилетело в комменты и даже мне в лс по посту про агентов, которые пишут код 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

Видел недавно интересный тейк, мол, все только хвастаются как внедряют ИИ, но конкретных успешных кейсов никто не показывает. Да и вообще, большая часть ИИ пилотов в компаниях – провалилась

Ну во-первых, большая часть пилотов и должны проваливаться по определению – это проверка гипотез

А во-вторых, я вижу, что реально успешные внедрения идут не от разработки кастомного решения, а от правильного онбординга уже готовых универсальных агентов (codex/cc) внутри компаний

Даже своих клиентов я сейчас отговариваю от кастома – вместо этого мы стали настраивать им агентную инфру с управлением скиллами, трейсиноом сессий и управлением доступами

Но это для среднего и малого бизнеса. Про крупняк я очень скептично настроен. Но на конфе от Community Sprints ребята обещают кейсы успешных применений в нетехнических командах известных компаний. Ну, посмотрим

Участие бесплатное и без подписок на спикеров (🫢)

Я там тоже как-то затесался – покажу один из своих любимых кейсов:

Продуктовый/маркетинговый рисерч агентами по одному из самых богатых, но наименее индексируемых хранилищ информации – ютубу

Еще будут крутые ребята из известных компаний (круто, что и РФ и международка). Весьма no-bullshit состав, на мой взгляд - многих знаю лично

8-10 сентября со стартом в 18:00 по мск

Бесплатная регистрация и подробности по темам – у ребят на сайте

↑ Cейчас разбирал с Фейблом system card gpt-6-astra и чет опять такими вайбами ai-2027.com повеяло, ух

Полтора года назад, когда она жестко зафорсилась в ИИ пузыре, ее мало кто реально прочитал, зато много кто высмеивал в нереалистичности (classic).

В целом не удивительно – тогда более-менее в теме актуальных возможностей ИИ были единицы, да и то скорее аккуратные скептики. Да и английский в статье не самый простой. Если кто пропустил, но хочет прочитать – напоминаю, что я тогда выложил перевод на хабр. Даже обе концовски сделал – можно выбрать свою

Перевод, кстати, уже тогда был полностью сделан нейронкой (даже картинки), хотя и с кучей хаков, чтобы это было комфортно читать

Есть всё-таки что-то ироничное в том, что текст про опасности ИИ полностью переведен самим ИИ

Время чтения – пару часов, ощущения – бесценны

https://habr.com/ru/articles/898622

Разбор аудиорежима в кодексе

Будет особенно интересно тем, кто сам разрабатывает что-то подобное.
Но и просто пользователям тоже постарался сделать полезным – чтобы понимать ограничения таких систем и лучшие практики взаимодействия с ними

Короче, я тут на днях делал себе компрессы для глаз (*звуки деда*), а они прям полностью глаза закрывают, там такая маска, типа как для сна

Ну и вместо того, чтобы спокойно посидеть и подумать о вечном, я врубил диалоговый режим кодекса и проболтал с ним пол часа вместо положенных мне 15 минут

Стало интересно, че это он такой умный, и я полез реверсить билд кодекс аппа – реализация оказалась одновременно и простой, и глубокой. А сам подход можно использовать не только для аудио (но об этом в конце поста)

В общих чертах – вы общаетесь не с самой gpt-5.6-sol в полноценном кодекс агенте, а с тупенькой моделькой gpt-realtime-1. Тупенькой, но быстрой. И заточенной под диалоговый формат с переживаниями – без этого естественности не добиться и любое общение будет мучением.

Так вот, пока у этой модельки хватает сил самой с вами общаться - она будет. Но как только нужно будет сделать что-то сложное, она побежит к кодекс агенту и даст ему задачку. В этот момент сразу же скажет вам что-то вроде «ну-ка дай подумаю» или «так, разбираюсь». Это важно, чтобы мы чувствовали непрерывность общения – как с людьми

Такой типа эффект Джарвис. И это реально работает!

Получается интересная система, очень похожая на ту, которая бывает в обычных айти командах:

- есть менеджер, который всегда онлайн и быстро отвечает, и который общается с заказчиком

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

А менеджер ему еще по ходу докидывает задачки, если у заказчика появились новые хотелки

Что интересного из этого следует для нас как для пользователей:

1. Если в процессе выполнения слишком много докидывать новые хотелки, то результат получится плохим: если вы когда то пробовали отправлять steer сообщения в чат работающему агенту, то вы скорее всего замечали – они часто его слишком сбивают с начального пути (ну реально, все как с человеками)

2. Как и в реальных командах, если хотите рулить через одного менеджера несколькими процессами – нужен еще тимлид для команды. Поэтому можно просить выступать в этой роли и ничего не делать самому, а для всех задач на исполнение создавать либо отдельные чаты, либо субагентов. Тогда получится:

Менеджер
⬇️
Тимлид
↙️⬇️↘️
Исполнитель1, Исполнитель2, ..., ИсполнительN

Тогда выполнение одной задачи не будет блочить главного думающего агента и будет наш привычный опыт, когда в параллель работают несколько чатов, но только с голосом в качестве канала передачи инфы

Что тут полезного для тех, кто сам делает AI продукты/фичи

Мне кажется, можно забрать сам подход с тем, что сессия основного агента не видна пользователю напрямую, а есть какой-то прокси уровень коммуникации. И это не обязательно должен быть голос. Это может быть какой-то визуальный слой (скоро поделюсь своими экспериментами с Liquid UI), или даже обычный текстовый, но в привычном интерфейсе условного Slack, с быстро отвечающей моделью, которая подтягивает контекст из сессии умного, но долгого агента

Ну и если вы делаете голосовых роботов, то советую отправить агента посмотреть, в чем отличие вашей системы от кодекса – мб захотите что-то к себе перетащить

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

P.s. я, конечно, очень сильно упростил работу менеджеров – на самом деле они делают гораздо больше, чем gpt-realtime-1. Это просто самая близкая и наглядная аналогия, которую я придумал. Если у вас есть лучше, прошу в комменты

@ai_grably