ランタイム内部構造

このページは、Agents セクションの他の部分を補完する、アーキテクチャの詳細を解説するものです。ランタイムがどのようにエージェントごとの権限を適用し、メモリのスコープを設定し、ログを関連付けるかについて説明します。エージェントの設定と実行については Agents を参照してください。スキーマレベルのフィールドリファレンスについては Config を、実際のセットアップ手順については Multi-agent setup を参照してください。

権限モデル

各エージェントの実効的な SecurityPolicy は SecurityPolicy::for_agent(config, alias) によって構築されます:

1. エージェントのリスクプロファイル（[risk_profiles.<profile>]）から始めます。
2. 境界をエージェントごとのワークスペースディレクトリ（<install>/agents/<alias>/workspace/）に設定します。
3. [agents.<alias>.workspace.access] を確認:
   • Read → 兄弟のワークスペースが読み取り専用の許可リストに追加されます。
   • Write / ReadWrite → 兄弟プロセスのワークスペースが読み書き許可リストに登録されます。
4. [agents.<alias>.workspace.unrestricted_filesystem] が true の場合は、workspace_only をオフにします。

読み取り専用の許可リストは file_read（およびその他の読み取り系ツール）で適用されます。読み書きの許可リストは file_write、file_edit、git_operations、およびシェルツールのパスに触れる呼び出しを制御します。POSIX デバイスファイル（/dev/null、/dev/zero、/dev/random、/dev/urandom）は常に読み取り可能であり、エージェントごとの設定なしでシェルのイディオムが動作し続けます。

SubAgent の生成では、子が親を超えて権限を昇格できないというルールが適用されます。バリデーターの全軸リストと予算共有の動作については、委譲 → 権限の継承に記載されています。

メモリモデル

各エージェントは独自の Arc<dyn Memory> インスタンスを持ちます。ファクトリ（zeroclaw_memory::create_memory_for_agent）はバックエンドの種類に応じてディスパッチします:

• SQLite / Postgres / Lucid: インストール全体で共有されるストア。agents テーブルがエイリアス → UUID をマッピングし、memories テーブルはその UUID を参照する agent_id を保持します。ファクトリは内部バックエンドを AgentScopedMemory でラップし、これは store_with_agent を介してすべてのストアにバインドされたエージェントの UUID を刻印し、解決された許可リストを使用して recall_for_agents を介してすべての recall をフィルタリングします。
• Markdown: エージェントごとのディレクトリ。各エージェントの MarkdownMemory は <install>/agents/<alias>/workspace/MEMORY.md と memory/YYYY-MM-DD.md に書き込みます。エージェント間のリコールは AgentScopedMarkdownMemory によって構成されます。これはバインドされたエージェントの MarkdownMemory に加えて (alias, MarkdownMemory) ペアのピアセットを保持し、各行に [<alias>] という帰属プレフィックスを付けて結果を統合します。
• Qdrant: 共有コレクション、ペイロードをキーとして使用。agent_id ペイロードフィールドはエージェントごとの帰属情報です。recall_for_agents は多めにフェッチし、ペイロードで事後フィルタリングします。
• None: no-op スタブ。ランタイムパスを統一するため、ラッパー自体は引き続き存在します。

クロスバックエンドのクロスエージェントメモリはサポートされていません。設定読み込み時のスキーマバリデーターは、異なるバックエンド上の兄弟を指す read_memory_from エントリを拒否します。

名前の変更と削除のライフサイクル

名前変更と削除には、gateway ダッシュボードのエージェント操作、または専用の zeroclaw agents CLI を使用してください。gateway と agent-runtime を有効にした標準ビルドでは、どちらのインターフェイスでも参照と所有状態のカスケードが実行されますが、TOML 内で agents.<alias> を直接削除またはキー変更したり、汎用の設定セッターを介して操作したりしても、カスケードは実行されません。機能を削減した CLI でも設定参照は更新されますが、所有状態のカスケードは行われなかったことを警告するため、ライフサイクル操作には両方の機能を有効にしたビルドを使用してください。

どちらの操作も、所有状態のサイドエフェクトを実行する前に設定変更を永続化します。Rename は最初に設定参照を書き換え、次にエイリアスごとのデフォルトワークスペースを移動して、メモリ、cron、ACP、およびセッション状態を再指定します。Delete は最初にハード参照とライブ ACP セッションを拒否し、次に設定エントリとソフト参照を削除してから、ワークスペースのアーカイブ、所有状態のエクスポートとクリーンアップ、およびセッション帰属のクリアを試みます。

永続化後の副作用はベストエフォートで実行され、表面化した失敗は報告されますが、アーカイブファイルへの書き込み失敗はゲートウェイのログにしか現れない場合があります。名前変更の警告が出た場合は、古いエイリアスの下に残された残留物を収束させるため、同じゲートウェイ API の名前変更を再試行してください。削除後は、アーカイブを復旧に利用する前に、アーカイブの内容とログを確認してください。自動復元はサポートされていません。

現在の操作、ブロッカー、アーカイブのレイアウト、オペレーターによる確認については、マルチエージェント設定の手順を参照してください。

現在サポートされていません

1. バックエンド間・エージェント間のメモリアクセス（例: SQLite エージェントが Postgres エージェントの行を読み取る）。
2. エージェント削除アーカイブからの自動復元。
3. エージェントごとのシークレット名前空間: ワークスペース全体で単一の SecretStore が存在します。
4. クロスエージェントスコープ用のLucidワイヤーフォーマット拡張。