Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Автономные ИИ-агенты предложено считать отдельной системной абстракцией, а не надстройкой над LLM. Ian Foster из Argonne National Laboratory и The University of Chicago выделяет шесть областей, где привычных механизмов операционных систем и сервисов уже недостаточно; работа не рецензирована, а приведённые в ней числа получены самим автором. Для продукта это переносит контроль с отдельных вызовов модели на весь жизненный цикл агента.
Ключевое различие автор формулирует так: процесс исполняет программу, агент преследует цель. Процесс получает заранее написанный код, а агент во время работы составляет и пересматривает порядок действий, опираясь на цель, наблюдения, память и доступные инструменты. Такой агент сохраняет состояние, действует по собственной инициативе и взаимодействует со средой, которую нельзя полностью описать заранее.
Из-за этого бесконтрольный расход ресурсов, перенаправление поведения вредоносным содержимым и непрозрачная непрерывная работа становятся не отдельными ошибками реализации, а следствием устройства системы. Foster группирует требования в шесть областей: исполнение, интерфейсы, корректность, надзор, координация и долговременное состояние. Обычного ограничения процессорного времени недостаточно: агенту нужен бюджет, связанный с ценностью цели, а вместо простого списка доступных API — явные полномочия и условия их применения.
Проверять приходится не только правильность результата, но и допустимость поведения на пути к нему. Автор предлагает окружать генератор действий небольшими доверенными механизмами, которые учитывают ресурсы, ограничивают полномочия, записывают решения, сохраняют происхождение данных и позволяют человеку остановить работу. Такой слой проще контролировать, чем пытаться заранее доказать корректность всех будущих действий LLM.
Работа носит концептуальный характер: аргумент строится на сравнении агентов с процессами, сервисами, акторами, контейнерами и потоками данных, а не на эксперименте или готовой эталонной архитектуре. Для команды практическая граница проходит по самостоятельности системы: если она долго хранит состояние, выбирает инструменты и сама продолжает работу, бюджеты, полномочия, аудит и остановку стоит закладывать в архитектуру, а не добавлять после первых отказов.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
