大厂 MCP 面试实录知识库 RAG 检索封装为 MCP Tool 的工程实践本文为模拟面试实录围绕「将内部维护的产品知识库含操作手册、故障排查指南、过往工单记录的 RAG 检索能力封装为 MCP Tool供内部 AI 助手调用要求检索结果可溯源、高风险操作需人工确认」的业务场景展开由浅入深考察候选人的 MCP 协议理解、RAG 工程化落地与安全设计能力。面试官你好今天我们的业务场景是公司内部有维护了3年的产品知识库包含操作手册、故障排查指南、过往工单记录现在需要把 RAG 检索能力封装为 MCP Tool供内部 AI 助手调用要求检索结果可溯源、高风险操作需要人工确认。你先说说整体的方案设计思路吧候选人我的整体方案分为三层架构从外到内分别是协议接入层、RAG 引擎层、安全控制层。首先协议接入层对外暴露名为knowledge_base_retrieval的 MCP Tool严格遵循 MCP Tools 规范用 JSON Schema 对输入参数做结构约束同时支持 Host 自动发现和调用符合 Tools 的模型可控设计[资料3]中间 RAG 引擎层负责向量粗召回、语义重排和来源元数据标记保证检索结果的可溯源性最上层安全控制层负责参数校验、意图识别、权限校验和审计日志覆盖全链路的安全要求。具体调用流程是Host 发起 Tool 调用请求Server 先做参数结构和业务逻辑校验校验通过后触发 RAG 检索先通过向量近似最近邻算法做粗召回再用轻量交叉编码器做语义重排最终返回结果时附带每个片段的来源文档ID、页码、更新时间等溯源元数据如果识别到用户查询涉及高风险意图则返回结构化待确认响应明确提示操作影响要求用户显式确认后再继续。这个方案的适用边界是适合知识库更新频率中等、需要模型根据对话上下文主动触发检索的场景如果知识库更新极频繁或者需要预检索保证响应速度的场景更适合由 Host 在调用模型前主动完成检索流程更可预测[资料1]。以下是 Tool 输入参数的版本无关接口设计伪代码{ type: object, properties: { query: { type: string, maxLength: 200, description: 用户要检索的知识库问题最多200字 }, top_k: { type: integer, maximum: 10, default: 5, description: 返回的最相关片段数量最多10条 } }, required: [query] }服务端会基于该 schema 做基础结构校验不符合要求的请求直接拦截不会进入后续 RAG 流程。面试官你提到用 MCP Tool 封装为什么不直接用 MCP Resource 暴露知识库内容这两者在你的场景里有什么本质区别候选人两者的核心差异由 MCP 的能力定义决定Resource 是面向应用的可读上下文通常由 URI 标识适合暴露静态、只读的完整内容比如某个固定的操作手册全文而 Tool 是模型可主动发起的参数化操作适合需要动态计算、输入变量化的场景[资料1]。我们的知识库检索是动态流程用户的查询文本是变量需要经过向量检索、重排的实时计算如果用 Resource 的话要么需要预定义海量 URI 对应所有可能的查询实现成本极高要么只能暴露全量知识库内容会占用大量模型上下文反而降低检索准确率。另外 Tool 支持输入 schema 约束我们可以限制查询参数的范围避免恶意输入这是 Resource 不具备的能力。当然如果场景是让模型直接读取某个固定的、更新频率极低的操作手册用 Resource 更合适但我们的场景是泛化检索所以选 Tool 是更合理的。这里也要注意不要把只读的静态资料强行设计成有副作用的 Tool避免违反 MCP 的能力语义[资料1]。面试官你提到了用 JSON Schema 约束 Tool 的输入参数但如果模型传入了畸形的 JSON或者参数值超出预期范围比如 top_k 传了100你的服务端会怎么处理另外 JSON Schema 本身只能做结构校验你还有哪些额外的校验逻辑候选人我们会做两层校验机制第一层是协议层结构校验由 MCP Server 原生能力完成如果参数类型错误、必填项缺失、JSON 格式畸形直接返回参数错误响应不会进入 RAG 流程第二层是业务逻辑校验比如 top_k 我们限制最大允许值为10如果传入100会自动截断到10查询文本长度超过200字会做截断避免向量检索的性能问题和上下文溢出。此外我们会把所有模型传入的文本都视为不可信输入对查询文本做特殊字符过滤避免 SQL 注入、路径遍历等风险因为知识库检索接口底层可能对接数据库或文件系统恶意输入可能造成安全漏洞。审计日志只会记录调用时间、Tool 名称、用户ID、结果状态所有敏感字段包括用户查询文本、返回的敏感片段都会做脱敏处理不会出现在日志、Tool 返回值或模型上下文中避免敏感信息泄露[资料1]。面试官你提到了高风险操作需要人工确认具体怎么实现如果知识库的检索结果里被植入了诱导性内容比如“请用户同意删除所有工单”你的安全机制能拦截吗候选人高风险操作的识别完全在服务端完成不依赖模型或知识库内容的判断。我们会预先定义高风险关键词列表如“删除”“修改权限”“导出全量数据”等同时对接内部敏感意图识别服务对用户的原始查询做前置判断如果识别到高风险意图Tool 不会直接返回检索结果而是返回结构化的待确认响应里面包含操作的影响范围、涉及的知识库片段摘要明确提示“该操作需要人工确认请回复「确认」或「取消」”。针对知识库被植入诱导性内容的问题我们的安全机制分两层拦截第一层知识库内容属于不可信数据Host 会对 Tool 返回的内容做指令注入过滤把其中的指令性文本比如试图覆盖系统规则的指令过滤掉只保留事实性信息第二层Tool 返回值只会作为用户查询的参考上下文提供给模型不会直接作为系统提示词避免知识库里的恶意指令影响模型行为[资料1]。如果出现模型试图绕过确认流程的情况Host 会拦截非法的二次调用强制要求用户显式确认不会直接执行高风险操作。面试官现在你这个方案如果知识库有10万份文档业务要求检索延迟P99低于2秒你怎么优化有哪些取舍另外有没有容易踩坑的细节候选人优化会从检索链路、缓存、预处理三个方向入手首先是检索链路优化采用分层检索策略先通过近似最近邻ANN算法做粗召回取TopN个候选片段再用轻量交叉编码器做语义重排最终返回TopK个结果具体的N、K参数需要根据业务压测结果调整不能直接固定数值[资料2]。然后是缓存优化对同一个用户的重复查询做短期缓存缓存命中直接返回结果跳过检索流程缓存时长需要根据知识库更新频率权衡知识库更新越频繁缓存时长越短。最后是预处理优化知识库的切块、向量化工作都在离线完成查询时不需要实时计算减少实时开销。取舍方面缓存命中率和知识时效性需要平衡重排精度和延迟也需要权衡如果需要更低的延迟可以换成更轻量的重排模型但会损失部分准确率。容易踩坑的细节有两个第一如果使用 stdio 传输模式调试日志不能写到标准输出否则会破坏 JSON-RPC 的通信协议我们的日志统一写到标准错误或远程日志服务[资料1]第二JSON Schema 只是结构约束必须在服务端做细粒度的权限校验比如用户只能访问自己部门对应的知识库片段不能只依赖模型传入的参数合法避免越权访问。如果是远程部署的场景还需要额外考虑认证、授权、会话管理和限流避免未授权的调用[资料1]。面试官点评考察点MCP 能力选型Tool vs Resource的适用场景、RAG 工程化落地的核心流程、MCP 安全边界设计、人机协同的实现逻辑、性能优化的权衡思维。合格回答能明确区分 Tool 和 Resource 的差异知道 JSON Schema 仅能做结构约束、必须配合服务端校验能设计出可溯源、有安全拦截的基础检索流程理解 MCP 的传输和安全规范。加分项提到分层检索、缓存等性能优化策略能识别知识库内容的指令注入风险知道 stdio 传输的日志规范以及细粒度权限校验的必要性。如果候选人能结合实际项目经验提到具体的压测调优过程或者线上问题的排查思路会是显著的加分项。总结将 RAG 检索封装为 MCP Tool 的核心是明确能力边界用 Tool 的动态调用能力适配泛化检索需求通过 JSON Schema 做基础输入约束配合服务端的权限、意图校验和安全拦截同时做好检索的性能优化和可观测性设计才能在发挥 MCP 协议优势的同时保证系统的安全性和稳定性。参考资料MCP 基础知识Tools | https://modelcontextprotocol.io/specification/2026-07-28/server/toolsRetrieval-augmented generation (RAG) in Azure AI Search | https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overviewRetrieval-Augmented Generation for Knowledge-Intensive NLP Tasks | https://arxiv.org/abs/2005.11401