Обвязка агента: какие инструкции убрать, какие границы укрепить

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

Метафора words & walls разделяет две задачи. Слова — системные инструкции, правила и содержимое файлов навыков, которые компенсируют конкретные слабости модели. После обновления часть таких указаний можно удалить без потери качества; прежняя полезность не доказывает нынешнюю. Стены — песочницы, ограничения доступа и детерминированные проверки действий. Более способная модель по-прежнему может выполнить недопустимое действие, поэтому эти ограничения нужны независимо от качества её рассуждений. Направление развития здесь двойное: меньше предписаний о каждом шаге решения, более надёжный периметр вокруг исполнения. Это даёт агенту свободу внутри задачи, сохраняя границы разрешённого.

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

В этой истории важны три перемещения. Формат вызова функций, структурированный ответ, поиск инструментов и уплотнение контекста переходят из пользовательской обвязки в возможности модели или API. Запреты, которые раньше пытались выразить словами, закрепляются в среде исполнения. Сам цикл работы перемещается с ноутбука в облако. У клиента при этом остаётся доступ к его конкретному состоянию: файлам, редактору, браузеру и локальным приложениям. При выборе архитектуры нужно понимать, где проходит эта граница и какая сторона управляет состоянием и доступом.

Словарь продуктов во многом совпадает: инструменты, сессии, память, субагенты, права и проверки. Совместимость поддерживают протоколы: MCP связывает агента с инструментами, A2A — агентов между собой, ACP — агента с редактором. Однако одинаковое название функции не означает одинакового поведения. Различаются настройки защиты по умолчанию, доступные модели, место исполнения, устройство памяти и способ проверки результата. Песочница, классификатор опасных действий и запрос подтверждения человеку решают разные задачи.

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

Минимальный mini-SWE-agent показывает, насколько далеко модель может продвинуться с одним bash и небольшой обвязкой. Это свидетельство роста возможностей моделей и насыщения конкретного бенчмарка. Но успешное исправление кода ещё не даёт оснований доверить модели авторизацию. Она не обеспечивает надёжного разделения инструкций и данных, а вероятностный классификатор может пропустить опасное действие. Повторные попытки атакующего делают даже небольшую вероятность пропуска существенной.

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

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

Практический способ проверки — абляция: убрать один компонент и измерить изменение результата. Для эксперимента фиксируют модель и уровень рассуждения, выбирают представительные задачи из реальных неудач, сохраняют одинаковую среду. Успех определяют внешней проверкой, а не самоотчётом агента; одной оценки другой моделью желательно не ограничиваться. Несколько прогонов позволяют увидеть разброс. Затем сравнивают успешность и стоимость принятого результата. Если компонент не приносит измеримой пользы, появляется основание удалить его. Накопленные инструкции становятся набором проверяемых предположений, которые пересматривают после значимых обновлений.

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

Удешевление токенов также не гарантирует снижения расходов организации: растут контекст, число вызовов и объём поручаемой работы. Поэтому важны работа с кэшем и стоимость успешной задачи, а затем — эффект в разработке. Больше изменений кода не обязательно означает больше пользы: нужно учитывать время и понимание результата инженерами. Поломодов отдельно отмечает риск когнитивного долга. На вопрос из зала о цене разных обвязок он предлагает сначала выбрать общий бенчмарк. Цены из отдельных сравнений нельзя превратить в универсальный тариф на задачу.

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

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