AREX Feed Article
Google AI Studio 开放 Gemini API Managed Agents 自带沙箱，七家伙伴同日接入
11 月 11 日（北京时间 12 日凌晨 4 时 10 分），Google AI Studio 官方 X 账号宣布：在 Gemini API 上使用 Managed Agents（托管智能体）构建的开发者，现在可以自带沙箱（bring your own sandbox），用自托管环境（self-hosted environments）接管智能体的工具执行；帖文附上 ai.studio 链接，称当天即可开始构建。5 分钟后，列出同日一同发布的七家伙伴：Vercel、Modal、Daytona、fly.io、Google Cloud、Cloudflare 与 E2B。
这道功能改变的是 Managed Agents 里「工具在哪跑」的默认设定。按 Google 的描述，此前一次 API 调用会让 Gemini 在 Google 托管的隔离云沙箱里完成推理、代码执行、装包、文件管理和网络检索。官方帖文没有展开的部分，由两家伙伴随后贴出的集成文档补齐：模型与 agent 循环（agent loop）留在 Google，命令行（shell）操作和文件读写被推到开发者自己的沙箱里执行。
模型留在 Google，工具调用搬回自家沙箱
E2B 在原帖回复里贴出文档，其描述了机制：自托管环境下，Managed Agent 的文件与 shell 工具运行在一台由开发者控制的机器上，Gemini 在 Google 侧完成规划；沙箱内一个小型 worker 进程 gemini-api environments connect 通过 HTTPS 主动连向 Google，领取每一条工具调用、在本地执行后回传结果——文档原话是「没有任何连接反向进入沙箱」（Nothing connects in）。
Daytona 的给出了三方分工：Google 运行 Gemini API、agent 循环和模型，并托管这个自托管「环境」——一个环境 id、一把 environment key（环境密钥）、一条等待 worker 认领的交互队列，环境本身没有任何计算资源；开发者运行自己的应用和 worker（即 Google 的 gemini-api CLI 内置的环境运行时，负责在本地执行工具调用）；沙箱平台提供 worker 的落脚处。创建环境只需向 generativelanguage.googleapis.com 的 v1beta/environments 端点发送 mode: self_hosted 的 POST 请求；返回的 environment key 只在响应里出现一次。Daytona 的示例 agent 是 antigravity-preview-09-2026，且 environment 参数只在 v1beta 版本上被接受。
worker 提供七个工具：执行 shell 命令的 execute_bash，读取和检索文件的 view_file、list_dir、grep_search、find_by_name，创建与编辑文件的 write_to_file、replace_file_content。文件类工具被限制在 worker 的 --root-dir 目录内；execute_bash 执行的是模型生成的命令、不受此限制——Daytona 文档因此提醒，worker 应放进沙箱，而不是直接跑在自己的机器上。权限也做了切分：environment key 只允许 worker 认领这一个环境的交互，动不了 Gemini 项目里的其他资源；Gemini API key 留在应用侧。Google 官方的 也已单列 self-hosted environments 一节。
Daytona：一个长驻 worker，或每个任务一个一次性沙箱
Daytona 的指南给出两种跑法，对应「沙箱状态要不要保留」这个部署问题。长驻模式是 gemini-api environments connect 在一个长期存活的沙箱里自己领单，文件在沙箱存活期间跨交互保留，适合单人使用或开发循环；代价是 environment key 就存在 agent 命令运行的沙箱里。Daytona 的示例给这个沙箱设置了闲置 15 分钟自动停止并删除。
一次性模式对应生产口径：gemini-api environments poll 在开发者自己的主机上运行，为每条交互租约启动一个全新沙箱，沙箱里只注入该次交互的短时 lease token（租约令牌），交互结束即销毁，存活上限（TTL）2 小时；沙箱里既没有 Gemini API key，也没有 environment key。代价是每次交互多几秒沙箱启动时间；派发交接默认限时 2 分钟，超时按失败处理、交互稍后重新派发。
E2B：预置模板与一把读不到的密钥
E2B 的路径是一条命令：e2b sandbox create gemini-e2b --timeout 3600 启动预置沙箱，gemini-api CLI 已安装、版本固定并经校验和验证，git、python3、node 就绪，无需构建镜像或克隆仓库。
密钥处理是这份文档的重点：Gemini API key 和 environment key 都存进 E2B Secrets，沙箱里只有一个占位符字符串，E2B 在请求发往 Gemini API 时按 host 注入真实密钥。文档解释了为什么这样做：agent 的 shell 与 worker 跑在同一个沙箱里，密钥若以环境变量传入就能被 agent 读走；这套注入让沙箱里没有可读的密钥。边界同样写明——按 host 注入意味着沙箱内任何进程仍能发起对 Gemini API 的已认证调用；其余出站流量默认开放以便安装软件包，可用 allowOut、denyOut 收紧。另有一个浏览器工作台：跑在沙箱的 8000 端口，访问 token 每个沙箱一把、只在沙箱终端打印一次、放在 URL 的 # 之后（浏览器不会把它发给服务器），拿不到 token 的请求一律返回 401。
这套模式，Anthropic 已先行开放
自带沙箱在 Managed Agents 这类产品里并非新事物。显示，其 Managed Agents 的 self-hosted sandboxes 已进入 Beta，API 要求 managed-agents-2026-04-01 版本头，架构与 Gemini 这套相仿：环境充当工作队列，worker 认领任务，Claude 模型跑在 Anthropic 一侧，工具的输入与输出仍流经 Anthropic。文档列出的平台指南覆盖 Cloudflare、Daytona、E2B、Fly.io、GKE（Google Cloud）、Modal、Vercel——与这次 Google 公布的名单几乎重合。
宣布过用 Modal Sandbox 承接 Claude Managed Agents 的全部工具调用；同样面向 Claude Managed Agent、以 Vercel Sandbox 作为执行层。对这批同时服务两家的沙箱厂商来说，同一套 worker 模式现在要接两个平台：Daytona 和 E2B 的文档库已同时挂着 Claude 与 Gemini 两套 Managed Agents 指南。
回复区：两句问候与一串追问
（其 X 资料注明在做 Gemini、Google AI Studio、Gemini API 与 Kaggle）回帖「不错！」；（资料注明 applied ai @E2B）贴出 e2b sbx create gemini-e2b 和一句「很高兴参与其中！」；（资料注明 Engineer @daytonaio）在原帖发布约 14 分钟后贴出部署指南链接。
开发者的追问集中在两件事。：会话结束后 agent 能否在同一沙箱里恢复，还是每次都要重建环境；了自己的观察——「没有安全团队会让 agent 在别人的盒子里碰生产凭证」——同样问状态能否跨运行保留。Daytona 文档对这个问题给出了分模式的答案。「模型还是跑在 Google，对吧，只有沙箱是我的」，文档里也有直接答案。
限制也被点了出来。：沙箱是计算边界，不是数据边界——agent 在自家环境里读到的每样东西仍要经过模型才能被处理，自托管盒子并不搬走数据。这与两份文档描述的机制相符。
名单之外的空白
官方帖文只给出名单和一句引导语：各伙伴环境的具体集成形态、定价、可用区域都没有说明。回复区与本文检索中，能直接核实到的当日集成文档来自 E2B 与 Daytona 两家；对 Vercel、Modal 与 Cloudflare 的公开检索，看到的仍是其为 Anthropic Managed Agents 发布的同类指南。名单上其余五家如何接入、环境如何计价、开在哪些区域，截至发稿没有下文。