他者に先んじて、自らのエージェントにレート制限をかける

1,000通の送信につき1件のスパム報告があると、メールアカウントは審査対象となります。スパム報告率が0.5%に達すると、プラットフォームは送信を停止します。バウンスも同様です。これらの制限に達した場合、単にタイマーが切れるのを待つだけでは済みません。修正の証拠を添えてサポートに連絡する必要があります。

プラットフォームの制限値を目標にしてはいけません。それは最後の防衛線として捉えてください。自分自身で、より厳格な制限を設定する必要があります。

自律型エージェントは、従来のコードとは異なる動きをします。モデルがループに陥る可能性があります。返信がwebhookをトリガーし、それがまた別の返信をトリガーする、といった具合です。小さなバグが、数分で数千通のメールへと膨れ上がります。モデルは、自分が送りすぎているかどうかを判断できません。その「認識」をインフラストラクチャに組み込む必要があります。

ワークスペースを保護するためにポリシーを活用しましょう。ポリシーでは以下の設定が可能です： • 1日の送信クォータ • ストレージ容量制限 • 保持期間 • スパム設定

自らに課したクォータは、単なるスロットリングではありません。それは「アサーション（断言）」です。もしサポート担当者が1日に必要なメールが150通だけであれば、制限を151通に設定しておくことで、何かがおかしいということに気づけます。これはサーキットブレーカーのように機能します。エラーが大きなコスト（損失）に変わる前に、可視化してくれるのです。

また、アウトバウンドルールを使用して送信方向を制御することもできます。特定のドメインをブロックしたり、エージェントが新しいスレッドを開始するのを防いだりできます。これらのルールは、メッセージが送信される前に評価されます。ルールのチェック中にシステムエラーが発生した場合、システムは「フェイルクローズ」します。つまり、安全でない送信のリスクを冒すのではなく、メッセージをブロックすることを意味します。

安全を確保するために、以下の手順に従ってください： • メッセージ配信、バウンス、苦情、拒否に関するwebhookを購読する。 • これらのレートを独自のテレメトリで監視する。 • レートが上昇した場合は、手動でアウトバウンドロジックを停止する。

「プラットフォームによって停止させられた」と言うよりも、「自ら停止させた」と言う方が、優れたインシデントレポートです。

送信量の急増が心配な場合は、クォータを「行き止まり」にしないでください。「エスカレーションパス」にしましょう。エージェントが制限に達した場合は、人間にアラートを飛ばすか、承認のためにメッセージをキューに溜めます。メールの遅延は軽微な問題ですが、破壊された送信者レピュテーションの修復には数週間かかります。

次のステップ： ピーク時の送信量の2倍の1日クォータを持つポリシーを作成します。それをワークスペースに適用してください。ステージング環境でクォータをトリガーしてみましょう。もしアラートが飛ばなければ、そこに欠陥が見つかったということです。

Source: https://dev.to/qasim157/rate-limit-your-own-agent-before-someone-else-does-33cb

Optional learning community: https://t.me/GyaanSetuAi