大厂 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、用户 ID），Server 侧校验凭证有效后才会执行变更。如果用户拒绝确认，直接返回拒绝结果，不执行任何操作；如果确认后执行变更失败，比如数据库连接超时、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，比如普通运维只能调用测试库的变更 Tool，DBA 才能调用生产库的；还要做限流和超时控制，防止恶意调用或者长时间占用资源，同时审计日志要记录请求的 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-sdk
- MCP Java SDK，公开链接：https://github.com/modelcontextprotocol/java-sdk
- Tools，公开链接：https://modelcontextprotocol.io/specification/2026-07-28/server/tools
