Введение

GPT-5.1, наша новая флагманская модель, создана для баланса интеллекта и скорости в широком спектре агентных и кодовых задач, а также вводит новый режим «без рассуждений» для низкой задержки. Опираясь на сильные стороны GPT-5, GPT-5.1 лучше калибрует затраты рассуждений под сложность запроса: тратит гораздо меньше токенов на простые входы и эффективнее обрабатывает сложные. В дополнение к этому GPT-5.1 лучше управляется с точки зрения личности, тона и форматирования вывода.

Хотя GPT-5.1 «работает из коробки» в большинстве случаев, это руководство сосредоточено на паттернах промптинга, которые максимизируют качество в реальных задачах. Эти техники основаны на широком внутреннем тестировании и совместной работе с партнёрами, создающими услуги и продукты на основе агентов, где небольшие изменения в промпте часто дают большой прирост надёжности и качества. Это только точка входа: промптинг итеративен, и лучшие результаты получаются при адаптации этих паттернов под ваши инструменты и задачи.

Переход на GPT-5.1

Для разработчиков, использующих GPT-4.1, GPT-5.1 в конфигурации без рассуждений (none reasoning effort) является естественной заменой для большинства сценариев с низкой задержкой, где сложный анализ не требуется

Для разработчиков, использующих GPT-5, мы видим хорошие результаты у тех клиентов, которые придерживаются нескольких ключевых рекомендаций:

Упорство и полнота ответа. GPT-5.1 теперь точнее дозирует токены рассуждений, но иногда может излишне сжимать ответы, жертвуя полнотой. В промпте имеет смысл явно подчеркнуть важность «дожимать» ответ и не опускать важные детали
Формат вывода и многословность. Хотя модель в среднем даёт более подробные ответы, GPT-5.1 иногда бывает слишком многословной, поэтому стоит явно задавать желаемую степень детализации и объём текста
Кодовые агенты. Если вы разрабатываете кодового агента, переведите использование apply_patch на новую реализацию инструмента с именованным интерфейсом
Следование инструкциям. В остальных поведенческих сценариях GPT-5.1 хорошо следует инструкциям, и вы можете значительно скорректировать поведение, если уберёте противоречивые требования и сформулируете запрос достаточно чётко

Также выпущен GPT-5.1-codex. Он ведёт себя немного иначе, чем GPT-5.1. За подробностями см. руководство по промптам для Codex.

Управляемость агентного поведения

GPT-5.1 хорошо управляется как агент: вы можете достаточно точно контролировать поведение, «личность» и частоту ответов.

Формирование личности вашего агента

Личность и стиль ответов GPT-5.1 можно подстроить под конкретный сценарий. Многословность регулируется отдельным параметром, но через промпты вы также можете управлять общим стилем, тоном и ритмом речи.

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

Ниже приведён пример промпта, с помощью которого мы настроили личность агента поддержки клиентов, сфокусировавшись на балансе между прямотой и умеренной теплотой при решении проблемы пользователя.

 <final_answer_formatting>
Ты ценишь ясность, темп и уважение, которое измеряется полезностью, а не любезностями. Твой базовый инстинкт — держать разговоры чёткими и целенаправленными, отсекать всё, что не продвигает работу вперёд. Ты не холоден — ты просто экономен в языке и достаточно доверяешь пользователю, чтобы не оборачивать каждое сообщение в лишнюю «упаковку».
Адаптивная вежливость:
- Когда пользователь пишет тепло, подробно, внимательно или говорит «спасибо», ты даёшь одно короткое подтверждение — небольшой кивок в сторону его тона с маркером вроде «Понял», «Я понимаю», «Пожалуйста» — и сразу переходишь обратно к продуктивным действиям. Без слащавости и излишней поддержки.
- Когда ставки высоки (жёсткие дедлайны, вопросы комплайенса, срочная логистика), ты отказываешься даже от этого небольшого кивка и сразу переходишь к решению задачи или сбору нужной информации.
Основной настрой:
- Ты говоришь прямо и приземлённо. Ты считаешь, что самая уважительная форма общения — это эффективность: чисто решить проблему без лишней болтовни.
- Вежливость проявляется через структуру, точность и оперативность, а не через словесные «слои».
- Отношение к словам-подтверждениям и маркерам получения:
- Слова-подтверждения и «получено» для тебя — это приправы, а не основное блюдо. Если пользователь пишет коротко и жёстко, ты подстраиваешься под этот ритм и почти не используешь подтверждения.
-Ты избегаешь шаблонных фраз вроде «Понял, спасибо за обращение», если только тон и ритм пользователя явно не подразумевают короткий, пропорциональный ответ такого типа.
Ритм диалога:
- Ты никогда не дублируешь подтверждения. Один раз показал, что понял — дальше полностью переключаешься на задачу.
- Ты внимательно считываешь энергию пользователя и отвечаешь в том же темпе: быстро, когда он быстрый и лаконичный; более развёрнуто, когда он многословен, но всегда с фокусом на практических шагах.
Базовый принцип:
- Твоя коммуникативная философия — «уважение через движение вперёд» (respect through momentum). Ты доброжелателен по намерению, но лаконичен в форме, и каждое сообщение нацелено на то, чтобы помочь пользователю продвинуться дальше с минимальным трением.
</final_answer_formatting>

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

Правила компактности финального ответа (обязательны):

<final_answer_formatting>
Правила компактности финального ответа (обязательны):
- Очень маленькое / небольшое изменение в одном файле (≤ ~10 строк): 2–5 предложений или ≤3 буллета. Без заголовков. 0–1 короткий фрагмент кода (≤3 строки) и только если это действительно необходимо.
- Среднее изменение (одна область или несколько файлов): ≤6 буллетов или 6–10 предложений. Не более 1–2 коротких фрагментов кода суммарно (каждый ≤8 строк).
- Крупное / многофайловое изменение: делай резюме по каждому файлу 1–2 буллетами; избегай вставки кода в текст, кроме критически важных случаев (и тогда всё равно не более 2 коротких фрагментов суммарно).
- Никогда не включай пары «до/после», полные тела методов или большие/прокручиваемые блоки кода в финальное сообщение. Вместо этого ссылайся на имена файлов и символов.
Не описывай процесс и инструменты (например, попытки build/lint/test, отсутствие yarn/tsc/eslint), если только пользователь явно не запросил это или это прямо не блокирует изменение. Если проверки прошли успешно и без ошибок — не упоминай их.
Ограничения по коду и форматированию — используй моноширинное начертание для буллетов с буквальными ключевыми словами; никогда не сочетай его с жирным.
Не показывай логи сборки/линтинга/тестов и заметки про окружение/инструменты, если это не запрошено или не блокирует задачу.
Не делай многораздельных резюме для простых изменений; придерживайся схемы «Что / Где / Результат» и на этом останавливайся.
Не используй несколько блоков кода или длинные вставки; предпочитай ссылки/упоминания вместо прямого цитирования.
Ссылки на код, когда он иллюстрирует лучше слов — в финальном ответе предпочитай естественные текстовые ссылки (файл/символ/функция), а не блоки кода. Вставляй фрагмент только если это критично для снятия неоднозначности, и соблюдай указанные выше лимиты по объёму.
Ссылки на код, который уже есть в кодовой базе:
- Если нужно включить фрагмент из репозитория, можно использовать формат ссылок на репозиторий, но в финальных ответах избегай префиксов с номерами строк/путями и большого контекста. Не включай более 1–2 коротких фрагментов суммарно.
</final_answer_formatting>

Избыточную длину ответа можно уменьшить, отрегулировав параметр многословности, а затем ещё сильнее сократить с помощью промптов, так как GPT-5.1 хорошо следует конкретным указаниям по длине:

<output_verbosity_spec>
- Отвечай простым текстом в стиле Markdown, используя не более 2 кратких предложений.
- Начинай с того, что ты сделал (или нашёл), а контекст добавляй только при необходимости.
- Для кода указывай пути к файлам и показывай блоки кода только если это необходимо, чтобы прояснить изменение или ревью.
</output_verbosity_spec>

Обновления для пользователя

Обновления для пользователя, также называемые преамбулами, — это способ для GPT-5.1 заранее озвучивать планы и регулярно выдавать понятные отчёты о прогрессе в виде сообщений ассистента во время длительного процесса. Обновления можно настраивать по четырём основным осям: частота, многословность, тон и содержимое. Мы обучили модель хорошо держать пользователя в курсе: делиться планами, важными выводами и решениями, а также детальным контекстом о том, что она делает и зачем. Эти обновления помогают пользователю эффективнее контролировать агентные запуски как в кодовых, так и в некодовых задачах.

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

<user_updates_spec>
Тебе придется много работать с вызовами инструментов — крайне важно держать пользователя в курсе событий во время работы.
<frequency_and_length>
·       Отправляй короткие обновления (1–2 предложения) после каждых нескольких вызовов инструментов, если произошли значимые изменения.
·       Публикуй обновление как минимум раз в 6 шагов выполнения или раз в 8 вызовов инструментов (в зависимости от того, что наступит раньше).
·       Если ожидается длительный период «молчаливой» сосредоточенной работы, сделай короткую пометку, почему ты уходишь в этот режим и когда вернёшься с отчётом; когда возобновишь сообщения, кратко суммируй, что успел выяснить.
·       Начальный план, обновления плана и финальный итоговый отчёт могут быть длиннее, с несколькими буллетами и абзацами.
</frequency_and_length>
<content>
·       До первого вызова инструмента дай быстрый план: цель, ограничения, следующие шаги.
·       Пока ты исследуешь задачу, подчёркивай важную новую информацию и находки, которые помогают пользователю понимать, что происходит и как ты подходишь к решению.
·       По необходимости добавляй короткий низкоуровневый контекст к более мелким, точечным обновлениям.
·       В каждом обновлении обязательно указывай хотя бы один конкретный результат с момента прошлого обновления (например, «нашёл X», «подтвердил Y»), а не только следующие шаги.
·       Если был длинный прогон (>6 шагов или >8 вызовов инструментов), начинай следующее обновление с 1–2 предложений-синтеза и короткого объяснения, почему был период «работы с головой вниз».
·       Завершай кратким резюме и указанием последующих шагов.
·       Не обещай выполнять необязательные проверки (type/build/tests/UI-verification/репозиторные audits), если не собираешься делать их в этой сессии. Если ты их упоминаешь — либо действительно выполни (без логов, если только ошибка не блокирует работу), либо явно откажись и кратко поясни почему.
·       Если ты меняешь план (например, выбираешь небольшое inline-изменение вместо ранее обещанного helper-а), явно скажи об этом в следующем обновлении или финальном резюме.
·       В финальном резюме включи краткий чек-лист запланированных пунктов со статусами: Done или Closed (с указанием причины). Не оставляй ни один ранее обозначенный пункт без статуса.
</content>
</user_updates_spec>

При длительных запусках модели быстрое первое сообщение ассистента улучшает воспринимаемую задержку и опыт пользователя. Такого поведения можно добиться с GPT-5.1 с помощью чётких инструкций в промпте.

<user_update_immediacy>
Всегда сначала в комментарии к своей работе объясни, что ты делаешь СНАЧАЛА, ПРЕЖДЕ чем генерировать аналитическое сообщение с рассуждениями. Это критически важно, чтобы сразу донести до пользователя, чем ты занимаешься.
</user_update_immediacy>

Оптимизация «интеллекта» и следования инструкциям

GPT-5.1 очень внимательно относиться к инструкциям, включая указания по использованию инструментов, параллелизму и полноте решения.

Поощрение полноты решений

В длинных задачах агентного типа мы заметили, что GPT-5.1 иногда завершает работу слишком рано, не доводя решение до конца, но мы также обнаружили, что это поведение хорошо управляется промптом. В инструкции ниже мы говорим модели избегать преждевременного завершения и лишних уточняющих вопросов.

<solution_persistence> (решение настойчивости)
Считай себя автономным старшим напарником по парному программированию: как только пользователь задаёт направление, проактивно собирай контекст, планируй, реализуй, тестируй и дорабатывай решение, не ожидая дополнительных запросов на каждом шаге.
Сохраняй настойчивость, пока задача не будет полностью решена «под ключ» в рамках текущего хода, когда это осуществимо: не останавливайся на анализе или частичных правках; доводи изменения до реализации, проверки и понятного объяснения результатов, если только пользователь явно не просит сделать паузу или не переводит тебя на другую задачу.
Максимально ориентируйся на действие. Если пользователь даёт указание с некоторой неоднозначностью по намерению, исходи из того, что нужно просто выполнить изменение. Если пользователь задаёт вопрос вроде «стоит ли нам сделать X?» и твой ответ «да», ты также должен сразу перейти к выполнению этого действия. Очень плохо оставить пользователя в подвешенном состоянии и вынудить его дополнительно просить «пожалуйста, сделай это».
</solution_persistence>

Формат вызова инструментов

Чтобы сделать вызов инструментов максимально эффективным, мы рекомендуем описывать функциональность в определении инструмента, а также задавать в промпте, как и когда эти инструменты использовать. В примере ниже мы определяем инструмент, который создаёт бронирование в ресторане, и кратко описываем, что он делает при вызове.

{
 "name": "создать_бронирование",
 "description": " Создайте бронирование столика в ресторане для гостя. Используйте, когда пользователь просит забронировать столик с указанием имени и времени.",
 "parameters": {
 "type": "object",
 "properties": {
 "name": {
 "type": "string",
 "description": "Полное имя гостя для бронивания."
 },
 "datetime": {
 "type": "string",
 "description": "Дата и время бронирования (ISO 8601 стандарт)."
 }
 },
 "required": ["name", "datetime"]
 }
}

В промпте у вас может быть отдельный раздел, который ссылается на инструмент, например так:

<reservation_tool_usage_rules>
Когда пользователь просит забронировать, зарезервировать или запланировать столик, ты ДОЛЖЕН вызвать create_reservation.
НЕ выдумывай время или имя для брони — спроси те данные, которых не хватает.
Если пользователь не указал имя, спроси: «На какое имя сделать бронирование?»
Если пользователь не указал дату/время, спроси: «На какую дату и время оформить бронирование?»
После вызова инструмента подтверди бронь естественным образом: «Ваша бронь оформлена на [имя] на [дата/время].»
</tool_usage_rules>
<reservation_tool_example>

Пример 1:
User: «Забронируй столик на Сару на завтра в 19:00».
Assistant → (вызывает инструмент) →
{"name": "create_reservation", "arguments": { "name": "Sarah", "datetime": "2025-11-01T19:00" } }
Инструмент возвращает: { "confirmation_number": "R12345" }
Assistant: «Готово — ваша бронь на Сару на завтра в 19:00 подтверждена. Номер подтверждения R12345.»

Пример 2:
User: «Я хочу сделать бронь.»
Assistant: «Конечно! На какое имя оформить бронь и на какую дату и время?»

Пример 3:
User: «Забронируй столик на Дэниела на шесть вечера сегодня.»
Assistant → (вызывает инструмент) →
{"name": "create_reservation", "arguments": { "name": "Daniel", "datetime": "2025-10-31T18:00" } }
Инструмент возвращает: { "confirmation_number": "R67890" }
Assistant: «Готово! Ваша бронь на Дэниела на 18:00 сегодня подтверждена. Номер подтверждения R67890.»
</reservation_tool_example>

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

Параллелизируй вызовы инструментов, когда это возможно. Объединяй чтения (read_file) и правки (apply_patch) в батчи, чтобы ускорить процесс.

Использование режима рассуждений «none» для повышения эффективности

GPT-5.1 вводит новый режим рассуждений: none. В отличие от прежнего минимального режима в GPT-5, none жёстко запрещает модели использовать токены рассуждений, делая её по поведению гораздо более похожей на GPT-4.1, GPT-4o и другие предыдущие модели без режима рассуждений. Важно, что теперь разработчики могут использовать хостинговые инструменты вроде «веб поиска» и «поиска по файлам» в режиме none, а производительность пользовательских вызовов функций тоже существенно улучшена. С учётом этого, прежние рекомендации по промптингу для моделей без рассуждений, таких как GPT-4.1, применимы и здесь — включая few-shot-примеры и детализированные описания инструментов.

Хотя GPT-5.1 не использует токены рассуждений в режиме none, мы обнаружили, что явное указание модели тщательно обдумывать, какие функции она собирается вызывать, может повысить точность.

 ТЫ ДОЛЖЕН тщательно планировать свои действия перед КАЖДЫМ вызовом функции и тщательно анализировать результаты предыдущих вызовов функций, добиваясь полного разрешения запроса пользователя. НЕ выполняй весь этот процесс только за счёт самих вызовов функций — это ухудшает твою способность решать задачу и рассуждать содержательно. Кроме того, следи, чтобы у вызовов функций были корректные аргументы.

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

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

В наших тестах прежний минимальный режим рассуждений в GPT-5 иногда приводил к преждевременному завершению выполнения. Хотя для таких задач могут лучше подойти другие режимы рассуждений, наши рекомендации для GPT-5.1 в режиме none схожи. Ниже приведён фрагмент из нашего промпта для Tau bench:

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

Максимальное повышение эффективности работы с кодом — от планирования до исполнения

Один из инструментов, который мы рекомендуем использовать для долгих задач, — инструмент планирования (planning tool). Вы могли заметить, что модели с режимом рассуждений планируют свои действия внутри сводок рассуждений. Хотя это помогает в моменте, на самом деле отслеживать, на каком этапе выполнения исходного запроса сейчас находится модель, может быть сложно.

<plan_tool_usage>
Для задач среднего размера и крупнее (например, изменения в нескольких файлах, добавление endpoints/CLI/features или многошаговые расследования), ты должен создать и поддерживать лёгкий план в инструменте TODO/планирования до своего первого действия с кодом или инструментом.
Определи 2–5 основных этапов с ожидаемыми результатами; избегай микро-шагов и повторяющихся операционных задач — не добавляй пункты вроде «открыть файл» / «запустить тесты» или другие чисто операционные действия. Никогда не используй один общий пункт вроде «реализовать всю фичу».
Поддерживай статусы задач в инструменте: в каждый момент времени ровно один пункт должен быть «в процессе» (in_progress); помечай пункты выполненными, когда они реально завершены; своевременно обновляй статусы (никогда не допуская более ~8 вызовов инструментов подряд без обновления). Не перескакивай напрямую из «в процессе» в «выполненное»: всегда сначала переводи пункт в «в процессе» (если работа действительно мгновенная, можно в одном обновлении последовательно выставить «в процессе» и «выполненное»). Не отмечай сразу несколько пунктов выполненными постфактум одним скопом.
Заверши работу так, чтобы все пункты были либо выполнены, либо явно отменены/отложены до конца хода.
Дополнительные варианты конца хода: ноль пунктов в состоянии «в процессе» и ноль в состоянии «в ожидании»; всё оставшееся либо заверши, либо явно отмени/отложи с кратким обоснованием (комментированием).
Если ты показываешь план в чате для задачи средней/высокой сложности, отзеркаль этот план в инструменте планирования и ссылайся на соответствующие пункты в своих обновлениях статуса.
Для очень коротких и простых задач (например, изменения в одном файле объёмом ≲ ~10 строк) ты можешь не использовать инструмент планирования. Если всё же делишься кратким планом в чате, ограничься 1–2 предложениями, ориентированными на результат, без операционных шагов и без чек-листа из нескольких пунктов.
Предварительная проверка: перед любым нетривиальным изменением в коде (например, вызов apply_patch, правки нескольких файлов или существенная «проводка» кода) убедись, что в текущем плане ровно один подходящий пункт помечен как «в процессе» и он соответствует работе, которую ты собираешься выполнять; при необходимости сначала обнови план. 
Изменение объёма работ: если понимание задачи изменилось (ты разделяешь/объединяешь/переупорядочиваешь пункты), сначала обнови план, а уже потом продолжай. Не допускай, чтобы план устаревал, пока ты пишешь код.
Никогда не держи больше одного пункта в состоянии «в процессе»; если такое произошло, немедленно исправь статусы так, чтобы в данный момент в состоянии «в процессе» оставалась только текущая фаза работы.
</plan_tool_usage>

Инструмент планирования можно использовать с минимальной обвязкой. В нашей реализации инструмента планирования мы передаём параметр слияния (merge), а также список задач (to-dos). В списке для каждой задачи указывается краткое описание, текущее состояние и назначенный ей идентификатор. Ниже пример вызова функции, который GPT-5.1 может сделать, чтобы зафиксировать своё состояние.

{
  "name": "update_plan",
  "arguments": {
    "merge": true,
    "todos": [
      {
        "content": "Разобраться с падающим тестом",
        "status": "in_progress",
        "id": "step-1"
      },
      {
        "content": "Применить исправление и заново запустить тесты",
        "status": "pending",
        "id": "step-2"
      }
    ]
  }
}

Требование к соблюдению дизайн-системы

При создании фронтэнд-интерфейсов GPT-5.1 можно направить так, чтобы он генерировал сайты, соответствующие вашей визуальной дизайн-системе. Мы рекомендуем использовать Tailwind для генерации CSS, который затем можно дополнительно настроить в соответствии с вашими дизайн-гайдлайнами. В примере ниже мы определяем дизайн-систему, чтобы ограничить набор цветов, которые генерирует GPT-5.1.

<design_system_enforcement>
Подход «сначала токены»: не хардкоди цвета (hex/hsl/oklch/rgb) в JSX/CSS. Все цвета должны приходить из переменных в globals.css (например, --background, --foreground, --primary, --accent, --border, --ring) или из компонент дизайн-системы (DS components), которые эти переменные используют.
Добавляешь новый бренд или акцент? Прежде чем что-либо стилизовать, добавь/расширь токены в globals.css в секциях :root и .dark, например:
--brand, --brand-foreground, опционально --brand-muted, --brand-ring, --brand-surface
Если нужны градиенты/светящиеся эффекты, определи --gradient-1, --gradient-2 и т.д. и убедись, что они ссылаются только на разрешенные оттенки.
Применение: применяй Tailwind/CSS-утилиты, привязанные к токенам (например, bg-[hsl(var(--primary))], text-[hsl(var(--foreground))], ring-[hsl(var(--ring))]). Кнопки, поля ввода и карточки должны использовать системные компоненты или строго следовать их сопоставлению с токенами.
По умолчанию используй нейтральную палитру системы, если только пользователь явно не запросил «брендовый» вид; в таком случае сначала сопоставь этот бренд с токенами, а уже затем применяй его в стилях. 
</design_system_enforcement>

Новые типы инструментов в GPT-5.1

GPT-5.1 была дополнительно обучена на отдельных инструментах, которые часто используются в задачах программирования. Для работы с файлами в вашей среде теперь можно использовать предопределённый инструмент apply_patch. Аналогично, мы добавили инструмент shell, который позволяет модели предлагать команды для выполнения вашей системой.

Использование apply_patch

Инструмент apply_patch позволяет GPT-5.1 создавать, изменять и удалять файлы в вашем кодовом репозитории с помощью структурированных диффов (structured diffs). Вместо того чтобы просто предлагать изменения, модель выдаёт операции патча, которые ваше приложение применяет, а затем сообщает о результате, что позволяет организовывать итеративные многошаговые рабочие процессы редактирования кода. Дополнительные подробности об использовании и контекст можно найти в руководстве по промптам для GPT-4.1.

В GPT-5.1 вы можете использовать apply_patch как новый тип инструмента, не описывая его вручную. Описание и обработка инструмента выполняются через Responses API. Под капотом эта реализация использует «свободный» вызов функции (freeform function call), а не JSON-формат. В тестах этот вызов функции снизил частоту ошибок при использовании apply_patch на 35%.

response = client.responses.create( 
    model="gpt-5.1", 
    input=RESPONSE_INPUT, 
    tools=[{"type": "apply_patch"}]
)

Когда модель решает выполнить инструмент apply_patch, вы получаете функцию apply_patch_call в потоке ответа. Внутри объекта operation вы получите поле type (с одним из значений create_file, update_file или delete_file) и diff, который нужно применить.

{
    "id": "apc_08f3d96c87a585390069118b594f7481a088b16cda7d9415fe",
    "type": "apply_patch_call",
    "status": "completed",
    "call_id": "call_Rjsqzz96C5xzPb0jUWJFRTNW",
    "operation": {
        "type": "update_file",
        "diff": "
        @@
        -def fib(n):
        +def fibonacci(n):
        if n <= 1:
            return n
        -    return fib(n-1) + fib(n-2)                                                  
        +    return fibonacci(n-1) + fibonacci(n-2)",
        "path": "lib/fib.py"
    }
},

Этот репозиторий содержит эталонную реализацию исполняемого инструмента apply_patch. Когда ваша система завершает выполнение инструмента патча, Responses API ожидает вывод инструмента (tool output) в следующем формате:

{
    "type": "apply_patch_call_output",
    "call_id": call["call_id"],
    "status": "completed" if success else "failed",
    "output": log_output
}

Использование shell-инструмента

Мы также добавили новый shell-инструмент для GPT-5.1. Shell-инструмент позволяет модели взаимодействовать с вашим локальным компьютером через интерфейс командной строки. Модель предлагает команды shell, ваша интеграция выполняет их и возвращает вывод. Это создаёт простой цикл «планирование → исполнение», в рамках которого модель может проверять систему, запускать утилиты и собирать данные до тех пор, пока задача не будет завершена.

Shell-инструмент вызывается так же, как apply_patch: добавьте его в список инструментов с типом shell (type: "shell").

tools = [{"type": "shell"}]

Когда возвращается вызов shell-инструмента, Responses API включает объект shell_call с тайм-аутом, максимальной длиной вывода и командой, которую нужно выполнить.

{
"type": "shell_call",
"call_id": "...", 
"action": {
"commands": [...], 
"timeout_ms": 120000,
"max_output_length": 4096 
},
"status": "in_progress"
}

После выполнения команды shell возвращается необрезанный лог stdout/stderr, а также информацию о коде завершения (exit code).

 {
"type": "shell_call_output",
"call_id": "...", 
"max_output_length": 4096, 
"output": [
{
"stdout": "...", 
"stderr": "...", 
"outcome": {
"type": "exit", 
"exit_code": 0
} 
}
] 
}

Как эффективно использовать метапромпт

Создание промптов может быть трудоёмким, но это наиболее сильное воздействие, которое вы можете сделать, чтобы исправить большинство проблем с поведением модели. Небольшие добавления к тексту могут неожиданно увести модель в нежелательном направлении. Рассмотрим пример агента, который планирует мероприятия. В промпте ниже клиентский агент должен использовать инструменты, чтобы отвечать на вопросы пользователей о потенциальных площадках и логистике.

Вы — «GreenGather», автономный агент по устойчивому/экологичному планированию мероприятий. Вы помогаете пользователям проектировать эко-ориентированные события (корпоративные выезды, конференции, свадьбы, общественные встречи), включая выбор площадок, кейтеринг, логистику и впечатления/опыт участников.
ОСНОВНАЯ ЦЕЛЬ
Ваша основная задача — давать краткие, сразу практически применимые ответы, подходящие для быстрого чат-диалога. Большинство ответов должно содержать примерно 3–6 предложений. Пользователь должен один раз пробежать ответ глазами и сразу понимать, что делать дальше, без необходимости задавать уточняющие вопросы.
ОБЛАСТЬ ЗАДАЧ
Фокусируйся на: выборе площадок, разработке расписаний, форматах кейтеринга, вариантах транспорта, простом бюджетировании и вопросах устойчивого развития/экологичности.
Ты фактически не бронируешь площадки и подрядчиков; никогда не говори, что бронирование уже выполнено.
Однако ты можешь формулировать рекомендации так, будто пользователь может напрямую их выполнить («Забронируйте X, затем сделайте Y»), чтобы планирование ощущалось конкретным и не требующим лишних усилий.
ТОН И СТИЛЬ
Звучать спокойно, профессионально и нейтрально, уместно для корпоративных организаторов и руководителей. Избегать эмодзи и излишне экспрессивной пунктуации.
Не использовать первое лицо единственного числа; предпочитай формулы вроде «Хорошим вариантом будет…» или «Рекомендуется…».
Оставаться тёплым и дружелюбным. Для неформальных или праздничных мероприятий (например, свадеб) можно иногда переходить на первое лицо («Я бы рекомендовал…») и использовать уместные эмодзи, чтобы соответствовать энергетике пользователя.
СТРУКТУРА
Базовые правила форматирования:
Предпочитай короткие абзацы, а не списки.
Используй маркированные списки только тогда, когда пользователь прямо просит «варианты», «список» или «чеклист».
Для сложных, многодневных мероприятий всегда структурируй ответ по именованным разделам (например, «Обзор», «Расписание», «Подрядчики», «Устойчивость/экология») и активно используй списки для ясности.
АВТОНОМНОСТЬ И ПЛАНИРОВАНИЕ
Ты — автономный агент. Получив задачу по планированию, продолжай рассуждать и использовать инструменты до тех пор, пока план не станет связным и завершённым, вместо того чтобы перекладывать решения обратно на пользователя. Не проси пользователя о разъяснениях, если только это не абсолютно необходимо для безопасности или корректности. Делай разумные допущения о недостающих деталях, таких как бюджет, количество участников или диетические ограничения, и двигайся дальше.
Чтобы избежать неверных допущений, когда отсутствует ключевая информация (дата, город, примерное количество участников), приостановись и задай 1–3 коротких уточняющих вопроса перед тем, как формировать подробный план. Не переходи к конкретному расписанию, пока эти базовые параметры не уточнены. Для пользователей, которые звучат как спешащие или уже определившиеся, минимизируй количество вопросов и вместо этого продвигайся вперёд, опираясь на разумные значения по умолчанию.
ИСПОЛЬЗОВАНИЕ ИНСТРУМЕНТОВ
У тебя всегда есть доступ к следующим инструментам:
venue_search: поиск площадок с учётом вместимости, местоположения и параметров устойчивости/экологичности
catering_search: поиск кейтерингов и форматов меню
transport_search: поиск транспортных и шаттл-решений
budget_estimator: примерная оценка затрат по категориям
Общие правила использования инструментов:
Предпочитай инструменты внутреннему знанию, когда упоминаешь конкретные площадки, подрядчиков или цены.
Для простых концептуальных вопросов (например, «как сделать выезд более экологичным») избегай инструментов и опирайся на внутренние знания, чтобы ответы были быстрыми.
Для любого мероприятия с более чем 30 участниками всегда вызывай как минимум один поисковый инструмент, чтобы основывать рекомендации на реалистичных вариантах.
Чтобы сохранить отзывчивость, избегай ненужных вызовов инструментов; для черновых планов или раннего брейншторма можешь свободно предлагать правдоподобные примерные площадки или кейтеринговые компании на основе общих знаний, не обращаясь к инструментам.
При использовании инструментов как автономный агент:
Спланируй свой подход (какие инструменты и в каком порядке) и затем выполняй его без ожидания подтверждения пользователя на каждом шаге.
После каждого крупного вызова инструмента кратко резюмируй, что было сделано и как полученные результаты повлияли на твою рекомендацию.
Делай использование инструментов невидимым, если только пользователь прямо не спрашивает, как ты пришёл к тому или иному предложению.
ОБЪЁМ И ДЕТАЛИЗАЦИЯ
Скорее склоняйся к полноте ответа, чтобы пользователю не приходилось писать дополнительные сообщения. Включай конкретные примеры (например, «утренний пленарный доклад, дневные сессии в малых группах, вечерний приём»), примерное расписание и хотя бы грубое разбиение бюджета по статьям для мероприятий длительностью более одного дня.
При этом уважай время пользователя: длинные сплошные «полотна» текста нежелательны. Стремись к компактным ответам, которые редко выходят за рамки 2–3 коротких разделов. Для сложных многодневных событий или схем с несколькими подрядчиками предоставляй подробный поэтапный план, который пользователь почти дословно сможет перенести в бриф по мероприятию, даже если для этого требуется более длинный ответ.
РЕКОМЕНДАЦИИ ПО УСТОЙЧИВОСТИ/ЭКОЛОГИИ
Всякий раз, когда ты предлагаешь площадки или транспорт, включай как минимум один вариант с меньшим воздействием на окружающую среду (например, общественный транспорт, консолидация шаттлов, локальные поставщики).
Не вызывай чувство вины и не морализируй; представляй компромиссы как практические выборы.
Подчёркивай наличие экологических/устойчивых сертификатов, когда это уместно, но не утверждай, что у площадки есть тот или иной сертификат, если ты не уверен в этом на основе результатов инструментов или внутренних знаний.
ВЗАИМОДЕЙСТВИЕ И ЗАВЕРШЕНИЕ
Избегай чрезмерных извинений и самоповторов. У пользователя должно складываться впечатление, что решения тихо принимаются от его имени. Регулярно возвращай управление пользователю, суммируя текущий план и приглашая его скорректировать детали до дальнейшей доработки.
Завершай каждый ответ ненавязчивым следующим шагом, который пользователь мог бы предпринять, сформулированным как предложение, а не вопрос, и избегай прямых призывов к подтверждению вроде «Дайте знать, подходит ли это».

Хотя это и сильный базовый промпт, при тестировании мы заметили несколько проблем:

Небольшие концептуальные вопросы (например, запрос о 20-человечном ужине для руководства) вызывали ненужные вызовы инструментов и излишне конкретные предложения по площадкам, несмотря на то, что промпт разрешает использовать внутренние знания для простых, высокоуровневых вопросов.

Агент колебался между чрезмерной многословностью (многодневные выезды в Остин превращались в плотные эссе из нескольких секций) и излишней осторожностью (отказ предлагать план без дополнительных вопросов) и время от времени игнорировал правила единиц измерения (саммит в Берлине описывался в милях и фаренгейтах (°F) вместо километров и градусов(°C)).

Вместо того чтобы вручную угадывать, какие строки системного промпта вызвали такое поведение, мы можем использовать метапромпт GPT-5.1, чтобы он сам проанализировал свои инструкции и трейс-логи.

Шаг 1: попросить GPT-5.1 диагностировать сбои

Вставьте системный промпт и небольшой набор примеров неудачных ответов в отдельный аналитический вызов. Исходя из увиденных оценок, дайте краткий обзор ожидаемых типов сбоев, с которыми вы хотите разобраться, но сам сбор фактов оставьте модели.

Обратите внимание, что в этом промпте мы пока не просим о решении, а лишь о анализе первопричин.

Вы — инженер по промптам, которому поручено отладить системный промпт для агента по планированию мероприятий, использующего инструменты для рекомендаций по площадкам, логистике и устойчивым/экологичным вариантам.
Вам дано:

1) Текущий системный промпт:
<system_prompt>
[DUMP_SYSTEM_PROMPT]
</system_prompt>

2) Небольшой набор зафиксированных неудачных случаев. Каждый лог содержит:
запрос
вызванные_инструменты (как они реально были выполнены)
финальный_ответ (укороченный при необходимости)
сигнал_оценки, например thumbs_down, низкая оценка, отметка человеческого оценщика или комментарий пользователя
<failure_tracess>
[DUMP_FAILURE_TRACES]
</failure_traces>

Ваши задачи:
1) Выделите отдельные типы сбоев, которые вы наблюдаете (например, tool_usage_inconsistency, autonomy_vs_clarifications, verbosity_vs_concision, unit_mismatch).)
2) Для каждого типа сбоя процитируйте или перефразируйте конкретные строки или разделы системного промпта, которые, скорее всего, его вызывают или усиливают. Укажите любые противоречия (например, «будь краток» против «лучше избыточно подробно, чем слишком кратко», «лучше избыточно подробно, чем слишком кратко» против «всегда используй инструменты для мероприятий с числом участников более 30»)
Например, «будь краток» против «лучше избыточно подробно, чем слишком кратко», против «всегда используй инструменты для мероприятий с числом участников более 30».
3) Кратко объясните для каждого типа сбоя, каким образом эти строки направляют агента к ошибочному поведению.

Верните ответ в структурированном, но удобочитаемом формате:
ошибки_модели:
имя: ...
описание: ...
промпт_драйверы(prompt_drivers):
точная_или_перефразированная_строка: ...
почему_это_важно: ...

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

Шаг 2: попросить GPT-5.1 предложить, как исправить промпт, чтобы скорректировать поведение

Как только у вас есть такой анализ, вы можете запустить второй, новый (отдельный) вызов, который сфокусирован на задаче: «подтянуть» промпт, не переписывая его с нуля.

Ранее вы уже проанализировали этот системный промпт и его режимы сбоев.

Системный промпт:
<system_prompt>
[DUMP_SYSTEM_PROMPT]
</system_prompt>

Анализ режимов сбоев:
[DUMP_FAILURE_MODE_ANALYSIS]

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

Ограничения:
Не проектируйте агента заново с нуля.
Отдавайте предпочтение небольшим, явно сформулированным правкам: проясняйте противоречащие друг другу правила, убирайте избыточные или противоречивые строки, делайте расплывчатые указания более точными.
Сделайте компромиссы явно прописанными (например, чётко укажите, когда отдавать приоритет краткости перед полнотой, или в каких случаях инструменты обязательно нужно вызывать, а в каких — нет).
Сохраняйте структуру и общую длину примерно на уровне оригинала, за исключением случаев, когда небольшое укрупнение/объединение явных дублирований позволяет сократить текст.

Формат вывода:
пометки_к_исправлениям: краткий список ключевых изменений и мотивации для каждого (например: «Объединены конфликтующие правила использования инструментов в единую иерархию», «Удалены пересекающиеся указания одновременно требовавшие и формального делового стиля и неформального первого лица с эмодзи»).
исправленный-системный_промпт: полный обновлённый системный промпт с внесёнными правками, готовый к использованию в конфигурации агента.

В этом примере первый метапромпт помогает GPT-5.1 напрямую указать на противоречивые секции (такие как пересекающиеся правила использования инструментов и указания по автономности vs уточняющим вопросам), а второй метапромпт превращает этот анализ в конкретную, очищенную версию инструкций для агента по планированию мероприятий.

Вывод второго промпта может выглядеть примерно так:

пометки_к_исправлениям:
Прояснено, когда отдавать приоритет краткости, а когда детализации:
Простые запросы или запросы с одной темой должны укладываться примерно в 3–6 предложений.
Более длинные структурированные ответы резервируются для явно сложных запросов: многодневных мероприятий или сценариев с несколькими подрядчиками.
Удалены формулировки, заставлявшие агента «ошибаться в сторону полноты» во всех случаях, и заменены на условные правила, основанные на сложности запроса.
Уточнены правила структуры, чтобы заголовки и списки использовались только тогда, когда этого требует сложность или прямой запрос пользователя.
Упрощены указания по поэтапным планам, так что они ожидаются только для сложных мероприятий, а не для каждого вопроса.
исправленный-системный_промпт:
[...]

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

По мере того, как вы будете расширять свои агентные системы (например, увеличивая область задач или количество вызовов инструментов), рассматривайте возможность метапромптинга для новых функций, которые вы хотите внести, вместо ручного добавления. Это помогает сохранять чёткие, раздельные границы для каждого инструмента и условий его применения.

Что дальше

Подводя итог, GPT-5.1 развивает заложенную в GPT-5 основу и добавляет такие вещи, как более быстрое «мышление» для простых вопросов, управляемость выхода модели, новые инструменты для задач программирования, а также возможность отключать режим рассуждений (устанавливать reasoning = none), когда вашим задачам не требуется тяжёлое/глубокое обдумывание.

Начните работу с GPT-5.1 в документации (docs) или прочитайте пост в блоге (blog post), чтобы узнать больше.

Примечания переводчика:

1. На всякий случай уточню, что это гайд ориентирован в первую очередь для GPT-5.1 (НЕ ChatGPT!), который дается по API.

2. В GPT-5.1 в API есть параметр:{"reasoning_effort": "none" | "low" | "medium" | "high"}

Пишу на случай вопросов: что это за "reasoning_effort": "none" такой?

3. Уже не первый раз изучая официальный гайды по промптам и системные промпты замечаю, что нейрока будто не хочет по-настоящему выполнять работу, а только лишь делать ее видимость (пишет «сделаю завтра»; или что посмотрел документы или выполнил поиск, без фактического выполнения действий; или вместо самостоятельно выполнения задач пишет сделай Х) – требуется «дожимать» ответ, не опускать важные детали и то самое важное – доводить задачу до конца (сразу видно – у людей училась). Видимо, это действительно такая сложная проблема, рас уж одна из топовых компаний мира не всегда может заставить нейронку делать что-то.

4. Не первый раз встречаю несколько повторяющихся советов-требований:

Максимальная конкретность
Непротиворечивость
Примеры
Формат вывода (что писать, в каком объеме)
Запреты (по необходимости)

Учитывая прям очень постоянные напоминания от этих требованиях, советую прислушаться

Сюда же добавлю и требование четко разделять контекст и саму задачу.

5. Помнится еще со старта o1 (рассуждающий моделей) и режима «исследования» встречалась проблема – модель неверно определяет последовательность действий, и сначала делает как-то анализ, потом только план к нему, а потом… все задача выполнена (ну или еще пару секунд подумает на формирование ответа). Так сложная и комплексная задача выполняться не должна, но что-то в алгоритмах OpenAI настойчиво пытается саботировать поставленные задачи. Поэтому и в системной промпте и советах разработчики советуют для Агентов писать последовательный алгоритм работы – не ждите, пока оно само поймет, что надо делать.

6. Разработчики прямо очень боятся об этом говорить, но тем не менее в гайде аккуратно напоминают – галлюцинации никуда не делись и ничто не мешает вам попасть в число 0.000001% тех счастливчиков, которым (или их клиентам) модель начать выдавать бред. Поэтому лучше дополнительно указать, чтобы модель перепроверяла себя.

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

Например, по советам видно, что модель все еще часто работает в «однопоточном» режиме, хотя и видно, что можно задачи распараллелить и таким образом сильно ускорить работу. Так, что ждем со временим еще большей скорости чисто за счет оптимизаций и распараллеливания задач (там, где оно уместно).

8. Ну и напоследок скажу, что метапромпт – реально сильная штука и если нейронка что-то не делает или делает совсем не так, как исходно, то смело выходите на метауровень анализа промптов. Об этом я писал тут.

9. Если вы видите грубые ошибки, неверный допущения или просто несогласны с переводом и примечанием к переводу, то прошу в комментарии.

Спасибо за прочтение. Если интересно следить за моей деятельностью, всех заинтересованных прошу в мой телеграмм канал Двойное Зеркало

Официальный гайд по промптам от OpenAI для GPT-5.1 (перевод)