Инженерия подсказок, контекста, управления и циклов: четыре уровня ИИ-агента
Инжиниринг промптов и инжиниринг контекста охватывают два из четырех уровней. Инжиниринг харнесов и циклов контролирует процессы, приводится пример триажа в GitHub, а также порядок сборки.
Источники: Prompt, context, harness, loop: the four layers of engineering an AI agent
В середине 2025 года генеральный директор Shopify Тоби Лютке написал, что настоящим навыком при работе с большими языковыми моделями совсем не является инжиниринг промптов, а предоставление достаточного количества контекста, чтобы задачу можно было разумно решить. Андрей Карпати согласился с ним, назвав это искусством, заключающимся в том, чтобы точно включить нужную информацию в окно контекста для дальнейших действий модели. Вскоре после этого термин «инжиниринг контекста» заменил «инжиниринг промптов» в большинстве серьезных обсуждений по использованию больших языковых моделей.
Через год команды, разрабатывающие автономных агентов для программирования, ботов для сортировки проблем и систем самовосстановления при развертывании, по-прежнему сталкиваются с одними и теми же трудностями. Оказалось, что инжиниринг контекста — это лишь один из аспектов четырехуровневой проблемы. С самого узкого по самый широкий уровни представляют собой пrompt, контекст, инструментарий и цикл, причем каждый из них охватывает уровень, находящийся внутри него. Два внешних уровня — инжиниринг инструментария и инжиниринг циклов — привлекают наименьше внимания, что странно, ведь именно в них сейчас заключается основная польза.
Можно рассматривать это как четыре вопроса. Как сформулирован запрос? Это и есть prompt. Что уже известно модели при ее запуске? Это контекст. Что она может делать после запуска? Это инструментарий. А когда и как часто кто-то вызывает ее? Это цикл. Сегодня основная польза заключается в цикле — уровне, у которого год назад едва было название.
Далее приведена рабочая структура для различения слоев, а также порядок их обработки. Она предполагает, что вы уже выполняли вызовы инструментов или функций через API LLM. Если нет, начните с этого.
На практике наблюдается определенный паттерн, объясняющий полезность этой структуры. Когда результат работы агента оказывается неудовлетворительным, проблема почти никогда не кроется в запросе; она всегда связана с слоем выше.
Слой 1: запрос, или то, что вы говорите
Инжиниринг запросов — это самый узкий слой, который занимается одной вещью: формулировкой инструкции для модели.
Примеры: как формулируется системный запрос, как оформляется пример с несколькими примерами, требуется ли пошаговое рассуждение или тщательное обдумывание, а также должен ли ответ приходить в формате JSON или свободного текста. Это искусство написания сообщения, заставляющего модель выполнить желаемое в следующем шаге.
Эта задача реальна. Точность выполнения одной и той же задачи может сильно различаться в зависимости от того, являютсясь ли инструкции краткими или точными. В качестве примера рассмотрим агента для сортировки задач в проекте GitHub. Слабый промпт выглядит следующим образом:
Look at this GitHub issue and label it.
И более точный вариант:
You are a triage agent for project X. For each issue, output JSON with:
component (one of the values in the taxonomy provided in context)
severity (critical | high | medium | low)
team (the owning team from the on-call table provided in context)
Base severity only on user-facing impact stated in the issue, not on your
own guess about difficulty. If the component is ambiguous, set
"component": "unknown" rather than guessing.
Модель, инструменты и всё остальное идентичны, однако при использовании второго запроса получается структурированный и обоснованный результат. Но стоит обратить внимание на то, что считается само собой разумеющимся: всё это выполняется за один шаг одного вызова. Предполагается, что таксономия и таблица дежурных инструментов уже загружены, что инструменты существуют, и что кто-то ещё определяет момент вызова модели.
Большинство учебных материалов останавливаются на этом этапе. Большинство производственных систем-агентов едва начинают развиваться на этом уровне.
Уровень 2: контекст, или то, что знает модель
Инжиниринг контекста включает всё, что попадает в «окно восприятия» модели до того, как она начнёт обрабатывать ваш запрос. Он находится на этапе, предшествующем обработке запроса. Даже идеальный запрос даёт бесполезный результат, если контекст неверен.
Это включает определение того, какие документы, файлы с кодом или записи базы данных извлекаются и вставляются, какие схемы инструментов загружаются, а какие оставляются для сохранения токенов, сколько истории разговора сохраняется, а сколько сводится к краткому изложению или удаляется, а также то, что говорят системные инструкции о роли и ограничениях модели.
Дрю Бройниг в 2025 году классифицировал способы сбоев контекста. Отравление контекстом происходит, когда галлюцинация попадает в контекст и постоянно упоминается. Развлекательный эффект контекста возникает, когда слишком длинный контекст заставляет модель опираться на него и игнорировать то, чему она научилась во время обучения. Путаница в контексте возникает, когда нерелевантный материал снижает качество вывода. Конфликт контекста происходит, когда новые инструменты или факты противоречат существующим инструкциям.
Обработка контекста также стоит денег, причем способ его кодирования влияет на сумму расходов. TOON — компактная форма кодирования модели данных JSON — согласно отчетам, к середине 2026 года позволяет сократить количество токенов примерно на 42,6% по сравнению с JSON в рамках собственных тестовых наборов, при этом точность восстановления данных составляет около 72,2% против 71,4%. Разница в затратах зависит от структуры данных: для плоских табличных данных сокращение достигает почти 59%, для смешанных вложенных данных — около 33%, а обычный формат CSV может превзойти оба варианта при полностью плоской структуре данных. Это цифры, приведенные самим проектом, поэтому проверьте их на своих данных. Главный вывод заключается в том, что одни и те же данные, представленные в трех форматах, отличаются по стоимости и по степени надежности восстановления. Инженерия контекста подразумевает не только выбор того, что включать, но и способа его кодирования.
Краткая иллюстрация показывает, как это может пойти не так. Представьте агента для генерации статей, который постоянно создаёт универсальный результат. Два дня уходит на переписывание инструкций, добавление примеров и ограничений, а также уточнение определения роли, но ситуация не меняется. Проблема никогда не была в самой инструкции. Заранее загружаются тридцать схем инструментов, которые заглушают релевантные указания. Переход на ленивую загрузку, при которой определение появляется только тогда, когда агент его запрашивает, улучшает качество без изменения ни одного слова в инструкции. Два дня были потрачены впустую.
Если инжиниринг инструкций — это выбор ваших слов, то инжиниринг контекста — это выбор того, что модель сможет увидеть до того, как вы что-либо скажете.
Уровень 3: среда выполнения, или что может делать модель
Среда выполнения — это окружающая модель исполняемая среда: всё, к чему она может обратиться, и всё, что воздействует на неё.
Известные рекомендации компании Anthropic по созданию эффективных агентов ввели понятие интерфейса агента и компьютера, намеренно схожего с интерфейсом человека и компьютера. Согласно этим рекомендациям, следует вкладывать столько же усилий в проектирование способов взаимодействия агента с инструментами, сколько отрасль вкладывает в разработку способов взаимодействия людей с программным обеспечением.
Вот упрощенное определение инструмента из примера сортировки:
{
"name": "apply_label",
"description": "Apply a label to a GitHub issue. Only use after reading the issue body and checking the component taxonomy.",
"parameters": {
"type": "object",
"properties": {
"issue_number": { "type": "integer" },
"labels": { "type": "array", "items": { "type": "string" } }
},
"required": ["issue_number", "labels"]
}
}
Поле description выполняет функции, связанные с контекстом. Оно определяет момент, когда модель обращается к инструменту, а не только аргументы, которые она передаёт. Однако схема представляет собой лишь половину всей структуры.
Другая половина находится в оркестраторе, который оборачивает инструмент элементами, недоступными для модели. Механизм утверждения решает, будет ли функция apply_label выполняться автоматически или будет ожидать в очереди человека. Ограничение скорости, например 60 записей меток в час, предотвращает бесконтрольный цикл, приводящий к спаму в репозитории. Границы песочницы ограничивают возможности инструмента. Такие обёртки формируют поведение без каких-либо изменений в системном промпте.
Структура также включает в себя:
- Файловую систему. Файлы, которые модель может открывать, редактировать, создавать или удалять.
- Память. Способ хранения и извлечения информации между этапами работы, такой как журналы корректировок, прошлые решения и стандарты проекта.
Если предоставить среднему запросу хорошие инструменты, он обычно покажет лучшие результаты, чем блестящий запрос без инструментов. Агент, который не может открыть необходимый файл, не получит никакой пользы от улучшения формулировок. Сначала необходимо обеспечить доступ к инструментам.
Уровень 4: цикл, или то, что делает агента автономным
Инженерия циклов — это механизм, делающий агента автономным. Он действует, наблюдает за результатом, принимает решение о дальнейших действиях и продолжает работу до достижения цели или срабатывания условия остановки, при этом на каждом шаге не требуется участие человека. Этот уровень превращает чат-бота, использующего инструменты, в существо, способное самостоятельно решать проблемы.
Вот та же идея в виде псевдокода. Он носит иллюстративный характер и не может быть запущен: помощники вроде model.decide и execute не учтены.
def agent_loop(goal, max_iterations=10):
context = gather_initial_context(goal)
consecutive_errors = 0
for i in range(max_iterations):
action = model.decide(context, goal)
if action.type == "done":
return action.result
result = execute(action)
if result.error:
consecutive_errors += 1
if consecutive_errors >= 3:
# stuck: same approach keeps failing, decompose differently
context.add("Previous approach failed 3 times. Try a different strategy.")
consecutive_errors = 0
else:
consecutive_errors = 0
context.add(result)
return escalate_to_human(context)
В нескольких строках содержатся решения, имеющие значение: когда остановиться, когда изменить стратегию, когда сдаться. В апреле 2026 года компания OpenAI встроила эту схему в продукт, добавив команду /goal в интерфейс Codex CLI. Вы задаёте цель, и система продолжает работу до тех пор, пока не сочтёт её достигнутой или не исчерпает лимит токенов.
Примитивный цикл пытается снова и снова, пока что-то не сработает. Хорошо спроектированный цикл замечает, что застрял, переосмысливает проблему по-другому, обращается за помощью к человеку или отказывается от неэффективного подхода. Дизайнер Мэтт Уэбб в марте 2026 года отметил, что агент, получивший задачу и цикл while, в конечном итоге её решит. Именно слово «в конечном итоге» определяет уровень инженерной реализации: лимиты на попытки, задержки после многократных неудач и стратегии разбиения задачи на части в случае застоя при одной попытке решения.
Именно поэтому этый уровень представляет собой наибольшую смену в распределении полномочий. При использовании методов инжиниринга промптов человек пишет каждую инструкцию. При инжиниринге контекста человек решает, что будет видеть модель при каждом вызове. При инжиниринге инструментов человек создает инструменты один раз, а модель использует их бесконечно. Инжиниринг циклов отличается по своей сути: человек проектирует систему, которая формирует промпты для модели, оценивает результат и снова вызывает модель, причем в процессе нет никаких людей. Контроль переходит от того, кто формирует промпты для агента, к тому, кто спроектировал систему, осуществляющую эти промпты.
В середине 2026 года Джон Уделл предложил полезную формулировку: он не любит выражение «человек в цикле», потому что оно передает полномочия машинам, хотя на самом деле это по-прежнему наш цикл, и мы теперь привлекаем агентов для участия в команде.
Все четыре уровня в одном агенте: сортировка задач на GitHub
Представьте агента, который обрабатывает новые проблемы в GitHub для проекта с открытым исходным кодом среднего размера: он присваивает метки компоненту, оценивает степень серьезности и направляет каждую проблему в соответствующую команду.
- Подсказка. Системная подсказка указывает ему найти затронутый компонент, оценить степень серьезности от критической до низкой, назначить правильную команду и ответить в формате структурированного JSON.
- Контекст. Для каждого решения система предоставляет заголовок и текст проблемы, пять последних комментариев, таксономию компонентов (файл YAML, обновляемый ежеквартально), ранее возникшие похожие проблемы с их метками (получаемые с помощью векторного поиска в качестве примеров) и информацию о человеке, находящемся на дежурстве.
Каждые 100 выпусков система сравнивает свою точность с ручными корректировками людей и корректирует свои пороговые значения. В аналогичной системе порог уверенности, по сообщениям, приходилось начинать с 0,85, а не с предполагаемых 0,7, поскольку неверные метки создавали больше работы для людей, чем пропущенные. Такой тип калибровки называется инженерией циклов: его можно обнаружить только путем запуска системы и наблюдения за её ошибками со временем.
Если убрать хотя бы один слой, система будет работать иначе. Без подсказок формат вывода становится угадыванием. Без контекста придумываются названия компонентов. Без инструментов система может понять, что делать, но не может ставить метки или выполнять поиск. Без циклов у вас остается ассистент, который действует только тогда, когда кто-то вводит фразу «определить приоритет этой проблемы» в окно чата, по одной проблеме за раз.
Откуда берётся словарный запас
Термин «инжиниринг промптов» появился в 2022 году. Ещё в 2023 году Райли Гудсайд предложил разделить его на инжиниринг контекста и программирование промптов, но этот термин закрепился лишь после того, как в июне 2025 года Лютке и Карпати использовали выражение «инжиниринг контекста», а Саймон Уиллисон объяснил, почему оно более подходит.
Термины «использование ресурсов» и «вспомогательные структуры» вошли в обиход благодаря работам компании Anthropic над эффективными агентами, которые сформализовали интерфейс между агентом и компьютером и рассматривали проектирование инструментов как важную часть инженерии.
Инженерия циклов является самой молодой из четырех категорий, и никто её не придумал. Она возникла в результате слияния нескольких подходов: целево-ориентированных циклов в Codex от OpenAI, разделения на рабочие процессы (фиксированные пути) и агентов (циклы, управляемые моделью) от Anthropic, развития LangChain от маршрутизатора до машин состояний и автономных агентов, а также распространённой практики, при которой человек проектирует цикл, не вмешиваясь в его отдельные этапы.
Упомянутое здесь четырёхуровневое деление является синтезом этих совпадающих подходов, а не отраслевым стандартом. Тем не менее наименование уровней ускоряет диагностику. Вопрос о том, связана ли проблема с подсказками, контекстом, инструментами управления или самим циклом, сразу сужает круг поиска.
Куда инвестировать в первую очередь
Уровни перечислены от наиболее узкого к наиболее широкому, но их следует создавать сначала в наиболее широком виде, а точнее — сначала разрабатывать инструменты управления. Для первого автономного кодингового агента порядок будет следующим.
- Инструментарий. Необходимы возможности для чтения и записи файлов, доступ к оболочке, способ запуска тестов и команд git. Агент, не занимающийся программированием, получает вместо этого вызовы API, запросы к базе данных или возможность обмена сообщениями; суть остаётся прежней.
- Цикл. Даже примитивный цикл помогает: запустить процесс, проверить, прошли ли тесты, в случае неудачи вернуть ошибку, а после трёх попыток или при успехе завершить работу. Уже это обеспечивает большую часть преимуществ автономности.
- Контекст. После наблюдения за работой агента в цикле становится ясно, чего ему не хватает — будь то код, прошлые ошибки или стандарты проекта. Предполагать заранее в основном лишь тратит время.
- Подсказки. При наличии рабочего инструментария и цикла необходимые подсказки обычно бывают краткими и простыми. Сложная инженерная работа к тому времени уже выполнена где-то ещё.
Есть одно исключение. Если агенту необходимо генерировать текст в строго определённом формате, например структурированный JSON для API или текст в соответствии с определёнными правилами Markdown, заранее продуманные инструкции критически важны, поскольку исправление нарушений формата в процессе работы сложно. Это особый случай, а не стандартная практика.
Новички обычно меняют порядок действий: они тратят недели на создание сложных системных инструкций, в то время как у агента ещё нет никаких инструментов, циклов, а в его контексте находятся неправильные файлы.
Переход от составления инструкций к разработке контекста означает признание того, что материал, предоставляемый модели, имеет большее значение, чем формулировка запроса. Переход к разработке механизмов использования модели и циклов подразумевает ещё большее признание: тот, кто создаёт систему, окружающую модель, обладает большей властью, чем тот, кто с ней общается.
Связанные материалы
- Инженерия контекста для агентов: пошаговое руководство для инженеров машинного обучения: как спроектировать то, что видит агент на каждом этапе — получение информации, структурированный контекст, память, компрессия и оценка, с примером использования агента для отладки моделей машинного обучения.
- От модели без примеров к самоконсистентности: практическая иерархия техник формулировки запросов: как выбирать между подходами без примеров, с небольшим количеством примеров, декомпозицией, циклами критики и запросами для рассуждений, с примером бота-помощника, и когда лучше использовать обычный код.