MCP 面试高频考点把知识库 RAG 检索封装成 ToolJava 落地要避哪些坑面试场景面试官我们先做一个贴近工程的题。假设团队已经有一套内部知识库 RAG 能力包含文档解析、切块、向量索引、召回和重排现在要把它接入支持 MCP 的 AI 应用让模型在回答企业制度、产品文档和运维手册问题时能按需检索。技术栈要求用 Java MCP SDK 实现服务端。请你先说整体方案再回答我后面的追问。候选人结论先说我会把“知识检索”设计成一个 MCP Tool而不是 Resource 或 Prompt服务端用 Java 实现本地联调优先用 stdio远程部署时切到 Streamable HTTP并把鉴权、输入校验、结果裁剪、审计日志和来源回传放在服务端完成。核心原因是检索是模型根据对话上下文主动触发的操作符合 Tool“由模型调用”的语义Resource 更适合按 URI 读取稳定上下文Prompt 更适合用户显式选择模板不应把带查询条件的检索强行塞成只读资源 [资料1][资料4]。基础问题为什么选 Tool而不是 Resource 或 Host 前置检索面试官先展开一下为什么你优先选 Tool候选人MCP Server 常见有三类能力Tools、Resources、Prompts。Tools 是模型可发起调用的操作需要清晰名称、描述和输入 schemaResources 是应用可读取的上下文通常用 URI 标识Prompts 是用户可显式选择的模板化消息或工作流 [资料1]。知识检索的输入是用户问题、过滤条件、召回范围等参数输出是与问题相关的片段列表本质上是一次“根据上下文执行检索”的动作不是预先固定的文档资源所以更适合 Tool [资料1][资料4]。如果由 Host 在调用模型前统一做前置检索流程更简单、可预测但模型无法根据多轮对话动态决定“要不要查、查什么、查几次”。把检索封装成 MCP Tool 后模型可以先判断问题是否需要外部知识再发起调用灵活性更高代价是要控制调用次数、权限和返回内容长度避免上下文膨胀或越权检索 [资料1]。面试官那这个 Tool 的接口你会怎么设计候选人我会先把能力边界收紧不暴露底层向量库、SQL 或文件系统细节。Tool 名称建议语义明确例如search_knowledge_base描述里写清楚适用场景、输入含义和返回内容输入 schema 至少包含 -query检索语句必填 -top_k返回片段数选填服务端设置上限 -filters知识库范围、文档类型、时间范围、业务线等过滤条件选填 -need_rerank是否启用重排选填。返回结果不要只给拼接后的大段文本应该返回片段数组每个片段包含内容、来源标题、文档 ID、章节、更新时间、链接或定位信息以及可选相关性分数。这样 Host 或上层应用可以做引用展示、排错和可信度判断符合 RAG 结果保留来源元数据的要求 [资料1]。下面给一个版本无关的接口示意不绑定具体 SDK 版本// 伪代码Java MCP Server 注册知识检索 Tool server.addTool( ToolDefinition.newBuilder(search_knowledge_base) .description(根据问题检索企业知识库返回相关片段和来源。仅用于查询文档不执行修改操作。) .inputSchema(/* JSON Schema: query, top_k, filters, need_rerank */) .build(), (request, context) - { KnowledgeQuery query validateAndBind(request.getArguments()); ListKnowledgeChunk chunks ragService.retrieve(query); return ToolResult.success(toContent(chunks)); } );这里我不会直接把底层retrieve(query, topK, rerank)原样暴露而是在服务端先做参数绑定、权限过滤、结果裁剪和脱敏。第一轮追问异常、安全和不可信输入怎么处理面试官如果模型传入异常参数呢比如top_k很大或者filters里带路径穿越、SQL 片段、敏感知识库标识。候选人这里有个容易踩坑的点Tool 的参数 schema 只是结构约束不能代替服务端校验和授权 [资料1]。我会把模型传入的文本都视为不可信输入。具体做法分三层 1.结构校验依赖输入 schema 做基础类型、必填项、枚举值校验 2.业务校验对top_k设置服务端上限超过就截断或报错对filters做白名单映射例如只允许按当前用户有权限的业务线检索不接受任意文档 ID、文件路径或原始查询语句直传底层存储 3.安全约束对可能进入 SQL、URL、文件路径、Shell 或向量库过滤表达式的参数做转义和约束避免把检索 Tool 变成越权查询入口 [资料1]。异常处理上我不会把底层堆栈、索引地址、数据库名、鉴权票据返回给模型。Tool 返回值应区分用户可理解的业务错误和系统错误例如“未指定检索词”“超出最大返回条数”“当前知识库范围无权限”系统异常则记录日志后返回通用失败信息。凭据也不能出现在日志、Tool 返回值或模型上下文中 [资料1]。面试官如果用户问的是高敏感文档比如薪酬制度或未发布产品方案呢候选人不能因为请求来自 AI 应用就默认可信。远程 MCP Server 需要对每次请求执行授权检查不能只判断用户是否登录 [资料1]。实现上我会把用户身份、租户、角色、可访问知识库范围通过会话上下文传入服务端在执行检索前按资源范围过滤如果是高风险或不可逆操作MCP 安全建议要求显示具体影响并在执行前让用户确认但知识检索本身通常是只读操作重点是最小权限、范围裁剪和审计而不是二次确认 [资料1]。审计日志需要记录谁在什么时间调用了哪个 Tool、关键资源范围和结果状态并对敏感字段脱敏 [资料1]。例如记录query的摘要、命中知识库范围、返回片段数、耗时、 traceId不记录完整敏感文档内容。第二轮追问传输方式、可观测性和工程取舍怎么做面试官你提到本地用 stdio远程用 Streamable HTTP。为什么如果要落地到团队开发环境和生产环境怎么选候选人stdio 适合 Host 在本机启动子进程的场景。这个模式下MCP Server 的标准输出用于协议消息调试日志必须写到标准错误否则日志内容会混入 JSON-RPC 消息流直接破坏通信这是本地调试非常常见的坑 [资料1]。Java 服务启动时要特别注意日志框架配置避免把 SDK 通信报文、应用日志打到 stdout。Streamable HTTP 适合远程服务。远程部署时不能只连通接口还要考虑认证、授权、会话管理、限流和超时 [资料1]。我的取舍是 - 本地开发、IDE 插件、桌面 AI 客户端联调优先 stdio部署简单适合单机调用 - 团队共享测试环境、生产环境用 Streamable HTTP把 MCP Server 作为独立服务部署接入统一身份认证、网关限流和监控 - 如果未来要支持网页端或多租户访问HTTP 模式更容易做水平扩展和会话隔离。面试官可观测性呢模型调用 Tool 失败你怎么排查是参数问题、权限问题、RAG 召回问题还是传输问题候选人我会把一次 Tool 调用拆成几个可观测阶段请求进入、参数校验、授权检查、召回、重排、结果裁剪、响应返回。每个阶段打结构化日志并生成统一 traceId。关键指标包括调用量、错误率、P95 耗时、空结果率、平均返回片段数、被 schema 拒绝的请求数、越权拦截数。RAG 场景里还要单独看“空结果”和“低相关结果”。空结果不一定是系统错误可能是 query 与知识库不匹配但如果空结果率异常升高就要排查索引同步、切块策略、过滤条件是否过严。检索结果保留来源元数据也很重要否则无法做引用校验和问题追溯 [资料1]。关于返回长度我不会让 Tool 无限制返回原文。切块大小需要保留语义完整性同时避免不相关内容占用大量上下文 [资料1]。具体 top_k 上限、片段长度、超时阈值、重试策略应该结合业务 SLA、上下文窗口和压测结果确定不能拍脑袋写死。面试官还有什么关键取舍候选人一个核心取舍是“模型自主检索”和“流程确定性”之间的平衡。把 RAG 做成 MCP Tool 后模型可以按需调用适合开放问答、多轮追问和跨主题检索但调用次数和时机不完全可控可能出现重复检索、过早检索或检索词不准的问题。如果是强流程场景比如客服工单必须先检索标准 SOP 再回答可以由 Host 在模型调用前主动检索流程更可预测 [资料1]。实际落地中可以两者结合简单问题由 Tool 自主调用高风险或强 SOP 场景由 Host 预置检索上下文。另一个容易踩坑的点是“把检索文档当指令”。检索回来的文档内容是不可信数据其中的文字不能覆盖系统规则否则知识库中的恶意或错误文本可能诱导模型执行不该做的事 [资料1]。因此在 Tool 返回内容拼装时要明确标记这是“参考资料”并在上层提示中约束其用途。面试官点评考察点这道题不是单纯问 MCP 概念而是看候选人能否把 RAG 能力正确映射到 MCP 的能力模型理解 Tool、Resource、Prompt 的语义边界并在 Java SDK 落地时处理传输、安全、异常、可观测性和工程取舍。合格回答需要包含几个关键点 1. 能说清 MCP 客户端—服务端架构以及为什么知识检索应设计为 Tool而不是错误地用 Resource 或 Prompt 承载动态查询 [资料1][资料4] 2. 知道 schema 校验不等于安全必须在服务端做授权、输入校验、敏感信息保护和审计 [资料1] 3. 能区分 stdio 与 Streamable HTTP 的适用场景并知道 stdio 下日志不能打到标准输出 [资料1] 4. 返回结果保留来源元数据控制片段长度和召回范围理解 RAG 链路中的切块、召回、重排与上下文成本 [资料1] 5. 能说明 Tool 自主检索与 Host 前置检索的取舍不把某一种方案绝对化 [资料1]。加分项包括 - 能主动提到检索内容属于不可信数据不能覆盖系统规则 [资料1] - 能设计可观测性指标和 traceId方便排查“模型答非所问”到底是 Tool 没被调用、参数错误、权限不足还是召回质量问题 - 在 Java 实现上不臆造 SDK 细节而是用清晰的服务端注册接口、参数绑定和结果转换思路表达方案并能结合官方 Java SDK 文档进一步对接具体 API [资料2]。总结把知识库 RAG 检索封装为 MCP Tool表面上是“写一个接口”实质是在模型可控性、协议语义、安全边界和工程稳定性之间做设计。面试中回答到“能调通”只是第一层真正有落地经验的回答会把输入不可信、授权每次校验、stdio 日志坑、远程传输治理、来源元数据保留、结果长度控制和检索内容不可指令化这些细节讲清楚。对于使用 Java MCP SDK 的团队先把 Tool 边界和服务端防护做扎实再谈召回优化和多轮检索策略才是更稳妥的工程路径。参考资料[MCP 基础知识]MCP Java SDKMCP Python SDKTools