Промпт, Лупа, Граф: Эволюция управления AI-агентами

В индустрии искусственного интеллекта терминология развивается с пугающей скоростью. То, что вчера было новинкой, сегодня становится стандартом, а завтра — устаревшим понятием. В середине 2026 года мы стали свидетелями уникального явления: три термина — Prompt Engineering (инжиниринг промптов), Loop Engineering (инжиниринг циклов) и Graph Engineering (инжиниринг графов) — начали конкурировать за одно и то же место в описаниях вакансий AI-инженеров. Это не просто маркетинговая шумиха. Эти понятия отражают фундаментальный сдвиг в том, как мы строим взаимодействие человека с машиной и как машины взаимодействуют друг с другом.

На первый взгляд, эти три направления кажутся конкурирующими методами решения одной проблемы: как заставить ИИ сделать то, что нам нужно. Однако глубокое погружение в архитектуру современных AI-систем показывает обратное. Это не три разных способа написать запрос. Это три разных единицы контроля, наложенных друг на друга, как слои в многослойном пироге. Промпт управляет одним ответом модели. Цикл (loop) управляет поведением одного агента во времени. Граф (graph) управляет организацией множества агентов. Каждый верхний слой сохраняет функциональность нижележащего, но меняет контекст его применения.

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

01Эволюция стека: от слова к системе

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

История начинается с Prompt Engineering. Это устоявшаяся дисциплина, которая охватывает написание и структурирование инструкций для одного вызова модели. Здесь ключевым игроком является Anthropic, чьи рекомендации стали де-факто стандартом. Они предлагают разделять системный промпт на четко обозначенные секции: фоновая информация, инструкции, руководство по использованию инструментов и описание формата вывода. Эти секции часто отделяются XML-тегами или заголовками Markdown. Важно понимать: рекомендация «минимального набора информации» не означает «короткого промпта». Она означает, что каждый токен должен нести максимальную смысловую нагрузку, полностью специфицируя ожидаемое поведение модели без лишнего шума.

За этим последовал Context Engineering (инжиниринг контекста). Anthropic описывает его как естественное продолжение инжиниринга промптов. Вопрос смещается с «какие слова использовать» на «какую конфигурацию токенов поместить в окно контекста». Контекст — это конечный ресурс. Задача инженера — оптимизировать полезность этих токенов с учетом ограничений модели. Это уже не просто текст, это управление памятью модели в рамках одного вызова.

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

На один уровень выше находится Loop Engineering. В июне 2026 года появилась статья Buildrix (опубликованная на arXiv), которая явно описывает четырехступенчатую прогрессию: промпт, затем контекст, затем среда (harness), и наконец, цикл. Именно этот последний слой определяет, как система повторно наблюдает, действует, проверяет и восстанавливается. А Graph Engineering — это самый новый и наименее устоявшийся термин, который появился примерно через шесть недель после пика обсуждений Loop Engineering.

02Уровень 1: Инжиниринг промптов (Prompt Engineering)

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

Что ломает модель «человек-в-петле»?

• Высокий объем: Невозможно вручную проверять тысячи запросов в час.
• Многошаговые задачи: Когда результат одного шага является входом для следующего, ручная проверка каждого шага убивает скорость.
• Отсутствие человека: В фоновых процессах или ночных заданиях человека просто нет.
• Автоматизация: Результаты должны автоматически питать следующий шаг без вмешательства.

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

03Уровень 2: Инжиниринг циклов (Loop Engineering)

Фреймворк Loop Engineering рассматривает кодингового агента как инструмент грубой силы для поиска решений. Ремесло здесь заключается не в написании идеального промпта, а в проектировании цели, инструментов и самого цикла. Термин вошел в мейнстрим обсуждений разработчиков в июне 2026 года после широко распространенного поста, в котором утверждалось, что инженеры должны перестать просто «промптить» кодинговые агенты и начать проектировать циклы, которые их промптят.

Самое подробное публичное разделение выделяет пять примитивов, плюс шестой элемент, который держит их вместе:

1. Automations (Автоматизации): Расписание или событие, которое выполняет обнаружение и триаж без надзора. Например, ночной бот, который проверяет логи и создает тикеты.
2. Worktrees (Рабочие деревья): Изоляция, чтобы параллельные агенты не редактировали одни и те же файлы. Это предотвращает конфликты слияния в Git.
3. Skills (Навыки): Знания проекта, записанные один раз в файле SKILL.md, а не объясняемые заново в каждой сессии. Это позволяет агенту быстро входить в контекст специфичных для проекта стандартов.
4. Plugins and connectors (Плагины и коннекторы): Доступ на основе MCP (Model Context Protocol) к трекеру задач, базе данных или staging-API. Агент должен видеть реальное состояние системы.
5. Sub-agents (Подагенты): Разделение ролей «создатель/проверитель». Модель, которая написала код, оценивает его слишком щедро. Нужен отдельный агент для ревью.
6. State (Состояние): Markdown-файл или доска вне разговора, потому что модель забывает между запусками. Память должна быть внешней и персистентной.

Две функции внутри сессии имеют решающее значение. Команда /loop перезапускает процесс по расписанию. Команда /goal работает до тех пор, пока записанное условие не станет истинным, с отдельной маленькой моделью, проверяющей результат после каждого хода. Так агент, написавший код, не является тем же агентом, который его оценивает. Обе функции (или их аналоги) доступны в Claude Code и приложении Codex.

Цикл — это не самая сложная часть. Самая сложная часть — это условие остановки (stop condition). Цикл, который не может механически отличить «готово» от «застрял», не терпит неудачу громко. Он просто продолжает тратить токены. Без четкого условия остановки вы платите за бесконечные итерации.

04Уровень 3: Инжиниринг графов (Graph Engineering)

В июле 2026 года дискуссия перешла от циклов к графам. Циклы сделали поведение агента программируемым. Графы сделали программируемой организацию агентов.

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

1. Org Graph (Организационный граф): Стабильный. Долгоживущие агенты имеют именованные роли, владеют определенной зоной ответственности и накапливают контекст со временем. Он меняется только при перенастройке (redeploy).
2. Work Graph (Рабочий граф): Эфемерный. Узлы задач существуют только пока выполняется работа. Ребра расходятся для параллельных путей, сходятся при достижении консенсуса и исчезают, когда доказательства делают ветвь ненужной.

Орг-граф отвечает на вопрос «Кто?» (кто владеет задачей). Рабочий граф отвечает на вопрос «Что, прямо сейчас?» (какие шаги выполняются).

Скептицизм относительно термина «Graph Engineering» вполне обоснован. Подагенты с определенной целью уже образуют граф, и технология предшествовала словарю. LangGraph выпустил свой графовый API задолго до того, как термин стал мейнстримом. Пять шаблонов рабочих процессов Anthropic от декабря 2024 года — цепочка промптов, маршрутизация, параллелизация, оркестратор-работники, оценщик-оптимизатор — это графовые топологии, описанные текстом. Новым является общее имя для решений, которые эти фреймворки всегда заставляли принимать: что такое узлы, что такое ребра, что находится в состоянии.

Конкретный артефакт, который стоит знать, — это StateGraph в LangGraph. Он объявляется над схемой состояния. Узлы регистрируются с помощью add_node. Ребра соединяются с помощью add_edge и add_conditional_edges. START и END отмечаются, затем граф компилируется. Узлы — это обычные функции, которые принимают состояние и возвращают частичные обновления. Контекст не пересекает границу узла, если ребро не переносит его. Последняя часть описывает весь режим отказа системы: если вы неправильно настроите передачу состояния между узлами, граф будет работать, но агенты будут работать вслепую.

05Как выбрать уровень: Практическое руководство

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

1. Читает ли человек каждый вывод перед тем, как что-либо начнет действовать на него?
   Если да, то уровня промпта достаточно. Цикл покупает ненаблюдаемое выполнение, а не автономность. Если человек не читает, переходите к следующему вопросу.
2. Может ли «готовность» быть проверена чем-то другим, кроме человека?
   Тесты, схема, рубрика, вторая модель. Если нет, то нет условия остановки — только бюджет. Если условие остановки есть, переходите к следующему вопросу.
3. Вмещается ли задача в контекст одного агента и одну доменную область?
   Если да, стройте цикл. Один трассировочный след (reasoning trace) — самый дешевый способ сохранить согласованность предположений. Если задача требует параллельной работы независимых ветвей, переходите к следующему вопросу.
4. Нужно ли независимым ветвям работать одновременно?
   Если да, это проблема графа: объявите узлы, ребра, общее состояние и пути отказа. Если нет, расширьте инструменты цикла, прежде чем добавлять агентов.

Статья на arXiv от июля 2026 года о циклах кодинговых агентов правильно описывает взаимосвязь. Цикл — это промпт, повторяемый с конструкцией вокруг него, и инжиниринг циклов дополняет инжиниринг промптов, а не заменяет его. То же самое верно на один уровень выше. Графы строятся из циклов, а циклы строятся из промптов.

06Что это значит на практике

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

Опубликованные цифры устанавливают цену. Внедрение мультиагентных систем (графов) может дать прирост в +90.2% на внутренних исследовательских оценках качества. Однако это требует примерно в 15 раз больше токенов, чем обычный чат. Расход токенов сам по себе объясняет 80% дисперсии в затратах. Это значит, что вы платите за надежность и сложность, а не за простоту.

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

Итак, что мы имеем в итоге? Промпт-инжиниринг — это база. Без хорошего промпта цикл будет выполнять плохие действия, а граф будет организовывать хаос. Цикл-инжиниринг — это мост к автономности, позволяющий агенту работать без постоянного контроля человека, но только при наличии четкого условия остановки. Граф-инжиниринг — это масштабирование, позволяющее управлять сложными, параллельными процессами с множеством участников. Не пытайтесь использовать граф, если вам нужен цикл. Не пытайтесь использовать цикл, если вам достаточно промпта. Понимание этих слоев и их иерархии — ключ к построению эффективных, экономичных и надежных AI-систем в 2026 году и далее.

Источник: MarkTechPost ↗