MCP 面试高频考点：如何用 JSON Schema、OAuth 2.1 与 OpenTelemetry 落地可复用 Prompts 工作流

MCP 面试高频考点：如何用 JSON Schema、OAuth 2.1 与 OpenTelemetry 落地可复用 Prompts 工作流

面试场景

面试官：假设你所在团队已经接入多个 AI Host，大家都在重复写"需求澄清---检索资料---生成方案---自检输出"这类提示词流程。现在希望沉淀一套团队级、可复用、可审计的 MCP Prompts 工作流，而不是把模板散落在各个客户端里。你会怎么设计？请先给结论，再展开。

候选人：结论先说：我会把这类稳定、可复用、面向用户显式触发的流程定义为 MCP Server 的 Prompts 能力，而不是 Tool 或 Resource；用 JSON Schema 约束 Prompt 入参、返回结构和工作流节点配置；远程部署时用 OAuth 2.1 做用户级授权，而不是只做登录校验；再用 OpenTelemetry 把"用户选择哪个 Prompt、传入什么参数、调用了哪些 Tool/Resource、最终是否成功"串成一条可观测链路。这样做的核心目标是：复用、安全、可排错。

面试官：先别急着上组件。为什么这里应该选 Prompts，而不是 Tool？很多人会觉得工作流就是让模型去调用一系列操作，放 Tool 里也能跑。

候选人：这是语义边界问题。MCP 的三类能力分工很明确：Tools 是模型可调用的操作，适合有副作用或需要执行的动作；Resources 是只读上下文，通常用 URI 标识；Prompts 是用户可显式选择的模板化消息或工作流 资料1。团队沉淀的"需求澄清模板""代码评审模板""事故复盘模板"本质上是用户主动发起、带固定步骤和参数槽位的交互入口，它本身不是操作，也不是单一资料，所以更适合暴露为 Prompts。

如果硬做成 Tool，会有两个问题：第一，模型可能在不恰当时机自动调用它，用户体验不可控；第二，Tool 更强调执行语义，容易把只读准备步骤和有副作用动作混在一起，后续做权限和审计会更乱。当然，Prompt 工作流内部可以再调用 Tool 检索知识库、读取 Resource，但入口层应保持"用户显式选择"的语义 资料1。

基础问题：Prompt 工作流长什么样

面试官：那你说的"可复用 Prompts 工作流"在协议层具体包含什么？

候选人：一个可落地的 Prompt 工作流至少包含四部分。第一是 Prompt 元数据：稳定 ID、显示名称、适用场景、版本号。第二是输入契约：用 JSON Schema 定义必填参数，例如"业务背景""目标语言""输出长度""是否需要引用来源"，并对枚举、长度、格式做基础约束。第三是工作流定义：不是把整段提示词写死，而是拆成步骤，例如"澄清缺失信息 → 调用检索 Tool → 组装上下文 → 生成草稿 → 自检格式"。第四是输出约定：告诉 Host 最终返回给用户的内容结构，以及是否附带引用、下一步建议、需要用户确认的风险点。

这里我会特别注意一个边界：JSON Schema 只能做结构和格式校验，不能代替服务端业务校验和授权。比如 Prompt 里允许传入"要检索的文档空间"，服务端仍要检查当前用户是否真的能访问那个空间，不能因为参数长得合法就放行 资料1。

面试官：给一个不绑定具体 SDK 版本的接口设计示例。

候选人：可以用版本无关的伪代码表达：

Prompt:
  id: "team.requirement.draft.v1"
  title: "需求方案草稿生成"
  description: "适用于产品、研发在立项前生成结构化需求草稿"
  input_schema:
    type: object
    required: ["background", "audience"]
    properties:
      background: { type: "string", minLength: 1 }
      audience: { type: "string", enum: ["dev", "pm", "leader"] }
      need_citations: { type: "boolean", default: true }
      resource_scope: { type: "string", pattern: "^kb/[a-z0-9-]+$" }
  steps:
    - name: validate_input
    - name: clarify_missing_fields   # 必要时先反问用户
    - name: retrieve_docs            # 调用检索 Tool
    - name: render_prompt
    - name: run_self_check
  output:
    type: "prompt_messages"
    include_citations: true
    require_user_confirmation_before_side_effect: true

这个设计的关键不是代码写法，而是把"输入契约""步骤""输出约束"显式化，方便不同 Host 复用，也方便后续做审计和观测。MCP 本身在协议层广泛使用 JSON Schema 做校验，并提供官方 JSON Schema 供工具链使用 资料4。

追问一：远程部署时安全怎么做

面试官：如果这个 MCP Server 不是本机子进程，而是部署成团队内部远程服务，供多个 Host 连接，认证授权怎么设计？

候选人：结论是：传输层可以用 Streamable HTTP，认证授权层采用 OAuth 2.1，做"每次请求、每个能力、每个资源范围"的细粒度授权，而不是"登录一次就全放行"。

原因很直接：stdio 适合 Host 在本机启动子进程的场景；远程服务更适合 Streamable HTTP，但远程部署必须额外考虑认证、授权、会话管理、限流和超时 资料1。MCP 客户端和服务端可以协商认证授权策略 资料4，而 Spring AI MCP 也提供了 OAuth 2.0 与 API Key 的安全支持 资料2。在这个场景里，我会优先选择 OAuth 2.1，因为我们需要区分用户身份、托管端身份、Prompt 访问范围和下游资源范围。

具体分层上，第一层是客户端认证：Host 或 MCP Client 要证明自己是谁；第二层是用户委托：用户登录后，客户端拿到访问令牌；第三层是能力授权：不是所有 Prompt 都对所有人开放，例如"事故复盘模板"可能只对 SRE 和研发负责人开放；第四层是下游授权：Prompt 工作流内部调用检索 Tool 时，仍要按资源范围校验，比如 resource_scope 只能访问用户有权限的知识库。

面试官：你刚才提到"不能只判断是否登录"，为什么？

候选人：因为登录只能证明用户身份存在，不能证明他能执行这次操作。MCP 安全边界里有个很重要的原则：服务端必须把模型传入的文本视为不可信输入；远程 Server 应对每次请求执行授权检查，不能只判断用户是否已登录 资料1。举个例子，用户已登录不代表他能读取其他团队的文档空间，也不代表他能调用带有写操作的 Tool。Prompt 工作流虽然入口是模板，但内部可能拼接参数、调用检索、甚至触发高风险动作，所以授权点要落在每个步骤，而不是只放在连接建立时。

还有一个容易踩坑的细节：凭据不能出现在日志、Tool 返回值或模型上下文中，审计日志要记录谁在什么时间调用了哪个能力、访问了什么资源范围、结果如何，但敏感字段必须脱敏 资料1。如果把 Bearer Token、用户邮箱、内部资源 ID 直接打进模型上下文，后续不仅会泄露，还可能被模型误写进输出。

追问二：异常、可观测性和取舍

面试官：如果出现异常呢？比如 Prompt 参数合法，但检索 Tool 超时；或者用户传了一个看似正常、实际越权的 resource_scope；或者 Host 端只支持部分能力，你怎么保证工作流可排错？

候选人：这里必须上 OpenTelemetry，但不是简单打日志，而是做跨层链路关联。我的做法是给一次 Prompt 调用分配一个 trace context，从用户在 Host 中选择 Prompt 开始，一路贯穿：参数校验、授权检查、Prompt 渲染、Tool 调用、Resource 读取、最终返回。每一步都记录标准化属性：mcp.prompt.id、mcp.prompt.version、mcp.user.id（脱敏）、mcp.client.id、mcp.transport、mcp.tool.name、mcp.resource.uri、mcp.auth.scope、mcp.result.status。

异常处理上要分三类。第一类是输入类异常：JSON Schema 校验失败时，直接返回结构化错误，告诉 Host 哪个字段缺失或格式不对，而不是让模型猜。第二类是授权类异常：resource_scope 越权时，要返回明确的"无权限访问该范围"，不能把内部目录结构、存在性信息泄露出去。第三类是依赖类异常：检索 Tool 超时、下游服务不可用时，工作流要支持降级，例如返回"资料检索暂不可用，请缩小范围或稍后重试"，而不是把底层堆栈抛给模型。超时、重试、限流阈值不能拍脑袋定，应该结合业务 SLA、风险评估和压测结果确定。

面试官：还有什么取舍？你这个方案的边界在哪里？

候选人：有三个关键取舍。

第一，Prompts 适合稳定、可复用、由用户显式触发的流程；如果是高度动态、需要模型自主决策何时调用的能力，更适合做成 Tool。不要把所有逻辑都塞进 Prompt，否则会变成难维护的"提示词大泥球" 资料1。

第二，JSON Schema 很适合描述结构，但它不能理解业务语义。比如字符串长度合法，不代表内容安全；枚举值正确，不代表用户有权使用那个值。所以 Schema 校验必须和服务端授权、输入清洗配合使用 资料1。

第三，OAuth 2.1 适合远程团队服务，但如果只是本地开发、单机 CLI 场景，上来就搞完整 OAuth 会过重。本地 stdio 场景可以先靠宿主进程启动、环境变量传递凭据和本机权限边界；一旦进入远程共享服务，再上完整的令牌、范围、审计和限流 资料1资料3。

一个很容易踩坑的点是日志输出位置：如果用 stdio 传输，MCP Server 的标准输出必须留给协议消息，调试日志只能写到标准错误；如果把日志写到 stdout，会直接破坏 JSON-RPC 通信，表现为客户端解析失败、偶发断连，排查起来很隐蔽 资料1。

面试官点评

考察点：这道题不是背 MCP 定义，而是看候选人能否在真实团队场景里选对能力类型，把协议语义、输入契约、远程安全和可观测性串成一个可落地方案。

合格回答需要做到四点：第一，能准确区分 Prompts、Tools、Resources 的语义边界，不把只读上下文或用户模板错误设计成 Tool；第二，知道 JSON Schema 在 MCP 中用于结构校验，但不能替代服务端授权和业务校验；第三，远程部署时能说出 OAuth 2.1 解决的是"用户委托 + 细粒度授权"问题，而不是只做登录；第四，能说明 OpenTelemetry 如何贯穿一次 Prompt 工作流，覆盖异常、审计和排错，并知道日志不能泄露凭据。

加分项包括：能主动说明 stdio 与 Streamable HTTP 的适用场景；能指出 stdout/stderr 的坑；能把 RAG 检索正确地放到 Prompt 工作流内部的 Tool 调用中，并强调检索内容也是不可信数据，其指令不能覆盖系统规则 资料1；能明确方案边界，不把 Prompts 当成万能编排器。

总结

沉淀团队级 MCP Prompts 工作流，本质上是在 Host 与 Server 之间建立一层"标准化交互入口"：Prompts 负责承接可复用流程，JSON Schema 负责把输入输出和步骤配置结构化，OAuth 2.1 负责远程场景下的身份与权限控制，OpenTelemetry 负责把一次调用从用户点击到结果返回完整串联。真正容易被忽略的不是 API 怎么调，而是三个边界：能力语义边界、安全授权边界、可观测排错边界。把这三件事做好，MCP 才不会停留在"能跑通 demo"，而能进入团队长期复用的工程化阶段。

参考资料

• MCP 基础知识
• MCP Java SDK：https://github.com/modelcontextprotocol/java-sdk
• MCP Python SDK：https://github.com/modelcontextprotocol/python-sdk
• Overview：https://modelcontextprotocol.io/specification/2026-07-28/basic