Промпт-инжиниринг для агентов: системные промпты, управление контекстом и few-shot примеры

Анатомия системного промпта агента

Системный промпт агента выполняет несколько функций одновременно: определяет роль и цель агента, описывает доступные инструменты, задаёт формат вывода, устанавливает ограничения и политики поведения.

Рекомендуемая структура системного промпта:

1. Identity: кто агент и какова его основная цель («Ты — агент для анализа данных. Твоя задача — отвечать на вопросы о данных компании, используя предоставленные инструменты»)

2. Tools: явное перечисление инструментов с описанием назначения, входных параметров и возможных ошибок

3. Workflow: предпочтительный алгоритм действий («Всегда начинай с проверки наличия данных, прежде чем вычислять метрики»)

4. Constraints: явные запреты («Никогда не изменяй данные без подтверждения пользователя»)

5. Output format: формат финального ответа

Ошибка, которую допускают большинство разработчиков на старте: слишком общий промпт без конкретных инструкций по handling edge cases. Агент, столкнувшийся с неожиданной ситуацией, без явных инструкций будет «галлюцинировать» решение вместо того, чтобы сообщить об ошибке.

Управление окном контекста

Окно контекста — критический ресурс агента. По мере выполнения задачи контекст растёт, и при достижении лимита агент либо теряет ранние сообщения, либо деградирует в качестве ответов.

Стратегии управления контекстом:

• Sliding window: удаление старейших сообщений при достижении порога. Простейший подход, но рискует потерять важный контекст задачи.
• Summarization: периодическая свёртка истории разговора в краткое резюме. Сохраняет семантическое содержание, но требует дополнительного LLM-вызова каждые N сообщений.
• Selective retention: явная маркировка «важных» элементов контекста, которые всегда сохраняются (результаты ключевых инструментов, решения пользователя).
• External memory: перенос долгосрочной памяти в векторную БД с retrieval по мере необходимости.

Для большинства production-агентов рекомендуется комбинация Summarization + Selective retention. Реализуйте автоматический триггер свёртки при использовании более 70% доступного контекста, а не при полном заполнении — это оставляет место для развёрнутых ответов инструментов.

Few-shot примеры: когда и как применять

Few-shot примеры в системном промпте агента демонстрируют не просто формат ответа, а желаемые паттерны рассуждений. Качественный few-shot пример показывает: как агент должен декомпозировать задачу, в каком порядке вызывать инструменты, как обрабатывать ошибки инструментов, как формулировать финальный ответ.

Шаблон few-shot примера для ReAct-агента:

User: Сколько заказов было обработано за прошлый месяц?
Thought: Мне нужно запросить данные о заказах за прошлый месяц. Сначала определю временной диапазон.
Action: get_date_range(period="last_month")
Observation: {"start": "2024-02-01", "end": "2024-02-29"}
Thought: Теперь запрошу количество заказов за этот период.
Action: query_orders(start_date="2024-02-01", end_date="2024-02-29", aggregate="count")
Observation: {"count": 1847}
Final Answer: За прошлый месяц (февраль 2024) было обработано 1847 заказов.

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

Техники повышения надежности

Несколько проверенных техник, которые существенно повышают стабильность агентов в продакшне:

Structured output: используйте JSON Schema или Pydantic-модели для принудительного форматирования вызовов инструментов. Большинство современных LLM поддерживают JSON mode или structured outputs нативно.

Self-consistency: для критических решений запустите агента несколько раз и выберите ответ большинством голосов. Дорого, но эффективно для high-stakes задач.

Verification step: добавьте явный шаг верификации перед финальным ответом: «Прежде чем отвечать пользователю, проверь: все ли необходимые данные получены? Нет ли противоречий в собранной информации?»

Explicit error taxonomy: перечислите в системном промпте типы ошибок и ожидаемое поведение при каждой из них. Агент, знающий о возможных типах сбоев, обрабатывает их значительно корректнее.

Итеративная оптимизация промптов

Промпт-инжиниринг для агентов — итерационный процесс. Рекомендуемый цикл: составьте baseline-промпт → прогоните на тестовом наборе задач (минимум 50 сценариев) → выявите паттерны сбоев → добавьте специфические инструкции или примеры → повторите.

Ведите changelog промптов с привязкой к метрикам качества. Изменение промпта, улучшающее один класс задач, нередко деградирует другой — автоматизированные тесты необходимы.

Используйте автоматическую оценку с LLM-as-judge для масштабируемого тестирования: попросите отдельную модель оценить корректность ответов агента по заданным критериям. Это позволяет тестировать сотни сценариев без ручной проверки.

Заключение

Промпт-инжиниринг для агентов требует системного подхода: чёткой структуры системного промпта, продуманного управления контекстом и качественных few-shot примеров с покрытием edge cases. Инвестиция времени в проработку промптов на старте проекта окупается снижением количества инцидентов в продакшне в несколько раз. Относитесь к промптам как к коду: версионируйте, тестируйте и документируйте их изменения.