Что ломается при запуске кодирующих агентов на маленьких локальных моделях

После нескольких недель запуска реальных многофайловых задач кодирования на маленьких локальных моделях (менее 7B) и маленьких облачных моделях на бесплатных тарифах, пользователь Reddit задокументировал стабильные точки отказа, выходящие за рамки типичного шума бенчмарков. Вот что на самом деле ломается.

Ограждения Markdown — самая частая проблема

Даже с "выводить только сырой код, без форматирования Markdown" в системном промпте, большинство моделей оборачивают ответы в тройные обратные кавычки. Qwen3.5:9b и Gemma4:e4b следуют инструкциям наиболее последовательно, но все равно иногда сбиваются. Исправление — не в улучшении промпта, а в удалении ограждений на этапе постобработки по умолчанию.

Структурированный вывод ненадежен ниже 7B

Когда агентам требуется JSON для списков задач или типов действий, маленькие модели ошибаются гораздо чаще, чем показывают бенчмарки. Бенчмарки тестируют валидный JSON; реальное использование добавляет сложные многошаговые инструкции с краевыми случаями. Gemma4:e4b — самая надежная среди локальных моделей; Qwen3.5:9B немного отстает. Codellama справляется хуже. В облаке Llama 3.3 70B на Groq абсолютно надежна. Практическое решение: проверять JSON, повторять попытку с явной инструкцией, затем переходить на снисходительный парсер, извлекающий JSON из текста.

Модели редактируют не тот файл

Дайте маленькой модели задачу переименовать validateToken в verifyToken с картой проекта, содержащей похожие имена, и она может переименовать validateUser или изменить вообще не тот файл. Модель воспринимает карту проекта как предложения, а не ограничения. Исправление на уровне оркестрации: проверять, что пути к файлам существуют, а имена функций есть в указанных файлах. Выдавать ошибки при несоответствии — маленькие модели уверенно врут.

Классификация вопроса и действия

Вопрос «сколько строк в utils.js» должен быть только для чтения. Но если у исполнителя есть только один режим редактирования, он отредактирует файл, вставив туда ответ. Исправление: планировщик должен классифицировать запросы по типам действий до выполнения. Запросы только для чтения направляются на отдельный путь, который никогда не затрагивает диск.

Что работает лучше ожидаемого

• Контроль токенов в коде: подсчитывайте токены перед каждым вызовом; маленькие модели не имеют понятия о лимитах контекста и не будут краткими, если им доверять.
• Изоляция по файлам: отправка одного файла за раз значительно надежнее, чем двух — модели путают исправления.
• Синтезная память: храните одно предложение о том, что сделала модель, а не полный список задач. Работает для отмены и добавления запросов.

Еще предстоит выяснить

Возможна ли какая-либо локальная модель менее 7B для роли агента — автор не нашел такую, которая не ошибалась бы в структурированном выводе достаточно часто. Открытый тестовый фреймворк на github.com/razvannec для вкладов.