大厂 MCP 面试实录：本地 Server 远程化改造中的技术选型与落地实践

本文为模拟面试复盘形式，围绕「本地 MCP Server 改造为可远程访问服务」的业务场景展开，覆盖基础概念、技术选型、安全边界、异常处理等核心考察点。

面试官：候选人你好，今天我们的面试题围绕一个实际业务场景：公司目前有一套基于 MCP 的本地工具服务，通过 stdio 传输和本地 AI 应用（比如 IDE 插件）对接，现在需要改造为可远程访问的 SaaS 化服务，供多个租户的 AI 应用调用。请你先说说你会怎么整体规划这个改造方案，以及会用到哪些核心技术？

候选人：整体我会分三层来做改造：第一层是传输层替换，把原来仅支持本机子进程通信的 stdio 传输替换为支持远程调用的 Streamable HTTP 传输，这是 MCP 规范明确支持的远程传输方案[资料4]，比如用 Python SDK 开发的 Server，只需要修改传输配置，不需要改动 Tool 的实现代码，SDK 已经自动完成了 JSON Schema 生成和协议处理[资料2]；第二层是能力层保留，原有 Server 暴露的 Tools、Resources、Prompts 能力定义不需要改动，其中 Tools 的参数校验继续沿用 JSON Schema 标准，保证能力描述的兼容性；第三层是部署层封装，用 Docker 把改造后的 MCP Server 和依赖打包成镜像，方便多环境部署和扩缩容。同时会配套补充认证授权、限流、审计日志等生产级能力，满足多租户场景的安全要求。

面试官：你提到了用 JSON Schema 做参数校验、用 Docker 做部署，能不能具体说说这两者在改造过程中分别解决什么核心问题？有没有可能只用一个，不用另一个？

候选人：两者的分工非常明确，解决的是不同层面的问题。首先 JSON Schema 是 MCP 协议层面定义 Tool 输入输出的强制标准，不管是本地还是远程部署，Tool 的参数结构、类型、必填约束、返回格式都需要通过 JSON Schema 声明[资料1]，它解决的是「能力描述的标准化」问题：客户端可以根据 Schema 自动生成调用表单、做前置参数校验，不需要每个客户端重复实现解析逻辑，也能保证不同客户端调用同一 Tool 的行为一致。而 Docker 解决的是「运行环境的隔离与一致性」问题：原有本地 Server 可能依赖特定的 Python/Java 版本、系统动态库、第三方依赖，远程部署到不同服务器时很容易出现环境不一致导致的兼容性问题，Docker 把 Server 和所有依赖打包成轻量镜像，保证从开发、测试到生产的运行环境完全一致，还能快速实现多租户实例的隔离和扩缩容。 至于能不能只用一个：如果不用 JSON Schema，Tool 的参数校验就需要每个客户端自行实现，不仅开发成本高，还容易出现不同客户端对参数理解不一致的问题，同时不符合 MCP 协议对 Tool 定义的要求；如果不用 Docker，远程部署时环境一致性很难保障，多租户场景下用虚拟机隔离资源开销太大，无法满足弹性扩缩容的需求，所以两者是互补关系，不能互相替代。

面试官：MCP 的安全规范里明确提到「远程 Server 必须对每次请求执行授权检查，不能只判断用户是否已登录，Tool 的参数 schema 只是结构约束，不能代替服务端校验和授权」[资料1]。结合你选的 JSON Schema 和 Docker，你能说说具体怎么落地授权吗？如果出现参数注入的异常怎么处理？

候选人：授权会分成两层落地：第一层是传输层认证，用 API Key 或者 OAuth2.0 做身份校验，凭据通过 HTTP Header 传递，不会出现在 URL 或者请求体里，Docker 部署时凭据会通过密钥管理服务注入环境变量，不会硬编码在镜像中。第二层是业务层授权，每次调用 Tool 时，除了用 JSON Schema 做参数结构的合法性校验，还会额外校验当前用户是否有权限调用该 Tool、访问对应的资源范围，比如普通租户只能调用查询类 Tool，管理员才能调用写入类 Tool。 参数注入的异常处理上，首先要明确 JSON Schema 只能做结构层面的校验，比如校验参数是不是整数、是不是必填，无法做语义层面的校验[资料1]，所以服务端必须对高风险参数做额外的约束：比如文件路径参数要做白名单校验，SQL 参数要做预编译，Shell 参数要做命令注入过滤。如果检测到注入攻击，会直接返回 403 错误，同时记录审计日志。另外 Docker 层面可以配置资源限制，比如每个 Tool 调用的 CPU、内存配额，防止恶意调用耗尽服务器资源。

面试官：改造后的服务是远程部署的，出问题时排查成本比本地高很多，你怎么结合 JSON Schema 和 Docker 做可观测性？如果某个 Tool 调用超时了，你的重试策略是什么？

候选人：可观测性会从三个维度搭建：第一层是日志维度，每次 Tool 调用都会生成带唯一请求 ID 的日志，记录用户 ID、调用的 Tool 名称、脱敏后的参数、结果状态、耗时，通过 Docker 日志驱动收集到统一的日志平台，方便排查问题；第二层是 metrics 维度，用 Prometheus 采集每个 Tool 的调用次数、成功率、耗时、错误率，以及 Docker 容器的 CPU、内存、网络指标，配置告警规则；第三层是链路追踪维度，用 OpenTelemetry 把请求链路串起来，从客户端发起的请求到服务端执行 Tool 的全流程都可以追踪。 超时和重试的策略上，首先要区分 Tool 的幂等性：只有查询类等幂等的 Tool 才支持重试，有副作用的 Tool（比如删除、写入）绝对不允许重试，避免重复执行造成数据异常。超时时间会根据 Tool 的类型和业务 SLA 动态配置，比如查询类 Tool 超时设为 5 秒，写入类设为 10 秒，不会统一设置固定值。重试时会携带唯一的 request_id，服务端如果已经处理过该请求，会直接返回结果，不会重复执行，同时 Docker 层面的健康检查会自动剔除异常的容器实例，保证流量只发往健康的节点。

面试官：你这个方案有没有明确的适用边界？有没有什么容易踩坑的细节？

候选人：适用边界上，这个方案适合无状态或者轻量有状态的 MCP Server，如果是需要长时间保持本地连接、有大量本地状态的 Server（比如需要持久化本地数据库连接的场景），直接容器化会遇到状态丢失的问题，需要先把状态外置到分布式存储中再改造。关键取舍上，选择 Streamable HTTP 传输会放弃 stdio 的子进程启动模式，原有本地 Host 如果需要兼容，需要同时支持两种传输方式，会增加一定的客户端适配成本，但远程场景下这是必须的取舍。 容易踩坑的细节有三个：第一个是 JSON Schema 的兼容性问题，不同 MCP SDK 对 JSON Schema 版本的支持有差异，比如部分 SDK 不支持 $ref 引用等复杂特性，所以定义 Schema 时要尽量用基础类型和结构，避免使用不兼容的扩展特性。第二个是 Docker 的日志输出问题，MCP 协议要求调试日志写到标准错误（stderr），不能写到标准输出（stdout），否则会破坏 JSON-RPC 的消息格式[资料1]，很多开发者打包的时候忽略这点，把日志输出到 stdout，导致远程调用时协议解析失败。第三个是敏感信息泄露问题，JSON Schema 中定义的敏感参数（比如密码、API Key）不能出现在日志、Tool 返回值或者模型上下文中，审计日志必须对敏感字段做脱敏处理[资料1]。

面试官点评： - 考察点：① 对 MCP 客户端-服务端架构、传输方式选型的理解，能否根据业务场景匹配 stdio 和 Streamable HTTP 的适用场景；② 对 MCP 核心概念（Tools、JSON Schema）的掌握程度，能否区分 Schema 的结构约束和服务端校验的边界；③ 生产级工程化能力，能否考虑到远程部署的安全、异常处理、可观测性等非功能需求。 - 合格回答：能明确 stdio 仅适合本地场景、远程必须用 Streamable HTTP，知道 JSON Schema 是 Tool 定义的标准，知道 Docker 用于环境隔离，能提到基础的认证和参数校验。 - 加分项：能明确 JSON Schema 的结构校验和服务端语义校验的边界，能设计出分层授权、可观测性、幂等重试的具体方案，能指出日志输出、Schema 兼容性、敏感信息脱敏等实际落地中的易错点。

总结：本地 MCP Server 远程化改造的核心是传输层的平滑替换，同时严格遵循 MCP 协议规范保留能力层的定义，用 JSON Schema 保证能力描述的标准化，用 Docker 解决运行环境的一致性和隔离问题，最终落地时必须把安全边界、异常处理、可观测性纳入设计，避免只完成传输层改造就上线的低级错误。

参考资料

1. MCP 基础知识
2. MCP Python SDK | https://github.com/modelcontextprotocol/python-sdk
3. MCP Java SDK | https://github.com/modelcontextprotocol/java-sdk
4. Architecture | https://modelcontextprotocol.io/specification/2026-07-28/architecture