エージェントの計画が利用可能なツール権限と乖離する要因とは？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

What Factors Cause Agent Plans to Diverge From Available Tool Permissions? - Zima Store Online

エージェントの計画は、プランナーが説明や過去の成功例に基づいて推論する一方で、認可は現在のID、対象、状態、ポリシーに依存する場合、権限から乖離します。

ホームエージェントは「ファイルを管理する」ツールを見てバックアップを移動する計画を立てても、委任されたトークンでは1つの共有フォルダー内での読み取りしか許可されていないことがあります。計画は論理的に正しくても、実行できない可能性があります。整合性を確保するには、機械可読な機能情報、IDを考慮した事前チェック、明示的な拒否理由、そして計画から実行までの間に権限やリソース状態が変化した場合の再計画が必要です。

ツールの説明では通常、認可条件が隠れている

名前とJSONスキーマで説明できるのはツールの呼び出し方法であり、どのユーザー、パス、受信者、時間、金額が許可されるかまでは示されません。モデルは、例や以前のセッションから学習した仮定でその空白を埋め、現在の権限範囲を超える手順を生成します。

機能の表現に関する研究では、機能の表現とコンテキスト依存のディスカバリーがエージェントシステムの中核的な課題として挙げられています。機械可読な告知は計画に役立ちますが、告知された能力には依然として実行時の認可が必要です。この違いは、その後の家庭内テストでも明らかになります。

スコープ、制約、リスク分類、必要な承認を含む、アクションレベルの機能記述子を公開します。必要に応じて機密性の高いポリシーの詳細をプロンプトから除外しつつ、不可能な分岐を避けるために十分な抽象的制約をプランナーへ提供します。自動化が進む前に、中間結果を検証可能な状態に保つ必要があります。

委任されたIDは人間のアカウントより狭い権限しか持たないことがある

エージェントは、短期間だけ有効なトークンやサービスIDを通じて、ユーザーの代理として動作することがよくあります。人間なら手動で実行できる場合でも、エージェントの権限には管理操作、プライベートフォルダー、破壊的なメソッド、外部の受信者などが含まれないことがあります。

エージェントの権限モデルに関する分析では、人間のアクセス権をそのまま継承するのではなく、非決定的な委任ワークフロー向けに設計された権限モデルがエージェントには必要だと論じています。これにより、「ユーザーが実行できる」という前提がプランナーにとって有効ではない理由が明確になります。

計画では、各ステップを実効アクターと要求された機能に結び付ける必要があります。別の家族、承認、または昇格された認証情報が必要な場合は、複数の後続ステップを実行した後で初めて発見するのではなく、その依存関係を明示的に表現します。

計画後に権限と対象が変わることがある

ファイルの移動、共有の切断、トークンの期限切れ、デバイスのオフライン化、承認期間の終了、ポリシーの変更は起こり得ます。作成時に検証された計画でも数秒後には失敗する可能性があるため、実行レイヤーは副作用を起こす直前に、現在の状態に基づいて認可を行う必要があります。

実用的なアクションレベルの権限では、リクエスト経路でアクションレベルの権限を適用し、許可された呼び出しと拒否された呼び出しの両方を記録することが推奨されています。拒否のテレメトリは、不透明なツールエラーではなく、再計画のための構造化されたフィードバックになります。この境界は、現実的な運用条件の下で個別に測定すべきです。

失敗の境界は、不可能な機能に対して計画を繰り返すことです。拒否された後は、機能のスナップショットを更新し、安全な代替手段が存在するかを分類して、試行回数を上限内に抑えて停止します。目標を達成するためだけにポリシーを弱めたり、より広範なツールに置き換えたりしてはいけません。

-15% OFF