Anti-Runaway в MAS
Популярный подход к защите от зацикливания (anti-runaway) в мультиагентных системах (MAS) — повесить контроль на глобальный оркестратор графа. Настраиваются max_loops, выставляются глобальные таймауты, внедряются circuit breakers на уровне переходов. Это необходимый слой безопасности, но он борется с симптомами, а не с причиной. Глобальный оркестратор не знает истинной интенции(намерение) конкретного агента и не обладает его контекстом, поэтому принимать за него решения он не должен. Решение «пересмотреть цель или продолжать следовать плану» должно приниматься децентрализованно — внутри самого агента, на каждом его шаге
Архитектурное решение: Commitment Controller на Temporal Инженерно эта логика переносится внутрь агента в виде изолированного компонента —
Commitment Controller. Это внутреннее свойство агента, а не отдельный узел в графе оркестрации. При реализации на Temporal схема выглядит следующим образом:
1. reconsider()— легковесный детерминированный гейт. Он выполняется на каждом шаге агента и работает на чистом коде — без единого дорогого LLM-вызова.
2. classify() — триггерится только при срабатывании гейта, разделяя сбои по уровням: ↳ Провалился план? → Запускается REPLAN (детерминированная или локальная пересборка шагов; часто, дёшево). ↳ Провалилась сама цель? → Запускается REGROUND (тяжелая LLM-делиберация для валидации целеполагания; редко, дорого).
3. DROP — окончательный сброс интенции. Происходит только при подтверждении легитимных условий: цель достигнута, цель гарантированно недостижима, цель потеряла актуальность, либо появилась верхнеуровневая альтернатива с более высоким приоритетом.
Главный инвариант архитектуры: Реплан должен быть дешев и част, сброс или пересмотр цели — дорог и редок.
· 49 мин
А зачем зацикливать граф?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 36 мин
Приведен пример анти-патерн проектирования
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён