AI実行環境ではenvironmentとterminal sessionを分けて考える
AIエージェントをshellやPTY経由で動かす場合、terminal sessionとsandbox environmentを同じlifecycleにしない方が設計しやすい。
terminal sessionは「対話中のprocess」であり、environmentはfilesystem、network policy、credential、resource limitなどを持つ実行基盤である。両者は寿命が一致しないことが多い。
例えば1つのenvironmentに、次のような複数sessionが存在しうる。
- coding agentのPTY
- plain shell
- test runner
- log tail
- 別agentのsession
これを1 session = 1 sandboxと固定すると、同じworking treeやdependency cacheを共有したいだけでもenvironmentを複製する必要が出る。一方で、互いに変更を干渉させたくないtaskではenvironmentごとforkした方がよい。
そのため、概念的には次のように分けると扱いやすい。
- Environment: isolation boundary、filesystem、network、secrets、resource lifecycle
- Session: PTY/process/conversation lifecycle
必要なときだけEnvironmentをclone/forkし、その中に1つ以上のSessionを作る。
この分離は、Kubernetes Agent Sandboxが Sandbox / SandboxClaim をprocessそのものより上位のlifecycle primitiveとして扱っている考え方とも相性がよい。Kubernetes Agent Sandboxはstateful singletonをSandbox CRDにする
また、VM snapshotを使う場合も、sessionの状態保持とenvironmentのstate保存を区別する必要がある。FirecrackerではmemoryとVMM stateをsnapshotできる一方、network connectionやvsock connectionの継続には制約がある。Firecracker snapshotは状態を持つsandbox再開に向く
sandbox方式そのものの選択は AIエージェント用sandboxでcontainerとVMをどう選ぶか を参照。