Техническое исследование — это дело, полное ловушек (как для людей, так и для ИИ). Ведь с самого начала исследования вы получаете огромное количество информации, точек зрения становится всё больше, а выводы — всё более размытыми. Поэтому важно постоянно помнить об исходной цели.
Именно поэтому ИИ до сих пор не был достаточно хорош в этом. С точки зрения внимания и ассоциативного мышления он сильнее, чем человек, зацикливается на текущем объёме информации и очень слаб в действительно ценных междисциплинарных ассоциациях.
Конечно, сильная сторона ИИ — его исполнительность. В форме агентов он может искать, обобщать и резюмировать информацию слой за слоем, полностью избегая потери деталей.
Хотя я почти не публиковал посты в публичном аккаунте за последние полгода, я пристально следил и изучал все основные тренды в индустрии, и мои вводные и выводящие данные поддерживаются собственной системой deep-research.
С выходом на прошлой неделе функции Dynamic Workflows в Claude Code, я захотел сравнить их, посмотреть, сможет ли его стандартная функциональность полностью превзойти мою собственную.
2. Что такое Dynamic Workflows
Основная идея Dynamic Workflows (динамических рабочих процессов) такова: перед выполнением задачи ИИ сначала автоматически проектирует, каким рабочим процессом эту задачу следует выполнить, и только потом запускает исполнение.
Это коренным образом отличается от используемых ранее "режима планирования" и "скиллов". Режим планирования разбивает задачу на более мелкие части, но не обязательно в соответствии с разумным рабочим процессом. Только если вы укажете в промпте, он может добавить критерии проверки (что крайне важно для исследований). Точно так же, только при наличии промпта, он может лучше предустановить некоторые harness-правила.
Но динамический рабочий процесс автоматически включает в себя логику проверки, схождение результатов, проверку методом противодействия и т.д.
Способ запуска прост: прямо в cc используйте /deep-research и предоставьте несколько шаблонов исследования и исходных данных. Если вы хотите использовать только возможности динамических рабочих процессов, то укажите в промпте или прямо скажите ultracode. Обратите внимание перед использованием: потребление токенов примерно в десятки раз выше обычного.
3. Шесть встроенных режимов рабочих процессов
В основе динамических рабочих процессов лежат шесть основных режимов оркестрации, обобщённых разработчиками. Именно поэтому они мощнее обычного диалога/агента/скилла.
На самом деле, за этими шестью режимами скрываются всего два основных вопроса: Как разбить задачу? Как объединить результаты? Разделение на шесть режимов по сути является перестановкой этих двух вопросов.
3.1 Маршрутизация (Classify-And-Act)
Сначала один агент определяет тип задачи, а затем распределяет её наиболее подходящему специализированному агенту для выполнения. Ключевая логика — логика выбора маршрута, а не параллелизм или итерации. Задача проходит только по одному пути, другие пути вообще не выполняются.
Например, у меня могут быть три предустановленных сабагента: агент-аналитик, строго проверяющий данные; агент-писатель, сильный в выводе; агент-искатель уязвимостей, специализирующийся на поиске дыр. Слой маршрутизации будет решать, какому агенту подходит текущая подзадача, а не доверять всё одному агенту.
Ценность этого режима: точность и экономия. Промпт каждого агента может быть высоко независимым, не подверженным влиянию других целей, формируя глубокие вертикальные исследования. Потребление токенов минимально, скорость отклика максимальна. Границы ответственности очень чёткие.
Недостаток также очевиден: слабая способность обрабатывать задачи с размытыми границами (например, "одновременно техническая проблема и проблема с аккаунтом").
3.2 Разделение и объединение (Fan-out & Merge)
Это также мой наиболее часто используемый режим. Ключевая логика — параллелизм + объединение. Задача разбивается на N независимых подзадач, которые выполняются одновременно, а затем все результаты объединяются.
Преимущества — скорость и изоляция. Общее время выполнения примерно равно времени самой медленной подзадачи, а не сумме всех подзадач. Каждая подзадача имеет независимый контекст, не мешает другим и не загрязняет шумом от одной подзадачи контексты других.
Слабое место — стоимость в токенах в N раз выше последовательного выполнения, а сам слой объединения (Synthesize) также представляет сложность — как объединить N результатов с разной структурой — это задача проектирования. Плохое разделение подзадач может привести к пропускам или дублированию.
3.3 Проверка противодействием (Adversarial Verification)
Ключевая логика — проверка. Для одного и того же вывода несколько агентов оспаривают его с точки зрения "опровержения", и вывод считается принятым, только если получит большинство голосов.
Преимущество в том, что, поскольку Verifier не знает логику Worker и видит только результат, структурно устраняется смещение самооценки, возникающее, когда «модель проверяет свой собственный код».
Этот режим решает проблему, которая долго меня беспокоила: мы часто общаемся с ИИ обычным языком, но ИИ склонен отвечать в соответствии с вашими ожиданиями, что легко приводит к «подтверждающей предвзятости». Проверка противодействием заставляет ИИ искать контрпримеры, проверять на основе данных и экспериментов, а не подстраиваться под ваши мысли.
Однако, если проверка даёт ошибочное суждение, она может увести Worker в сторону, заставив его подстраиваться под Verifier. Поэтому предпочтительнее основываться на воспроизводимых фактах, а не на мнениях.
Шутки ради, если вы попросите ИИ найти проблемы, он сможет находить их бесконечно, поэтому вам нужно ограничить границы поиска проблем.
3.4 Генерация и фильтрация (Generate & Filter)
Ключевая логика — дивергенция, а затем конвергенция. Сначала намеренно генерируется избыточное количество кандидатов, затем с помощью rubric (критериев оценки) отбрасывается всё лишнее, оставляя только высоконадёжные результаты для вывода.
Лучше, чтобы один агент сгенерировал десять ответов, а затем слой проверки отфильтровал их, чем чтобы он выдал один «нормальный» ответ. Таким образом, преимущество — в разнообразии. Несколько генераторов могут использовать разные стратегии, разные промпты, производить решения, которые трудно предугадать человеку, а этап фильтрации обеспечивает высокую концентрацию качества конечного результата.
Слабость в том, что качество rubric фильтра напрямую определяет конечный результат. Ошибочный дизайн rubric равносилен провалу всего процесса.
Подходит для ситуаций, когда правильный ответ заранее неизвестен, нужно выбрать лучшее из множества вариантов, есть явная потребность в разнообразии.
Поверхностное сходство с Fanout-And-Synthesize: оба являются «многопоточным параллелизмом → единый вывод», их легче всего спутать.
Ключевое различие в намерении: каждый поток в Fanout обрабатывает разные части задачи, результаты дополняют друг друга, и при объединении вносят вклад все потоки; каждый поток в Generate-And-Filter обрабатывает одну и ту же задачу, результаты конкурируют, и при объединении большинство из них отбрасывается. Первое — «сборка пазла», второе — «конкурс красоты».
3.5 Турнирный режим (Tournament)
Ключевая логика — соревнование и отбор. N агентов независимо выполняют одну и ту же задачу, попарно сравниваются и отсеиваются раунд за раундом, в конечном итоге выбирается лучшее решение.
Раньше я делал это вручную — запускал два-три варианта одного изменения кода, а затем просил ИИ сравнить, какой из них лучше. Теперь это можно напрямую интегрировать в рабочий процесс.
Преимущество в стабильности оценки. Попарное сравнение («Что лучше, A или B?») намного стабильнее абсолютной оценки («Оцените A»), поскольку исключает проблему дрейфа стандартов оценки. Результат проходит через несколько раундов конкуренции, доверие к победителю высокое.
Поверхностное сходство с Generate-And-Filter: оба выбирают лучшее из нескольких кандидатов. Ключевое различие в механизме выбора: Tournament использует попарное судейство (pairwise judge), это «заставляет кандидатов конкурировать друг с другом». Когда rubric трудно квантифицировать, а суждение по сути является относительным, это более надёжно.
3.6 Циклический режим (Loop)
Ключевая логика — адаптивная итерация. Постоянные попытки, при столкновении с препятствиями сбор информации об ошибках, дополнение контекста, повторные попытки до тех пор, пока не будут удовлетворены критерии приёмки.
По сути, это борьба со случайностью ИИ: попробовав несколько раз, рано или поздно наткнёшься на лучший результат. Но более зрелый подход — сочетать с проверкой противодействием, чтобы каждый цикл выполнялся с большим объёмом информации, а не только на удачу.
Преимущество в способности обрабатывать задачи с неизвестным объёмом работы. Остальные пять режимов предполагают, что границы задачи определены, Loop Until Done — единственный режим, способный обрабатывать задачи, где «неизвестно, сколько раундов потребуется».
Слабость — потенциальный риск выхода из-под контроля — плохо спроектированное условие остановки может привести к бесконечному циклу. Агент в каждом раунде имеет новый контекст и не может накапливать состояние между раундами (если явно не записывать в файл).
4. Сравнение моих скиллов и официальных рабочих процессов
До появления динамических рабочих процессов я специально разработал свой собственный deep-research. Логика моего скилла была примерно такой:
- Дать только простую информацию (например, что в неком проекте появилась новая функция).
- Попросить ИИ найти все соответствующие материалы: официальную документацию, исходный код, рыночные обсуждения.
- Сжать информацию в содержательные сводки.
- Несколько агентских ролей проводят аналитику с проверкой противодействием, генерируют отчёт.
- Автоматическое устранение дубликатов, так как контент от нескольких агентов часто сильно повторяется.
Используя его какое-то время, я считал его очень полезным. Но у него есть фундаментальный недостаток: отсутствие целеориентированной конвергенции.
И часто, даже при наличии пятого шага по удалению дубликатов, он удалял ценную информацию. А если не удалять дубликаты, то скилл легко мог выдать вам длинный текст на десятки тысяч знаков, информация полная, но без прямого указания "какое отношение это имеет к вам и что вам делать".
Однако исследование служит «принятию решений», поэтому многие скиллы останавливаются на самом исследовании, достигая 80 баллов, но не хватает самых важных 20 баллов.
В результате, после первоначального завершения исследования, ИИ часто требуется ещё десять раз подумать и пообщаться, чтобы прийти к удовлетворительному и всестороннему выводу.
Что ещё делает официальный динамический рабочий процесс
После нескольких экспериментов со сложными исследовательскими задачами на этой неделе я обнаружил, что встроенный в Claude Code рабочий процесс deep research (обратите внимание, это не просто скилл, а модуль, встроенный и скомпилированный в cc), по сравнению с моим собственным скиллом, добавляет несколько ключевых этапов:
- Слой декомпозиции вопроса: Он не начинает сразу искать, а сначала задаёт вопросы, разбивая мой вопрос на несколько подвопросов: Что вы действительно хотите выяснить? Какое отношение это имеет к вам? Какие аспекты стоит глубоко изучить? Этот шаг я раньше пропускал.
- Оценка достоверности: Оценка опровержимости каждой единицы информации, аналогично оценке авторитетности в традиционном SEO — насколько надёжен источник? Как часто его цитируют? Это этап, о добавлении которого я раньше не задумывался.
- Перекрёстное удаление, а не усреднённое объединение: Мой прежний подход заключался в усреднённом выборе всех выводов, поэтому документ получался большим. Динамический рабочий процесс проводит голосование нескольких агентов по каждому выводу, выводы, не набравшие достаточного количества голосов, удаляются, а не просто объединяются.
- Целеориентированный вывод: Конечный отчёт — это не нагромождение информации, а оценка и рекомендации, сфокусированные на вашей исходной цели. Ключ к реализации этого — его способность по умолчанию оркестрировать множественные подчинённые агенты. Причина, по которой мои скиллы часто не имели конечной целевой ориентации, заключалась в ослаблении веса инструкций после огромного объёма информации.
Какие проблемы решают эти механизмы?
Они направлены на решение нескольких типичных проблем ИИ при выполнении длительных задач:
Дрейф цели: В начале задачи состояние хорошее, к середине уже непонятно, что происходит, а к концу снова возвращается ритм — похоже на то, как человек отвлекается на уроке. Чем длиннее задача, тем это заметнее.
Преждевременная остановка: Во время выполнения встречаются трудности, ИИ считает, что он "выполнил" задачу, и останавливается, хотя на самом деле критерии приёмки не выполнены.
Загрязнение контекста: Один агент выполняет сложную задачу, большое количество промптов в начале сжимает пространство для последующего выполнения. Лучший способ — ограничить начальные промпты несколькими тысячами токенов и распределить контекст между несколькими агентами.
Смещение вывода: ИИ склонен отвечать в соответствии с вашими ожиданиями, вопросы, заданные обычным языком, легче провоцируют эту проблему.
Динамический рабочий процесс структурированно решает эти четыре проблемы: автоматическое добавление критериев проверки для предотвращения преждевременной остановки; параллельная изоляция контекстов; проверка противодействием для компенсации смещения вывода; декомпозиция проблемы и пошаговое ограничение ИИ сначала понять цель, а затем действовать.
5. Заключение
В заключение, я как многолетний исследователь, восхищён этим новым механизмом в CC. Его встроенные шесть режимов — маршрутизация, разделение и объединение, проверка противодействием, генерация и фильтрация, турнирный отбор, цикл — охватывают подавляющее большинство потребностей в оркестрации для сложных исследовательских задач.
Мне больше не нужно вручную проектировать оркестрацию агентов, не нужно самому выполнять удаление дубликатов и перекрёстную проверку — всё это встроено в сам рабочий процесс.
И он особенно хорошо подходит для размышлений над исследовательскими вопросами с недостатком информации, с открытым концом, поскольку естественная оркестрация множественных агентов + разделение целевых задач ещё больше повышает его универсальность. На самом деле, ещё 3 года назад ИИ уже хорошо справлялся с решением предельно ясных мелких задач при многослойных ограничениях. Но качественный скачок ИИ заключается именно в универсальности, в том, чтобы его конкуренты превратились из простого кода в настоящих агентов, от статического решения одной проблемы к адаптации к любой проблеме.
Поэтому Dynamic Workflows — это не «более умный единичный диалог», а структурирование самого исследовательского процесса.
Исследование, которое раньше требовало от меня запуска десятков независимых диалогов, теперь сжимается до 3-4. Хотя соответствующее потребление токенов увеличивается в десятки раз.
Почему всё ещё требуется 3-4 раза? Я считаю, что коренная причина кроется в различиях этих потребностей.
Первое — строгость механизма проверки. Я в основном занимаюсь исследованиями новых технологий в блокчейне, и по многим вопросам официальная документация отстаёт, есть более достойные внимания данные, такие как открытый исходный код, транзакции в цепи и т.д. А в настоящее время ИИ по умолчанию всё ещё полагается на официальную документацию, а не на фактическую проверку.
Второе — полностью междисциплинарное глубокое мышление. Хотя с помощью предустановок рабочих процессов можно решить некоторые проблемы (предопределение subAgent различных измерений) для размышлений над одной проблемой. Но ИИ силён в основном в мейнстримных моделях мышления, а для очень новых, очень глубоких вопросов, не имеющих достаточной основы данных, он несколько слабоват.
Третье — проектирование и проверка решений. Значение решения заключается не в предложении, а в проверке и поддержке, оно опирается на оценку существующих механизмов, вложений и затрат. Если хорошо обучать ИИ, он, конечно, может делать лучше, но это противоречит универсальности.
И наконец — крайняя концентрация информации. Это требует возврата к пониманию аудитории, для которой предназначена информация. Некоторые люди абсолютно не имеют базовых знаний и нуждаются в очеловеченном, образном изложении, а некоторые слушатели хотят, чтобы вы задели их одной фразой~.
