建一个企业知识库做 RAG 问答，从零自研要解决文档解析、向量化、检索、Rerank、多租户隔离一连串问题。阿里云 Tablestore 把这些做成了托管的知识库服务，并提供多种接入方式适配不同团队——有开发能力的直接用 SDK，要可视化管理的用 AgentRun，已用 Dify 的外接进来，要让知识在多个 Agent 间流动的用 Skills。下面把这四种方式拆开，讲清各自适合谁、怎么接。
先看 API 结构
知识库提供三类 API，覆盖从创建到精细化管理的完整生命周期，全部走 SDK 调用、请求响应都是 JSON。
- 知识库管理：创建、配置、删除知识库，设定 Embedding 模型、检索策略、元数据结构等基础配置。
- 文档管理：上传、解析、索引文档，文档状态会从「索引中」变为「已完成」。
- Chunk 管理：对文档切片做精细化管理。
最核心的是 Retrieve 检索接口，根据自然语言查询检索相关文档切片。关键参数：knowledgeBaseName（目标知识库）、retrievalQuery（检索查询，TEXT 类型，最长 128 字符）、retrievalConfiguration（覆盖默认检索配置：searchType、向量/全文检索数量、Rerank 策略）、subspace（支持多值联合检索，最多 32 个，做多租户隔离）、filter（Metadata 过滤，支持多种算子）。响应每条结果含 docId、chunkId、score（相关性得分）、content（切片文本）、subspace、metadata。理解这几个参数，四种接入方式的差异就好懂了。
方式一：SDK 接入
适合有开发能力、想把知识库集成进自有应用的用户。接入五步：开通 Tablestore 服务（目前支持北京、中国香港，其他地域陆续开服）→ 控制台一键授权访问 OSS（用于读原始文档和存解析中间结果）→ 准备 AccessKey ID/Secret → pip install tablestore-agent-storage → 创建知识库上传文档检索，最少 4 行核心代码跑通。需要自定义 Embedding 模型、检索策略、元数据过滤时，创建知识库时传入完整配置即可。这是自由度最高的方式，也是其他三种方式底层走的同一套服务。
方式二：AgentRun
适合想通过可视化界面快速建库和管理的用户。AgentRun 是以高代码为核心、开放生态的一站式 Agentic AI 基础设施平台。流程：登录控制台一键完成权限配置 → 创建知识库（自动配置下输入知识库名称即可，可定制描述、标签、Embedding 模型、Metadata、检索配置）→ 上传文档等状态变「已完成」→ 创建知识库助手关联到 Tablestore 知识库 → 集成进 Agent 智能体做问答。适合不想写代码、但要快速搭一套带 Agent 的知识库问答的团队。
方式三：Dify 外接 Tablestore
适合已用 Dify 构建 AI 应用、想把 Tablestore 知识库作为外部知识源接入的团队——不迁移数据，直接在 Dify 工作流里检索 Tablestore 内容做 RAG。前提是已用方式一或二建好知识库并上传文档，且已部署 Dify（支持 Docker 或计算巢部署）。
接入五步：
- 安装插件配 API 端点：Dify 插件市场搜 Tablestore 安装，进插件详情新增端点配置，填 Endpoint、Instance Name、AccessKey 等。生成 URL 后复制并删掉末尾的
/retrieval后缀，再按部署环境替换 host：Docker 部署换成host.docker.internal，计算巢换成ack-dify-plugin-daemon，其他换成 dify-plugin 服务实际 IP/域名。 - 注册外部知识库 API：Dify 知识库页面点「外部知识库 API」，填上一步的 URL 和 API Key。
- 连接外部知识库：选刚注册的 API，填外部知识库 ID——这里要填 Tablestore 里的知识库名称（即 knowledgeBaseName）。
- 召回测试：验证 Dify 能否通过插件正确检索到相关内容。
- 工作流使用：创建工作流加「知识检索」节点关联外部知识库，用户提问时自动检索切片作为上下文传给 LLM。
这种方式的价值是不改原有 Dify 技术栈、不迁数据就能用上 Tablestore 的检索能力，适合已重度使用 Dify 的团队。
方式四：Agent Skills 与 Dashboard
适合想让知识在多个 Agent 间流动、统一管理的团队。把知识库封装成 Skills，多个 Agent 共享同一套知识源，避免每个 Agent 各存一份。适合做多 Agent 协作、知识需要在 Agent 间传递的场景。
检索效果与性能
选知识库方案最关键的是检索效果和性能。基于多个公开数据集（CMRC2018 中文阅读理解、SQuAD 英文阅读理解、C-MTEB T2Retrieval 中文综合检索）和自定义数据集，用开源评测框架 RAGAS，与自建 RAGFlow 方案做系统对比（TopK、Rerank、Embedding 配置一致）：
- 检索延迟：Tablestore 知识库服务单路查询延迟相比自建 RAGFlow 降低约 70%。
- 检索质量：四个数据集各项指标均达到或优于自建 RAGFlow。
性能优势来自 Tablestore 内置全文索引、无需额外维护中文分词组件、分布式架构水平扩展。这意味着在大规模知识库下不会出现慢查询，运维成本也显著下降。
怎么选
四种方式不是非此即彼，按团队情况对号入座：
- 有开发团队、要深度定制、知识库是产品核心模块：SDK 接入，自由度最高。
- 不想写代码、要快速搭一套带 Agent 的问答：AgentRun 可视化建库。
- 已用 Dify、不想换技术栈：Dify 外接，不迁数据。
- 多 Agent 协作、知识要跨 Agent 共享：Skills 方案。
底层的检索能力、多租户隔离、性能是一致的，差别只在接入形态和可控程度。Tablestore 用 Subspace 机制做多租户严格数据隔离和性能隔离，按量付费的 Serverless 模式把单用户边际成本压到很低——这对网盘类、控制台类多租户场景尤其关键，是自建方案很难同时兼顾规模、成本和隔离的根源。
接入知识库不必从零造轮子，先确认团队的技术栈和定制诉求，选对方式，剩下的文档解析、向量化、检索、Rerank、隔离这些麻烦事托管服务已经处理好。