和睿盆底康复
87.08M · 2026-03-28
2026 年，随着 Manus（已被 Meta 收购）、Happycapy 等云端 AI Agent 产品的爆发，Agent 沙箱架构成为构建自主智能体的核心基础设施。本文系统性地分析了两种主流沙箱架构模式（Agent-in-Sandbox 与 Code Interpreter Sandbox），并基于业界最佳实践，提出了生产级框架的设计原则。
核心议题：
一、架构模式对比与选型
二、安全与隔离
三、高并发与基础设施
四、架构分工与边界
五、框架设计与最佳实践
OpenPerplexity 属于 Code Interpreter Sandbox（代码解释器沙箱）模式。
证据：
LLM 在服务器进程内运行 [base_agent.py:42-45] 使用 LangChain + BaseChatModel，LLM 调用发生在 FastAPI/Granian 服务器进程中。
Agent 循环在服务器进程内
[base_agent.py:83] 使用 LangGraph create_agent，规划、工具调用、反思等都在服务器进程完成。
沙箱只负责执行
[SANDBOX_SYSTEM.md:36-42] 数据流为：
【代码执行沙箱】local_storage/sandboxes/ 或 Docker /workspace/ 或 E2B /home/user/
│ execute() / execute_bash()
▼
【结果】stdout/stderr → Agent
工具调用链路
[bash_executor.py:86-94] BashExecutor 接收 SandboxExecutor，LLM 生成 tool call → 工具调用 executor.execute_bash() → 沙箱执行 → 结果返回给 LLM。
定义：
Code Interpreter Sandbox：LLM 和 Agent 在服务器进程中运行，只把代码/命令发送到沙箱执行，结果再返回给 Agent 继续推理。
| 项目 | 模式 | 简要说明 |
|---|---|---|
| Manus | Agent-in-Sandbox | 每任务一台 Firecracker microVM，Agent 完整在云 VM 内 |
| Happycapy | Agent-in-Sandbox | 浏览器内持久化容器，Agent 在容器内运行，用户看「直播」 |
| Devin 云端版 | Agent-in-Sandbox | 云端沙箱，Agent 在云电脑中自主执行 |
| Claude Code（桌面） | Code Interpreter Sandbox | Claude 在本地，代码在 OS 级沙箱（Seatbelt/Bubblewrap）执行 |
| Claude Code（云版） | 偏 Agent-in-Sandbox | 云环境更接近「给 Agent 一台云电脑」 |
| ChatGPT Code Interpreter | Code Interpreter Sandbox | GPT 在外，只把代码丢进沙箱执行 |
| Perplexity Computer | 混合 | 三层：cloud backend 编排 + E2B sandbox 执行 + cloud browser；子 agent 在沙箱内，但 orchestration 在外 |
| Perplexity Sandbox API | Code Interpreter Sandbox | 作为 Agent API 的工具，Agent 决定要执行什么，再派发到 Sandbox |
| E2B 基础 SDK | Code Interpreter Sandbox | 仅提供代码执行沙箱，不包含 Agent |
| LangChain Code Sandbox | Code Interpreter Sandbox | 外部 Agent + 代码沙箱 |
| OpenPerplexity（本项目） | Code Interpreter Sandbox | LLM/Agent 在服务器，沙箱只执行代码/命令 |
Claude Code
Perplexity Computer
若希望从 Code Interpreter Sandbox 升级到 Agent-in-Sandbox，大致需要：
当前架构（LLM 在服务器、沙箱只执行）是典型的 Code Interpreter Sandbox，与 ChatGPT Code Interpreter、LangChain Code Sandbox、E2B 基础用法等一致。
根据 2026 年行业标准（如 LangChain 的 Deep Agents 论述和 E2B/Manus 的公开架构说明），这两种模式的本质区别在于「大脑（LLM 编排）与手脚（执行环境）的距离」。
| 维度 | Agent-in-Sandbox (Manus / Happycapy) | Code Interpreter Sandbox (本项目 / ChatGPT) |
|---|---|---|
| Agent 位置 | 沙箱内部（Agent 进程在 VM/容器内跑） | 沙箱外部（Agent 在你的服务器进程跑） |
| 交互逻辑 | Agent 本地调用 Shell/文件，低延迟 | Agent 跨网络发送代码，等待沙箱返回结果 |
| 状态持久性 | 高：整个 OS 状态随任务持久化 | 低：通常仅文件持久化，进程状态易失 |
| 安全边界 | 隔离 Agent 本身（防止 Agent 逃逸） | 隔离代码执行（防止恶意代码损毁宿主） |
| 凭据管理 | API Key 需注入沙箱（风险较高） | API Key 留在服务器（更安全） |
| 典型技术 | Firecracker MicroVM / 专用 Micro-OS | Docker / gVisor / E2B SDK |
| 2026 术语 | Pattern 1: Agent IN Sandbox | Pattern 2: Sandbox as a Tool |
模式 A：Agent-in-Sandbox（全沙箱模式） 代表：Manus, Happycapy, Devin 2.0
优点：
缺点：
模式 B：Code Interpreter Sandbox（工具调用模式） 代表：OpenPerplexity, ChatGPT, Claude Code (桌面版)
优点：
rm -rf / 也不会影响主系统。execute() 即可。缺点：
该模式在长时程自主、隔离强度上叙事最强，但并非无代价。
主要缺点与解决办法
| 排序 | 缺点 | 严重度 | 解决办法（实用） | 落地难度 |
|---|---|---|---|---|
| 1 | 调试与审计难（黑箱） | 结构化 JSON 日志落 stdout；控制平面拉取沙箱日志；关键操作 HITL 审批 | 中 | |
| 2 | 成本不可预测（长任务 / 死循环） | 沙箱超时；sleep / recycle 机制；控制平面 CPU/预算阈值暂停或降级 | 低 | |
| 3 | 单沙箱崩溃影响面大 | 快照或周期性 artifact 上传对象存储；崩溃后新建沙箱并恢复关键产物 | 低–中 | |
| 4 | 镜像与模板更新复杂 | 蓝绿 / 多版本模板；新任务新模板、老任务自然退出；skills 等热加载 | 中 | |
| 5 | 过程透明度不足 | 可视化桌面（Happycapy 类）；或控制平面进度事件流 | 低–中 | |
| 6 | 数据主权与合规 | BYOC / 自托管沙箱；企业侧加密与驻留策略 | 中 |
生产向最佳实践
/output。在 2026 年的 Deep Agents 范式中，行业得出了一个重要结论："如果你想让 Agent 像人一样工作，它必须住在电脑里。"
本项目 (OpenPerplexity) 目前的定位是"高性能 AI 搜索与知识处理助手"，因此采用 Code Interpreter Sandbox 是目前最理性的架构选择。
两者均偏按量付费：Manus 以 credits 为主，Happycapy 以 Claude Code credits + 算力/存储 为主；年付常有折扣。更高档通常对应更长 sleep/更大存储与更高并发。
| 档位 | Manus Claw | Happycapy |
|---|---|---|
| Free | $0；约 300 credits/天；1 concurrent task | $0；有限 trial + 基本 sandbox |
| 入门 Pro | 约 $20–39/月；约 4000 credits/月 | 约 $20/月；约 2000 credits；2c/4GB/50GB |
| 高阶 Pro / Max | 约 $40–199/月；8000–19900+ credits | 约 $200/月；「无限」credits；4c/8GB/200GB |
沙箱与持久化影响
| 维度 | 仅运行代码 (Code Interpreter) | Agent-in-Sandbox |
|---|---|---|
| 核心逻辑 | LLM 外部生成代码 → 扔进沙箱跑 | 整个 Agent 项目完整跑在沙箱内 |
| 自主程度 | 中（多依赖外部 LLM 往返） | 高（长时程、少打断） |
| 典型流程 | 用户任务 → LLM 生成代码 → 沙箱执行 → 回传 | 启 VM/容器 → Agent 迁入 → 内循环 Plan/Execute |
只要涉及代码运行、浏览器控制、文件操作、API 调用，99% 的生产级云端 SaaS 都强制采用每个用户/每个任务一个独立沙箱。
| 维度 | 核心原因 | 无独立沙箱的风险 | 独立沙箱带来的价值 |
|---|---|---|---|
| 安全隔离 | Agent 代码不可信 | 容器逃逸、内核共享漏洞 | Firecracker 硬件级隔离 |
| 隐私与数据 | 用户文件须隔离 | 跨用户泄露、PII 暴露 | Per-user filesystem、零信任 |
| 爆破半径 | 单用户故障勿拖垮全平台 | OOM、死循环拖慢全站 | 自毁、资源限额、隔离崩溃 |
| 资源公平 | 避免「吵闹邻居」吃资源 | 全站卡顿、免费用户不可用 | Ephemeral 按需创建与回收 |
| 持久化 | 跨会话文件、context | 状态冲突、互相覆盖 | Manus sleep/恢复；Happycapy 专用存储 |
| 合规与企业 | GDPR/HIPAA 审计 | 难以上线、数据主权质疑 | 可审计、可证明隔离 |
数据主权风险：数据实际受哪国法律管辖。在 Agent-in-Sandbox 模式下，数据全程在云端运行，风险被放大。
「云电脑」类能力通常需要完整出站联网。产品侧一般用 强隔离 + Zero Trust + 出口控制。
在 Agent-in-Sandbox 模式下，为了不让用户在沙箱里偷走 API Key，推荐使用 Tool Proxy（工具代理） 模式。
sandbox_token。sandbox_token 后代为请求外部 API。控制平面代理（示意）：
@app.post("/tool/{tool_name}")
async def call_tool(tool_name: str, payload: dict, authorization: str | None = None):
# 1. 校验短命 sandbox_token (JWT 或 Redis 临时 Key)
user_ctx = verify_sandbox_token(authorization)
# 2. 从控制平面数据库取该用户的真实 Key (如 OpenAI/Google Key)
real_key = get_user_api_key(user_ctx.user_id, tool_name)
# 3. 代为请求外部 API，Key 永远不进入沙箱
return await call_external_api(tool_name, payload, api_key=real_key)
沙箱内工具（示意）：
import requests
def google_search(query: str, sandbox_token: str) -> dict:
# 沙箱内代码只知道代理地址，不知道真实 Key
r = requests.post(
"https://proxy.example.com/tool/google_search",
json={"query": query},
headers={"Authorization": f"Bearer {sandbox_token}"},
timeout=60,
)
r.raise_for_status()
return r.json()
| 模式 | 并发压力主要在哪？ | 核心逻辑 | 谁来扛？ |
|---|---|---|---|
| 纯 Agent-in-Sandbox | 沙箱创建层 (IaaS) | 压力下沉：中央服务只管"发钥匙"，Agent 在 VM 内自转 | E2B / K8s 横向扩容 |
| 混合模式 (Perplexity) | 中央 Orchestrator | 压力集中：中央服务需维持数万个活跃 HTTP/WS 连接 | 自研队列、限流、熔断 |
| Code Interpreter 式 | 共享 Executor Pool | 资源竞争：多用户抢占同一个代码执行队列 | Celery / 线程池等 |
Sandbox.create）和"收盘子"（获取结果）。虽然框架层不需要写并发代码，但系统层面仍需水平扩展：
| 维度 | Firecracker microVM | 持久化 OCI 容器 |
|---|---|---|
| 隔离机制 | KVM + 独立内核 | namespace + cgroup |
| 安全强度 | (需 gVisor 加固) | |
| 冷启动 | 约 125–150ms | 常 <50ms |
| 持久化 | Ephemeral + 智能恢复 | 原生持久卷、百 GB 工作区 |
| 可视化 | 常为 Web/App 报告 | 浏览器里「直播」操作 |
gVisor 是 Google 开源的 OCI 兼容 runtime（runsc）。它在用户空间实现了一个轻量内核（Sentry），拦截所有系统调用。Happycapy 的持久化容器通常就是 OCI 标准容器 + gVisor 安全加固。
| 维度 | 纯 Agent-in-Sandbox | 混合偏 (Perplexity) | 加强版 Code Interpreter |
|---|---|---|---|
| 运营商成本 | 约 $13–27 (边际低) | 约 $25–50+ (路由重) | 约 $12–25 |
| 高并发能力 | |||
| 基础设施 | microVM / 容器池 | Firecracker + 复杂编排 | E2B + 共享 Pool + 队列 |
| 适用场景 | 长期自动化、建站 | 企业审计、研究 | 快速原型、简单脚本 |
二者核心差在 Agent 大脑是否在沙箱内。
| 维度 | 纯 Agent-in-Sandbox (Manus) | 混合偏 (Perplexity Computer) |
|---|---|---|
| 大脑位置 | 全在沙箱 (Planner + Executor) | Orchestrator 在外，sandbox 跑子任务 |
| 启动方式 | 单次拉沙箱，箱内跑全程 | 多轮：外部分解 → 下发 → 回传 |
| 自主程度 | ||
| 延迟 | 低 (本地循环) | 中 (每步外呼 LLM) |
| 审计 | 中 (需自建日志) | (子任务级轨迹) |
选择建议：
在 2026 年的架构博弈中，Perplexity 坚持"编排在外、执行在内"的混合模式，主要基于以下四个核心考量：
非纯模式（Pattern 2 / Sandbox-as-Tool）的核心代价是 「大脑留在外面」，这在生产级 Agent 应用中会引发一系列连锁反应：
checkpoint 完美恢复。LangChain 创始人 Harrison Chase 在 2026 年初曾极力推荐 Pattern 2 (Sandbox-as-Tool)，其核心理由是：
对于 Manus、Happycapy 这种追求极致自主性的 Claw 类 Agent，Pattern 1 (Agent-in-Sandbox) 才是唯一的出路：
sleep/recycle 机制，可以在不损失状态的前提下极大地降低闲置成本。sandbox_token。最终共识：LangChain 的建议是面向"通用开发框架"的保守方案，而如果你要打造一个"数字员工"级别的 SaaS 产品，必须勇敢地拥抱 Pattern 1。
| 维度 | 控制平面 (Control Plane) | 镜像层 (Image / Framework) |
|---|---|---|
| 职责 | 谁在用、开几个、谁付钱 | 怎么干活、Agent 逻辑 |
| 隔离性 | 管跨用户隔离 (Tenant-ID) | 仅管单沙箱内逻辑 |
| 并发 | 管多沙箱横向扩展与队列 | 管单沙箱内异步/并发 |
| 生命周期 | 沙箱自毁与 Artifact 导出 | 任务执行与 状态检查点 (Checkpoints) |
在 SaaS 环境下，任务结束后的处理至关重要：
SIGTERM 或完成信号。terminating 状态前，控制平面必须执行同步逻辑。
/output 导出到 S3；/memories 增量同步到向量库；关键日志。/tmp 临时文件；未持久化的环境变量；进程内存状态。在 Agent-in-Sandbox 模式下，Agent 逻辑的更新是一个工程痛点：
| 特性 | 框架层是否需要 | 原因 |
|---|---|---|
| 高并发核心 | 不需要 | 并发靠多沙箱实例扩展 |
| 多租户隔离 | 不需要 | 隔离由沙箱 + 控制面完成 |
| 用户/计费 DB | 不需要 | 属于控制平面职责 |
| 多模型路由 | 按需 | 框架可提供接口，但策略由控制面注入 |
框架应做的优化：
数据库 100% 在控制平面层。镜像里不连数据库，只处理单次任务。
在设计 SaaS 时，绝对禁止将多个用户塞进同一个沙箱实例：
ls -R / 就能看到用户 B 的私有文件。为了兼顾开发体验与生产扩展，控制平面应支持通过 MODE 环境变量一键切换。
配置示例 (.env)：
# .env.local
MODE=local
DATABASE_URL=sqlite:///local.db
SANDBOX_PROVIDER=docker
# .env.saas
MODE=saas
DATABASE_URL=postgresql://user:pass@db.example.com
SANDBOX_PROVIDER=e2b
控制逻辑 (伪代码)：
if os.getenv("MODE") == "local":
# 本地模式：挂载磁盘，极速调试
db = SQLiteDB()
sandbox = LocalDockerRunner(mount_path="./workspace")
else:
# SaaS 模式：云端隔离，增量同步
db = PostgresDB()
sandbox = E2BRunner(template="agent-prod")
底层差异说明：
FileSystem 抽象应直接调用 OS 原生 IO。sync_on_save 或 auto_sync 机制，FileSystem 抽象层封装为远程 API 调用。在 SaaS 模式下，为了解决网络延迟带来的体验问题，业界常采用 Shadow FS 模式：
针对极高安全要求的场景（如处理核心算法、财务数据）：
stdio 或 Tool Proxy 与外界交换极少量数据。答： 框架层完全不需要考虑多租户逻辑。记忆系统的按用户隔离，不是框架层该做的事，而是控制平面在创建沙箱时负责。
| 层级 | 负责什么 | 是否需要考虑多租户 |
|---|---|---|
| 框架层 | 提供记忆系统的抽象接口和 Backend 支持 | 不需要 |
| 控制平面 | 在创建沙箱时注入用户专属配置（Prefix/Env） | 必须 |
| 沙箱实例 | 实际运行时使用注入的配置自动隔离 | 运行态隔离 |
核心思路：框架只提供带 namespace/prefix 的记忆系统，控制平面在创建沙箱时动态注入不同前缀。
框架层实现（推荐写法）：
# framework/memory.py
class AgentMemory:
def __init__(self, backend_config: dict):
# 关键：从配置中获取前缀，支持 user-id 和 assistant-id 嵌套
# 默认：user-{user_id}/assistant-{assistant_id}/
self.prefix = backend_config.get("memory_prefix", "default/")
self.backend = self._create_backend(backend_config)
def save(self, key: str, value: Any, namespace: str = "default"):
# 自动拼接前缀：实现多租户与多 Agent 隔离
full_path = f"{self.prefix}{namespace}/{key}"
self.backend.write(full_path, value)
def load(self, key: str, namespace: str = "default"):
full_path = f"{self.prefix}{namespace}/{key}"
return self.backend.read(full_path)
控制平面在创建沙箱时注入隔离（关键一步）：
# 控制平面代码（创建沙箱时）
sandbox = e2b.Sandbox.create(
template="your-agent",
env_vars={
"MEMORY_BACKEND": "s3",
"MEMORY_PREFIX": f"user-{user_id}/assistant-{assistant_id}/", # 核心：嵌套隔离
"S3_BUCKET": "agent-memories"
}
)
结果：两个用户天然完全隔离，框架代码无需修改。框架保持极简干净，以后想加新 Backend 或新功能都非常容易。
在 2026 年的 Deep Agents 架构中，记忆系统通常分为两层：
AgentMemory 抽象层异步写入，利用 prefix 实现跨沙箱隔离。问：LangChain 的 DeepAgents Backend 是不是就是解决多租户的？ 答： 绝对不是。
prefix 或 schema。在 Agent-in-Sandbox 架构中，框架层边界的清晰界定是保持系统简洁性与可扩展性的关键。这一原则已被 Manus、Happycapy 等生产级 Agent 系统实践验证。
| 特性 | 说明 | 理由 |
|---|---|---|
| user_id | 用户身份标识 | 框架无需知道"谁"在使用，只需完成任务 |
| 多租户隔离 | 跨用户的资源与数据隔离 | 隔离由沙箱物理边界 + 控制平面配置注入保障 |
| TAURI / SaaS 部署模式 | 本地桌面 vs 云端 SaaS | 框架一旦感知部署模式会迅速变重、变复杂 |
| 跨用户限流 | 全局流控、配额管理 | 属于控制平面的资源调度职责 |
核心理由：这些都是控制平面的责任。框架一旦开始感知 user_id 或部署模式，就会迅速变重、变复杂，违背「保持框架干净」的核心原则。
| 职责 | 具体内容 | 目标 |
|---|---|---|
| 单沙箱内的资源管理 | 内存限额、文件清理、临时目录管理 | 让单个 Agent 不会自己把自己搞崩 |
| 单沙箱内的性能优化 | 启动加速（lazy import）、执行缓存、增量计算 | 把单次任务跑得又快又省 |
| 单沙箱内的自我保护 | 熔断、限流、内存监控、超时中断 | 避免死循环或资源耗尽拖垮沙箱 |
| 提供最佳实践 | 预设配置方案、推荐架构模式 | 降低开发者接入门槛 |
除了上述核心职责，以下 4 点虽然容易被忽略，但在生产环境中非常关键：
| 特性 | 说明 | 价值 |
|---|---|---|
| 清晰的生命周期钩子 | on_task_start、on_task_complete、on_low_memory、on_error | 控制平面可轻松实现快照、结果导出、告警 |
| 结构化日志 + 可观测性 | 强制输出 JSON 格式日志（带 step、tool、token_usage 等字段） | 便于控制平面实时拉取和监控 |
| 可配置的 Backend 前缀支持 | 记忆系统、文件系统必须支持 memory_prefix / storage_prefix 配置 | 不是多租户，而是单沙箱内的可扩展性 |
| 资源使用报告机制 | Agent 结束时自动输出 resource_report.json（耗时、峰值内存、token 数等） | 方便控制平面计费和优化 |
核心理念：框架在设计时，主动提供几套开箱即用的"最佳配置模板"，让开发者不需要从零开始研究，就能直接拿到生产可用的推荐方案。
必要性分析：
设计原则：预设方案不是强制要求，而是"框架送给用户的礼物"——用户可以直接 use_preset("recommended") 得到优化配置，同时保留完全自定义的能力。
推荐实现的五大预设方案：
1. 内存优化预设（最重要）
适用场景：资源受限的沙箱环境，需要在有限内存下稳定运行。
# 使用方式
agent = create_agent(preset="memory-optimized")
# 框架内部实现
PRESETS = {
"memory-optimized": {
"memory_backend": "filesystem",
"max_memory_mb": 400,
"auto_gc": True, # 自动垃圾回收
"lazy_load_tools": True, # 工具按需加载
"context_window_limit": 8000 # 限制上下文长度
}
}
2. 生产级日志预设
适用场景：需要接入监控系统、追踪 Agent 行为的生产环境。
agent = create_agent(preset="production-log")
# 效果
# - 自动输出结构化 JSON 日志到 stdout
# - 包含 step、token_usage、tool_name、timestamp
# - 支持实时推送给控制平面
# - 符合 ELK/Prometheus 采集标准
3. 长期记忆预设（最常用）
适用场景：需要跨会话记忆、用户偏好学习的智能体。
agent = create_agent(preset="long-term-memory")
# 内部自动配置
{
"memory_backend": "s3", # 或 postgres
"memory_prefix": "memories/", # 留给控制平面注入 user_id
"auto_save_interval": 300, # 每5分钟自动保存
"memory_compression": True, # 自动压缩历史记忆
"semantic_index": "vector_db" # 启用语义检索
}
4. 自我保护预设（防止沙箱爆炸）
适用场景：不可信的用户输入、需要严格资源控制的环境。
agent = create_agent(preset="safe-mode")
# 包含
{
"max_steps": 50, # 最大执行步数限制
"memory_threshold_mb": 512, # 内存上限触发熔断
"timeout_per_step_sec": 30, # 单步超时时间
"loop_detection": True, # 死循环自动检测
"sandbox_isolation": "strict" # 严格沙箱隔离
}
5. 本地极简预设（开发友好）
适用场景：个人开发者本地调试、快速原型验证。
agent = create_agent(preset="local-light")
# 特点
{
"memory_backend": "in-memory", # 内存后端，无需外部依赖
"log_level": "INFO", # 简洁日志
"auto_install_deps": True, # 自动安装缺失依赖
"fast_startup": True, # 跳过非必要初始化
"minimal_tools": True # 仅加载核心工具
}
预设方案对比
| 预设名称 | 适用场景 | 内存占用 | 启动速度 | 功能完整度 |
|---|---|---|---|---|
| memory-optimized | 资源受限环境 | |||
| production-log | 生产监控 | |||
| long-term-memory | 跨会话智能体 | |||
| safe-mode | 不可信输入 | |||
| local-light | 本地开发 |
实现建议：
preset 参数，用户一行代码即可切换presets=["memory-optimized", "production-log"]代码示例（框架实现）：
# framework/presets.py
PRESETS = {
"memory-optimized": {...},
"production-log": {...},
"long-term-memory": {...},
"safe-mode": {...},
"local-light": {...}
}
def create_agent(preset: str | list[str] = None, **custom_config):
config = {}
# 加载预设
if preset:
presets = [preset] if isinstance(preset, str) else preset
for p in presets:
config.update(PRESETS[p])
# 用户自定义配置覆盖预设
config.update(custom_config)
return Agent(config)
最佳实践总结：框架层强烈推荐实现以上五个预设方案，既能显著降低用户接入成本，又为控制平面集成提供标准化接口。这是框架从"能用"到"好用"的关键一步。
经过对 Manus、Happycapy、Perplexity 等生产级系统的深度分析，以及对 LangChain DeepAgents 架构的反复商榷，我们得出以下框架设计的最终指导思想：
| 层级 | 职责 | 实现方式 |
|---|---|---|
| 框架层 | 提供能力（记忆、工具、规划） | 单沙箱单用户语义；提供 prefix/namespace 配置支持 |
| 控制平面 | 隔离与调度 | 创建沙箱时注入 user_id 对应的 prefix/env；管理多沙箱并发与队列 |
| 沙箱实例 | 执行任务 | 使用注入的配置自动隔离；输出结构化日志与资源报告 |
这个设计思想已经被验证，和 Manus / Happycapy 实际采用的思路高度一致：
本文深入分析了 Agent 沙箱的两种主流架构模式，并基于 Manus、Happycapy、Perplexity 等生产级系统的实践，提炼出以下核心结论：
模式选型：Agent-in-Sandbox 适合"数字员工"级别的自主智能体（>50 步复杂任务），Code Interpreter Sandbox 适合"AI 助手"级别的辅助工具（<10 步代码执行）。
高并发真相：纯 Agent-in-Sandbox 通过"压力下沉"实现数万并发，中央控制平面极轻；混合模式则需自研复杂的队列、限流、熔断机制。
框架边界：框架层只管单沙箱内的"怎么干活"，完全不感知 user_id、多租户、部署模式等控制平面职责。记忆系统隔离通过 prefix 注入实现，无需框架层修改。
安全工程化：通过 Tool Proxy 模式、BYOC 部署、出口控制等手段，在"极致自主性"与"安全可控"之间取得平衡。
生产级要素：生命周期钩子、结构化日志、Backend 前缀支持、资源使用报告是框架从"能用"到"好用"的关键。
预设方案最佳实践：框架应提供五大开箱即用的配置模板（memory-optimized、production-log、long-term-memory、safe-mode、local-light），大幅降低开发者接入门槛，同时为控制平面集成提供标准化接口。
最终指导思想：把单个沙箱内的 Agent 做到极致（快、省、稳、好调试），控制平面负责多租户隔离与全局调度。职责分离、边界清晰，是构建可扩展 Agent SaaS 的基石。
声明：文中定价、速率限制等数据为 2026 年 3 月口径，引用前请以各厂商最新文档为准。本文侧重架构分析与设计原则，不涉及具体商业推荐。
