ReAct-промпт стал монолитом

Это был узел в агенте, который искал круизы и вел пользователя по процессу бронирования. Тот самый, который упоминался в посте выше.

В этом агентском цикле модель должна была делать tool calls по инструкциям, а затем отвечать пользователю.

Пока бронирований не было, всё работало нормально: агент искал круизы, уточнял параметры и показывал варианты. Алгоритм был достаточно простым.

Потом добавилась booking-логика. Причем уже заметно сложнее: с явными состояниями, переходами и запретами.

И в одном промпте оказалось сразу три ответственности:
— определить бизнес-сценарий
— выбрать и вызвать нужные инструменты
— отформатировать ответ пользователю

Сценариев становилось больше. Появлялись исключения, запреты, новые шаги логики. При этом дообучать модель мы не могли.

Пошли ошибки:
— неправильно определялись сценарии
— пропускались шаги
— игнорировались важные запреты
— да, те самые, которые написаны капсом и с восклицательными знаками

Проблема была в том, что один промпт пытался быть сразу planner’ом, tool executor’ом и formatter’ом.

Для LLM это превращается в complex instruction following: много ограничений разного типа внутри одного вызова.

Формально — один промпт.
По факту — несколько задач в одном forward pass.

Решение было не в том, чтобы еще раз “лучше написать промпт”.

Мы разделили узел на два этапа:
— planning: определить сценарий и план действий
— tool execution: выполнить нужные вызовы

После этого стало проще понимать, где ломается логика: на выборе сценария или на исполнении.

Следующий шаг — отдельно вынести presentation logic.

Главный вывод:

когда промпт начинает содержать бизнес-логику, он становится кодом.
А код нужно декомпозировать.

Благо, на моем любимчике LangGraph это легко провернуть