1. RAG 到底是什么从大模型的“知识焦虑”说起大模型有个很尴尬的问题它知道的东西截止到训练数据被冻结的那一天。你问它昨天公司内部发布的规章制度它要么编一个看起来很像真的答案要么直接告诉你“我不知道”。更麻烦的是它有时候会非常自信地编造事实这就是大家常说的“幻觉”。RAG全称 Retrieval-Augmented Generation中文叫检索增强生成。这个名字听起来很学术但拆开看就三件事检索、增强、生成。用户问一个问题系统先去知识库里把相关内容找出来再把找到的内容和问题一起交给大模型让大模型基于这些真实材料来回答。大模型不再靠“记忆”答题而是像开卷考试一样拿着参考资料作答。我刚开始接触 RAG 的时候觉得这不就是“搜索 大模型”吗能有多复杂真正动手做起来才发现从文档切分、向量化、存储、检索到最终生成每一步都有坑。检索不准后面全白搭切分不合理语义被割裂Embedding 模型选错相似度计算完全跑偏。这些问题在 demo 阶段可能看不出来一旦上真实业务数据立刻暴露。这篇文章适合谁看如果你是正在做 Agent 开发的工程师RAG 几乎是你绕不开的基础设施。Agent 要调用工具、要查资料、要基于事实做决策RAG 就是它的“外部记忆”。如果你在准备面试RAG 是高频考点面试官会从原理问到工程细节从 Embedding 选型问到检索优化。如果你只是想给自己的小项目加一个本地知识库这篇也能帮你少踩坑。接下来我会从整体设计、核心细节、实操流程、常见问题四个维度把 RAG 拆开讲透。不堆术语不背概念用我实际做项目时踩过的坑和总结的经验帮你建立一套能落地的 RAG 认知框架。2. RAG 整体架构设计与核心思路拆解2.1 为什么 RAG 是 Agent 开发的“基础设施”Agent 和普通聊天机器人的核心区别在于Agent 要自主决策、要调用工具、要基于环境反馈调整行为。一个 Agent 如果只能靠大模型内部知识做判断它的能力边界就被锁死了。RAG 给 Agent 提供了一个可扩展、可更新、可验证的外部知识源。举个例子你做一个客服 Agent产品价格、库存、售后政策每天都在变。把这些信息全部塞进大模型微调成本高、周期长、更新慢。用 RAG你只需要把最新的产品文档放进知识库Agent 每次回答前先检索就能拿到最新信息。这就是 RAG 在 Agent 架构中的核心价值把“知识”和“推理”解耦。从架构上看RAG 在 Agent 中通常以“工具”的形式存在。Agent 收到用户问题后判断是否需要查知识库如果需要就调用 RAG 检索工具拿到相关文档片段再结合这些片段生成最终回答。这种设计让 Agent 的知识库可以独立维护、独立更新不影响 Agent 本身的逻辑。2.2 经典 RAG 流水线的四个核心环节一个标准的 RAG 流水线不管用什么框架实现核心环节都是四个文档加载与切分、向量化与存储、检索与召回、生成与后处理。文档加载与切分是第一步也是最容易被低估的一步。很多人直接把整篇 PDF 扔进去结果检索出来的内容要么太长、要么太碎。切分的核心目标是让每个 chunk 在语义上尽量完整同时长度可控。我一般会把 chunk size 控制在 300 到 800 个 token 之间具体取决于文档类型和 Embedding 模型的最大输入长度。向量化与存储是把文本变成向量存进向量数据库。这里的关键是 Embedding 模型的选择。不同模型对中文、英文、代码、专业术语的表现差异很大。选错了模型相似度计算就是“鸡同鸭讲”。向量数据库的选择也很关键Chroma、Milvus、Qdrant、Weaviate 各有适用场景后面会详细对比。检索与召回是 RAG 的“命门”。检索不准生成再强也没用。基础做法是向量相似度检索但实际项目中往往需要混合检索向量检索 关键词检索再加重排序。单一向量检索在遇到专有名词、缩写、代码片段时召回率会明显下降。生成与后处理是把检索到的内容拼进 Prompt交给大模型生成回答。这里要注意 Prompt 的设计要明确告诉模型“只基于提供的资料回答”要给出“如果资料中没有相关信息就说不知道”的指令否则模型还是会编。2.3 朴素 RAG、高级 RAG 与 Agentic RAG 的演进逻辑RAG 不是一成不变的它经历了从朴素到高级再到 Agentic 的演进。朴素 RAG就是最基础的“检索-拼接-生成”流程。优点是简单、快、容易实现。缺点是检索质量依赖单一向量检索遇到复杂问题容易召回不准。高级 RAG在朴素 RAG 基础上加了优化查询改写、混合检索、重排序、上下文压缩、多路召回等。查询改写是把用户的口语化问题改写成更适合检索的形式混合检索是向量检索和关键词检索结合重排序是用一个专门的模型对召回结果重新打分。这些优化能显著提升检索命中率。Agentic RAG是把 RAG 嵌入 Agent 的决策循环。Agent 不再是一次性检索而是可以多轮检索、可以判断检索结果是否足够、可以调用不同工具获取信息。比如 Agent 可以先查知识库发现信息不够再去查数据库再不够就去调用 API。这种模式更灵活但也更复杂需要 Agent 框架的支持。我个人的经验是不要一上来就追求 Agentic RAG。先把朴素 RAG 跑通把检索命中率提上去再逐步加高级优化。很多项目连基础检索都没做好就急着上 Agentic结果问题排查都无从下手。3. 核心细节解析与实操要点3.1 文档切分别让“切”毁掉语义文档切分看起来简单实际上决定了 RAG 的上限。我见过太多项目检索效果差最后发现是切分策略有问题。最常见的错误是按固定字符数切分。比如每 500 个字符切一刀不管句子有没有结束。这样切出来的 chunk 经常在半句话处断开语义不完整。检索的时候用户问“退货政策是什么”检索到的 chunk 可能是“退货政策是自购买之日起 7 天内商品未拆封且不影响二次销售的情况下可以申请退货。超过 7 天……”然后被切断了后面的关键信息在下一个 chunk 里。正确的做法是按语义边界切分。优先按段落切段落太长再按句子切句子还太长才按字符切。很多框架提供了 RecursiveCharacterTextSplitter它会按分隔符优先级递归切分先按双换行切再按单换行切再按句号切最后才按字符切。这样能最大程度保留语义完整性。还有一个细节是 chunk overlap。相邻 chunk 之间保留一定的重叠内容比如 50 到 100 个 token。这样即使一个问题涉及两个 chunk 的边界也能保证至少有一个 chunk 包含完整信息。overlap 不能太大否则检索结果冗余严重也不能太小否则边界信息丢失。注意切分参数没有万能值。技术文档、法律合同、客服对话、代码文件最佳切分策略完全不同。一定要拿真实数据测试看检索结果再调参。3.2 Embedding 模型选型中文场景别乱用默认模型Embedding 模型是把文本变成向量的“翻译器”。模型选错了后面所有优化都是徒劳。英文场景下OpenAI 的 text-embedding-ada-002 和 text-embedding-3-small 是常见选择效果稳定。但中文场景下直接用这些模型效果会打折扣。中文的语义理解、分词、专有名词处理都需要针对中文优化的模型。目前中文 Embedding 模型里BGE 系列BAAI General Embedding是绕不开的选择。BGE-large-zh 在中文语义相似度任务上表现很好BGE-m3 支持多语言和长文本。M3E 系列也是常见选择轻量且效果不错。如果追求极致效果可以考虑用大模型做 Embedding但成本和延迟会高很多。选型时要考虑几个维度语言支持、最大输入长度、向量维度、推理速度、部署成本。最大输入长度很重要如果你的 chunk 是 512 个 token但模型最大只支持 256超出的部分会被截断信息就丢了。向量维度影响存储成本和检索速度维度越高存储越大检索越慢但表达能力越强。我一般会先用 BGE-large-zh 做 baseline跑一批真实 query 看检索命中率。如果命中率不够再尝试其他模型或者微调。微调 Embedding 模型需要标注数据成本较高一般项目先用现成模型就够了。3.3 向量数据库选型Chroma、Milvus、Qdrant 怎么选向量数据库是 RAG 的“存储层”。选型要考虑数据量、并发量、部署方式、运维成本。Chroma 是最轻量的选择适合本地开发和小规模项目。它可以直接嵌入 Python 进程不需要单独部署服务。数据量在几万到几十万条向量时Chroma 完全够用。缺点是分布式能力弱大规模场景下性能有限。Milvus 是功能最全的向量数据库之一支持分布式部署、多种索引类型、混合检索。适合数据量大、并发高的生产环境。但 Milvus 的部署和运维复杂度也最高需要单独维护一套集群。Qdrant 在功能和易用性之间取得了不错的平衡。它支持过滤、混合检索、分布式部署API 设计也比较友好。中小规模生产环境用 Qdrant 是很务实的选择。Weaviate 的特点是内置了模块化能力可以直接集成 Embedding 模型减少开发工作量。但灵活性相对低一些。数据库适用规模部署方式核心优势注意事项Chroma小规模嵌入式零部署、上手快不适合大规模并发Milvus大规模分布式功能全、性能强运维复杂Qdrant中小规模单机/分布式平衡好、API 友好生态相对小Weaviate中小规模单机/分布式模块化、集成度高灵活性受限我个人的建议是本地开发和小项目用 Chroma快速验证想法生产环境如果数据量在百万级以下Qdrant 是性价比很高的选择数据量再大或者有特殊需求再考虑 Milvus。3.4 检索策略单一向量检索为什么不够用向量检索的原理是把 query 也变成向量然后找向量空间里距离最近的 chunk。它擅长语义匹配比如用户问“怎么退钱”能匹配到“退款流程”的文档即使字面不一样。但向量检索有短板。遇到专有名词、产品型号、代码函数名、缩写向量检索经常召回不准。因为这些词的语义信息在 Embedding 模型里可能没有被充分训练。比如用户问“RAG-001 型号的参数”向量检索可能召回一堆关于 RAG 技术的文档而不是那个具体型号的说明书。解决办法是混合检索向量检索 关键词检索BM25。关键词检索擅长精确匹配能补上向量检索的短板。两路召回结果合并后再用重排序模型Reranker重新打分把最相关的结果排到前面。重排序模型和 Embedding 模型不同它直接对 query 和文档的 pair 打分精度更高但速度更慢。所以通常只对召回的前几十条做重排序不会对全量数据做。提示混合检索的权重需要调。向量检索和关键词检索的分数尺度不同直接相加不合理。一般会做归一化后再加权或者用 RRFReciprocal Rank Fusion融合排名。3.5 Prompt 设计让大模型“老实”基于资料回答检索到资料后怎么让大模型基于资料回答而不是自由发挥这是 Prompt 设计的核心。一个常见的错误是把检索结果直接拼在问题前面不加任何指令。这样大模型可能忽略资料继续用自己的知识回答。正确的做法是在 Prompt 里明确指令只基于以下资料回答如果资料中没有相关信息就说“根据现有资料无法回答”。Prompt 的结构一般是系统指令 检索资料 用户问题 输出格式要求。系统指令要清晰、具体不要含糊。比如“你是一个客服助手只基于提供的产品文档回答用户问题”比“请回答用户问题”有效得多。还有一个技巧是给资料加编号让模型在回答时引用来源。比如“根据资料[1]退货政策是……”。这样不仅方便追溯也能减少模型编造。如果检索结果很多不要全部塞进 Prompt。大模型的上下文窗口有限塞太多反而会稀释关键信息。一般选 Top 3 到 Top 5 的 chunk 就够了配合重排序保证质量。4. 实操过程与核心环节实现4.1 环境准备与依赖安装先搭一个最小可跑的 RAG 环境。我习惯用 Python 虚拟环境避免依赖冲突。python -m venv rag-env source rag-env/bin/activate # Windows 用 rag-env\Scripts\activate pip install langchain langchain-community chromadb sentence-transformers pypdf这里选了 LangChain 做流程编排Chroma 做向量存储sentence-transformers 加载 Embedding 模型pypdf 读取 PDF。如果你用 Ollama 跑本地大模型再装一个 langchain-ollama。pip install langchain-ollamaOllama 的好处是本地跑模型不需要 API key适合开发和测试。生产环境再换成 API 或者自部署的大模型服务。4.2 文档加载与切分实操假设你有一个 PDF 格式的产品手册先加载再切分。from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter loader PyPDFLoader(product_manual.pdf) documents loader.load() text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , ., , ] ) chunks text_splitter.split_documents(documents) print(f切分后 chunk 数量{len(chunks)})这里 chunk_size 设为 500overlap 设为 80。separators 里把中文句号、感叹号、问号也加进去了因为默认的分隔符主要针对英文。中文文档一定要加中文标点否则切分效果会差很多。切分完建议抽查几个 chunk看看有没有在句子中间断开的情况。如果断开严重调大 chunk_size 或者调整 separators 顺序。4.3 向量化与存储实操用 BGE 模型做 Embedding存进 Chroma。from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma embedding_model HuggingFaceEmbeddings( model_nameBAAI/bge-large-zh-v1.5, model_kwargs{device: cpu}, encode_kwargs{normalize_embeddings: True} ) vectorstore Chroma.from_documents( documentschunks, embeddingembedding_model, persist_directory./chroma_db ) vectorstore.persist()normalize_embeddings 设为 True 很重要它把向量归一化到单位长度这样余弦相似度计算更稳定。BGE 模型官方也建议归一化。第一次跑会下载模型大概 1G 多。如果机器有 GPU把 device 改成 cuda 会快很多。CPU 也能跑就是慢一点。4.4 检索与生成实操检索部分先做基础向量检索再加混合检索。retriever vectorstore.as_retriever( search_typesimilarity, search_kwargs{k: 5} ) query 退货政策是什么 docs retriever.invoke(query) for i, doc in enumerate(docs): print(f--- 结果 {i1} ---) print(doc.page_content[:200])生成部分用 Ollama 跑本地模型。from langchain_ollama import OllamaLLM from langchain.prompts import ChatPromptTemplate llm OllamaLLM(modelqwen2.5:7b) prompt ChatPromptTemplate.from_template( 你是一个客服助手。请只基于以下资料回答用户问题。 如果资料中没有相关信息请回答“根据现有资料无法回答”。 资料 {context} 用户问题{question} 回答 ) context \n\n.join([doc.page_content for doc in docs]) chain prompt | llm answer chain.invoke({context: context, question: query}) print(answer)这个流程跑通后你就有了一个最基础的 RAG 系统。但别急着上生产先拿一批真实问题测试检索命中率和回答准确率。4.5 混合检索与重排序的代码实现基础向量检索跑通后加混合检索和重排序。from langchain.retrievers import BM25Retriever, EnsembleRetriever bm25_retriever BM25Retriever.from_documents(chunks) bm25_retriever.k 5 vector_retriever vectorstore.as_retriever(search_kwargs{k: 5}) ensemble_retriever EnsembleRetriever( retrievers[bm25_retriever, vector_retriever], weights[0.4, 0.6] ) docs ensemble_retriever.invoke(query)BM25 是经典的关键词检索算法LangChain 内置了实现。EnsembleRetriever 把两路结果融合weights 控制权重。中文场景下BM25 需要先分词LangChain 默认用空格分词中文效果不好。可以换成 jieba 分词。import jieba def chinese_tokenizer(text): return list(jieba.cut(text)) bm25_retriever BM25Retriever.from_documents( chunks, preprocess_funcchinese_tokenizer )重排序可以用 BGE-reranker 模型。from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-large) pairs [[query, doc.page_content] for doc in docs] scores reranker.predict(pairs) sorted_docs [doc for _, doc in sorted(zip(scores, docs), reverseTrue)] top_docs sorted_docs[:3]重排序模型直接对 query-doc pair 打分精度比向量相似度高但计算量大。只对召回的前 10 到 20 条做重排序选 Top 3 到 Top 5 给大模型。4.6 参数计算与选择过程chunk_size 怎么定我的经验公式是Embedding 模型最大输入长度 × 0.6 到 0.8。比如 BGE-large-zh 最大支持 512 个 tokenchunk_size 设在 300 到 400 比较合适。留出余量是因为 tokenizer 的实际切分和字符数不是一一对应中文一个字可能对应多个 token。overlap 怎么定一般是 chunk_size 的 10% 到 20%。500 的 chunk_sizeoverlap 设 50 到 100。overlap 太大检索结果冗余太小边界信息丢失。Top K 怎么定召回阶段 K 可以大一点比如 10 到 20保证召回率。重排序后选 3 到 5 给大模型保证精度。K 太大Prompt 太长大模型注意力分散K 太小可能漏掉关键信息。这些参数没有绝对最优值一定要用真实数据做 A/B 测试。我一般会准备 50 到 100 个真实 query人工标注正确答案然后测不同参数下的命中率和准确率。5. 常见问题与排查技巧实录5.1 检索命中率低从四个方向排查检索命中率低是 RAG 最常见的问题。我一般按这个顺序排查第一看切分是否合理。把检索到的 chunk 打印出来看内容是否完整。如果 chunk 在句子中间断开或者一个 chunk 里混了多个不相关的段落那就是切分问题。调整 chunk_size 和 separators。第二看 Embedding 模型是否适合。如果 query 和文档明明语义相关但相似度分数很低可能是模型不适合你的领域。换一个模型试试或者用领域数据微调。第三看检索策略是否单一。纯向量检索在专有名词、缩写、代码场景下召回差。加 BM25 混合检索再加重排序。第四看 query 是否需要改写。用户问“那个东西怎么弄”这种口语化 query 直接检索效果很差。用大模型把 query 改写成更具体的检索语句比如“XX 功能的操作步骤是什么”。5.2 大模型不按资料回答Prompt 和上下文的问题有时候检索到了正确资料但大模型还是按自己的知识回答。原因通常是 Prompt 不够明确或者上下文太长导致关键信息被淹没。解决办法在 Prompt 里用强指令比如“必须只基于以下资料回答”、“如果资料中没有答案必须回答不知道”。把资料放在 Prompt 的前面问题放在后面这样模型更容易关注资料。如果资料太长做上下文压缩只保留和问题最相关的部分。还有一个技巧是让模型先复述资料中的关键信息再回答问题。这样能强制模型关注资料。5.3 向量数据库检索慢索引和参数调优数据量大了之后向量检索会变慢。Chroma 在小数据量下很快但超过几十万条向量后检索延迟明显上升。优化方向建索引。Chroma 默认用 HNSW 索引可以调 ef_search 参数值越大精度越高但速度越慢。Milvus 和 Qdrant 支持更多索引类型比如 IVF、PQ可以根据场景选择。另一个方向是减少向量维度。用 PCA 或者 OPQ 做降维能显著减少存储和计算量但会损失一些精度。需要权衡。还有一点是过滤条件。如果检索时能加元数据过滤比如只搜某个类别的文档能大幅减少搜索范围。5.4 常见问题速查表问题现象可能原因排查方向解决方案检索结果不相关切分不合理检查 chunk 内容调整 chunk_size 和分隔符专有名词召回差纯向量检索短板测试关键词检索加 BM25 混合检索回答编造事实Prompt 不明确检查 Prompt 指令加强指令要求只基于资料检索延迟高数据量大/索引未优化看检索耗时建索引、降维、加过滤中文效果差Embedding 模型不适配换中文模型用 BGE 或 M3E边界信息丢失overlap 太小检查相邻 chunk增大 overlap5.5 独家避坑经验坑一不要用默认参数跑生产。默认 chunk_size 和 overlap 是通用值不一定适合你的数据。一定要用真实数据调参。坑二不要忽略元数据。给每个 chunk 加上来源、页码、类别等元数据检索时可以过滤回答时可以引用来源。这个在后期排查问题时非常有用。坑三不要一次性把所有文档都灌进去。先拿一小部分数据跑通流程验证效果再逐步扩大。全量灌入后发现问题排查成本很高。坑四不要只测“标准问题”。真实用户的提问方式千奇百怪有错别字、有口语、有省略。测试集要覆盖这些情况否则上线后命中率会大跌。坑五不要忽视大模型的上下文窗口。检索结果太多Prompt 超长大模型可能截断或者忽略后面的内容。控制好 Top K 和 chunk 长度。5.6 RAG 与 Agent 结合时的特殊问题RAG 作为 Agent 的工具时有几个额外问题要注意。工具调用的时机。Agent 什么时候该调 RAG什么时候不该调如果 Agent 对每个问题都调 RAG会增加延迟和成本。可以在 Agent 的 Prompt 里加判断逻辑如果问题涉及具体事实、产品信息、内部文档就调 RAG如果是闲聊或者通用知识就不调。多轮检索的上下文管理。Agentic RAG 可能多轮检索每轮检索的结果怎么管理全部塞进上下文会爆只保留最后一轮可能丢信息。我的做法是维护一个检索结果池每轮检索后做去重和重排序只保留最相关的几条。检索失败的处理。如果 RAG 检索不到相关内容Agent 应该怎么回应直接说“不知道”可能体验不好可以引导用户换个问法或者转人工。这个逻辑要在 Agent 的决策流程里明确。安全与权限。企业知识库往往有权限控制不同用户能查到的文档不同。RAG 检索时要带上用户身份做权限过滤。这个在 Agent 架构里要提前设计后期加会很麻烦。5.7 效果评估怎么知道 RAG 做得好不好RAG 的效果评估分两部分检索质量和生成质量。检索质量看命中率Hit Rate和 MRRMean Reciprocal Rank。命中率是 Top K 结果里包含正确答案的比例MRR 是正确答案排名的倒数的平均值。这两个指标能客观反映检索能力。生成质量看准确率、忠实度、相关性。准确率是回答是否正确忠实度是回答是否基于检索资料相关性是回答是否切题。可以用大模型做自动评估也可以人工抽检。我一般会建一个测试集包含 50 到 100 个真实问题和标准答案。每次调整参数或换模型都跑一遍测试集对比指标变化。没有测试集调参就是盲调。提示测试集的问题要覆盖不同类型事实型、操作型、对比型、否定型。事实型问“是什么”操作型问“怎么做”对比型问“A 和 B 有什么区别”否定型问“什么情况下不能做”。不同类型的问题对 RAG 的挑战不同。5.8 从 Demo 到生产还需要补哪些能力Demo 跑通只是第一步上生产还要补很多能力。监控和日志。记录每次检索的 query、召回结果、生成回答、耗时。出问题时能追溯。缓存。高频 query 的检索结果可以缓存减少向量数据库压力。降级策略。向量数据库挂了怎么办大模型服务超时怎么办要有降级方案比如切到关键词检索或者返回预设话术。数据更新。知识库文档会更新怎么增量更新向量库全量重建成本高要做增量索引。多租户。如果服务多个客户每个客户的知识库要隔离。向量数据库的 collection 或者 namespace 要设计好。这些能力在 demo 阶段可以不管但上生产前必须补齐。我见过太多项目 demo 很惊艳一上生产就各种问题核心原因就是工程化没做好。5.9 面试高频问题与回答思路RAG 是 Agent 开发面试的高频考点。面试官常问的问题包括“RAG 的流程是什么”回答要覆盖四个环节文档切分、向量化存储、检索召回、生成后处理。不要只背概念要结合具体技术选型讲。“怎么提升检索命中率”从切分优化、Embedding 选型、混合检索、重排序、查询改写几个方向回答。最好能举一个你实际做过的优化案例。“RAG 和微调有什么区别”RAG 是外挂知识微调是内化知识。RAG 更新快、成本低、可追溯微调效果更稳定但更新慢、成本高。两者可以结合。“Agentic RAG 是什么”把 RAG 嵌入 Agent 的决策循环支持多轮检索、工具调用、动态决策。比传统 RAG 更灵活但复杂度更高。“怎么评估 RAG 效果”检索看命中率和 MRR生成看准确率、忠实度、相关性。要有测试集要能量化。回答这些问题时不要只背理论要结合你实际做过的项目。面试官更看重你的实战经验和排查问题的思路。5.10 我个人的实操体会做了几个 RAG 项目后我最大的体会是RAG 的瓶颈往往不在生成而在检索。很多人把精力花在换大模型、调 Prompt 上但检索不准生成再强也没用。先把检索命中率提上去再优化生成。另一个体会是不要追求一步到位。先跑通朴素 RAG再逐步加混合检索、重排序、查询改写。每加一个优化都要用测试集验证效果。没有测试集的优化都是盲调。最后RAG 不是银弹。有些场景不适合 RAG比如需要复杂推理、需要多跳查询、需要实时计算。这些场景可能需要结合其他技术比如知识图谱、代码执行、工具调用。RAG 是 Agent 能力的一部分不是全部。这个内容后续还可以这样扩展把 RAG 和知识图谱结合做 GraphRAG把 RAG 和 Agent 的记忆系统结合做长期记忆把 RAG 和多模态结合支持图片和表格检索。每一个方向都值得深入。