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

System prompt агента — это не «представься экспертом и работай хорошо». Это спецификация: что модель может, чего не может, какими инструментами располагает и что делать, когда инструмент вернул ошибку. От качества этого текста напрямую зависит, зациклится ли агент на вызове одной функции, начнёт ли выдумывать данные и как поведёт себя, когда пользователь попросит выйти за рамки задачи. Anthropic и OpenAI в своих гайдах по промптингу сходятся в одном: чем конкретнее и структурированнее инструкция, тем предсказуемее агент — и это ровно та часть, которую разработчики недооценивают.

Чем system prompt агента отличается от обычного

Для чат-бота хватает пары строк про тон и роль. Агент — это модель, которая в цикле сама выбирает действия: вызвать инструмент^*, прочитать результат, решить, что дальше. Здесь system prompt выполняет роль конституции: он живёт во всём контекстном окне^** и влияет на каждый шаг рассуждения, а не на один ответ.

^* Инструмент (tool, function calling) — внешняя функция или API, которую модель может вызвать: поиск по базе, отправка письма, запрос к календарю. Модель не выполняет её сама, а формирует запрос, который исполняет ваш код.

^** Контекстное окно — максимальный объём текста (в токенах), который модель удерживает одновременно: system prompt, история диалога, результаты вызовов инструментов. У современных моделей это от 128 тысяч до нескольких миллионов токенов.

Практическое следствие: в длинном диалоге инструкции из начала контекста «размываются». Anthropic рекомендует ключевые ограничения и формат вывода дублировать ближе к концу — например, в последнем сообщении или в напоминании перед вызовом инструмента.

Из каких блоков собрать промпт

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

1. Роль и цель. Кто агент и какую одну задачу решает. Не «универсальный помощник», а «агент поддержки, который отвечает на вопросы по возвратам в интернет-магазине».
2. Инструменты. Список функций с описанием, когда каждую вызывать и когда НЕ вызывать. Именно второе чаще спасает от лишних действий.
3. Порядок действий. Как рассуждать: сначала проверь базу знаний, потом — эскалируй человеку. Если шаги жёсткие, опишите их нумерованно.
4. Ограничения и запреты. Что нельзя: обещать сроки, которых нет в системе; выдумывать номер заказа; отвечать на темы вне задачи.
5. Формат вывода. JSON, Markdown, обычный текст. Если нужен строгий JSON — приведите схему прямо в промпте.
6. Поведение при сбое. Что делать, если инструмент вернул ошибку или пустой результат. Без этого агент часто галлюцинирует правдоподобный ответ.

Три ошибки, из-за которых агенты ломаются

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

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

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

Хороший system prompt читается не как мотивационная речь, а как должностная инструкция: что делать, чего не делать, что делать, когда что-то пошло не так.

Подходы к структуре: что советуют вендоры

Единого стандарта нет, но три распространённых подхода дают разное поведение. Выбор зависит от того, насколько жёстко вы хотите контролировать агента и какую модель используете.

Anthropic для моделей Claude отдельно рекомендует размечать секции XML-подобными тегами (например, <instructions>, <constraints>) — модель обучена обращать на них внимание. Для моделей OpenAI чаще используют Markdown-заголовки. Универсального правила нет: то, что улучшает поведение одной модели, для другой нейтрально, поэтому тестировать промпт нужно на той модели, с которой поедете в продакшн.

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

Полноценная работа над system prompt окупается не всегда. Ориентиры по сценариям:

• Пригодится: вы строите агента поддержки с доступом к базе заказов, RAG^***-ассистента по внутренним документам, автоматизацию, где агент вызывает несколько API подряд. Здесь цена ошибки — выдуманный ответ клиенту или лишний вызов платного инструмента.
• Пригодится частично: внутренний прототип для одной команды. Достаточно структурных секций без пошагового регламента — вы быстро увидите сбои сами.
• Не нужно: разовый скрипт «переформатируй текст» или чат без инструментов. Тут длинный system prompt только съедает токены и деньги за контекст.

^*** RAG (retrieval-augmented generation) — подход, при котором модель перед ответом получает релевантные фрагменты из внешней базы (документов, статей) и опирается на них, а не только на то, что «помнит». Снижает выдумывание, если правильно описать в промпте, что отвечать только по найденным данным.

Как проверить промпт перед запуском

Промпт — это код, который нельзя отладить в голове. Минимальный чек-лист:

1. Прогоните 10–15 типовых и 5 «злых» запросов (провокации, попытки увести от задачи, отсутствующие данные).
2. Проверьте, что агент честно говорит «не знаю» вместо выдумки.
3. Убедитесь, что он останавливается и не зацикливает вызовы инструментов.
4. При смене версии модели перепрогоните те же тесты — поведение может измениться даже без правок промпта.

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