Как ИИ-агент меняется без переобучения модели

ИИ-агент учится менять собственную обвязку

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

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

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

Как обвязка переходит от набора инструкций и процедур к изменяемым исполняемым компонентам.

Что именно меняется

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

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

Авторы проводят границу между двумя видами изменений:

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

🟠 Изменения исполняемых компонентов: агент меняет код инструментов, логику управления, правила восстановления после ошибок или способ подключения сервисов.

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

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

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

От одной правки до новой архитектуры

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

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

Третий вариант строится вокруг подключаемых компонентов. Агент может создавать и подключать инструменты во время работы, если они подходят под заданные интерфейсы. Интерфейс помогает проверить, что компонент совместим с системой, но не доказывает, что его поведение безопасно. Проверять нужно весь результат работы связки, а не только каждый компонент по отдельности.

Один пример из статьи касается обработки офисных таблиц. В повторяющихся задачах агент создаёт инструменты для пакетного поиска и сводок. На первой задаче число вызовов инструментов снижается с 13 до 3. Но затраты сначала растут: обработка занимает 24 секунды вместо 15,49, а расход токенов увеличивается с 41 119 до 47 572. Экономия появляется на следующих задачах: в накопленных результатах после пяти задач указано снижение расхода на 110 351 токен и времени на 22,97 секунды.

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

Когда улучшение действительно работает

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

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

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

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

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

Что даёт подход — и чего он не решает

Изменять обвязку проще, чем переобучать модель. Можно обновлять инструкции, память и код вокруг модели, не создавая новый набор весов. Это особенно полезно, если модель доступна только через программный интерфейс или если её веса нельзя менять. Кроме того, правки в коде и промтах легче сравнивать и проверять, чем изменения внутри параметров модели.

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

Для развёртывания нужны три разных уровня защиты:

🟣 Проверка изменений: новые версии испытывают на независимых задачах.

🟣 Ограничение доступа: агенту дают только те права, которые нужны для работы.

🟣 Контроль последствий: рискованные действия требуют отдельного разрешения или проверки.

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

Вывод

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

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