让自主编码 Agent 接管 Shell 权限后，最让人提心吊胆的不是它写出死循环，而是环境变量里的 API Key 被直接打印或打包送走。2026年10月13日，Ollama 宣布与 Fly.io 达成集成，把后者的持久化 Linux 虚拟机沙箱 Sprites 接进了生态，上线 Ollama Connector。
官方的卖点很直接：让 Claude Code、Codex 或 Gemini CLI 跑在独立的微虚拟机里，调用 Ollama Cloud 上的模型，全程不需要在沙箱内注入真实的 API Key。
但这套方案只解决了一半的问题。开发者必须看清的是，凭证没有泄露，绝不等于调用过程安全。
凭证代注入：把密钥从沙箱里拔掉
过去把执行权限交给自主 Agent 时，工程上往往面临两难：要么把密钥写进虚拟机环境变量冒着泄露风险，要么开发者自己架设一层反向代理。
Fly.io Sprites 采取了宿主网关代注入的逻辑。开发者在组织层录入 Ollama API Key，系统加密存储且禁止通过 API 导出。在沙箱内部，程序只知道一个网关地址与一个 connection ID，发送的请求没有真实的认证头。当流量经过 Fly.io 网关时，网关核对 Sprite 身份，自动拼装真正的认证密钥转发给 Ollama Cloud。
+-------------------------------------------------------------+
| Sprite 沙箱 (Linux 微VM) |
| |
| Agent (Claude Code / Codex / Gemini CLI) |
| | |
| | curl / SDK 请求 (api_key="unused") |
| v |
+--------+----------------------------------------------------+
| (无真实 Authorization 头，仅携带 connection ID)
v
+-------------------------------------------------------------+
| Fly.io Gateway (网关层) |
| |
| 1. 校验 Sprite 来源与访问权限 |
| 2. 自动注入组织层加密的真实 Ollama API Key |
+--------+----------------------------------------------------+
|
| 携带有效凭证转发
v
+-------------------------------------------------------------+
| Ollama Cloud API (kimi-k3 / glm-5.3 / deepseek-v4.1-flash) |
+-------------------------------------------------------------+网关遵循默认阻断原则，新创建的 Connector 默认拒绝任何沙箱的请求，开发者必须显式按标签或名称前缀绑定白名单。这一套设计确实封死了黑客通过执行 env 命令盗取明文 Key 的路径。
网关防住了外泄，但防不住提示词劫持
古人云：门虽设而常关。然而如果开门的人被掉包，锁再结实也无济于事。
这就是所谓的安全落差。API Key 确实没有暴露在虚拟机的操作系统里，但 Agent 依然拥有向网关发送请求的合法通道。一旦 Agent 处理不可信外部输入时遭遇提示词注入（Prompt Injection），被恶意指令劫持，攻击者根本不需要导出密钥。攻击者只需让沙箱内的 Agent 持续向网关发送高消耗请求，网关就会忠实地盖上合法印章，转发给云端。
此时网关实际上变成了攻击者的免费代理。Fly.io 目前并未公开细粒度的网关控制能力：既没有单任务硬性支出上限，也没有按模型划分的精细白名单，更缺乏针对提示词内容的风控过滤。官方文档中，对于 Connector 网关的额外请求速率限制、单次 Payload 限制以及超额队列容量，同样未予明确说明。
凭证未泄露不等于系统安全，身份防护代替不了授权治理。
- 风险.若缺乏请求层面的单次预算硬限制，提示词注入可以直接把合法网关变成消耗账户额度的抽水泵。
保硬盘还是保内存：微 VM 的路线分流
除了安全盲区，开发者还必须面对沙箱运行机制的妥协。目前业内主流隔离环境正从轻量容器转向微虚拟机，但底层的设计取向截然不同。
Fly.io Sprites 采用基于 Firecracker 的微 VM，唤醒耗时常规约在 100–500 毫秒 之间（冷启动约 1–2 秒），其休眠机制是仅持久化磁盘，清空内存与进程。每台实例挂载 100GB 卷并按实际使用量计费。相比之下，同样基于 Firecracker 的 E2B 唤醒耗时约 1 秒，却选择通过内存暂停来保留 Python 进程与内部变量；Modal 主打亚秒级冷启动；Daytona 的容器方案则能压到 90 毫秒以内。
| 沙箱技术方案 | 底层隔离机制 | 休眠保留状态 | 常规唤醒耗时 |
|---|---|---|---|
| Fly.io Sprites | Firecracker 微VM | 仅保留磁盘（RAM清空） | 100–500 毫秒 |
| E2B | Firecracker 微VM | 磁盘 + 内存与进程挂起 | 约 1 秒 |
| Modal | 微VM / gVisor | 镜像恢复（视模式而定） | 宣称亚秒级 |
| Daytona | 容器 / Linux VM 分立 | 区分容器快照与虚拟机磁盘 | 容器模式 <90 毫秒 |
Sprites 只保硬盘的设计是一把双刃剑。好处是实例空闲休眠时直接切断计算收费，但代价是交互式运行状态会随着休眠灰飞烟灭。如果你的 Agent 高度依赖长时间运行的守护进程或类似 Jupyter Notebook 的内存变量流，Sprites 唤醒后必须重新走一遍初始化脚本，体验明显不如具备进程挂起能力的方案。
算力单价与云端模型的双重账本
从本地开源运行时走向多模型托管平台，Ollama Cloud 的野心写在定价表里。其订阅分为四档：Free 套餐 0 美元配备 1 个并发；Pro 套餐每月 $20，包含 60 美元额度与 3 个并发；Max 套餐每月 $100，含 300 美元额度与 10 个并发；Team 套餐每月 $500，含 1,000 美元共享额度与 10 个并发。
其托管模型的调用单价各不相同：deepseek-v4.1-flash 输入每百万 Token 收费 $0.30，缓存输入只需 $0.006，输出 $1.20；glm-5.3 输入 $1.40、输出 $4.40；kimi-k3 则达到输入 $3.00、输出 $15.00。
在基础设施层面，Fly.io Sprites 采取纯细粒度计费：
- CPU.每 CPU-小时 $0.0385
- 内存.每 GB-小时 $0.021875
- 存储.热存储每 GB-小时 $0.000683，冷存储每 GB-小时 $0.000027
配额方面，按量付费租户每分钟最多创建 10 个实例；Hero 套餐支持 100 个运行中与 100 个热备（warm）实例，冷存储实例无限制。
在 100 小时运行基准测试中（2 vCPU / 4 GiB 规格），E2B 与 Daytona 的固定预留成本约为 16.56 美元，Modal 约为 23.80 美元。Sprites 若处于持续满载，成本同样在 16.45 美元左右；但如果 Agent 大部分时间处于等待思考的低负载状态（按平均 0.5 CPU / 1.5 GB 测算），其实际硬件支出会骤降至 $5.21。
- 建议.断续调用与间歇性编码任务优先选 Sprites 吃满休眠红利；需要常驻进程、即时交互的工作流则应留在保留内存的微 VM 里。
Ollama 联手 Fly.io 迈出了工程解耦的务实一步，用透明网关拆除了开发者自行反向代理的繁琐脚手架。但面对自主 Agent 这个充满不确定性的执行体，藏起一把钥匙只是防线的起点，如何把控每一次未经审查的调用，才是接下来真正要结算的硬账。