私が高コストなAPIループをLobster駆動のパイプラインとHonchoメモリ管理に置き換えた方法、そしてなぜデバッガーだけが有料エンドポイントに触れるのか。

私たちは皆このジレンマを知っています。真のマルチエージェントインテリジェンス—永続的なメモリ、サブエージェントの引き継ぎ、長期的な計画—を望みますが、有料APIのトークンコスト（特にループでのメモリ取得）はプロジェクトが立ち上がる前にそれを殺してしまう可能性があります。

私はこの問題を解決するために、OpenClawの設定をゼロから再構築することに決めました。目標：メモリ操作の推論コストがゼロで、タスク委譲のオーバーヘッドがほぼゼロのハイブリッドマルチエージェント/サブエージェントアーキテクチャ。

ここで私がどのようにそれを実現したかを正確に示します。

アーキテクチャ：ハイブリッドマルチエージェント + サブエージェントスウォーム

ほとんどの実装では、すべてのエージェントをファーストクラスのAPI呼び出し元として扱います。その結果、トークンが消費されます。

私のOpenClawセットアップはハイブリッドモデルを使用します：

• プライマリーエージェント（オーケストレーター）はローカル推論またはフリーティアーエンドポイントで実行されます。
• サブエージェントは一時的であり、特定のタスク（検索、要約、検証）のためにスピンアップされ、すぐに破棄される。
• 秘訣は？ サブエージェントは「記憶」しない。中央のメモリストアをクエリし、実行して消える。これによりコンテキストウィンドウは極小に保たれる。セッション状態を保持するのはプライマリエージェントだけである。

ゴールデンルール：デバッガーのみが有料APIと通信する

ここに、すべてを変えた制約がある。

私のワークフローでは、有料APIエンドポイントにアクセスできるコンポーネントはデバッガーのみである。

その他のエージェント―プライマリ、サブエージェント、オーケストレーター、メモリーワーカー―はローカル推論（Ollama、LM Studio、または無料ティアクラウド）で動作する。デバッガーのみがGPT-4、Claude、またはその他の有料モデルを呼び出せる。

なぜか？ 3つの理由：

1. 強制されたアーキテクチャの規律

何かが壊れたとき、デバッガーがそれを追跡します。しかし、デバッガーが唯一の有料パスであるため、パイプライン全体にAPI呼び出しを散らばらせて「ごまかす」ことはできません。ローカルの推論とメモリ取得を最適化するよう強制されます。

2. デバッグはランタイム依存ではなく、有料ティアのサービスとして

システムは時間の99%を有料APIに触れずに動作します。エージェントが失敗したとき—予期しない出力、スキーマの不一致、無限ループ—のみデバッガーが起動します。デバッガーは失敗コンテキストを受け取り、修正案を提示し、それをローカルエージェントに返します。これにより、有料APIはランタイムの頼りではなく、例外ハンドラーとして機能します。

3. コストは使用量ではなく、問題の数に応じてスケールします

健全なパイプラインはコストが0ドルです。バグがあるパイプラインの診断には数セントかかります。これに対し、従来のマルチエージェントシステムでは、正しさに関わらず、各エージェントの各ターンごとにお金がかかります。

Honcho メモリ管理: 永続的、検索可能、ゼロコスト

メモリについては、ローカルファーストでプログラマブルなメモリレイヤーであるHonchoを統合しました。Honchoは以下を提供します：

• 永続的なユーザー/セッションストレージ。
• クラウドベクトルデータベースを使わないベクトル検索
• メモリの読み書きにAPIコールがゼロ

エージェントのすべてのインタラクションはHonchoに書き込まれます。すべてのサブエージェントはHonchoから読み取ることでコンテキストをブートストラップします。有料のエンベディングはありません。外部のメモリ・アズ・ア・サービスもありません。

デバッガーがメモリ操作に触れないため、Honchoは完全に無料で動作します。

時間的減衰 + MMR: 古いメモリとの闘い

メモリが最近のコンテキストを圧倒すると役に立たなくなります。Honcho内に2つの検索メカニズムを実装しました：

1. 時間的減衰

古いメモリは指数関数的に重みが下げられます。10分前の事実が、10日前の類似事実よりも関連性が高くなります。これにより、エージェントが古い情報に基づいて行動することを防ぎます。

2. MMR (最大マージナル関連性)

エージェントがメモリをクエリするとき、MMRは多様性を確保します。ほぼ同一のメモリを10件返すことを避けます。代わりに、関連性と多様性を得られます—これは広いコンテキストが必要なサブエージェントにとって重要です。

両方ともローカルで実行されます。コスト: $0。デバッガーはそれらを決して見ません。

Lobster: オーバーヘッドなしのタスク委譲 & パイプライン

ここでトークン使用量が崩壊します。

私は線形のエージェントチェーンを Lobster に置き換えました—軽量なタスクパイプラインランタイムです。Lobster を使うと、タスクの有向非巡回グラフ (DAG) を定義できます。

私のワークフロー:

1. プライマリエージェントがリクエストをサブタスクに分解します。
2. 各サブタスクはパイプラインノードとして Lobster にプッシュされます。
3. Lobster はローカルサブエージェントを使用して、サブタスクを並列または順次に実行します。
4. ノードが失敗したり、予期しない出力を生成したりした場合、Lobster はそれをフラグ付けします。
5. そのときだけデバッガーが起動し、失敗したノードのコンテキストを受け取り、修正を生成し、パイプラインを再開します。

Lobster パイプラインはコンテキストを再利用し、冗長な LLM 呼び出しを避けるため、同等のワークロードにおいてトークン消費を概ね 70-80% 削減しました。さらに、デバッガーは例外のみを処理するため、この 70-80% の削減は有料利用に特化して適用されます。

トークン使用量への実際のインパクト（有料 API）

数字について話しましょう。

このセットアップ以前、典型的なマルチエージェント会話は次の通りでした：3 つのエージェントがそれぞれ GPT-4 を呼び出し、プロンプトごとにメモリ取得が追加されました。その結果、ユーザーとのやり取りごとに 8,000–12,000 トークンが発生しました。

OpenClaw + Honcho + Lobster + デバッガー専用の有料アクセス後: プライマリエージェントはローカルで実行されます。サブエージェントはローカルで実行されます。メモリはローカルで実行されます。Lobster は API コールを一切行わずにすべてをオーケストレーションします。有料 API の使用は失敗時にのみ発生します—これはパイプラインが安定した後、インタラクションの <5% で起こります。

結果: 有料 API における 1 インタラクションあたりのトークン数は 50〜500 で、ほとんどのインタラクションはコストが $0 です。

これは、従来のマルチエージェントシステムと比較して、有料トークン使用量が 20〜100 倍削減されることを意味します。

高ボリュームアプリケーション—カスタマーサポート、リサーチエージェント、オートメーション—において、これは実用的な製品と金食い虫の違いです。1 日あたり 10,000 インタラクションの場合、従来の構成では $200〜$500 のコストがかかる可能性があります。この構成では、コストはほとんどかからず、せいぜい数セント程度です。

デバッガー専用制約がより良いエンジニアリングを強いる理由

ここに反直感的な洞察があります: デバッガーに有料 API を制限することで、システムの信頼性が向上し、コスト削減だけでなくなります。

すべてのエージェントが GPT-4 を呼び出せる場合、ずさんなプロンプト、不適切なメモリ取得、脆弱なパイプラインを許容してしまいます。有料 API がそれらのひびを埋めます。

デバッガーだけがその特権を持つ場合、あなたは次のことを強いられます:

• エッジケースに対応できる堅牢なローカルプロンプトを書く。
• 適切なメモリ減衰とMMRを構築し、手間をかけずに検索が機能するようにする。
• 明確な成功/失敗基準を持つLobsterパイプラインを設計する。
• 有料モデルを作業者ではなく調査員として扱う。

その結果、エラーに優しく対応し、自己デバッグを行い、運用コストがほとんどかからないシステムとなる。

なぜこれが重要なのか

インテリジェントエージェントを構築するために、高価なクラウドメモリや止まらないAPIループは必要ありません。

OpenClaw、Honcho、Lobster、およびデバッガー専用の有料API制約を使えば、次のものを構築できます：

• 時間的減衰とMMRを伴う永続メモリ
• ハイブリッドエージェント/サブエージェントスウォーム
• 自動障害回復を伴うタスクパイプライン
• 有料APIが例外ハンドラーであり、ランタイム依存ではないシステム

…すべてながら、あなたの有料APIの請求額をほぼゼロに近い範囲内に保つ。

設定ファイル、Honchoスキーマ、Lobster DAGの定義、あるいはデバッガーをパイプラインの失敗時にのみ起動するように設定した方法について聞いてください。

もっと安価に構築しよう。もっと賢く構築しよう。有料APIを最初の選択肢ではなく、最後の手段にしよう。