Примеры из практики · Учебное пособие 10
Постройте и проверьте динамический рабочий процесс Claude Code
Превратите крупную задачу Claude Code в независимых работников, выполните преднамеренное слияние и отдельный этап проверки без создания дорогой стаи агентов.

0 из 14 завершено
Проверено по исходникам и обновлено: 10 августа 2026 года. Поведение рабочего процесса и элементы управления в этом руководстве были проверены с учетом публикации о запуске компании Anthropic и документации рабочего процесса Claude Code.
К концу этого руководства у вас будет небольшой рабочий процесс с разветвлением, структурированный договор слияния, отдельный шаг проверки и запись выполнения, содержащая источники, ошибки, затраченное время и стоимость токенов.
Самая полезная идея в широко обсуждаемой теме «Graph Engineering with Claude» также является наименее эффектной: многоступенчатый агент автоматически не становится рабочим процессом.
Если задача B не нуждается в результате задачи A, заставлять B ждать — это потеря времени. Если нескольким агентам нужно проверять разные файлы, источники или маршруты, им не следует по очереди работать в одном и все более загромождаемом чате. Некоторые части работы зависят друг от друга, некоторые можно выполнять параллельно, а некоторые требуют проверки перед тем, как им можно доверять.
Anthropic теперь придает этой форме конкретное воплощение в Claude Code. Динамические рабочие процессы позволяют Claude написать сценарий оркестровки на JavaScript для задачи, запускать множество подагентов в фоновом режиме, проверять результаты и возвращать скоординированный результат. Функция доступна в Claude Code версии 2.1.154 и выше на платных планах, а также через API Anthropic и на нескольких облачных платформах.
Это делает «инженерию графов» скорее практическим навыком, чем грандиозным новым названием: решать, что может выполняться одновременно, что действительно требует результата на предыдущем этапе, где объединять работу и как не допустить, чтобы ошибка дошла до окончательного ответа.
Переход происходит от последовательного чата к графу работы.
Линейная задача агента выглядит знакомо:
- Прочитать файл A.
- Прочитать файл B.
- Прочитать файл C.
- Составить сводку.
Это нормально, если каждый шаг требует предыдущего. Это плохой дизайн, когда файлы независимы. Более подходящая форма — разветвление: один работник на каждый файл, затем объединение, которое ранжирует, удаляет дубликаты и проверяет результаты.
маршрут обзора A ─┐
маршрут обзора B ─┼─> объединить и удалить дубликаты ─> проверить ─> отчет
маршрут обзора C ─┘
Коробки — это задачи. Стрелки — это данные, которые одна задача получает от другой. Это различие важно, потому что оно выявляет фиктивные зависимости. «Проверьте документацию и посмотрите трекер задач» не является последовательностью, если одна из этих задач не требует результата другой. Они могут начинаться одновременно.
Документация по рабочим процессам Anthropic делает то же архитектурное различие. Обычные субагенты, навыки и команды агентов хранят промежуточную работу в контексте модели или в общем списке задач. Динамический рабочий процесс помещает план, циклы, ветвления и промежуточные результаты в сценарий, оставляя основной разговор для получения результата вместо потока необработанной работы.
Как Claude Code выполняет рабочий процесс
Когда вы просите Claude Code «использовать рабочий процесс» или включить ultracode ключевое слово, Клод планирует задачу и пишет скрипт оркестровки. Во время выполнения она исполняется в фоне, а основная сессия остаётся доступной. Вы можете проверить запланированные этапы перед запуском, следить за прогрессом в /workflows, приостанавливать или останавливать выполнение, а также сохранять успешный рабочий процесс для последующего использования.
Задокументированные примеры специально практичные:
- проверить многие обработчики маршрутов на отсутствие аутентификации, затем противодействующим образом проверить каждое выявленное нарушение;
- перенести большой набор компонентов в изолированные копии, чтобы параллельные изменения не конфликтовали;
- просмотреть каждый изменённый файл, затем объединить и оценить результаты;
- исследовать вопрос по разным источникам, перепроверить утверждения и составить ссылающийся отчёт;
- повторять поиск или тестовый прогон до тех пор, пока последовательные раунды не перестанут находить что-либо новое.
Встроенный /deep-research рабочий процесс является самым наглядным примером без кода. Он распределяет веб-поиск по разным направлениям, извлекает и перекрёстно проверяет найденное, голосует по утверждениям и возвращает отчет с цитатами. Claude Code также документирует важный режим отказа: когда проверяющий не может проверить утверждение из-за ограничения скорости или ошибки API, отчет помечает его непроверенный вместо того, чтобы считать его опровергнутым.
Почему граф полезен
В теме это называют «инженерным графом», но базовая дисциплина знакома всем, кто когда-либо разрабатывал систему сборки, конвейер данных или распределённую очередь заданий.
Каждый работник нуждается в узкой задаче и чёткой форме результата. «Проверьте этот маршрут на наличие пробелов в аутентификации и предоставьте ранжированный список с указанием файла, строки, доказательства и уровня уверенности» — это работоспособный контракт. «Осмотритесь и скажите, что кажется неправильным» — нет. Чёткие результаты позволяют на следующем этапе сравнивать результаты без необходимости привлекать другого агента для расшифровки текста.
Этап объединения заслуживает не меньшего внимания. Иногда это простое кодирование: объединение результатов, удаление дублирующихся пар файл-и-строка, отбрасывание пустых ответов и сортировка по степени серьёзности. Тратить вызов модели на такую «трубу» добавляет расходов и создаёт ещё одну возможность для ошибок. Сохраняйте суждение агента для работы, где оно реально необходимо, например, при решении, описывают ли два слегка различных отчёта одну и ту же проблему безопасности.
Затем добавьте реальную проверку. Второй агент может попытаться воспроизвести заявленную ошибку, проверить, подтверждает ли источник вывод, или рассмотреть предложенную миграцию с другой стороны. Anthropic утверждает, что рабочие процессы могут использовать независимые попытки и противников до публикации результатов. Это не гарантирует корректность, но гораздо лучше, чем давать первому ответу одного работника полномочия итогового отчёта.
Крупные рабочие места создают проблемы с координацией
Работы крупных агентов обычно проваливаются двумя предсказуемыми способами. Первый — это давление контекста: один разговор накапливает исходный текст, выход инструмента, частичные выводы и детали реализации, пока не теряет поток. Второй — это давление на координацию: агент должен помнить, какие задачи находятся в ожидании, какие не сработали, какие результаты пересекаются, а что ещё нужно проверить.
Динамические рабочие процессы решают обе задачи, помещая координацию в сценарий. Документация Claude говорит, что рабочий процесс может масштабироваться от десятков до сотен агентов в одном запуске, при этом результаты хранятся в переменных сценария, а не в основном окне контекста. Anthropic также указывает, что прогресс сохраняется, поэтому прерванные запуски могут быть возобновлены в той же сессии.
Это не означает, что каждая задача должна превращаться в флот. Anthropic предупреждает, что рабочие процессы могут использовать существенно больше токенов, чем обычная сессия Claude Code. Они также занимают больше времени, чем простой запрос, потому что системе нужно планировать, распределять работу, ждать соответствующих слияний и проверять их.
Перед добавлением большего числа агентов спросите себя, смогут ли независимые работники дать лучший ответ быстрее и с проверкой, которой можно доверять.
Начните с одной полезной формы
Для большинства команд первый рабочий процесс должен быть достаточно небольшим, чтобы его можно было проверить. Проверка каждого маршрута API на отсутствие аутентификации является лучшей отправной точкой, чем автономная перепись всей кодовой базы.
Используйте этот запрос в Claude Code:
используйте рабочий процесс для аудита каждого обработчика маршрутов в src/routes/ на наличие отсутствующих проверок аутентификации.
Запустите одного проверяющего на каждый файл, враждебно проверьте каждое потенциальное обнаружение, затем верните один ранжированный отчет с доказательствами.
Этот запрос указывает, что может разветвляться, что должно происходить после слияния и что должен содержать окончательный ответ. Он достаточно специфичен, чтобы Claude могла построить разумную схему без необходимости вручную писать код оркестрации.
Если рабочий процесс окажется полезным, сохраните его из /workflows с s. Claude Code может сохранить его в .claude/workflows/ для репозитория или в вашей личной конфигурации Claude. Сохранённый скрипт становится повторяемой командой, а не впечатляющей одноразовой подсказкой.
Превратите один рабочий процесс в доказательство портфолио
Не создавайте огромную систему агентов лишь для демонстрации оркестрации. Выберите результат, который клиент или коллега уже понимает:
| Проект | Готовый результат | Доказательство для хранения | Кто может это оценить |
|---|---|---|---|
| Аудит репозитория | Ранжированные результаты с указанием файла, строки, доказательств и степени серьёзности | Проверки воспроизводимости и ложные срабатывания удалены | Небольшая команда, готовящая выпуск |
| Краткий исследовательский отчёт | Короткий цитируемый ответ на один бизнес-вопрос | Журнал источников и необоснованные утверждения отмечены | Оператору, которому требуется еженедельный информационный отчет для принятия решения |
| План миграции | Инвентаризация компонентов, порядок зависимостей, риски и план тестирования | Пример миграции и успешное прохождение проверок | Команда, оценивающая изменение в фреймворке или системе дизайна |
Запустите рабочий процесс один раз на вашем собственном материале. Запишите граф, контракты подсказок, стоимость модели и токенов, затраченное время, ошибки проверки и ручной обзор. Работа становится коммерчески интересной, когда она производит проверенный результат быстрее или стабильнее, чем старый процесс.
Самый маленький оплачиваемый тест — это поставка с фиксированным объемом для одного реального заказчика. Согласуйте вопрос, стандарт доказательств, формат, срок и что находится за пределами объема. Взимайте плату за проверенный аудит или отчет. «Рой» агентов — это деталь реализации, а не продукт.
Где люди ошибаются
Тема справедливо пытается оттолкнуть людей от прямых линий. Она заходит слишком далеко, когда делает так, что каждая последовательность кажется ошибкой.
Некоторые задачи действительно последовательны. Нельзя проверить миграцию до того, как она существует. Нельзя сделать обоснованный синтез, не собрав материала, с которым он должен сравниваться. Не следует позволять нескольким агентам одновременно редактировать одни и те же файлы без изоляции и плана слияния.
Параллельная работа также требует ограниченного объема. Сотня неопределенных работников может создать сотню версий одного и того же слабого утверждения. Больше агентов усиливают плохое определение задачи так же эффективно, как они усиливают полезное покрытие.
Рабочее правило:
- распределяйте независимую работу;
- объединяйте только когда этап требует полного набора;
- используйте обычный код для детерминированной очистки;
- проверяйте утверждения перед их публикацией или отправкой;
- останавливайтесь, когда задача становится достаточно маленькой, что затраты на оркестрацию превышают экономию.
Динамические рабочие процессы полезны, потому что они превращают запутанное, длительное задание в видимый план, который разработчики могут изучать, повторно запускать и улучшать. Количество агентов вторично.