私は、ローンチ記事よりもローカルのLLM基盤リポジトリを読むのが好きで、この週末にその一つをかなり深く掘り下げました。Ollamaのようなローカルプロバイダをサポートしているからです。
「よし、誰かが実行時のエンジニアリングにちゃんと気を配っているな」という反応をくれたのは、2つのことです。
1つ目は、ランタイムのパスが完全にTypeScriptへ移されたことです。APIレイヤ、ランナーのオーケストレーション、ワークスペースのMCPホスティング、パッケージングはすべてそこに集約され、パッケージされたランタイムはもうPythonのソースやPython依存を同梱しません。ローカル／セルフホストの構成では、これは聞こえる以上に重要です。バンドルが小さくなり、可動部が減り、クロス言語のズレも減ります。
2つ目は、ハードコードされたMCPポート計算をやめたことです。ポートはSQLiteに永続化され、キーとしてUNIQUE(port)と(workspace_id, app_id)が使われています。そしてランナーはブートストラップ時に、用意されたMCPサーバをマージします。これにより、ローカル側のサイドカーは、通常の13100 + なんとなくの推測ではなく、再起動をまたいで安定して衝突しにくいポートで戻ってきます。
私にとって大きな学びは、ローカルのモデルが十分に良くなると、苦労の多くがモデル品質からハーネス品質へ移るということです。パッケージング、サイドカーのライフサイクル、ローカルでのサービス探索、ランタイムの状態は退屈な話題ですが、ローカルエージェントの構成が本当に「しっかりしている」と感じられるかどうかを決めます。
ここでOllama / llama.cpp / LM Studio + MCPを作っている人たちに聞きたいのですが、いまも静的なポート／設定の管理をしていますか？それとも、どこかにオーケストレーションの状態を永続化していますか？
同じコードを読んでみたい人向けのリポジトリ：
[link] [comments]
