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

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

Делиться

1. Почему один разум терпит неудачу

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

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

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

Всё это было реальным прогрессом. Но у каждого инструмента по-прежнему оставался тот же структурный потолок.

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

Компания Anthropic выявила три типа сбоев, которые постоянно возникают, когда одно контекстное окно — будь то окно, принадлежащее одному агенту или руководителю, координирующему работу небольшой команды, — отвечает за задачу, слишком большую для четкого отслеживания. Именно здесь проявляются три распространенных типа сбоев (рис. 1).

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

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

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

Это не ошибки. Это то, что происходит, когда план — это всего лишь мысль, а мысль деградирует.

В начале 2026 года, когда Джарреду Самнеру, создателю Bun, потребовалось пошагово перенести около 750 000 строк кода Zig на Rust, стало трудно игнорировать затраты. Раньше подобная задача занимала у команды месяцы. Схема Самнера была проста: выполнить один блок работы, провести состязательную проверку, а затем применить изменения. Позже он назвал динамические рабочие процессы «современным методом надежного использования агентов для выполнения средних и крупных проектов». Результат: 750 000 строк кода на Rust, 99,8% существующего набора тестов пройдены, и всего 11 дней от первого коммита до слияния.

Главная идея заключается в том, что Клоду не нужно держать весь план в голове. Рабочий процесс переносит план в код . Скрипт содержит цикл, ветви и промежуточные результаты. Клоду нужно обрабатывать только текущий шаг и окончательный синтез. План становится файлом JavaScript. Он не забывает, не отклоняется от намеченного пути и не останавливается на полпути, объявляя работу выполненной.

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

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

2. Что такое динамический рабочий процесс?

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

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

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

Ключевое слово здесь — «шаблон» . Шаговый механизм — это основа модели: часть, которая определяет, как задача планируется, разделяется, проверяется и выполняется. Стандартный шаговый механизм Claude Code создан в основном для задач программирования. Команда Anthropic обнаружила, что такие динамические шаговые механизмы «иногда даже более полезны для нетехнической работы». Затем они создали его на месте, сформировав его под заданную задачу.

Прежде чем продолжить, полезно отделить понятие рабочего процесса от нескольких других слов, которые часто путают. Инструменты, агенты, средства обеспечения и рабочие процессы часто используются как одно и то же. Это не так. Самый простой способ разделить их — я заимствую эту формулировку у AlphaSignal — это задать один вопрос: у кого есть план? (Рисунок 2)

• Субагент — это помощник, которого главный Клод отправляет для выполнения конкретной задачи. План остается за главным Клодом. Субагент выполняет свою часть работы, отправляет результат обратно, и этот результат отображается в вашем чате. В основном это принцип «запустил и забыл». Как показано в таблице ниже, субагент не может создавать своих собственных помощников или общаться с другими субагентами.
• Команда агентов — это совсем другое. Это группа Клодов, работающих бок о бок, координирующих свои действия как коллеги. План не хранится внутри одного Клода. Он существует между ними. Они могут обмениваться сообщениями, корректировать его по мере выполнения работы и продолжать работу над одной большой общей задачей. Это больше похоже на поручение проекта небольшой команде.
• Динамический рабочий процесс — это совсем другое дело. Клод пишет небольшую программу на JavaScript для выполнения самой задачи. В этом случае план хранится в коде. Агенты выполняют свою работу в фоновом режиме, их результаты сохраняются в переменных, и только окончательный объединенный ответ возвращается вам.

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

И вы можете задать ещё один вопрос. Что такое динамический? В чём разница между динамическим и статическим ?

Вы всегда можете собрать систему самостоятельно. Вы можете подключить Agent SDK или запустить claude -p в цикле и создать фиксированную систему, которую будете использовать снова и снова. Это статическая система : полезная, воспроизводимая, но разработанная заранее.

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

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

Теперь Клод способен создавать динамические рабочие процессы, поскольку Opus 4.8 теперь достаточно функционален, чтобы создавать подходящий шаблон на лету — как заявила команда Anthropic, «достаточно интеллектуален, чтобы написать пользовательский шаблон, специально разработанный для вашего конкретного случая».

3. Настоящее испытание

3.1 Шаблоны, которые делают динамические рабочие процессы полезными

Anthropic предлагает 6 рабочих процессов, и я провел несколько тестов, чтобы наглядно показать вам, как они работают. Вот они:

• Разделение и синтез — сначала разделение работы, затем её объединение. Каждому фрагменту присваивается свой собственный элемент и чёткий контекст; финальный синтезатор ожидает завершения всех фрагментов, прежде чем объединить результаты.
• Противоположная проверка — для каждого результата создается отдельный агент, единственная задача которого — опровергнуть его. Скептик, проверяющий оптимиста.
• Классификация и обработка — использование агента-классификатора для предварительной сортировки каждого элемента, а затем направление его соответствующему обработчику. Стойка регистрации.
• Метод генерации и фильтрации : проведите широкий мозговой штурм, затем отфильтруйте по заданной схеме: удалите дубликаты, проверьте, оставьте только то, что выдержало проверку.
• Турнир — создайте N агентов, каждый из которых пытается выполнить одно и то же задание по-разному, затем пусть агент-судья сравнит их попарно, пока один из них не победит. Хорошо подходит для придания игре вкуса и названий.
• Цикл до завершения — для задач неизвестного размера запускайте агентов до тех пор, пока не будет выполнено условие остановки (нет новых результатов, нет ошибок), а не до фиксированного числа проходов.

Вероятно, наиболее распространенным является подход «разделение и синтез» . Одна задача разделяется на несколько задач, каждая из которых имеет свой собственный чистый контекст , чтобы исключить взаимное влияние, а затем этап синтеза — этап, который ожидает завершения работы всех участников — объединяет их результаты в один (Рисунок 3).

А также еще одним распространенным методом является состязательная проверка (рис. 4).

3.2 Динамический рабочий процесс при решении нетехнических проблем

Самый быстрый способ понять динамические рабочие процессы — это применить один из них к задаче, не имеющей никакого отношения к программированию.

Итак, я дал Клоду простой бизнес-план для модели подписки на услуги ресторана и попросил его проанализировать эту идею сразу с трех враждебных сторон: инвестора, избегающего рисков, требовательного клиента и действующего конкурента. Каждый агент работал независимо. Затем финальный анализ объединил результаты и выдал три самых сильных возражения, а также варианты ответов на них.

Вот ускоренная версия этого заезда (Рисунок 5):

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

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

Вот ответы:

1. Инвестор раскритиковал расчеты : экономические показатели слишком слабы, чтобы выдержать отток клиентов. При цене 29 долларов в месяц и марже около 40% продукт приносит всего около 11,60 долларов валовой прибыли с каждого клиента в месяц. При стоимости привлечения клиента в 35 долларов бизнесу необходимо, чтобы клиенты оставались достаточно долго, чтобы пожизненная ценность клиента явно превосходила стоимость привлечения. Но подписки на еду обычно сталкиваются с оттоком, и один слабый месяц удержания может поставить модель под угрозу. Решение: исправить экономику единицы продукции, прежде чем масштабировать: увеличить доход на пользователя за счет годовых планов или дополнительных услуг, доказать низкий отток когорт и явно смоделировать соотношение LTV к CAC.
2. Клиент раскритиковал ценность предложения : в презентации слишком много внимания уделялось таким идеям, как меняющееся меню и доставка с нулевым выбросом углерода. В презентации это может звучать хорошо, но это может быть не то, что больше всего волнует клиентов при выборе ужина. Большинство клиентов хотят скорости, гибкости и меньшего количества ежедневных решений. Решение: сделать ценность более практичной: начать с экономии времени, удобства и того, как услуга упрощает приготовление ужина в будние дни.
3. Конкурент атаковал защитный барьер : вращающееся меню и углеродно-нейтральная доставка могут быть быстро скопированы. Ни то, ни другое не приводит к значительным затратам на переход к другому сервису. Более крупный конкурент мог бы имитировать поверхностные функции, снизить цену или интегрировать предложение в существующую сеть доставки. Решение: создать более сильный защитный барьер: плотность логистики в каждом городе, персонализация, бонусы за переход или привычки, которые затрудняют замену сервиса.

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

3.3 Включение динамических рабочих процессов

Настройка проста. Вы переключаете модель на Opus 4.8 (я объясню это позже) и запускаете рабочий процесс одним из трех способов. Самый надежный способ — просто ввести слово workflow в командную строку . Другой способ — установить значение ultracode , что включает в себя сверхвысокий уровень логического мышления и позволяет Клоду самостоятельно решать, создавать ли рабочий процесс. Однако будьте осторожны с ultracode — он стоит больше токенов, поэтому используйте его, когда вам нужна автоматическая оркестровка.

Третий вариант можно запустить, если у вас уже был хорошо отлаженный рабочий процесс, и его можно запустить снова через / . Есть два места сохранения: .claude/workflows/ (общедоступный для проекта; доступен всем, кто клонировал репозиторий) ~/.claude/workflows/ (для личного использования; доступен для всех проектов, но только для вас).

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

3.4 Давайте проверим их

3.4.1 Подход по умолчанию

Цель: я использую многофайловый репозиторий и прошу Клода запустить рабочие процессы для проверки этого репозитория с помощью алгоритмов Fan-out-and-synthesize и Adversarial verification.

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

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

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

Внутри /workflows (Рисунок 7) работают 6 агентов, и плохо то, что все они используют Opus 4.8 и потребляют примерно по 50 000 токенов каждый. Мой кошелек скоро опустеет.

Через 2 минуты поисковые системы завершили свою работу и обнаружили 50 потенциальных проблем (Рисунок 8). В результате для каждой проблемы необходимо запустить 50 проверочных агентов, чтобы проверить, является ли проблема реальной или просто ложным срабатыванием. Все они используют Opus 4.8.

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

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

3.4.2 Более дешевая модель для агентов

Ещё одна попытка, где Sonnet выступает в роли агентов, а Opus — в роли оркестратора и синтезатора.

Задача: провести аудит репозитория с помощью рабочего процесса: распределить средства поиска и проверить каждое обнаруженное нарушение, составить отчет с ранжированием по степени серьезности. Использовать 200 тыс. токенов . Использовать Sonnet для всех агентов и Opus в качестве оркестратора и синтезатора.

На рисунке 9 Клод предоставил 7 агентам поиска Sonnet 4.6 и потратил 254 000 токенов на поиск 71 потенциальной проблемы, что заняло почти 5 минут 17 секунд . Sonnet определенно работает дольше, чем Opus.

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

Процесс проверки 71 проблемы потребляет примерно 1,5 миллиона токенов. Это значительно дешевле, чем в Opus, но время выполнения для агентов поиска значительно дольше.

Вот результат работы синтезатора (Opus 4.8), показанный на рисунке 11.

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

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

3.4.3 Перед запуском пересмотрите рабочий процесс.

Задача: провести аудит репозитория с помощью рабочего процесса: распределить средства поиска и проверить каждое обнаруженное нарушение, составить отчет по степени серьезности. Использовать 200 тыс. токенов n. Использовать Sonnet для всех агентов и Opus в качестве оркестратора и синтезатора . Напишите рабочий процесс и предоставьте ссылку для доступа и редактирования перед запуском.

Отлично. Клод предоставляет мне скрипт рабочего процесса для проверки и редактирования, прежде чем дать Клоду команду запустить его (просто run the workflow ) (Рисунок 12).

Для демонстрации компонентов файла рабочего процесса JavaScript на рисунке 13 я использовал более короткий код и более простую подсказку.

Вот область, которую я хочу пересмотреть для своего тестового кода:

 { key: 'correctness', prompt: `Audit for CORRECTNESS / LOGIC bugs. Focus: the deterministic date-based daily pick, shuffle behavior, the "last 5 worn excluded" history logic (off-by-one, wraparound, per-wardrobe isolation), wardrobe-gender switching, 2-piece/3-piece filter, theme auto-switch by hour (6am-6pm boundaries), localStorage key handling. Trace edge cases (empty male wardrobe, all outfits recently worn). Read app.js and collection.js.`, }, { key: 'docs-accuracy', prompt: `Audit DOCUMENTATION ACCURACY. Compare README.md and docs/*.md claims against actual code behavior. Focus: features described that don't match implementation, wrong localStorage keys, stale config, deployment steps that won't work, outdated counts ("all 40 outfits"). Read README.md, docs/codebase-summary.md, docs/deployment-guide.md, then verify against the code.`, },

Я удалил: shuffle behavior, theme auto-switch by hour (6am-6pm boundaries).Trace edge cases (empty male wardrobe, all outfits recently worn) и всю 'docs-accuracy' . Я также проверил другие места в файле js, чтобы убедиться, что указанные выше пункты удалены.

Вы также можете попросить Клода исключить это, но это несложно, поэтому я предпочитаю сделать это сам.

Таким образом, из 7 аспектов, которые будут искать агенты, их количество сокращается до 6, а один аспект имеет меньший охват (Рисунок 14).

Шесть агентов-поисковиков обнаружили 44 различных потенциальных проблемы и подтвердили 40 из них . Весь процесс, в котором участвовало 51 агент, занял 9 минут и 52 секунды и потребовал около 1,66 миллиона токенов.

3.4.4 Сравнение с работой одного агента.

Я запустил тот же код с одним агентом за один проход , без команды и проверки. Он обнаружил 47 проблем — больше, чем в рабочем процессе (44) — в трети токенов. Однако, поскольку проверка не проводилась, среди этих 47 проблем оказались те же 2 ошибки, которые агенты-верификаторы в рабочем процессе обнаружили и удалили. Для удобства сравнения я показываю различия на диаграмме ниже (Рисунок 15).

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

4. Когда использовать рабочий процесс

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

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

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

• Следующий сигнал — необходимость проверки задачи . В некоторых случаях неправильный ответ обходится дорого. Не стоит двигаться дальше, основываясь на слабом выводе о безопасности, ложном сообщении об ошибке или рискованном плане миграции. Для таких задач может быть целесообразно использовать дополнительных агентов для перекрестной проверки результата, прежде чем ему можно будет доверять. Но проверка не бесплатна. Больше агентов означает больше токенов и больше времени. Поэтому задача действительно заслуживает такого уровня проверки. Не стоит запускать пять агентов только потому, что вы недавно услышали от генерального директора компании, занимающейся технологиями в области ИИ, что больше токенов означает больше денег.

• Последний признак — детерминированность задачи . Рабочий процесс использует код для вызова агентов в фиксированной структуре. Поэтому, если задача имеет четкую форму и может быть разбита на известные шаги, рабочий процесс работает хорошо. Но если задача требует, чтобы агент принимал решение о дальнейших действиях во время выполнения, то рабочий процесс, вероятно, не является подходящим инструментом. Полезно рассматривать это с точки зрения того, является ли задача широкой или глубокой . Широкую задачу можно разбить на множество более мелких задач, которые выполняются одновременно. Именно здесь рабочие процессы проявляют свои преимущества. Они вызывают несколько агентов параллельно, позволяют каждому работать над своей частью, а затем объединяют результаты. Глубокая задача выполняется шаг за шагом. Каждый шаг зависит от того, что произошло до него. Для такого типа задач обычно лучше подходит команда цели. Она обрабатывает одну задачу за раз и продолжает двигаться вперед, вместо того чтобы пытаться выполнять множество действий параллельно.

5. Можно ли экономически выгодно использовать динамический рабочий процесс?

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

Удивительно, но рабочий процесс завершился примерно за 7,5 минут — с участием 37 агентов. Было использовано 37 агентов и 1,35 миллиона токенов. Было обнаружено 23 потенциальных проблемы, что значительно меньше, чем в случае с Sonnet, описанном выше, и все 23 прошли проверку.

Однако история с затратами оказалась не такой простой, как «более дешевая модель, более дешевый рабочий процесс». Haiku обнаружила всего 23 проблемы при использовании 1,35 миллиона токенов. Версия Sonnet обнаружила 40 проблем при использовании 1,66 миллиона токенов. Таким образом, хотя Haiku дешевле в пересчете на токен, эффективность использования токенов оказалась хуже . Для выполнения той же аналитической работы требовалось больше итераций, и каждая дополнительная итерация означала повторное прочтение большего объема контекста. Вывод прост: меньшая модель не обязательно дешевле на практике. Если для проработки задачи требуется больше шагов, ее ценовое преимущество может быть очень быстро нивелировано.

Стоимость одного токена в Haiku примерно в три раза ниже, чем в Sonnet . На бумаге это выглядит как явная победа. Но в этом тесте Haiku использовал примерно в 1,5 раза больше токенов. Эти два показателя практически компенсируют друг друга. В итоге, стоимость разветвления кода в Haiku оказалась примерно такой же, как в Sonnet , возможно, примерно на 10% дешевле, и лишь немного быстрее в реальном времени. Поэтому правило «просто направляйте все на самую маленькую модель» не является надежным. Меньшая модель может потерять свое ценовое преимущество, если ей потребуется больше токенов для выполнения задачи.

Ещё одно замечание о качестве, которое, на мой взгляд, довольно важно. В обеих версиях было выявлено 14 проблем. Это довольно неожиданно и говорит о том, что агенты действительно выполняли полезную работу, когда были изолированы друг от друга. Однако были также 2 проблемы, по которым версии расходились. Удивительно, но Хайку оказался прав в обеих версиях, а Соннет — нет. Это не показывает, какая из моделей лучше, а скорее говорит о том, что модель не работает на 100% стабильно, как ожидалось. Одна из причин заключается в том, что я дал Клоду расплывчатую и общую подсказку. Поэтому вместо этого я проведу тестирование с более конкретным аспектом.

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

Как прошёл показ хайку :

• 15 агентов, ~572 тыс. токенов субагентов, ~3,5 мин времени.
• 5. Поиск хайку → Верификаторы, противодействующие хайку → Синтезатор Opus
• 9 исходных результатов → 3 подтверждены, 6 опровергнуты. Все «высокие» оценки были удалены.

А для агентов Sonnet :

• 23 агента, ~1,3 млн токенов за оба прохода. ~2,51 мин.
• 5. Поиск сонетов → Противоположные верификаторы сонетов → Синтезатор опусов
• 18 исходных результатов → 13 подтверждены, 5 отклонены → разделены на 8 отдельных вопросов. Критически важных/высокоэффективных состязательных проверок не проводилось.

Важная деталь: все 3 проблемы, подтвержденные в ходе тестирования Haiku, были обнаружены и в ходе тестирования Sonnet. Это более последовательно, чем в предыдущем тесте. Одна из возможных причин заключается в том, что на этот раз задание дало агентам конкретный ракурс для исследования, вместо того чтобы просить их рассматривать всю систему с широкой точки зрения. Это логично. В рабочем процессе участвовали 5 агентов, и каждый агент сосредоточился только на одном аспекте безопасности. Поскольку область исследования была уже, агенты могли глубже изучать один и тот же тип проблемы, вместо того чтобы распылять свое внимание на слишком много возможных категорий проблем. Когда агенту не приходится расставлять приоритеты в широком диапазоне, он естественным образом тратит больше своего логического бюджета на конкретную поставленную перед ним задачу — и это приводит к более тщательным и воспроизводимым результатам.

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

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

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

Если рабочий процесс сработал хорошо и вы хотите использовать его повторно, нажмите клавишу S в меню рабочего процесса, чтобы сохранить его в ~/.claude/workflows . Вы также можете переместить скрипт в навык, если цель состоит в том, чтобы поделиться методом со своей командой и упростить его повторное использование в аналогичных задачах.

Но не стоит сохранять рабочий процесс только потому, что первый запуск прошел успешно. Успешный запуск лишь доказывает, что все сработало один раз. Сохраняйте его, когда сама оркестровка становится ценной: когда скрипт проще проверить, повторно использовать и улучшить, чем заново писать обычный код Claude Code с нуля.

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

Проведите стресс-тест плана: «Возьмите приведенный ниже план и запустите рабочий процесс, в котором разные агенты — скептически настроенный инвестор, привередливый клиент, действующий конкурент — независимо друг от друга. Затем выделите три наиболее острых возражения и наиболее убедительный ответ на каждое из них».

Проверка репозитория: «Запустите рабочий процесс для проверки этого репозитория. Распределите агентов для обнаружения логических ошибок, небезопасных маршрутов, слабой аутентификации, отсутствующей авторизации, раскрытых секретов, рискованных зависимостей и утечек данных. Для каждого обнаруженного нарушения запустите отдельный агент для его проверки злоумышленниками — попытайтесь доказать, что это не так. Составьте отчет с ранжированием по степени серьезности, указав пути к файлам и исправления. use 200k tokens ».

Сделайте это дёшево: «Создайте систему так, чтобы агенты поиска работали на model: 'haiku' в то время как оркестратор остаётся на Opus 4.8 и выполняет окончательный синтез. Сообщайте о токенах и времени выполнения».

Воспроизведите нестабильный тест: «Этот тест проваливается примерно в 1 из 50 запусков. Настройте рабочий процесс для его воспроизведения — сформулируйте теории и проверьте их в рабочих деревьях. /goal не останавливаться, пока хотя бы одна теория не сработает».

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

Ранжирование по реальному приоритету (турнир): «У меня есть список результатов/вариантов. Используйте алгоритм для их ранжирования по [реальной возможности применения / влиянию / чему-либо еще, что имеет значение] — но вместо того, чтобы оценивать каждый вариант, проведите парный турнир и ранжируйте по победителям. Затем покажите мне три лучших варианта и объясните почему».

Выявление первопричины ошибки Хайзенбага: «Эта ошибка возникает периодически, и очевидная причина выглядит неправильно. Используйте рабочий процесс: разделите расследование по признакам — один агент занимается симптомами, другой — кодом, третий — данными/журналами — затем пусть отдельные агенты попытаются опровергнуть каждую теорию и выявят оставшуюся причину».

Безопасная сортировка невыполненных задач: «Используйте рабочий процесс для сортировки невыполненных задач: классифицируйте каждый элемент (исправить немедленно / передать на рассмотрение вышестоящим инстанциям / требует принятия решения), удалите дубликаты и распределите их по группам. Все, что считывает ненадежные входные данные, должно быть доступно только для чтения — держите его отдельно от любых предложений по изменениям».

Маршрутизация по форме задачи: «Используйте рабочий процесс с классификатором, который анализирует каждую задачу и направляет ее к наиболее экономичной и подходящей модели — небольшие модели для механических работ, Opus для неоднозначных, критически важных с точки зрения безопасности рассуждений — а затем запускает каждую задачу на выбранной модели».

Проверьте внутренние правила: «Используйте рабочий процесс для проверки этого кода на соответствие нашим правилам в файле CLAUDE.md — один проверяющий на каждое правило, плюс скептик, который ищет ложные срабатывания. Мне важнее не поднимать ложную тревогу, чем выявлять каждую мелочь».

Источники

1. Тарик Шихипар и Сид Бидасария (Anthropic), «Подход к каждой задаче: динамические рабочие процессы в Claude Code» — почему, шаблоны, подсказки, сохранить/поделиться.
2. Factory.ai, «Проблема контекстного окна: масштабирование агентов за пределами ограничений по количеству токенов».
3. Инженерный отдел в компании Anthropic, тема: «Эффективное проектирование контекста для агентов искусственного интеллекта».
4. Технический отчет Chroma, «Разрушение контекста: как увеличение количества входных токенов влияет на производительность LLM»
5. Anthropic, «Создание эффективных агентов» — справочная информация об основных моделях организации работы.
6. Anthropic, «Введение в динамические рабочие процессы в Claude Code».

Чиен Ву Минь: посмотреть все из Чиен Ву Минь

Источник: towardsdatascience.com