Agent37发布低成本智能体沙箱：Agent运行与隔离成本分析

YC F26 新创公司 Agent37 近日发布智能体沙箱服务，试图用按量计费的隔离运行环境，降低浏览器操作、代码执行和长期 Agent 任务的基础设施成本。

Agent37想解决的，不是模型成本

Agent37近日在 Hacker News 发布产品，推出面向 AI Agent 的低成本沙箱服务。它的目标很直接：让开发者不必自己拼装 Docker、虚拟机、浏览器环境、任务调度和生命周期管理，也能为每个 Agent 提供一个可启动、可隔离、可回收的执行空间。

Agent 沙箱是为智能体提供隔离计算环境的基础设施，用来运行浏览器、代码、命令行工具或桌面交互，同时限制任务对宿主机和其他任务的影响。 对今天的 Agent 开发者来说，模型只是“决策层”，真正把任务做完，还需要一个能执行 shell 命令、安装依赖、读写文件、访问网页、运行浏览器甚至保存中间状态的“操作层”。

过去这部分工作往往被低估。一个 Coding Agent 需要临时拉起开发环境，一个 Deep Research Agent 需要启动浏览器并执行多轮网页操作，一个 GUI Agent 可能要维持完整桌面会话。开发者如果直接在宿主机执行，成本最低，但安全风险几乎不可接受；如果为每个任务创建虚拟机，隔离更强，却会迅速遇到启动速度、资源利用率和账单问题。

Agent37切入的正是这段基础设施空白：把“给 Agent 准备一台临时电脑”变成一种按使用量购买的托管服务。

AI Agent 在隔离沙箱中运行浏览器、代码和命令行任务的架构示意图

低成本的核心，不只是便宜的 CPU

Agent37 的低成本路线，本质上是把沙箱的创建、配置、隔离和销毁流程产品化，而不是简单出租一台云服务器。 这一区别很重要。开发者购买 EC2 实例后，仍然需要自己解决镜像构建、环境初始化、权限控制、任务超时、异常回收、并发扩容和数据清理；Agent37试图把这些运维工作纳入沙箱服务本身。

从公开的产品定位看，Agent37面向的是高频、短生命周期、并发波动明显的 Agent 任务。典型任务不是持续占用一台服务器数天，而是启动一个环境，执行几分钟到几十分钟的操作，再暂停、销毁或从快照恢复。这样的负载与传统 Web 服务不同：它更像“批量开工的临时工作间”，空闲时间不应该持续支付完整计算资源费用。

对于开发者而言，真正影响总成本的通常有四项：实例启动时间、实际运行时长、空闲资源占用和环境维护成本。单看每小时 CPU 价格，很容易得出错误结论。一台便宜的云主机，如果每次任务都要等待几分钟安装依赖，或者需要长期保留一批预热机器，最终账单未必低。

Agent37的价值判断因此不是“它的 vCPU 单价一定最低”，而是它试图把 Agent 工作负载中大量不可见的工程成本压缩掉。对于每天运行数千次短任务的产品，这往往比单纯降低几分钱的算力单价更有意义。

和云主机、容器平台相比，差异在哪里

普通云主机提供的是计算资源，Agent 沙箱提供的是面向任务的执行单元。 AWS EC2、Fargate 等产品足够灵活，但隔离策略、生命周期和 Agent 环境需要开发者自行搭建；容器平台降低了部署难度，却不天然解决不可信代码、多租户任务和浏览器状态管理问题。

下面是公开资料中几类方案的价格和能力对比。价格为参考值，地区、存储、网络流量和套餐折扣可能改变最终成本，不能简单视为同等规格的一对一报价。

| 方案 | 公开计算价格或计费方式 | 隔离形态 | 开发者需要自行处理的部分 | 更适合的场景 | |---|---:|---|---|---| | Agent37 | 主打低成本、按用量运行的 Agent 沙箱；公开资料未给出完整统一规格价格 | 面向 Agent 任务的托管沙箱 | 需重点确认配额、持久化和网络策略 | 高频短任务、浏览器 Agent、代码执行 | | AWS Fargate | us-east-1 约为 $0.000011244/vCPU-秒 + $0.000001235/GB-秒 | Serverless 容器 | 隔离策略、镜像、生命周期、调度和回收 | 已有 AWS 体系的容器工作负载 | | AWS EC2 C6a | us-east-1 约 $0.0765、$0.153、$0.306/小时，取决于实例规格 | 虚拟机 | Agent 环境、扩缩容、更新、备份、权限和清理 | 长时间运行、可控性优先的服务 | | Morph | $0.05/MCU；MCU/小时按 vCPU、RAM/4、磁盘/16 的最大值计算 | 面向开发任务的托管执行环境 | 需评估快照、网络和生态适配 | 代码 Agent、开发环境和快照工作流 | | Northflank | 约 $0.01667/vCPU-小时 + $0.00833/GB-小时 | 容器化平台 | 计算之外的存储、隔离和 Agent 编排 | 通用容器部署 | | Docker Sandboxes | $0.14、$0.28、$0.56/小时，按秒计费 | 每个沙箱一个 microVM | 需要自行设计更上层的 Agent 调度 | 对隔离要求较高的开发和测试 |

表格里最值得注意的是，Fargate 和 EC2 的价格并不等于“运行 Agent 的总价”。存储、IPv4、网络传输、镜像拉取、日志以及长期保留的工作区都可能额外计费。更关键的是，开发者仍要为每个 Agent 任务写一套资源分配和异常回收逻辑。

Agent37如果能在这些环节提供一致的默认能力，就有机会以更高的单位价格换取更低的总拥有成本。不过，这个判断成立的前提是它的启动速度、故障率、并发上限和数据持久化能力达到生产要求。仅凭“低成本”三个字，还不足以替代成熟云平台。

沙箱隔离，为什么不能只靠 Docker

Docker 容器隔离依赖宿主机共享 Linux 内核，因此容器不等于虚拟机，也不等于绝对安全。 对内部工具和可信代码，容器加上 seccomp、AppArmor 或 SELinux 通常已经足够；但对由大模型生成的代码、第三方插件和多租户任务，开发者需要考虑更强的隔离层。

一个 Agent 可能执行模型生成的 shell 命令，安装未知 npm 或 Python 包，访问网页并下载文件，还可能被提示注入诱导去读取环境变量。只要任务能够接触宿主机文件系统、云凭证或内部网络，风险就不再是“代码写错了”，而是潜在的数据泄露和权限越界。

通常可以把隔离方案分成三档：

进程级隔离：成本最低，启动最快，但不适合运行不可信代码。
容器级隔离：通过 Linux namespace、cgroups 和 seccomp 限制资源与系统调用，适合单租户或经过强化的任务。
microVM 级隔离：每个任务拥有更独立的内核边界，常见实现包括 Firecracker 或 Kata Containers，适合多租户和高风险执行。

Agent37的产品价值，很大程度上取决于它到底采用哪种隔离模型，以及是否允许开发者配置网络出口、文件挂载、系统调用和凭证注入。产品页面如果只强调“sandbox”，却不说明威胁模型，企业用户很难据此做安全评估。

Agent37最可能的三个使用场景

Coding Agent 是低成本沙箱最直接的落地场景。 例如，用户提交一个 GitHub 仓库后，Agent 在独立环境中安装依赖、运行测试、修改代码并生成补丁。任务完成后，环境可以销毁，避免不同用户之间的依赖和文件相互污染。对这类场景，快照和工作区恢复能力比单纯的 CPU 峰值更重要。

浏览器 Agent 是第二个高价值场景。 浏览器自动化通常涉及 Chromium 进程、页面缓存、下载文件、Cookie、代理和反爬策略。如果所有任务共用一个浏览器进程，状态串扰和数据泄露风险都会上升；如果每个任务都启动一台完整桌面虚拟机，资源开销又过高。托管沙箱能够把浏览器会话封装成可创建、可暂停、可销毁的执行单元。

浏览器控制方式也会影响成本。基于 Chrome DevTools Protocol 的方式主要传输页面结构、事件和控制指令，带宽与 CPU 开销通常低于 VNC 传输完整桌面画面。参考资料显示，CDP 方案的典型带宽约为 1—5 Mbps、延迟约 10—50ms；VNC 可能需要 10—50 Mbps，延迟约 50—200ms。对于需要视觉点击的 Computer Agent，VNC 或图形桌面仍有价值；对于网页表单、DOM 操作和网络拦截，CDP 更高效。

Deep Research 和强化学习是更能体现规模效应的场景。 一个研究 Agent 可能同时打开多个网页、执行搜索、下载文档并运行解析脚本；强化学习任务则可能每分钟启动大量短生命周期环境。此时，沙箱的创建速度、并发配额、快照克隆和资源回收能力，比单个实例的峰值性能更重要。

低价能否成立，关键看四个数字

评估 Agent37不能只看每小时价格，至少要同时看启动延迟、有效运行占比、并发上限和失败重试成本。 这四个指标决定了“低成本”是否会在实际业务中兑现。

第一是启动延迟。如果一个沙箱从请求到可执行需要 10 秒，而 Agent 每次只运行 20 秒，那么一半时间都花在等待环境。云厂商已经把毫秒级或百毫秒级启动作为竞争指标，腾讯云公开资料称其 Agent 沙箱实例可在约 100ms 启动，并支持大规模并发。Agent37需要说明自己的冷启动、热启动和镜像缓存数据，否则开发者无法判断它适合交互任务还是批处理任务。

第二是有效运行占比。Agent 经常会思考、等待网页、等待外部工具或暂停数分钟。如果暂停期间仍按完整实例计费，所谓按量计费的优势会被闲置成本抵消。能够休眠并从内存或快照快速恢复的沙箱，更适合长链路任务。

第三是并发上限。一个开发者本地测试几十个 Agent 并不困难，但生产环境可能在几分钟内同时触发数千个任务。官方资料应明确每账户并发数、区域资源、排队机制和突发配额，而不是只提供单实例性能。

第四是失败重试成本。浏览器崩溃、网络超时、依赖安装失败和模型重复规划都会造成任务重试。如果每次重试都重新拉取镜像和安装依赖，账单与延迟都会快速上升。快照、缓存和幂等任务设计，是降低真实成本的关键。

它还没有取代云厂商

Agent37目前更像是 Agent Infra 的专用入口，而不是 AWS、腾讯云或阿里云的全面替代品。 大型云厂商的优势在于区域覆盖、网络、身份权限、对象存储、审计和企业采购体系；创业公司的优势则在于产品聚焦，能够围绕 Agent 任务提供更短的接入路径。

国内市场已经出现相近方向的产品。腾讯云 Agent 沙箱服务支持 Code、Browser 和自定义沙箱，并提供 SDK、API、CLI、MCP 等接入方式；相关资料宣称实例可实现约 100ms 启动、支持 24 小时实例存在时间和弹性资源供给。阿里云 ACS Agent Sandbox 则强调 MicroVM 隔离、内存级休眠唤醒、Checkpoint 克隆和最高每分钟 15000 个沙箱的弹性能力。

这意味着Agent37面对的不是一个空白市场，而是一个正在快速标准化的基础设施赛道。它必须在至少一个维度形成明确优势：更低的短任务成本、更好的浏览器环境、更简单的开发者体验，或者对主流 Agent 框架更友好的兼容性。

对开发者来说，选择标准也不应是“谁宣传得最便宜”，而应是任务是否匹配：

内部可信脚本：容器或现有 CI 环境可能已经足够。
多租户代码执行：优先确认 microVM、网络隔离和凭证保护。
浏览器自动化：重点测试 CDP、下载、Cookie 隔离和反爬稳定性。
长时间研究任务：重点看休眠、唤醒、快照和持久化工作区。
强化学习与批量评测：重点看并发启动速度、排队机制和失败重试费用。

判断：沙箱会成为 Agent 的必选基础设施

Agent37发布的意义，不在于又增加了一个云计算供应商，而在于 Agent 正在从“调用模型”进入“管理执行环境”的阶段。 当智能体只负责生成文本时，开发者可以把大部分注意力放在上下文、工具调用和提示词上；当智能体开始运行代码、打开网页和修改文件时，隔离、状态、权限和成本就变成同等重要的问题。

Agent37的低成本定位抓住了一个真实痛点：很多 Agent 任务并不需要一台长期运行的服务器，却需要一个随时可用、相互隔离、能保存状态的临时工作区。谁能把这个工作区做得足够快、足够安全，并且让账单与任务量线性对应，谁就更可能成为 Agent 应用的底层基础设施。

但它目前仍处于需要验证的阶段。开发者在投入生产前，至少应要求看到冷启动 P50/P95、不同镜像下的启动耗时、单账户并发上限、网络出口策略、数据删除机制、沙箱逃逸防护、快照存储价格和完整的失败重试规则。

我的判断是：Agent37的方向是对的，产品价值也比“又一个容器托管平台”更清晰；但它能否真正做到低成本，取决于运行时效率和安全边界，而不是宣传页上的基础计算价格。对正在开发 Coding Agent、Browser Agent 或多步骤研究 Agent 的团队，值得尽早做小规模压测；对已经拥有成熟 Kubernetes、云安全和调度体系的大型团队，它更可能是补充，而不是替换。