Pizza Bot: 長期実行AIエージェントのためのローカルファーストなインボックス

Pizza Botは、長時間実行されるAIエージェントの作業のための、ローカルファーストなインボックスです。ユーザーはタスクを開始またはスケジュールし、後でそれらに戻ることができます。完了した作業はUnreadキューに、人間の介入が必要なタスクはActionキューに蓄積されます。Amazonで開発され、Apache 2.0ライセンスの下でリリースされたこのシステムは、ユーザーが切断したりインターフェースから離れたりしても、エージェントがバックグラウンドで作業を継続できるようにします。

コアアーキテクチャとワークフロー

Pizza Botは、DeepAgentsとLangGraphに基づいたステートフルなランタイムを利用しています。このシステムは非同期になるように設計されており、ユーザーは実行中のプロセスを停止させることなく会話を切り替えることができます。

タスク管理

Unread Queue: 完了したAIの作業がユーザーの確認のために保存される場所。
Action Queue: 耐久性のある承認リクエストや、human-in-the-loopの決定が必要なタスクが保存される場所。
Folders: ユーザーは、グローバルなUnreadおよびActionキューからスレッドを削除することなく、フォルダにスレッドを整理できます。
Persistence: チェックポイント化された実行はクライアントの切断後も維持され、タスクはアクティブな会話なしでcronやwebhooksを介してトリガーできます。

デプロイメントオプション

Pizza Botは、ユーザーのニーズに応じて、アプリケーションを実行するための複数の方法を提供します：

Electron Desktop App: バックエンドが組み込まれたローカルインボックス。
Browser: Web開発または静的デプロイメント用。
Terminal CLI: スクリプト、ターミナル、およびリモートバックエンド用。
Standalone Backend: リモートのElectronクライアント、コンテナ、またはLinuxサービス用。

技術仕様と拡張性

モデルプロバイダーのサポート

Pizza Botは、Amazon Bedrock、Anthropic、Google Gemini、OpenAI、OpenRouter、およびOllamaを含む、幅広いモデルプロバイダーをサポートしています。デスクトップアプリケーションは、ElectronのsafeStorageを使用してシークレットを保護し、サーバー設定は環境変数への参照のみを永続化します。

MCPとSkillsによる拡張性

このプラットフォームは、Model Context Protocol (MCP) サーバーと「Skills」を通じて拡張可能です。

MCP Servers: UIまたは設定ファイル経由で追加できます。
Skills: 特定のデータルートの下で定義され、宣言されたツールが有効になると利用可能になります。カスタムスキルは、同じIDを持つ組み込みまたはプラグインのスキルを上書きできます。
Plugins: MCPサーバーとスキルを組み合わせたパッケージ。

セキュリティとデータプライバシー

Pizza Botは、デフォルトでローカルファーストです。api-serverは127.0.0.1にバインドされ、スレッド、チェックポイント、メモリ、およびログを含むアプリケーションの状態は、<PIZZA_DATA_ROOT>（デフォルトは~/.pizza-bot-oss）の下にローカルに保存されます。ローカルフォルダへのアクセスはユーザーによって明示的に許可される必要があり、システムはデフォルトでホームディレクトリへのアクセス権を持ちません。

コミュニティの洞察とフィードバック

Hacker Newsコミュニティからのユーザーフィードバックは、アプリケーションの強みと課題の両方を浮き彫りにしています：

"設定や構成などに何時間も費やすのではなく、単一のアプリをインストールしてすぐに使い始められるという事実は、今後これを使う可能性を大幅に高めてくれます。"

ユーザーはインストールの容易さを称賛しましたが、一部のユーザーはllama.cppのようなローカルモデルを使用する際のセットアップ中の「jankiness（ぎこちなさ）」を指摘し、MCPサーバーとスキルの接続をより直感的にするためのユーザーインターフェースの改善を提案しました。あるユーザーは、特定の複雑なタスクのために、ローカル（安価/プライベート）と高機能なモデル（例：Claude）を組み合わせて使用できるように、タスクごとにモデルプロバイダーを上書きする機能を要求しました。

その他のコミュニティメンバーは、既存のメールやチケットトラッカー（例：Linear）のようなツールを使用するのではなく、なぜ別のインボックスが必要なのかという疑問を呈しましたが、エージェントのワークフローにおける専用のインボックスは、エージェント的なワークフローのための必要な進化であると示唆されました。