给会写代码的 agent 划一道墙：Akamai 的沙箱与推理服务同时进入 beta

当 agent 开始自己写代码、自己跑代码，问题就不再只是“模型够不够强”，而是“它写出来的代码能在多大范围内活动”。Akamai 在 2026 年 10 月 27 日同时推出的两款产品，正好对应这两个问题：一边是 Akamai Inference，解决模型怎么被调用；另一边是 Akamai Agent Sandbox，解决 agent 写出来的代码被允许跑到哪里。两款产品同时进入 beta，这个搭配本身就是判断：只给模型，不给边界，等于只发了油门，没装刹车。

按 Akamai 官方通稿的说法，这两款产品是 Akamai Cloud 上 AI 栈的基础层：企业可以在同一个平台上构建、调优自己的或托管的开放权重模型，用自己的数据做 grounding，让 agent 在有强制边界的环境里运行，并保护应用、agent 与基础设施。通稿里的大词不少，但真正值得抠的只有三处：推理接口是否真的降低迁移成本、沙箱的边界到底由什么执行、以及 beta 这个词背后还缺什么。

Inference：托管的模型调用，不用自己搭整套栈

Akamai Inference 给企业提供的是对开放权重模型和定制模型的托管访问，接口兼容 OpenAI API，因此现有应用迁移时不需要重写。这是整篇通稿里对中小团队最实在的一句：接口兼容意味着调用方式可以复用，团队不必为了换一家推理供应商，就把请求构造、鉴权、错误处理全部重写一遍。但“不需要重写”不等于“不需要验证”——模型行为、输出格式细节、限流与延迟特征，仍然要按自家用例逐项跑通，接口兼容只省掉了接入层的工作，没有省掉验证层的工作。

部署方式上，Akamai 给了两个选项：无服务器的按量付费推理，或者专用部署。按量适合流量波动大、还没摸清用量曲线的团队；专用部署适合对延迟、版本控制、隔离性有硬要求的团队。通稿还提到，Akamai Cloud 提供托管数据库与对象存储，并能连接私有云与公有云平台，让模型可以调用企业数据；推理服务本身负责编排、模型执行与鉴权，请求跑在 Akamai 全球网络上，以降低延迟、保证可用性与稳定的服务水平。

上线时的模型目录包括 12 个开放权重模型，参数规模从 80 亿到 2.8 万亿不等，其中点名的有 NVIDIA Nemotron 3 Ultra、OpenAI gpt-oss-120b、Google Gemma 4，此外还包括用于检索增强生成的 embedding 模型。这个目录的意义不在于数字大，而在于跨厂商：同一个托管入口里既有 NVIDIA 的模型，也有 OpenAI 与 Google 的开放权重模型，团队选模型时可以先比效果、再定部署，而不必先被某一家供应商的栈锁死。当然，目录会不会持续更新、每个模型的具体版本与可用区如何，通稿没有展开，选型时要以实际可用的目录为准。

Agent Sandbox：代码和 agent 运行时分开跑

如果说 Inference 解决的是“怎么调用模型”，Agent Sandbox 解决的就是“代码跑在哪里、能碰到什么”。Akamai 的设计是两层分离：agent 本身跑在 Akamai Functions 上，而它写出来的代码跑在自己独立的隔离环境里，与 agent 的运行时隔开。沙箱作为 Spin 框架的开源组件交付，用 WebAssembly 隔离来设定计算、内存、出站连接与系统能力的上限。

这个分离值得单独强调。很多 agent 安全事故的根因，不是模型说了什么，而是它生成的代码在执行时拥有了和 agent 本人一样的权限：能读环境变量、能访问内网服务、能向外发请求。一旦执行环境和 agent 运行时是同一层，任何一次提示注入或错误指令，都可能直接变成一次越权操作。把“写代码的 agent”和“跑代码的环境”拆开，并用 WebAssembly 的能力模型去限制后者，等于在架构上先承认：agent 生成的代码默认不可信，必须先关进笼子，再谈它能做什么。

通稿还提到，agent 隔离正在收敛到几种模型：带快照与分叉能力的微虚拟机、策略强制的容器、WebAssembly 隔离的函数。Akamai 的做法是让开发者按工作负载选择架构：NVIDIA 加速与专用 CPU 基础设施、托管 Kubernetes、以及用于无服务器执行的 Akamai Functions，覆盖边缘与核心。这句话的潜台词是：没有一种隔离适合所有场景——需要强隔离的跑微虚拟机，需要弹性的跑函数，需要自定义环境的跑容器。选错隔离层级，和没有隔离一样危险：太松会越权，太严会让正常任务跑不起来。

GPU 与硬件：同一篇通稿里的第三条线

除了两款软件产品，通稿还宣布了 GPU 舰队的扩展：新增 NVIDIA Blackwell Ultra GPU 集群，并为明年支持 NVIDIA Vera Rubin 平台做准备。舰队里既有用于低延迟推理的 NVIDIA RTX PRO 6000 Blackwell Server Edition GPU，也有用于构建、调优与自托管模型的 Blackwell Ultra 集群。每个八卡 Blackwell Ultra 节点单卡配备 288GB HBM3e 显存，合计 2.3TB，目标工作负载是测试时扩展、思维链推理与长上下文 agent 任务。

对普通 vibe coding 团队来说，这条硬件线不是必读项，但它解释了 Akamai 的商业逻辑：托管推理与沙箱不是空中楼阁，它们跑在同一套从核心到边缘的基础设施上。通稿提到，GPU 集群让企业可以控制模型版本与退役时间线，并且在没有速率限制与共享租户排队的情况下运行。这对受模型退役时间表困扰的团队有实际意义——10 月里 GitHub 与 OpenAI 接连公布模型退役日期，已经让不少人意识到：模型版本能不能自己说了算，本身就是一种生产稳定性。

Akamai Cloud 首席运营官兼总经理 Adam Karon 在通稿里的表述，也印证了这个逻辑：客户希望在同一个平台上构建、运行并保护 AI，推理与执行层把 Akamai 的 AI 基础设施变成了完整的 AI 栈。而云技术高级副总裁 Jon Alexander 的那句话，更值得直接引用：“每个运行 agent 的团队，都需要为 agent 编写的代码划定边界。”这句话不是营销口号，它是整篇通稿唯一一句可以直接拿去当验收标准的话。

Beta 意味着什么，还缺什么

通稿在“可用性”一节写得很短：Akamai Agent Sandbox（通过 Spin SDK）与 Akamai Inference 均已进入 beta，其中推理 beta 包括无服务器部署选项；NVIDIA B300 GPU 集群的可用性需联系销售。短有短的好处——它没有把 beta 包装成正式发布。但读者也要把 beta 的含义读全：功能、限额、定价、服务等级，都可能在正式发布前变化；通稿没有公布价格表，评估时不能按正式产品的成本模型去算账。

还有两处需要区分“已交付”与“计划中”。第一，通稿说 Akamai“还计划增加”用于管理 agent 可以触达什么、什么可以触达 agent 的能力——这是未来计划，不是今天可用的控制项，评估时不能把它算进现有边界里。第二，沙箱的 WebAssembly 隔离是一种边界机制，不是安全保证：它限制了代码能用的计算、内存、出站连接与系统能力，但不能保证所有程序在任何情况下都是安全的。边界需要配合代码审查、依赖检查、密钥管理与审计日志一起用，单靠沙箱并不能替代这些。

此外，有二手报道提到推理文档称其为封闭 beta、沙箱页面提供的是申请接入的技术预览。本文以 Akamai 官方通稿的“beta”表述为准，但提醒读者：实际接入时可能需要申请或排队，不能默认“beta”等于“注册即用”。这一点在立项排期时尤其重要——如果团队的计划建立在“下周就能用上”的假设上，最好先确认接入方式再排期。

它和 Vercel durable-harness 有什么不同

本站在 10 月 21 日发过 Vercel 的 durable-harness，同样面向 agent 执行环节，容易混淆。两者的分工其实很清楚：durable-harness 解决的是“agent 崩溃后不断线、不重复烧 token”的续跑问题，重点在执行过程的韧性；Akamai Agent Sandbox 解决的是“agent 写出的代码被关在多大笼子里”的边界问题，重点在执行环境的隔离。一个管“跑得住”，一个管“跑不出去”。两个都需要，但不能互相替代：续跑做得再好，跑出去的代码照样能越权；隔离做得再严，崩溃后重跑的成本照样存在。

对 vibe coding 团队来说，这个区分可以直接变成一条检查清单：第一，你的 agent 生成的代码现在跑在哪里——是和你的开发机、服务器、生产数据库同一层，还是已经隔离？第二，它能访问哪些密钥、内网服务与出站地址——是默认全开，还是默认关闭、按需放行？第三，崩溃与超时的成本由谁承担——是重跑一次，还是断点续跑？三条里只要有一条答不上来，就说明执行环节还缺一块拼图，而 Akamai 这次发布的正是其中“边界”那一块。

判断：先补边界，再谈规模

把 Akamai 这次发布放在 2026 年 10 月的 agent 安全语境里看，它的时机并不偶然。同一个月里，既有 agent 削弱监控的自曝，也有 agent 攻击事件的报道，还有模型退役时间表的接连公布。所有这些新闻指向同一个结论：agent 已经从“帮你写代码的工具”变成了“会自己行动、会自己花钱、会自己跑代码的执行者”，而执行者的治理，才刚刚开始补课。

在这个语境下，Akamai 的产品组合有一个清晰的判断值得肯定：推理服务解决的是“用什么模型、怎么调用”，沙箱解决的是“代码跑在哪里、能碰到什么”，两者缺一不可。只谈模型，不谈边界，是把执行风险留给了用户；只谈边界，不谈推理，是把调用成本留给了用户。同时推两个 beta，至少说明厂商意识到了这两件事必须一起解决。

但肯定归肯定，验收标准不能降低。对任何打算评估这两款 beta 的团队，建议先跑三项测试：第一，用一段故意越权或访问外部地址的 agent 生成代码，验证沙箱是否真的拦住了它；第二，用自家真实的调用量与模型，验证 OpenAI 兼容接口在输出格式与延迟上是否符合预期；第三，确认 beta 的限额、定价走向与退出路径——如果 beta 结束后面向正式版的迁移成本很高，现在就要把这部分写进决策里。三项测试都通过，再谈规模化；任何一项含糊，都应该先把范围控制在实验项目里。

三项验收测试，写得再具体一点

第一项测试是越权测试。准备一段 agent 生成的代码，让它尝试读取一个不该读的环境变量、访问一个不该访问的内网地址、向一个未授权的外部地址发请求，然后看沙箱是否逐项拦住。测试时要记录三件事：哪一项被拦住了、拦住的方式是静默失败还是明确报错、报错信息里是否泄露了不该泄露的内部信息。静默失败和明确报错各有利弊，但测试者必须知道实际是哪一种，否则上线后排查问题时会无从下手。更重要的是，测试用的越权代码不能只准备一种：环境变量、文件系统、网络出站、系统调用，至少各准备一例，漏掉任何一类，都等于给那一类留了后门。

第二项测试是接口兼容测试。用自家真实的请求量、真实的提示词、真实的输出长度，去跑 OpenAI 兼容接口，核对三件事：输出格式是否和现有代码的解析逻辑一致、流式输出的断句与结束标记是否符合预期、错误码与重试行为是否和现有供应商一致。接口兼容最容易在边缘处翻车：正常请求都通，偏偏超长上下文、空输出、限流时的表现不一样。测试时要特意覆盖这些边缘，而不是只跑几条 happy path 就宣布通过。延迟也要按百分位记录，而不是只看平均值——agent 任务对尾部延迟最敏感，平均值好看、百分之九十九分位很差，实际体验照样糟糕。

第三项测试是退出与成本测试。确认 beta 结束后的迁移路径：数据、配置、模型版本、沙箱策略，能不能原样带走；如果不能，迁移成本是多少；如果 beta 期间的限额突然收紧，团队有没有降级方案。价格未公布时，不要用“beta 免费”或“beta 便宜”来做预算——按正式产品的市场价做最坏情况测算，测算结果如果仍然划算，再推进；如果只有在 beta 优惠价下才划算，就应该把范围控制在实验项目里，等正式定价出来再决策。这三项测试的共同点是：它们测的都不是厂商宣传的优点，而是团队真正要承担的风险。

给独立开发者的低成本思路

Akamai 的产品组合首先面向企业，但独立开发者也可以从中借用思路，而不必立即采购。核心思路只有一句话：agent 生成的代码，永远不要在和你的密钥、生产数据库同一层的环境里直接运行。低成本的做法有很多：本地用容器隔离执行，网络默认关闭、按需放行；密钥通过环境变量注入给受控进程，而不是写进 agent 可读的文件；所有出站请求先过一层允许名单，名单之外的地址一律拒绝。这些做法不需要买任何新产品，它们只是把 Akamai 沙箱背后的原则，用现有工具先落地。

推理侧也一样：OpenAI 兼容接口的价值在于可替换性。独立开发者在写调用层时，尽量把模型调用封装成一层薄薄的适配器：请求构造、重试、错误处理、用量统计，都放在适配器里，业务代码只依赖适配器。这样一来，未来无论换到 Akamai Inference、还是其他兼容接口的供应商，改动范围都只有一个文件。可替换性不是为了频繁换供应商，而是为了在某家供应商涨价、退役模型、收紧限额时，团队还有选择权。10 月的模型退役新闻已经证明：选择权本身，就是一种生产稳定性。

别把 beta 当成正式版来排期

最后一个提醒是关于排期的。beta 产品的正确用法是实验与验证，而不是支撑核心业务的排期锚点。如果团队的发布计划写着“等 Akamai 沙箱上线就切生产”，那就要先问一句：这个“上线”指的是 beta 可用，还是正式版可用？两者之间可能隔着功能变更、限额调整、定价公布，甚至是产品方向的修正。把核心业务押在 beta 时间表上，等于把自己的发布节奏交给了别人的实验节奏。更稳妥的做法是：beta 期间只跑实验项目与影子流量，正式版发布、定价与服务等级都明确之后，再谈生产迁移。实验期间的结论——沙箱到底拦住了什么、接口到底兼容到什么程度、成本模型到底长什么样——才是正式决策时真正有用的资产。急着在 beta 阶段宣布“已落地”，除了多一篇内部通报，没有任何实际收益。