大厂 MCP 面试实录：可复用 Prompts 工作流的设计与落地

本文为 MCP 工程化场景模拟面试复盘，围绕「为团队沉淀可复用 MCP Prompts 工作流」的业务场景展开，覆盖基础概念区分、方案设计、安全边界、异常处理与可观测性等核心考察点。

面试官：今天我们考察的是 MCP 工作流沉淀的场景：你们团队需要把日常高频使用的 AI 交互流程封装成可复用的能力，降低普通业务方的使用门槛，同时保证流程可控、安全。请你先基于 MCP 的 Prompts 和 Tools 能力，说说你的整体设计思路。

候选人：我的整体结论是：Prompts 负责封装模板化的流程骨架，Tools 负责提供流程中所需的动态操作能力，两者按语义分工，不强行交叉。 首先从 MCP 规范的能力定义出发：Prompts 是用户可显式选择的模板化消息或工作流，适合沉淀固定交互逻辑、预置流程步骤，降低用户使用成本；Tools 是模型可自动发起的操作，适合封装需要动态参数、有业务逻辑的操作能力，比如数据查询、接口调用等[资料1][资料3]。 在这个场景下，我们可以把通用的工作流步骤（比如「先查询数据、再校验、最后输出结果」）固化到 Prompts 模板里，不同业务方只需要选择对应的 Prompts，传入自己的业务参数即可；而具体的查询、校验逻辑封装成不同的 Tools，由模型根据 Prompts 的指引自动调用，既保证了流程的规范性，又保留了灵活性。 适用边界上，这个方案适合内部团队沉淀高频、标准化的交互流程，如果是需要高度自定义的个性化流程，就不适合强行封装成 Prompts，否则会限制灵活性。关键取舍是模板化程度和灵活性的平衡：Prompts 模板越固定，使用门槛越低，但可扩展性越差；模板越灵活，越接近普通对话，可复用性也会下降。

面试官：你说得分工很清晰，但如果这个工作流里，有一部分是固定的数据校验规则，另一部分是需要根据用户输入动态生成查询条件的，你会怎么设计这两部分的归属？为什么？

候选人：固定校验规则放到 Prompts 模板中，动态查询条件封装成独立的 Tool。 原因是：固定校验规则的逻辑是确定的，不需要动态调整，直接写到 Prompts 模板里，模型在执行流程时会自动遵循，不需要额外调用；而查询条件需要根据用户的自然语言输入动态生成，参数是不固定的，封装成 Tool 后，模型可以根据用户输入自动生成参数并调用，符合 Tools「模型可控」的设计初衷[资料2]。 举个可落地的示例，我们可以先定义一个 Prompts 模板，结构如下：

# 业务数据查询校验工作流
1. 调用 `dynamic_query` 工具，传入用户输入的自然语言查询条件，获取原始数据
2. 调用 `data_validation` 工具，校验原始数据是否符合预设规则
3. 如果校验通过，整理数据返回给用户；如果校验失败，返回具体的错误原因

对应的 dynamic_query Tool 的输入 schema 可以设计为符合 MCP 规范的结构：

{
  "name": "dynamic_query",
  "description": "根据自然语言查询条件获取业务数据",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query_text": {
        "type": "string",
        "description": "用户输入的自然语言查询条件"
      }
    },
    "required": ["query_text"]
  }
}

这样的设计下，用户只需要选择这个 Prompts，输入自己的查询需求，模型会自动完成查询和校验的完整流程，不需要用户手动操作。

面试官：如果这个工作流需要支持多团队复用，不同团队的校验规则、查询的数据源都不一样，你之前的方案怎么调整才能满足需求？

候选人：把 Prompts 设计成可配置的模板，将团队专属的校验规则、数据源能力封装成独立的 Tools 或 Resources，通过参数动态绑定。 具体来说，我们可以把 Prompts 模板里的工具名称、校验规则来源改成可配置的参数，比如：

# 业务数据查询校验工作流
1. 调用 `{{query_tool_name}}` 工具，传入用户输入的查询条件，获取原始数据
2. 调用 `{{validation_tool_name}}` 工具，校验数据是否符合 `{{validation_rule_uri}}` 中定义的规则
3. 返回结果给用户

不同团队只需要提供自己的查询 Tool、校验 Tool 和校验规则 Resource（由 URI 标识，符合 Resources 的规范[资料1]），在调用 Prompts 的时候传入对应的参数即可，不需要修改 Prompts 模板本身。 这里的取舍是：参数越灵活，Prompts 的通用性越强，但对使用方的配置能力要求也越高；如果团队的业务差异很小，也可以直接预置多个版本的 Prompts，降低使用门槛。适用边界上，这个方案适合团队业务差异较大、需要高度定制化的场景，如果所有团队的流程完全一致，就不需要做这么灵活的配置。

面试官：假设模型在调用 Tool 的时候，传入了恶意的 SQL 注入 payload，或者拼接了非法的文件路径，你怎么保证工作流的安全性？

候选人：核心原则是：不信任模型传入的任何输入，服务端做多层校验，高风险操作做用户确认。 首先，MCP 的 Tool 参数 schema 只是结构约束，不能代替服务端的内容校验和授权[资料1]，所以 Tool 的服务端必须对传入的 SQL、文件路径、URL 等敏感内容做校验，比如用预编译语句防止 SQL 注入，对文件路径做白名单限制，禁止访问系统敏感目录。 其次，高风险或不可逆的操作（比如删除数据、修改配置）需要在执行前明确告知用户操作影响，并要求用户确认后再执行，不能因为请求来自 AI 应用就默认可信[资料1]。 另外，远程部署的场景下，每次 Tool 调用都要做授权检查，不能只判断用户是否登录，还要判断用户是否有权限操作对应的资源；审计日志要记录调用者、时间、Tool 名称、关键参数脱敏、结果状态，同时禁止把凭据、敏感参数写到日志、Tool 返回值或模型上下文中[资料1]。

面试官：如果 Tool 调用的时候出现异常，比如远程接口超时、服务不可用，或者工作流里有多个独立的查询操作，你怎么保证用户体验和流程效率？

候选人：异常场景提前预判处理，并行场景用 MCP 原生能力优化效率。 针对异常场景：首先给 Tool 调用配置合理的超时时间，超时后返回结构化的错误信息，而不是直接抛出异常；Prompts 模板里可以预置错误处理的指引，比如「如果查询工具返回超时错误，提示用户「查询超时，请稍后重试或联系管理员」，不要重复调用避免雪崩」。Host 端需要捕获所有 Tool 调用的异常，给用户明确的反馈，不能直接把错误栈抛给用户；同时记录错误日志，方便排查问题。对于无状态的读类 Tool，可以配置短过期时间的缓存，缓存热点数据降低超时概率，但缓存要支持手动失效，避免数据不一致，这个方案的取舍是：缓存会带来一定的不一致风险，只适合对一致性要求不高的场景，高一致性场景需要去掉缓存或者用极短的过期时间。 针对并行查询场景：MCP 规范支持模型发起多个并行的 Tool 调用，我们可以把独立的查询操作（比如查询用户基础信息、查询订单信息）封装成不同的 Tool，Prompts 模板里指引模型并行调用，不需要串行等待，能大幅降低流程耗时[资料4]。

面试官：你怎么监控这个 Prompts 工作流的使用情况，比如哪个模板使用率最高，哪个 Tool 的失败率最高？

候选人：基于审计日志做指标采集和链路追踪，覆盖 Prompts 和 Tools 的全生命周期。 首先，审计日志要记录 Prompts 的调用次数、调用用户、传入参数，以及每次调用过程中所有 Tool 的调用耗时、结果状态、错误码；然后基于这些日志采集核心指标：比如 Prompts 的调用量、Top 使用模板、Tool 的成功率、P99 耗时、失败率 Top 的 Tool，设置告警规则，比如 Tool 失败率超过业务阈值就触发告警。 同时可以做链路追踪，给每次 Prompts 调用生成唯一的链路 ID，串联整个流程中所有 Tool 的调用记录，当用户反馈工作流异常时，可以通过链路 ID 快速定位是哪个步骤出了问题。 这里的取舍是：全链路采集会带来一定的性能开销，需要根据业务 SLA 调整采样率，比如核心工作流全量采集，非核心工作流按比例采样。

面试官：你提到用缓存降低 Tool 超时概率，但如果业务对数据一致性要求很高，比如查询用户余额，缓存会不会带来严重问题？你怎么权衡？还有没有其他容易踩坑的细节？

候选人：缓存的使用必须匹配业务的一致性要求，传输方式选型也有常见的踩坑点。 对于查询用户余额、订单状态这类对一致性要求高的场景，绝对不能使用缓存，或者只能使用过期时间极短（比如几秒级，具体数值根据业务 SLA 确定）的缓存，同时提供手动刷新能力，在 Prompts 的返回结果里提示「数据可能存在延迟，如需最新数据请点击刷新」，给用户明确的预期。对于资讯、配置类对一致性要求低的场景，可以使用较长过期时间的缓存，提升性能。 容易踩坑的细节有两个：一个是远程部署使用 stdio 传输时，Server 的调试日志必须写到标准错误（stderr），不能写到标准输出（stdout），因为标准输出是用来传 MCP 协议消息的，日志写到标准输出会破坏通信，导致 MCP 会话失败[资料1]；另一个是不要把只读的静态资料强行封装成有副作用的 Tool，比如把固定的产品说明文档做成 Tool，应该用 Resources 能力暴露，符合 MCP 的能力语义[资料1]。

面试官点评

• 考察点：首先是 MCP 三类核心能力（Prompts、Tools、Resources）的语义区分，能否根据业务场景选择合适的能力，避免能力滥用；其次是方案设计的扩展性，能否支撑多团队复用的需求；第三是安全边界意识，是否知道 MCP 参数 schema 的局限性，能否覆盖输入校验、授权、审计等安全环节；第四是异常处理、可观测性和传输方式选型的工程化意识。
• 合格回答：能清晰区分 Prompts 和 Tools 的分工，给出基础的流程设计，知道服务端要做输入校验，能根据部署场景选型传输方式。
• 加分项：能考虑到多团队复用的扩展性设计，知道 Resources 可以用来存储可变配置，能覆盖链路追踪、缓存权衡、错误处理等工程化细节，能指出 stdio 传输下日志输出的踩坑点，以及能力语义的边界。

总结

在沉淀可复用 MCP Prompts 工作流的场景下，核心是先明确 Prompts 和 Tools 的边界：Prompts 负责沉淀固定的流程骨架，降低使用门槛；Tools 负责封装动态的业务操作能力，保证灵活性。设计过程中需要兼顾扩展性、安全、异常处理和可观测性，根据部署场景选择合适的传输方式，避免常见的踩坑点。

参考资料

1. MCP 基础知识
2. Tools | https://modelcontextprotocol.io/specification/2026-07-28/server/tools
3. Prompts | https://modelcontextprotocol.io/specification/2026-07-28/server/prompts
4. Sampling | https://modelcontextprotocol.io/specification/2026-07-28/client/sampling