一、Knowledge 是什么#

提到 Agent 的 Knowledge，容易望文生义地以为它是某种被写进协议里的标准能力，像 OAuth 有规范文档、[[MCP]] 有 Anthropic 发布的协议规格。

事实并非如此——“Knowledge” 从来不是一个有正式规范的技术术语，它是各家产品和框架各自起的功能性名字：Claude 把它叫 project knowledge，OpenAI 把它叫 knowledge files / vector store，Gemini 把它叫 File Search，开源 Agent 框架（LangChain、LlamaIndex）则统一叫它 RAG（Retrieval-Augmented Generation）。没有任何组织出面定义”Knowledge 必须长什么样”，这也是它和 MCP 最大的不同——MCP 有协议文档规定”外部工具怎么被标准化调用”，Knowledge 没有对应的东西，各家实现可以完全不兼容，甚至同一家公司不同产品线的做法都不一样。

剥掉命名的外壳，Knowledge 的技术内核只有一句话：模型参数之外、运行时可检索的外部信息源。模型的”知识”在训练阶段就已经固化进权重，而 Knowledge 指的是训练之后、通过工程手段外挂进来的信息，本质就是 RAG 那一套。

Knowledge 与 Skill 是同一层面的两种东西：都是在运行时往上下文里注入内容，但注入的东西性质不同。Skill 注入的是”指令”——一份 SOP、一套操作步骤，教模型”怎么做”；Knowledge 注入的是”资料”——一段事实、一份文档，告诉模型”是什么”。

二、Knowledge 与上下文、与 Skill reference 的关系#

三、是否一开始加载 & upload 文件算什么#

四、聊天框 与 Project 中的 Knowledge#

普通聊天框（比如不开 Projects 的一次性对话）当然”有知识内容”——这次对话里拖进来的文件，模型完全读得到、答得出。但它没有”持久知识库”：这份文件只活在这一次的 context 里，会话一关、窗口一超，内容就彻底消失，不会被任何向量库记录，下次开新对话等于从未上传过。

只有 Project（Claude Projects、ChatGPT Projects、自定义 GPT 的 knowledge files、Gemini 的 Gems / File Search）才提供跨会话持久、可复用的 Knowledge Base——文件上传一次，之后每次在这个 Project 里开新对话，都可能被重新检索到。

所以准确的措辞不是”普通聊天框没有知识”，而是**“普通聊天框没有持久化、可挂载的知识库”**——它有的只是一次性的长 context，会话结束即焚。

五、Knowledge 如何与 LLM 关联 / LLM 怎么知道自己有知识#

呼应 Token 那篇的核心结论——自然语言在 LLM 内部不存在，模型只处理数字——这里同样成立：Knowledge 与 LLM 只有一条关联路径：知识内容变成 context 里的 token。不存在第二条路径能让 LLM 凭空”知道”自己有一个知识库，它不会读数据库的 schema，不会感知向量库里躺着多少份文件，它能看到的永远只是这一次 API 调用 messages 数组里已经拼好的文字。

这条唯一路径之上，衍生出两种截然不同的工作模式：

模式一：传统 RAG。检索这件事完全发生在 LLM 外部，由应用层的 orchestrator 代劳——先做检索，再把结果拼进 prompt，LLM 从头到尾是被动接收方，它不知道、也不需要知道这段文字是”从知识库查来的”还是”用户自己打的”，更谈不上任何声明。

模式二：Agentic RAG。知识库被包装成一个工具（比如 search_knowledge_base），连同其他工具一起，通过工具的 description 出现在这次调用的工具清单里。LLM 看到工具描述，自己判断”这个问题需不需要查知识库”，主动发起调用。这一模式下 LLM 是主动知道自己”有知识可查”的——它看到的是一份工具清单，跟看到 Skill 清单没有本质区别，这也是 Agentic RAG 与 Skill 高度趋同的原因。

六、外部检索器的例子#

一个具体例子：embedding 模型（OpenAI text-embedding、Voyage、Gemini embeddings 等）配合向量数据库（Azure AI Search、Pinecone、FAISS、Milvus 等）。

整个流程分离线、在线两段，离线阶段 LLM 完全不参与：

1. 切块：把文档切成几百 token 一段的小块（OpenAI 的 file_search 工具默认切成 800 token、重叠 400 token）。
2. 向量化：用 embedding 模型把每个块转成一个高维向量。
3. 入库建索引：向量连同原文写入向量数据库，建好可供近似搜索的索引。

运行阶段则是：

1. 用户提问，用同一个 embedding 模型把问题也转成向量；
2. 在向量数据库里计算相似度，取 top-k 个最相关的块（OpenAI file_search 默认取 20 个块，Anthropic 在 Contextual Retrieval 的实验里也发现取 20 个块效果最好——两家不约而同选中同一个数字）；
3. 把这几个块拼进 prompt；
4. 交给 LLM 生成最终回答。

核心结论是：检索器独立于 LLM 运行，只做”比较向量距离谁更近”的数学活，这一步是纯粹的线性代数与工程索引问题（常用 HNSW、IVF 等近似最近邻算法），跟”理解语言”没有任何关系，LLM 全程不参与这一步的计算。

七、检索结果在 prompt 里的具体呈现#

呼应 Context 那篇提到的四种标准 role（system / user / assistant / tool）——Knowledge 检索结果没有专属的 role，最终必须伪装成这四种里的一种才能进入 context。实践中常见三种做法：

做法 A：塞进 user 消息。最常见的传统 RAG 实现，把检索到的几段资料和用户原始问题拼在一起，包一层”以下是相关资料：……\n用户问题：……”，整个包装完的文本作为一条 user 消息发给模型。LLM 对此浑然不觉，它看到的只是一条比较长的 user 输入，无法分辨哪部分是用户写的、哪部分是检索器塞的。

做法 B：塞进 system 消息。把检索结果当成背景设定放进 system prompt，常见于企业客服类场景——把命中的产品手册片段写进 system，人设加资料一起定义这轮对话的背景。

做法 C：以 tool 返回，前面配一个 tool_calls。这是 Agentic RAG 的标准做法——模型主动发起一次 tool_use 调用（比如调用 search_knowledge_base），检索器执行后把结果包成 tool_result 传回去。这里可以直接借用 Context 那篇提到的一个细节：tool_result 的 role 其实是 user，因为 Anthropic 的设计逻辑是工具执行器站在用户侧，把结果”递给”模型。也就是说，即便是最像 Skill 的 Agentic RAG，检索结果最终进入 context 时，依然要套上四种标准 role 之一——通常又是套上了 user。

八、是否每轮都做向量比对#

默认是的，做法 A、B 这类无脑塞入的实现，每一轮提问都会重新触发一次完整的检索流程。但这不等于”每轮都要把整个知识库重新算一遍”，中间有几层工程上的修正：

知识库的向量早就预存好了，第六节的离线阶段只做一次，之后每一轮只需要重新计算”这句提问”的 embedding，知识库那一侧的向量是现成的，不会被重复计算。

检索靠索引近似搜索，不是逐一扫全库。向量数据库依赖 HNSW、IVF 这类近似最近邻算法，把毫秒级的响应时间和几乎线性的召回质量做了权衡，即便知识库有几十万条向量，一次查询通常也就是几毫秒到几十毫秒。

真正的成本大头不在向量比对本身，而在每轮注入 context 的那几段资料 token——这与 Context 那篇的结论一致：Agent 系统里 tool_result 才是消耗大户，检索命中的几个 chunk 一旦拼进 prompt，就是实打实的输入 token，要按次付费、占用窗口，向量数据库那边的计算开销相比之下可以忽略不计。

有两个常见的优化方向：一是加一道门控判断，先用一个轻量分类器判断这轮提问要不要检索，不需要就跳过，省下一次检索调用；二是改成 Agentic 检索，把检索包装成工具，让模型自己判断要不要调，用不上就不调。多轮对话场景下还有一个绕不开的问题：用户这一轮的原始提问经常是”那它呢""再详细说说”这类指代不明的短查询，直接拿去做向量检索效果很差（语义信息不完整），因此需要先做 query rewriting——用 LLM 把带着历史上下文的提问改写成一句独立、完整的检索查询，再送去做向量比对。

九、主流产品策略（ChatGPT / Claude / Gemini）#

三家的共同核心策略高度一致：知识库小就走 long-context 全量塞入，知识库大就切换到 RAG，分界线大致在20 万 token附近，正是第三节提到的 Anthropic 那条经验值，三家的产品设计大致都在这条线附近做取舍。

Claude：Projects 会在 project knowledge 接近 context window 上限时自动切换到 RAG 模式，官方说明这一步可将知识容量扩容至多 10 倍，且是双向可逆的——如果之后内容量又降回阈值以下，会自动切回 context 模式，全程不需要用户手动配置。在检索质量上，Anthropic 通过 Contextual Retrieval（Contextual Embeddings + Contextual BM25，再叠加 Cohere 重排序）把 top-20 chunk 检索失败率从 5.7% 降到 1.9%，相当于降低 67%。2026 年 3 月，Claude Opus 4.6 与 Sonnet 4.6 的 1M token 上下文窗口已按标准价格全量开放，进一步抬高了”直接塞 long context”这条路径能覆盖的场景。

OpenAI：策略更偏”按文件类型分流”——ChatGPT 对文本类文件（PDF、Word、PPT）走文本抽取 + 检索，对表格类文件（CSV、Excel）交给 Code Interpreter 用 Python 直接跑分析，对图片走 Vision 描述，三条路径互不相同；开发者侧的 file_search 工具默认按 800 token 切块、重叠 400 token、取 top-20 chunk 拼进 prompt。GPT-5.5 在 2026 年 4 月把 API 端上下文窗口做到了 100 万 token，是 OpenAI 第一个达到这一量级的模型。相比之下，普通 ChatGPT Projects 里”自动检索”这一层目前还不够成熟——开发者社区里能看到”把 Project 级检索能力搬到 ChatGPT 里”的功能请求帖，说明这块拼图眼下还在补齐中。

Gemini：押注的方向是超大窗口 + Context Caching——当前的 Gemini 3.1 Pro 输入上限为 1,048,576 token；Google 官方的 long-context 文档明确表达了这层立场：更小窗口的模型需要”滑动窗口丢弃旧消息、摘要压缩、RAG 检索”这类补救手段，而 Gemini 的超大窗口鼓励一种更直接的做法——把相关信息一次性全部放进去。与此同时，implicit context caching 在 Gemini 2.5 及之后的模型上默认自动生效（最低缓存门槛 2,048–4,096 token 不等），命中缓存部分的输入输出成本可降至标准价格的四分之一左右，完全不需要开发者写代码开启。File Search 这个托管 RAG 工具则更像一层面向开发者的 API 级基础设施——自动完成切块、向量化、建索引，2026 年新增了多模态检索能力，但定位始终不是面向普通用户、开箱即用的 Project 知识库产品。

三家共同的演化方向也很清楚：检索正在从”被动拼接”走向”模型主动调用的工具”——Claude 的 project knowledge search tool、OpenAI 的 file_search、Gemini 的 File Search tool，本质上都是把第五节的”模式二：Agentic RAG”做成了标准配置，这条路线也是三家都在收敛的共同答案。

十、由该机制衍生的常见现象#