大厂 MCP 面试实录：设计需人工确认的高风险 Tool 与 RAG 知识库协作方案

大厂 MCP 面试实录设计需人工确认的高风险 Tool 与 RAG 知识库协作方案本文为模拟面试复盘形式围绕「设计需人工确认的高风险 MCP Tool 并结合 RAG 知识库提供规范参考」的业务场景展开由浅入深考察候选人对 MCP 能力边界、安全设计、RAG 协作与工程落地的掌握程度。面试官你好今天我们考察的业务场景是公司要开发内部运维助手需要暴露一个「生产环境数据库变更」的 MCP Tool这个操作高风险、不可逆要求结合内部运维 RAG 知识库提供变更规范、历史案例参考且必须经过人工确认才能执行。请你先给出整体方案设计。候选人我的整体方案是基于公开的 MCP Python SDK 实现 MCP Server[资料2]将能力拆分为三个部分第一是核心的「生产库变更申请」Tool负责接收模型传入的变更需求参数做基础的结构校验第二是内部封装的 RAG 检索能力用于召回对应的变更规范、同类型历史变更的成功率与风险点第三是变更预览与确认逻辑将检索到的参考信息、待执行的变更内容整理成预览卡片返回给 Host 侧由运维人员在 UI 上确认后Host 再调用「执行变更」的 Tool 完成实际操作全程记录审计日志。这里我把 RAG 检索能力封装为 Server 内部可调用的能力而不是让 Host 侧预检索是因为模型可以根据用户的实际需求自主判断是否需要检索灵活性更高也避免了 Host 侧预检索带来的无关内容占用上下文的问题[资料1]。面试官你提到选择 Server 侧按需调用 RAG 而不是 Host 预检索具体有哪些取舍如果模型频繁调用 RAG Tool 导致性能问题你怎么处理候选人两种方式的取舍核心是灵活性和可控性的平衡Host 预检索的优点是流程简单、可预测不会出现模型误调用导致的资源浪费缺点是模型无法根据上下文自主判断检索时机比如用户询问变更注意事项时若无需参考规范也会执行预检索浪费资源且若 RAG 知识库更新需要修改 Host 侧的配置灵活性差[资料1]。Server 侧按需调用的优点是模型可以自主决定何时检索知识库更新只需要修改 Server 侧配置缺点是如果模型判断失误频繁调用会增加延迟和 token 消耗。针对性能问题我会在 RAG Tool 的配置里设置合理的调用次数上限具体阈值需结合业务 SLA 与压测结果确定同时在 Tool 描述里明确说明适用场景引导模型只在需要参考规范的时候调用另外对 RAG 的召回结果做长度截断仅返回与需求高度相关的片段避免占用过多上下文。面试官这个 Tool 是高风险不可逆操作你提到需要人工确认具体怎么实现确认逻辑如果用户拒绝确认或者确认后执行变更失败怎么处理候选人确认逻辑的实现分两步首先「生产库变更申请」Tool 不会直接执行变更只会返回待确认的变更预览包括待执行的 SQL 语句、预估影响行数、召回到的规范条款、历史类似变更的成功率同时明确提示「该操作不可逆请确认是否执行」Host 侧收到这个返回后在运维助手的 UI 上弹出确认框展示所有预览内容用户点击确认后Host 再调用另一个独立的「执行生产库变更」Tool这个 Tool 需要额外传入用户确认的操作凭证比如操作工单 ID、用户 IDServer 侧校验凭证有效后才会执行变更。如果用户拒绝确认直接返回拒绝结果不执行任何操作如果确认后执行变更失败比如数据库连接超时、SQL 语法错误我会捕获异常返回具体的失败原因给 Host同时记录审计日志包含失败的 SQL、错误信息、操作人、时间方便后续排错[资料1]。面试官MCP 官方明确说明 Tool 的参数 schema 只是结构约束不能代替服务端校验你这里做了哪些校验另外 RAG 召回的文档属于不可信数据你怎么避免里面的恶意内容影响系统候选人服务端校验分为三层第一是结构校验用参数 schema 限制输入的字段类型比如变更类型只能是「字段修改」「表结构变更」「索引调整」表名必须是白名单内的业务表不能是系统表第二是语义校验对传入的 SQL 做关键字过滤禁止出现 DROP、DELETE、TRUNCATE 等危险操作禁止修改白名单外的表同时校验用户是否有对应库的变更权限不能只要是登录用户就能调用第三是凭证校验执行变更的 Tool 必须传入有效的确认凭证防止恶意调用[资料1]。对于 RAG 召回的不可信文档我会严格区分「参考内容」和「执行逻辑」所有变更的执行逻辑都是 Server 侧预定义的不会把 RAG 召回的内容直接拼接到 SQL 中执行RAG 的结果只作为预览信息展示给用户供用户参考同时 RAG 知识库只允许内部运维规范、历史变更工单进入外部导入的文档必须经过安全扫描过滤掉可能的恶意指令避免召回内容包含误导性信息[资料1]。核心 Tool 的参数 schema 可参考 MCP Tools 规范设计[资料4]伪代码示例如下{ name: prod_db_change_apply, description: 生产环境数据库变更申请仅返回预览信息不执行实际操作, inputSchema: { type: object, properties: { change_type: {type: string, enum: [字段修改, 表结构变更, 索引调整]}, target_table: {type: string, enum: [user_info, order_record, product_sku]}, change_content: {type: string} }, required: [change_type, target_table, change_content] } }面试官如果这个 MCP Server 用 stdio 传输部署在本地和远程用 Streamable HTTP 部署分别要注意什么问题尤其是日志和安全的差异。候选人stdio 传输是 Host 在本机启动子进程的方式协议消息走标准输出所以调试日志绝对不能打到标准输出必须写到标准错误否则会破坏 JSON-RPC 的消息格式导致通信失败[资料1]这个是内部开发时非常容易踩坑的点。远程用 Streamable HTTP 部署的话首先要做传输层认证比如用 API 密钥或者 OAuth2每个请求都要校验凭证有效性其次要做细粒度的授权不能只要认证通过就允许调用 Tool比如普通运维只能调用测试库的变更 ToolDBA 才能调用生产库的还要做限流和超时控制防止恶意调用或者长时间占用资源同时审计日志要记录请求的 IP、用户 ID、调用参数、结果敏感字段比如数据库密码必须脱敏不能出现在日志或者返回值里[资料1]。面试官你刚才的方案有什么适用边界有没有必须明确的取舍候选人这个方案的适用边界是首先适合需要人工介入的高风险、不可逆操作场景不适合全自动化的低风险操作因为人工确认会引入延迟其次依赖 RAG 知识库的内容质量如果知识库里的规范过时、历史案例不准确会导致召回的内容有误导性所以需要配套知识库的更新和审核流程。关键取舍是灵活性和安全性的平衡如果把 RAG 调用、变更逻辑都做的非常灵活会增加模型误判的风险如果限制非常严格比如只能调用固定的 SQL 模板又会降低工具的实用性。另外还有一个容易踩坑的点很多开发者会把 RAG 召回的内容直接作为执行依据比如直接把召回的历史 SQL 拿来执行这是非常危险的因为 RAG 的文档是不可信的[资料1]必须严格把参考内容和执行逻辑分离所有执行逻辑都必须在 Server 侧预定义不能依赖外部召回的内容。面试官点评考察点本次面试围绕具体业务场景逐步考察了四个核心能力① MCP 三类能力Tools/Resources/Prompts的语义区分有没有正确选择 Tool 承载有副作用的变更操作避免把只读的 RAG 能力强行设计为有副作用的 Tool[资料1]② 高风险 MCP Tool 的安全设计包括人工确认、服务端多层级校验、审计日志、不可信输入处理[资料1]③ RAG 与 MCP 的协作模式选择以及不同协作模式的取舍[资料1]④ 不同传输方式下的安全与可观测性设计以及异常处理逻辑[资料1]。合格回答能清晰区分 MCP 能力的适用场景知道高风险操作需要人工确认、服务端多层级校验能说出 RAG 两种协作模式的核心区别了解 stdio 传输的日志要求。加分项能明确区分 RAG 参考内容和执行逻辑的边界知道远程部署的细粒度授权、审计脱敏要求能说出参数 schema 不能代替语义校验的关键点了解知识库内容质量对方案的影响。总结本场景的核心设计原则是「模型负责决策人类负责确认服务端负责执行与校验」MCP 的 Tool 能力适合承载有副作用的业务操作但高风险操作绝不能将执行权完全交给模型[资料1]RAG 知识库作为辅助参考能力既可以封装为 MCP Tool 供模型按需调用也可以由 Host 预检索需要根据业务对灵活性和可控性的要求选择[资料1]所有外部输入包括模型传入的参数、RAG 召回的文档都必须视为不可信输入服务端必须做全链路的校验与边界约束才能保证方案的安全性[资料1]。参考资料MCP 基础知识MCP Python SDK公开链接https://github.com/modelcontextprotocol/python-sdkMCP Java SDK公开链接https://github.com/modelcontextprotocol/java-sdkTools公开链接https://modelcontextprotocol.io/specification/2026-07-28/server/tools