Введение в AI-агентов и автоматизацию в ASO

На курсе ASO Engineering вы не будете учиться «правильно просить нейросеть делать ASO». Вы будете собирать рабочие процессы с помощью AI.

Можно написать в чат GPT:

«Собери семантическое ядро, проанализируй конкурентов и подготовь метаданные, вот тебе данные…».

GPT даст ответ. Но насколько он будет точен? И сможет ли он в точности повторить этот процесс в следующий раз? И не забудет ли эти данные в следующем анализе?

Он может:

• взять не те данные;
• не проверить релевантность;
• не сохранить результат;
• не дать возможности повторить анализ через неделю.

На курсе мы разбираем, как не получать такой результат. Потому что все AI-генераторы метаданных, которые есть – это игрушка, где генерация захардкожена (от англ. hard code – «жестко закодировать», то есть убить универсальность).

Костыль решает проблему здесь и сейчас. Но он не обязательно решает ее правильно и не дает системе нормально масштабироваться. Например, агент может написать программу, которая отлично работает на вашей текущей выгрузке. Вы запускаете ее — все прекрасно. А потом вы закидываете другую выгрузку с другими данными, объемом и запросами. И программа ломается.

Потому что агент не построил универсальное решение. Он подогнал код под те входные данные, которые увидел. Поэтому после каждой итерации нужно спрашивать агента: «Будет ли это работать на других входных данных?». Можно и в грубой форме ему написать. Чтобы не создавал костыли, которые закрывают текущую проблему, но не решают ее окончательно.

Вот наглядный пример, что отдает сервер и что видим в интерфейсе. И тут виден валидатор, который удаляет стоп-слова. Сервер отдает в поле keywords ключ “for”, но в интерфейсе его нет. То есть генератор изначально не учел этот нюанс. А значит, что вся генерация уже должна вызывать сомнения.

Генератор сгенерит поле keywords со 109 символами, но перед тем, как это окажется в интерфейсе, просто обрежется все по запятой, чтобы уложиться в лимит. Что-то важное, возможно, мы потеряем.

Всё, что предлагают ASO-сервисы — это просто промпты, отправляемые в AI. А для правильной автоматизации нужны сложные программы. 

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

А в данном случае все отдали на откуп AI. Так автоматизировать нельзя. И мы на курсе так делать, конечно же, не будем.

Отправить промпт на ресерч и поставить ежедневный ресерч на 7:00 – это не автоматизация. Ну, это автоматизация ресерча, но не автоматизация реального процесса с качественным результатом.

И раздел Automations тоже не то, что нам нужно.

Это все просто повторяемые действия: проверить почту, почитать новости, что в мире за ночь произошло, написать текст, ответить на письма, поставить задачи в календаре.

Выбранный режим Agent еще не означает, что у вас появился высококвалифицированный ASO-специалист, аналитик или разработчик, который может безопасно делать все сам.

Режим Agent означает только одно:

Модель получила возможность не только отвечать в чате, но и выполнять действия в папке проекта: читать файлы, создавать и менять файлы, запускать команды, пользоваться доступными инструментами.

Это полезно. Но без четкой задачи и ограничений агент может выполнить действие слишком широко.

Например, вы пишете:

«Очисти мой диск от мусора».

Агенту не объяснили, что именно считается мусором. Мусором может быть и старый файл из папки Загрузки с вашей налоговой декларацией.

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

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

Но мы не знаем ни критериев, ни того, какие правила использовались. Мы вообще ничего не знаем. Оркестратор сам решил, что результат подходит. А мы потом удивляемся этой ерунде.

Так что же такое агент

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

У него есть:

• входные данные;
• одна зафиксированная роль;
• правила, по которым он работает;
• доступ к конкретным данным или инструментам;
• понятный результат его работы.

Например:

Вход:

Название приложения, стор, страна, язык, список запросов.

Задача агента:

Собрать поисковые подсказки по каждому запросу.

Выход:

Таблица подсказок с указанием исходного запроса, страны, стора и даты сбора.

Это агент-сборщик.

Он не должен одновременно:

• решать, какие ключи полезны;
• делать семантическое ядро;
• анализировать конкурентов;
• писать метаданные;
• составлять стратегию продвижения.

Когда один агент пытается делать все сразу, он получает слишком много данных, слишком много инструментов и слишком размытый критерий качества. Он начинает пропускать шаги и выдавать поверхностный результат.

Одна роль = одна задача = один понятный выход

А как же выглядит агент? 

Никак. Это просто документ в формате MD с инструкцией. Чисто технически это вообще сложнее намного. Но уж тут в техничку мы точно лезть не будем.

Структура файла достаточно простая:

• Роль
• Цель
• Критерий готовности
• Что запрещено
• Какие данные берет
• Что должен сделать перед запуском
• Какими инструментами пользуется
• Логика работы по шагам
• Что отдает на выходе

Вот пример первого шага агента для составления полного описания приложения:

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

Вернемся к примеру с очисткой диска.

Сначала вы говорите агенту:

«Посмотри, что находится в папке “Загрузки”».

Он изучает содержимое и присылает результат. Затем вы уточняете:

«Удалить все, кроме этих 2 файлов».

После этого возникает новая задача:

«Mac показывает, что System Data занимает 75% диска. Посмотри, что именно занимает место и что можно удалить без риска».

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

Когда результат вас устраивает, вы говорите:

«Создай скилл безопасной очистки диска по правилам, которые мы только что выработали».

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

А может, тогда упростить себе жизнь и собрать все эти правила в скиллы? Нет. Скилл может подключаться оркестратором в других проектах. Нам этого не нужно. Наши правила должны действовать только внутри конкретного проекта, поэтому мы ограничиваем агента папкой, в которой работаем. 

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

Более того, при обычном общении с чатом этот скилл тоже может быть подключен, когда понадобится создать документ. В итоге вы будете получать не то, что нужно. Поэтому все, что относится только к конкретной задаче или проекту, оставляем внутри проекта.

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

Агент не равен ChatGPT

ChatGPT, Claude, Gemini и другие сервисы – это интерфейсы для разговора с языковой моделью.

Вы пишете сообщение.
Модель отвечает текстом.

Это удобно для:

• объяснений;
• вопросов;
• черновиков.

Но браузерный чат сам по себе не является агентной системой.

В обычном чате нет:

• контролируемой папки проекта;
• структуры входных и выходных файлов;
• истории изменений;
• надежной памяти о прошлых действиях;
• базы данных;
• контроля, что именно модель изменила или создала.

Поэтому в чате можно обсудить систему, но рабочую систему нужно собирать в проекте на компьютере.

Например здесь агент пишет, что аудит сохранен где-то на сервере Perplexity, но как к нему получить доступ? Как мне открыть этот файл и посмотреть что внутри? Закончится лимит на токены и тогда вообще завершить задачу не получится. Не говоря о том, чтобы сохранить черновики.

Или вот частая проблема с Claude даже на тарифе Pro – задача не завершена, а лимиты закончились. Что было сделано – мы так и не узнаем, пока не сбросится лимит и не продолжится задача.

Почему мы работаем на компьютере

Агентная система состоит не только из переписки с AI.

У нее есть:

• Папка проекта
• Файлы с входными данными
• Код отдельных программ
• Файлы правил
• Логи (записи, которые программа создает в процессе работы)
• Ключи доступа к сервисам

Когда вы работаете в папке проекта, вы видите, что реально происходит. И можете контролировать весь процесс!

Например, в input мы помещаем выгрузку из Asodesk. В output мы должны получать готовое семантическое ядро. 

Что дальше? Просто в чат пишем «собери ядро по этой выгрузке»? 

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

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

Вы возразите: «Как так? У нас же есть правила».

Да, правила есть. Например, правило, как оформлять Excel-файл. Но это все равно общая инструкция. Если нам нужно, чтобы таблица каждый раз выглядела абсолютно одинаково, лучше один раз написать код, который формирует эту таблицу и подставляет в нее новые данные.

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

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

Представьте джуна. Сегодня он узнал, что ключи из выгрузки, связанные с VPN, нужно удалять. Вчера он их оставил, потому что еще не знал об этом правиле. Сегодня удалил. 

Мы можем написать это в промпте. Но если каждый раз заново прописывать одни и те же правила, это уже не автоматизация, а лишняя ручная работа. К тому же сегодня агент может понять промпт одним образом, а завтра – немного иначе. Так мы не работаем.

Поэтому повторяемые правила нужно выносить из промпта в структуру самого проекта.

Например, в папке проекта мы создаем словари со списками исключений. Когда агент получает задачу на сбор семантического ядра, он каждый раз обращается к этим словарям и применяет одни и те же правила.

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

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

Но зачем вообще каждый раз указывать это в промпте? Можно заранее установить правило, что для детских приложений целый ряд тем запрещен и должен автоматически удаляться. 

Кстати, а что со стоп-словами? Может их тоже удалить?

Создаем словари для App Store и Google Play. В них храним слова и темы, которые нужно исключать из семантического ядра. Агент использует нужный словарь в зависимости от стора и автоматически очищает выгрузку.

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

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

Спрашиваем в чате, как это сделать.

И он нам отвечает, что нам агент здесь не поможет. Ведь тут еще и косинусную близость какую-то считать надо. Непонятно. Понятно, что обычный чат для этой задачи не подходит, а значит нам нужно переходить в среду разработки. Переходим в IDE (от англ. Integrated Development Environment).

Внутри проекта говорим агенту реализовать эту механику.

Он устанавливает нужную библиотеку, пишет код, и у нас наконец появляется рабочий инструмент. Ура! Возвращаемся в окно чата.

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

И здесь у нас два пути.

• Первый – сказать ему в чате, чтобы он всегда запускал эту программу. Тогда он создаст файл AGENTS.md, в котором будет зафиксирована эта инструкция.
• Второй – вообще убрать чат из цепочки. Мы продолжаем развивать программу, обновляем входные данные, запускаем ее – и получаем готовое ядро в папке output.

Вот второй вариант – уже зрелая автоматизация процесса. Человек меняет только входные данные и запускает процесс. Все остальные шаги система выполняет сама.

Как все это работает вместе

Разберем по шагам задачу сбора ядра.

Человек ставит задачу
↓ 
Координатор решает порядок шагов
↓ 
Программа выполняет точные действия
↓ 
Агент выполняет смысловую работу
↓ 
Память хранит историю и результаты
↓ 
Человек принимает решение

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

Программа – инструмент, а не второй агент

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

Например:

• Программа читает выгрузку из input/.
• Программа удаляет точные дубли и ключи из словаря стоп-слов.
• Программа сохраняет очищенный список.
• Агент получает этот список и проверяет на релевантность.
• Агент передает результат дальше.

Не нужно в начале курса уметь писать такую программу руками. Важно понимать, что именно она должна делать и как проверить ее результат.

Агент может предложить способ реализации, установить нужную библиотеку, написать код и создать тесты. Вы будете осваивать все эти нюансы прямо в процессе работы с ним.

И нюансы у каждого будут свои. У вас будут разные программы, разные способы их реализации и разные проблемы. Научить вас не ошибаться я не могу. Да и не нужно. Ошибки – часть работы.

Зато в IDE есть хороший инструмент для таких ситуаций:

Выбираем режим Debug и ставим задачу исправить ошибку. 

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

А как он вообще находит ошибку?

На самом деле все довольно просто.

В программе есть последовательность действий, и после каждого важного шага она может записывать в лог, что именно произошло.

Например:

Загрузили 10 000 ключей
↓
После удаления дублей осталось 8 420
↓
После удаления стоп-слов осталось 7 860
↓
После фильтрации по релевантности осталось 3 120

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

Например, мы ожидали 3 000 релевантных ключей, а получили 17. Значит, нужно смотреть не всю программу целиком, а сначала тот этап, после которого количество резко изменилось.

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

Как выглядит программа?

Зависит от того, какую задачу она выполняет.

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

В таком случае это просто код. Главное, чтобы он правильно выполнялся и стабильно выдавал нужный результат.

Вот этот файл с расширением .py – и есть программа, написанная на Python.

В рабочем пространстве мы видим много таких файлов, потому что это отдельные программы, из которых собирается цепочка одного процесса. Иногда одного .py-файла недостаточно. Тогда программа состоит из нескольких файлов, которые мы складываем в отдельную папку.

Например, data_loader – это набор программ для загрузки данных из разных сервисов. Один файл может отвечать за Asodesk, другой – за AppTweak, третий – еще за какой-то сервис.

Если мы работаем только с Asodesk, все остальные загрузчики нам не нужны. А следовательно и папка data_loader тоже не нужна. Но, если мы не хотим получить в корне нашего проекта свалку, нужно все-таки структурировать файлы по папкам.

То есть папка в проекте не обязательно означает отдельную программу. Часто это просто несколько связанных .py-файлов, которые вместе выполняют одну задачу.

А как это встроить в мой проект?

Я даю вам много модулей и готовых агентов. Большую часть работы я сделал за вас. Но как их использовать? Просто скачиваете нужный файл и пишите в чат:

«Встрой это в наш проект».

Что такое IDE

IDE – это программа на компьютере, где создают и ведут проект.

Слева – файлы проекта. 

В центре – файл, код, таблица или документ. 

Справа – чат с AI-агентом.

Снизу – терминал. 

Это важно потому, что агент должен работать внутри вашей папки, а не «где-то в облачном чате». Разонравился Cursor и хотите попробовать Codex? Welcome! Открываете эту папку и продолжаете в ней работать, используя другую оболочку.

Чат без папки = снова просто чат

Координатор, исполнитель и критик

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

По сути, это тот, с кем вы общаетесь. Вы ставите ему задачу, а он сам решает, кому ее поручить. Он же запускает программы и передает результаты между шагами.

Исполнитель делает одну узкую работу. Например: привести таблицу к единому формату, собрать топ выдачи, сгруппировать запросы или подготовить отчет.

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

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

Иногда проверку можно полностью отдать программе. Например, программа может проверить, не пустой ли файл, есть ли в нем нужные поля и сколько в нем строк.

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

А как все это выглядит вместе?

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

Но вот наглядный пример из Qoder. Специалист дал задачу в чате. Его принимает координатор. Он решает каких агентов запустить. 

Посмотрите на окно чата справа. По умолчанию уже есть готовые агенты с именами. Тэйлор – фронтендер, он создает пользовательский интерфейс. Еще есть Джей, который тоже что-то делает с интерфейсом – видимо, они работают параллельно: один собирает элементы, другой занимается стилями.

После этого подключается Крис, QA – типичный критик. Он проверяет результат и, если все в порядке, апрувит его. Затем Джеймс забирает задачу и занимается бэкендом, например пишет код, чтобы при нажатии на кнопку что-то происходило.

В конце оркестратор пишет саммари всей работы.

К слову, такую геймификацию я видел только в Qoder. Не ждите, что Cursor будет также запускать и отображать агентов.

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

Что такое модуль, скрипт и программа

Не застревайте на названиях.

Скрипт – небольшой файл кода для одной операции.

Модуль – часть программы, которую можно использовать снова.

Программа – один или несколько модулей, собранных в процесс.

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

Для старта важнее три вопроса:

• Что этот шаг получает на входе?
• Что он делает?
• Что он возвращает на выходе?

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

Например, дайте ему максимально широкий запрос: создать сервис, похожий на YouTube, и повторить не только его функциональность, но и дизайн. А дальше смотрите, что он делает. Исправляйте, направляйте, ставьте новые задачи. Именно это я покажу в лекциях «Вайбкодинг».

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

Что такое память

Память – не еще один агент. Это место, где лежит то, что понадобится системе позже:

• исходные выгрузки;
• прошлые результаты;
• история позиций;
• версии метаданных;
• результаты прошлых проверок.

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

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

Где находится эта память? Тоже в какой-то папке, например data.

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

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

«Что там у нас было на прошлой неделе? Напомни».

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

Техническая теория

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

Достаточно знать, под какую задачу какой метод брать, чтобы грамотно ставить задачу агенту.

Например, нам нужно проверить, насколько ключ связан с нашим приложением.

Я сразу понимаю: здесь можно использовать эмбеддинги. Нужно представить и ключ, и описание приложения в виде векторов, а затем посчитать косинусную близость между ними. Как минимум. Но и это не предел.

Понятно ли вам сейчас, что именно я сказал? Скорее всего, нет.

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

Но для работы с агентом вам не обязательно изучать все это, чтобы начать. 

Достаточно правильно сформулировать задачу:

«Мне нужна программа, которая проверяет, насколько ключ соответствует нашему приложению».

А дальше спросить агента:

«Как это можно реализовать? Какие методы здесь подойдут?»

Агент объяснит варианты, предложит способ реализации, установит нужные библиотеки и напишет код.

Ваша задача – понимать что вы хотите получить и какой результат считать правильным.

Можно ли разговаривать с агентом в том же чате?

Можно и нужно. Спрашивайте:

• зачем выбран такой способ;
• есть ли другой вариант;
• какие риски;
• что будет, если входные данные неполные;
• как проверить результат;
• что именно изменилось в коде.

Но важные решения не должны оставаться только в переписке. Контекст чата может сжиматься, а детали – теряться.

Поэтому цель проекта, его архитектура, правила и способ запуска должны быть зафиксированы в файлах проекта: README и ARCHITECTURE. О них поговорим позже.

Чат – место для работы и обсуждения. Файлы проекта – место, где хранится то, что система должна помнить постоянно. 

Что такое JSON

В какой-то момент мы поймем, что входных данных становится много – надо и выгрузки дать, и по конкурентам какую-то информацию, и указание на какие-то нюансы… В общем, как все это учесть?

Каждый раз в чате ему писать в промте? Это не автоматизация.

В формате .txt добавлять в input? Очень много файлов придется открывать и редактировать. 

И тут на помощь приходит JSON – текстовый формат для хранения структурированных данных. 

Этот формат вы будете встречать часто. Например, в JSON может храниться память проекта.

В JSON мы можем собрать всю информацию, которая нужна агенту или программе. Агент или программа может прочитать этот файл целиком и использовать данные в своей работе.

Метаданные можно хранить в конфиге (конфигурационный файл). Это как раз показано на скрине выше.

А описание приложения лучше держать в отдельном .txt, чтобы не превращать конфиг в свалку. Там же можно хранить информацию о конкурентах, кросс-локалях и другие пояснения, которые нужны для работы.

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

Опросник помещаем в input и заполняем. После этого запускаем программу, которая считывает ответы и превращает их в структурированный машиночитаемый текст – JSON.

Просто отправьте этот файл в чат вашего проекта и он сам знает, что с ним делать, куда положить и как адаптировать под ваш проект.

Зачем JSON нужен

Потому что вместо того, чтобы каждый раз вбивать параметры в терминал/чат/отдельные файлы, вы один раз заполняете файл, а программа читает его сама.

Даже, если там будут ссылки какие-то, то он сможет по ним скачать и добавить в input. Для этого есть уже готовый код.

Потом вы можете заменить только данные в JSON и снова запустить тот же процесс для другого приложения. Или даже не лезть туда, а изменять информацию только в опроснике. Это удобно. И ускоряет процесс.

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

Что делает агент, программа и человек

В каждом шаге процесса должен быть указан исполнитель:

• Агент
• Программа
• Человек

Иногда они работают вместе, но их роли нельзя смешивать.

Программа

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

• скачивание данных из API;
• чтение CSV, Excel, JSON и текстовых файлов;
• расчет позиций;
• сравнение списков;
• дедупликацию;
• проверку обязательных полей;
• проверку лимитов;
• запись результата в файл;
• обработку тысяч строк без изменения правил посередине.

Программа не «думает» как человек. Но она стабильно делает то, что ей описали. Например, удаление стоп-слов не надо поручать агенту, если ядро из тысячи строк. Он в середине списка может забыть что-то или начать по-другому думать.

Агент

Агент нужен, когда в задаче есть что-то над чем надо подумать.

Агент может:

• открыть страницы и собрать сведения по заданным правилам;
• прочитать описания, отзывы, статьи и документы;
• сгруппировать похожие запросы;
• найти противоречия;
• объяснить результаты расчета.

Программа не сможет объяснить результаты, она может только высчитать их.

Если дважды дать ему одни и те же 10 000 строк, он может получить немного разные результаты. В одном случае учесть все строки, в другом пропустить часть. Может по-разному обработать пропуски, дубликаты, округление или решить, какие данные включать в расчет.

Почему? Потому что агент каждый раз заново интерпретирует задачу. Он не выполняет инструкцию так же строго, как программа.

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

Агенту оставляем то, где действительно нужна работа со смыслом: анализ, классификация, поиск закономерностей и принятие решений.

Человек

Человек нужен там, где:

• цена ошибки высокая;
• нет эталона качества;
• нужен опыт;
• решение влияет на репутацию и деньги;
• нужно выбрать стратегию;
• результат выглядит подозрительно.

Пример для ASO:

Программа:
считает позиции и изменения.

Агент:
группирует ключи, объясняет закономерности, предлагает гипотезы.

Человек:
решает, менять ли метаданные, какие ключи оставлять.

Почему нельзя поручать агенту «сделать все»

Представьте задачу:

«Зайди в Asodesk, собери семантическое ядро и пришли готовый результат».

Агент может:

1. Зайти в сервис.
2. Собрать все подсказки.
3. Выгрузить их в таблицу.
4. Назвать это семантическим ядром.
5. Написать «готово».

Формально задача выполнена.

Но результат может быть бесполезным, потому что никто не указал:

• как проверить релевантность ключей приложению;
• исключаем ли брендовые запросы;
• что делать если разные языки;
• какие ключи считать мусором;
• какие метрики нужны;
• что считается хорошим и плохим результатом.

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

Он не ленится и не саботирует. Просто для него «готово» определяется тем, что вы написали.

Если вы не описали критерий качества, модель сама выберет самый дешевый для себя вариант завершения задачи.

Поэтому нужна архитектура!

Перед тем, как создавать агентную систему, надо продумать свою архитектуру. Архитектура – это схема процесса работы вашей системы.

Архитектура отвечает на вопросы:

• Какой результат нужен?
• Какие данные нужны для результата?
• Что происходит с этими данными?
• Кто выполняет каждый шаг?
• Где сохраняем результат?
• Кто получает его дальше?

Архитектура всегда начинается с выхода

Не с модели. Не с промпта. Не с Cursor.

Сначала спросите:

Что я хочу увидеть в конце?

Например:

Файл result_2026-09-07.json.
В нем есть:

• название приложения;
• стор;
• страна;
• дата;
• список ключей;
• текущая позиция;
• позиция до итерации;
• изменение позиции;
• рекомендованный следующий шаг.

После этого становится понятно, что нужно на входе и какие шаги необходимы.

Для создания архитектуры я использую бесплатный SimpleMind.

Сначала сформулируйте конкретную задачу.

«Автоматизировать сбор семантического ядра» – плохая постановка. Непонятно, какую именно работу должна выполнять автоматизация, и что мы должны получить в результате.

Например:

«Определить, по каким запросам из семантического ядра приложение имеет наибольшие шансы выйти в топ».

Это уже конкретная задача. Создаем новый проект и называем его

Дальше делаем три ветки:

• что получаем на входе;
• что делаем с этими данными;
• что должны получить на выходе.

Далее нужно буквально описать конечный результат:

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

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

И только после этого проектируем сам процесс:

как превратить входные данные в нужный нам список запросов.

Разбиваем задачу на отдельные действия, пока для каждого шага не станет понятно:

что приходит на вход → что с этим делаем → что передаем дальше.

Если с этим возникают сложности, то можно попросить любую нейронку расписать процесс. У нее знаний много и она может сопоставить как А превратить в Б. 

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

И это нормальная часть работы. Процесс редко получается идеально спроектировать с первого раза.

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

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

Вот пример архитектуры сбора семантического ядра, уже разбитый по папкам. 

Но можно это записать и в другом виде:

Здесь нет варианта, как делать правильно. Главное, чтобы информация была структурированная: какие файлы на выходе хотим получать, и какие нам нужны на входе, чтобы было из чего получать.

Как построить первую архитектуру

Зафиксируем сразу важный момент. После этого курса вы не начнете с первого раза проектировать идеальные архитектуры. Я тоже не могу дать вам универсальный шаблон, по которому вы всегда будете получать правильную систему. Так не работает даже у профессиональных разработчиков.

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

Выгрузка
↓
Агент чистит данные
↓
Агент группирует запросы
↓
Агент пишет результат

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

И вот здесь начинается настоящая архитектура. Вы начинаете задавать вопросы:

• Что здесь вообще должен делать агент?
• Почему ключ оказывается не релевантен моему приложению?
• Что произойдет, если входные данные будут неполными?
• А что если собрать ядро для приложения, которого еще нет?

Вот эти вопросы невозможно один раз выучить и закрыть.

Поэтому ваша первая архитектура почти наверняка будет плохой. И это нормально.

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

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

Плохая первая архитектура полезнее идеальной схемы, которую вы скопировали и не понимаете.

Автоматизация – сложное направление. За несколько модулей мы успеваем залезть сразу в несколько областей: разработку, работу с данными, машинное обучение, NLP, линейную алгебру, информационный поиск и еще черт знает что. И люди на это тратят десятилетия!

Можно отлично разбираться в ASO и при этом вообще не уметь выстраивать бизнес-процессы. Потому что знание процесса ASO и умение превратить этот процесс в работающую систему – две разные компетенции.

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

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

Но, можно вообще ничего из этого не делать. Можно каждый раз в ChatGPT писать:

«Собери семантическое ядро».

Получится магия. Только бестолковая.

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

На курсе мы используем другой подход. На осознание этого подхода нужно время. Потому что сначала гораздо проще написать в чат: «Собери мне ядро». А когда начинаешь строить систему, приходится разбираться, что именно происходит на каждом шаге и почему оно должно происходить именно так.

Мастер мотивации, конечно. 

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

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

Шаг 1. Выберите один процесс

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

Берите один контур.

Например:

Сбор keyword suggestions из Asodesk.

Или:

Анализ результата ASO-итерации.

Шаг 2. Опишите выход

• Что создается?
• Где лежит?
• Как называется?
• Какие поля обязательны?
• Зачем каждое поле?

Шаг 3. Опишите вход

• Какие данные нужны?
• Откуда берется каждое поле?
• Какая страна?
• Какой стор?
• Какой язык?
• Какой период?

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

Шаг 4. Запишите шаги короткими действиями

Плохо:

Агент анализирует данные.

Хорошо:

• Проверить, что есть App ID, store, страна и список запросов.
• Собрать подсказки по каждому запросу.
• Сохранить сырую выгрузку.
• Удалить точные дубли.
• …

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

Шаг 5. На каждый шаг поставьте исполнителя

Человек:
кладет исходную выгрузку в input/.

Программа:
проверяет формат, удаляет дубли, сохраняет файл.

Агент:
группирует запросы по смыслу и помечает вероятные бренды.

Критик:
проверяет, что не потерялись обязательные поля.

Человек:
утверждает финальный список.

Шаг 6. Добавьте условия

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

Как работать с агентом в среде разработки

Создаем папку проекта

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

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

Создаем с помощью агента два файла: README и ARCHITECTURE.

README.md – что это за проект, как его запустить, какие команды важны, куда класть данные, что нельзя трогать. Агент почти всегда открывает README первым.

ARCHITECTURE.md – как устроены модули, потоки данных, границы ответственности, где конфиги, где код, где артефакты.

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

Остальные папки формируем под процесс работы, например

01_loader
02_normalization
03_nlp
04_embedding

Это не совсем правильный подход к структуризации проекта, но очень удобный для контроля “где, что находится”. Просто, если не вы создадите структуру, в которой вам удобно будет ориентироваться, то ее создаст агент. И тогда вы запутаетесь окончательно.

Не бойтесь сделать что-то не так. Вы так учитесь. Задавайте вопросы в чате, говорите, чтобы проще объяснял, чтобы советовал как сделать лучше и т. п.

Почему не надо отдавать десять задач разом

Когда вы пишете:

«Собери все: архитектуру, парсер, базу, UI, семантику, отчет и автоматизацию»,

модель получает большую неоднозначную задачу.

Она должна угадать:

• технологию;
• структуру проекта;
• формат данных;
• методы расчета;
• UX;
• критерии проверки.

В результате она часто делает много файлов, но не строит надежный контур.

Рабочий запрос выглядит так:

Прочитай README.md и ARCHITECTURE.md.

Ничего не изменяй.

Сначала опиши:

• Как ты понял цель модуля.
• Какие входные файлы нужны.
• Какие проверки должны быть до запуска.
• План реализации первого шага.
• Какие риски и неясности ты видишь.

После этого вы читаете ответ и только потом разрешаете работу.

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