HN 日本語サマリー

← 一覧へ戻る
プログラミング

自壊しないエージェントの構築

Building Agents That Don't Break Themselves (fly.io)

8 pointsby ryantsuji0 コメント

要約

AIエージェントが誤ったコマンド実行で自身やシステムを破壊するリスクを回避するため、Fly.ioでは「Sprite」と呼ばれる使い捨て可能なサンドボックス環境を活用しています。これにより、エージェントは安全な隔離空間でコードを実行でき、セッションごとに新しいSpriteを起動してリソースをクリーンに保つことで、セキュリティと信頼性を向上させます。このアプローチは、エージェントの自己改善機能を安全に活用し、誤操作からの復旧を容易にします。

全文翻訳

エージェントを構築するのは楽しいものです。自壊するエージェントを再構築するのは…あまり楽しくありません。 Flyの多くのメンバーは、エージェントに危険なことはすべてSprite内で実行させるように教えることで、自己破壊の傾向が少ないエージェントを構築しています。 これにより、エージェントはスナジーな自己改善機能を実際に使用できるまで生き残り、そうでなければ戦艦規模のフットガンになりかねないことを試すことができます。 やり方は以下の通りです。 脳対手 エージェントはシェルがなければ pretty useless になるでしょう。なぜなら、シェルはエージェントがエージェントの仕事をする場所だからです。 テストスイートを実行する、マイグレーションを適用する、依存関係をインストールする、一時ファイルを削除する。 残念ながら、エージェントのシェルアクセスは、単に「一時ファイルを削除する」と「間違ったファイルを削除する」が指一本のミスで分かれるため、あなたの午後を台無しにする原因にもなり得ます。 そして、AIは間違いを犯す可能性があると頻繁に警告されています。 だからこそ、私たちはサンドボックスを持っています。 しかし、多くの人は、潜在的に危険な作業を行うエージェントをサンドボックスに入れることをデフォルトにしています。 これは、エージェントがどこに住んでいるかと、コードを実行する場所が完全に別々の考慮事項であるため、実際には行う必要のないトレードオフの長いリストを伴います。 エージェントワーカーのためのPPE エージェントプロセスはループです。 モデルを呼び出し、応答を読み取り、ツールを選択し、繰り返し。 これは、メモリ、スキル、履歴が永続する場合にのみ、より有能で愚かでない、長期間実行されるプロセスです。 そのため、アイドル時にスリープし、メッセージで起動するFly Machine、小さなVPS。 あなたがイテレーションしている間のあなたのラップトップ。 これらはすべて、APIを呼び出すループの適切なホームであり、ブラストシールドを必要としません。 物事が厄介になるのは、エージェントに実行させたいときです。 bash -c + モデルがちょうど生成した文字列は、パディングされた部屋で実行される必要があります。 エージェントのコードが自分自身や接続されているものを破壊できない場所。 そして、あなたのエージェントがあなたよりも多くの仕事をしているなら、あなたは気まぐれで捨てて再構築できるパディングされた部屋の施設全体を望むでしょう。 セッションごとに1つのSprite ここで、この概念をうまく実証しているFlyメンバーによる2つの最近のプロジェクトを見てみましょう。 まず、 Henrique による内部Flyトラブルシューティングエージェント、SpriteDoc です。 SpriteDoc はマルチユーザーであり、Piエージェントの上に構築されています。 各セッションは、1つの共有サーバーで、1つのNode.jsランタイムで実行されます。 そのサーバーでbashコマンドを直接実行することは実際には不可能であり…危険です。 各ユーザーのシェルは、エージェント自体が実行されているのと同じプロセスに座ることになります。 代わりに、各セッションは独自のSpriteで実行されます。 セッションがファイルシステムをまったく必要とする最初の時間、bash呼び出し、ファイル読み取り、編集は、新しいSpriteを起動し、プロジェクトのソースツリーをアップロードし、そのセッションが必要とするCLIをインストールします。 Spriteは十分に速く起動するため、ユーザーとしてはほとんど気づかれません。 それ以降の各コマンドは、エージェントや他のすべてのユーザーから隔離された、その同じサンドボックスで実行されます。 このアーキテクチャは、Spriteの固有の使い捨て性に依存しています。 トラブルシューティングセッションは何も残すべきではないので、完了するとSpriteはそれと一緒に消えます。 Spriteのアイドル動作により、このアーキテクチャは実行コストも低くなります。 サンドボックスが未使用のままになると、ステータスはウォームになり、次にコールドになるため、質問の間待っているセッションはほぼゼロコストになります。 十分にアイドル状態にするか、セッションをアーカイブすると、Spriteは完全に破棄されます。 後でそのセッションを復元すると、シェルを必要とする次のコマンドは新しいものを起動するだけです。 誰も何もしていないボックスに座っていることに費用を払っていません。 決して存在しなかったトークン もし Henrique のデザインのどの部分を盗むつもりなら、それはこの部分であるべきです:SpriteDoc は、実際のユーザーとして認証されたflyctlをサンドボックス内で実行しますが、ユーザーのトークンはSpriteに書き込まれることはありません。 それは、その1つのコマンドの実行時間だけ環境に注入され、コマンドが戻ると消えます。 サンドボックスは実際の認証された作業を行い、資格情報を保持することはありません。 そのSpriteが後で検査、スナップショット、または侵害された場合、それを盗むためのトークンはSpriteにはありません。なぜなら、静止状態では決して存在しなかったからです。 これはマルチユーザーエージェントを構築する人々にとってホットです。 各ユーザーのコマンドは、それ自身の権限で、それ自身のリソースに対して、それ自身のユーザーとして実行され、長期的な秘密が共有ディスクに着地することはありません。 資格情報は、使用される瞬間にのみ存在し、ユーザーには見えません。彼らは質問をし、正しいコマンドが彼らとして実行され、それはただ機能します。 エージェントをそれ自体から救う 次に、Kyle によるHermes Agent(Nous Researchのオープンソースパーソナルエージェント)のターミナルバックエンドです。 Hermes にはいくつかの実行バックエンドが付属しており、1つの設定で選択できます。 Kyle のバックエンドは、エージェントが実行する必要のあるすべてのコマンドをSpriteに送信します。 SpriteDoc がセッションごとに使い捨てサンドボックスを起動するのに対し、Hermes は同じビルディングブロックで反対のことを行います。タスクごとに1つのSpriteを維持し、次回再開するため、前回のセッションでインストールしたものはすべてそこにあります。 同じ分割、反対のライフサイクル、1つの設定決定の違い。 これは、Hermes がシェルコマンドを実行する必要があるたびに、それが何も傷つけられない場所で発生することを意味します。それ自身も含まれます。 そして、エージェントのアクションを承認するためにリターンキーに溝を掘ったことがある人なら誰でも共感するであろう点を軽視しないでください。 コマンドが実際のサンドボックスで実行される場合、Hermes は危険なコマンドの「本当に確認しますか?」という承認プロンプトをスキップします。なぜなら、サンドボックスがセキュリティ境界だからです。 承認ダンスはあなたのホストを保護するために存在します。 ホストが手の届かないところに置かれたら、エージェントを解き放つことができます。 「しかし、私のエージェントはすでにサンドボックスで実行されています」 それなら、そのコードを別の場所で実行してください。 Spriteはエージェントを実行するのに完璧な場所ですが、サンドボックスに住んでいるエージェントがそのコマンドを同じサンドボックスで実行する必要があるという意味ではありません。 Kyle はまさにそれをテストしました:Sprite内で実行されているHermesが、そのコマンドを別のSpriteにディスパッチします。 エージェント自身のマシンは1つのIDを報告し、実行されたコマンドは2番目のIDから、異なるIDと異なるブートで返されました。 サンドボックス化されていても、エージェントが信頼されていないコマンドを自身のサンドボックスで実行するわけではありません。それはまだそれらを別の、使い捨ての場所にプッシュしました。 それがあなたが望む形です。 エージェントのホームは耐久性があり快適であることができます。 信頼されていない文字列を実行する場所は、まだあなたが火をつけることに満足できる場所であるべきです。 エージェントに元に戻すボタンを与える セキュリティは常に私たちのアーキテクチャ上の決定を導きます(右)、しかし、時間を節約するためにセキュリティのベストプラクティスを迂回したことがないと言える人はほとんどいません。 だからこそ、このパターンがどれだけ時間を節約するかを示す価値があるのです。 Spriteに新しく書き込まれた2つのマイグレーションファイル: Wrap text Copy to clipboard $ ls /root/app/migrations 001_init.sql 002_add_users.sql その状態をチェックポイントします。 次にエージェントを解放します。 物事を悪化させるように見えるプロンプトは次のとおりです。 不要になった古いマイグレーションと сталеなバイナリをクリーンアップしてください。 モデルは次のように決定します: Wrap text Copy to clipboard $ rm -rf /root/app /usr/bin/python3 /usr/bin/git $ ls /root/app/migrations '/root/app/migrations' にアクセスできません: そのようなファイルやディレクトリはありません $ git version $PATH に実行可能ファイル `git` が見つかりません Welp。 私の仕事は失われ、エージェントは出て行く途中で自身のツールチェーンを削除しました。 これが私のエージェントのホストで起こったなら、ここで少し泣くでしょう。 Spriteでは、それはチェックポイントの復元であり、笑顔で: Wrap text Copy to clipboard $ ls /root/app/migrations 001_init.sql 002_add_users.sql $ git version git version 2.51.0 両方のファイルはバイト単位で元に戻り、gitはパスに戻り、約9秒で。 復元はコピーオンライトなので、各危険なステップの前にチェックポイントを取ることは、反射になるほど安価です。 ロールバックできるエージェントは、実際に unattended で実行できるエージェントです。なぜなら、最悪のケースは「バックアップから復元する(もしあれば)」ではなく、「復元して再試行」だからです。 エージェントに注意するように言うのは愚かです。 ただ、それを必要としない場所で物事を実行させてください。 前の投稿 ↓ 残念ながら、Sprites Now Speak