Russian
| English
"Куда идет мир? Каково будущее науки? Как "объять необъятное", получая образование - высшее, среднее, начальное? Как преодолеть "пропасть двух культур" - естественнонаучной и гуманитарной? Как создать и вырастить научную школу? Какова структура нашего познания? Как управлять риском? Можно ли с единой точки зрения взглянуть на проблемы математики и экономики, физики и психологии, компьютерных наук и географии, техники и философии?"

«Многоагентные системы (обзор)» 
В.И.Городецкий, М.С.Грушинский, А.В.Хабалов

Синхронизация входов и выходов уровней также обеспечивается этой подсистемой. Фактически правила подсистемы выступают в роли фильтра между сенсорами агента и внутренними уровнями агента (“supressors”) и между уровнями и их исполнительными элементами (“censors”). Посредничество это остается активным все время работы агента, однако оно “прозрачно” для уровней, каждый из которых продолжает действовать так, как если бы он был единственным при управлении агентом, не заботясь о возможном конфликте.

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

5.3.3. Многоуровневая архитектура для распределенных приложений 

Эта архитектура [23] была разработана специально для системы здравоохранения. Она включает в себя многоуровневую структуру знаний, рабочую память, менеджера коммуникаций и человеко-машинный интерфейс (см. рис.10)

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

 Рис.10. Архитектура для распределенных медицинских приложений

В этой архитектуре интеллектуальное поведение поддерживается совместной работой таких компонент, как блок решающих правил для вычисления плана, блок правил для управления задачами, их декомпозицией и размещением, а также блок правил для поддержки соглашений с другими агентами при кооперативном решении задач. Реактивное поведение реализуется с помощью управляющего уровня, который реагирует на изменение состояния рабочей памяти (например, при поступлении новых результатов решения задачи, целей или сообщений, а также при изменении имеющихся данных, целей, межагентских соглашений или состояний задач). Ключевым моментом данной архитектуры является трехуровневая организация знаний, при этом выделяются следующие уровни:

1. Уровень специфических предметных знаний, в котором содержатся медицинские знания о болезнях, знания о планах управления лечением болезней (“протоколы”), база данных о пациентах (истории болезней) и база данных о доступных ресурсах. Однако предметные знания не содержат какой-либо информации о том, как их следует использовать, здесь представлены только свойства предметной области.

2. Уровень знаний о процедурах вывода; он содержит декларативные правила вывода, которые должны применяться к предметным знаниям о конкретном пациенте, чтобы вывести новые данные. Этот уровень — основной в архитектуре. В свою очередь он подразделяется на компоненты принятия решений в условиях неопределенности, управления задачами и управления кооперацией агентов. Например, модуль управления задачами содержит декларативную схему вывода для управления переходами состояний задачи. Особенности системы вывода решений состоят в том, что она не использует понятия ментального состояния агента (убеждения, желания, намерения) и не использует какой-либо логический язык для вывода, для этого она использует стратегии аргументации в условиях неопределенности. Это означает, что эта архитектура не является BDI-архитектурой.

3. Менеджер задач ответственен за декомпозицию задач на подзадачи и их распределение по соответствующим агентам, а также за управления переходами состояний задач. Управление кооперацией агентов использует механизм, основанный на взаимных обязательствах агентов (“любой агент согласен предпринимать схему действий, которая имеет целью исполнить задачу за подходящее время”), и соглашениях о том, при каких условиях агент вправе отказаться от своих обязательств и как он должен себя вести по отношению к другим агентам, когда такие обстоятельства возникнут.

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

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

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

Рабочая память служит для запоминания текущих данных, генерируемых уровнем управления, пользователя и менеджера коммуникаций. Типы информации, которая хранится в рабочей памяти, таковы: цели, которые должны быть достигнуты; состояния задач, которые находятся в текущем состоянии процесса выполнения соглашений с другими агентами. Фактически, в привычной нам терминологии, рабочая память есть ни что иное, как доска объявлений.

Менеджер коммуникаций содержит в себе сообщения, которые должны быть посланы другим агентам, представленные на языке коммуникаций с примитивами типа примитивов языка KQML: обратиться с просьбой, принять, отвергнуть, изменить, предложить, проинформировать, запросить данные, отказаться и подтвердить.

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

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

5.3.4. IDS-архитектура 

Эта архитектура возникла [31] в результате комбинирования двух направлений исследований. Первое из них — это логика рассуждений о действиях и изменениях с исходным понятием «населенной (живыми существами) динамической системы» (“Inhabited Dynamic System”-IDS). Второе направление — это построение эффективной реализации интеллектуальной системы.

Архитектура имеет трехуровневую структуру и является гибридной. Полагается, что IDS — система размещается в некотором мире (среде) и состоит из двух базовых частей — “Мыслящей части” (“Я”, “Ego”) и “Машины” (“Подвижной части объекта”, “тела”, “vehicle”). Автор интерпретирует понятие “Мыслящая часть” как интеллектуальную, основанную на знаниях часть автономного агента, его “мозг”, в то время как “машина” — это тело агента, т.е. его бессознательная часть, которая в порядке реакции на восприятие и приказы на исполнение что-то делает. IDS воспринимает внешнюю среду. Используя процесс восприятия, она редуцирует и существенно обобщает воспринимаемую информацию, и посылает выход в “Мыслящую часть”. В свою очередь, “Мыслящая часть” посылает команды на свою подвижную часть, которая их отрабатывает без какого-либо дополнительного управления или изменения, вызывая соответствующие изменения во внешнем мире (см. Рис.11).

Эта идея реализуется в виде трехуровневой архитектуры, представленной на рис.12. Разделение по уровням производится в соответствии с характером тех вычислений, которые на них выполняются. Первый уровень — это уровень процессов, на котором периодически выполняются с заданной частотой некоторые вычисления, а также осуществляется управление процессами восприятия и исполнения. Второй уровень, называемый уровнем ответной реакции, вычисляет ответную реакцию на асинхронные события, которые либо воспринимаются уровнем процессов, либо им генерируются. Уровень анализа выполняет символические рассуждения, такие, как предсказание, планирование и перепланирование, а также является тем местом, где располагается компонента обучения агента. Данная архитектура является типичным представителем многоуровневой архитектуры, которая относительно близка к архитектуре “Touring Machine” и отличается от нее вариантом распределения задач по уровням. Достоинства архитектуры, по мнению автора, следует рассматривать в трех аспектах:

Рис. 11. Взаимодействие IDS-архитектуры с внешним миром

-в ней имеет место явное разделение задач, которые требуют различных концептуальных и вычислительных рамок;

-она позволяет при проектировании использовать различные инструментальные средства (языки, алгоритмы) для упрощения разработки;

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

5.3.5. WILL-архитектура 

Эта архитектура интенсивно использует метафоры и понятия, традиционно применяемые к описанию человеческой интеллектуальной деятельности, что делает ее привлекательной и понятной, но от этого она не становится в чем-то принципиально новой по отношению к другим архитектурам, а, как представляется, только отдаляет возможность ее практической реализации. Однако авторы утверждают, что это наиболее простая архитектура автономного агента. Следует, однако, принимать во внимание, что это архитектура рассчитана на одного агента, который имеет одну цель и его функционирование направляется его собственными мотивами, которые автор называет интересами (“concerns”). Вопрос о методах кооперации и коммуникации агентов такой архитектуры авторы оставляют без внимания. Эта архитектура представлена на  рис.13.

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

Рис.12. IDS-архитектура

Главной проблемой при этом является вопрос о том, как организовать совместную согласованную работу этих модулей, в частности, согласовать взаимодействие потоков информации и потоков управления. Чтобы решить проблему согласованного взаимодействия потоков информации, они предлагают применить нечто вроде схемы “бродкастинга”, когда соединены все входы и все выходы модулей между собой, так что любое сообщение, генерируемое тем или иным блоком становится доступным любому другому блоку. Все эти сообщения собираются в глобальном буфере, который называется Памятью. Все блоки могут  читать информацию из Памяти, кроме Сенсоров, и все они могут писать информацию в Память, кроме Исполнительного устройства. Каждый модуль может просто брать информацию из памяти, когда ему это нужно.

Авторы этой архитектуры полагают, что цели системы могут меняться и генерироваться “изнутри” агента, будучи обусловленными некими фундаментальными целями агента, которые авторы называют “интересами“ (“concerns”).

Рис.13. WILL-архитектура

Они определяются как некие предпочтения агента находиться в каких-то состояниях и каких-то состояний избегать. Когда агент получает информацию, которая в соответствии с его интересами отвечает предпочтительному состоянию (скажем, температура среды равна 20 градусов),  то генерируется внутренний сигнал о том, что желательно, чтобы в этом состоянии среда оставалась и в будущем. Для каждого состояния внешней среды агент должен уметь оценивать меру его релевантности своим интересам (нечто вроде заряда статического электричества — в объяснении авторов). Это означает, что когда некий модуль обращается к памяти, он “видит“ тот ее фрагмент, который имеет “наибольший заряд“ и обрабатывает этот фрагмент. Наибольшее внимание модуля привлекается к тому событию, с которым агент не знает, что делать.

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

5.3.6. InteRRaP-архитектура 

Основная идея этой архитектуры [36] в том, чтобы представить агента как множество уровней, которые связаны через управляющую структуру и используют общую

Рис.14. InteRRaP-архитектура агента

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

Интерфейс с внешним миром содержит возможности агента по восприятию событий внешнего мира, воздействия на него и средства коммуникации.

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

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

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

База знаний агента имеет трехуровневую структуру и построена по принципу доски  объявлений. Уровни базы знаний фактически отвечают уровням абстракции знаний в соответствии со структурой управляющих компонент. Модель мира агента содержит  убеждения агента в соответствии с уровнем, ориентированным на поведение. Второй уровень соответствует модели ментальных знаний агента и знаниям о текущем ментальном состоянии агента (намерения, цели, планы). Наконец, третий уровень содержит знания  и убеждения агента о других агентах, информацию о совместных планах, целях и намерениях, т.е. то, что связано с “общественным  контекстом”. Внутри базы знаний, как уже отмечалось, возможен доступ с верхних уровней к нижним. Например, компонента, ответственная за поведение, не имеет доступа к знаниям о ментальной модели и к знаниям о кооперативном поведении.

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

Очевидно, существует три варианта реакции агента на внешние события:

-реакция с использованием только поведенческого уровня, когда этот уровень находит фрагмент поведения, адекватный ситуации, без явного привлечения локального планирования;

-реакция с использованием локального планирования, когда задача перемещается с нижнего уровня на уровень локального планирования, где и конструируется план;

-реакция с использованием уровня кооперативного планирования, когда поиск плана с уровня локального планирования перемещается дальше на уровень планирования кооперативного поведения.

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

6. Языки программирования агентов

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

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

6.1. Требования к языкам программирования агентов 

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

1. Обеспечение переносимости кода на различные платформы. Это требование возникает всегда, когда необходимо обеспечить агента свойством мобильности. Чтобы обеспечить мобильность агента, язык должен поддерживать механизм посылки, передачи, получения и выполнения кодов, содержащих агентов. Имеются два различных подхода, которые решают проблему мобильности. Первый — это передача агента в текстовой форме, как специального сценария (script) с последующей интерпретацией этого сценария на принимающей машине. Второй — передача агента в форме машинно-независимого байт-кода. Этот байт-код генерируется транслятором на этапе создания агентской системы, посылается по сети и выполняется интерпретатором байт-кодов на принимающем компьютере. Оба из этих методов имеют свои преимущества и недостатки.

2. Доступность на многих платформах. Это требование непосредственно вытекает из предыдущего. Интеллектуальные агенты должны работать в гетерогенной компьютерной среде. Любой компьютер, получающий агента, должен быть способен принять и выполнить его.

3. Поддержка сетевого взаимодействия. Свойство агентов участвовать в переговорах и многие другие особенности агентов нуждаются в доступе к удаленным ресурсам. Поддержка сетевых услуг может включать семейства соответствующих программных интерфейсов (APIs) таких как: sockets, интерфейсы к базам данных, интерфейсы взаимодействия объектов (CORBA, OLE, ActiveX и т.д.), специальные механизмы, встроенные в язык (типа Remote Method Invocation в языке Java), специальные примитивы языка для осуществления переговоров агента и т.д.

4. Многопоточная обработка (“Multithreading”). Агент может выполнять некоторые действия одновременно. Тем самым, язык программирования агентов должен включать поддержку параллельного выполнения различных функций агента (типа “threads”) и различных примитивов синхронизации (семафоры, мониторы, критические секции, и т. д.). Кроме того, процесс который выполняет всех агентов (и может, фактически, рассматриваться как мета-агент) должен поддерживать параллельное выполнение агентов. Последнего можно добиться с помощью отдельной виртуальной машины с реализованным режимом вытесняющей многозадачности и собственной стратегией разделения времени.

5. Поддержка символьных вычислений. Так как в рамках современных взглядов агент должен активно использовать достижения и методы искусственного интеллекта, было бы полезно иметь поддержку символьных вычислений и, возможно, логического программирования, встроенную в язык (подобно PROLOG и LISP), а также иметь встроенный механизм выводов, включающий различные стратегии поиска решения. Автоматическое управление памятью и сборка мусора — стандартные средства для таких языков.

6. Безопасность, в частности, наличие системы защиты от несанкционированного доступа и “плохих кодов”. Это важно по многим причинам. Мобильные агенты, которые приходят из сети, могут таить в себе множество опасностей для принимающей машины, так как они выполняются в ее адресном пространстве. Для обеспечения безопасности перед передачей управления каждому агенту необходимо выполнить процесс авторизации агента, т. е. проверить, зарегистрирован ли он и имеет ли  соответствующие полномочия  (привилегии), чтобы выполнить то или иное действие или обратиться к некоторым ресурсам. Система безопасности должна предотвращать любые несанкционированные действия агента.

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

8. Языковая поддержка свойств агента. Было бы, вероятно, удобно иметь поддержку специфических для агента свойств, встроенную в язык на уровне синтаксических конструкций, так, чтобы, например, свойства типа “beliefs-desires-intentions” (BDI), инструкции для переговоров и обеспечения мобильности, места встречи, и т.д. могли бы быть выражены с помощью соответствующих примитивов языка.

9.   Эффективность, достаточная для потребностей прикладных программ.

6.2. Классификация

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

1. Универсальные языки программирования (Java)
2. Языки, «ориентированные на знания»:

  • языки представления знаний (KIF)
  • языки переговоров и обмена знаниями (KQML, AgentSpeak, April)
  • языки спецификаций агентов.

3. Специализированные языки программирования агентов (TeleScript)

4 Языки сценариев и scripting languages (Tcl/Tk)

5. Символьные языки и языки логического программирования (Oz)

6.3. Сравнительная характеристика языков 

Java — вероятно, один из наиболее популярных языков используемых в последнее время для программирования агентов. Java представляет из себя язык программирования, подобный C++ по синтаксису, но более схожий со Smalltalk и Objective C по идеологии. Система программирования на Java включает в себя виртуальную машину Java и транслятор с Java в bytecode.

Язык Java предусматривает создание приложений, переносимых на различные платформы. Программа, написанная на Java, компилируется в специальный машинно-независимый байт-код. Затем этот код может быть исполнен с помощью интерпретатора Java на любом компьютере, где реализована Java Virtual Machine. Тем самым обеспечивается платформо-независимость Java — приложений на уровне байт-кода, который может приходить откуда угодно, включая Web-страницу, в которой содержится ссылка на него. Java Virtual Machine работает в среде вытесняющей мультизадачности и поддерживает облегченные процессы (threads). Средства создания и синхронизации таких процессов включены в Java на уровне языковых конструкций и классов. Средства многозадачности также призваны обеспечить реакцию системы в реальном времени для мультимедийных приложений, критичных ко времени.

Java представляет собой истинно объектно-ориентированный язык программирования с сильной типизацией. Схожесть с C++ делает его простым для изучения программистами. В нем отсутствует предельно ясное распределение памяти и для повышения надежности программ из языка исключена арифметика указателей. Каждый тип данных понимается как класс объектов, любая функция является методом класса. Ее вызов рассматривается с объектно-ориентированных позиций как посылка сообщения объекту. Имеется встроенная расширяемая библиотека классов, включающая Abstract Window Toolkit (AWT) для создания пользовательских интерфейсов, классы поддержки основных типов данных, threads, сетевых возможностей, графики, мультимедиа, и т. д. К средствам повышения надежности следует отнести встроенную в язык обработку исключительных ситуаций (exceptions) и run-time контроль за выполнением программы, такой, как проверка выхода за границы массивов и т.д.

Язык Java может быть использован для создания двух типов программного обеспечения: автономных приложений, которые могут включать «родной» (т.е. машинно-зависимый) код и апплетов — платформо-независимых приложений, которые могут приходить из сети и запускаться с помощью поддерживающих Java Web — броузеров. Апплеты могут встраиваться в Web страницы после специальной метки языка HTML, указывающей ссылку на их код, и запускаться автоматически, когда страница открывается в броузере.

Язык Java был спроектирован с учетом возможности создания приложений работающих в распределенной среде. Кроме поддержки возможностей TCP/IP, таких как чтение URLs, работу с сокетами и обмен сообщениями на уровне датаграмм, в Java предусмотрен механизм удаленного вызова объектов, определенный в спецификации RMI (Remote Method Invocation). Этот механизм позволяет вызывать методы удаленных объектов, объявленные в специальном интерфейсе, причем синтаксически такой вызов выглядит идентично вызову простого метода. Эта схема предоставляет более гибкие возможности по сравнению с традиционным протоколом RPC (Remote Procedure Call). Механизм сериализации (Serialization) позволяет сохранять объекты и графы объектов в потоках данных (файлах, сетевых каналах) и восстанавливать их при необходимости. При этом обеспечивается достаточный уровень секретности передаваемой информации. С выходом спецификации Java IDL и нового продукта Black Widow компании PostModern Computing Technologies открылась возможность к сближению Java приложений и коммуникационного стандарта CORBA 2.0 консорциума OMG (Object Management Group). Специальный компилятор позволяет, исходя из описаний интерфейсов на языке IDL CORBA, генерировать код Java объектов. Это позволит использовать вызовы объектов, находящихся в корпоративных сетях, из Java приложений и сделать Java — объекты доступными для этих вызовов.

На сегодняшний день Java доступна на следующих платформах: Windows 95/NT, Solaris (Intel, SPARC), Macintosh System 7.5.

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

Приложение, рассчитанное на неподготовленного пользователя (End User Application);

Систему, основанную на знаниях (Knowledge Based System);

Хранилище специальных знаний (Knowledge Base Repository) — хранилище знаний о содержимом базы знаний — используется для отслеживания истории доступа, целостности и других аспектов функционирования баз знаний;

Система управления базами данных (Database System);

Активные сенсоры (Active Sensors) - отвечают за обмен данными (знаниями) с “внешним миром”

Возможны различные способы взаимодействия перечисленных компонент.

Разработчики KQML выделяют 3 направления, особенно важных с их точки зрения для коммуникаций интеллектуальных агентов:

Связность (Connectivity) — фокусируется на способе связывания агентов между собой;

Архитектура (Architecture) - акцентирует внимание на способе построения будущей системы (будет ли система статической, когда все компоненты известны уже на этапе проектирования/реализации или динамической);

Коммуникации (Communication) - данное направление рассматривает синхронность/асинхронность обмена сообщениями между агентами.

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

Архитектура. Агенты — это отдельные процессы, работающие в одном адресном пространстве или на различных машинах, соединенные посредством Internet.

Коммуникации. Язык поддерживает следующие стратегии передачи информации: point to point, multicast, broadcast.

Синтаксис. Сообщения между уровнями содержимого, сообщений и коммуникаций представлены в виде s-выражений языка Lisp. Между процессами выражения передаются как потоки ASCII -символов.

Протокол. Для транспортной поддержки KQML был создан специальный протокол — SKTP (Simple Knowledge Transfer Protocol).

Рассмотрим уровни языка KQML. Язык KQML состоит из трех уровней: содержимого, сообщений и коммуникаций. KQML-выражение можно рассматривать как выражение-содержимое, помещенное в сообщение-обертку, которое, в свою очередь, помещено в коммуникационную обертку. На уровне содержимого находится представление знаний на некотором языке. Уровень сообщений добавляет дополнительные атрибуты, такие как описание языка, на котором выражено содержимое, его онтологию и тип используемого метода переговоров. Коммуникационный уровень добавляет информацию об отправителе и получателе сообщения, а также указывает, является сообщение синхронным или асинхронным.

Основу синтаксиса языка KQML составляют имена примитивных действий- сообщений, которые в английской транскрипции называются “performatives” Тип сообщений определяет, что можно сделать с предложениями, содержащимися в сообщении, с этим связано само название KQML-сообщений на английском языке.

Все действия-сообщения можно разделить на следующие категории:

-языка содержимого KQML, который предполагает модель баз в форме множества предложений некоторого языка, который может быть объектным;

-контекста рассуждений - подмножества предложений (фрагмента) базы знаний; запросы и отклики должны делаться относительно некоторого контекста, при этом сообщения данного типа должны позволять определять контекст и переключаться между фрагментами базы знаний;

-определения, которые имеют целью  активизировать и отменять определения;

-ответы на вопросы, которые позволяют задавать вопросы относительно истинности предложений;

-отклики, которые определяют набор сообщений для получения ответов на заданные вопросы.

SKTP — Simple Knowledge Transfer Protocol. Первые две реализации SKTP были написаны на языках Common Lisp и Пролог соответственно. В настоящее время разрабатываются интерфейсы на других языках. SKTP — это реализация стека протокола KQML. Как и KQML, SKTP состоит из нескольких уровней: содержимого, сообщений и коммуникации. Коммуникации между приложениями происходят на языке приложений, поддержку данного процесса обеспечивает уровень содержимого (content layer). Выражения, помеченные для передачи, “обертываются” в сообщения — это т.н. уровень сообщений (message layer) , реализуемый с помощью интерфейса библиотеки посредника (Facilitator Interface Library — FIL).  Уровень, отвечающий за  стратегию передачи сообщений (multicast, broadcast и т.д.) называется коммуникационным и реализован в виде отдельного агента, называемого посредником (facilitator). На самом нижнем уровне, реально несущем структурированные данные между посредниками, находится протокол TCP/IP.

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

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

Перечислим основные свойства языка KIF.

1. Язык является декларативным, чем отличается от языков типа Prolog и Emycin.

2. Язык является логически полным.

3. Язык является транслируемым (translatability) — он предполагает значения для трансляции декларативных баз знаний в/из типичных языков представления знаний.

4. Язык является хорошо читаемым, что упрощает его использование разработчиком баз знаний.

5. Язык может быть использован как язык представления знаний.

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

Соответствие между линейным и структурированным представлениями определяется следующим образом: строка ASCII-символов будет правильным выражением линейного варианта языка KIF тогда и только тогда, когда (1) она допускается интерпретатором языка Common Lisp, и (2) структура, порожденная интерпретатором Common Lisp  будет правильным выражением структурированного KIF.

В структурированном KIF определены следующие синтаксические конструкции: word, expression, operator, constant, term, sentence, definition, rule и т.д.

Применимость KIF в рамках разработки агентов видится следующим образом. Ядро агента, а именно: подсистемы управления памятью, планирования, база знаний и т.д. пишутся на С++ или на одном из языков Java, Telescript (если нас интересует способность агента к мигрированию по сетям), а KIF используется как язык для обмена знаниями/данными с другими агентами (для этого агент должен иметь подсистему перетрансляции с языка внутреннего представления знаний на KIF). Язык KIF можно также использовать и как язык представления собственных знаний агента, в этом случае отпадает надобность в упомянутом выше трансляторе.

                April: Agent Process Interaction Language. Это язык высокого уровня, который предлагает простой интерфейс к другим языкам программирования типа C. April ориентирован на реализацию многоагентных систем. Однако, April не является языком программирования агентов в том смысле, что он не предлагает таких высокоуровневых возможностей, как планировщики, механизмы вывода на основе правил и системы представления знаний. April скорее является объектно-ориентированным языком со средствами поддержки параллельного выполнения задач и рассматривающим объекты как процессы. Он является подходящей основой расширений для задач распределенного искусственного интеллекта и для прикладного программирования многоагентных систем.

                AgentSpeak. Аналогом класса в данном языке выступает семейство, представителем (экземпляром) семейства является агент. Каждый агент обладает базой данных отношений с публичной и приватной частями, множеством сервисов и множества планов — процедур, о которых известно лишь то, выполнены они или нет. Язык обеспечивает распределенность хранения информации в пространстве функционирования агентов.

Каждый агентский сервис может быть одного из следующих трех типов: achieve, query, told. Каждый агентский план определяется при помощи имени и описания абстрактной ситуации, в которой он может быть применен. Во время работы агента, если план применим в текущей ситуации, выполняются действия, связанные с данным планом.

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

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

Каждый агент может находиться в одном из трех состояний: активный, ожидающий, неработающий (idle).

По прибытии к агенту сообщения оно кладется в его почтовый ящик, далее агент начинает обрабатывать сообщение. Это заключается в следующем. Сначала по типу речевого сообщения (achieve, query, told) выбираются планы, которые могут быть потенциально применимы в данной ситуации (множество подходящих планов), далее выполняется просмотр абстрактных ситуаций множества выбранных на предыдущем шаге планов (множество применимых планов). Затем для последнего множества строятся реализации (ссылки). По умолчанию система выбирает один план из множества применимых и начинает выполнять действия, указанные в целевой части описания плана. Такой выбранный план называется намерением . В любой момент выполнения агент может обладать несколькими намерениями — потоками. Как следствие из этого, агент является многопотоковым процессом. Внешние и внутренние сервисы агента функционируют, конкурируя за ресурсы, поскольку агент может выполнять как внешние, так и внутренние сервисы.

Данный язык близок по духу таким языкам как Agent0 and PLACA, от них он отличается тем, что здесь ментальное состояние агента рассматривается как объединение убеждений (отношений), целей (сервисов), планов и намерений. Agent0 рассматривает ментальное состояние, состоящее из списков способностей, убеждений и намерений.

Agent0 и Placa трактуют агентно-ориентированное программирование как вид объектно ориентированного программирования, создатели же AgentSpeak считают, что первое является расширением (продолжением) второго.

                TeleScript. Первая коммерческая реализация концепции мобильного агента была сделана в среде TeleScript-технологии фирмы General Magic. Данная технология основана на метафоре электронного рынка — общедоступной сети (public network), которая позволяет продавцам и потребителям товаров и услуг находить друг друга и заниматься совместным бизнесом.