TL;DR
WorkflowOps — каркас, который строит план работы команды агентов не с нуля, а с опорой на прошлый опыт. Он ведёт таблицу передач: после какого агента чаще всего шёл какой. Задачу система режет на 3–7 подзадач с зависимостями, подбирает каждой агента по описанию его умений и использует таблицу как мягкую подсказку: в каком порядке ставить агентов и какие связи добавить. Независимые подзадачи идут параллельно.
Обычные системы «беспамятны»: каждая новая задача раскладывается заново, хотя похожие уже решались успешно. Это дорого, медленно, и ошибки копятся на каждом шаге. Вторая боль: когда нужного специалиста в команде нет, задачу берёт тот, кто «примерно подходит», и качество падает. Авторы решают обе проблемы: опыт копится в таблице, а нового агента создают только при явной нехватке умений.
В методе три механики. (1) Таблица передач подсказывает порядок и связи, но не отменяет жёсткие зависимости задачи. (2) Если ни один агент не подходит достаточно хорошо, LLM пишет описание нового агента и сразу предсказывает, с кем он будет работать. (3) Подбор агента сначала идёт дешёвым способом (сравнение текстовых описаний по смыслу, без LLM), а LLM подключается только в спорных случаях. Это сокращает число вызовов LLM больше чем на 80%.
⚠️ Метод реализован кодом (векторные эмбеддинги, графы, матрица). В обычном чате его не воспроизвести. В статье нет готовых промптов, но принципы можно перенести в инструкции агенту. Ниже это сделано в отдельном блоке «Адаптация», оригинальная механика описана отдельно.
Схема метода (оригинал)
ШАГ 1: LLM режет задачу на 3–7 подзадач → у каждой описание нужного умения + зависимости (граф DAG, без циклов)
ШАГ 2: Подбор агента → сходство «умение подзадачи ↔ описание агента» (эмбеддинги, без LLM)
ШАГ 3: Проверка достаточности → если сходство ниже порога τ, это пробел
ШАГ 4: Пробел → LLM создаёт нового агента + предсказывает, кто до/после него → агент вносится в таблицу
(до 3 раундов, не больше 4 новых агентов за запуск)
ШАГ 5: Сборка графа → жёсткие зависимости + мягкие связи из таблицы (если вероятность ≥ θ)
ШАГ 6: Убрать лишние связи (транзитивная редукция) → больше параллельности
ШАГ 7: Выполнение слоями → слой за слоем, внутри слоя параллельно
ШАГ 8: Успешный запуск → записывается в историю, таблица обновляется
Шаги 1, 4 и опциональная проверка в шаге 3 идут через LLM. Остальное считается кодом.
Пример применения
Задача: Вы ведёте Telegram-канал про e-commerce и каждую неделю выпускаете разбор: «Wildberries против Ozon: кто выиграл квартал». Работаете в Claude Code с набором субагентов. В команде есть Исследователь, Аналитик цифр, Фактчекер, Автор, Редактор. Выпуск повторяется, и вы хотите, чтобы агент использовал опыт прошлых выпусков. Сегодня в разбор нужно добавить блок про рекламу у блогеров с маркировкой (ERID), а такого специалиста в команде нет.
Промпт:
Ты — оркестратор команды агентов. Работай по методу WorkflowOps.
ЗАДАЧА: Подготовить разбор «Wildberries vs Ozon за квартал» для Telegram-канала,
включая блок про рекламу у блогеров и требования к маркировке.
ПУЛ АГЕНТОВ:
- Исследователь: собирает отчёты и новости по компаниям
- Аналитик цифр: считает выручку, GMV, доли, сравнивает метрики
- Фактчекер: сверяет каждое число и цитату с источником
- Автор: пишет текст для Telegram в стиле канала
- Редактор: правит стиль, сокращает, проверяет структуру
ИСТОРИЯ ПЕРЕДАЧ (сколько раз B шёл сразу после A в успешных выпусках):
Исследователь → Аналитик цифр: 9
Исследователь → Фактчекер: 3
Аналитик цифр → Фактчекер: 8
Фактчекер → Автор: 10
Автор → Редактор: 11
Аналитик цифр → Автор: 2
Выполни по шагам, показывая результат каждого шага.
[далее — шаблон ниже]
Результат: Модель сначала разложит задачу на 3–7 подзадач и покажет зависимости. Затем сопоставит подзадачи с агентами и отметит слабое совпадение: блок про маркировку рекламы никому не подходит. Она предложит описание нового агента (например, специалиста по рекламному законодательству) и предскажет, после кого он работает и кому передаёт результат. Затем она соберёт план по слоям: что идёт параллельно (исследование компаний, исследование рекламного блока), что строго после чего. Мягкие связи из истории (например, Аналитик → Фактчекер) будут помечены отдельно от жёстких зависимостей. В конце будет итоговый порядок запуска.
Почему это работает
Слабость LLM: при планировании «с нуля» модель каждый раз изобретает схему заново. Одна и та же задача раскладывается по-разному, лишние шаги идут последовательно, хотя могли бы параллельно. А если нужного эксперта нет, модель молча «натягивает» на задачу ближайшего агента.
Сильная сторона: модель хорошо режет задачу на части и описывает нужное умение словами. Она неплохо оценивает, подходит ли агент под требование, и умеет написать описание нового специалиста. Простая частотная статистика («после А чаще всего шёл Б») даёт ей надёжный ориентир, для которого не нужно обучение.
Как метод это использует: История работает как подсказка, а не как приказ. Жёсткие зависимости задачи нельзя нарушить. Таблица только добавляет связи и выбирает порядок там, где зависимостей нет. Новый агент создаётся только при измеримом пробеле, поэтому пул не раздувается.
Рычаги управления: - Порог достаточности τ (в статье 0,45): выше — система чаще создаёт новых агентов, ниже — чаще терпит «примерно подходящих». - Порог связи θ (0,3): выше — меньше мягких связей, план свободнее и параллельнее. Ниже — больше опоры на историю. - Число подзадач 3–7: меньше для простых задач, чтобы не плодить лишние шаги. - Лимит новых агентов за запуск (4) и раундов (3): защита от разрастания команды. - Режимы пула: свободный рост, периодическая проверка человеком, «заморозка» для продакшена.
Шаблон промпта
В статье нет опубликованных промптов. Ниже адаптация механики под чат или агента. Алгоритмы (подбор по эмбеддингам, матрица, редукция графа) заменены явными шагами в тексте. Это не авторский код, а перенос логики.
Ты — оркестратор команды агентов. Ты не выполняешь задачу сам:
ты строишь план и распределяешь работу.
{задача}
{агент_1}: {описание умений}
{агент_2}: {описание умений}
...
Сколько раз в успешных запусках агент B шёл сразу после агента A:
{агент_A} → {агент_B}: {число}
...
subtasks: от 3 до 7
sufficiency_threshold: 0.45 (шкала 0–1)
edge_threshold: 0.3 (доля от всех передач из агента A)
max_new_agents: {максимум_новых_агентов}
max_rounds: 3
Step 1. Decompose:
Разбей задачу на подзадачи. Для каждой:
id, цель, required_capability (одной фразой), depends_on (только жёсткие зависимости).
Циклов быть не должно.
Step 2. Match:
Для каждой подзадачи найди лучшего агента из AgentPool.
Оцени совпадение умения и описания агента от 0 до 1.
Покажи таблицу: подзадача → агент → оценка.
Step 3. Sufficiency check:
gaps = подзадачи, у которых оценка < sufficiency_threshold.
Если gaps пуст → переходи к Step 5.
Step 4. Create agent (только для gaps, не больше max_new_agents):
Прежде чем создавать, проверь: действительно ли никто из существующих не подходит?
Если да — опиши нового агента: имя, умения, формат входа и выхода.
Предскажи predecessors (после кого он обычно работает) и successors (кому передаёт результат).
Добавь его в AgentPool и повтори Step 2 для gaps.
Step 5. Build graph:
edges = жёсткие зависимости из Step 1.
Для каждой пары подзадач без прямой зависимости:
если по HandoffHistory доля передач A→B от всех передач из A ≥ edge_threshold
И подзадача A находится выше B по слоям, добавь мягкую связь (пометь как soft).
Мягкая связь не может противоречить жёсткой зависимости и не может создать цикл.
Step 6. Reduce:
Если есть связи A→B, B→C и прямая A→C, удали прямую A→C.
Step 7. Layers:
Раздели подзадачи на слои. В одном слое — всё, что можно делать параллельно.
Внутри слоя поставь первым агента, который чаще всего идёт после агентов предыдущего слоя.
Step 8. Output:
Покажи слои, агентов, жёсткие и мягкие связи, новых агентов (если были).
Выполняй слой за слоем: следующий слой получает результаты предыдущего.
- Жёсткие зависимости задачи важнее истории.
- История — подсказка, а не запрет: допускай порядок, которого в ней не было.
- Не создавай агента, если подходит существующий.
Что подставлять:
- {задача}: повторяющийся рабочий процесс (выпуск разбора, обработка заявки, релиз).
- {агент_N}: роль плюс одна-две фразы о том, что именно она умеет. Чем конкретнее описание, тем точнее подбор.
- {HandoffHistory}: реальные передачи из прошлых успешных запусков. Если истории нет, оставьте пустой блок: в статье матрицу можно засеять синтетическими цепочками (65 штук на 8 доменов).
🚀 Быстрый старт — вставь в чат:
Вот шаблон WorkflowOps. Адаптируй под мою задачу: {опиши свой повторяющийся процесс}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие агенты или роли у тебя есть, как они обычно передают работу друг другу и что считалось успешным запуском. Это нужно, потому что метод держится на описаниях умений (для подбора) и на истории передач (для порядка). Остальное она возьмёт из шаблона.
Адаптации (мои, не из статьи)
- Файл инструкций агента (CLAUDE.md, AGENTS.md): держите там раздел «Журнал успешных передач» и обновляйте его после каждого удачного запуска. Это аналог матрицы без кода.
- Правило «не создавай нового агента без пробела»: в инструкциях оркестратору явно пропишите, что новый субагент создаётся, только если ни один из существующих не покрывает подзадачу.
- Жёсткое против мягкого: в промптах планировщика разделяйте «обязательные зависимости» и «рекомендуемый порядок». Это снижает риск, что история сломает логику задачи.
Эти идеи автор статьи не проверял на промптах. Они следуют из механики метода.
Ограничения
⚠️ Нужен код: оригинальный метод считает сходство по эмбеддингам, строит граф и матрицу программно. В чате воспроизводится только упрощённая версия, и ни качество, ни экономия вызовов LLM для неё не измерены.
⚠️ Слабее на открытых задачах: на вопросах по чтению и пониманию текста (QA) система уступает конкурентам. Пул агентов и история лучше подходят для структурных задач: код, математика.
⚠️ Нужна история: метод выигрывает на повторяющихся процессах. Для разовой нестандартной задачи таблицы передач нет, и преимущество исчезает.
⚠️ Одна модель и учебные бенчмарки: все системы запускались на одной LLM. Сравнение шло на известных тестовых наборах (код, математика, QA), а не на живых бизнес-процессах. Числа конкурентов взяты из их собственных прогонов.
⚠️ Разреженная матрица: заполнено около 20% ячеек. Поэтому история используется как мягкая подсказка: жёсткие правила заблокировали бы работающие, но ещё не встречавшиеся цепочки.
⚠️ Вклад компонентов разный: без таблицы передач точность падает умеренно, без роста пула падает совсем немного. Сильнее всего влияет подбор по смыслу (замена на простое сравнение слов по частоте сильно ухудшила результат).
⚠️ Текст статьи обрезан: часть результатов и приложения (формат сообщений, обработка ошибок) в доступной версии отсутствует.
Ресурсы
WorkflowOps: Learning Agent Collaboration Priors for Multi-Agent Workflow Orchestration
Авторы: Qi Cheng, Xiaowei Jia (Rutgers University); Shengyu Chen (University of Pittsburgh); Wei Cheng, Zhengzhang Chen, Haoyu Wang, Haifeng Chen (NEC Labs America).
Упомянутые работы: MetaAgent, ADAS, AFlow, MaAS, Agent Workflow Memory, EvoFlow, TopoPrior, AOrchestra, Sentence-BERT (all-MiniLM-L6-v2).