MCP 面试高频考点：用 Docker 与 Resources 沉淀可复用 Prompts 工作流，怎么答才落地

面试场景

面试官：假设你们团队已经在多个 AI 应用里反复手写类似的提示词流程，比如需求澄清、代码评审、故障复盘、文档总结。每次都要复制粘贴模板，还经常漏上下文、版本不一致。现在希望基于 MCP 做一套可复用的 Prompts 工作流服务，并且用 Docker 统一交付。你会怎么设计？

候选人：我会先把问题拆清楚：目标不是做一个"万能提示词仓库"，而是让 Host 应用能稳定发现、选择、组合和执行团队沉淀的工作流模板。基于 MCP 的能力边界，我会用 Prompts 暴露可复用工作流入口，用 Resources 提供只读上下文，用 Docker 做标准化部署和本地开发，尽量不把只读资料做成有副作用的 Tool $资料1$ 。

基础问题：MCP 三类能力怎么分工

面试官：先别讲部署。你刚才提到 Prompts、Resources、Tools，为什么不是全部做成 Tool？

候选人：结论是按语义分层。

第一，Prompts 适合做"用户可显式选择的模板化消息或工作流" $资料1$ 。比如"代码评审工作流""线上故障初筛""接口文档生成"，这些本质上是可复用的交互模板，用户或 Host 可以主动选择，而不是让模型自由决定何时调用。

第二，Resources 适合提供只读上下文，并且由 URI 唯一标识 $资料2$ 。比如团队规范、服务目录、代码仓库结构、历史案例、风险检查清单，这些都是给工作流补充背景的数据，不应该被模型"调用"产生副作用。

第三，Tools 才是模型可发起调用的操作，比如调用检索、创建工单、提交评审意见、查询监控数据 $资料1$ $资料4$ 。Tool 是 model-controlled，模型可以根据上下文自动发现和调用；Resources 更偏 application-driven，由 Host 决定如何纳入上下文 $资料2$ $资料4$ 。

如果把规范文档、模板片段、案例库都做成 Tool，会带来两个问题：一是语义错位，把只读上下文伪装成动作；二是增加模型误调用风险，因为 Tool 是模型可控入口，而不是稳定的上下文供给。

面试官点评： - 考察点：是否理解 MCP 三类能力的语义边界，而不是只背定义。 - 合格回答：能说清 Prompts 是模板工作流、Resources 是只读上下文、Tools 是可执行动作，并解释为什么不能混用。 - 加分项：能点出 user/application/model 三种交互模型的差异。

追问一：Prompts 工作流和 Resources 怎么协作

面试官：那在"代码评审"这个具体工作流里，Prompts 和 Resources 如何配合？请给出一个可落地的结构。

候选人：我会把一个工作流拆成三层。

第一层是 Prompt 入口。比如暴露一个"code-review"Prompt，它负责定义工作流步骤：收集变更范围、识别风险点、对照团队规范、输出评审意见。这个 Prompt 不直接硬编码所有规范，否则模板会越来越长，也难维护。

第二层是 Resources 上下文。每个 Prompt 在参数或描述中声明它依赖哪些资源，例如： - rc://team/standards/python：Python 编码规范 - rc://team/standards/security-review：安全评审清单 - rc://repo/service-order/schema：订单服务关键数据结构 - rc://cases/prod-incident/db-connection-leak：历史故障案例

这些资源由 URI 标识，Host 可以根据当前仓库、语言、风险级别决定加载哪些资源 $资料2$ 。这样 Prompt 保持稳定，上下文按场景动态拼装。

第三层才是必要的 Tool。比如代码评审可能需要一个"diff 检索"Tool 拉取变更文件，或一个"依赖漏洞查询"Tool 检查风险，但读取规范文档本身不应该是 Tool。

一个简化的接口设计可以这样表达，这里用版本无关的伪代码：

text 复制代码

Prompt:
  name: code-review
  description: 按团队规范执行代码评审，输出风险、建议和待确认问题
  arguments:
    - repo
    - change_id
    - review_focus
  attached_resources:
    - rc://team/standards/{language}
    - rc://team/standards/security-review
    - rc://repo/{repo}/schema

Resource:
  uri: rc://team/standards/python
  content: 团队 Python 规范正文 + 元数据
  metadata:
    version: 2026.03
    owner: backend-group

这里的关键取舍是：Prompt 负责流程骨架，Resources 负责可版本化、可组合的上下文，Tool 只保留真正需要执行外部动作的环节。这样做的好处是模板不会把业务知识写死，团队更新规范时只需要更新 Resources，不需要改每个 Prompt。

面试官：为什么不让 Prompt 直接把规范文本嵌进去？

候选人：因为复用和治理会变差。规范、案例、服务目录这些内容更新频率不同，所有者也不同。嵌进 Prompt 会导致版本漂移：A 同事本地用的是旧模板，B 同事 CI 里用的是新模板。Resources 用 URI 标识后，可以做版本、权限、审计和缓存，Host 也能决定是预加载、懒加载还是按用户选择加载 $资料2$ 。

面试官点评： - 考察点：是否能把抽象能力映射到真实工作流设计。 - 合格回答：能给出 Prompt、Resource、Tool 的职责边界和一个具体例子。 - 加分项：能解释版本治理、上下文裁剪和资源所有权问题。

追问二：用 Docker 怎么交付，为什么不是只靠本地 stdio

面试官：你提到用 Docker 统一交付。MCP 不是可以用 stdio 本地启动吗？为什么还要容器化？

候选人：结论是：本地开发可以用 stdio，团队共享和稳定运行更适合容器化交付，但要区分本地调试、团队服务和远程部署三种模式。

stdio 适合 Host 在本机启动子进程的场景，部署简单，协议消息走标准输出，调试日志走标准错误 $资料1$ 。但如果团队要沉淀统一的 Prompts 和 Resources，直接让每个人本地装 Python 依赖、拉模板仓库、配权限，环境不一致的问题会很快出现。

Docker 的价值主要有三点：

第一，环境一致性。MCP Server、模板加载器、资源读取逻辑、依赖版本都打包进镜像，开发者和 CI 使用同一个运行时，减少"我本地能跑"的问题。

第二，部署模式灵活。同一个镜像可以支持两种运行方式： - 本地模式：Host 通过 stdio 启动容器内的 MCP Server，适合桌面 AI 应用和本地调试。 - 服务模式：容器暴露 Streamable HTTP 接口，供团队内多个 Host 远程接入，适合统一治理 $资料1$ 。

第三，隔离边界。容器可以限制文件系统访问、网络访问和环境变量注入，降低 Server 读取敏感路径或误用凭据的风险。但要注意，容器隔离不能替代应用层授权。

一个典型启动方式可以抽象为： - 本地调试：Host 启动容器，把容器的 stdin/stdout 接成 MCP stdio 传输，日志输出到 stderr。 - 远程服务：容器内启动 HTTP 服务，路径按 MCP 规范暴露，前面接网关做认证、限流、审计。

面试官：如果容器里的 MCP Server 要读取 Resources，比如团队规范和仓库 schema，资源放在哪里？

候选人：有两种常见方式，要做取舍。

一种是镜像内置：把稳定、公开、版本跟随发布的资源打进镜像，比如团队通用规范、检查清单模板。优点是启动快、版本固定；缺点是更新要发镜像。

另一种是启动时挂载或远程拉取：把频繁变化的资源通过挂载目录、配置中心或内部文档服务加载，比如服务 schema、当前季度案例库。优点是更新灵活；缺点是要处理网络异常、缓存、权限和资源一致性。

我的建议是分层：稳定资源内置，动态资源通过受控 URI 提供。Resource 的 URI 不要直接暴露宿主机文件路径，避免路径遍历和越权读取；服务端必须把传入的资源标识符视为不可信输入，做约束和校验 $资料1$ 。

面试官点评： - 考察点：是否理解传输方式差异、容器化价值，以及交付与运行模式的关系。 - 合格回答：能说明 stdio 与 HTTP 的适用场景，以及 Docker 在一致性、部署、隔离上的作用。 - 加分项：能区分镜像内置资源与动态资源，并意识到路径安全问题。

追问三：异常、安全和可观测性怎么补

面试官：如果出现异常呢？比如 Resource 拉取失败、Prompt 参数缺失、远程服务超时，工作流会不会直接坏掉？

候选人：不能让工作流因为某个上下文缺失就整体不可用，需要分级处理。

第一，参数校验要在 Server 端做。虽然 Tool 可以通过 schema 描述输入，但结构约束不能代替服务端校验和授权 $资料1$ 。Prompts 也是一样，必填参数缺失时要返回明确错误，而不是把残缺模板丢给模型。

第二，Resources 要区分关键资源和可选资源。比如安全评审清单缺失，代码评审流程就不应继续；但某条历史案例加载失败，可以降级为"案例暂不可用"，并在结果中提示，避免误导模型给出过度确定的结论。

第三，远程部署时必须考虑认证、授权、会话管理、限流和超时 $资料1$ 。不能因为请求来自 AI 应用就默认可信 $资料1$ 。审计日志要记录谁在什么时间调用了哪个 Prompt、读取了哪些关键 Resource、调用结果如何，同时对敏感字段脱敏 $资料1$ 。

第四，日志不能污染协议通道。stdio 模式下，MCP 消息走标准输出，调试日志必须写标准错误，否则会破坏 JSON-RPC 通信 $资料1$ 。很多团队第一次接 MCP 时容易踩这个坑：把 print 调试信息打到 stdout，导致客户端解析失败。

第五，资源内容本身也要视为不可信数据。即使 Resources 来自内部文档，也可能包含过期规则、错误指令或被污染内容。RAG 场景下也强调检索文档是不可信数据，其中的指令不应覆盖系统规则 $资料1$ 。所以 Prompt 模板里要明确：Resources 提供参考依据，最终结论必须遵守系统规则和用户确认。

面试官：还有什么容易忽略的取舍？

候选人：一个重要取舍是"上下文丰富度"和"上下文噪声"的平衡。Resources 很容易越挂越多，导致 Prompt 过长、重点模糊。MCP 的 Resources 是由 Host 决定如何纳入上下文 $资料2$ ，所以服务端应提供资源元数据，比如主题、版本、更新时间、适用范围，让 Host 或上层工作流做裁剪，而不是一股脑全塞进去。

另一个取舍是本地 stdio 与远程 HTTP 的选择。本地模式简单、低延迟、适合个人开发；远程模式便于统一治理，但要承担认证、限流、多租户和网络故障成本。团队初期可以先用 Docker 封装本地 stdio Server，等规范和权限模型稳定后再升级为远程服务。

面试官点评： - 考察点：异常降级、安全边界、传输细节和工程取舍。 - 合格回答：能覆盖参数校验、资源分级加载、远程安全、审计日志和 stdout/stderr 区别。 - 加分项：能提到不可信上下文、上下文裁剪，以及本地到远程的演进路径。

总结

面试官最后总结：这道题看起来是在问"怎么做 Prompt 模板"，实际考的是三层能力：

协议语义：Prompts 负责可显式选择的工作流，Resources 负责只读上下文，Tools 负责模型可调用动作，不能为了方便把所有能力都做成 Tool $资料1$ $资料2$ $资料4$ 。
交付方式：stdio 适合本地子进程，Docker 解决环境一致性和部署标准化，Streamable HTTP 适合远程共享服务，但要补齐认证、授权、限流和超时 $资料1$ 。
工程边界：参数 schema 不是安全边界，资源标识符和检索内容都不可信；日志不能写乱，审计不能漏，上下文不能无限堆。

一个可落地的团队方案通常是：用 Prompts 定义稳定工作流骨架，用 URI 标识的 Resources 管理可版本化上下文，用少量 Tools 连接外部系统；用 Docker 同时支持本地 stdio 调试和远程 HTTP 服务；对关键资源做强校验和审计，对可选资源做降级，对所有外部输入保持不信任。

最容易踩坑的细节，是把调试日志写到标准输出。在 stdio 传输下，这会直接破坏 JSON-RPC 通信，导致客户端出现看似莫名其妙的解析错误 $资料1$ 。这类问题不复杂，但在第一次接入 MCP 时非常常见。

参考资料

$MCP 基础知识$
Resources
MCP Python SDK
Tools