エージェントフレームワークのトークン肥大化:500:1の入出力比率が正常

マルチプロバイダールーティングを使用したセルフホストのTelegramベースのAIエージェントを実行しているRedditユーザーが、極端な入力対出力トークン比に気付きました:メッセージあたり約21kの入力トークンに対し50~200の出力トークンで、比率は100:1から500:1。内訳:ツール定義約13kトークン、システムプロンプト約5k、メモリ/コンテキストファイル約3k、ユーザーメッセージ100トークン未満。
これは正常ですか?
コミュニティの反応は、LangChainやAutoGPTのようなエージェントフレームワークでは15~25kのベースラインコンテキストが標準であることを確認しています。高い比率は実際のツールアクセスを持つ構造上のものです。主な推奨事項:
- 安価なプライマリモデル — 肥大化してもコストは一定範囲に抑えられる
- プロンプトキャッシング — アクティブセッションでは節約になるが、TTLが5分のためアイドル期間をまたぐと効果が限定的
- 支出上限 — 安価なモデルでも必須のガードレール
緩和戦略
ユーザーは2つのアプローチについて議論:意図に基づいてメッセージごとにツール定義をトリミングする(動的ツール選択)か、肥大化を受け入れてキャッシングに頼るか。ベンチマークによると、スケールで構築する場合を除き、フレームワークをフォークしてオーバーヘッドを削減する必要性はほとんどない。コンセンサス:21kのコンテキストはエージェントフレームワークの「ビジネスコスト」である。
📖 全文ソース: r/openclaw
👀 See Also

M4 Pro上のOpenClaw:ブラウザ利用、コンピュータ利用、Codexで壁にぶつかる
ユーザーが報告:エージェントがターミナルループに陥る、サイトでブロックされる、Codexの出力が壊れる。自動化ブラウザ、macOS GUI制御、割り込みループの設定調整を模索中。

Claude CodeとAIエージェントに対するHTMLの不合理な効果
あるバイラル投稿が示しているのは、Claude CodeなどのAIコーディングエージェントがHTMLを生成するように指示されると、より良い結果が得られるということです。実際の動作例と、このパターンについて解説したブログ記事も紹介されています。

Opus 4.7の人間ペーシング行動を無効にするCLAUDE.mdエントリ
3つのCLAUDE.mdディレクティブで、長時間のコーディング中におけるClaude 4.7 Opusの休憩提案、時間の過大評価、フェーズ分割を抑制します。

Claudeのプロジェクトサマリーをリポジトリにチェックインしよう — 人間のドキュメントより優れている
開発者が、Claudeが生成したプロジェクトサマリーをリポジトリにコミットすることを提案。品質は十分で、生成に数秒しかかからず、将来の読者の役に立つ。