AI ツールを逆さまに設計していることに気づきました。 次に例を示します。これは私のニュースレター処理チェーンでした:電子メールを読み、ニュースレター処理業者に電話し、企業を抽出し、それらをCRMに追加しました。これには 4 つの異なるステップが含まれ、処理されたニュースレター 1,000 件ごとに 3.69 ドルの費用がかかりました。 変更前: ニュースレター処理チェーン (画像 1 枚目) 次に、本番グレードの AI エージェント ツールを構築するための Google のフレームワークである Google Agent Development Kit を使用してすべてを組み合わせた統合ニュースレター ツールを作成しました。 統合ニュースレターツールがより複雑なのはなぜですか? 単一のインターフェイスに複数のアクション (プロセス、検索、抽出、検証) が含まれ、使用パターンを追跡して結果をキャッシュする状態管理を実装し、レート制限が組み込まれており、プレーン テキストではなくメタデータを含む構造化された JSON 出力を生成します。 しかし、ここに直感に反する部分があります:内部的にはより複雑であるにもかかわらず、統合ツールは、出力が長くても解析しやすい一貫した構造化された出力を提供するため、LLMにとって使いやすくなります。 影響を理解するために、テスト シナリオごとに 30 回のイテレーションのテストを実行しました。結果は、新しいアーキテクチャの影響を示しています:(3番目の画像) トークンを41%削減することができ(p=0.01、統計的に有意)、直線的にコスト削減につながりました。成功率は8%(p=0.03)向上し、30%の確率でキャッシュにヒットすることができ、これもコスト削減につながりました。 個々のツールはより短く「クリーンな」応答を生成しましたが、LLM は一貫性のない形式の解析にさらに努力することを余儀なくされました。統合ツールからの構造化された包括的な出力により、LLM 処理は長くなりますが、より効率的な LLM 処理が可能になりました。 私のワークフローは、電子メール、調査、タスク管理のための数十の特殊なRubyツールに依存していました。各ツールには、独自のインターフェイス、エラー処理、および出力形式がありました。それらをメタツールにまとめることで、究極のパフォーマンスが向上し、大幅なコスト削減が得られます。完全なアーキテクチャは GitHub にあります。