AI Agent 不只是调用模型和返回文本。它们还需要运行构建工具、安装第三方依赖、分析数据集、保存中间结果，并在用户稍后回来时继续之前的工作。随着 Agent 沙箱从几十个扩展到数千甚至数百万个并发会话，工作区存储会成为平台架构中的关键瓶颈。
Google Cloud 推出的 Filestore agent volumes，目标正是解决这类动态工作负载的存储问题：为每个 Agent 沙箱提供隔离、持久、可快速挂载的文件工作区，并自动处理存储卷的生命周期。
Agent 工作区为什么不能只靠本地磁盘
传统做法通常有三类：把沙箱状态频繁同步到集中式对象存储，给每个运行环境预分配本地磁盘，或者自行维护共享文件系统。这些方案都能工作，但在 Agent 数量扩大后会暴露出明显问题：
- 状态搬运增加延迟：每次恢复任务都要重新下载代码、依赖和中间文件。
- 预分配造成浪费：大量短任务或间歇性任务并不需要持续占用完整磁盘。
- 人工运维复杂：平台团队需要创建、挂载、回收和清理大量临时卷。
- 隔离边界不清晰：多个租户或多个 Agent 共享目录时，容易出现数据泄露和文件冲突。
Filestore agent volumes 与 Agent Substrate on GKE、GKE Agent Sandbox 等计算环境配合使用，把 Agent 的计算沙箱和持久文件工作区连接起来。新任务启动时，系统可以为沙箱动态分配隔离的文件空间；任务暂停或结束时，再由平台自动处理卷的挂载、卸载和生命周期。
这让平台不必把每个 Agent 的工作区当作一台需要手工维护的服务器，而可以把它视为随会话变化的基础设施资源。
四个关键能力：隔离、恢复、成本与协作
1. 按工作区隔离，降低动态代码执行风险
编码 Agent 可能会安装依赖、执行编译命令、运行测试，研究型 Agent 可能会生成和修改大量数据文件。每个沙箱拥有独立工作区，可以减少不同租户、不同会话之间的文件串扰。
对于企业平台，这种隔离还应与身份权限、网络策略和运行时沙箱结合使用。文件存储解决的是工作区边界问题，并不能单独替代容器隔离、最小权限和不可信代码防护。
2. 毫秒级挂载，支持暂停后快速恢复
交互式 Agent 经常处于“等待用户确认”或“等待下一条指令”的状态。如果沙箱和磁盘都长期运行，成本会不断累积；如果释放全部资源，恢复时又需要重新准备环境。
Filestore agent volumes 的设计重点是快速附加和分离持久工作区。平台可以在 Agent 空闲时暂停计算环境，只保留工作区状态；用户继续操作时，再快速恢复执行。对于长时间运行的数据分析、代码审查和人工审批流程，这种模式尤其有价值。
3. 按实际使用量管理存储成本
为每个并发会话预留固定大小的高性能磁盘，通常会导致大量闲置容量。动态工作区配合按使用量计费和自动生命周期分层，可以把活跃数据与低频访问数据区别对待：Agent 正在编译或分析时保持高性能，长时间未访问的状态则转移到成本更低的存储层。
需要注意的是，按使用量并不意味着成本自动可控。平台仍应设置配额、会话保留时间、最大工作区大小和清理策略，避免失控的日志、构建产物或数据集长期占用空间。
4. RWX 与 POSIX 锁支持多 Agent 协作
多 Agent 工作流常见的模式是：主 Agent 拆分任务，研究 Agent 收集资料，代码 Agent 修改实现，验证 Agent 执行测试。若每个 Agent 都通过消息传递文件，编排逻辑会变得复杂，也容易产生版本和文件冲突。
支持 Read-Write-Many（RWX）和 POSIX 文件锁后，多个 Agent 可以挂载同一个共享工作区，在统一目录树中协作。文件锁可以降低并发写入风险，但它不会自动解决所有协作问题。平台仍应设计清晰的目录约定、任务边界和提交协议，例如让不同 Agent 写入不同目录，再由审查 Agent 合并结果。
一个可改造的 Kubernetes 工作区示意
下面的 YAML 展示了一个通用的 RWX 工作区声明方式。它是便于理解和改造的示意配置：实际使用 Filestore agent volumes 时，应根据所在区域、GKE 集群配置以及已启用的 Filestore/GKE 集成，替换 storageClassName 和相关资源字段。不要直接假定示例中的 StorageClass 名称在所有项目中都存在。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: agent-workspace
namespace: agent-runtime
spec:
accessModes:
- ReadWriteMany
storageClassName: <filestore-agent-volume-storage-class>
resources:
requests:
storage: 20Gi
---
apiVersion: v1
kind: Pod
metadata:
name: agent-sandbox-example
namespace: agent-runtime
spec:
restartPolicy: Never
containers:
- name: agent
image: python:3.12-slim
command: ["bash", "-lc"]
args:
- |
set -euo pipefail
mkdir -p /workspace/project
printf 'workspace ready\n' | tee /workspace/project/status.txt
python - <<'PY'
from pathlib import Path
p = Path('/workspace/project/status.txt')
print(p.read_text().strip())
PY
volumeMounts:
- name: workspace
mountPath: /workspace
volumes:
- name: workspace
persistentVolumeClaim:
claimName: agent-workspace
应用前可以先检查集群中的 StorageClass，并确认目标命名空间和权限已经准备好：
kubectl get storageclass
kubectl create namespace agent-runtime --dry-run=client -o yaml | kubectl apply -f -
kubectl apply -f agent-workspace.yaml
kubectl -n agent-runtime get pvc,pod
如果平台采用“每个会话一个工作区”的模型，编排器可以根据会话 ID 生成 PVC 名称，并在会话结束或超过保留期限后执行回收。生产环境中还应补充 ResourceQuota、网络策略、服务账号最小权限以及工作区清理控制器。
适合落地的工作负载
编码与构建沙箱
Agent 可以在隔离目录中安装依赖、修改多文件项目、运行编译和单元测试。由于工作区保留了 .git、构建缓存和测试结果，暂停后恢复不必重新下载所有内容。
多 Agent 研究和验证流水线
主 Agent 可以创建任务目录，研究 Agent 写入原始资料和数据摘要，代码 Agent 生成分析脚本，验证 Agent 读取结果并追加测试报告。共享文件树减少了在消息系统中传递大文件的需要。
长周期、人在回路中的任务
需要用户审批的部署任务、持续数小时的数据分析，以及分阶段生成报告的工作流，都可以将计算和工作区状态分开管理。空闲期间暂停沙箱，用户回来时继续执行，有助于在交互体验和基础设施成本之间取得平衡。
采用前的工程检查清单
Filestore agent volumes 适合动态、文件密集型的 Agent 平台，但并不是所有数据都应该放进工作区。可以按下面的边界进行设计：
- 将代码、依赖缓存、临时数据和中间结果放入 Agent 工作区。
- 将最终业务记录、审计日志和不可变数据放入更适合长期保存的系统。
- 为每个租户、会话和协作组定义明确的目录与权限边界。
- 明确空闲、完成、失败和过期会话的存储回收策略。
- 测量冷启动时间、恢复时间、活跃容量、闲置容量和每次任务的存储成本。
- 对共享工作区制定文件锁、写入归属和冲突处理规则。
- 将存储隔离与容器、网络、身份和不可信代码防护一起设计。
结语
Agent 平台的存储不应只是一个挂载点，而应成为会话生命周期的一部分。Filestore agent volumes 的价值在于把隔离工作区、快速恢复、弹性容量和多 Agent 共享组合到同一套托管能力中，减少平台团队手工管理临时磁盘和文件系统的负担。
如果你的平台正在运行编码沙箱、企业级 Agent 集群或多 Agent 协作流水线，建议先从非生产环境验证三件事：工作区创建与回收延迟、暂停后的会话恢复体验，以及按真实访问模式计算出的存储成本。验证这些指标后，再决定哪些会话适合使用共享 RWX 工作区，哪些数据应转移到对象存储或数据库中。