レート制限はどのレベルに設定すべきですか？各レベルの具体的な制限値をどのように決めますか？
レート制限は3つのレベルで同時に設計する必要があります：
LLM API呼び出しレベル（トークンコストの爆発防止）： 各AgentタスクサイクルのLLM呼び出しの最大数を制限（通常5〜15回；超過は無限ループの可能性を示す）；1時間あたりのLLM呼び出し数を制限；1回の呼び出しの最大トークン数を制限。
ツール呼び出しレベル（外部APIの過剰リクエスト防止）：
各ツール関数にレート制限を設定（例：get_aave_apyは1分間に最大10回）；書き込みツール（オンチェーン操作）はより厳格（例：withdraw_from_protocolは1時間に最大3回）。
オンチェーン操作レベル（最も重要、資金安全に直接影響）： 日次最大トランザクション数；日次最大Gas消費；日次最大操作金額；1回の最大操作金額。
レート制限値の設定方法： テストネットで48〜72時間実行し、通常操作下の各指標のピーク値を記録し、本番環境のレート制限をピーク値の1.5〜2倍に設定します。
サーキットブレーカーのトリガー条件をどのように設計しますか？サーキットブレーカーがトリガーされた後、Agentはどうすべきですか？
サーキットブレーカーのトリガー条件の設計は4種類の異常シナリオをカバーする必要があります：
タイプ1：コスト系サーキットブレーカー（予算保護） 日次Gas消費が日次予算の200%超；日次LLM APIコストが日次予算の300%超。
タイプ2：セキュリティ系サーキットブレーカー（攻撃シグナルの検出） 30分ウィンドウ内に同一非ホワイトリストアドレスへの3回以上のValidation BLOCKED；ThoughtログにPrompt Injectionシグナルが明確に出現；15分以内にLLMの推論ループ数が通常ピークの5倍超。
タイプ3：ツール失敗系サーキットブレーカー（サービス障害時の操作継続防止） 重要なツールが連続して5回以上失敗；外部APIレイテンシが5分以上正常均値の10倍超。
タイプ4：マーケット異常系サーキットブレーカー（極端な市場状況での実行防止） 対象プロトコルのTVLが1時間以内に20%超下落；Gas費が短時間で正常水準の500%以上に急騰。
サーキットブレーカートリガー後のAgentの動作： すべての新しいツール呼び出しを自動停止；完全なサーキットブレーカーログを記録；P0アラートをTelegramで送信；人間の確認を待つ（自動回復なし）。注意：サーキットブレーカーは「シャットダウン」ではなく「一時停止して確認を待つ」——Agent状態は完全に保持され、人間の確認後に一時停止ポイントから継続できます。
Pythonコードでレート制限はどのように実装しますか？既製のライブラリはありますか？
PythonでAgentのレート制限を実装する方法はいくつかあります：
方法1：ratelimitライブラリの使用（最もシンプル、関数レベルのレート制限に適している）
@sleep_and_retry + @limits(calls=10, period=60) デコレータにより、関数を60秒に最大10回に制限し、超過すると自動待機します。
方法2：Redis + スライディングウィンドウカウンター（分散型シナリオに適している） Agentが複数のインスタンスで稼働している場合（複数のSub-agentがレート制限を共有）、Redisを使ってグローバルなレートカウンターを維持します。
方法3：PostgreSQLカウンターテーブル（オンチェーンAgentの永続的なレート制限に最適）
PostgreSQLでagent_rate_countersテーブルを維持して各操作の今日の実行回数を記録します。Agent再起動後もレート制限が有効なため、特に「日次操作上限」タイプのレート制限に適しています。
サーキットブレーカーのPython実装：
pybreakerライブラリ（オープンソース、専用のCircuit Breaker実装）を使用するか、circuit_state変数（CLOSED/OPEN/HALF-OPEN）を手動で維持します。
レート制限とサーキットブレーカーをどのようにテストしますか？本番環境で本当に機能していることをどのように確認しますか？
レート制限とサーキットブレーカーのテストは境界条件を積極的にトリガーする必要があります：
レート制限のテスト（テストネットで）： テストスクリプトを書いて、1分間にレート制限された関数を20回連続で呼び出し、確認します：11回目（レート制限を超えた場合）は自動待機かエラーをスローするか？Agentの再起動後にレート制限カウンターが正しく回復されるか（PostgreSQLの永続化が機能しているか）？
サーキットブレーカーのテスト（テストネットで）：
サーキットブレーカー条件を手動でトリガーします——agent_rate_countersテーブルの日次Gas消費値を直接修正して閾値を超えさせ、サーキットブレーカーがトリガーされるか確認します；サーキットブレーカートリガー後のAgent動作をテスト：すべての新しいツール呼び出しが停止されるか確認；Telegramアラートが正しく送信されるか確認；Agent状態が正しく保存されるか確認。
本番環境での継続的な検証： モニタリングシステムに「レート制限ヘルスチェック」を追加——定期的にレートカウンターを照会し、カウンターが正常範囲内で増加していることを確認します。サーキットブレーカーについて：すべてのトリガーの履歴を記録し、各トリガー後に根本原因分析を実施します。
完全なレート制限 + サーキットブレーカーの設計例
以下はDeFi利回り最適化Agentのレート制限とサーキットブレーカーの設計です（Pythonの疑似コードスタイル）：
# レート制限設定
RATE_LIMITS = {'llm_calls_per_cycle': 10, 'apy_queries_per_min': 5, 'write_ops_per_hour': 3, 'daily_gas_budget_usd': 20, 'daily_tx_count': 8}
# サーキットブレーカートリガー条件
CIRCUIT_BREAKERS = {'gas_exceeded_200pct': True, 'blocked_3x_30min': True, 'tvl_drop_20pct_1hr': True, 'tool_fail_5x': True}
# 各ツール呼び出し前の確認フロー（コードレベルで強制、LLMに依存しない）
def pre_execute_check(operation_type: str) -> bool:
check_rate_limit(operation_type)
check_circuit_breaker()
check_daily_budget()
return True
この設計のポイント：pre_execute_check()はツール呼び出し関数の最外層で実行され、LLMのThought推論によって回避することはできません——LLMがハルシネーションを起こしたりPrompt Injectionに攻撃されたりしても、コードレベルのレート制限とサーキットブレーカーの確認は有効です。
より厳格なレート制限（上限が低い）→ Agentはより安全（異常時の影響範囲が小さい）ですが、Gasトラフや高収益機会ウィンドウで、Agentはレート上限に達して最適な実行タイミングを逃す可能性があります（戦略効率が低下）。より緩やかなレート制限（上限が高い）→ 戦略実行効率が高いが、異常時の潜在的な影響が大きい。推奨：本番環境の初期は厳格に（元本保護）；Agentの動作が安定していることを確認した後、実際のデータに基づいて適度に緩和します。毎月運用データに基づいて一度再校正します。