Transcript
00:00:00Появился новый термин — графовая инженерия, и все в X только о нем и говорят.
00:00:04До графов была инженерия циклов: вы давали агенту цель, и он двигался к ней
00:00:09самостоятельно. Но с графами работа выполняется быстрее и охватывает куда больше задач,
00:00:14чем мог бы охватить цикл. Однако есть одна огромная проблема. Одна ошибка в малой части
00:00:18графа искажает весь итоговый результат, а отследить ее трудно, ведь на выходе
00:00:23вы получаете только готовый ответ. И вот Anthropic выпустила решение,
00:00:27которое устраняет эту проблему и защищает ваши графы от сбоев. Если вы здесь впервые, мы —
00:00:32IT-компания, а это наш канал AI Labs, где мы показываем, как оптимизировать бизнес с помощью ИИ.
00:00:37А если у вас нет своего бизнеса, вы можете зарабатывать, внедряя эти навыки для других.
00:00:42В этом видео мы разберем графовую инженерию для тех, кто с ней еще не знаком,
00:00:46и покажем точное решение от Anthropic. Но прежде чем разбирать графовую инженерию,
00:00:52нужно понять, что такое инженерия циклов. Если вы уже в теме, можете пропустить этот блок.
00:00:56Цикл — это, по сути, рабочий процесс, который вы передаете агенту. Вместо того чтобы
00:01:02вести его промптами через каждый шаг вручную, вы задаете конечную цель, и он добирается до нее сам,
00:01:07корректируя действия на ходу. Мы активно используем их в своей работе. На канале уже есть
00:01:12отдельное видео про инженерию циклов, где мы подробно разбирали способы их настройки, но сейчас
00:01:17циклы эволюционируют в графы. Проблема циклов кроется в самой их архитектуре.
00:01:22Цикл выполняет часть работы, затем включается этап проверки, чтобы убедиться, что все сделано
00:01:27как надо. После успешной проверки начинается следующий шаг. Все идет последовательно,
00:01:32и каждый шаг ждет завершения предыдущего, даже если они вообще не связаны. Графовая инженерия
00:01:37решает именно эту проблему. Вместо линейного процесса граф разбивает главную задачу на части,
00:01:42и для каждой части выделяется свой агент. Первое преимущество — это скорость, ведь сразу
00:01:47несколько агентов делают работу параллельно, а не один агент пробирается через весь объем.
00:01:52Разделение задач также немного снижает затраты, так как вы можете выбирать модель
00:01:56для каждого отдельного агента. Вы перестаете тратить самую дорогую модель на этапы,
00:02:01где мощный интеллект изначально не требовался. Но это экономия на агента, а не на всю систему.
00:02:07Граф сжигает намного больше токенов, чем один агент, так как у вас одновременно работает группа агентов.
00:02:12Если вы используете графы, будьте готовы, что лимиты исчерпаются куда быстрее привычного,
00:02:17так что построить это на тарифах за $20 в Claude Code или Codex не получится. Если вы пользовались Claude Code,
00:02:22для вас это не совсем новость: вы уже видели граф в виде динамического
00:02:27рабочего процесса. Он берет входную задачу и распределяет ее по субагентам,
00:02:33что, по сути, и делает граф. Прежде чем разбирать структуры графов, нужно понять,
00:02:38из чего они состоят. Любой граф строится из двух элементов: узлов (nodes) и ребер (edges). Узел —
00:02:44это отдельная подзадача из общего пула, которая выполняется изолированно. Это агент,
00:02:49который делает работу в своем контекстном окне и отчитывается о результате. Связывает эти задачи
00:02:55между собой ребро. Ребро управляет передачей данных от узла к узлу, чтобы вывод одного агента
00:03:01попадал к нужному агенту в нужный момент. Каждый узел должен быть так или иначе связан с графом.
00:03:06Пример — группа агентов, рецензирующих один и тот же фрагмент работы. Ни один из них
00:03:10не ждет остальных. Но все они стартовали с одной исходной точки, и отчет каждого из них стекается
00:03:15в единый финальный блок. Из этого и состоит граф. Теперь о формах, которые принимают эти элементы.
00:03:20Первая форма уже встречалась на нашем канале, хотя тогда мы назвали ее неправильно.
00:03:25Мы назвали ее циклом, потому что графовой инженерии как термина еще не существовало. Но
00:03:30на самом деле это был граф, запущенный по циклу, и его форма напоминала ромб. Задача на входе
00:03:35расщепляется на параллельных субагентов, а затем они снова сходятся к одному
00:03:41агенту, который собирает все находки в единый ответ. Еще есть граф с барьером (fan-in at a barrier),
00:03:46и он идеален, когда объект нужно оценить сразу с разных точек зрения. Этап «fan-out»
00:03:51рассылает задачу группе агентов, и каждый анализирует ее со своего ракурса.
00:03:56Процесс не двинется дальше, пока абсолютно каждый агент не пришлет отчет,
00:04:00и только потом запускаются исправления. Существует много других форм. Но все они держатся
00:04:05на одном фундаментальном этапе — верификации. Без грамотной проверки каждый следующий агент
00:04:10будет просто наслаивать работу поверх чужой ошибки. Прежде чем перейти к верификации, подпишитесь
00:04:15на канал и поставьте лайк. Эта небольшая поддержка очень важна для нас.
00:04:20Когда вы запускаете целую сеть агентов, сбои возникают там, где у одиночного агента их не бывает.
00:04:25Главная проблема — объем работы. Они работают одновременно, выдавая огромный пласт
00:04:30данных за раз, и проверять это в конце крайне сложно. Вторая проблема —
00:04:34отсутствие прозрачности. Если что-то ломается, невозможно понять причину сбоя.
00:04:39Вообще, любые агенты проверяют написанное, просите вы их об этом или нет. В работе с кодом
00:04:44агент просто прогоняет тесты и перехватывает ошибки. Но так выявляются лишь критические баги.
00:04:49Качество самой структуры кода не проверяется, а это критично: если Claude
00:04:53продолжит писать так, в будущем возникнут проблемы. В Claude Code есть пара встроенных
00:04:58инструментов для этого. Первый — навык verify, который проходит по коду от начала
00:05:03до конца и подтверждает корректность его работы. Второй — цепочка инструментов (tool chaining),
00:05:08когда агент запускает утилиты для проверки. Claude умеет запускать проверяющие утилиты,
00:05:13читает логи ошибок и сам их исправляет. Он способен сам определить команды вашего
00:05:18проекта. Однако пропись их в файле Claude.md избавит его от необходимости
00:05:24выяснять их каждый раз заново. Третий инструмент — навык ревью кода, проверяющий написанное
00:05:29на соответствие стандартам. Он есть не везде, но вы можете попросить агента создать его,
00:05:33если его нет. Но лучше всего работает верификация, настроенная вами вручную,
00:05:38а не полностью встроенная. Быстрейший способ создать навык проверки —
00:05:44плагин skill creator в Claude Code. Этот же навык Claude Code можно использовать
00:05:49и в Codex. Вы запускаете команду плагина, находите skill creator и устанавливаете его. Далее
00:05:54есть два варианта. Установить на уровне пользователя — тогда он доступен в любой
00:05:58папке. Или установить локально — только для текущего проекта.
00:06:03Поскольку этот навык нужен постоянно, мы выбрали пользовательский уровень. Затем
00:06:07вы перезагружаете плагины слэш-командой, и skill creator готов к работе. Теперь вы описываете,
00:06:12что именно нужно создать — то есть логику и тип желаемой проверки.
00:06:17Мы чаще используем навык ревью для сверки результата с изначальным ТЗ.
00:06:22Для графа это вдвойне важно, ведь каждый агент видит только свой кусок.
00:06:28Это дает ему способ сопоставить результат с исходными требованиями. Но навык
00:06:32хорош настолько, насколько хороша модель, на которой он работает. Когда мы делали проверку
00:06:37UI для сайта нашего сообщества, мы запустили ревьюер на Haiku: она дешевая, а задача казалась
00:06:43простой. Она выдала длинный список проблем. Судя по количеству замечаний,
00:06:47она справилась отлично. Но затем мы прогнали то же самое на Opus, и она нашла гораздо меньше.
00:06:53Это казалось худшим результатом — пока мы не вчитались в аргументацию. Многое из показанного Haiku
00:06:58было оставлено нами намеренно. Большинство ее замечаний оказались ложными.
00:07:03Opus поняла это из контекста кода, а Haiku полностью упустила. Дешевая
00:07:08проверка ничего не сэкономила: теперь требовалось проверять сам отчет. А теперь поместите это
00:07:13внутрь графа, где куча узлов проверяет свою работу тем же навыком. Получатся
00:07:18агенты, тратящие время и токены на исправление того, что не было сломано. А поскольку это происходит
00:07:23на разных агентах одновременно, вы даже не поймете, кто это начал.
00:07:27Выбранная модель определяет не просто качество проверки, а качество
00:07:31всего графа. Узел оценки — единственное место, где экономия на токенах обходится
00:07:37слишком дорого. Также нужно решить, как и когда вызывать этот навык.
00:07:41Поэтому они делятся на три типа. Но перед детальным разбором — пара слов от нашего спонсора.
00:07:46Если вы собирали данные в реальном времени из сети, вы знаете, какой это ад: вечная
00:07:51борьба с капчей, лимитами, прокси и версткой, которая ломается сразу
00:07:56после релиза. Мы используем SERP API: он решает эти проблемы, позволяя сосредоточиться на разработке.
00:08:01Всего один вызов API — вы отправляете запрос и получаете чистый JSON с нужными данными,
00:08:07с аптаймом более 99,9% и откликом около 1,2 секунды. При создании ИИ-агентов вы можете
00:08:14подключить Google Search API для свежих данных или Google Scholar API
00:08:20для научных статей с метаданными. Именно поэтому его выбирают для продакшена. Начните
00:08:25с 250 бесплатными кредитами по ссылке в описании или QR-коду на экране. Спасибо SERP API за
00:08:32спонсорство этого видео. Первый тип — автономные (standalone), они запускаются только
00:08:37по вашей команде. Автономный навык создается для глубокого анализа существующего кода,
00:08:42чтобы вычитать готовый результат. Поэтому его не стоит ставить на каждый прогон:
00:08:48вы сжжете токены на глубокий анализ еще не завершенной работы. Мы применяли
00:08:53«thermonuclear code review» от Cursor. Он распределяет агентов и прогоняет код
00:08:59по разным векторам безопасности. Все замечания собираются вместе для совместной
00:09:04правки. И это именно та проверка, которую делают один раз по завершении проекта. Для ее создания лучше использовать
00:09:10skill creator, а не просто промпт, так как результат будет протестирован и ему проще
00:09:15доверять. Укажите в промпте зону проверки и обязательно добавьте,
00:09:20что ревью должно быть комплексным, чтобы агент выполнил глубокий проход. Но автономный
00:09:26навык бесполезен для работающего узла, так как его нужно вызывать вручную. Для этого служат
00:09:31встроенные (embedded) навыки. Встроенный навык срабатывает внутри процесса автоматически,
00:09:36без явной команды. Можно сделать навык, запускающийся при запросе новой фичи.
00:09:41Он проверяет, соответствует ли создаваемый компонент заданным в навыке правилам,
00:09:45и не дает завершить реализацию без этой проверки. Вы можете создавать встроенные
00:09:50навыки сами, но нельзя взять предустановленный навык и автоматизировать его,
00:09:54как в случае с упомянутым verify. Инструкции таких навыков скрыты внутри продукта,
00:10:00и доступа к ним нет. Чтобы сделать свой, дайте skill creator промпт выполнять шаг проверки
00:10:05после внедрения каждой фичи — то есть тестировать ее сквозным образом, чтобы понимать,
00:10:10не сломал ли новый код уже работающий функционал. Claude сгенерирует навык,
00:10:16а поскольку использовался skill creator, он сразу будет содержать структурированные
00:10:21и протестированные референсы и скрипты. Для проверки фичи Claude по умолчанию берет
00:10:26браузерные тесты: открывает полновесный Chrome, загружает страницу и делает
00:10:31скриншоты. Если подключены Puppeteer или Playwright (стандартные инструменты
00:10:36для автоуправления браузером), происходит то же самое. Но Chrome известна прожорливостью,
00:10:41и постоянные проверки страниц внутри рабочего процесса сильно его замедляют,
00:10:46отнимая реальное время. Есть более легкий путь — Chrome Headless Shell. Это
00:10:52урезанная версия браузера без лишних компонентов. Агент точно так же открывает
00:10:57страницу и снимает скриншоты, но делает это значительно быстрее обычного
00:11:02Chrome. Это можно сразу прописать в создаваемый навык верификации. И тогда каждая
00:11:07написанная фича будет проверяться визуально без постоянной ручной настройки. Кроме этого,
00:11:12самый частый навык в нашей практике — «second opinion» («второе мнение»), и вот почему.
00:11:17Агент, создавший код — худший кандидат для его проверки. Он оценивает свою работу
00:11:23из того же контекста, в котором ее писал. Свежая сессия Claude этого контекста не имеет,
00:11:28выдавая объективный анализ и прямой ответ. В Claude есть встроенный
00:11:33советник с похожей логикой, но он читает текущий чат и наследует
00:11:38весь контекст. «Second opinion» нужен для проверки с чистого листа. Он запускает
00:11:43вторую сессию Claude прямо из текущей с помощью флага `-p`.
00:11:48Этот флаг поднимает в фоновом режиме изолированную сессию Claude Code с нужным
00:11:53промптом. Но здесь есть пару нюансов. Поскольку запускается
00:11:57отдельная сессия, ответ занимает довольно много времени. И здесь выбор
00:12:02модели важен как никогда, ведь суть — получить независимый и умный взгляд.
00:12:07Поэтому лучше явно указать Claude запустить эту сессию на Opus. Так каждый узел
00:12:12в графе сможет проверить работу через модель, не участвовавшую в создании. Но один навык
00:12:18не может закрыть все задачи. Полноценная проверка требует оценки с разных
00:12:22сторон, и для каждой нужен свой критерий. Нельзя впихнуть все типы ревью в один
00:12:27навык: агент получит слишком много фокусов и станет работать хуже,
00:12:33а не лучше. Поэтому под каждый ракурс создается отдельный навык, и они объединяются в цепочку. Команда
00:12:38Anthropic делает точно так же. Они связывают навык ревью кода с навыками simplify и verify,
00:12:43и все три идут в комплекте с Claude Code. Вдобавок они прогоняют собственный дизайн-навык,
00:12:49сверяющий интерфейс с файлом design.md, где прописаны все продуктовые
00:12:54дизайн-решения. Это дает проверку сразу с четырех направлений. Вы придете
00:12:59к такой же схеме: стек навыков, закрывающих разные углы. Но нельзя просто
00:13:04сказать агенту запустить все сразу. Нужен верхнеуровневый навык,
00:13:09дирижирующий остальными. Он поднимает по агенту под каждый
00:13:15навык проверки и передает им задачи. Они параллельно проводят ревью в своих
00:13:20контекстных окнах. Затем оркестратор сводит все замечания в один отчет, с которым работают
00:13:25агенты-исправители. В итоге при построении графа достаточно указать в промпте
00:13:30использование одного этого навыка. Каждый узел подгружает его, и вся структура верификации
00:13:35разворачивается сама. Мы подготовили документ с подробным описанием всех вариантов
00:13:40настройки проверок для графов. Этот документ и навыки из видео доступны
00:13:45в нашем сообществе AI Labs Pro. Если наша работа полезна и вы хотите нас поддержать,
00:13:50это лучший способ. Ссылка в описании. На этом видео подходит к концу.
00:13:55Если вы хотите поддержать канал и помогать нам выпускать новые ролики, используйте
00:14:00кнопку «Спасибо» под видео. Как всегда, спасибо за просмотр, и до встречи в следующем выпуске.