Проще говоря, системный промпт - это не разовый вопрос пользователя, а постоянная инструкция для AI-системы. Пользователь может написать что угодно, но модель должна продолжать работать в рамках роли, формата и правил, заданных системным промптом.
В простом чат-боте системный промпт может описывать тон, аудиторию и формат ответа. В AI-агенте он обычно шире: цель агента, границы автономности, правила работы с RAG, tools, памятью, персональными данными, structured output, handoff и risk levels.
Системный промпт отличается от пользовательского промпта. Пользовательский промпт - это текущая просьба: "объясни", "сравни", "создай", "найди". Системный промпт задает рамку, в которой эта просьба выполняется: например, отвечать только по базе знаний, не выдумывать факты, не раскрывать внутренние инструкции и не выполнять опасные действия без approval.
Системный промпт также отличается от developer prompt. В разных платформах developer prompt может задавать инструкции разработчика поверх системных правил или рядом с ними. Практический смысл один: важные правила приложения должны быть отделены от пользовательского текста и не должны меняться обычным сообщением пользователя.
Важно: системный промпт не является полноценной защитой. Он помогает направить модель, но не заменяет backend-валидацию, права доступа, guardrails, фильтрацию документов, проверку tool calls, audit log и human-in-the-loop. Если агент может изменить сделку, отправить письмо или удалить файл, одного промпта недостаточно.
Хороший системный промпт лучше писать не как длинный манифест, а как рабочую спецификацию поведения. В нем полезно явно разделить: роль, цель, источники данных, формат ответа, запреты, правила неизвестности, правила tool calling, escalation, privacy и критерии качества.
Системный промпт нужно версионировать и тестировать. Любая правка может улучшить один сценарий и сломать другой: JSON станет невалидным, ответы станут длиннее, агент начнет чаще отказываться или хуже выбирать tools. Поэтому после изменений стоит запускать evals и regression suite.
Примеры
- Для AI-виджета системный промпт может задавать: отвечай только по базе знаний, не обещай скидки, проси контакт только после явного интереса, спорные вопросы передавай менеджеру.
- Для CRM-агента системный промпт может запретить менять стадию сделки, сумму и ответственного без approval, даже если пользователь просит сделать это сразу.
- Для RAG-ассистента системный промпт может требовать: если ответа нет в найденных источниках, честно скажи, что данных недостаточно, и не придумывай факт.
- Для агента с tool calling системный промпт может описывать, когда можно вызвать read-only tool, когда нужен draft-only режим, а когда требуется подтверждение человека.
Где используется
- задание роли и границ AI-ассистента
- единый стиль ответов в продукте
- правила работы с RAG и источниками
- ограничение tool calling и опасных действий
- настройка structured output
- правила handoff человеку
- защита от раскрытия внутренних инструкций
- тестирование поведения агента через evals
Связанные термины
Частые вопросы
Чем системный промпт отличается от обычного промпта?
Обычный промпт - это текущий запрос пользователя. Системный промпт задает постоянные правила приложения: роль, ограничения, формат ответа, источники данных и границы действий.
Можно ли защитить агента только системным промптом?
Нет. Системный промпт помогает направить модель, но безопасность должны обеспечивать backend-валидация, права доступа, guardrails, policy checks, audit log и подтверждение человека для рискованных действий.
Что обязательно включить в системный промпт AI-агента?
Минимум: роль агента, цель, что считать источником правды, формат ответа, что запрещено, когда не отвечать, когда передавать человеку, как работать с tools, RAG, памятью и персональными данными.
Почему системный промпт нужно тестировать?
Правка промпта может изменить поведение модели неожиданно: сломать JSON, ухудшить выбор инструментов, повысить отказы или ослабить безопасность. Поэтому полезны evals, regression tests и сравнение версий.
Должен ли системный промпт быть коротким?
Он должен быть настолько коротким, насколько возможно, но достаточно полным для задачи. Слишком длинный промпт дороже, медленнее и чаще содержит противоречия. Правила, которые можно проверить кодом, лучше выносить в backend.
