Системный промпт для агента: что работает, а что ломает поведение

За последний год системный промпт из вежливого вступления превратился в рабочий контракт между разработчиком и моделью. Anthropic в феврале 2025 опубликовала полный системный промпт Claude для веб-интерфейса — несколько тысяч слов с правилами про даты, форматирование, отказы и работу с артефактами. OpenAI и Google держат свои промпты закрытыми, но выкладывают гайды по их составлению. Причина простая: как только модель получает доступ к инструментам, памяти и внешним данным, именно системный промпт решает, будет ли агент выполнять задачу или бесконечно дёргать один и тот же поиск.

Чем системный промпт агента отличается от промпта чат-бота

Обычный чат-бот получает вопрос и отвечает текстом. Агент¹ получает задачу, сам выбирает инструменты, вызывает их, читает результат и решает, что делать дальше — иногда десятки шагов подряд. Всё это без человека в цикле. Системный промпт здесь работает не как приветствие, а как политика: когда останавливаться, что делать при ошибке инструмента, какие данные нельзя раскрывать, в каком формате отдавать результат.

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

Хороший системный промпт агента ближе к должностной инструкции, чем к приветствию: он описывает не характер, а границы полномочий и порядок действий при нештатной ситуации.

Что реально работает

Роль и границы полномочий в первых строках

Модель лучше держит инструкцию, которая стоит в начале и сформулирована как ограничение, а не пожелание. Вместо «старайся быть точным» — «если данных для ответа нет в предоставленном контексте, скажи об этом и не предполагай». Границы полезно задавать явно: какие инструменты агент вправе вызывать без подтверждения, а какие требуют шага с участием человека.

Порядок действий, а не список качеств

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

Явные правила остановки

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

Формат вывода задаётся примером

Если агент должен вернуть JSON или строго размеченный ответ, покажите образец прямо в промпте. Описание словами («верни в формате JSON») работает хуже, чем один конкретный пример структуры с полями.

Правила работы с данными

Для агентов с доступом к базам и документам через RAG² в промпт добавляют инструкцию отделять факты из контекста от собственных знаний модели и указывать источник. Это снижает выдумывание и упрощает проверку ответа.

Что ломает поведение

• Противоречивые инструкции. «Отвечай кратко» и «объясняй каждый шаг подробно» в одном промпте — модель выберет одно из двух непредсказуемо.
• Перегруженный промпт. Чем больше правил, тем выше шанс, что часть из них модель проигнорирует. Длинный контекст размывает внимание к отдельным пунктам.
• Правила без приоритета. Если не сказано, что важнее — безопасность или выполнение задачи, — при конфликте агент решит сам.
• Пользовательский ввод как инструкция. Без явного разделения «это система, а это данные пользователя» открывается дыра для prompt injection: текст из письма или веб-страницы модель может принять за команду.
• Отрицания вместо позитивных правил. «Не делай X» работает слабее, чем описание того, что делать вместо X.

Как это устроено у крупных вендоров

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

Общая тенденция у всех троих — вводить иерархию инструкций, где системный или developer-уровень приоритетнее пользовательского. Это защита от того, что пользователь текстом «забудь все инструкции» переопределит поведение агента.

Кому это пригодится и кому нет

Пригодится:

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

Скорее не нужно:

• Для разовых запросов в чате без инструментов — там хватает короткой роли, вся сложность избыточна.
• Для прототипа на выходные: сначала запустите базовый сценарий, дошлифовка промпта имеет смысл, когда появляются повторяющиеся сбои.
• Если вы используете готовую платформу с зашитым поведением и не имеете доступа к системному уровню — тогда работаете только на developer/user слое.

Мини-чеклист перед деплоем

1. Роль и границы полномочий стоят в первых строках.
2. Прописан порядок действий и условия остановки.
3. Есть пример нужного формата вывода.
4. Пользовательский ввод явно отделён от системных инструкций.
5. При конфликте правил указан приоритет (безопасность выше выполнения).
6. Промпт прогнан на адверсариальных вводах — попытках его переопределить.

¹ Агент — LLM-приложение, которое само выбирает и вызывает инструменты (поиск, API, код) в цикле, решая многошаговую задачу без участия человека на каждом шаге.

² RAG (retrieval-augmented generation) — подход, при котором модель отвечает, опираясь на подгруженные в контекст документы, а не только на знания из обучения.