Claude и граница между кодом и моделью в LLM-агентах

LLM-агенты для запросов к данным часто ломаются не из-за «слабого ИИ», а из-за размытой границы между тем, что должен решать код, и тем, что отдаётся модели. В новом разборе показывают, почему устойчивость системы зависит не от числа правил в промпте, а от архитектуры.

Почему промпт перестаёт работать

Автор разбирает знакомый сценарий: агент для text2sql, аналитики или чат-бота по базе сначала выглядит надёжным, потому что на нескольких тестовых вопросах отвечает правильно. Но как только запросы приходят в других формулировках, начинаются странности: один и тот же вопрос может получить разную обработку, а одинаковые по структуре ответы — форму строки, таблицы или графика без понятной причины.

Похожая проблема возникает и с отказами. В одном случае система даёт пояснение, в другом — молчит, хотя внешне запрос почти не отличается. Обычно разработчик пытается лечить это добавлением новых правил в системный промпт, но со временем они начинают спорить друг с другом, а нестабильность просто прячется в порядке применения инструкций.

Что лучше оставить коду, а что — модели

Главная мысль текста в том, что границу между кодом и моделью надо проектировать явно. Если этого не сделать, система сама «нарисует» её по умолчанию, и чаще всего это будет не самый устойчивый вариант. В статье подчёркивается: не стоит поручать модели то, что обычный код выполнит точнее и надёжнее.

В качестве ориентира приводится разделение из подхода Anthropic: в workflow поток задаёт заранее написанный код, а в агентном режиме модель сама направляет ход выполнения. Отдельно упоминается и маршрут запросов через cascade routing — когда дешёвая проверка сначала пытается решить задачу, а при недостаточной уверенности запрос уходит на более дорогую обработку.

Почему это важно для продакшена

Текст предлагает важное правило: если запрос оказался сложнее, чем показалось сначала, его можно только перевести на более строгую и дорогую обработку, но не понижать категорию обратно. Почему это важно? Потому что ошибка повышения — это лишние ресурсы, а ошибка понижения может тихо подменить основание ответа, и потом её уже невозможно надёжно проверить задним числом.

Ещё один практический вывод касается логирования. Каждое повышение категории стоит записывать вместе с исходным и фактическим классом запроса — это помогает не только разбирать конкретные ответы, но и видеть, не устарел ли сам классификатор. Если для одного типа запросов повышений становится всё больше, значит, схема маршрутизации уже не справляется с реальностью.

Где ещё бывают скрытые ошибки

Авторы отдельно отмечают ситуацию, когда технически всё прошло без сбоев, но ответ всё равно неверный по смыслу. Например, данные могли быть связаны не по тому ключу или фильтр оказался не тем, который имел в виду пользователь. Ни проверка синтаксиса, ни контроль выполнения такой промах не поймают, потому что с точки зрения системы «ничего не сломалось».

Именно поэтому идея «добавим ещё одну проверку в промпт» не всегда спасает. Для бизнеса и команд, которые строят LLM-агентов, это означает простую вещь: надёжность чаще достигается не увеличением количества инструкций, а более жёстким разделением ролей между кодом, маршрутизацией и самой моделью.