要約

  • 10月26日提出の個人Internet-Draftは、依頼者に見せてよい候補と必須条件を先に確定し、残ったエージェントだけを意味的に比較する。
  • 評価できない必須条件にはunsupported_constraintを返す。一方、任意の希望を無視して選んだ場合はignored_preferencesに記録する。

「何でもできます」と書いたAIエージェントの名刺は、受付の質問を免除しない。この依頼者に、その相手を見せてよいのか。Yong Cui、Yihan Chao、Chenguang Duの草案は、エージェントを選ぶ処理の最初にこの確認を置く。

提案するSemantic Routing Functionは、作業の意図、実行時の状況、必要な能力、制約、希望を受け取る。参照できる候補のプロフィールとローカルの方針を使い、一つの相手かエラーを返す。ここでの「ルーティング」はアプリケーション上の作業の振り分けであり、IPパケットの経路制御ではない。

草案の第6.1節には順序がある。依頼者の認証情報と許可された候補の範囲を確認し、入力を検査する。活動中で方針に適合する候補を残し、必須の能力と制約を適用する。意味の近さや好みを比べるのは最後だ。どれほど説明文が魅力的でも、必須条件で落ちた候補は復活しない。

未知の必須条件を推測で処理することも認めない設計だ。その場合はunsupported_constraintを返す。対応できない任意の希望なら選択を続けられるが、無視した内容をignored_preferencesに示す。「最適」と言いながら希望を黙って捨てる手品を封じる。

注意したいのは、data_locationやlanguageを状況説明に書いただけでは強制条件にならない点だ。保存場所や言語を必須にするなら、制約としても指定する。草案に出てくる中国語の機密報告と中国国内のデータ所在は説明用の例であり、実際の事案ではない。

選択結果には期限があり、別の相手へ切り替えても元の必須条件は引き継ぐ。実際に呼び出す時点では相手側やゲートウェイが現在の権限を再確認する。選ばれたというだけで処理能力が予約されるわけでも、実行許可が出るわけでもない。内定通知を入館証にしてはいけない。

IETFの記録では、この文書は10月26日提出の個人草案だ。承認済みDAWN憲章が最初に扱うのは公開エージェントの発見で、意味による仲介や順位付けは対象外と明記する。名前を探すことと、誰に頼んでよいか決めることには別の責任者がいる。