代码执行
OPL 数据空间直接在聊天界面中提供强大的代码执行能力，让你无需离开平台就能把想法变成可执行结果。
核心特性
- Code Interpreter 能力：允许模型在响应过程中自主编写并执行 Python 代码。在 Native（Agentic）Mode 下通过
execute_code工具运行，这也是当前唯一受支持的工具调用模式。旧版 Default Mode 曾有基于 XML 的集成，但不再受支持，新部署应使用 Native Mode。 - Python 代码执行：可通过 Pyodide 在浏览器中运行 Python，或通过 Jupyter 在服务器上执行。支持
pandas、matplotlib等常用库，几乎无需额外准备。 - MermaidJS 渲染：可以直接在聊天中生成并渲染流程图、关系图、饼图等 MermaidJS 图表。
- Interactive Artifacts：可在对话中生成和交互 HTML 页面、SVG 图形、JavaScript 可视化等富内容。
- Open Terminal：可把远程 shell 执行 API 作为工具接入，实现完整的系统级访问，例如执行任意命令、安装包、管理隔离容器中的文件。
这些能力把“对话”和“实现”之间的距离显著缩短，让你在和模型聊天时就能完成数据分析、可视化、原型生成和思路验证。
如何选择代码执行后端
OPL 数据空间支持多个代码执行后端，适合不同场景。你需要根据需求选择：轻量浏览器执行、完整 Python 环境，还是不受限的 shell 访问。
Pyodide（默认）
Pyodide 通过 WebAssembly 在浏览器中运行 Python。它具有沙箱隔离，适合多用户环境，但也存在一些约束：
- 持久化文件存储：虚拟文件系统
/mnt/uploads/由 IndexedDB（IDBFS）支持，文件可在同一会话的多次执行间保留，也能在刷新页面后继续存在。 - 内建文件浏览器：启用 Code Interpreter 后，聊天控制侧栏会出现文件浏览器面板，支持浏览、预览、上传、下载和删除文件。
- 用户文件访问：聊天中上传的文件会在代码执行前自动放入
/mnt/uploads/，模型和你的代码都可直接读取。 - 库支持有限：仅 提供部分 Python 包。依赖 C 扩展或系统调用的库通常不可用。
- 无 shell 访问：不能运行 shell 命令、安装额外系统包，也不能直接访问操作系统。
Pyodide 很适合文本分析、哈希计算、图表生成、文件处理等自包含任务。像 matplotlib 这类图表库会输出 base64 编码图片， OPL 数据空间会自动捕获、上传并注入图片链接，因此模型无需额外配置就能在聊天中直接显示图表。
Pyodide 在浏览器中通过 WebAssembly 运行 Python。AI 无法安装超出内建清单之外的额外库，导入不受支持的包会直接失败。执行速度也明显慢于原生 Python，大数据集或高 CPU 任务可能触发浏览器内存限制。Pyodide 最适合基础文件分析、简单计算、文本处理和图表生成。如果任务更重，应改用 Open Terminal，它提供原生性能和不受限的包访问能力。
当前可用库包括：micropip、requests、beautifulsoup4、numpy、pandas、matplotlib、seaborn、scikit-learn、scipy、regex、sympy、tiktoken、pytz，以及 Python 标准库。运行时不能安装其他库。
Code Interpreter 开关和 Open Terminal 开关不能同时开启。启用其中一个会自动关闭另一个，因为它们承担的是相似职责，但使用的是不同执行后端。
Jupyter（旧版）
Jupyter 现已被视为旧版代码执行引擎。大多数场景推荐使用 Pyodide；需要完整服务端执行能力时推荐使用 Open Terminal。未来版本中 Jupyter 支持可能会被废弃。
Jupyter 提供完整 Python 环境，几乎可以处理所有任务，包括创建文件、安装包和使用复杂库。但它在共享部署中存在明显问题：
- 共享环境：所有用户共享同一 Python runtime 和文件系统。
- 默认不隔离：如果没有谨慎配置，用户可能访问系统资源或其他用户数据。
- 并非为多租户设计：Jupyter 原本更适合单用户工作流。
如果你运行的是多用户或组织化部署，不推荐把 Jupyter 作为代码执行后端。 OPL 数据空间的 Jupyter 集成连接到的是单个共享实例，没有按用户隔离。Jupyter 更适合单用户、开发环境或受信任用户场景。
Open Terminal
Open Terminal 是一个轻量 API，用于在 Docker 容器中远程执行 shell 命令。它提供完整的系统级访问能力，可以运行任意语言、任意工具和 shell 命令，并通过容器实现隔离。
- 完整 shell 访问：模型可以安装包、执行任意语言脚本，使用
ffmpeg、git、curl等系统工具。 - 容器级隔离：运行在独立 Docker 容器中，与 OPL 数据空间和其他服务隔离。
- 丰富的预装工具：镜像通常自带 Python 3.12、数据科学库、构建工具、网络工具等。
- 内建文件浏览器：可在聊天控制面板中浏览、预览、创建、删除、上传和下载文件。
- 内建多用户模式：单个容器可服务多个用户，并通过 Linux 账户实现隔离；适合小团队，不太适合大规模部署。
完整文档见 Open Terminal integration guide。
Terminals（多租户编排层）
Terminals 是一层多租户编排器，用于按用户创建和管理 隔离的 Open Terminal 容器。如果说 Open Terminal 是单实例执行层，那么 Terminals 则是面向规模化的生命周期管理层，负责创建、路由、空闲清理和回收。它需要 enterprise license。
- 每用户一个容器：每位用户拥有独立容器、文件系统、进程和资源，不共享 kernel 或进程空间。
- 自动生命周期管理：首次请求时创建容器，空闲超时后自动停止和清理。
- 多后端支持：可运行在 Docker、Kubernetes、本地 subprocess，或 static 代理模式。
- 透明路由：所有 Open Terminal API 都可从
/terminals/访问，系统会根据X-User-Id路由到正确用户容器。 - 面向企业：支持 PostgreSQL 保存租户状态、JWT 鉴权、审计日志、SIEM webhook 和加密 API key 存储。
- 管理面板：提供用于租户管理和实例监控的内建前端。
Terminals 仍在积极开发中，还不适合生产环境。API、配置和功能都可能随时变化。
Terminals 使用的是 OPL 数据空间 Enterprise License，并非 MIT。
对比
| 考量 | Pyodide | Jupyter（旧版） | Open Terminal | Terminals |
|---|---|---|---|---|
| 运行位置 | 浏览器（WebAssembly） | 服务器（Python kernel） | 服务器（Docker 容器） | 服务器（编排容器） |
| 库支持 | 有限子集 | 完整 Python 生态 | 完整 OS 级能力 | 完整 OS 级能力 |
| Shell 访问 | ❌ 无 | ⚠️ 有限 | ✅ 完整 | ✅ 完整 |
| 文件持久化 | ✅ IDBFS | ✅ 共享文件系统 | ✅ 容器文件系统 | ✅ 每用户持久卷 |
| 文件浏览器 | ✅ 内建 | ❌ 无 | ✅ 内建 | ✅ 内建 |
| 用户文件访问 | ✅ 自动挂载到 /mnt/uploads/ | ❌ 需手动处理 | ✅ 可直接访问 | ✅ 可直接访问 |
| 隔离性 | ✅ 浏览器沙箱 | ❌ 共享环境 | ✅ 容器级 | ✅ 每用户容器级 |
| 多用户安全性 | ✅ 天然按用户隔离 | ⚠️ 不隔离 | ℹ️ 小团队可用 | ✅ 真正多租户 |
| 文件生成能力 | ✅ 写入 /mnt/uploads/ | ✅ 完整支持 | ✅ 完整支持 | ✅ 完整支持 |
| 部署复杂度 | 无 | 管理员全局配置 | 原生集成 | 独立服务 |
| 组织部署推荐度 | ✅ 安全默认 | ❌ 不推荐 | ℹ️ 适合小团队 | ✅ 为多租户设计 |
| 企业扩展性 | ✅ 客户端侧，无服务端负载 | ❌ 单共享实例 | ℹ️ 单容器共享资源 | ✅ 可水平扩展 |
| 空闲管理 | N/A | N/A | N/A | ✅ 自动停止 |
| 许可证 | MIT | MIT | MIT | Enterprise |