MCP 面试高频考点：把知识库 RAG 检索封装成 Tool，Java 落地要避哪些坑？

面试场景

面试官：我们先做一个贴近工程的题。假设团队已经有一套内部知识库 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 是模型可发起调用的操作，需要清晰名称、描述和输入 schema；Resources 是应用可读取的上下文，通常用 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 复制代码

// 伪代码：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());
        List<KnowledgeChunk> 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 SDK
MCP Python SDK
Tools