Почему LLM-агенты ломаются от раздутых системных промптов
Habr-эксперимент с Qwen Code показывает: раздутый системный промпт может мешать LLM-агенту выбирать tools и skills. Разбираем, где риск, а где оговорки.
По состоянию на 5 июля 2026 года системный промпт LLM-агента - это постоянный набор правил, описаний инструментов, ограничений и проектного контекста, который попадает в рабочий контекст агента вместе с пользовательской задачей. В обычном чате это часто просто инструкция о стиле ответа. В coding agent всё сложнее: там рядом живут tools, skills, правила безопасности, память проекта, команды сборки и примеры поведения.
На Habr вышел свежий эксперимент с Qwen Code: автор вычистил из системных промптов примеры, повторы и часть технологического шума, после чего на своей тестовой задаче увидел более стабильный вызов skills и сокращение prompt tokens на 35-53%. Это не доказательство, что длинные промпты всегда вредны. Но это хороший повод обсудить проблему, которую команды часто недооценивают: системный промпт LLM-агента может стать не инструкцией, а постоянным источником шума.
Если нужен базовый разбор формата и роли system prompt, сначала посмотрите наш гайд о том, как задавать системные промпты без лишнего шума. Здесь речь уже не о промптах вообще, а о том, почему они ломают именно агентные сценарии.
Что проверял автор Habr
В исходном материале автор описывает практическую проблему: CLI-агент на Qwen Code путался в задаче, добавлял лишние артефакты и плохо выбирал нужные skills. После этого он форкнул Qwen Code и радикально сократил системные промпты: убрал примеры, повторы, универсальные наставления и часть нерелевантных терминов.
Тест был прикладным. Агенту давали задачу написать простое React-приложение с загрузкой пользователей из JSONPlaceholder, навигацией по строке таблицы и MobX для состояния. В окружении были релевантные skills new-app и routing, а также специально добавленный отвлекающий skill stm, который должен был срабатывать только при явном упоминании kr-observable.
Главная оговорка стоит прямо рядом с цифрами. Автор использовал ручной yolo-режим, то есть подтверждал действия без разборов. Выборка небольшая, задача одна, набор моделей и skills частный. Поэтому корректный вывод такой: в этом эксперименте сокращение системного промпта совпало с лучшим маршрутизированием skills и меньшим расходом prompt tokens. Некорректный вывод: «удаляйте примеры из любого агентного промпта, и качество вырастет».
Почему агентный промпт хуже переносит лишний текст
У LLM-агента системный промпт работает не как красивое вступление, а как постоянная часть среды выполнения. Каждый лишний абзац конкурирует с пользовательской задачей, описаниями инструментов, файлами проекта, историей диалога и результатами команд. Чем больше агент действует сам, тем дороже становится шум.
Официальная документация Qwen Code хорошо показывает эту сложность. Qwen Code описан как агентный инструмент для терминала: он может читать кодовую базу, редактировать файлы, запускать действия и подключать внешние источники через MCP. В нём есть Agent Skills: модель сама решает, когда загружать skill по описанию, а не ждёт явной slash-команды пользователя. В документации по памяти отдельно сказано, что QWEN.md лучше работает, когда он короткий и конкретный: чем он длиннее, тем менее надёжно Qwen следует этим инструкциям.
В агенте описание инструмента - это не справка для человека. Это сигнал для выбора действия. Если рядом с ним лежат длинные примеры про другие инструменты, устаревшие названия команд или универсальные советы «всегда действуй аккуратно», модель может выбрать не тот путь. На GitHub у Qwen Code уже есть открытый issue с похожим мотивом: автор предлагает разделить постоянный system prompt и динамические system reminders, потому что смешивание уровней инструкций может приводить к путанице и галлюцинированным tool calls. Это не официальный вывод команды Qwen, но хороший пример инженерной боли.
Что добавляют в системный промпт и где это ломается
| Что добавляют | Когда помогает | Когда начинает вредить |
|---|---|---|
| Короткие правила поведения | Когда агенту нужно помнить границы: не удалять файлы, спрашивать перед опасной командой, соблюдать стиль проекта. | Когда правила повторяются разными словами и вытесняют конкретную задачу. |
| Описания tools и skills | Когда каждое описание ясно отличает один tool от другого. | Когда описания похожи, содержат общие слова вроде «помогает с разработкой» и плохо отделяют релевантный skill от соседнего. |
| Примеры использования | Когда пример короткий и показывает точный паттерн вызова активного инструмента. | Когда пример ссылается на tool, которого сейчас нет, или закрепляет старый сценарий как будто он всегда верный. |
| Проектные соглашения | Когда это команды сборки, тесты, архитектурные запреты и naming conventions. | Когда туда попадает документация, которую агент может прочитать из репозитория сам. |
| Память и история | Когда она сохраняет редкие, но важные предпочтения команды. | Когда в память попадают временные решения, старые гипотезы и уже закрытые задачи. |
Похожая проблема видна и в исследованиях длинного контекста. В работе Lost in the Middle авторы показали, что модели хуже используют информацию, когда нужный фрагмент оказывается в середине длинного контекста. В препринте Lost in the Noise тесты NoisyBench показывают, что отвлекающий контекст может резко ухудшать reasoning, RAG, alignment и tool-use задачи. Эти работы не про Qwen Code напрямую, но они подтверждают общий принцип: большой контекст сам по себе не гарантирует, что модель правильно выберет важное.
Экономия токенов - полезный сигнал, но не метрика качества
Сократить prompt tokens на 35-53% приятно. Для coding agents это уже не абстрактная экономия: мы отдельно разбирали, почему coding agents теперь считают токены. Но стоимость запроса не должна становиться единственной целью.
Плохая оптимизация выглядит так: команда вычищает промпт, агент начинает отвечать короче и дешевле, но чаще делает неверные шаги. Хорошая оптимизация проверяется по задачам: выбрал ли агент правильный skill, спросил ли уточнение, не вызвал ли лишний shell, не проигнорировал ли библиотеку, не переписал ли чужой код вместо точечной правки.
В этом смысле эксперимент Habr ценен не процентом экономии, а способом смотреть на промпт. Автор проверял не «красоту» инструкции, а поведение агента в конкретном сценарии. Это ближе к нормальной инженерной проверке, чем к спору о том, какой промпт звучит убедительнее.
Как чистить системный промпт LLM-агента
Начинать стоит не с переписывания фраз, а с инвентаризации. Разделите всё, что получает агент, на четыре слоя: постоянные правила, описания tools/skills, проектный контекст и динамические напоминания. Если слой нельзя назвать, он уже подозрителен.
- Оставляйте в system prompt только то, что агент не должен выводить из репозитория сам.
- Пишите tool descriptions так, чтобы соседние инструменты различались по триггеру, входу и ожидаемому результату.
- Удаляйте примеры с неактивными tools. Они учат модель вызывать то, чего сейчас нет.
- Держите проектные файлы вроде
QWEN.md,CLAUDE.mdилиAGENTS.mdкороткими: команды, запреты, соглашения, ссылки на живые документы. - Тестируйте промпт на 5-10 типовых задачах, а не на одном удачном ответе.
- Считайте не только prompt tokens, но и число лишних шагов, отменённых действий и уточняющих вопросов.
Отдельно следите за сжатием контекста. Если агент после compaction теряет важные ограничения, проблема может быть не только в системном промпте, но и в том, как потеря контекста ломает AI coding agents. Длинный prompt и плохая компрессия часто усиливают друг друга: первый создаёт шум, вторая может выбросить как раз нужную часть.
Мини-тест для своей команды
Чтобы понять, мешает ли системный промпт вашему агенту, не нужен большой бенчмарк. Достаточно повторяемого набора задач.
- Возьмите пять рабочих сценариев: новый компонент, багфикс, миграция тестов, правка документации, задача с нужным skill.
- Добавьте один отвлекающий skill или tool с похожим описанием, но чётким отрицательным условием.
- Прогоните официальный промпт и сокращённую версию на одинаковых задачах.
- Запишите не только итог, но и маршрут: какие tools вызваны, где агент спросил уточнение, где начал угадывать.
- Сравните prompt tokens, completion tokens и число ручных вмешательств.
Если сокращённый промпт дешевле, но чаще ошибается, вы просто урезали инструкцию. Если он дешевле и стабильнее выбирает tools, вы нашли шум. Если разницы нет, возможно, проблема живёт в описаниях skills, памяти, модели или самой постановке задачи.
Главный вывод
Системные промпты LLM-агентов нужно редактировать как кодовую зависимость: с областью ответственности, тестами и откатом. Раздутый prompt кажется безопасным, потому что в нём «на всякий случай» написано всё. В агентной среде этот запас превращается в постоянный налог на внимание модели, стоимость запроса и качество выбора tools.
Лучший системный промпт для агента обычно не самый умный, а самый различимый: он говорит, что делать, где граница и какой инструмент выбирать. Остальное лучше вынести в короткие проектные файлы, документацию или динамический контекст, который появляется только тогда, когда он действительно нужен.
