Инженерия инструментов для управления агентами: состояние, верификация и контроль вокруг модели
Временная визуализация агентов производства: почему промпты и контекст недостаточны, и как устойчивое состояние, обеспечение соблюдения правил, верификация и наблюдаемость закрывают этот разрыв.
Источники: Agent Harness Engineering: The Runtime Architecture Behind Reliable AI Agents
Когда современная модель всё равно терпит неудачу
Представьте агента, оснащённого лучшей на рынке моделью, тщательно настроенным системным промптом, десятками инструментов и окном контекста, достаточно большим для всего кодового базиса. Однако он может потерпеть неудачу при выполнении задачи, которую любой компетентный инженер считал бы рутинной. Он выбирает правильное действие, но выполняет его неправильно. Он находит ключевой факт, но теряет его при сбросе контекста. Он правильно редактирует десять файлов, но в одиннадцатом вносит скрытую ошибку. Он тратит час на отладку проблемы, которую сам создал. Возможно, он даже составляет убедительный отчёт о завершении работы, хотя ничего не проверил.
Обычная реакция — работать над запросом: добавлять ещё инструкций, примеров, контекста или просить быть осторожнее. Это помогает некоторое время, а затем уже не помогает. Более глубокая проблема кроется в ментальной модели, согласно которой модель рассматривается как агент, а всё вокруг — как настройки. Такой подход теряет смысл, когда агенту необходимо постоянно работать в реальной среде.
Агент производства — это не просто модель с инструкциями вокруг неё. Это система во время выполнения: она хранит состояние, выполняет действия, взаимодействует с внешними системами, справляется с сбоями, принимает обратную связь и нуждается в способах восстановления, проверки и управления. Дисциплина, развивающаяся вокруг такой системы выполнения, называется инженерией среды для агентов. Сравните её с работой с инструкциями. Инженерия инструкций задаётся вопросом о том, как направлять модель на определённое поведение, в то время как инженерия среды занимается созданием условий, в которых модель может надёжно достичь цели. Это не улучшенные инструкции — это другая абстракция, охватывающая как то, что пишет модель, так и то, что может делать система, что выживает после сбоя, что разрешено и что считается завершённым.
Система выполнения для вероятностной модели
Самая простая картина агента — это модель с подсказкой и несколькими инструментами. Этого достаточно для понимания отдельного вывода, но этого недостаточно для производственного агента, который лучше рассматривать как систему выполнения, построенную на вероятностной модели.
Модель выполняет логические рассуждения. Механизм управления определяет условия, при которых эти рассуждения превращаются в действия: что видит модель, до чего она может дотянуться, какие действия разрешены, какое состояние сохраняется и какие доказательства необходимы для подтверждения успеха.
Возьмём агента для программирования, чей промпт предписывает сначала изучить архитектуру, запустить тесты и не трогать нерелевантные компоненты. Эти указания описывают намерение, но не обязывают к чему-либо. Инструментарий может сделать некоторые файлы читаемыми, а другие — нет, выполнять проверку после каждой изменения, блокировать запрещённые операции, сохранять прогресс и отказываться закрывать задачу без доказательств. Таким образом, промпт указывает, что должен делать агент, в то время как инструментарий определяет, что будет разрешено системой и что считается выполненным. Модель обеспечивает интеллектуальную базу, а инструментарий превращает её в что-то, с чем можно работать.
Три уровня инженерии
Инженерия агентов прошла через три всё более общих уровня абстракции: промпты, затем контекст, и наконец инструментарий.
Инжиниринг промптов заключается в определении того, что должен сделать модель. Он позволяет улучшить инструкции, примеры, описания инструментов и ограничения поведения, и для простых задач работает чрезвычайно хорошо. Однако промпт представляет собой лишь инструкцию и не обладает способностью к принудительному выполнению. Агенту, которому поручено выполнять тесты, всё равно можно заявить о успехе без их выполнения. Приказ не трогать производственные файлы мало что значит, если среда выполнения предоставляет ему неограниченный доступ. Прошение запомнить решение на шесть часов сталкивается с другими данными, поступающими в контекст.
Инжиниринг контекста решает следующую проблему — что именно должен знать модель в момент принятия решения. Поиск информации, навыки, память, результаты работы инструментов, структурированный состояние, поэтапное раскрытие информации и её сжатие способствуют созданию более качественного контекста для принятия решений, при этом цель смещается от просто наличия большего количества контекстной информации к её более эффективному использованию. Тем не менее модель может выбрать неверное действие, повредить состояние, пропустить проверку, застрять в цикле или заявить о успехе слишком рано.
В этот момент начинается работа над инженерной архитектурой: возникает вопрос о том, какая система должна окружать модель для надежного выполнения задачи. Она обеспечивает то, чего недостаточно от одних лишь подсказок и контекста: стабильное состояние, ограниченные инструменты, права доступа, изоляцию, проверку, восстановление, оценку и возможность наблюдения. Кроме того, она изменяет цикл разработки. Ошибка больше не требует просто переформулирования подсказки — она ставит вопрос о том, какого контроля не хватало, и ответом может стать валидатор, более строгий контракт инструментов, границы политик, точка проверки, стратегия восстановления или улучшенная видимость. Каждая ошибка приводит к изменениям в системе.
Результатом является «рatchet» для харчнеса: сначала сбой, затем отсутствие управления, затем улучшение харчнеса, затем проверка и, наконец, более прочная основа. Инжиниринг запросов улучшает то, что говорится модели, а инжиниринг контекста — то, что она знает. Инжиниринг харчнеса улучшает условия, в которых работает модель, и делает систему постепенно более устойчивой к повторным сбоям тем же способом.
За что отвечает временная среда выполнения
Если харчнес — это временная среда выполнения, что она содержит? Вместо перечисления запросов, инструментов, памяти и кода оркестрации более полезно определить обязанности временной среды выполнения.
- Контекст определяет, что модели необходимо знать для принятия следующего решения: инструкции, полученные материалы, навыки, результаты работы соответствующих инструментов и текущие наблюдения.
Это не семь независимых функций, и им не обязательно быть семью сервисами. Вместе они образуют контрольный цикл вокруг вероятностной модели. Когда этот цикл работает часами, а не минутами, преодолевая ограничения контекста, сбои, попытки повтора и замену рабочих процессов, архитектура начинает напоминать то, что инженеры уже хорошо знают — распределённую систему.
Окно контекста — это не хранилище состояния
Одной из самых распространённых ошибок при проектировании агентов является рассмотрение окна контекста как памяти.
Это соблазнительная привычка. Модель может видеть всю конверсацию, предыдущие вызовы инструментов, решения и промежуточные результаты, поэтому добавление новой информации кажется безвредным. Однако этот окно представляет собой рабочий набор данных, а не базу данных. Ничто в нем не является постоянным: перезагрузка, сокращение объема или процедура компактации могут уменьшить его объем или полностью заменить его. Расширение окна увеличивает емкость, но не влияет на стабильность хранения данных.
Для агента, работающего длительное время, информация о состоянии задач должна храниться в другом месте: цели, завершенная и оставшаяся работа, решения, результаты работы, контрольные точки, результаты проверки и ссылки на внешние ресурсы. Затем контекст воссоздается на основе этого состояния в соответствии с тем, что нужно модели в данный момент. Разница проста: контекст — это то, что видит модель, а состояние — это то, что знает система.
Процесс сжатия делает это очевидным. Агент, который тратил три часа на изменение репозитория, может накопить сотни вызовов инструментов, отказанных подходов и записей наблюдений. Сокращение этой истории может сделать следующий контекст пригодным для использования, но краткое изложение всё равно является интерпретацией произошедшего, поэтому критически важное состояние не должно зависеть от того, что сохранил сжимающий механизм. Вместо этого система может собрать новый контекст на основе устойчивого состояния в следующем порядке: состояние задачи, соответствующие артефакты, текущие наблюдения, навыки и, наконец, контекст модели.
Точки контроля применяют тот же принцип при сбоях процессов, а структурированная передача данных — при взаимодействии агентов или рабочих процессов. Приемнику необходимо состояние, необходимое для правильного продолжения работы, а не вся история общения его предшественника. Архитектурный вопрос заключается в том, какая информация должна сохраняться независимо от контекста, и как только это определено, управление контекстом превращается в проблему управления состоянием.
Долгоживущие агенты — это распределенные системы
Когда агент работает часами или днями, традиционная модель запроса и ответа перестает функционировать. Процесс может завершиться, инструмент может выйти из строя из-за истечения времени, а рабочий элемент может исчезнуть после выполнения операции, но до её отчёта. Два рабочих элемента могут взяться за одну и ту же задачу. Контекст модели может исчезнуть на полпути. Всё это не является чем-то необычным, поскольку это классические проблемы распределённых систем, и для решения их в долгосрочно работающих системах требуются чёткие семантики выполнения.
Если работа может продолжаться дольше, чем рабочий элемент, необходимо установить ограничения на её владение. Система аренды позволяет рабочему элементу брать на себя задачу на ограниченный период времени, а сигналы активности предоставляют внешнему наблюдателю информацию о том, что элемент всё ещё функционирует. Когда рабочий элемент исчезает, срок аренды истекает, и другой элемент может продолжить работу на основе сохранённого состояния.
Повторные попытки требуют тщательного подхода. Представьте агента, который отправляет запрос на развертывание, и время ожидания истекает до того, как появится какой-либо результат. Автоматическая повторная попытка может привести к двойному развертыванию. Поэтому инструменты агентов нуждаются в тех гарантиях, которые существуют в других распределенных системах: идентификаторах операций, идемпотентности, четко определенных состояниях сбоя и ясном ответственном за поведение при повторных попытках.
Затем идет возобновление работы. Длительная задача должна представляться в виде устойчивого прогресса, а не как временный диалог в памяти, следуя циклу проверки состояния, выполнения действий, наблюдения, сохранения результатов и продолжения работы. Если выполнение останавливается на полпути, системе необходимо определить, безопасно ли повторять текущий шаг, уже ли он сохранен, выполнен частично или требуется какая-то коррекция. Возобновление работы не означает повторного выполнения всего с нуля — это воссоздание минимального состояния, необходимого для безопасного продолжения. Передача заданий происходит по тому же принципу: новый исполнитель получает цель, решения, результаты работы, информацию о статусе проверки и незавершенные задачи, но не историю общения предыдущего исполнителя.
Это определяет основной критерий надежности. Как только агент может существовать дольше своего процесса, процесс перестает быть единицей надежности — надежностью становится сама задача.
Проверка — вторая половина способности к действию
Агент может писать код, выполнять развертывание, формировать запросы к базе данных или изменять инфраструктуру. Создание чего-либо — это не то же самое, что обеспечение его корректности, и опасной практикой является предоставление агенту права окончательно определять, увенчалось ли его работой успехом, например через сообщение о завершении процесса аутентификации и успешном пройдении всех тестов. Система управления не должна считать это доказательством; ей следует запустить тесты. Аналогичным образом, утверждение о том, что сервис работает нормально, должно запускать проверки его состояния, а не завершать задачу. Миграция данных должна оцениваться на основе схемы и неизменных свойств данных, а не на основе интерпретации моделью собственных вызовов инструментов. Уверенность агента в том, что у него всё получилось, не является надежным сигналом о завершении работы.
Именно поэтому в процессе производства используются три отдельные роли. Планировщик определяет, что необходимо сделать. Выполняющий элемент выполняет ограниченные действия. Оценщик определяет, соответствует ли получившееся состояние системы требованиям. Одна модель может выполнять все три роли, но их обязанности остаются разными.
Проверка должна основываться на том, что можно наблюдать, и детерминистические доказательства являются первым выбором там, где они доступны: компиляторы, инструменты для запуска тестов, валидаторы схем, проверки работоспособности, статус развертывания, проверки политик или простые утверждения. Оценка на основе моделей полезна, когда корректность имеет семантическую природу, но для неё требуются конкретные критерии, а не расплывчатый вопрос о том, хорош ли результат. Таким образом, завершение задачи становится свойством самой системы, а не чем-то, что говорит модель: требования выполнены, валидация пройдена, необходимые элементы присутствуют, проверки политик прошли успешно — только после этого задача считается завершённой. Другими словами, проверка предоставляет доказательства, которые оценщик анализирует, чтобы решить, можно ли продолжать выполнение, поэтому оценщик выступает в роли датчика в цикле обратной связи. Агент обеспечивает прогресс, в то время как система формирует доказательства.
Агенту могут указать не делать что-то, но при этом он должен оставаться способным это сделать. Фразы вроде «не изменяйте производственные данные», «писать можно только в рабочей области» и «никогда не раскрывайте учетные данные» полезны, однако ни одна из них не является реальным барьером безопасности, если среда выполнения всё равно позволяет соответствующую операцию. Инструкции передают намерения, а обеспечение соблюдения устанавливает неизменные принципы.
Дизайн инструментов четко показывает эту разницу. Если агенту предоставить универсальную функцию execute_sql(), его возможности совершенно не похожи на возможности агента, имеющего ограниченный интерфейс для чтения только. Ограниченный интерфейс позволяет проверять авторизацию, верифицировать параметры, аудитировать операции и сокращать зону воздействия. Инструменты MCP, API, файловые системы, оболочки и внешние сервисы работают по тому же принципу: модель предлагает действие, а механизм управления решает, можно ли его выполнить и под какой идентичностью, с какими правами, в какой среде и согласно какой политике.
Удобное правило помогает сортировать ограничения по степени затрат:
- Если нарушение ограничения допустимо, может хватить простого указания.
- Если нарушение сопряжено с большими затратами, необходима дополнительная верификация.
- Если нарушение опасно, его необходимо обеспечить на уровне границы.
Сандбоксинг добавляет второй измерительный уровень. Авторизация определяет, разрешена ли та или иная действие. Сандбокс же регулирует последствия ненадлежащего поведения агента. Границы файловой системы и сети, ограничения ресурсов и узко специфицированные учетные данные снижают ущерб от неожиданного поведения. Более совершенные решения также обеспечивают контроль за переходами между этапами работы, а не только за вызовами отдельных инструментов. Развертывание в производственной среде может оставаться недоступным до тех пор, пока не пройдут тесты, стадионная среда будет работать нормально и кто-то не даст разрешения. Модель может предложить такой переход, но правила выполнения определяют его законность. Это ближе к концепции автомата состояний, чем к доверию к предложению на естественном языке. Цель не в ограничении интеллекта, а в ограничении возможностей и зоны воздействия.
Нельзя управлять тем, что невозможно наблюдать
Обычная возможность наблюдения позволяет определить, работает ли сервис исправно, растёт ли задержка и какая зависимость не функционирует. Системам с агентами требуется дополнительный уровень наблюдения. Когда агент терпит неудачу, важно выяснить, что произошло, а также почему его действия привели к этому. Чего он пытался достичь? Какой контекст у него был? Какие инструменты он использовал? Какие правила разрешали или блокировали эти вызовы? Какое состояние изменилось? Какие доказательства убедили его в завершении задачи? Это и есть возможность наблюдения за траекторией действий агента.
Стандартные показатели LLM, такие как количество токенов, задержка, стоимость, версия модели, а также входные и выходные данные, необходимы, но недостаточны, поскольку один вызов модели представляет собой лишь отдельное звено в более сложной цепочке: намерение, контекст, решение, действие, наблюдение, состояние, проверка и результат. Предположим, агент тратит сорок минут на миграцию сервиса, после чего она терпит неудачу. Информация о том, что было потреблено 80K токенов, почти ничего не говорит. Полезная информация может включать сведения о том, что инструментарий использовал устаревшее руководство по миграции, агент выбрал устаревший API, развертывание технически прошло успешно, проверки интеграции провалились, а механизм восстановления попытался применить ту же стратегию снова. Вот что является настоящей диагностикой.
Это означает, что контекст должен содержать информацию о происхождении: способ определения того, какие навыки, документы, состояние системы и результаты работы инструментов повлияли на принятие того или иного решения. Для вызовов инструментов также необходим контекст причинно-следственных связей, включающий шаг задачи, который их запустил, используемый инструмент, оцениваемую политику и последствия её применения. Также должны быть видны решения, связанные с политикой, изменения состояния системы, а также действия, которые привели к успеху. Самыми информативными показателями оказываются поведенческие: коэффициент успешности выполнения задач, количество сбоев при верификации, успех в восстановлении работы, преждевременное завершение задачи, отклонения по причине политик, повторяющиеся паттерны сбоев, обращения к людям для решения проблем и количество шагов, необходимых для успешного выполнения задачи.
Наблюдаемость — это то, что доводит конструкцию до совершенства. Ошибка должна оставлять после себя нечто большее, чем просто запись в журнале. Её траектория должна позволять классифицировать причину сбоя и определить отсутствующий элемент управления — будь то источник контекста, оценщик, правило, границы инструмента, точка контроля или стратегия восстановления. Цель — система, которая не может сбоить таким же образом дважды.
Новая дисциплина в системном проектировании
Если спросить, как сделать агентов более эффективными, ответ становится все более широким по мере роста их автономии. Инжиниринг инструкций позволяет настраивать команды, инжиниринг контекста — информацию, доступную в момент принятия решения, а инжиниринг всей процедуры выполнения — состояние системы, действия, границы, обратную связь, процессы восстановления, проверку и наблюдаемость. Они не заменяют друг друга, а представляют собой все более широкие сферы применения.
Полезное разделение обязанностей лежит в основе всей системы: модель отвечает за принятие решений в условиях неопределенности, а движок выполнения — за соблюдение инвариантов. Файлы, которые никогда не должны меняться, ограничиваются границами файловой системы. Продакшн-системы, в которые нельзя вносить изменения, проходят проверки авторизации. Миграции, которые должны завершиться успешно, проверяются по полученному состоянию, а состояние задач, которое должно сохраняться после перезагрузки, фиксируется. Требований к тому, чтобы движок выполнения мог более надежно обеспечивать гарантии, от модели ожидать не следует.
Агенты обработки данных могут давать сбои, и признак зрелой системы — это то, как она реагирует на эти сбои. Каждый сбой влияет на процесс выполнения. Если одна и та же ошибка продолжает возникать, для неё формируется отдельный механизм оценки. Если какое-либо действие оказывается рискованным, функционал, стоящий за ним, сужается. Если прогресс теряется, появляется точка контроля в месте её отсутствия, а если попытки восстановления продолжают терпеть неудачу, вступает в силу политика эскалации. Выполнение программы создаёт доказательства, эти доказательства выявляют отсутствующие механизмы контроля, а эти механизмы делают следующую попытку выполнения более надёжной.
Это также влияет на то, как оцениваются агенты. Вопрос перестаёт касаться того, насколько хороша модель, и становится вопросом о том, насколько надёжно весь системный комплекс выполняет подобные задачи. Инженерия управления — это не просто ещё одна платформа для оркестрации. Это дисциплина системного проектирования, направленная на обеспечение надёжности вероятностного интеллекта. Демонстрация показывает, что агент может сделать что-то один раз. Промышленная система должна выполнять задачи надёжно, проверяемо, с возможностью восстановления и многократно, причём каждая неудача должна способствовать улучшению следующей попытки. Большая часть самой сложной работы сейчас скрыта за простыми запросами — в архитектуре состояний, механизмах обратной связи, проверки, восстановления и управляющих циклах, которые превращают логику агента в стабильное поведение системы.