「ブロック」は「失敗」ではない：エージェントには境界フィードバックが必要である
ほとんどのエージェント設定では、ブロックされたアクションをツールの失敗として扱っています。
エージェントがツールを呼び出します。リクエストがルールに抵触します。システムが汎用的なエラーを返します。ツール呼び出しが失敗します。
一見、これで問題ないように思えます。安全でないアクションは阻止されました。しかし、これでは問題の半分しか解決していません。
汎用的なエラーは、エージェントが自身の制限内で動作する助けにはなりません。それはポリシーに基づく決定を単なる「ノイズ」に変えてしまいます。エージェントは修正方法を推測しようとしたり、同じ間違いを繰り返したり、異なるペイロードを試したりするかもしれません。これにより、無益なリトライのループが発生します。
ブロックされたアクションは、予期せぬクラッシュではなく、構造化された決定であるべきです。
リクエストがブロックされた際、外部システム自体は変更されてはなりません。しかし、レスポンスはエージェントに対して、どのように安全に進めるべきかを伝えなければなりません。
単純なエラーの代わりに、構造化されたレスポンスを使用してください。
エージェントが、計画中に内容が変更されたファイルに書き込もうとしている場面を想像してください。汎用的なエラーは「失敗しました」とだけ伝えます。一方、構造化されたレスポンスは次のように伝えます。
- 決定ステータス: conflict
- 結果ステータス: no impact
- 理由: stale state
- 次のアクション: re-read target state
これで、エージェントは目標が不可能ではないことを理解できます。単に情報を更新する必要があるだけだと分かります。推測をやめ、正しい次のステップを踏むことができます。
これは多くのシナリオで有効です。
- パスがスコープ外である場合は、許可されたパスを提案する。
- すでに効果が存在する場合は、その結果を再利用することを提案する。
- 影響が大きすぎる場合は、人間によるレビューを待つことを提案する。
これによって境界が緩くなるわけではありません。アクションはブロックされたままです。システムは安全なままです。単に行き止まりを「ガイド付きの経路」に変えているだけなのです。
これとセキュリティのバランスを取る必要があります。詳細すぎるフィードバックは、悪意のあるエージェントがシステムの限界を探る（プローブする）手助けをしてしまう可能性があります。
古いデータや不正な入力といった運用上の摩擦については、明確な理由コードを使用してください。エージェントが不審な挙動を示したり、ヒントを無視したりする場合は、汎用的な拒否、または人間によるレビューに切り替えてください。
エージェントへのフィードバックと監査スコアは切り離して管理してください。エージェントにはコンプライアンスを遵守する方法を知る必要があります。システムには、エージェントが不適切な振る舞いをしていないかを知る必要があります。これら2つの役割を混同してはいけません。
境界が存在するのは、エージェントが実際のシステム上で動作できるほど有用になってきているからです。現実の業務にはルールと制限があります。
失敗だけを返す境界は「壁」です。ガイダンスを提供する境界は「ツール」なのです。
「Blocked」とは、以下の状態を指すべきです：
- 期待されたインパクトが発生しなかった。
- その理由が判明している。
- 次にとるべき安全なアクションが明確である。
出典: https://dev.to/davidloibner/blocked-is-not-failed-agents-need-boundary-feedback-bbg
オプションの学習コミュニティ: https://t.me/GyaanSetuAi