AI知识库 + AI Agent：为什么RAG是Agent的大脑资料库

摘要： 先建知识库再谈Agent

关键词： Agent知识库、RAG Agent、AI知识库、RAG教程、跨境电商AI、亚马逊运营知识库

系列定位： AI Agent完整教程，第 07 篇

核心观点： RAG 不是“把文件丢给 AI”这么简单，而是把公司资料整理成可检索、可引用、可更新、可审计的知识库，让 Agent 在行动前先查事实，再生成建议，再标注人工确认点。

---

很多卖家用 AI Agent，第一周觉得很惊艳，第二周就开始失望。

原因通常不是模型突然变笨。

而是 AI 没有读过你的资料。

它不知道这个 SKU 的真实尺寸。

不知道欧洲站和美国站售后规则不同。

不知道某个产品不能写“medical grade”。

不知道客服遇到差评暗示时不能引导评价。

不知道你去年 Prime Day 亏钱，是因为库存断货后广告还在跑。

不知道供应商已经改过包装，但旧版说明书还在网盘里。

于是它会给出一堆看似合理、实际危险的建议。

Agent 的执行力来自工具，但业务判断力来自知识库。没有知识库的 Agent，只是一个行动速度更快的猜测器。

这篇文章讲的 RAG，就是解决这个问题的。

RAG 全称 Retrieval-Augmented Generation，通常翻译成检索增强生成。

但卖家不用被术语吓住。

你可以把它理解成：

让 Agent 在回答和执行前，先去查你的产品资料、SOP、品牌规则、历史复盘和业务数据，再基于查到的资料输出结果。

关键不只是“查资料”，而是资料要能被正确查到、引用、更新和复核。

一句话理解 RAG：先查资料，再让 AI 说话

普通聊天 AI 的工作方式是：

用户提问。

模型根据训练知识和当前上下文回答。

RAG 的工作方式是：

用户提问或发起任务。

系统先从知识库检索相关资料。

再把检索到的资料交给模型。

模型基于这些资料回答、分析或生成建议。

OpenAI Retrieval 文档把 retrieval 描述为由 vector stores 支持，vector stores 作为数据索引，让系统可以做语义搜索。LangChain retrieval 文档也说，RAG 的基础是检索：在提问时获取相关外部知识，用上下文信息增强 LLM 的回答。

这对卖家来说很直观。

你不应该让 AI 凭经验回答：

“这款产品可以怎么写五点？”

你应该让它先查：

• 产品参数。
• 适配型号。
• 材质和尺寸。
• 禁用词。
• 竞品差评。
• 品牌语气。
• 平台合规规则。

再让它生成五点草稿。

这样输出才有业务依据。

RAG 为什么对 Agent 比对聊天机器人更重要

聊天机器人答错了，最多是建议不准。

Agent 答错了，可能会继续调用工具，把错误变成动作。

这就是风险差别。

比如客服 Agent 没有查售后 SOP，直接回复买家：

“我们可以免费补发。”

这不是文案问题。

这可能变成真实成本和政策风险。

广告 Agent 没有查库存，看到某关键词转化好，就建议加预算。

但如果 SKU 只剩 10 件库存，这个建议可能是错的。

Listing Agent 没有查产品资料，看到竞品差评里有人抱怨“不防水”，就把“防水”写进我方卖点。

如果产品没有防水认证，这就是合规风险。

所以 Agent 执行前更需要 RAG。

RAG 是 Agent 的事实检查层。

它不保证 Agent 永远正确，但能显著减少凭空猜测，并让结果有资料可追。

RAG 的完整流程：不是一个向量库就完了

很多人以为 RAG 就是：

把文件上传。

系统自动切块。

存进向量库。

然后问答。

这只是最基础版本。

一个商用 RAG 至少包括 8 个环节。

1. 资料收集

先决定哪些资料可以进入知识库。

对卖家来说，常见资料包括：

• 产品说明书。
• SKU 参数表。
• Listing 规范。
• 品牌禁用词。
• 客服 FAQ。
• 退换货 SOP。
• 广告命名规则。
• 历史广告复盘。
• 竞品评论归因。
• 图片拍摄规范。
• 供应链注意事项。

不要一上来把整个网盘都塞进去。

知识库第一原则是：宁可少而准，不要多而乱。

2. 清洗和脱敏

进入知识库前，资料要清洗。

要删掉：

• API key。
• token。
• seller ID。
• 客户姓名。
• 地址。
• 电话。
• 邮箱。
• 供应商敏感报价。
• 未批准公开的利润数据。

如果是客服资料，尤其要注意客户隐私。

如果是财务和成本资料，要限制访问角色。

3. 分类和元数据

每份资料都要有元数据。

元数据就是资料的身份证。

建议至少包括：

字段	示例
document_type	product_specs / sop / faq / policy / review_summary
product_line	kitchen_storage
sku	KS-001
marketplace	US / UK / DE
version	v2026-07
owner	listing_team
updated_at	2026-07-07
status	active / archived / draft
sensitivity	public / internal / confidential

没有元数据，Agent 很容易检索到错误资料。

比如把 UK 站退货政策用到 US 站。

把旧版包装尺寸写进新版 Listing。

把草稿 SOP 当成正式 SOP。

4. 分块

分块就是把长文档切成适合检索的小段。

切得太大，检索结果太泛。

切得太小，缺少上下文。

Dify 关于知识库和多模态检索的资料提到，RAG 常见流程包括 chunking、indexing、retrieval、reranking、generation。LangChain RAG 教程也会从加载、分割文档、索引、检索和生成讲起。

卖家资料分块要按业务逻辑。

说明书可以按“安装步骤”“注意事项”“保修规则”分块。

Listing SOP 可以按“标题规则”“五点规则”“图片规则”“禁用词规则”分块。

客服 SOP 可以按“物流问题”“质量问题”“退款问题”“差评相关问题”分块。

不要机械按页数切。

5. 索引

索引是让资料可检索。

常见方式包括关键词检索、向量检索、混合检索。

向量检索擅长语义相似。

比如用户问“买家说盖子松”，系统可能检索到“密封性”“配件松动”“安装不到位”等相关资料。

关键词检索擅长精确匹配。

比如 SKU、ASIN、型号、认证编号、站点代码。

混合检索通常更稳。

跨境资料里有大量 SKU、型号、站点、认证名，不能只靠语义。

6. 检索和重排

检索先找一批可能相关的片段。

重排再判断哪几个最相关。

Dify 文档和博客都强调过 hybrid search、rerank、metadata filtering 这些能力对提升知识检索准确率很重要。

对卖家来说，重排很关键。

比如用户问：

“这个产品可以写 BPA-free 吗？”

系统可能检索到很多关于材质、安全、包装的资料。

但最重要的是认证文件和合规 SOP。

如果重排不准，Agent 可能引用不相关内容。

7. 生成和引用

模型拿到检索结果后生成答案。

但商用 RAG 输出必须带引用。

尤其是：

• 产品参数。
• 售后承诺。
• 认证信息。
• 平台规则。
• 成本和库存判断。

OpenAI file search 文档强调模型可以在生成回答前检索相关信息。Dify 也有 citations and attributions 相关能力。对卖家团队来说，引用不是装饰，而是复核入口。

没有引用，就很难判断 Agent 到底依据了什么。

8. 评估和更新

知识库不是建完就结束。

要持续评估：

• 该检索到的资料有没有检索到。
• 检索结果是否过期。
• 输出是否引用了错误来源。
• Agent 是否编造了知识库没有的内容。
• 哪些问题需要新增文档。

这一步决定 RAG 能不能长期用。

跨境团队知识库应该怎么分层

不要把所有资料放在一个大知识库里。

更好的做法是按业务角色分层。

第一层：产品事实库

放真实产品资料。

包括：

• SKU。
• ASIN。
• 尺寸。
• 重量。
• 材质。
• 包装。
• 适配型号。
• 使用限制。
• 认证资料。
• 说明书。
• 配件清单。

用途：

给 Listing Agent、客服 Agent、图片脚本 Agent 使用。

要求：

所有参数必须可追溯。

旧版本必须归档。

第二层：品牌和合规库

放品牌表达和禁止表达。

包括：

• 品牌语气。
• 禁用词。
• 竞品商标禁用。
• 不可承诺内容。
• 医疗、安全、认证相关边界。
• 图片合规规范。

用途：

给 Listing 审核、A+ 内容、广告素材、客服回复使用。

要求：

敏感规则必须由负责人审核。

第三层：运营 SOP 库

放流程类知识。

包括：

• 上新流程。
• Listing 改版流程。
• 广告周报流程。
• Review 处理边界。
• 站内信处理规则。
• 退换货 SOP。
• 活动复盘流程。

用途：

让 Agent 按公司方法做事，而不是按通用经验做事。

第四层：历史复盘库

放历史案例。

包括：

• Prime Day 复盘。
• 广告失败案例。
• Listing 改版结果。
• 客诉归因。
• 断货事故。
• 竞品监控周报。

用途：

帮助 Agent 在生成建议时参考公司经验。

注意：

历史复盘是参考，不是规则。

要标注时间和背景，避免过度套用。

第五层：外部资料库

放公开资料。

包括：

• 平台帮助文档。
• 类目趋势资料。
• 竞品公开页面快照。
• 公开政策说明。

用途：

辅助研究。

注意：

公开页面可能变化，要标注抓取时间。

不同 Agent 需要不同知识库

Listing Agent 需要什么知识

必备：

• 产品事实库。
• 关键词库。
• 品牌和合规库。
• 竞品差评归因。
• 图片规范。
• 历史优秀 Listing。

不应该默认读取：

• 客户隐私。
• 供应商报价。
• 毛利表。

输出必须：

• 标注产品参数来源。
• 标注关键词来源。
• 标注需要人工确认的合规表达。

客服 Agent 需要什么知识

必备：

• 产品 FAQ。
• 说明书。
• 售后 SOP。
• 退换货规则。
• 敏感回复边界。
• 升级人工规则。

不应该默认读取：

• 全量客户地址。
• 毛利。
• 供应商合同。

输出必须：

• 生成草稿，不直接发送。
• 标注引用 SOP。
• 标注是否需要人工升级。

广告 Agent 需要什么知识

必备：

• 广告命名规则。
• 目标 ACOS 规则。
• SKU 毛利区间。
• 库存状态。
• 活动日历。
• Listing 改版记录。
• 历史广告复盘。

输出必须：

• 区分数据事实、原因推断、建议动作。
• 所有调预算、否词、调竞价动作进入人工确认。

竞品监控 Agent 需要什么知识

必备：

• 竞品 ASIN 列表。
• 竞品页面快照。
• 价格历史。
• 评论归因。
• 我方 Listing。
• 类目卖点词库。

输出必须：

• 标注页面抓取时间。
• 不把单次变化当成长期趋势。
• 不照抄竞品文案。

知识库不是越大越好

很多团队的第一反应是：

“我们把所有资料都喂给 AI。”

这很危险。

知识库太大、太乱、太旧，会让 Agent 更难用。

常见问题有 6 个。

1. 旧文档没有归档

Agent 检索到 2024 年旧版 SOP，却用在 2026 年的新流程里。

解决：

所有文档必须有 status。

active 才进入默认检索。

archived 只在特别请求时检索。

2. 多站点规则混在一起

美国站、英国站、德国站售后规则混在同一个文档里。

解决：

metadata 必须有 marketplace。

检索时先过滤站点。

3. 产品参数混乱

A 产品说明书和 B 产品配件表放在一起。

解决：

每份资料绑定 SKU / ASIN / product_line。

4. 草稿和正式文档混用

运营临时写的草稿被 Agent 当成正式规则。

解决：

draft 不进默认检索。

正式知识库必须有审核人。

5. 没有引用来源

Agent 给出答案，但没人知道它引用了哪份资料。

解决：

输出必须包含文档名、版本、更新时间、片段编号。

6. 敏感数据混入知识库

客户地址、供应商报价、利润表被普通 Agent 检索到。

解决：

按 sensitivity 分级。

普通 Agent 只访问 public / internal。

confidential 需要特殊权限。

一个可用 RAG Agent 的工作流

以“Listing 改版 Agent”为例。

Step 1：用户提出目标

“请根据竞品差评和产品资料，生成一版美国站 Listing 改版建议。”

Step 2：Agent 检查输入

它先确认：

• 是否有产品资料。
• 是否有关键词清单。
• 是否有竞品差评归因。
• 是否有品牌禁用词。
• 是否有站点信息。

如果缺资料，先停。

不要直接写。

Step 3：检索知识库

检索：

• 对应 SKU 的产品参数。
• 美国站 Listing SOP。
• 品牌禁用词。
• 图片规范。
• 竞品差评归因结果。

Step 4：展示引用资料

在正式生成前，先列出：

• 使用了哪些文档。
• 文档版本。
• 更新时间。
• 哪些资料缺失。

Step 5：生成草稿

输出：

• 标题建议。
• 五点结构。
• 图片文案。
• QA 建议。
• 差评对应解决方案。

Step 6：标注风险

单独列出：

• 产品参数待确认。
• 合规表达待确认。
• 竞品商标风险。
• 需要供应链验证的问题。

Step 7：写回复盘

人工审核后，把最终采用版本和修改原因写回复盘库。

这样下一次 Agent 会更懂团队偏好。

RAG 评估：别只看回答像不像人

RAG 质量要评估，不然越用越乱。

建议从 6 个指标看。

1. 召回率

该找到的资料有没有找到。

比如问“KS-001 是否适配 iPhone 15”，知识库里明明有适配表，Agent 却没检索到，这就是召回问题。

2. 精准率

找到的资料是否真的相关。

比如问美国站退货政策，却检索到德国站保修文档，这就是精准率问题。

3. 新鲜度

资料是否最新。

旧版 SOP 被引用，就是新鲜度问题。

4. 引用完整性

关键结论有没有来源。

没有来源的产品参数，不应该进入 Listing。

5. 拒答能力

资料不足时，Agent 能不能说“不知道”。

这是商用 Agent 的重要能力。

6. 业务可执行性

输出是否能转成运营动作。

只会说“优化卖点”的回答没有价值。

能说“第二张图增加适配型号对照，引用产品资料 v2026-07，避免误购”才有价值。

可复制提示词：设计卖家团队 RAG 知识库

你是我的跨境电商 AI 知识库架构顾问。

团队背景：
我们是一个亚马逊卖家团队，主要业务是：[填写类目/站点/团队规模]。

目标：
搭建一个给 AI Agent 使用的 RAG 知识库，用于：[Listing改版 / 客服回复 / 广告周报 / 竞品监控 / 选品研究]。

现有资料：
1. [资料1]
2. [资料2]
3. [资料3]

请你帮我设计知识库方案，输出以下内容：

1. 知识库分层：产品事实库、品牌合规库、运营SOP库、历史复盘库、外部资料库。
2. 每一层应该放哪些文档。
3. 每份文档需要哪些 metadata 字段。
4. 哪些资料必须脱敏。
5. 哪些资料可以给 Agent 默认检索。
6. 哪些资料必须特殊权限。
7. 文档命名规则。
8. 过期文档归档规则。
9. Agent 输出时必须引用哪些来源。
10. 第一周 MVP 怎么做。
11. 验收标准：如何判断知识库可用。

要求：
- 不要建议把所有文件直接上传。
- 对敏感数据做权限分级。
- 对不同 Agent 分别说明可访问范围。
- 资料不足时列出缺失清单，不要编造。

第一周落地 SOP：从客服知识库开始

客服知识库最适合做第一版 RAG。

因为资料相对明确，输出是草稿，风险可控。

第 1 天：选范围

只选一个产品线。

只做美国站。

只覆盖 20 个高频问题。

不要一上来覆盖全店。

第 2 天：整理资料

准备：

• 产品说明书。
• FAQ。
• 退换货 SOP。
• 保修规则。
• 禁止回复清单。
• 历史优秀客服回复。

删除：

• 客户姓名。
• 地址。
• 电话。
• 邮箱。
• 订单号。

第 3 天：做元数据

每份文档标注：

• product_line。
• sku。
• marketplace。
• document_type。
• updated_at。
• owner。
• status。
• sensitivity。

第 4 天：分块和入库

按问题类型切块：

• 安装问题。
• 物流问题。
• 质量问题。
• 配件问题。
• 退款问题。
• 保修问题。

不要整篇说明书直接丢进去。

第 5 天：写客服 Agent 指令

要求：

• 先检索知识库。
• 引用 SOP。
• 不确定就升级人工。
• 不承诺超出政策的赔偿。
• 不引导评价。
• 只生成草稿，不自动发送。

第 6 天：测试历史工单

拿 30 条历史工单测试。

检查：

• 是否检索到正确 FAQ。
• 是否引用正确 SOP。
• 是否拒绝回答敏感问题。
• 是否该升级人工时升级。

第 7 天：上线只读试点

只让客服主管审核使用。

记录每次错误。

一周后再扩大范围。

RAG 知识库验收标准

一个知识库是否可给 Agent 用，至少看 12 条。

1. 文档有分类。
2. 文档有负责人。
3. 文档有更新时间。
4. 文档有适用站点。
5. 文档有适用 SKU 或产品线。
6. 过期文档不进默认检索。
7. 敏感数据已脱敏。
8. 检索结果能引用来源。
9. 资料不足时 Agent 会停止。
10. 不同 Agent 权限不同。
11. 输出能区分事实、推断和建议。
12. 每周有错误复盘。

如果做不到这些，知识库越大，Agent 越容易错。

不要误读 RAG

第一，RAG 不是把文件夹上传给 AI。

文件夹是存储，知识库是治理。

第二，RAG 不能自动保证正确。

检索错了，生成也会错。

第三，向量检索不是万能。

SKU、ASIN、型号、站点、认证编号，很多时候需要关键词和 metadata 过滤。

第四，知识库不能替代人工负责。

政策、合规、财务、客户赔偿，仍然需要人确认。

第五，知识库必须维护。

没人更新的知识库，很快会变成错误来源。

结论

AI Agent 要真正进入跨境运营，不能只接工具。

工具让它能做事。

知识库让它知道怎么按你的业务规则做事。

RAG 的价值，不是让 AI 背更多资料，而是让 Agent 在行动前先查事实、引用来源、识别缺口、标注风险。

卖家做 AI Agent 的正确顺序，不是先追求全自动，而是先把产品资料、SOP、品牌规则、客服 FAQ、广告复盘整理成可检索、可引用、可更新的知识库。

资料治理做得越好，Agent 越像一个懂业务的助理。

资料越乱，Agent 只是更快地把混乱包装成流畅文字。

资料来源与事实边界

本文核验日期为 2026-07-07。以下来源用于校准 RAG、检索、文件搜索、知识库、混合检索、重排和引用等官方说法；跨境电商部分为基于卖家运营场景的业务推演和实操建议。

• OpenAI API Docs：Retrieval。文档说明 Retrieval API 由 vector stores 支持，vector stores 是数据索引，可用于语义搜索。链接：https://developers.openai.com/api/docs/guides/retrieval
• OpenAI API Docs：File search。文档说明 file search 可让模型在生成回答前，从上传文件知识库中检索相关信息。链接：https://developers.openai.com/api/docs/guides/tools-file-search
• LangChain Docs：Retrieval。文档说明 LLM 有有限上下文和静态知识两类限制，retrieval 通过在查询时获取相关外部知识来增强回答，这是 RAG 的基础。链接：https://docs.langchain.com/oss/python/langchain/retrieval
• LangChain Docs：Build a RAG agent。文档用 Retrieval Augmented Generation 构建能基于特定来源信息回答问题的应用，并涵盖文档加载、分割、索引、检索和生成。链接：https://docs.langchain.com/oss/python/langchain/rag
• Dify Docs：Knowledge。Dify 知识库文档覆盖知识库使用、外部知识库、metadata 过滤、hybrid search、rerank、citations and attributions 等能力。链接：https://docs.dify.ai/en/cloud/use-dify/knowledge/readme
• Dify Blog：Introducing Knowledge Pipeline。Dify 将 Knowledge Pipeline 描述为把混乱企业数据转成高质量 LLM 上下文的可视化流水线。链接：https://dify.ai/blog/introducing-knowledge-pipeline
• Dify Blog：Multimodal retrieval is now available in the Knowledge Base。文章把广义 RAG 流程概括为 chunking、indexing、retrieval、reranking、generation，并解释 embedding 和 reranking 的协同价值。链接：https://dify.ai/blog/multimodal-retrieval-is-now-available-in-the-knowledge-base
• Google AI for Developers：File Search。Gemini API 文档说明 File Search 通过导入、分块、索引数据实现 RAG，使模型基于检索信息给出更准确相关的回答。链接：https://ai.google.dev/gemini-api/docs/file-search