尧图网页设计 
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/pythonPython 编码规范 -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。一个简化的接口设计可以这样表达这里用版本无关的伪代码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 基础知识]ResourcesMCP Python SDKTools MCP 面试高频考点：用 Docker 与 Resources 沉淀可复用 Prompts 工作流，怎么答才落地
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/pythonPython 编码规范 -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。一个简化的接口设计可以这样表达这里用版本无关的伪代码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 基础知识]ResourcesMCP Python SDKTools