Anthropic только что устранила главный недостаток графовой инженерии

Русскийالعربية Deutsch English Español Français हिन्दी Bahasa Indonesia 日本語 한국어 Português 中文

Computing/SoftwareInternet Technology

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кнопку «Спасибо» под видео. Как всегда, спасибо за просмотр, и до встречи в следующем выпуске.

Key Takeaway

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

Highlights

Графовая инженерия параллелит задачи между специализированными ИИ-агентами, повышая скорость работы, но расходует значительно больше токенов по сравнению с одиночными циклами.
Главная проблема графовых систем — каскадирование ошибок: одна невыявленная погрешность в отдельном узле искажает итоговый результат всего графа.
Модель Claude Haiku генерирует множество ложноположительных замечаний при проведении код-ревью, в то время как Opus учитывает контекст и отсеивает ложные срабатывания.
Использование урезанного браузера Chrome Headless Shell вместо стандартного Chrome или Puppeteer ускоряет визуальную верификацию интерфейсов ИИ-агентами.
Инструмент «second opinion» запускает изолированную фоновую сессию Claude через флаг `-p` без контекста текущего чата для получения объективной оценки кода.
Оптимальная архитектура верификации графа строится на оркестраторе, который параллельно вызывает специализированные навыки проверки (simplify, verify, design review) и сводит их в единый отчет.

Timeline

Эволюция от инженерии циклов к графовой инженерии

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

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

Анатомия графов и базовые топологии

Любой граф состоит из узлов (изолированных подзадач агентов) и ребер (маршрутов передачи данных).
Топология «fan-in at a barrier» задерживает дальнейшее выполнение до получения отчетов от всех параллельных узлов.
Результативность любой графовой структуры напрямую зависит от этапа верификации на узлах.

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

Инструменты проверки и критическая роль выбора модели

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

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

Типы навыков верификации и визуальное тестирование

Автономные навыки верификации запускаются вручную по завершении проекта для предотвращения лишнего расхода токенов.
Встроенные навыки срабатывают автоматически внутри рабочего процесса после реализации каждой отдельной фичи.
Замена Chrome или Playwright на Chrome Headless Shell ускоряет визуальное скриншотное тестирование компонентов.

Глубокие автономные проверки (например, многовекторный анализ безопасности) целесообразно выполнять один раз на финише, а не при каждом промежуточном прогоне. Встроенные навыки проверяют сквозную работоспособность функционала непосредственно в ходе разработки. Использование Chrome Headless Shell в навыках проверки позволяет агентам визуально оценивать UI через скриншоты без накладных расходов полновесного браузера.

Метод «второго мнения» и оркестрация стека навыков

Флаг `-p` поднимает изолированную фоновую сессию Claude без контекста автора кода для получения объективной оценки.
Объединение узкоспециализированных навыков (simplify, verify, design review) дает более точный результат, чем один универсальный промпт.
Верхнеуровневый навык-оркестратор параллельно распределяет задачи проверки и формирует сводный отчет для агентов-исправителей.

Агент-создатель не способен объективно проверить собственный код из-за замусоренного контекста, поэтому метод «second opinion» вызывает независимую сессию на модели Opus. Чтобы не перегружать контекст одной проверки, задачи разделяют по отдельным узкопрофильным навыкам. Оркестратор запускает эти навыки параллельно в разных контекстных окнах, агрегирует найденные проблемы и передает единый массив задач узлам, отвечающим за исправления.

Community Posts

Write about this video