実行環境 / サンドボックス
エージェントが生成したコードをホストを危険に晒さずに実行するための隔離環境。エージェントに自作コードを実行させるなら、任意の追加要素ではなく前提条件です。
4件
`dsh`はDeepSeek AIが自ら開発するエージェントハーネスで、`npx @deepseek-ai/dsh web`を実行すれば既定で`http://127.0.0.1:3080`にWeb UIが立ち上がります。中身はCordisを土台にした「すべてがプラグイン」の構成なので、既製の挙動をそのまま使うより、自分で機能を足していく前提のチームに向いています。一方で本人たちがdeveloper previewと明言し、互換性を壊す変更があるとREADMEで大文字の警告を出しているため、いま書いたプラグインが次のバージョンでそのまま動く保証はありません。READMEが説明する起動方法も`web`コマンドとソースからの実行だけで、それ以外は開発ガイドとアーキテクチャ文書へのリンクが示されるにとどまる点は把握しておきたいところです。
隔離されたコンテナ内でファイル編集・テスト実行・ドキュメント参照を行うため、実行が失敗してもホスト環境を壊しません。SWE-bench系のベンチマークでは上位の成績を出していますが、実際のリポジトリに向ける前にコスト試算を勧めます。長時間の自律実行はトークン消費が大きく、生成結果はマージ前に人間のレビューが前提になります。
1秒を大きく下回る時間で隔離されたマイクロVMを起動できるため、タスクごとのサンドボックス化が理論ではなく実務になります。エージェントに自作コードを実行させるなら、この種の仕組みは「あると良いもの」ではなく必須要件です。セルフホストも可能ですが、ホスティング版に比べて相応の作業量が必要になります。
Cloudflare OSは、エージェントとの対話と、そのエージェントが書き上げる小型アプリ(Gadget)を同じ画面に載せた業務環境です。Gadgetのサーバー側はインターネット接続を無効化したDynamic Worker、クライアント側はサンドボックス化したiframeで動き、両者の通信はpostMessage経由のCap'n Web RPCに限られます。外部サービスへは利用者が明示的に「紹介」したリソースだけにGatekeeper経由で到達し、副作用のある操作はいったん模擬結果を返してエージェントを止めずに進ませ、実行そのものは後からまとめて承認・却下できます。ただし設計はWorkers固有の機能に深く依存しており、ワークスペースはDurable Object、GadgetはDynamic WorkerのFacetとして動きます。自前サーバーのworkerdへ載せる手順はREADMEでもCOMING SOONのままで、実質的な選択肢はCloudflareアカウントへのデプロイになります。2026年8月時点のv2は開発元自身がearly accessと位置づけているうえ、Gatekeeper側にも接続先ごとの設定が必要なものが多く、サービスによってはOAuthクライアント資格情報の取得が必要です。