Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Подагентов научили просить координатора менять им задачу, инструменты и бюджет прямо во время работы, не теряя накопленный контекст. В препринте команды The Chinese University of Hong Kong, Shenzhen и Beijing Academy of Artificial Intelligence, который не прошёл рецензирование и все числа в котором получили сами авторы, POrchestra повысила среднюю долю успешно выполненных заданий на 9,1% относительно сильнейшего базового подхода. Для агентных систем с долгими и изменчивыми процессами это предлагает альтернативу двум крайностям: заранее фиксировать весь план или регулярно перезапускать исполнителей.
Подагент сам сообщает, когда конфигурация перестала подходить
В обычной схеме координатор создаёт подагента и передаёт ему конфигурацию исполнения: подзадачу, рабочий контекст, доступные инструменты и бюджет шагов. Если инструмент перестал работать или новая информация изменила цель, подагент часто должен закончить работу. Только после этого координатор создаёт следующего исполнителя с другими настройками.
POrchestra разрешает подагенту приостановиться в любой логической точке и запросить изменение конфигурации. В сообщении он передаёт три части: текущее состояние работы, требуемое изменение и подтверждающие данные из ответов инструментов.
Запрос может изменить саму подзадачу либо ресурсы: контекст, набор инструментов и оставшийся бюджет. Координатор также вправе остановить ветку, создать другого подагента или завершить всю задачу.
После изменения прежний подагент продолжает работу. Новая конфигурация записывается в его локальную историю рядом с предыдущими действиями и результатами инструментов. За счёт этого система сохраняет ход рассуждения и уже собранные данные, но не заставляет исполнителя придерживаться устаревшего задания.
Протокол предусматривает и обычное завершение, и досрочную остановку. Поэтому связь с координатором становится не отдельной аварийной процедурой, а ещё одним доступным действием наряду с вызовом инструмента.
Запросы на исправление превращаются в материал для обучения
Финальная оценка всей задачи плохо объясняет, где координатор ошибся. Неудача могла начаться несколькими делегированиями раньше: координатор выдал расплывчатую цель, не передал нужный фрагмент контекста или ограничил доступ к инструменту. Один итоговый балл не указывает, какое решение надо менять.
Метод OPOD использует сообщения подагентов как промежуточную обратную связь. Когда подагент просит пересмотреть конфигурацию, система проверяет, можно ли связать возникшую проблему с прежним решением координатора. Например, неоднозначная подзадача указывает на ошибку при делегировании, а новая просьба пользователя уже не обязательно означает, что исходное решение было плохим.
Если связь подтверждается, модель формулирует текстовую подсказку: что именно в конфигурации не сработало и как это исправить. Затем та же модель получает исходную ситуацию вместе с этой подсказкой и строит улучшенное решение. Его используют как обучающий пример для координатора.
OPOD не заменяет оценку конечного результата. Обучение совмещает подсказки по отдельным решениям с итоговой наградой за выполненную задачу. Первые помогают найти локальную ошибку, вторая не даёт улучшать промежуточные действия в ущерб общей цели.
Менять архитектуру стоит для долгих и изменчивых процессов
Подход проверяли на GAIA для исследовательских задач, GAIA2 для цифрового помощника в изменяющейся среде и SWE-Bench для разработки программ. В экспериментах использовали три базовые модели подагентов и сравнивали POrchestra с одиночным выполнением, заранее заданной оркестрацией, перезапуском после завершения подагента и вмешательством по таймеру или ошибке. Такой набор охватывает несколько типов долгих задач, но результаты относятся именно к этим стендам и конфигурациям.
На GAIA2 с DeepSeek-V4-Flash POrchestra успешно решила 55,5% заданий против 44,5% у ReAct. При этом расходы на API для одной задачи оказались ниже на 36%. В отдельном опыте, где у подагента во время работы отбирали инструмент, запрос на изменение доходил до координатора в среднем через 1,67 шага.
Обучение через OPOD повысило успех небольшого координатора в среднем на 10,0% относительно других способов обучения. Разбор компонентов также показал, что системе нужны оба сигнала: просьбы подагентов помогают исправлять конкретные решения, а итоговая награда удерживает качество всей цепочки.
Для коротких процессов со стабильным набором инструментов работа не даёт причины переходить на многоагентную архитектуру. Выигрыш рос там, где выполнение занимало больше шагов и среда менялась по ходу задачи.
Если продукт уже распределяет работу между подагентами, практическое изменение локально: добавить структурированный канал пересмотра задачи и позволить обновлять конфигурацию без потери состояния. Потребуются правила, по которым исполнитель запрашивает новый инструмент или бюджет, а координатор принимает либо отклоняет запрос.
OPOD — следующий, необязательный слой. Он имеет смысл, если команда собирает собственные траектории и обучает модель координатора. Сам протокол POrchestra можно применять без этого обучения: основные замеры показывают отдельный эффект от вмешательства во время исполнения.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
