当 AI 编程助手开始安装依赖、修改代码和运行脚本时，它已经在操作一台真正的计算机。把这些动作放进独立 Linux 环境，能让任务更容易隔离、恢复和交付，但沙箱之外的网络、账号与生产系统仍需要单独设计边界。
以 Fly.io Sprites 连接 Ollama Cloud 为例，可以把代码执行、模型请求和服务凭据分开放置，再围绕任务范围安排访问与验收。
Sprite 怎样连接模型服务#
Sprite 是具备持久磁盘的独立 Linux 虚拟机，运行其中的 Agent 可以通过网关使用云模型。Ollama 凭据由平台连接器保存，网关识别获准实例并为请求附加凭据；实例侧使用网关地址和连接标识。新连接器默认阻止全部 Sprite，需再选择允许的实例。
这能减少模型 API 密钥直接出现在执行环境里的需要。它不意味着 Agent 无法发送敏感代码，也不意味着获准实例不会耗用额度。隐藏密钥和约束实际使用能力，是两个不同问题。
先分清模型在哪里、命令在哪里#
使用 Ollama 并不必然意味着模型在本地。使用云模型与远程执行环境时，请求链路如下：
开发者：提交任务、检查差异、决定是否发布
↓
Sprite：保存代码、执行命令、运行测试
↓
连接器网关：识别实例、核对访问配置、附加服务凭据
↓
Ollama Cloud：处理模型请求并返回响应代码运行在 Sprite，不代表模型权重也运行在 Sprite。调用远程模型时，发送的提示词和选入上下文的代码会离开这个执行环境，进入模型服务。
云服务会处理请求中的提示与响应。发送之前应先决定哪些材料允许进入模型服务：可以把公开示例交给云模型，也可以对私有代码和数据设置更严格的范围。具体选择取决于项目要求，不能从“独立 VM”这一个条件推导出来。
独立环境最先解决的是工作区问题#
一个独立任务可以对应一个明确工作目录、一份基线和一组验收命令。
比如让 Agent 修复一个 Go 接口的错误处理，输入可以只包含相关仓库和必要的脱敏样例。目标写成“错误输入返回既定状态码，正常请求保持原行为”，而不是笼统地说“把这个服务优化一下”。
建议同时写清三个边界：可以修改哪些模块，必须运行哪些检查，哪些动作属于最终交付。例如允许生成补丁和运行单元测试，发布生产由开发者在审查结果后处理。这样任务停在哪里是事先定义好的，不依赖 Agent 临时猜测。
对执行环境而言，最有价值的隔离往往是“没有带进去的东西”：没有开发电脑的完整家目录，没有日常 SSH 凭据，没有与任务无关的云账号配置，也没有生产数据库连接。仅给出完成这次任务必要的材料，排查和清理也更简单。
连接器隐藏凭据，但授权仍然有效#
可以用门禁作类比：Agent 不持有钥匙原件，却可以在获准区域刷门禁。只要门禁仍然有效，它依然能进入授权范围。
因此，连接器配置至少要回答：哪些实例可用、可以到达什么服务、如何停用、如何观察用量。连接标识也应作为内部配置处理，避免随手写入公共仓库或日志；它不能替代平台鉴权，但公开它没有必要。
可以从单个任务实例授权开始，而不是直接允许所有实例。如果使用名称前缀或标签匹配，还要确认谁有权限创建匹配实例或修改标签。匹配规则清晰，不等于整个组织的权限天然清晰。
任务完成后可以撤销连接访问并检查用量。若 Agent 仍需长期工作，则把授权有效期、预算和告警写进运行方案。具体限制能力需要在控制台与相应版本文档中核对。
持久磁盘与可恢复，也有各自的限制#
Sprite 可以跨会话保留磁盘；文件系统检查点用于恢复磁盘状态，不是暂停并恢复某条 CPU 指令。持久环境适合保留依赖和中间成果，也意味着上次留下的文件会继续存在。
可以把状态分成三类：
| 状态 | 示例 | 建议处理 |
|---|---|---|
| 可重建环境 | 工具链、依赖与缓存 | 记录安装方式，便于重建 |
| 任务成果 | 源码差异、测试日志、问题说明 | 导出为可审核交付物 |
| 临时材料 | 下载文件、调试数据、临时令牌 | 完成后按任务规则清理 |
恢复磁盘不能撤回已经发生的外部动作。即使把代码恢复到昨天，已经发送的消息、写入的外部数据库和已经部署的服务都不会自动回退。因此，检查点更适合解决环境和文件层面的恢复，外部业务仍需要自己的回滚或补偿机制。
长任务恢复后也要重新确认进度。不要只读一句“上次已经测试通过”便继续发布，应检查当时的提交、产物和日志是否对应当前文件。
用一份任务卡约束交付#
例如，一个接口修复任务可以这样约定：
任务：修复演示接口遇到空参数时的异常
基线：记录明确的提交标识
允许：修改相关处理函数与针对性测试
输入：示例请求与脱敏日志
验证：运行项目既有检查，并保留退出码和日志
输出：代码差异、验证结果、未解决项
停止：超过约定轮数、预算或缺少必要信息
交付：生成补丁，交由开发者审核基线记录非常关键。同一份测试日志，如果不知道对应哪个版本，就难以证明交付代码真的接受过检查。代码差异与日志最好一起保存，避免只交一段聊天总结。
验收可以先选择低影响任务：修改文档、修复纯函数或在隔离数据上运行测试。逐步检查环境能否重建、失败能否定位、结果能否导出，再接入更多工具。若任务需要网络服务，应明确测试环境地址，避免让 Agent 根据名称猜生产或测试。
几个值得主动验证的失败场景#
建议验收时故意撤销一次连接器授权，确认任务会报告访问失败，而不是悄悄切换到其他凭据；让测试返回非零退出码，确认报告保留错误；中断一次任务，再检查恢复过程是否识别未完成步骤。
还可以提交一个带有过期说明的样例，观察 Agent 是否把网页或仓库文字当成执行授权。外部内容可以提供技术事实，不能自行扩大任务权限。这种测试主要检验编程助手的执行规则，独立 VM 本身不会替你理解业务授权。
给 AI 一台独立 Linux，适合把执行环境从日常电脑中分出来。要让它成为可靠的开发工具，还需要清楚的输入、有限的访问能力，以及能由人复查的代码与验证证据。
参考来源#
- Ollama 团队：Run AI agents safely with Ollama and Fly.io，2026-10-13。
- Fly.io：Sprites。
- Fly.io 官方文档：Sprites Overview。
- Ollama 官方文档：Cloud。
- 配图：Ollama 团队 / Fly.io，图片出处。