最近阿里云发布了知识存储 skill，号称让智能体拥有企业级知识库，我试着装了下，并且把本地500多份白皮书文档放了进去。

我按一次真实落地的过程来讲一下这个Tablestore知识库：

• • 这个阿里云知识库方案到底是什么
• • 在 Codex 里如何安装和配置
• • 数据安全边界在哪里
• • 大概怎么收费
• • 它和本地知识库方案怎么取舍
• • 实操中踩了哪些坑

先说结论：如果你的知识库面向团队使用、文档量持续增长、需要云端稳定检索和后续工程化接入，Tablestore 这类云知识库方案是省运维的；如果你的数据极度敏感、必须离线、或者只是个人小规模资料库，本地知识库仍然更合适。

1. 这个方案是什么

这套方案的核心是一个比较标准的 RAG 知识库链路：

本地文档目录
  ↓
上传到 OSS
  ↓
Tablestore 知识库导入文档
  ↓
文档切片、向量化、索引
  ↓
基于向量检索 + 全文检索召回内容
  ↓
再交给大模型组织回答

在这次实验里，我使用的是阿里云 Tablestore 知识库 Skill，名称是：

alibabacloud-tablestore-Agent-storage

它本质上不是“一个已经装好内容的现成知识库”，而是给 Agent 用的企业级 RAG 知识库存储与检索能力封装。背后主要依赖 tablestore-agent-storage Python SDK，把知识库创建、文档导入、解析切片、向量化、索引构建和检索查询这些步骤包装成 Agent 可以调用的工作流。

它解决的问题很直接：你不用自己搭 Milvus、Elasticsearch、文档解析服务、向量化服务和索引任务。Agent 可以通过这个 Skill 在阿里云 Tablestore 上创建知识库，上传本地文档，或者接入 OSS 上已有的文档，然后让云端完成解析、切片、向量化、索引，再做语义检索或“向量检索 + 全文检索”的混合检索。

这套能力可以粗略拆成几类：

这套能力里有三个关键角色：

接入前需要满足几个条件：

1. 1. 开通阿里云表格存储 Tablestore。
2. 2. 配置 OSS 授权，因为文档上传、导入和解析会涉及 OSS 存储。
3. 3. 选择支持知识库能力的地域。官方快速开始文档里显示的支持地域包括华北 2（北京）和中国香港；实际可用地域建议以控制台和最新文档为准。
4. 4. Python 侧使用 tablestore-agent-storage SDK，官方示例里通过 AgentStorageClient 创建知识库、上传文档和发起检索。

用一句话概括：OSS 放原文，Tablestore 管知识库和索引，向量模型负责让机器“理解”文本相似度，而 alibabacloud-tablestore-agent-storage 这个 Skill 则把这些云服务能力封装成 Agent 可以直接调用的一套知识库工作流。

2. 我这次实际搭建了什么

我的本地目录是：

/Users/sunchx/Desktop/白皮书

里面主要是 PDF、Word 和少量文本文件。最后配置成一个云端知识库：

3. 安装和配置过程

我是在 Codex 里安装了一个 skill（openclaw和Hermes同理）：

https://github.com/aliyun/alibabacloud-aiops-skills/blob/master/skills/storage/ots/alibabacloud-tablestore-agent-storage/SKILL.md

安装交给codex就行：

这里要注意一点：不要把 AccessKey 明文写进项目。我的做法是使用阿里云默认凭证链：

{
  "credential_source": "default_chain",
  "access_key_id": "",
  "access_key_secret": "",
  "sts_token": ""
}

完整步骤大概是：

1. 1. 准备阿里云凭证，建议使用 RAM 用户或临时凭证，不建议用主账号长期 AK。
2. 2. 选择地域。本次使用北京，因为知识库能力可用。
3. 3. 创建或连接 Tablestore 实例。
4. 4. 创建知识库。
5. 5. 创建 OSS Bucket。
6. 6. 授权 AliyunOTSAccessingOSSRole，让 Tablestore 可以读取 OSS 中的文档。
7. 7. 绑定本地目录，生成同步脚本。
8. 8. 执行同步脚本，把本地文件上传到 OSS 并导入知识库。
9. 9. 查询文档状态，等待 pending / indexing 变成 completed。
10. 10. 用 retrieve 做一次真实检索。

跑完后，就可以直接检索知识库。比如我问：

人工智能在企业中哪些成熟场景？

知识库能召回智能客服、企业知识库、营销销售、办公协同、数据分析、制造业质检、设备维护、供应链优化等相关资料片段。

4. 数据安全吗？阿里云会看到我的数据吗？

只要你使用这类云端知识库，数据就会上传到阿里云相关服务中。本次链路里，原始文件会进入 OSS，文档内容会被 Tablestore 知识库处理、切片、索引，并调用向量模型生成 embedding。

所以它不是“本地私有知识库”。它是“云端托管知识库”。

但这不等于“阿里云员工可以随便看你的数据”。云服务通常是责任共担模型：云厂商提供访问控制、传输加密、落盘加密、审计、VPC、RAM 权限等能力；用户要正确配置权限、密钥、网络边界和数据分级。

从官方能力看，Tablestore 支持这些安全机制：

• • RAM / STS 权限控制
• • Network ACL、Instance Policy 等访问控制
• • TLS 传输加密
• • KMS 或 BYOK 数据落盘加密
• • VPC 网络隔离
• • 操作审计、监控日志

OSS 也支持服务端加密、权限策略、Bucket Policy、RAM 授权等机制。

我的判断是：

一句话：云方案可以做到“工程上可控的安全”，但不能满足“数据完全不离开本地”的要求。

5. 怎么收费？

这类知识库不是一个单一账单项，它通常由几部分费用组成：

阿里云百炼知识库计费文档里提到，知识库相关的向量、排序模型调用按输入 Token 计费，文档中给出的 text-embedding-v4 和 qwen3-rerank 参考价格是 0.0005 元/千 Token。实际价格要以控制台最新计费页为准。

对个人或小团队来说，最容易忽略的不是 OSS 存储，而是这三类：

1. 1. 大量文档首次导入时的 embedding token
2. 2. 高频检索时的 embedding / rerank token
3. 3. 后续大模型回答时的推理 token

如果只是几百份公开 PDF，成本通常不会太夸张；如果是几十万篇文档，并且每天大量查询，就必须做成本监控和缓存策略。

6. 和本地知识库方案怎么比

本地知识库一般是这样的架构：

本地文件
  ↓
本地解析 / 切片
  ↓
本地 embedding 模型
  ↓
本地向量库：FAISS / Chroma / LanceDB / Qdrant
  ↓
本地或远程大模型问答

两者差异很明显：

如果只看“能不能问文档”，本地方案当然也能做。但如果要考虑团队共享、权限、稳定性、后续和业务系统集成，云方案的工程优势会更明显。

反过来，如果你的核心诉求是“资料绝不能出本机”，那云方案再方便也不该选。

7. 我的推荐取舍

我会按这四个问题判断：

第一，数据能不能上云？

如果不能，直接本地。不要绕。

第二，使用者是一个人还是一个团队？

一个人做资料检索，本地就够。多人共享、跨设备、接业务系统，云方案更省心。

第三，文档规模会不会持续变大？

几十份文档，本地最简单。几千、几万份文档，云端托管的索引、存储、监控优势开始明显。

第四，是否需要工程化接入？

如果只是聊天式问答，本地工具足够。如果要嵌入客服、运营、销售、研发平台，云知识库更容易成为基础设施。

我的建议是：

9. 使用感受

过去做知识库，很多精力会花在基础设施上：

• • 文件怎么同步
• • PDF 怎么解析
• • 向量库怎么部署
• • embedding 怎么跑
• • 索引失败怎么重试
• • 多人访问怎么管

云知识库的价值，就是把这部分“地基工程”托管掉。你依然要理解 RAG 的基本原理，也要做好文档治理和权限控制，但不需要从零维护一整套向量检索基础设施。

不过它也有代价：数据进入云端，成本变成按量，服务边界由云厂商定义。工程上省心，不代表架构上无脑。

所以我更愿意把它看成一种选择：

本地知识库解决“我的资料我自己问”；云知识库解决“团队和业务系统稳定地用知识”。

如果目标是个人知识管理，本地化依然很香。

如果目标是企业 AI 应用，云端知识库会更像一块可以长期复用的基础设施。