アーキテクチャ概要

Project N.E.K.O. は、3つの主要サーバーがWebSocket、HTTP、ZeroMQメッセージングを通じて連携するマルチプロセスマイクロサービスシステムとして構築されています。

システム図

アーキテクチャ

3サーバー構成

サーバー	ポート	エントリーポイント	役割
メインサーバー	48911	`app/main_server/__init__.py`	Web UI、REST API、WebSocketチャット、TTS
メモリサーバー	48912	`app/memory_server.py`	セマンティック検索、時間インデックス付き履歴、メモリ圧縮
エージェントサーバー	48915	`app/agent_server.py`	バックグラウンドタスク実行（Computer Use、Browser Use、OpenClaw リモートエージェント、OpenFang スタンドアロンエージェント、ユーザープラグイン）

メインサーバーはユーザー向けのエントリーポイントです。Web UIの提供、すべてのREST APIリクエストの処理、リアルタイム音声/テキストチャットのためのWebSocket接続の維持を行います。メモリサーバーとエージェントサーバーは、メインサーバーが通信する内部サービスです。

通信パターン

┌────────────────────────────────────────────────┐
│              Main Server (:48911)                │
│                                                  │
│  FastAPI ─── REST Routers                        │
│  WebSocket ─── LLMSessionManager                 │
│  HTTP Client (httpx) ───────────┐                │
│  ZeroMQ PUB  (:48961) ──┐       │                │
│  ZeroMQ PUSH (:48963) ──┼── MainServerAgentBridge│
│  ZeroMQ PULL (:48962) ──┘       │                │
└─────────┬───────────────────────┼────────────────┘
          │                       │
    ┌─────┴─────┐         ┌───────┴────────┐
    │           │         │                │
    ▼           ▼         ▼                ▼
  Memory     Monitor    Agent Server   User-Plugin
  Server     Server     (Tool Server)  Server
  (:48912)   (:48913)   (:48915)       (:48916)
   HTTP      一方向       HTTP REST +    HTTP REST
            ステータス    ZeroMQ イベント
            プッシュ

Main ↔ Memory: メモリの保存/クエリ用 HTTP リクエスト（メモリサーバー :48912）
Main ↔ Agent: 2 つのチャネルが連携して動作します ——
- 制御 / ディスパッチ: httpx による HTTP REST で Tool Server（:48915）と、ユーザープラグインサーバー（:48916）を呼び出します
- イベントストリーミング: ZeroMQ で、メインプロセスがソケットをバインドします —— PUB :48961（セッション → エージェント）、PUSH :48963（分析キュー → エージェント）、PULL :48962（エージェント → メインの結果）；agent_server は対応するミラーソケットに接続します
Main ↔ Monitor: モニターサーバー（:48913）への一方向ステータスプッシュ

主要なアーキテクチャパターン

ホットスワップセッション

LLMSessionManager は、現在のセッションがまだアクティブな間に、バックグラウンドで新しいLLMセッションを準備します。ユーザーが会話ターンを終了すると、ダウンタイムゼロで事前にウォームアップされたセッションにシームレスに切り替わります。移行中の音声はキャッシュされ、その後フラッシュされます。

キャラクターごとの分離

各キャラクター（lanlan_name で識別）は、それぞれ独自の以下を持ちます：

LLMSessionManager インスタンス
同期コネクタースレッド
WebSocketロック
メッセージキュー
シャットダウンイベント

非同期/同期の境界

FastAPIハンドラーは非同期です。TTS合成はキューベースの通信を使用する専用スレッドで実行されます。音声処理はエグゼキュータースレッドプールを使用します。ZeroMQイベントブリッジはバックグラウンド受信スレッドを実行します。

3サーバー設計 — 各サーバーの詳細な内訳
データフロー — フロントエンドからLLMへのリクエストライフサイクルとその戻り
セッション管理 — ホットスワップメカニズムの詳細

アーキテクチャ概要 ​

システム図 ​

3サーバー構成 ​

通信パターン ​

主要なアーキテクチャパターン ​

ホットスワップセッション ​

キャラクターごとの分離 ​

非同期/同期の境界 ​

次へ ​