| (1) 概要 |
例題 3.7 では、契約ネットプロトコルを用いた問題解決組織の形成を行っている。例題のエージェントには、契約通知(タスクアナウンス)や入札(ビッド)といった契約ネットプロトコルに必要なメッセージを送受信し、状態遷移を行うのために必要なルールを記述しているが、これらが記述されているDash-Orgルールセットをインクルードすることでエージェント設計者が記述しなければならないルールを最小限にできる。ここでは、例題3.7で設計したエージェントをルールセットに対応した形式に直し、タスク通知を用いた組織が構成されるまでの手順について述べる。
この例題では、旅行者からの要求を受け取り、その要求にあったホテルを探して予約を行う代理店エージェントManagerを設計することが目的で、検索先となるホテルは、ホテルエージェントとして提供されている。また、宿泊の予約は、Managerがホテルエージェントとの間で契約を結ぶことにより行われるものとする 。
| (2) エージェント |
- ACLエディタ(_interface)
- ここにパフォーマティブ(:perforamtive)や宛先(:to)を入力し、 CnpManagerに対してメッセージを送信する。
- 組織構成エージェント(CnpManager)
- 他のエージェント(ACLエディタを含む)から受信したメッセージを組織構成プロトコル に適した形式に変換し、指定されたエージェントとの通信を行う。
- Manager
- 例題 3.7 で設計したエージェントにManagerをDash-Orgルールセットに対応できるように書き直したもの。 契約ネットプロトコルではマネージャに相当する。
- Hotel-X・Hotel-Y・Hotel-Z
- 例題 3.7 で述べられていたエージェントにDash-Orgルールセットに対応できるように書き直したもの。 契約ネットプロトコルではコントラクタに相当する。
| エージェント名 | 機能名 (:name) |
情報 | ||
| 宿泊料金 (:cost) |
徒歩時間 (:toho) |
朝食付 (:breakfast) |
||
| Manager | hotel-search | ― | ― | ― |
| Hotel-X | hotel-info | 8000 | 10 | yes |
| Hotel-Y | hotel-info | 10000 | 5 | yes |
| Hotel-Z | hotel-info | 5000 | 7 | no |
例題3.7で設計したプログラムに記述されていたルールとDash-Orgルールセットを用いた場合とのルール構成の違いを表2に示す。ルールセットを用いた場合でもエージェント設計者が記述する必要があるルールについては、色を変えて示した。また、Dash-Orgルールセットに対応できるように書き直したプログラムをリスト1に示す。
| TAFの例題 | Dash-Orgを使用した場合 |
|---|---|
| 利用者要求の受理と契約通知 (received-request) |
タスク実現可能性の判断(分割する場合) (received-request) |
| コントラクタからの入札受付 (received-bid) |
― (読み込んだルールセット内に記述されているので不要) |
| コントラクタからの入札締切 (timeout-without-bid) |
|
| 落札処理 (timeout-with-bid) | 入札の選択 (timeout-with-bid) |
| 処理結果受信 (receive-info) | ― (結果の表示についてはtimeout-with-bidで処理する) |
| 後処理 (prep-1) | ― (読み込んだルールセット内で処理されるので不要) |
| 後処理終了 (prep-2) |
1 // 例題 3.7 エージェントManager 2 (agent Manager /* 代理店エージェント(マネージャ) */ 3 (property 4 (create :author "太郎@ieice" :date "05/31/2000")) 5 (initial_facts 6 /* (CNP :state wait-task) 契約ネットプロトコルの初期状態設定 */ 7 ) 8
10
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||
| 6行目 | 契約ネットプロトコルの初期状態設定 |
| 【解説】契約ネットプロトコルにおける状態遷移は、ルールセット内のルールで行われている。エージェント設計者側で状態を示すファクトを生成する必要がないので除外した。 | |
| 9行目 | ルールセットの読み込み |
| 【解説】Dash-Orgルールセットの読み込み。ファイル名とRuleSet名は一致している必要はない。 | |
| 12〜15行目 | ルールセットをアクティブにする |
| 【解説】9行目で読み込んだルールセットをアクティブにするためのルール。17行目から記述してあるルールセットを別名で定義していた場合は、ここでそのルールセットが読み込んだDash-Orgルールセットよりも優先度が高くする必要がある。 | |
| 20〜32行目 | タスク実現可能性の判断 |
| 【解説】利用者からの要求メッセージに記述されている予約情報(宿泊料金(:cost)、徒歩時間(:toho)、朝食の有無(:breakfast))を基にタスク通知(task-announcement)を作成し、ホテルエージェント(Hotel-X、Hotel-Y、Hotel-Z)に対してブロードキャストするための記述である。 | |
| 33〜43行目 | 入札の選択 |
| 【解説】入札(bid)メッセージの中から採用する入札を決定するためのルールである。ここでは、宿泊料金(:cost)が最も安い入札を落札している。アクション部では採用したエージェント名と入札メッセージに含まれていた情報(:content)を出力している。 | |
例題3.7で設計したプログラムに記述されていたルールとDash-Orgルールセットを用いた場合とのルール構成の違いを表3に示す。ルールセットを用いた場合でもエージェント設計者が記述する必要があるルールについては、色を変えて示した。また、Dash-Orgルールセットに対応できるように書き直したプログラムをリスト2に示す。なお、Hotel-X以外のホテルエージェント(Hotel-Y,Hotel-Z)については、初期状態記述に格納されるホテル情報が違うのみなので省略する。
| TAFの例題 | Dash-Orgを使用した場合 |
|---|---|
| 通知された契約ないように基づく判断 (receive-task) |
タスク実現可能性の判断(分割しない場合) (receive-task) |
| 落札受信 (receive-award) |
― (読み込んだルールセット内で処理されるので不要。) |
| 落札後処理 (timeout-with-award) |
|
| 落札待ち打ち切り (timeout-without-award) |
1 // 例題 3.7 ホテルエージェントHotel-X 2 (agent Hotel-X /* ホテルエージェントHotel-X(コントラクタ) */ 3 (property 4 (create :author "太郎@ieice" :date "12/01/1999") 5 (agent :name Hotel-X) 6 ) 7 8 (initial_facts 9 /* (id :last 0) 初期状態設定 */ 10 (info :cost 8000 :toho 10 :breakfast yes) // Hotel-Xの場合 11 // Hotel-Yの場合 (info :cost 10000 :toho 5 :breakfast yes) 12 // Hotel-Zの場合 (info :cost 5000 :toho 7 :breakfast no) 13 )
|
|||||||||||||||||||||||||||||
| 9行目 | 初期状態設定 |
| 【解説】入札を識別するための識別子は、Dash-Orgルールセット内で管理しているのでエージェント設計者が改めて専用のファクトを生成する必要はない。 | |
| 25〜34行目 | タスク実現可能性の判断(分割しない場合) |
| 【解説】ここでは、エージェントがもっているホテル情報 (info) からタスクを受けるか判断するためのルールを記述する。ホテルエージェント側ではタスク分割をする必要がないのでMnagerエージェントで使用した(decompose)ファクトを生成する必要はない。 | |
| (3) 動作実験 |
(2)で設計したエージェントをリポジトリに読み込み、ワークプレース上から要求メッセージを送信し、エージェント間でやりとりされるメッセージを確認する。
| 1. 起動と読み込み | ||||||||||||||||||||||||||||||||||
|
リポジトリとワークプレースを起動し、(2)で示したエージェントが読み込まれていることを確認する。 また、全てのエージェント名が既知であり、同じリポジトリ上に存在しているものとする。
| ||||||||||||||||||||||||||||||||||
| 2. メッセージの送信 | ||||||||||||||||||||||||||||||||||
次に、 [acl-editor] タブの各空欄に以下のように入力し、 [Send] ボタンを押す。
| ||||||||||||||||||||||||||||||||||
| 3. 直接落札の送信 | ||||||||||||||||||||||||||||||||||
以下のように直接落札(directed-award)メッセージが送信される。
| ||||||||||||||||||||||||||||||||||
| 4. タスク実現可能性の判断 (Manager) | ||||||||||||||||||||||||||||||||||
|
(2.1)の20〜32行目に記述したタスクの実現可能性を判断するためのルールが発火する。 この後、読み込んだルールが発火し、ホテルエージェントに対してタスク通知メッセージが送信される。
| ||||||||||||||||||||||||||||||||||
| 5. タスク実現可能性の判断 (Hotel-X, Hotel-Y, Hotel-Z) | ||||||||||||||||||||||||||||||||||
(2.2)の25〜34行目に記述したルールが発火する。各ホテルエージェントはタスク通知の内容と表1の内容を比較し、以下のような処理を行う。
| ||||||||||||||||||||||||||||||||||
| 6. 採用する入札の決定 (Manager.dash: 33〜43行目) | ||||||||||||||||||||||||||||||||||
一定時間が経過したあと、採用する入札を決定するためのルールが発火する。入札を返信してきたエージェントは2つあるが表1よりHotel-Xのほうが宿泊代金(:cost)が安いので、Hotel-Xが採用される。採用されなかった入札を返信してきたHotel-Yに対して交渉終了(negotiation-end)メッセージが送信される。
また、発火したルールのアクション部で採用したホテルに関する出力をする記述がされているため以下に示す出力が得られる。
| ||||||||||||||||||||||||||||||||||
| 7. 落札の送信 (CnpManager → Manager) | ||||||||||||||||||||||||||||||||||
一定時間経過後、 CnpManager から落札(award)メッセージが送信される。
| ||||||||||||||||||||||||||||||||||
| 8. インスタンシエート (Manager) | ||||||||||||||||||||||||||||||||||
Managerエージェントがインスタンシエートを行う。
| ||||||||||||||||||||||||||||||||||
| 9. 落札の送信 (Manager → Hotel-X) | ||||||||||||||||||||||||||||||||||
Manager から Hotel-X に対して落札(award)メッセージが送信される。
| ||||||||||||||||||||||||||||||||||
| 10. インスタンシエート (Hotel-X) | ||||||||||||||||||||||||||||||||||
エージェントHotel-Xがインスタンシエートを行う。
| ||||||||||||||||||||||||||||||||||
| 11. 動作可能の送信 | ||||||||||||||||||||||||||||||||||
エージェント Hotel-X から Managerエージェントに対して動作可能(acceptance)メッセージが送信され、Managerエージェントから CnpManager に動作可能メッセージが送信される。最後にCnpManagerが結果を出力する。
| ||||||||||||||||||||||||||||||||||