Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Многоагентный процесс можно перестраивать на ходу, не запуская заново уже выполненные шаги. InFlowOp прибавил до 9,64 процентного пункта к точности других конструкторов при сопоставимом бюджете ходов; работа пока не рецензирована, а все числа получили сами авторы. Для продуктовой команды это прежде всего схема локального ремонта, а не готовое доказательство экономии в промышленной системе.
Одна стоимость выбирает разбиение и исполнителей
Конструкторы многоагентных процессов обычно сначала делят задачу по шаблону, а затем раздают части доступным агентам. Эти решения связаны: слишком крупный шаг может не подходить ни одному специалисту, а слишком мелкое разбиение увеличивает задержку и добавляет точки отказа.
InFlowOp начинает с максимально подробного разложения задачи на элементарные операции. Для каждой операции система описывает требования и сопоставляет их с карточками агентов: ролью, навыками, инструментами и накопленной историей успешной работы.
Результат сопоставления превращается в стоимость. Это не цена в долларах, а сводная оценка из трёх частей: риска ошибки, задержки на критическом пути и штрафа за создание нового агента. Если ни один доступный агент не проходит порог компетентности, система может добавить специалиста в пул и пересчитать назначения.
Затем модуль Coalesce идёт снизу вверх. Он либо открывает для элементарной операции отдельный шаг, либо объединяет её с уже открытым шагом. Объединение сохраняют только тогда, когда оно снижает общую стоимость с учётом исполнителя и зависимостей.
Так разбиение, назначение агента и создание специалиста становятся частями одной задачи оптимизации. Гранулярность не задают заранее числом шагов: она получается из доступного пула и требований конкретной задачи.
Каждый собранный шаг получает контракт с условиями для входа и ожидаемого выхода. Эти условия нужны не только для планирования: во время выполнения они заменяют эталонный ответ, которого у системы ещё нет.
Нарушенный контракт указывает, что именно чинить
Процесс выполняет шаги в порядке зависимостей и сравнивает фактические входы и выходы с контрактом. Для этого применяется тот же смысловой оценщик, который до запуска сопоставлял требования задачи с карточками агентов.
Если шаг не получил нужные входные данные, InFlowOp считает ошибочным разбиение: смена исполнителя не добавит недостающий контекст. Если вход корректен, но выход не соответствует условиям, проблема относится к назначению агента.
В первом случае система подробнее делит локальный участок процесса, во втором пробует другого исполнителя. Варианты перебираются по рассчитанной стоимости. Изменение принимается, только если новый результат проходит условия контракта; иначе процесс откатывается к прежней версии.
Выполнение при этом останавливается на неисправном шаге, а не в начале процесса. InFlowOp повторяет изменённый участок и сохраняет результаты, которые уже были получены до него. Обучать конструктор, готовить размеченные примеры или выбирать лучший результат из нескольких полных запусков для такого исправления не требуется.
Метод проверяли на Braid — созданном в работе наборе задач, где результат зависит от координации нескольких агентов. Эксперименты охватили восемь предметных областей, шесть базовых моделей и четыре конструктора процессов при сопоставимом бюджете ходов.
На Qwen3.5-9B точность одиночного агента составила 17,38%, а полного InFlowOp — 25,13%. Разбор компонентов показал, что основную прибавку дало исходное разбиение через Coalesce, тогда как локальные исправления во время выполнения добавили меньшую часть. Само наличие нескольких агентов результата не гарантировало: неудачное разбиение уступало одиночному агенту.
Планы меняет локальный ремонт, а не новый конструктор целиком
Команде с фиксированным графом агентов не обязательно заменять всю архитектуру. Из работы можно отдельно взять три элемента: явные контракты шагов, контрольные точки после выполнения и выбор между сменой исполнителя и повторным разбиением только неисправного участка.
Это особенно применимо там, где полный повтор процесса дорог из-за длинной цепочки вызовов. Контракт должен описывать проверяемые свойства входа и выхода, а промежуточные результаты нужно сохранять так, чтобы процесс мог продолжиться после локального изменения.
Слово «без разметки» относится к исправлению процесса во время запуска. Для проверки качества метода всё равно использовались задачи с эталонными ответами. Поэтому InFlowOp не отменяет собственную оценку качества продукта и набор контрольных сценариев.
Есть и более фундаментальная граница: смысловой оценщик видит соответствие шага его контракту, но не всегда понимает пользу результата для последующих шагов. В приведённом в работе примере формально правильный выход приводил к неверному финальному ответу, а нарушение локального условия помогало решить задачу. Дополнительный глобальный поиск ошибок эту проблему не устранил и снижал среднюю точность.
Практический вывод состоит не в том, чтобы сразу создавать агентов динамически. Сначала стоит проверить, удаётся ли для существующего процесса формализовать входы и выходы шагов и локально повторять их без потери предыдущей работы. Если это возможно, InFlowOp предлагает связать планирование и ремонт одной оценкой вместо отдельного механизма для каждого этапа.
Источники
Иллюстрация: рисунок из статьи «Pay for the Fault, Not the Flow: Label-Free In-Flow Multi-Agent Workflow Optimization», Xuehang Guo, Haoyu Wang, Shengyu Chen и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
