大厂 MCP 面试实录：可复用 Prompts 工作流服务的架构设计与落地
本文采用技术岗模拟面试复盘形式，围绕「为团队沉淀可复用 MCP Prompts 工作流」的业务场景展开，考察候选人对 MCP 协议核心能力、远程服务治理、安全边界的综合理解。
面试官：你好，今天我们考察的业务场景是：团队有多个业务线的 AI 应用，都需要用到「代码审查」「周报生成」「数据报表解读」这类标准化的 Prompt 工作流，希望基于 MCP 协议沉淀一套公共服务，避免各业务线重复开发。请你先给出整体的架构设计思路。
候选人：我的整体设计是基于 MCP 客户端-服务端架构，将标准化 Prompts 封装为独立的 MCP Server 对外暴露，各业务线的 AI 应用作为 MCP Client 接入。 首先，能力选型上选择 MCP 的 Prompts 能力而非 Tools，是因为这类场景的核心是提供模板化的提示词工作流，没有副作用操作，符合 MCP 协议「按语义选择能力」的要求，不会出现把只读资料强行设计为 Tool 的问题资料1。 传输层选择 Streamable HTTP，因为服务是远程部署，各业务线的 AI 应用分布在不同集群，stdio 传输仅适合本机子进程通信的场景，不满足要求资料1。 针对远程服务的常见问题，我会补充超时重试、OAuth 2.1 认证、幂等控制、可观测性四类治理能力，保证服务的可用性和安全性。
面试官：你提到用 Prompts 而不是 Tools 封装工作流，能具体说下两者的适用边界吗？如果某个工作流需要根据用户输入动态拉取内部知识库内容，是不是应该把整个工作流改成 Tool？
候选人 ：核心结论是：Prompts 和 Tools 的适用边界由能力语义决定，动态拉取知识库不需要把整个工作流改成 Tool，采用「Prompts 模板 + 独立 Tool」的组合方案即可。 具体来说，Prompts 是服务器向客户端提供的模板化消息/工作流 ，由客户端（用户或 Host）显式选择、传入参数后直接使用，适合预定义的、无副作用的标准化流程；Tools 是模型可自主发起的带副作用的操作，适合需要动态决策、会修改状态或调用外部能力的场景资料1。 如果工作流需要动态拉取知识库，只需把「内部知识库检索」封装为独立的 MCP Tool，在 Prompts 模板中通过占位符引用该 Tool，当用户选择该 Prompts 时，Host 会自动填充 Tool 的检索结果作为上下文。这样既保留了 Prompts 的模板化优势，又实现了动态能力扩展。 这里需要注意，RAG 检索到的文档属于不可信数据，其中的指令不能覆盖系统规则，所以 Tool 返回的检索结果需要做内容校验，避免注入恶意提示词资料1。
面试官：现在服务是远程部署的，你会怎么处理超时、重试和幂等的问题？有没有容易踩坑的细节？
候选人：核心原则是「重试仅限幂等操作，非幂等操作做幂等控制」，分三层治理： 1. 传输层超时：MCP Client 配置连接超时和读取超时，读取超时时间需要大于服务端最长处理时间，避免网络波动导致正常请求被误判为超时。具体数值需要根据业务 SLA 和压测结果确定，不能直接拍脑袋设置资料1。 2. 重试策略：仅对纯读操作开启重试，比如 Prompts 模板获取、知识库检索这类无副作用的操作，天然幂等，可以配置指数退避重试，重试次数根据业务可用性要求确定。如果工作流中包含生成文档、发送通知这类有副作用的 Tool，绝对不能开启自动重试，避免重复执行。 3. 幂等控制：对于包含有副作用操作的请求，要求客户端生成唯一的请求 ID，服务端通过请求 ID 做去重，保证同一个请求只会被执行一次。 最容易踩坑的点有两个：一是把所有请求都配置为重试，导致有副作用的操作重复执行，造成数据错误；二是超时时间设置过短，比如 Prompts 模板如果包含大量动态参数拼接，处理时间可能波动，超时过短会导致正常请求大量失败，影响用户体验。
面试官：多业务线接入这个服务，你会怎么设计认证授权？为什么选 OAuth 2.1 而不是更简单的 API Key？
候选人：核心结论是：优先选择 OAuth 2.1 的授权码模式（配合 PKCE 增强安全性）做认证，结合 Scope 做细粒度授权，仅在极简单场景下考虑 API Key。 具体原因和设计思路如下： 1. 选型原因：API Key 的权限粒度太粗，只能做到全有或全无，无法实现「业务线 A 只能调用代码审查 Prompts，业务线 B 只能调用周报生成 Prompts」这类细粒度控制；而且 API Key 泄露后很难做吊销，风险极高。OAuth 2.1 支持 Scope 维度的权限控制，access token 可以过期、可以主动吊销，安全性更高，而且 Spring AI MCP 已经提供了现成的 OAuth 2.0 集成，落地成本低资料2。 2. 安全边界设计：服务端需要对每次请求执行授权检查，不能只判断用户是否已登录，需要校验 token 的有效性、Scope 是否包含请求的 Prompts 权限资料1。同时，Prompts 参数中的敏感信息、Tool 返回的敏感数据都不能出现在日志、返回值或模型上下文中，审计日志需要记录调用者、调用时间、调用的 Prompts 版本、资源范围和结果状态，对敏感字段做脱敏资料1。 3. 适用边界：如果团队规模很小，只有少量业务线接入，且对权限粒度要求不高，也可以用 API Key 做简单认证，但随着业务线增加，OAuth 2.1 的细粒度控制优势会更明显。
面试官：如果服务端更新了某个 Prompts 模板，部分业务线的客户端还在用旧版本，你会怎么处理？怎么保证服务的可观测性？
候选人：核心方案是「版本化 Prompts + 灰度发布 + 全链路可观测」： 1. 版本化管理：每个 Prompts 模板都携带版本号，客户端调用时可以指定版本，不指定则默认使用最新稳定版。服务端更新模板时生成新版本，不会覆盖旧版本，给业务线留足够的升级过渡期。如果业务线需要持续使用旧版本，可以继续指定版本调用，直到主动升级。 2. 灰度发布：模板更新后先给小流量灰度，监控错误率、耗时等指标，确认无问题后再全量发布，避免全量更新导致大面积故障，具体放量比例根据业务风险承受能力确定。 3. 可观测性设计：① 链路追踪：每个请求携带唯一的 trace ID，从客户端到服务端全链路透传，方便排错；② 指标监控：监控 Prompts 调用的 QPS、耗时、错误率、重试次数，以及每个模板的调用占比、版本分布；③ 审计日志：记录调用者、调用时间、模板版本、脱敏后的参数、结果状态，满足安全审计要求资料1。 异常处理上，如果客户端请求的版本不存在，要返回明确的错误码，附带当前可用的版本列表，不要直接返回 500 错误，方便客户端快速定位问题。
面试官：现在团队希望在这个基础上，支持用户自定义 Prompts 模板，并且可以分享给其他业务线使用，你会怎么设计这个功能？要注意哪些问题？
候选人：核心设计是在现有 MCP Server 的基础上增加「Prompts 生命周期管理」能力，重点解决权限控制和兼容性问题： 1. 功能设计：提供 Prompts 的增删改查接口，用户创建模板时可以指定可见范围：私有、部门可见、全团队公开。每个模板携带创建人 ID、版本号，修改时生成新版本，不会覆盖旧版本，避免影响正在使用的业务线。 2. 分享机制：支持两种分享方式：① 复制模板：接收方获得模板的独立副本，可以自行修改不影响原模板；② 引用模板：接收方直接引用原模板，原模板更新后自动同步，适合需要保持一致的标准化工作流。 3. 安全与兼容性：用户自定义的 Prompts 需要做内容审核，避免注入恶意指令；自定义模板可调用的 Tool 范围需要受创建人的权限限制，比如普通用户不能调用有副作用的删除类 Tool，高风险操作需要用户确认资料1。同时，如果采用引用同步的方式，需要做模板兼容性校验，避免新版本模板的参数变化导致调用方报错。 关键取舍：如果团队对模板稳定性要求高，建议默认只支持复制分享，不开放自动同步，让业务线自主选择是否升级，避免原模板更新导致下游故障。
面试官点评
考察点
- 对 MCP 三类核心能力（Tools、Resources、Prompts）的语义区分，避免滥用能力；
- 远程 MCP 服务的治理能力，包括超时重试、幂等控制、认证授权；
- MCP 安全边界的理解，包括授权检查、敏感数据脱敏、不可信输入处理；
- 工程化落地能力，包括版本管理、灰度发布、可观测性设计。
合格回答
能基于 MCP 协议特性选择合适的传输方式和核心能力，明确超时重试仅适用于幂等操作，知道 OAuth 2.1 相比 API Key 的多租户优势，能考虑到安全审计、敏感数据脱敏等基础安全要求，整体架构符合 MCP 协议规范。
加分项
能结合 RAG 场景将知识检索封装为独立 Tool 与 Prompts 配合使用，提到 Prompts 版本化和灰度发布的能力，考虑到自定义模板的权限控制和兼容性问题，能结合 Spring AI MCP 的现有集成降低落地成本。
总结
本场景下 MCP 的核心价值是将分散的 Prompt 工作流标准化、服务化，避免各业务线重复开发，同时通过统一的协议让不同的 AI 应用可以无缝接入。超时重试、OAuth 2.1、幂等控制是远程 MCP 服务落地的必要治理能力，没有万能的最优配置：比如重试次数、超时时间、权限粒度、灰度放量比例都需要根据业务的 SLA、安全要求和团队规模权衡确定，需要通过压测和实际运行数据持续优化。最容易踩的坑是滥用重试导致副作用操作重复执行，以及忽略 Prompts 的版本管理导致更新影响存量业务，需要在设计阶段就纳入考虑。