企业官网建设流程全解析

大厂 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 协议优势的同时，保证系统的安全性和稳定性。

参考资料

1. MCP 基础知识
2. Tools | https://modelcontextprotocol.io/specification/2026-07-28/server/tools
3. Retrieval-augmented generation (RAG) in Azure AI Search | https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview
4. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks | https://arxiv.org/abs/2005.11401