OPL 数据空间 核心要点

你已经安装了 OPL 数据空间、接好了提供方，也完成了第一轮对话。本页介绍的是把“能聊天”变成“日常真正好用”的六件事。它们都不是强制项，但大多数用户在第一周内都会逐步碰到。

建议按顺序阅读，或者直接跳到你当前需要的部分：

1. 工具调用
2. 插件
3. 任务模型
4. 上下文管理
5. 基础 RAG
6. Open Terminal
7. 故障排查

面向团队部署？

如果你是在为多人部署 OPL 数据空间，也请一并阅读 Scaling OPL 数据空间。它关注的是 PostgreSQL、Redis、外部向量数据库、共享存储这类基础设施决策；而本页聚焦的是日常功能层面的“用得顺不顺”。

Tool calling

没有 Tool 时，LLM 只能生成文本。有了 Tool，它就可以查资料、运行代码、调用外部系统，甚至代你执行动作。

你可以把 Tool 挂到聊天或模型上，然后模型会在回答过程中自己决定：

• 是否调用工具
• 调哪个工具
• 用什么参数

OPL 数据空间 执行工具后，再把结果反馈给模型，模型继续基于新信息完成回复。

为什么先讲这个

Tool calling 是把“聊天模型”变成“agent”的关键开关。后面很多高级能力都建立在这里。

先搞清楚工具调用模式

OPL 数据空间 有两种连接模型与工具的方式，而最常见的误解是：名字叫 “Default” 的并不是今天大多数用户应该首选的模式。

大多数用户应优先使用 Native Mode

Default Mode 是历史遗留兼容模式。只要你的模型支持 function calling，通常都应改用 Native Mode。

Default Mode

这是最早的做法：把工具描述进 system prompt，再从模型自然语言回复中解析出它想调用哪个工具。它之所以还保留，是因为任何能遵循指令的模型几乎都能勉强使用它。

但它现在已经属于遗留方案：

• 会破坏 KV cache
• 更慢
• 更脆弱
• 不支持 OPL 数据空间 新的内建系统工具能力

Native Mode

在 Native 模式下，工具定义会作为结构化 schema 传给模型，模型返回结构化 tool call。它：

• 更快
• 更稳定
• 更节省 token
• 支持记忆、笔记、知识库、网页搜索、图像生成、代码解释器等新能力

你可以一次性全局设置：

管理面板 > 设置 > 模型 → 右上角 设置 → 把 Function Calling 改成 Native

也可以按模型或按聊天单独设置。

该启用哪些工具

很多用户想要的工具其实 OPL 数据空间 已经内置，只是需要打开：

• 网页搜索
• 代码执行
• 图像生成
• 记忆
• 知识库检索

常见入口：

• 网页搜索
• 图像生成
• 代码执行
• 记忆

除此之外，OPL 数据空间 社区 里还有大量社区插件，涵盖：

• 可观测性与成本追踪
• 智能家居与自动化
• 学术研究工具
• Jira / Linear / GitHub / Slack
• 数据库与内部 API
• 垂直领域工具

更多参考：

• Tools reference
• Tool-calling modes

插件

OPL 数据空间 自带很多能力，但真正的上限来自可扩展性。许多你在演示里看到的高级能力，本质上都是插件。

插件主要分为两大类：工具 与 函数。

工具

工具给模型“在回答过程中调用外部能力”的能力。

来源	作用	示例
内建工具	OPL 数据空间 自带系统工具	网页搜索、代码执行器、图像生成、记忆、笔记、知识库
自定义工具	你自己写的或从社区安装的 Python Tool	Langfuse, Home Assistant, arXiv, SQL query
工具服务端	通过 MCP / OpenAPI 接入的外部服务	微服务、第三方 API、现成 MCP 服务器

函数

函数更偏平台级，它们改的是 OPL 数据空间 自身的行为。

类型	作用	示例
管道	给模型列表增加一个“新模型入口”	模型路由、Agent loop、自定义 LLM backend
过滤器	修改请求或响应流	PII 脱敏、token 计数、Langfuse tracing
动作	在消息下方增加按钮	翻译回复、保存到知识库、消息二次处理

安装入口：

• OPL 数据空间 社区
• 直接在管理后台导入

更多参考：

• Plugin overview
• Tools reference
• Functions reference
• MCP tool servers

任务模型

很多 UI 里的“小功能”其实也要调用模型，例如：

• 自动生成聊天标题
• 自动生成标签
• 自动生成追问建议
• 输入框自动补全

默认情况下，它们会直接使用你当前聊天的主模型。这意味着：

• 成本高的旗舰模型会被拿去写“三个字标题”
• 慢模型会让 UI 变卡
• 推理型模型会为了一个简短标题思考很久

建议做法

在 管理面板 > 设置 > 界面 中单独设置任务模型。

推荐方向：

• 任务模型（外部）：选一个快、便宜、非推理型模型，例如 gpt-5-nano、gemini-2.5-flash-lite
• 任务模型（本地）：选一个很小的本地模型，例如 qwen3:1b

如果机器较弱，也可以直接关闭这些后台任务，例如：

• 自动补全生成
• 追问建议生成
• 标题生成
• 标签生成

环境变量也分别支持开关。

Context management

聊久了之后，你很可能会看到：

The prompt is too long...

这不是 OPL 数据空间 的 bug，而是你的模型提供方拒绝了超出上下文窗口的请求。

每次发送消息时，真正送给模型的是：

• system prompt
• 全部历史对话
• 已附加文件
• tool call 结果
• 你的新消息

OPL 数据空间 没有内建一个“统一裁剪器”，因为：

• 不同模型 tokenizer 不同
• 不同模型上下文窗口不同
• 不同部署对裁剪策略要求不同

推荐做法是安装一个 filter Function，按你自己的规则去裁剪。

快速入口见：

• Context Window / Prompt Too Long

Basic RAG

RAG（Retrieval-Augmented Generation）让你可以把 PDF、文档、知识材料喂给系统，再在聊天时按需检索相关片段，而不是每次都把整份文档塞进上下文。

最简单的两种用法：

1. 一次性附件：直接拖文件到聊天输入框
2. 知识库：在 工作区 > 知识库 建知识库，供多个聊天复用

默认配置足够单人轻量使用；但规模上来后，最重要的三个旋钮是：

• Embedding engine
• Content extraction engine
• Vector database

推荐起步配置

在 管理面板 > 设置 > 文档 中，一个通用起点通常是：

设置项	建议值	默认值	原因
Text Splitter	token	character	分块更稳定
Markdown Header Splitting	开	开	更尊重文档结构
Chunk Size	2000	1000	保留更多局部上下文
Chunk Overlap	200	100	降低关键信息被切断的风险
Top K	15	3	提高检索召回
Embedding Model	外部 embeddings API	本地 CPU 模型	节省内存、更适合多用户

更多参考：

• RAG overview
• 知识库工作区
• Performance tuning for RAG

Open Terminal

如果“运行一段 Python”还不够，而你希望模型真的去操作一个终端环境，例如：

• clone 仓库
• 安装依赖
• 跑测试
• 启一个网站预览
• 分析本地 CSV

那就是 Open Terminal 的用武之地。

它把一个真实 shell（默认跑在 Docker 沙箱里）作为 Tool 提供给模型。配合 Native Mode，这会让 OPL 数据空间 从“聊天 UI”变成“模型真正帮你做事的工作台”。

更多参考：

• Open Terminal
• 高级工作流用例

Troubleshooting

当你已经完成基本接入，但日常使用仍不顺时，优先回到这些问题域排查：

• Tool calling 模式是否正确
• Task model 是否过重
• Context 是否失控
• RAG 的 embeddings / extraction / vector DB 是否配置合理
• Open Terminal 是否具备足够但不过度的执行权限

这页的作用，不是列出所有功能，而是帮你先抓住最容易影响体验的几根主线。*** End Patch