大厂 MCP 面试实录内部 REST API 封装为可审计 Tool 的落地方案设计本文为模拟面试复盘形式围绕「将内部订单查询、售后处理类 REST API 封装为可审计 MCP Tools供 AI 助手自主调用」的业务场景展开由浅入深考察候选人对 MCP 协议规范、安全边界、可观测性及技术栈协作的理解。面试官你好我们今天聚焦的业务场景是公司内部有多套订单查询、售后处理的 REST API需要封装成 MCP Tools 供 AI 助手根据用户自然语言需求自主调用同时要求所有调用行为可审计、可追溯技术栈限定使用 Docker、向量检索与重排、OpenTelemetry。你先说说整体的架构设计思路候选人整体架构分为四层各技术栈分工明确无冗余设计 1.MCP Server 适配层作为核心网关将内部 REST API 封装为符合 MCP 规范的 Tools定义清晰的 Tool 名称、描述与输入 Schema负责参数校验、权限校验、API 调用与结果返回同时生成审计日志所需的原始数据[资料1]。 2.Docker 容器层负责 MCP Server 的部署与隔离将 Server 程序、依赖、敏感配置如 API 密钥、内网地址打包为镜像实现环境一致性同时通过容器隔离避免敏感配置泄露到宿主机。 3.向量检索与重排层作为非核心辅助能力不参与主调用链路主要用于两个场景一是将脱敏后的历史成功 Tool 调用用户 query、参数、结果向量化新请求到来时召回相似案例经重排后作为上下文返回给模型降低参数填写错误率二是调用异常时召回相似异常案例辅助排错。 4.OpenTelemetry 可观测层为每个请求生成唯一关联 ID贯穿从模型发起调用、参数校验、REST 调用到结果返回的全链路将审计字段作为 Span 属性上报支持全链路追踪与审计查询。面试官你提到用向量检索和重排这个场景下它的核心作用是什么和传统 RAG 的文档召回有什么区别候选人这里的向量检索核心作用是降低模型调用错误率辅助异常排错和传统 RAG 有本质区别 传统 RAG 是召回外部知识文档补充模型的领域知识而这里的召回对象是工具调用的历史行为数据目的是辅助工具调用流程。具体来说模型填写 Tool 参数时容易因语义理解偏差填错值比如用户问“查上周订单”模型可能填错时间范围参数我们将脱敏后的历史成功调用向量化新请求时召回 Top 相似案例经交叉编码器重排后将 Top 匹配的调用示例作为上下文返回给模型相当于提供“调用模板”能有效降低参数错误率。调用异常时则将异常请求的 query、错误信息向量化召回相似已处理异常案例为运维或模型提供排错参考。面试官那向量检索的数据源是什么什么时候更新如何避免敏感数据泄露候选人数据源仅收录脱敏后的工具调用元数据包括用户 query 语义向量、Tool 名称、脱敏后的参数结构、结果状态码、错误类型不收录任何明文敏感业务数据如用户身份证号、订单金额、手机号入库前会做统一的敏感字段过滤。更新策略为双通道一是每日凌晨全量更新前一天的调用记录二是每次 Tool 调用完成后异步增量写入脱敏后的记录保证召回时效性。风险控制上向量库仅对内网 MCP Server 开放禁止外部访问入库前做二次敏感校验即使向量库被非法访问也不会泄露明文敏感数据。面试官你提到 MCP Server 要做参数校验但模型传入的参数是不可信的除了 Schema 结构校验还需要做什么和内部 REST API 原有的校验逻辑是什么关系候选人参数校验需要做三层不能仅依赖 MCP 层的 Schema 校验 第一层是 MCP 层的结构校验用 Tool 输入 Schema 拦截参数类型错误、必填项缺失等明显问题第二层是业务权限校验比如订单查询 Tool 需要校验查询的订单是否属于当前登录用户不能跨用户查询需结合用户身份信息做授权不能信任模型传入的参数[资料1]第三层是内部 REST API 的原有业务校验作为最后一道防线比如校验订单号是否存在、用户是否有操作权限。另外退款、订单取消等高风险不可逆操作必须向用户明确说明操作影响执行前要求用户确认不能因请求来自 AI 应用就默认可信[资料1]。面试官审计日志具体要记录哪些内容怎么和 OpenTelemetry 结合实现全链路可追溯候选人审计日志需记录四个核心要素谁调用的用户 ID、模型版本、请求来源、什么时候调用的毫秒级时间戳、调用了什么Tool 名称、版本、脱敏后的参数、结果怎么样调用状态、错误码、耗时、脱敏后的结果摘要。和 OpenTelemetry 的结合方式是每个请求生成唯一 correlation ID贯穿全链路每个环节的 Span将审计字段作为 Span 属性上报支持通过 correlation ID 查询全链路调用日志。所有敏感字段在上报前必须脱敏不能出现在 Span 属性或日志中避免泄露[资料1]。面试官如果出现内部 API 超时、向量检索服务不可用、OpenTelemetry Collector 宕机等异常你的方案怎么处理候选人核心原则是核心链路不中断辅助能力可降级审计数据不丢失 - 内部 REST API 超时超时时间需根据业务 SLA 和压测结果确定超时后返回明确错误信息给模型同时将异常请求写入死信队列供后续排查记录审计日志。 - 向量检索服务不可用向量检索是辅助能力直接跳过召回重排步骤正常处理 Tool 调用请求同时上报告警待服务恢复后补录历史数据不影响核心流程。 - OpenTelemetry Collector 宕机MCP Server 先将审计日志写入本地磁盘待 Collector 恢复后同步上报避免审计数据丢失同时上报告警。面试官现在需要支持多租户不同租户的 API 地址、权限规则、审计要求都不一样你怎么调整架构候选人主要在三个层面扩展 1. MCP Server 层增加租户上下文解析模块从请求认证信息中提取租户 ID动态加载对应租户的 API 地址、权限规则、脱敏规则、审计存储配置Tool 调用逻辑按租户 ID 隔离。 2. 向量检索层为不同租户的调用记录分配独立命名空间实现数据隔离召回时仅返回对应租户的历史案例。 3. OpenTelemetry 层在 Span 中添加租户 ID 标签审计日志增加租户 ID 字段支持按租户查询调用记录。部署层面可通过容器编排实现租户实例的独立扩缩容与资源隔离。面试官这个方案有什么适用边界、关键取舍和容易踩坑的细节候选人 -适用边界当前方案适合内部使用的、需模型自主调用内部 API 的场景若是对外公开的 MCP 服务还需补充认证授权、限流熔断、WAF 防护等额外安全能力。 -关键取舍向量检索与重排会引入少量额外延迟若业务对延迟要求极高可关闭该能力直接走核心调用链路审计日志会占用存储空间需根据调用量配置日志生命周期管理策略容器化部署会增加运维复杂度无容器运维经验的团队可先从二进制部署开始后续再迁移。 -容易踩坑的细节若使用 stdio 传输方式部署 MCP Server调试日志必须写到标准错误stderr不能写到标准输出stdout否则会破坏 JSON-RPC 通信格式导致通信失败[资料1]。面试官点评 -考察点首先考察候选人对 MCP 核心架构与能力边界的理解能否区分 Tools、Resources、Prompts 的适用场景避免把只读资源强行封装为有副作用的 Tool其次考察安全边界意识能否意识到模型传入参数不可信需要多层校验与授权审计日志需脱敏第三考察技术栈的协作能力能否明确各技术栈的分工而非硬拼技术第四考察异常处理与可扩展性的设计思路。 -合格回答能明确 MCP Server 作为适配层的核心作用知晓审计日志的核心要素能区分核心链路与辅助能力知道异常场景需做降级处理。 -加分项能清晰说明向量检索重排的具体价值、多租户隔离方案、敏感字段脱敏要求、stdio 传输的日志坑、关键取舍的权衡逻辑说明具备实际落地经验而非仅懂概念。总结将内部 REST API 封装为可审计 MCP Tools 的核心是将 MCP Server 作为内部 API 的合规网关既保留模型自主调用工具的灵活性又通过多层校验、权限控制、审计日志保障内部 API 的安全。Docker 负责部署隔离向量检索与重排作为辅助能力降低调用错误率OpenTelemetry 负责全链路可观测性各技术栈分工明确。落地时需根据业务 SLA、安全要求、团队技术栈做针对性调整比如高延迟场景可关闭向量检索能力小团队可先从二进制部署起步逐步迭代。参考资料MCP 基础知识MCP Java SDK | https://github.com/modelcontextprotocol/java-sdkMCP Python SDK | https://github.com/modelcontextprotocol/python-sdkMCP TypeScript SDK | https://github.com/modelcontextprotocol/typescript-sdk