Як використовувати динамічні робочі процеси Claude для глибоких досліджень

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

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

Ще раз подумайте: що саме є глибоким дослідженням, яке людина повинна проводити в епоху ШІ, і як побудувати мої взаємодоповнюючі відносини з ШІ.

Проведення технічного дослідження насправді пов’язане з багатьма пастками (незалежно від того, чи для людини, чи для ШІ), оскільки з самого початку дослідження ви отримуєте величезну кількість інформації, думок стає все більше, а висновки — все більш нечіткими. Тож завжди треба пам’ятати про початкову мету.

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

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

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

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

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

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

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

Спосіб запуску простий: просто використовуйте /deep-research у cc, а потім надайте кілька шаблонів дослідження та вхідні матеріали. Якщо ви хочете використовувати можливості динамічного робочого процесу окремо, використовуйте підказку або просто сказати ultracode. Перед використанням зверніть увагу: споживання токенів становить приблизно десятки разів більше, ніж зазвичай.

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

Справді, за цими шістьма режимами стоять лише дві основні проблеми: як розбити завдання? Як об’єднати результат? Розділення на шість режимів — це просто комбінації цих двох аспектів.

3.1 Режим маршрутизації (Classify-And-Act)

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

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

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

Недоліки також помітні: слабка здатність обробляти завдання з нечіткими межами (наприклад, «і технічна проблема, і проблема з акаунтом»).

3.2 Розбиття та об’єднання (Fan-out & Merge)

Також це мій найчастіше використовуваний підхід: паралельне виконання + об’єднання. Завдання розбивається на N незалежних підзавдань, які виконуються одночасно, а після завершення всіх — об’єднуються.

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

Слабкістю є те, що вартість токена є N разів більшою у послідовному режимі, а саме об’єднання (Synthesize) також має складність — як об’єднати вихідні дані з N різними структурами — це виклик проектування. Погане розбиття на підзавдання може призвести до пропусків або повторного охоплення.

3.3 Адверсарна верифікація

Основна логіка полягає у перевірці: для однієї й тієї ж висновку кілька агентів викликають її з позиції "спростування", і вона вважається прийнятою, якщо за неї виступає більшість голосів.

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

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

Але, перевіряючи це, якщо він дасть неправильну оцінку, це може відвести Worker у бік підстроювання під Verifier. Тому краще опиратися на відтворювані факти, а не на думки.

Сказавши це на жарт, якщо ви дозволите ШІ шукати проблеми, він зможе безкінечно їх знаходити, тому вам потрібно обмежити межі пошуку проблем.

3.4 Генерація та фільтрація

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

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

Слабким місцем є те, що якість rubric Filter безпосередньо визначає кінцевий ефект; помилка у дизайні rubric дорівнює повній збою всього процесу

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

Тільки поверхнево схожі на Fanout-And-Synthesize: обидва мають структуру «багато паралельних → один вихід», і їх найлегше переплутати.

Ключова відмінність — у намірі: кожен шлях Fanout обробляє різну частину завдання, і результати є доповнюючими — при об’єднанні кожен шлях вносить свій внесок; кожен шлях Generate-And-Filter обробляє одне й те саме завдання, і результати є конкурентними — при об’єднанні більшість з них відкидаються. Перший — це «пазл», другий — «конкурс краси».

3.5 Режим турніру (Tournament)

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

Це я раніше робив вручну — запускав одну й ту саму зміну коду у двох-трьох версіях, а потім змушував AI порівняти, яка краща. Зараз це можна безпосередньо інтегрувати у робочий процес.

Перевага полягає у оцінці стабільності. Порівняння парами ("Який кращий: A чи B?") набагато стабільніші, ніж абсолютні оцінки ("Оцініть A"), оскільки виключають проблему зміщення критеріїв оцінки. Результати проходять кілька раундів конкурсу, і в результаті переможець має високу надійність.

Також схожий на Generate-And-Filter: обидва вибирають найкраще з кількох варіантів. Ключова різниця — у механізмі вибору: Tournament використовує pairwise judge для попарного порівняння, тобто «дає кандидатам змагатися між собою». Коли критерії важко квантифікувати, а оцінка суттєво відносна, це більш надійно.

3.6 Циклічний режим (Loop)

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

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

Перевага полягає в здатності обробляти завдання з невідомим обсягом роботи. Інші п’ять режимів припускають, що межі завдання відомі; Loop Until Done — єдиний режим, який може обробляти ситуації, коли невідомо, скільки ітерацій потрібно виконати.

Слабкість — це потенційний ризик втрати контролю — погано спроектовані умови зупинки можуть призвести до нескінченного циклу. Кожен агент у кожному циклі має новий контекст і не може накопичувати стан між циклами (якщо тільки не записувати його явно у файл).

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

1. Просто надішліть просте повідомлення (наприклад, що проект запустив нову функцію)
2. Нехай ШІ знайде всю відповідну інформацію: офіційну документацію, вихідний код, ринкові обговорення
3. Стисніть інформацію у змістовний скорочений варіант
4. Кілька ролей агентів для аналізу протистояння, генерація звіту
5. Автоматичне видалення дублікатів, оскільки контент багатьох агентів має високий рівень повторюваності

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

І часто, навіть якщо є п’ятий крок видалення дублікатів, він часто видаляє корисну інформацію; якщо не робити видалення дублікатів, то skill надасть вам статтю на десять тисяч слів, з повною інформацією, але не скаже прямо: «Як це стосується вас і що вам слід робити».

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

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

Що ще зробив офіційний робочий процес

Протягом цього тижня, експериментуючи з кількома складними дослідницькими завданнями, я виявив, що вбудований робочий процес deep research у Claude Code (зверніть увагу, що це не просто навичка, а модуль, вбудований у cc), має кілька ключових етапів, яких не вистачає в моїх власних навичках:

• Шар розбиття питань: він не починає пошук відразу, а спочатку задає питання, розбиваючи моє запитання на кілька підпитань: Що саме ви хочете зрозуміти? Як це стосується вас? Які аспекти варто дослідити глибше? Цей етап я раніше пропускав.
• Оцінка надійності: оцініть фальсифікованість кожної інформації, подібно до рейтингу авторитетності в традиційному SEO — чи є джерело надійним? Яка кількість цитувань? Це етап, який раніше не вважав необхідним додавати.
• Перехресне видалення замість середнього об’єднання: раніше я середнім значенням обирала всі висновки, тому документ був дуже великий. Динамічний робочий процес проводить голосування між кількома агентами для кожного висновку, а ті, що отримали недостатньо голосів, видаляються — це не просте об’єднання.
• Орієнтований на ціль вивід: кінцевий звіт — це не збір інформації, а оцінка та пропозиції рішень, спрямовані на вашу початкову мету. Ключем до досягнення цього є використання передбачуваних можливостей багатьох підагентів. Раніше мій навичковий підхід часто не мав орієнтації на кінцеву мету, оскільки після обробки величезного обсягу інформації вага інструкцій зменшувалася.

Які проблеми вирішують ці механізми?

Це саме типові проблеми, з якими стикаються AI при виконанні довгих завдань:

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

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

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

Наклон виводу: ШІ схильний відповідати відповідно до ваших очікувань, розмовний стиль запиту легше сприяє цьому.

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

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

Тепер мені не потрібно вручну проектувати планування агентів, ні виконувати видалення дублікатів та перехресну перевірку — все це вбудовано в сам робочий процес.

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

Тому Dynamic Workflows — це не «розумніший одноразовий діалог», а структуризація самого процесу дослідження.

Раніше мені потрібно було провести десятки окремих діалогів для дослідження, тепер це зведено до 3–4. Хоча відповідне споживання токенів зросло в десятки разів.

Чому потрібно ще 3–4 рази? Я вважаю, що корінна причина полягає у різниці цих вимог.

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

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

Третє — це проектування та перевірка рішення. Значення рішення полягає не у його запропонуванні, а у підтримці та перевірці; воно ґрунтується на оцінці існуючих механізмів, вкладів та витрат. Якщо AI добре налаштувати, можна досягти кращих результатів, але це суперечить універсальності.

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