Кратко

  • Uniform Resource Agent объединял данные активации, цели, опыт, сценарий и фильтр ответа в устойчивую спецификацию, которую можно было передавать, менять и повторять.
  • Работу выполняла URAgency: сопоставляла тип с реализацией, обеспечивала среду и зависимости, активировала локальные или удалённые цели и толковала ответ.
  • Сохранённый объект или успешный запуск не доказывали разрешение на ввод, неизменность смысла, корректность выполнения, воспроизводимость или достижение цели.

Исходная проблема RFC 2016 — жёсткая связь между тем, что нужно пользователю, и тем, как это делается сегодня. Подписка на список рассылки, поиск в нескольких службах или сбор результатов описывают действие. URL, протокол, скрипт и конкретная веб-страница — лишь выбранный механизм. Когда они зашиты в клиент, изменение службы ломает и клиента.

URA был постоянной записью действия. Общая виртуальная структура включала шесть частей: заголовок типа; значения, необходимые при активации; цели в форме URL или URN; сведения об опыте, например дату прошлого запуска и найденные адреса; программу с условиями и порядком; фильтр, который преобразовывал или оценивал ответ.

Каждая часть обозначала точку контроля. Поле ввода не подтверждало полномочие использовать значение. Цель могла заменяться ближайшим узлом, зеркалом или удалённой URAgency. Опыт мог экономить время и переносить устаревшее допущение. Фильтр мог принять страницу ошибки или частичное совпадение за результат.

Исполняла среда, а не карточка

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

URAgency могла сама быть целью; один URA мог вызвать другой; верхний объект мог координировать подчинённые. При каждом переходе менялись возможные владельцы учётных данных, библиотеки, положение в сети, политика замены целей и критерий завершения.

Прототип Silk показал реализацию на Tcl. Интерфейс позволял сохранять экземпляры и вводить данные активации. Пример посылал HTTP-запрос на жёстко заданный адрес и разбирал HTML регулярными выражениями; комментарии признавали слабую обработку ошибок. Это свидетельство эксперимента, а не массового внедрения.

Читаемая страница была ненадёжным интерфейсом

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

Фильтр обладал властью толкования. Квитанция о запуске доказывала начало, а не результат. Завершение процесса доказывало остановку компонента, а не выполнение человеческой цели. Повторный запуск мог выбрать другое зеркало, загрузить другую библиотеку или получить изменившийся формат.

RFC 2016 опубликован в октябре 1996 года как Experimental в Legacy stream. Черновик, статья авторов и Silk подтверждают архитектурный опыт, но не широкое применение и не прямое происхождение современных ИИ-агентов. Исторический вывод точнее: перенос намерения делает особенно важным вопрос, у какой среды остаётся исполнимая власть.

Источники