企业官网建设流程全解析

用户问一句 "退货政策是什么"，知识库找到了几段相关文字，模型也给出了流畅的回答；但这些文字可能分别来自淘宝、京东和亚马逊，适用条件并不相同

这类问题说明，找出语义相似的内容，只完成了知识问答的一部分；系统还要判断资料属于哪个业务、上下文是否完整，以及是否需要继续查找

除了提前把文档切片、建立检索索引，还可以让 Agent 保留资料的文件结构，在处理任务时逐步查阅；Skill 的references/就能承载这种按需读取的资料，两种方式也可以配合使用

RAG 如何把资料交给模型：

RAG 的全称是 Retrieval-Augmented Generation，即检索增强生成；常见的向量检索实现先把文档拆成较小的片段，再用 Embedding 模型把片段转换为向量，存入向量数据库

用户提问时，系统也把问题转换为向量，找出语义上最接近的若干片段；这些候选片段通常称为 Top-K，随后进入模型的上下文，供模型生成答案

这种做法能够从大量资料中快速筛选相关内容，但切片方式会影响答案质量；如果一个条款的适用条件在前一节，例外情况在后一节，只取中间一段，模型就可能拿到不完整的依据

纯向量检索也有自己的盲点；"退货政策" 可能命中不同平台的相似规则，而产品编号、错误码、函数名等需要精确匹配的内容，未必能仅靠语义相似度准确找到

这些问题需要通过检索设计解决；例如，把关键词检索与向量检索结合，并在片段中补充所属文档的上下文，再对候选结果重排序，可以改善单纯依赖向量相似度的效果；Anthropic 的 Contextual Retrieval 方案就采用了这样的思路

Skill 的 references 如何组织知识：

Skill 可以把任务说明与参考资料放在同一个目录中；SKILL.md说明这项技能什么时候适用、应该如何执行，references/保存执行时可能需要查阅的资料

以售后知识库为例，退货政策、换货流程、产品编号表可以分别保存在普通文件里；目录名、文件名、章节以及文件之间的引用关系，都能为 Agent 提供查找线索

这里的关键是按需加载；按照 Agent Skills 规范，Agent 先通过name和description了解技能的用途，在激活技能后读取SKILL.md，再根据具体需要加载参考文件

这一机制称为 "渐进式披露"；它让 Agent 先知道有哪些能力和资料入口，再逐步获取完成当前任务所需的细节

遇到退货问题，Agent 可以先看目录，根据文件名判断资料范围，用 Glob 匹配文件路径，用 Grep 搜索关键词，再打开命中的章节；如果读到某条规则引用了其他条款，就继续查阅对应内容

前一次查找的结果，会影响下一次查找的方向；这种文件查阅方式不要求预先建立向量索引，也不要求一次把整个知识库装进上下文

不过，references/本身只是资料目录；保留文件结构能提供更多线索，能否找到正确内容，仍取决于资料组织、技能指引和 Agent 的工具使用能力

两种方式的差别在哪里：

把常见的向量切片方案与基于文件的按需查阅放在一起，可以从四个方面理解它们的差别

资料更新是一个实际的维护差别；文件方案能够直接修改政策文件并保留版本记录，向量检索方案则需要让索引与源资料保持一致，避免继续召回旧规则

这并不意味着 RAG 每次更新都必须重建整个知识库；支持增量更新的系统，可以只处理发生变化的文档或片段

同样，RAG 也可以保留章节信息、补读相邻内容，或者由 Agent 发起多轮检索；上表比较的是两种常见实现的工作重心，实际系统可以组合这些能力

从代码查阅理解按需获取上下文：

假设用户问："这个项目的登录是怎么做的？"

Agent 可以先看项目结构，再搜索login、auth、路由和中间件等线索；找到相关文件后，继续沿着import和函数调用关系，查清登录入口、会话处理与令牌生成之间的联系

如果实现细节还不明确，就继续查看测试、配置和 Git 历史；每次读取都在缩小问题范围，并为下一步提供依据

这个过程的价值在于，Agent 可以根据任务逐步建立理解；它既能利用文件内容，也能利用路径、命名和依赖关系

Anthropic 将这种在需要时动态获取资料的方式称为 just-in-time context；其上下文工程说明介绍了 Claude Code 如何结合预先加载的说明与 Glob、Grep 等工具，按需查阅工作区资料

Skill 的参考文件也可以采用相同思路；先提供清晰的入口和读取规则，再让 Agent 根据当前问题加载必要内容

这种方式对模型能力有要求；Agent 需要理解指令、选择工具、判断查找结果，并在发现缺口时继续探索，工具调用越多，通常也意味着更高的时间和上下文成本

随着长上下文和工具使用能力的发展，更多任务可以交给 Agent 自主查阅；但模型能力增强，并不会消除大规模资料检索的需求，也不能保证文件查阅在所有任务上都更好

哪些场景仍然适合 RAG：

是否需要专门的检索系统，可以结合资料规模、提问方式和服务要求判断

• 资料规模很大：面对数百万份工单、邮件、合同、研报或客服记录，先通过索引筛出候选资料，通常比让 Agent 逐个探索文件更实际
• 用户描述模糊：用户只记得大意，不知道准确关键词，语义检索可以帮助找到相关表达，给后续阅读提供起点
• 延迟和并发要求高：在线客服等场景需要持续处理大量请求，预先建立索引有助于减少查询时的探索步骤，具体性能仍需结合实现验证
• 资料保存在外部系统：知识已经分布在工单平台、数据库、邮箱或企业文档中心时，可以通过检索接口访问，无须全部搬进本地文件夹

这些场景可以把检索能力作为工具交给 Agent；例如，通过 MCP 暴露一个search_knowledge工具，由后端完成关键词与向量混合检索、结果重排序，再把候选资料返回给 Agent 阅读

Skill 则负责说明什么时候需要调用这个工具、如何组织查询，以及应该获取哪些字段；MCP 提供工具接入方式，实际的检索逻辑由背后的服务实现

这样，Skill 组织任务流程，检索服务处理大范围资料筛选，Agent 负责结合上下文继续判断

把知识访问组织成三层：

对于同时具备本地参考资料和外部知识源的 Agent，可以采用逐步扩展查找范围的方式

第一层，用 SKILL.md 和目录结构引导查阅；先让 Agent 明确资料范围、文件用途和执行规则，知道应该从哪里开始

第二层，用 Glob、Grep 或其他本地文本搜索精确定位；根据文件路径、关键词和已发现的引用，找到相关章节，并读取理解规则所需的上下文

第三层，在内部资料不足时调用外部检索系统；通过 MCP 访问更大范围的知识源，再依据返回结果继续阅读和判断

回到退货政策的例子，Agent 可以先确认适用业务，定位相应政策文件，再核对条件和例外；如果资料中没有所需规则，或用户的描述无法映射到明确关键词，就扩大检索范围，借助外部搜索寻找候选资料

这种分层方式把资料导航、精确搜索和语义检索连接起来；每一层都为下一步提供线索，也让系统能够根据问题选择合适的查找路径

知识库接入 Agent 时，需要同时设计资料入口、上下文保留方式和检索工具；文件结构清晰、适合逐步阅读的资料，可以放进 Skill 的参考文件，规模庞大或需要语义召回的资料，则可以交给专门的检索服务