製品アーキテクチャ
Myrm は 2 つの製品レイヤーと、任意のクラウド制御プレーンで構成されています。この区分を理解すると、導入・トラブルシュート・他エージェントからの移行が容易になります。レイヤー
平易な言い換え: フロントエンドはあなたがクリックする画面、サーバーはワークスペースへの扉、ハーネスはサンドボックスの中の「脳と手足」です。
ハーネスの公開 API（統合契約）
オープンソースの Server はmyrm_agent_harness.api を通じてハーネスと連携し、内部モジュールへの深い import は禁止されています。
myrm-agent-server のアーキテクチャ CI は from myrm_agent_harness.*._* 形式の import を禁止しており、内部を進化させつつ公開 api.__all__ を安定に保ちます。配布 wheel は可読な .py シェル + コンパイル済み core 拡張です。
SaaS にとっての意味: 制御プレーンはユーザー sandbox ごとに runtime Docker イメージ tag をロールアウトします（イメージ内に server + harness を同梱）。Server の接着層は api.hooks / api.skills のみを import するため、イメージのロールアウト時も接着層は安定します — 多くのオープンソースエージェントのモノリシック構成では実現できません。
リクエストフロー（典型的な会話）
- ユーザーがフロントエンド（またはサーバー経由で接続した IM チャネル）からメッセージを送信します。
- サーバーが認証し、Agent 設定を読み込み、UI にイベントをストリーミングします。
- ハーネスが Agent ループを実行します: ツール、記憶リコール、サブエージェント、コンテキスト圧縮。
- 結果はサーバー → UI へ戻り、任意でチャネル通知に送られます。
何をどこに設定するか
デプロイモード（同じ機能、別のパッケージング）
デバイスとハードウェア層：いま使えるもの・まだ無いもの
「ポータブル AI コンパニオン」系の競合ルートは、Agent を自分のボード・ウォッチ・古いスマホに組み込むことを指しています。現状を 3 段で、はっきり書いています。
競合との正直な差: Hermes Gadget はすでにオープン SDK、デスクトップシミュレータ（同じファームウェアコアをデスクトップウィンドウで動かすため、ハードウェアなしでも開発・検証できる）、機種ごとの実機検証マトリクスを公開しています。この方向は私たちも賛同し、同じ基準（ビルド成功 ≠ 実機で動く、未検証項目は明示）で計画していますが、今日時点では出荷されていないため、ここでは宣伝しません。
プラットフォーム対応と検証状態：すべての能力に状態を
3 つのプラットフォームで実装の深さは異なります。「全プラットフォーム対応」とは書かず、能力ごとに検証状態を付けます。
基準: ✅ 実スタック / 実バイナリの検証記録あり · ⚠️ コードは存在するが実機検証の記録なし · ❌ そのプラットフォームで明示的に無効、または未実装。単体テストと CI の通過は実機で動くことと同義ではなく、未記載は未検証です。
未検証項目の完全なリストはロードマップ
topic_19 #1 にあり、この原則自体は topic_19 #68（能力検証マトリクスとサポートラベル）に対応します。
他エージェントからの移行
- 設定: Hermes / OpenClaw 形式のエクスポートの取り込み経路（クイックスタートを参照）。
- 記憶: Myrm は構造化 DB の記憶 + GUI を使います — 単一の
MEMORY.mdファイルではありません。 - スキル: プリセット + コミュニティ発見。進化には承認が必要です。
- チャネル: 26 個の組み込みプロバイダー — 設定で OAuth / Token を再バインドします。
次のステップ
クイックスタート
数分でローカル実行。
メモリシステム
セッションをまたぐ記憶の仕組み（英語版）。
サンドボックスランタイム
ツールが実際に実行される場所。
デスクトップアプリ
Tauri のパッケージングと更新。