ローカルツール向けのCLIおよびMCPのより良い代替案：オープンソース・プロジェクトに関するフィードバック募集

Unix の名前付きパイプ（named pipe）機構を通じて、ローカルで動作するエージェント用ツールとやり取りするためのライブラリ／プロトコルを、いまずっとノリで（vibe-coding）作っていて、ようやく最初のバージョンをリリースしました！

ぜひフィードバックが欲しいです。ここでのアイデアは良い方向に進んでいますか、それとも完全に不要なものですか？

https://github.com/stefanwebb/named-pipes

README から：

名前付きパイプは、ネットワークスタックではなくカーネルメモリ経由でデータをルーティングするため、ローカル HTTP より低遅延で、共有メモリよりもはるかに複雑さが低くなります。そのため、音声エージェントのようなリアルタイムアプリケーションにとって実用的な「ちょうどいい」選択肢になります。

CLI ツールは、呼び出すたびに新しいプロセスが立ち上がります。毎回スタートアップコストを払い、必要な状態をディスクから再読み込みし、呼び出しが完了すると終了します。軽量なコマンドならそれで問題ありませんが、LLM 推論、ベクター検索、ブラウザ自動化のように、重い処理がモデルの重みの読み込み、インデックスの構築、ブラウザの起動にある場合—この「呼び出しごとの」オーバーヘッドは耐えがたいものになります。名前付きパイプのサーバーは一度だけ起動し、すべてをメモリに保持して、呼び出し間も常駐し続けます。オーケストレータがメッセージを送って応答を受け取るだけで、プロセスは生成されず、状態も再読み込みされません。

MCP は別の前提に基づいて作られています。モデルは別の場所（クラウド、API の背後など）に存在し、ツールはローカルまたはリモートのサーバーとして動作し、フレームワークがそれを検出・管理します。このアーキテクチャには、JSON-RPC のフレーミング、プロセス生成とディスカバリのためのプロトコル、そしてモデルとツールの間に割り込むフレームワークの仲介役が導入されます。1 台のマシン上で完全にローカルに動くセルフホスト型のエージェントなら、これらはすべてメリットのないオーバーヘッドです。名前付きパイプはプロトコル層を丸ごとスキップします。オーケストレータはファイルパスを開いてメッセージを書き込み、返信を読み取るだけです。実行ループはオーケストレータ側の手にとどまり、途中にフレームワークは入らず、ネットワークスタックも関与しません。