大厂 MCP 面试实录：设计需人工确认的高风险 Tool 的工程化方案

本文为 MCP 技术岗模拟面试复盘，聚焦内部运维场景下高风险 MCP Tool 的设计问题，结合 OpenTelemetry、向量检索与重排、RAG 知识库三类技术的能力边界，考察候选人对 MCP 协议规范、安全设计、可观测体系与 RAG 工程实践的落地能力。

面试官：我们先明确业务场景：内部运维团队需要开发一个面向 DBA 的 MCP Server，暴露一个「生产环境数据库变更执行」的 Tool，该 Tool 一旦误调用会导致数据丢失，要求设计完整方案，需用到 OpenTelemetry、向量检索与重排、RAG 知识库三类技术，你先说下整体设计思路。

候选人 ：整体采用四层串行架构，从入参到执行全链路兜底： 1. MCP 协议层 ：按照 MCP 规范定义 Tool 的输入 schema，但仅做结构约束，服务端额外做权限、参数合法性校验；高风险操作必须展示具体影响，执行前强制用户确认，不自动执行。 2. RAG 合规校验层 ：用 RAG 知识库存储历史变更故障案例、合规规则、操作手册，调用 Tool 时自动检索当前变更请求对应的风险提示和合规要求，前置暴露风险。 3. 人工确认交互层 ：将变更影响、RAG 检索到的参考信息、操作内容脱敏后展示给用户，仅当用户主动确认后才触发执行逻辑，取消则直接终止流程。 4. OpenTelemetry 可观测层：全链路埋点追踪，从 Tool 调用、RAG 检索、用户确认到执行结果全流程记录，用于审计、排障和效果复盘。

三类技术的协作关系是：MCP Tool 作为入口触发流程，RAG 负责前置风险暴露，OpenTelemetry 负责全链路追踪，三者串联形成"校验-确认-执行-审计"的闭环。

可落地的 Tool 定义伪代码如下（版本无关接口设计，基于 MCP 通用规范）：

python 复制代码

# 高风险 Tool 定义示例
def register_high_risk_tool(server):
    server.add_tool(
        name="execute_db_change",
        description="生产环境数据库变更执行工具，执行前需人工确认",
        input_schema={
            "type": "object",
            "properties": {
                "db_name": {"type": "string", "description": "目标数据库名"},
                "change_sql": {"type": "string", "description": "待执行的SQL语句"},
                "change_reason": {"type": "string", "description": "变更原因"}
            },
            "required": ["db_name", "change_sql", "change_reason"]
        },
        handler=handle_db_change
    )

async def handle_db_change(arguments: dict):
    # 服务端二次校验，不依赖Schema约束
    if arguments["db_name"] not in ALLOWED_DB_LIST:
        return {"status": "error", "message": "数据库不在允许操作列表中"}
    # 触发RAG检索
    rag_result = await rag_retrieval(arguments)
    # 返回待确认状态，不执行实际操作
    return {
        "status": "pending_confirmation",
        "confirmation_content": f"请确认变更：\n数据库：{arguments['db_name']}\n风险提示：{rag_result['risk_tips']}\n参考来源：{rag_result['sources']}\n操作SQL：{mask_sql(arguments['change_sql'])}"
    }

面试官：为什么把 RAG 校验放在人工确认前面？如果 RAG 检索结果不准，误导用户做出错误决策怎么办？

候选人：首先把 RAG 放在确认前的原因是前置风险暴露比事后补救成本低：DBA 发起变更请求时，往往容易忽略同类型历史故障的共性风险，RAG 可以把历史上同库、同类型操作的故障案例、合规限制提前展示，降低误操作概率。针对检索不准的问题，我们做两层优化：第一是检索链路优化：采用混合检索（关键词+向量检索）+ 交叉编码器重排的方案，优先召回和当前变更的数据库名、操作类型、业务场景最相关的片段，重排后只取 Top3 高相关内容返回，避免无关内容干扰用户决策；所有返回的 RAG 片段都附带来源元数据，用户可点击查看原始规则文档，同时确认界面会明确标注「以下为历史参考信息，最终决策请以官方合规规则为准」，避免 RAG 内容覆盖系统规则，符合 MCP 安全边界里"检索文档是不可信数据，指令不能覆盖系统规则"的要求 $资料1$ 。第二是降级逻辑：如果 RAG 检索超时（可配置阈值，默认可根据业务 SLA 调整）或返回空结果，自动降级为展示通用的高风险操作确认提示，不会因为 RAG 故障跳过校验环节。

面试官：人工确认的交互逻辑具体怎么设计？如果用户确认后执行失败，或者用户中途取消，流程怎么处理？OpenTelemetry 具体要埋哪些关键点？

候选人：人工确认的逻辑是异步阻塞的：Tool 调用触发后，不会直接执行业务逻辑，而是返回一个「待确认」状态给 MCP Client，Client 需要将以下信息完整展示给用户：变更影响的业务范围、RAG 检索到的风险提示与来源、脱敏后的操作内容、确认/取消按钮。只有用户点击确认后，Client 才会再次调用 Tool 的执行接口，触发真正的变更逻辑；点击取消则直接终止流程，不产生任何副作用。如果用户确认后执行失败，会把失败原因、执行时的参数、RAG 检索结果同步返回给 Client，同时记录审计日志，不会暴露数据库密码、完整 SQL 等敏感信息；如果用户中途取消，流程直接终止，不执行任何操作，同时记录取消状态。 OpenTelemetry 的埋点覆盖全链路四个核心节点，所有 Span 关联同一个 TraceID： 1. Tool 入口 Span：记录请求ID、用户ID、Tool 名称、入参（敏感字段脱敏）、请求时间。 2. RAG 检索 Span：记录检索 Query、检索到的文档ID、重排得分、返回的片段、检索耗时、是否降级。 3. 用户确认 Span：记录确认结果（确认/取消）、确认时间、用户身份。 4. Tool 执行 Span：记录执行状态、执行时长、错误信息、影响行数等结果指标。同时按照 MCP 安全要求，审计日志会记录谁在什么时间调用了哪个 Tool、关键资源范围与结果状态，所有敏感字段脱敏 $资料1$ 。

面试官：如果这个 MCP Server 是远程部署的，不是本机 stdio 传输，还要考虑哪些额外问题？RAG 知识库更新后怎么保证检索到最新规则？有没有什么容易踩坑的细节？

候选人：远程部署时按照 MCP 规范需要额外考虑四类问题 $资料1$ ： 1. 认证授权：不能用简单的登录态判断，每次请求都要校验用户身份和操作权限，比如只有 DBA 组的用户才有权调用该 Tool，防止越权操作。 2. 会话管理：用户确认的会话有效期要合理设置，避免会话过期导致用户确认失效，或者被恶意利用。 3. 限流：高风险 Tool 要限制调用频率，避免短时间内被批量调用导致误操作扩散。 4. 超时控制：除了 RAG 检索的超时，整个 Tool 调用的超时也要设置，避免长时间占用资源。

RAG 知识库更新采用增量更新机制：每次规则文档、故障案例更新时，重新生成向量索引并打版本号，检索时默认使用最新版本的索引，如果需要追溯历史规则也可以指定索引版本，保证检索内容的时效性。容易踩坑的细节有三个：第一个是 MCP Server 的调试日志必须写入标准错误，不能写入标准输出，否则会破坏 JSON-RPC 的通信格式，导致 MCP 会话中断 $资料1$ 。第二个是 Tool 的参数 Schema 仅做结构约束，服务端必须做二次校验，比如用户传入的数据库名必须在允许操作的库列表中，不能直接拼接到 SQL 中执行，防止 SQL 注入攻击。第三个是远程部署时，凭据不能出现在日志、Tool 返回值或模型上下文中，避免敏感信息泄露。

面试官：你这个方案有没有适用边界？关键取舍是什么？

候选人 ：适用边界是需要人工确认的高风险、不可逆操作场景，比如生产数据库变更、权限变更、生产环境发布等，不适用于低风险、可自动执行的 Tool 场景，因为人工确认环节会降低操作效率。关键取舍是：用 RAG 前置校验和人工确认机制换误操作风险的降低，代价是会增加 Tool 调用的延迟（主要来自 RAG 检索耗时），我们通过设置 RAG 超时、降级逻辑、混合检索重排来平衡延迟和风险，具体的超时阈值、重排模型选择需要根据业务 SLA 和实际压测结果调整，没有通用的固定值。

面试官点评

考察点：① 对 MCP 协议规范的理解，特别是安全边界、Tool 设计原则、远程部署的要求；② RAG 与 MCP 结合的工程实践，包括检索质量优化、不可信输入处理、降级逻辑设计；③ 高安全等级系统的可观测、审计和异常处理能力。
合格回答：能覆盖高风险 Tool 的强制确认机制、基本的 RAG 校验逻辑、OpenTelemetry 核心埋点，明确 MCP 的安全要求，知道参数不能只靠 Schema 校验。
加分项：能说出混合检索+重排的优化方案、RAG 内容不可覆盖系统规则的边界、远程部署的额外安全要求、调试日志写入标准错误的易踩坑细节，以及审计日志的脱敏要求。

总结

本方案的核心是"前置校验、人工兜底、全链路可观测"，三类技术分工明确：MCP 协议负责能力暴露与安全边界约束，RAG 知识库+向量检索重排负责前置风险提示与合规校验，OpenTelemetry 负责全链路追踪与审计。该方案平衡了操作效率和风险控制，适合内部高风险操作的 Tool 化场景，后续可以根据实际使用数据优化 RAG 检索的准确率和重排策略，进一步提升风险提示的有效性。

参考资料

MCP 基础知识
Retrieval-augmented generation (RAG) in Azure AI Search：https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview
Tools（MCP 规范）：https://modelcontextprotocol.io/specification/2026-07-28/server/tools
MCP Python SDK：https://github.com/modelcontextprotocol/python-sdk