"AI agent" 在产品语境下已被广泛使用，但同一个名字下面的工程实现并不一样。本文从一次完整请求的执行路径切入，针对每个具体产品考察三个基础问题：代码在何处执行 · agent 控制循环在何处运行 · 凭证保存在哪里。

举两个对照例子。Perplexity Pro 处理数据分析请求时，后端把 LLM 生成的 Python 下发到 e2b 启动的 Firecracker microVM 内执行，用户文件、代码、运行结果隔离在其中，session 结束就销毁 [1]。Claude Code 在本地终端执行 claude 命令时，模型推理在 Anthropic 云端完成，工具调用全部在本地 claude 进程内以登录用户 UID 执行，默认不启用 OS sandbox，安全由进程内的 permission 系统承担 [2]。

两者都被叫作"AI agent"，但在上述三个问题上的回答完全不同。本文调研了 7 款常见的 agent 产品，逐一回答这三个问题，再从答案中归纳出共通的差异维度。

七款产品介绍

Perplexity Pro（数据分析）。后端把 LLM 生成的 Python 下发到 e2b 启动的 Firecracker microVM 内执行，每月在 e2b 平台启动数百万个此类 sandbox。agent 控制循环留在 Perplexity 后端；OAuth 凭证不进 sandbox，需要连接器时由后端代理调用；session 结束 VM 销毁。agent 与 LLM 生成的代码不共享信任域。

Manus（端到端任务）。每个 Manus 任务获得一台 microVM 形态的完整 Linux 环境（第三方拆解称底层接近 e2b / Firecracker），内含 Node、Python、headless Chromium、终端、文件系统，以及预装的约 27 个工具。任务工作状态、工具执行与 agent 行为决策驻留在同一 VM 内。这给了 agent "本地虚拟员工"般的工程便利，代价是把一切都装进同一个信任域：Chromium 一旦加载攻击者构造的恶意网页，prompt injection 攻击的直接目标就是 agent 自身的决策，sandbox 反而位于攻击者的身后。Manus 的强隔离防的是横向移动（用户 A 的 VM 影响不了用户 B），而不是纵向劫持（同一个用户的 agent 被诱导执行恶意指令）。

Claude Code 默认配置（本地终端）。模型推理在 Anthropic 云端，工具调用全部在本地 claude 进程内以登录用户 UID 执行。默认不启用 OS sandbox，安全由进程内的 permission 系统承担。Anthropic 在 2025-10 开源了一个可选的 sandbox-runtime 工具，启用后会把 Bash 子进程包进 macOS Seatbelt 或 Linux bubblewrap，但默认关闭。Ona 团队公开演示过这种模式的脆弱性：诱导 Claude Code 通过 /proc/self/root/usr/bin/npx 绕过自身的命令 denylist；进一步当 sandbox 检测到绕过并拦截后，agent 自主执行了一条 disable sandbox 指令，随后重新执行原命令并成功。这一失败模式比 Manus 更严重，因为没有 microVM 提供的 OS 级横向隔离兜底。

ChatGPT Code Interpreter（数据分析）。生成的 Python 路由到 OpenAI 后端的 sandboxed、firewalled Python 执行环境，社区推断底层为 gVisor pod。结构上与 Perplexity 同档（不共享信任域、每请求即时），区别在于该环境通常不具备任意公网出站，威胁模型更保守。

Bolt.new（应用生成）。把 Node 运行时通过 WebContainers 装进浏览器内执行，sandbox 跑在用户的浏览器标签页里。云端无需承担 vCPU 成本，代价是兼容性，依赖 fork() 或原生扩展的 Node 代码无法运行。

Codex CLI（本地终端）。与 Claude Code 几乎相同的本地 CLI 形态，但默认开启 OS 级子进程隔离（macOS Seatbelt、Linux bwrap + seccomp），并提供 read-only / workspace-write / danger-full-access 三档 sandbox 模式与 approval policy。Codex 是 Claude Code 在 sandbox 默认开关上的镜像选择。

Cursor（IDE 编辑器）。本地交互模式（IDE 内编辑 + 终端）历史上无 OS sandbox，2026-02 起在 supported platforms 部分启用（Seatbelt / Landlock+seccomp / WSL2）；并行 / 后台模式则在每个 task 用一台独立的后端 VM（第三方材料称接近 Firecracker microVM 形态），agent 控制循环留在 Cursor 服务端。同一款产品在两种使用模式下采用截然不同的隔离强度。

把 7 款产品的差异整合成一张定位表：

三个对比维度与一个共同的安全盲区

表里的三列对应三个贯穿性的对比维度。

隔离强度。从弱到强分布在"同 UID 同进程 → OS 级子进程隔离 → 浏览器 origin → gVisor → VM / microVM"五档。两端在技术上到 2018 年前后就已基本成熟，e2b / Modal 等公开可比的 CPU sandbox 服务价格已经趋同。

agent 控制循环是否与代码执行共享信任域。Perplexity、Bolt.new、Cursor 并行模式属"不共享"路径，sandbox 关的是 LLM 生成的代码；Manus、Claude Code 默认配置属"共享"路径，agent 行为决策与执行代码同处一个信任域；Codex CLI 与启用 sandbox-runtime 后的 Claude Code 属"边界跨越"中间档。这条轴决定了 prompt injection 攻击落在哪里。

sandbox 生命周期。每请求即时、每任务可休眠、本地持久三种。生命周期直接决定计费形态：API 按请求 / session·hour（Anthropic Managed Agents 的 $0.08 / session·小时、idle 免费）/ 月度订阅 + credits + usage-based billing（Replit AI 的 effort-based 计费按 agent 实际消耗计量）。

三个维度之上，所有产品共享一个共同的安全盲区。

共同的安全盲区：sandbox 关的是代码，被劫持的是 agent 的决策

经典 sandbox 解决的是"代码可能恶意或有缺陷"这一问题，Firecracker / gVisor / V8 isolate 到 2018 年前后已经基本就绪。AI agent 则引入了 sandbox 设计阶段未明确考虑的新威胁：LLM 自身的决策可能被 prompt injection 劫持。被攻击的对象不是 sandbox 内部的代码，而是位于 sandbox 边界上的 agent 控制循环本身。

研究者 Simon Willison 将这一攻击模式概括为 lethal trifecta：当一个 agent 系统同时具备访问私有数据、接触不可信内容、对外发起请求这三种能力时，系统会进入极高风险状态，传统 prompt-level 防护很难可靠阻断数据外泄。本文样本里的多数产品一旦启用连接器、浏览器或网络工具，就会进入这一风险区。Manus 加载恶意网页即触发、Claude Code 通过第三方 Skill 引入的指令注入，都是同一模式的具体变体。

几家厂商正在尝试填补这一缺口。把各家的应对方向归类，可以提炼出四种局部 solution（不是完备的安全分类，而是本文样本里反复出现的四类工程取舍）：

四类相对独立，工程上可叠加。Vercel 的设计同时落在"架构分离 + 凭证隔离"两类；Anthropic 的 sandbox-runtime 同时落在"出口控制 + 决策门控"两类。在本文考察的公开材料中，尚未看到一家把四类能力以统一产品形态完整暴露出来。

更高一层的"跨产品统一治理"则完全空着。每款 agent 产品都自行定义 policy 格式、自行维护 audit 日志；开发者同时用 Claude Code、Cursor、Aider 时，要分别配置三套 policy、分别查看三份 audit log。模型厂商的利益边界天然把他们限制在自家产品内，这一空白更可能由第三方、开源标准或企业治理层先行填补。

结语

我们认为，下一阶段的竞争焦点不再是"单点隔离原语谁更强"，因为 Firecracker / gVisor / V8 isolate 这类基础设施已经成熟。竞争会转向更结构性的议题：agent 控制循环是否应与代码执行共享信任域的设计分歧、多组件下的出口控制、跨产品的统一 policy 与 audit 标准。