LobeHub

チャット単位ではなくAgentを仕事の単位にし、役割・協働・実行タイミングまで管理する

LobeHubは『Agents as the unit of work』を掲げ、Agent Builderで必要な役割を作成し、Agent Groupsで複数エージェントを同じタスクへ参加させます。Pagesでは複数agentと同じ文脈で文章を編集でき、Scheduleではユーザーがオンラインでなくても決めた時間にagentを実行できます。ProjectとWorkspaceは仕事をまとめる単位となり、個別チャットを渡り歩くよりも、誰が何を担当し、どの文脈で進めているかを長期的に管理する方向へ設計されています。

出典：[1]

複数モデルと1万以上のSkills、MCP-compatible pluginsを組み合わせてAgentごとの能力を作る

Agent Builderは特定モデルに固定されず、複数のLLM providerやmodalityを選択できる前提で設計されています。READMEでは10,000以上のSkillsとMCP-compatible pluginsを利用できるとされ、agentごとに検索、外部サービス操作、専門作業などの能力を足せます。IM Gatewayも用意されており、専用Web UIだけではなく日常的に使うメッセージング環境側からagentへアクセスする運用も想定されています。

出典：[1]

Personal Memoryを編集可能なWhite-Boxとして持ち、エージェントの継続学習をユーザー側で制御する

LobeHubのPersonal Memoryは、会話履歴を単に保持するのではなく、エージェントがユーザーの仕事の進め方やニーズを継続的に学ぶための層として位置付けられています。READMEではWhite-Box Memoryとして構造化・編集可能であることを明示しており、何を覚えているかをユーザーが確認・修正できる思想です。自動化を増やしながらも、ブラックボックスの個人プロファイルへ全面的に任せない設計が特徴です。

出典：[1]

複数のAIツールを切り替える状態から、役割を持つ常駐エージェントへ仕事を渡したい人・チームへ

調査用、文章作成用、開発用など複数のAIを別々のチャットで使い分けており、毎回コンテキストを渡し直す負担が大きい人に向きます。特に、定期レポートや継続調査のようなScheduled work、複数agentで並列化したい作業、チーム内でagentの役割や成果を共有したい用途と相性があります。一方、単一モデルとの軽量なチャットだけが目的なら、LobeHubのWorkspace、Memory、agent orchestrationは過剰になる可能性があります。

出典：[1]

セルフホストはPostgreSQLやストレージを含む基盤運用が必要で、ライセンスも純粋なApache-2.0ではない

公式Self Hostingドキュメントでは、LobeHubの主要構成としてNext.js、PostgreSQL、S3-compatible storageを挙げ、Redisはsessionやcache用途で推奨されています。Docker ComposeではPostgreSQL、Redis、RustFS、Searxngまでまとめて起動できますが、バックアップ、監視、TLS、認証、API key管理は運用者の責任です。Vercelは導入が簡単な一方、外部PostgreSQLが必要で、serverless functionの10秒制限やWebSocket非対応といった制約があります。

ライセンスはLobeHub Community Licenseで、Apache License 2.0を土台に追加条件を設けています。ソースを変更せずfrontend/backend serviceとして商用利用することは許可されていますが、LobeHubを基に商用の派生物を開発・配布する場合はproducerからcommercial licenseを取得する必要があると明記されています。そのため、単純なApache-2.0 OSSとして再利用できると解釈せず、派生開発や再配布ではLICENSEの追加条件を確認する必要があります。

出典：[2][3]