Кратко

  • Основная идея AI4AN — использовать LLM прежде всего для разработки и тестирования сетевого ПО, которое затем запускается как Autonomic Service Agent, а не полагаться только на модель, напрямую принимающую решения в реальной сети.
  • В версии проекта -01 рассматриваются интерфейсы с широкими правами на маршрутизаторе, но раздел безопасности всё ещё помечен как незаполненный. Это индивидуальный проект документа, а не стандарт IETF и не свидетельство промышленного внедрения.

Модели отводится другая роль

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

Toerless Eckert и Alexander Clemm описывают Agentic Network DevOps Center: он получает намерение в форме задания, интерпретирует его и использует LLM для разработки автоматизационного ПО. Программа должна работать как Autonomic Service Agent (ASA) на отдельных устройствах или в сети шире. В этой архитектуре модель в основном помогает при разработке; после установки постоянным исполнителем становится программа. Проект не запрещает прямую агентную автоматизацию на основе LLM там, где она осуществима. Его предпочтение — промежуточный программный слой между рассуждением модели и действием устройства.

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

Граница проходит по интерфейсу устройства

Схема помещает среду разработки над уровнем исполнения на сетевом оборудовании, рядом с традиционными процессами управления. В ней указаны компоненты ANIMA: Autonomic Control Plane, безопасная загрузка BRSKI и координация GRASP. Эти протоколы дают технический контекст, но не утверждают AI4AN в качестве стандарта.

Раздел об интерфейсах между агентом и устройством показывает масштаб возможного доступа. Среде могут понадобиться CLI маршрутизатора вплоть до наивысшего уровня привилегий, чтение, изменение, запись и удаление файловой системы, соединения с сетевыми сокетами и интерфейсами управления, а также аппаратная и программная диагностика. Документ перечисляет возможные возможности; он не требует предоставлять весь этот доступ каждому ASA и не утверждает, что так уже работают реальные сети.

В разделе Security Considerations версии -01 стоит отметка «TBD». Это незаполненная часть документа, а не доказательство внутренней небезопасности архитектуры. Но пока проект не устанавливает, как удостоверять происхождение сгенерированной программы, ограничивать её права, соотносить симуляцию с реальным состоянием сети или отзывать неисправного агента. На эти вопросы должны ответить последующие версии и реализации.

Вклад Eckert и открытый выбор архитектуры

Toerless Eckert подготовил AI4AN вместе с Alexander Clemm и возглавляет рабочую группу ANIMA. Протокол заседания ANIMA на IETF 126 фиксирует их выступление и обсуждение нескольких подходов: включить LLM непосредственно в автономный контур управления; ограничить модель оптимизацией параметров; либо использовать её как помощника при разработке и развёртывании детерминированных ASA. В протоколе нет ни консенсуса, ни принятия проекта группой, ни утверждения новой хартии.

Ценность идеи в переносе вопроса с «достаточно ли умна модель?» на «какое ПО будет работать, на каких устройствах и с чьего разрешения?». Сгенерированную программу можно рассматривать как обычный программный артефакт, но доверие должно охватывать весь путь: исходные данные, результат генерации, тесты, подпись, развёртывание и откат.

Записка Heng Lu № 65 «Running-Code Primacy» служит здесь редакционной рамкой, а не источником фактов о Eckert или AI4AN: публикация спецификации не равна локальной проверке, реализации, принятию или наблюдаемой работе в сети. Следующими полезными доказательствами для AI4AN были бы завершённый раздел безопасности, воспроизводимые тестовые среды, ясная цепочка подписи и обновления, интерфейсы с минимальными правами, независимые реализации и испытания операторов. Пока граница исполнения очерчена, а её гарантии ещё нет.

Источники