1. 为什么“知识获取”是 Agent 绕不过去的一道坎我在前面几篇里反复强调过一句话Agent 的核心竞争力不在于“能调用多少工具”而在于“能不能在正确的时间拿到正确的知识”。很多刚入门的朋友把 Agent 理解成“大模型加一圈流程控制”觉得只要写好 Prompt、挂上几个工具函数就能让模型帮自己干活了。这种理解不能说错但它忽略了一个致命问题——大模型的参数知识是有边界的。你可以把 LLM 想象成一个受过高等教育的聪明人他读过很多书、知道很多常识但他不是全知全能的。你问他“今天北京的天气”他答不上来因为他没有实时感知能力你问他“你们公司内部的报销流程是什么”他也答不上来因为这份知识根本没有出现在他的训练语料里。更麻烦的是他的知识截止日期是固定的训练完之后这个世界还在继续变化而他停在了原地。这就引出了 Agent 知识获取管道的核心问题怎么让模型在推理时动态获得它原本不知道的信息RAGRetrieval-Augmented Generation检索增强生成就是目前最主流、最务实的答案。它的思路非常直白与其逼模型记住所有知识不如把知识存在外部在模型回答问题之前先根据用户的问题去知识库里检索相关片段把片段塞进上下文再让模型基于这些片段生成答案。整个过程有点像开卷考试——模型不需要背下整本书它只需要在考试时知道去哪一页翻答案。这篇是“走进 AI Agent”系列的第四篇我会从零开始拆解 RAG 这条管道它由哪些环节组成、每个环节在解决什么问题、有哪些容易被忽略的坑、以及如何从最简单的原型逐步演进到生产可用。内容偏向工程落地不讲玄学我会尽量把每一步的“为什么”也讲清楚。适合谁看如果你正在搭建自己的 AI Agent或者你在公司里要做一个基于私有知识库的问答系统又或者你只是好奇“ChatGPT 为什么能引用我的文档内容”这篇文章都值得你花二十分钟读完。读完你至少能明白RAG 不是一个“调个库就行”的黑盒它是一个需要精心照料的管道以及当你的 RAG 效果不好的时候问题到底出在哪一环。2. RAG 管道的宏观视图三个环节一条主线在动手写代码之前我强烈建议你先把 RAG 的整体架构在脑子里过一遍。很多教程上来就贴代码结果读者代码跑通了但换个场景就抓瞎因为不理解每一行代码到底在扮演什么角色。2.1 从业余版到生产版的演进路径我见过太多人把 RAG 理解成“三步走”加载文档、向量化、检索。没错这是最简版本但它和真实的 RAG 系统之间隔着好几层工程细节。最原始的 RAG 流程大概长这样拿一批 PDF 和 Word按固定长度切块用 Embedding 模型把每块变成向量存进向量数据库用户提问时把问题也变成向量去向量库里做相似度检索取回 TopK 个块把问题和这些块一起拼进 Prompt交给 LLM 生成答案。这个流程能跑通但效果通常不理想。真正生产可用的 RAG 系统在每一个环节上都做了额外的功夫先说“加载文档”。真实世界里的文档不是干净的纯文本有的是 PDF 里的扫描图片有的是表格套表格的 Excel有的是带页眉页脚的排版报告。如果直接按字节读进来你得到的可能是一堆乱码或者语义断裂的碎片。所以第一环节的完整版要包含格式解析、编码识别、版面分析、表格抽取等一系列预处理动作。再说“切块”。固定 500 字一切是最省事的做法但也是最容易出问题的做法。一个完整的语义单元可能只有一句话也可能跨越好几页表格切得太碎检索回来的片段缺乏上下文切得太整向量之间互相污染相似度区分度下降。所以切块策略要结合文档结构来做标题、段落、列表项都可能是天然的语义边界。然后是“向量化”。Embedding 模型的选择直接影响检索质量。有的模型擅长中文、有的擅长代码、有的对长文档友好、有的对短查询友好。而且 embedding 之后通常还需要做一步归一化或降维否则高维空间里的距离计算会失真。最后是“检索和生成”。朴素的向量相似度检索只是起点。生产系统里往往要配合关键词检索BM25、重排序Rerank、元数据过滤、多路召回融合等机制才能把真正相关的片段捞上来。生成阶段也有讲究Prompt 怎么组织、引用怎么标注、模型产生幻觉了怎么办、知识库里没有答案时怎么回应这些都是需要单独设计的问题。所以 RAG 的完整管线我建议你这样理解文档解析 → 切块 → 向量化 → 存储 → 查询改写 → 检索 → 重排 → 生成。前四步是“索引构建”离线做做一次后四步是“查询生成”在线做每次提问都跑一遍。2.2 每个环节的“为什么”不能跳过我特别想强调一件事RAG 的每个环节都有它存在的理由跳过任何一个“为什么”后面排查问题的时候都会加倍痛苦。举个例子。很多人不理解为什么要单独做“查询改写”。用户问“那个项目的进度怎么样了”问题是针对多轮对话的上下文问的而知识库检索是基于单轮问句做的。如果直接把这句话拿去检索向量相似度大概率匹配到一堆“项目”“进度”的泛泛内容真正的项目名反而不在问题里。这时候就需要把对话历史、用户画像、知识库里的实体信息结合起来把问题改写成“2025 年 Q3 的某客户 CRM 项目实施进度如何”再去检索效果立刻不一样。再比如重排序。向量检索的 TopK 结果里可能前三个片段都来自同一段文字信息高度冗余而真正有用的第四五个片段反而被挤掉了。重排模型的职责就是把这五个候选重新打乱用更精细的交叉编码器计算“问题和片段的相关度”保留信息密度最高的那几段。我把这些环节背后的逻辑列成一张表方便你对照理解环节解决什么问题不问“为什么”的代价文档解析把非结构化数据变成可处理的文本乱码、缺行、语义断裂切块确定语义检索的最小单元检索不精确、上下文缺失向量化把文本搬到可计算的向量空间语义相近但表述不同的文本匹配不上存储解决大规模数据的组织与快速召回检索慢、无法过滤元数据查询改写让问题本身变得更适合检索复杂问题搜到的都是无关片段检索从候选池中召回最可能相关的片段召回率低、答案缺料重排修正向量检索的粗糙排序TopK 里冗余太多、关键信息被埋没生成基于检索结果组织可信答案幻觉、答非所问、引用不可靠3. 关键决策点之一切块策略直接决定检索质量的上限这一节我打算展开讲切块因为在我接触过的 RAG 项目里至少有一半的“效果不好”问题根源都在切块策略上。检索模型再强喂给它的块本身就是碎的、乱的后面全都白搭。3.1 固定长度切块与语义切块的取舍固定长度切块最简单拿一个 200 到 800 的字数窗口按顺序把文档切成若干块块与块之间可以设置 10% 到 20% 的重叠防止语义在边界处被一刀切断。它的优点是好实现、好调试、模型无关任何格式的文档都能切。缺点也很明显它完全不理解文档的结构和语义。比如一个法律条款可能前面是“定义”后面是“适用条件”中间隔着好几个编号固定切块可能把“定义”的一部分和“适用条件”的一部分揉在一起检索时返回的片段四不像。语义切块则是另一种思路利用文档本身的层级结构比如 Markdown 的标题、PDF 的目录、HTML 的标签把文档切成长度不一但语义完整的块。一个常见的做法是“基于标题树的滑动窗口切块”先解析出文档的标题层级然后在同一级标题下的正文里动态决定哪里该断块。实际项目中我通常采用混合策略先试语义切块如果文档结构不明显比如一堆聊天记录、日志文件再退回固定长度加重叠。判断标准很朴素——把切出来的块随机抽二十个人眼扫一遍如果绝大多数块都能独立读通就算合格。3.2 不同文档类型的切块参数参考这里我给出几组我实测下来比较稳的参考值你可以当作起点来调不要直接照搬。技术文档Markdown / HTML按标题层级切块窗口大小 600 到 1000 字重叠 100 字左右。技术文档的语义单元通常比较长切太碎会让“上下文”缺失严重。新闻资讯 / 公众号文章按段落切块窗口 300 到 500 字。这类文本每段自带完整观点切长了反而引入无关信息。法律合同 / 政策文件优先按条款编号切如果条款很长再在条款内部按子句切。窗口可以到 800 字以上因为条款内部逻辑紧凑拆开会丢失因果链。聊天记录 / 工单日志固定窗口 200 到 300 字重叠 50 字。这类文本噪音大块越小检索精准度越高哪怕牺牲一点召回率也值得。切块还有一个经常被忽略的细节要不要保留元数据。比如“这个块来自哪个文档、哪个章节、第几页”这部分信息不参与向量化但会在检索后处理阶段发挥大作用。我在生产环境里一定会把元数据挂在每个块上后面无论是做权限过滤、引用溯源还是做重排时的来源加权都用得上。4. 关键决策点之二向量化与存储选型别在最容易迁移的地方过度设计切块之后下一个大头是向量化和存储。这一节的标题之所以叫“别过度设计”是因为很多团队在这一步花了大把时间纠结选型结果发现后期换了 Embedding 模型或者从向量库换成了关系型数据库前面的努力全部白费。4.1 Embedding 模型怎么选Embedding 模型的作用是把你切好的文本块和用户的查询都映射到同一个向量空间里。选型时有几个维度值得看语言支持中文场景优先看中文评测榜单比如 C-MTEB有些模型英文很强但中文很弱。最大输入长度有的模型上限是 512 token有的是 8k token。如果你的块比较长选短上限的模型就得被迫切小窗口。维度大小向量维度直接影响存储成本和检索速度。768 维和 1536 维之间存储量差一倍。检索质量最可靠的做法是拿你自己的领域数据做一个小规模测试集跑一遍检索看召回效果不要只看公开榜单。一个我踩过的坑早期图省事直接用了一个通用中英双语模型测试时效果还行上线后发现对于代码类问答检索效果很差。后来换成专门优化过代码语义的模型检索命中率立刻涨了十几个点。所以我的经验是先确定你的知识库是什么类型再选模型通用模型可以是起点但很可能不是终点。4.2 向量数据库与“用不用向量库”之争向量数据库最近两年很火但我建议你在决定引入之前先想清楚一个前提你的数据量到底有多大如果知识库只有几千个块十万个向量以内那 SQLite 加上一个向量检索插件或者直接用内存里的 numpy 暴力算相似度完全足够。非要上一个分布式向量数据库集群等于杀鸡用牛刀运维负担反而成了新问题。如果数据量到了百万级或者检索延迟有硬性要求那再考虑专用向量数据库。选型时优先看这几项是否支持混合检索向量 关键词 元数据过滤、索引类型HNSW 还是 IVF、数据更新机制、以及云厂商托管版本的运维成本。我在几个项目里的组合是小项目用 Chroma 或者 PG 的 pgvector中等规模用 Milvus 的 Standalone 模式规模再大或者有多机房需求再看 Elasticsearch 这类自带向量能力的搜索引擎。这个组合不一定适合所有人但思路是通用的——从轻到重、按需升级不要在第一天就上重型武器。5. Retrieval 进阶查询改写、混合检索与重排序的配合现在假设你已经有了一个还不错的索引块切得合理、向量存得干净。这一节讲的是“检索”这个在线环节怎么从“能搜到东西”进化到“搜到的东西正好能用”。5.1 查询改写让问题先被理解再被检索很多 RAG 系统的第一个瓶颈不是检索模型而是查询本身。用户的自然语言往往带着指代、省略和不精确的表达直接拿去和向量比对经常差之毫厘、谬以千里。我的做法是在检索之前加一个小模型环节专门负责把原始查询改写成更利于检索的形式。这个改写可以是多轮的扩展把对话历史里提到的实体补全也可以是同义改写把口语换成书面语甚至可以拆解成多个子查询分别检索再合并结果。举个实际例子。用户问“它和手动挡比哪个更省油”这个“它”指代的是上文讨论的某款混动车型。如果不去追问历史直接向量检索大概率召回一堆“省油”“手动挡”的碎片。改写之后变成“本田雅阁混动版与手动挡车型的油耗对比”检索命中率会明显提升。需要注意的是查询改写不能每轮都做它本身也消耗模型资源和时间。我的经验是设置触发条件只有当对话历史里存在指代、或者原查询长度太短、或者上一轮检索的置信度过低时才执行改写。这样既能保住效果又不会让每个请求都多跑一遍模型。5.2 混合检索向量不是万能的关键词也不是向量检索擅长“语义相似”但它在精确匹配这件事上很不擅长。比如用户搜“BUG-2025-001”如果知识库里确实有这个编号向量检索可能会因为这个词太罕见、太短而匹配不到。关键词检索BM25反而能精准命中。混合检索的思路就是两者结合向量检索召回语义相近的BM25 召回字面匹配的两边结果合并再统一去重、加权、排序。融合方式最简单的有“分数加权取平均”好一点的是“先分别取 TopK再用 Rerank 模型统一排序”。我在生产项目里推荐第二种因为两种检索的得分体系不可比直接加权很容易让某一方主导而 Rerank 模型可以做到在一个统一的语义空间里重新打分。5.3 万物皆可 Rerank质量再上一个台阶的杠杆重排序Rerank是检索质量提升里投入产出比最高的一个环节。它用交叉编码器把问题和候选块拼在一起直接算相关度得分比单纯用向量距离准确得多。常见的流程是这样第一步用向量检索 关键词检索各召回 50 个候选第二步用 Rerank 模型对这 100 个候选重新打分第三步取前 5 到 10 个分数最高的块作为最终上下文。重排模型一般比 Embedding 模型要大、要慢所以它只应该作用在“少量候选”上而不是全库。这也是为什么它必须放在第一轮粗召回之后。我在实际项目中测试过加上 Rerank 之后答案的命中率平均提升了 20% 到 30%有时候甚至能把排名第一位的候选直接换掉。如果你觉得重排太慢还有两个折中方案一是只用它重排前 20 个候选二是按查询类型动态启用——简单事实类问题可以跳过复杂推理类问题必须走重排。6. 从“检索到”到“生成好”上下文组织、幻觉抑制与拒答策略检索环节做得再好如果生成阶段的 Prompt 组织不当前面的功夫照样可能白费。这一节聊几个生成侧的实战要点。6.1 上下文组织的三个原则第一个原则引用来源不能丢。每个送进 Prompt 的知识块都要带上它的来源标签文档名、章节、页码。这样模型在生成答案时才能输出“根据报告第 3 章……”这样的引用读者也才能去核对原始材料。这个机制不仅是体验问题也是容错问题——一旦答案错了你能迅速定位是哪一条材料误导了模型。第二个原则给模型“不知道”的权利。Prompt 里必须明确告诉它如果检索到的内容不足以回答问题就直接说“知识库中没有相关信息”不要强行编造。我在实际测试中发现很多幻觉不是模型能力不够而是 Prompt 里没给它放弃的选项它觉得“必须回答点什么”于是就开始发挥了。第三个原则过滤掉检索噪音。Rerank 之后拿到的 TopK 块仍然可能有与问题无关的碎片。一个简单的启发式做法是设定一个相关度阈值低于阈值的块不进上下文。宁可让模型说“不知道”也不要硬塞垃圾给它。6.2 幻觉检测的两个低成本方案关于幻觉抑制除了 Prompt 层面的引导我建议再叠一层检测机制。方案一是“答案可验证性检查”让模型在生成答案时同时输出它引用了哪些知识块的关键片段。这一步相当于逼着模型“自证清白”。下游再做一个校验看看答案里的关键实体是否能在被引用的片段里找到找不到就标记为“疑似幻觉”拒绝输出或降级为“缺乏足够信息”。方案二是“双模型交叉验证”用两个不同的模型或者同一个模型用两种不同的 Prompt 温度分别生成答案再比较它们的关键结论是否一致。这个方法成本高一些适用于高风险场景比如医疗建议、法律意见、金融分析。日常的客服问答没有必要上这么重的手段。6.3 拒答不是失败是 RAG 的自我保护很多产品经理会担心“知识库里没有答案时模型说不知道会让用户体验变差”。但从长线看强行回答的后果更严重——一次编造的错误答案可能带来信任崩塌而“诚实地说不知道”反而会被用户接受。我的实践是把拒答也做成一种可解释的交互。当触发拒答时系统不是冷冰冰地丢一句“我不懂”而是告诉用户“我在知识库中没有找到与 XX 相关的信息你可能需要查看官方文档或者换一种问法。”这样用户会觉得系统是“懂边界”的而不是“傻了”。从技术上说拒答策略本质上是给生成环节设定了一个“置信门槛”检索结果最高分低于阈值→拒答问题与知识库主题域完全不相关→拒答多轮对话里上下文出现严重指代不明→先请求澄清再检索。这几种规则可以在工程上写成分支逻辑并不复杂但对用户体验的提升非常明显。7. 一个可以照抄的最小可用代码骨架写到这里原理讲得差不多了我直接给你一个可以跑起来的最小 Python 实现。这个骨架不追求生产级但它把整条管道串起来了适合你在这个基础上迭代。7.1 文档加载与切块from langchain_community.document_loaders import TextLoader, PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter # 加载文档这里以文本和 PDF 为例 loader TextLoader(knowledge_base/example.txt, encodingutf-8) docs loader.load() # 切块固定长度 重叠 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , , ] ) chunks splitter.split_documents(docs) print(f切块数量: {len(chunks)})RecursiveCharacterTextSplitter的思路是从大到小尝试分隔符优先按段落切再按句子切最后按字符切。这比“硬按字数切”聪明一点至少不会把一句话从中间劈开。7.2 向量化与存储from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma # 加载本地 Embedding 模型 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) # 建向量库 vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db )这里用了一个中文效果不错的开源模型bge-small-zh-v1.5如果你对英文场景为主可以换成bge-base-en-v1.5或text-embedding-3-small之类的模型。Chroma 的好处是零配置、能落盘适合做原型。7.3 检索与生成from langchain.chains import RetrievalQA from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4o-mini, temperature0.2) qa RetrievalQA.from_chain_type( llmllm, retrievervectorstore.as_retriever(search_kwargs{k: 5}), chain_typestuff ) answer qa.invoke(公司今年第一季度的营收情况如何) print(answer[result])这个版本是最基础的单轮问答。如果你想把 Rerank、查询改写加进去LangChain里都有对应的组件比如ContextualCompressionRetriever和MultiQueryRetriever可以直接替换上面的retriever。需要提醒一句这个骨架的文档解析能力非常弱。真实场景里如果遇到扫描版 PDF 或复杂表格你需要再引入 OCR 工具和版面分析库这个我在后面的运维章节会详细讲。8. 从原型走到生产我踩过并且你大概率也会踩的坑从“能在本地跑通”到“能在线上稳定服务”中间的距离远比大多数人想象得大。这一节是我最想分享的部分都是实际项目中踩过的坑不是从文档里抄来的注意事项。8.1 坑一知识库更新了检索结果却还是旧的这是一个非常隐蔽的问题。很多向量数据库支持增量写入但如果你用的是 Chroma 这类本地库很容易出现“旧的向量文件还在新的文档没进来”的状态。更要命的是你改了原文档的内容向量库里旧的向量并不会自动删除或更新。我的做法是在系统的“知识管理”模块里维护一份文档版本表。每次文档变更先把旧文档的所有块向量删除再重新解析切块、写入新向量。整个过程做成一个离线任务跑完后做一次“抽样验证”——随机选几个问题对比更新前后的检索结果确认没有异常。如果你用 Milvus 这类专业向量库它有分区Partition机制可以按文档 ID 删除或重建分区操作起来会更优雅。但无论如何“文档变更必须触发向量重建”这一条一定要在产品设计上就固定下来否则一定有人忘了手动更新。8.2 坑二扫描版 PDF 直接切块检索结果惨不忍睹我之前做过一个内部知识库里面全是扫描版 PDF用 PyPDFLoader 加载之后出来的是一堆乱码。当时第一反应是“换个 PDF 库”试了好几个都差不多后来才意识到问题根本不是 PDF 解析库不够好而是文档本身是图片需要先 OCR。OCR 我推荐 PaddleOCR 或者 Tesseract中文场景 PaddleOCR 效果明显更稳。但加了 OCR 之后又带来新的问题OCR 结果没有段落结构排版全丢了。我的经验是把 OCR 分两步第一步识别整页文字第二步根据坐标信息做版面还原把标题、段落、表格大概恢复出来。这个步骤说起来轻巧做起来要花不少时间所以我的建议是在项目早期就盘点文档格式如果扫描版占比超过 20%直接把 OCR 纳入主流程别抱侥幸心理。8.3 坑三检索命中率挺高但答案质量还是很差如果测试时发现“检索出来的片段看起来相关但最终答案不对”问题大概率出在生成阶段而不是检索。这时候优先检查三件事第一上下文里是否有互相矛盾的片段。TopK 返回的块可能来自不同版本的文档一个说“支持该功能”另一个说“不支持该功能”模型不知道信谁自然容易出错。解决办法是在 Prompt 里增加“当多个来源冲突时优先信任最近更新日期的来源”这样的规则性引导。第二是否缺少必要的背景信息。有些问题的答案依赖“隐性知识”比如某个术语在知识库的其他文档里定义了但当前文档直接使用了没有在上下文里体现。解决办法是增加“知识扩展”环节在最终生成之前先把返回块里的关键实体做一次二次检索把相关定义、背景补充进来。第三温度参数是否太高。生成答案时温度太高模型会倾向于自由发挥。知识库问答场景我通常把温度调到 0.2 以下甚至 0。有些人觉得“温度太低答案太死板”但知识库问答的第一诉求是准确不是文采。8.4 坑四Rerank 模型太慢影响线上延迟我曾经在一个项目里把 Rerank 加在每次查询的必经路径上结果 P95 延迟直接涨了 800 毫秒。后来做了两个优化一是只在候选数大于 20 时才启用 Rerank候选少的话直接用向量排序二是把 Rerank 模型换成了一个小蒸馏版本虽然单条精度掉了两三个点但延迟降了一半。如果你对延迟敏感我建议你在设计检索流程时就考虑“多级策略”简单问题走快速通道纯向量检索、不重排、不改写复杂问题走完整通道混合检索 改写 Rerank。判断一个问题是简单还是复杂可以交给一个小模型做意图分类也可以设置规则——比如问题长度、是否包含实体、是否指代不明等。9. 进阶方向Agentic RAG 与图谱增强到底“进”在哪最后简单聊一下 RAG 的进阶方向因为这一篇既然属于 Agent 系列我们不能只停留在“检索 生成”的经典框架里。最近被反复讨论的 Agentic RAG本质上是把“检索”从一个固定流程变成一个由 Agent 动态决策的行为。经典的 RAG 是一次性完成的你问一个问题系统检索一次生成一次答案。Agentic RAG 里的“Agent”体现在几个维度它可能会先自我判断这个问题需不需要检索外部知识它可能会把一个复杂问题拆解成多个子问题分别检索、分别回答再做汇总它可能会在首轮检索结果不够好时主动改写查询、换一个检索源、再试一次。换句话说检索不再是“流水线上的一个工位”而是 Agent 手里的一个工具它可以根据需要反复调用、调整策略。另一个值得关注的方向是图谱增强 RAG。向量检索处理的是“片段相似度”但它不理解知识之间的拓扑关系。举个例子两个片段里都提到了“张伟”一个是“张伟是销售总监”另一个是“张伟负责华东区”向量检索可能把这两个片段都捞回来但模型不一定知道它们是同一个人。如果引入知识图谱先做实体识别和关系抽取把“张伟 – 担任 – 销售总监”和“张伟 – 负责 – 华东区”连成图谱检索时就能利用图结构做多跳推理回答“华东区销售总监是谁”这类问题会精准得多。但我要泼一盆冷水Agentic RAG 和图谱增强都不是银弹它们各自有代价。Agentic RAG 的代价是多轮检索带来的延迟和成本以及 Agent 决策本身可能出错图谱增强的代价是构建和更新图谱的成本很高而且实体识别的错误会被下游放大。我的建议是——先把经典 RAG 的各个环节做到 80 分再考虑进阶方向。绝大多数系统的问题都出在基础环节没做到位而不是没用上最新技术。在这条路上走了几个项目之后我最大的体会是RAG 不是一个“接入即完成”的组件而是一条需要持续观测、持续调优的管道。它的每一个环节都像一个水管的接口只要有一个接口松动水就会漏。而最耗时的部分往往不是写代码而是不断用真实数据去检验、去调整、去修补那些接口。如果你正在搭建自己的 Agent 知识获取管道我建议你从最基础的版本跑起来然后把真实用户的问题一批一批喂进来按照“哪里不对就修哪里”的方式迭代这比一开始就追求大而全的设计更能产出可靠的结果。