Редакторська примітка: Claude Code перетворюється з допоміжного інструменту для коду в налаштовуваний робочий стіл агента.

Наведені в цій статті робочі процеси мають ключову цінність у тому, що дозволяють Claude більше не обмежуватися «думанням, а потім дією» в межах одного вікна контексту, а натомість динамічно створювати виконавчу структуру: розбивати завдання, розподіляти підагенти, обробляти паралельно, проводити взаємну перевірку, циклічно ітерувати та навіть змушувати різні агенти конкурувати між собою, а потім інтегрувати результати.

Це означає, що сценарії використання Claude Code активно розширюються. Він підходить не лише для міграції коду, рефакторингу, відтворення тестів та перевірки коду, але й для глибоких досліджень, перевірки фактів, відбору резюме, аналізу інцидентів, формалізації правил, оцінки бізнес-планів, мозкового штурму назв та інших нетехнічних завдань. Багато складних робіт за суттю схожі на програмування: вони вимагають розбиття проблеми на частини, ізоляції контексту, перевірки гіпотез, роботи з великою кількістю деталей та вибору між кількома альтернативними шляхами.

Динамічні робочі процеси призначені для вирішення кількох поширених проблем великих моделей під час довгих завдань: «ленівість агента», коли він оголошує про завершення завдання напіввиконаним; «самоусамовіддана упередженість», коли він схильний підтверджувати власні висновки; та «зсув мети», коли після кількох ітерацій він поступово відхиляється від початкової мети. Передаючи завдання кільком Claude з окремими контекстами, цей підхід перетворює складне завдання з «одиночного марафону агента» на «спільну роботу кількох агентів».

Звичайно, workflows не є універсальним рішенням. Вони зазвичай витрачають більше токенів і не завжди підходять для кожного звичайного завдання програмування. Але вони вказують на важливий напрямок: майбутня конкуренція між AI-інструментами може полягати не лише в тому, наскільки розумним є окрема модель, а в тому, чи здатна вона організувати надійний, повторно використовуваний та перевіряємий процес виконання для складних цілей.

Нижче наведено оригінал:

Хоча стандартна виконавча рамка Claude Code була розроблена для програмування, вона також підходить для багатьох інших типів завдань. Виявляється, що багато завдань структурно схожі на завдання програмування. Однак для досягнення оптимальної продуктивності деяких конкретних типів завдань, таких як дослідження, аналіз безпеки, спільна робота агентів або перевірка коду, нам все ще потрібно створювати спеціалізовані виконавчі рамки поверх Claude Code.

Робочі процеси дозволяють вам динамічно створювати виконавчі рамки, щоб Claude міг більш природно вирішувати зазначені вище проблеми та багато інших типів завдань всередині Claude Code. Ви також можете ділитися цими робочими процесами та використовувати їх повторно.

У цій статті я поділюся своїм досвідом і враженнями щодо початкового використання workflows, щоб допомогти вам повністю розкрити його можливості.

Варто зазначити, що відповідні найкращі практики ще формуються. Динамічні робочі процеси зазвичай споживають більше токенів, тому вам слід уважно продумати, коли і як їх використовувати.

Примітка: Ця стаття також опублікована на Claude Blog.

Приклад запиту

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

Цей тест приблизно зазнає невдачі один раз на 50 запусків. Створіть workflow для відтворення цієї проблеми, сформулюйте гіпотезу та проводьте контрастні тести в різних worktree. /goal Не зупиняйтеся, доки одна з гіпотез не буде підтверджена.

Використовуйте workflow, щоб переглянути мої останні 50 сесій, виявити повторювані виправлення, які я роблю, і перетворити ці повторювані проблеми на правила CLAUDE.md.

Використовуйте workflow, щоб перевірити канал #incidents у Slack за останні шість місяців і виявити повторювані кореневі причини, які ніхто не подав у вигляді тікета.

Запустіть мій бізнес-план через workflow, щоб різні агенти розібрали його з точки зору інвесторів, клієнтів та конкурентів.

Тут є папка з 80 резюме. Використовуйте workflow, щоб відсортувати їх згідно з вимогами до позицій бекенду, а потім перевірте десятку лідерів. Задайте мені питання за допомогою інструменту AskUserQuestion, щоб допомогти мені встановити критерії оцінки.

Мені потрібно придумати назву для цього CLI-інструменту. Використайте workflow, щоб згенерувати список варіантів, а потім виберіть три найкращі за допомогою турнірної системи.

Використовуйте workflow, щоб переіменувати нашу модель User на Account у всіх місцях.

Прочитайте моє чернетку блогу та перевірте кожне технічне твердження за допомогою workflow та кодового репозиторію. Я не хочу публікувати нічого неправильного.

Як працює динамічний робочий процес

Динамічний робочий процес виконує файл JavaScript, який містить кілька спеціальних функцій для генерації та координації підагентів.

Динамічні робочі процеси також містять стандартні функції JavaScript, такі як JSON, Math і Array, для обробки даних.

Варто звернути увагу, що динамічний робочий процес може визначати, яку модель використовуватиме певний агент, а також чи мають підагенти працювати власними worktree. Це дозволяє Claude самостійно вибирати необхідний рівень інтелекту та ступінь ізоляції залежно від вимог завдання.

Якщо workflow перервано, наприклад, через ручну дію користувача або вихід із терміналу, після відновлення сесії цей workflow може продовжити виконання з місця перерви.

Коли ви використовуєте за замовчуванням фреймворк Claude Code для виконання завдання, він повинен одночасно планувати та виконувати його в межах одного вікна контексту. Для багатьох програмних завдань цей підхід дуже ефективний, але у довготривалих, масштабних паралельних або високо структурованих протистояльних завданнях він іноді не працює.

Причина полягає в тому, що чим довше Claude обробляє складні завдання в одному вікні контексту, тим більше він схильний до певних типів невдач:

Агентна лінь — це коли Claude при обробці надзвичайно складних, багатокомпонентних завдань зупиняється рано, не завершивши їх повністю, і оголошує про завершення лише з частковим прогресом. Наприклад, під час безпекового огляду обробивши лише 20 із 50 пунктів, він оголошує, що робота завершена.

Самопідсилювальний упередження — це тенденція Claude віддавати перевагу власним результатам або висновкам, особливо коли його просять перевірити або оцінити власний вихідний контент за певними критеріями оцінки.

Goal drift (відхилення від мети) — це поступове зниження відданості Claude початковій меті під час багатокрокового виконання, особливо після стиснення контексту. Кожен підсумок призводить до втрати інформації, і деякі детальні вимоги, наприклад, крайні випадки або обмеження типу «не робити X», можуть бути втрачені.

Створення workflow допомагає вирішити ці проблеми, оскільки воно дозволяє координувати кілька незалежних Claude, надаючи кожному власне вікно контексту та фокусуючись на ізольованих, чітко визначених завданнях.

Ви могли раніше створювати статичні робочі процеси за допомогою Claude Agent SDK або claude -p для координації кількох екземплярів Claude Code.

Оскільки статичні робочі процеси повинні охоплювати різноманітні крайні випадки, вони зазвичай більш універсальні. З появою Claude Opus 4.8 і динамічних робочих процесів Claude тепер достатньо розумний, щоб створити індивідуальну виконавчу рамку для вашого конкретного сценарію використання.

Практичні шаблони під час використання динамічних робочих процесів

Ви можете безпосередньо надати Claude створити динамічний робочий процес, або використовувати тригерне слово «ultracode», щоб забезпечити створення workflow за допомогою Claude Code.

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

Клауд при створенні робочих процесів часто використовує та комбінує такі моделі:

Класифікувати та виконати: використовуйте агента класифікації для визначення типу завдання, а потім маршрутизуйте його до відповідного агента чи дії. Також можна використовувати класифікатор наприкінці процесу для оцінки вихідних даних.

Розгалуження та агрегація: розбийте завдання на кілька менших кроків, щоб кожен крок виконувався окремим агентом, а потім об’єднайте результати. Цей підхід особливо підходить для завдань, що містять велику кількість малих кроків, або коли кожен крок вимагає чистого контекстного вікна, щоб уникнути взаємного впливу чи забруднення. Етап агрегації діє як «бар’єр»: він чекає, поки всі розгалужені агенти завершать роботу, а потім об’єднує їх структуровані вихідні дані в один результат.

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

Генерація та фільтрація: створіть велику кількість ідей навколо однієї теми, а потім відфільтруйте їх за критеріями оцінки або процесом перевірки, видаліть дублікати та поверніть лише перевірені, найякісніші ідеї.

Турнір: не розбивати роботу, а дозволити агентам змагатися між собою. Створіть N агентів, які намагатимуться виконати одне й те саме завдання різними методами. Потім prompt або модель оцінюватиме результати агентів у парних порівняннях, поки не визначиться переможець.

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

Сценарії використання

Ви можете більш креативно подумати про те, коли і як Claude Code створює динамічні робочі процеси. Я виявив, що робочі процеси іноді навіть корисніші у нетехнічній роботі.

Bun було переписано з Zig на Rust за допомогою workflows. Ви можете прочитати пост Jarred у X, щоб дізнатися деталі.

Ключовим є розбиття завдання на серію кроків, які потрібно виконати, наприклад, виклики точок, тести на помилки, модулі тощо. Для кожного завдання з виправленням запустіть підагент у worktree, щоб він виконав виправлення; після цього запустіть іншого агента для протестування з протилежної точки зору, а потім об’єднайте результати. Ви можете чітко повідомити агенту, щоб він не використовував ресурсоємні команди, щоб максимізувати паралелізм, не вичерпуючи ресурси локальної машини.

Ми запустили навичку deep research (/deep-research) у Claude Code, яка використовує динамічні робочі процеси. Зокрема, вона розгалужує виконання веб-пошуку, збір джерел, контрольну перевірку пов’язаних тверджень та комплексне створення звіту з посиланнями.

Але такі дослідження застосовні не лише до веб-пошуку. Наприклад, ви також можете попросити Claude створити звіт про статус на основі контексту Slack або дослідити, як працює певна функція, глибоко аналізуючи кодову базу.

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

У вас може бути набір проектів, які ви хочете впорядкувати за певним якісним показником, і ви впевнені, що Claude Code добре впорається з оцінкою такого показника. Наприклад, впорядкувати тікети підтримки за ступенем серйозності помилок.

Але якщо ви намагаєтесь відсортувати більше ніж 1000 рядків у одному запиті, якість знижується, а контекстне вікно не вміщує всі дані. Краще запустити турнірний механізм, створивши конвеєр з агентів, що проводять попарні порівняння, оскільки порівняльні судження зазвичай надійніші, ніж абсолютні оцінки; або спочатку паралельно розподілити дані на групи, а потім об’єднати результати. Кожне порівняння виконується окремим агентом, тому детермінований цикл може підтримувати всю структуру турніру, залишаючи в контексті лише поточний порядок виконання.

Якщо у вас є набір певних правил, а Claude навіть у CLAUDE.md, дивлячись на ці правила, часто пропускає їх або погано їх виконує, можна створити workflow, де ці правила перелічені, а агент перевірки перевіряє їх по черзі — кожне правило має свого агента перевірки. Створення підагента з особистістю «скептика», який перевіряє, чи є ці правила обґрунтованими, також допомагає уникнути надмірних ложних сповіщень.

Також можна зробити навпаки: проаналізуйте свої останні сесії та коментарі до код-рев’ю, щоб виявити повторювані виправлення; дайте паралельному агенту згрупувати ці проблеми; потім проведіть контрастну перевірку кожного кандидата на правило, щоб визначити, чи воно дійсно запобігає реальній помилці; нарешті, відновіть відібрані правила до CLAUDE.md.

Найефективніший спосіб налагодження — сформулювати кілька незалежних гіпотез і перевірити їх по черзі. Але якщо ви використовуєте лише одне вікно контексту, Claude може потрапити у передусім упередження.

Workflow може запобігти цій ситуації структурно: він може запустити кілька агентів, які створюють гіпотези на основі неперетинаючих доказів. Наприклад, різні агенти можуть аналізувати окремо журнали, файли та дані. Потім кожна гіпотеза підлягає перевірці групою верифікаторів і опонентів.

Це стосується не лише коду. Workflow можна використовувати також для аналізу продажів, наприклад: «Чому продажі в березні знизилися?»; для дата-інжинірингу, наприклад: «Чому цей пайплайн зазнав невдачі?»; або для будь-якого післяподійного аналізу.

Кожна команда має черги підтримки, звіти про помилки або інші завдання, які не можна повністю обробити людським способом. Робочий процес триажу може класифікувати кожен елемент, видалити дублікати з вже відстежених проблем та вжити заходів. Це може означати спробу виправлення або передачу на обробку людському користувачу.

Для робочого процесу триажу корисним патерном є карантин. Іншими словами, забороніть агентам, які читають ненадійний публічний контент, виконувати операції з високими правами; операції з високими правами повинні виконувати спеціалізовані агенти, відповідальні за дії.

Ви можете використовувати робочі процеси триажу разом із /loop, щоб дозволити Claude безперервно виконувати такі завдання.

Workflows корисні, коли вам потрібно дослідити різні шляхи рішень, особливо у завданнях, пов’язаних із дизайном та неймінгом, які вимагають естетичних оцінок і можуть скористатися набором критеріїв оцінки.

Ви можете дати Claude можливість дослідити велику кількість варіантів і надати агенту-ревізору набір критеріїв оцінки «який варіант вважається хорошим». Коли агент-ревізор вважає, що результат відповідає цим критеріям, завдання вважається завершеним. Різні варіанти також можна ранжувати або фільтрувати за допомогою цієї системи оцінки за принципом турніру.

Ви можете запустити легкі evals для конкретної задачі, запустивши окремий агент у worktree, а потім порівняльний агент, щоб порівняти та оцінити вихідні дані за критеріями оцінки. Наприклад, ви можете оцінити та покращити створений вами навичок, щоб перевірити, чи він відповідає певним стандартам.

Моделі та розумна маршрутизація: ви можете створити класифікаційний агент, оптимізований під ваше завдання, який вирішить, яку модель використовувати. Цей підхід корисний, коли завдання вимагає багато викликів інструментів, а дослідження перед виконанням допомагає визначити найбільш підходящу модель.

Наприклад, для завдання «Пояснити, як працює модуль auth» найбільш підходяща модель залежить від кількості файлів у модулі auth та структури кодового базу. Агент класифікації може спочатку провести дослідження, а потім, залежно від очікуваної складності, направити завдання на Sonnet або Opus.

Workflows все ще є новинкою. Хоча в багатьох сценаріях використання вони можуть принести значно більший ефект, ніж звичайні методи, не кожна задача потребує їх, і вони можуть значно збільшити споживання токенів.

Найкраще використовувати workflows для завдань, які можуть розширити межі можливостей Claude Code новим способом. Для звичайних програмних завдань спочатку запитайте себе: чи дійсно це завдання вимагає більше обчислювальних ресурсів? Наприклад, більшість традиційних програмних завдань не потребують групи з 5 рецензентів.

Поради щодо створення динамічних робочих процесів

При написанні запиту для динамічного робочого процесу деталізація завжди покращує результат, особливо при використанні конкретних технік, згаданих вище.

Робочі процеси застосовні не лише для великих завдань. Ви також можете запропонувати моделі використати «швидкий робочий процес». Наприклад, ви можете створити швидкий протестований процес перевірки для перевірки певної гіпотези.

Коли ви використовуєте робочі процеси, які можна виконувати повторно, наприклад, робочі процеси триажу, дослідження чи перевірки, ви можете поєднувати їх із /loop, щоб вони виконувалися через фіксовані інтервали, а також використовувати /goal для встановлення жорстких вимог щодо завершення.

Ви можете встановити чіткий бюджет використання токенів для динамічного робочого процесу, щоб обмежити кількість токенів, витрачених на завдання. Ви можете вказати в запиті таку вимогу, як «use 10k tokens», і це встановить ліміт на 10k токенів.

Ви можете зберегти робочі процеси, натиснувши «s» у меню workflow. Ви можете надіслати їх до ~/.claude/workflows або розповсюджувати через skill.

Щоб поділитися ними через skill, помістіть файл JavaScript workflow у папку skill і посилайтеся на нього у SKILL.md. Для більшої гнучкості ви також можете запропонувати Claude: сприймати workflows з skill як шаблони, а не як сценарії, які потрібно виконувати буквально.

Новий світ

Workflows — це корисний новий спосіб розширення Claude Code. Ми закликаємо вас сприймати це як початкову точку. Ще багато чого потрібно дослідити щодо того, як найкраще використовувати його. Будь ласка, розкажіть нам про ваші відкриття.

Тарік Шіхіпар і Сід Бідасарія (@sidbid) — члени технічної команди Anthropic, які займаються роботою над Claude Code.