StacklokのCraig McLuckieは、コーディングエージェントを開発者の端末や対話的なプロセスに結び付けたままにすべきではないと考え、エージェントループをクライアント、実行環境、ツール、補助サービスから分離する分散アーキテクチャのモデルとして、オープンソースプロジェクトのMecatlを紹介している。
コーディングエージェントの価値は、もはや質問に答えるチャットインターフェースだけに限られない。実用的な導入は、能力のあるツール、共有リポジトリと共有ファイルシステム、サブエージェント、そして過去の作業からシステムが学んだことを保存するスキルを備えていることと結び付いている。StacklokのCraig McLuckieによれば、次の段階は、これらの能力を開発者のコンピューターから、長時間稼働するサービスや、そもそもターミナルを開かない人々が利用するインターフェースへ移すことだ。
問題は、現在のエージェント実行フレームワークの大半がデスクトップモデルを中心に設計されていることだ。つまり、1人のユーザー、1台の端末、ローカルファイルシステム、そしてユーザーインターフェース、エージェントループ、分離環境、認証情報ストア、ツールのホスティング、セッションデータベースを同時にまとめる1つの対話的プロセスである。このモデルは個人の開発者には適しているが、組織が数百のセッションを実行したり、ツールに対して細かなポリシーを適用したり、ノード障害後にセッションを再開したり、異なる端末間を移動したりする必要が生じると、適合性が低下する。
エージェントループをシステムの他の部分から分離する
McLuckieは、デスクトップフレームワークを単にコンテナ内に置くのではなく、最初から分散アプリケーションとして構築することを、「クラウドネイティブな実行ベルト」と呼ぶものとして提案している。コンテナはプロセスの実行場所を変えられるが、その構成要素間の相互依存を分解することはできない。Stacklokでは、この目的のためにオープンソースフレームワークのMecatlを公開した。
Mecatlでは、コアがエージェントループを担う。これには推論、ツール呼び出しの配分、権限、フック、イベントの発行が含まれる。他の要素は、明確なインターフェースを通じてコアに接続される。
- エンドクライアントとAPI。これにはmeacatuiというTUI、gRPCおよびHTTP/SSEインターフェース、TypeScript SDKが含まれる。
- エージェントがタスクを実行する実行環境、ワークスペース、コマンドランナー。
- 組み込みツール、ストリーミングHTTP経由のMCPサービス、スキル、アプリケーション固有の統合から成るツールエコシステム。
- モデルプロバイダー、セッション状態、イベントログ、アイデンティティ、オーケストレーションを管理する補助サービス。
実際には何が変わるのか？
この分離により、エージェントループは他のサービスと同じように、リリース、デプロイ、監視が可能なコンポーネントになる。同じループを置き換えることなく、ターミナルで実行したり、サービスとして実行したり、Kubernetes上で実行したりできる。mecak8sのガイドでは、実行中にワーカーを置き換えながら、新しいバージョンをリリースする際にも永続セッションを維持できる。
セッション状態とイベントログは、単一ライターを前提とする調整モデルに基づき、永続ストレージに保存される。ワーカーに障害が発生した場合、代替ワーカーは保存された最後のターン境界から処理を続行できる。ただし、これは分散トランザクションと同等ではない。障害が発生した瞬間に実行中だった処理は再開されず、最後に正常に保存された時点以降に行われた作業が失われる可能性がある。そのため、プロジェクトはこの能力を、完全な分散トランザクションを保証するものではなく、ターン単位の継続性だと説明している。
また、明示的なカタログによって、許可されるツール、スキル、統合を制限し、権限、監査、実行環境に境界を設けることもできる。クライアントがファイルシステム、認証情報、セッション状態を保持しないため、同じループでターミナル、リモートサービス、組み込みアプリケーション、Kubernetesデプロイメントに対応できる。さらに、Webインターフェース、Slack統合、共同編集エディターを同じセッションに接続することも可能になる。
まだ解決されていない課題
出典は、Mecatlがまだ初期段階にあり、「クラウドネイティブな実行ベルト」は完成した仕様というよりもアーキテクチャ上の方向性だと強調している。主な論点の一つは、外部システムを呼び出す主体をどのように特定するかである。それはユーザーなのか、エージェントなのか、セッションなのか、それとも多層のサブエージェントなのか。プロジェクトは、独自のSPIFFE信頼ドメインと、完全な委任チェーンをJWTにエンコードする仕組みを提案している。これにより、受信側システムはアイデンティティの連鎖に基づいて判断できる。
プロジェクトは、MCPを超えるツール向けの経路も検討している。これにより、PDFアナライザーのようなツールは、入力と出力のすべてをモデルのコンテキストウィンドウ経由で渡すのではなく、ファイルシステム上で直接動作できる。また、「コンテキスト証明」という考え方も現れている。これは、パッケージ化されたコンテキストを発行、署名、帰属付け、配布し、ソフトウェアサプライチェーン内の他の成果物と同様にポリシーの対象にするというものだ。
編集部の見解：この提案の重要性は、新しいインターフェースを立ち上げることではなく、エージェントを、長時間稼働する個人的なプロセスではなく、管理可能なサービスとして再定義する点にある。ただし、出典は、Mecatlで現在機能しているものと、なお設計段階にあるものを明確に区別している。また、現在の継続性は実行中の作業の喪失を防げず、アイデンティティモデルやツール間の直接的なデータ転送もまだ確定していない。そのため、このモデルをあらゆるローカルエージェントフレームワークに対するすぐに使える代替手段とみなす前に、導入環境、権限の境界、データ保証を実務的に評価する必要がある。