PUDA、制限付きCLIとイベントログでラボエージェントを接続し、生成的プランニングをハードウェアドライバ層から分離

Physical Unified Device Architecture（PUDA）は、AIエージェント向けの自動ラボ実行レイヤーを提案している。エージェントにグラフィカルユーザーインターフェースの操作や、機器制御コードのリアルタイム生成を求めるのではなく、各デバイスを探索可能なコマンドラインツールとしてラップする。プロトコルとレスポンスにはJSONを採用し、コマンドのディスパッチ、テレメトリ、ステータス更新はNATSメッセージングシステムを介して伝送する。JetStreamはイベントの永続化、キューイング、リプレイを担う。

このアーキテクチャは、科学的意思決定と物理的操作を意図的に分離している。エージェントは測定値、ログ、画像、レポートに基づいて次の実験を決定できるが、エッジサービスが公開するのは、エンジニアが事前にレビューしたドライバメソッドだけである。コマンドがハードウェアに到達する前に、システムはコマンド名、必須入力、データ型、許容範囲を検証する。これにより、モデルが実行時に低レベルの制御プログラムを任意に書き換えることを防ぎ、個々の操作の原子性と監査可能性を維持する。複数のデバイスはそれぞれコマンドチャネルをサブスクライブし、分析、監視、プランニングを担うエージェントは、実験全体を単一のワークフローグラフに固定することなく並行して動作できる。

PUDAはさらに、protocol、run、sample、measurement、command logを、安定した識別子とタイムスタンプで関連付け、自動ラボで頻発するデータ来歴の断絶の解消を試みている。測定に異常が発生した場合、研究者はデータプロダクトからハードウェアのレスポンスと元のコマンドを遡って確認できる。また、耐久性のあるイベントストリームにより、サービス中断後も状態を再構築できる。このような軌跡は将来、物理エージェントの訓練データになり得るが、そのためには人間による承認、失敗、環境状態も漏れなく記録されている必要がある。

現時点で論文が主に提示しているのはアーキテクチャと設計上の論証であり、機器横断ベンチマーク、フォールトインジェクションの結果、レイテンシデータ、公開実装へのリンクは提供されていない。したがって、この情報だけから、システムが実際の化学実験や材料実験を安全に操作できる段階にあると判断することはできない。エンジニアリングチームは今後、ドライバインターフェースの権限モデル、危険なコマンドに対する二重確認、JetStreamの再配信による操作重複への対処、異なるメーカーの機器間で一貫した状態およびサンプルのセマンティクスを共有できるかどうかに注目すべきである。