大厂 MCP 面试实录：可复用 Prompts 工作流的工程化设计

本文采用模拟面试复盘形式，还原大厂基础架构/AI 应用开发岗位的 MCP 相关面试场景，围绕「为团队沉淀可复用 MCP Prompts 工作流」的业务需求，逐步考察候选人对协议原理、能力选型、安全设计与工程落地的掌握程度。

面试官：今天我们团队的核心需求是给内部 AI 助手平台沉淀一套可复用的 MCP 工作流，要求不同业务线的 AI 应用都能按需调用，同时避免重复开发。你先基于 MCP 的现有能力，说说你的整体设计方案？

候选人：我的核心结论是：以 MCP Prompts 作为模板化工作流的主要载体，搭配 Tools 实现工作流中的有副作用操作，通信层默认用 JSON-RPC over stdio 做本地调试，远程部署时切换到 Streamable HTTP 传输。具体原理上，MCP 的 Prompts 能力本身就是为模板化消息、工作流设计的，支持客户端传入参数自定义内容，刚好匹配「可复用工作流」的需求 $资料1$ $资料4$ ；而 Tools 适合封装有副作用的操作，比如查询业务数据、提交审批、更新记录等，符合 Tools「模型可发起调用的操作」的语义定位，避免把只读静态内容强行封装成 Tool $资料1$ $资料2$ 。JSON-RPC 是 MCP 规定的标准通信协议，负责客户端和服务端的消息序列化、请求响应匹配 $资料1$ ；stdio 传输适合 Host 在本机启动 Server 子进程的调试场景，远程部署时 Streamable HTTP 更适合服务端独立部署、多客户端调用的场景 $资料1$ 。这个方案的适用边界是：适合工作流有明确模板、需要支持业务线自定义参数的场景，如果工作流是完全动态、无固定模板的，就不适合用 Prompts 封装。

面试官追问：你提到工作流需要动态拉取业务线的文档内容，你是把文档检索做成 Tool 还是直接塞到 Prompt 模板里？为什么？如果业务方要求流程完全可控、不让 AI 应用自主决定是否检索，你又怎么调整？

候选人：首先结论是：优先把文档检索封装成独立的 MCP Tool，由 AI 应用根据用户问题自主决定是否调用；如果业务方要求强管控，就把检索逻辑放到 Host 层预处理，再把检索结果作为参数传入 Prompt。原理上，Prompt 是静态模板，如果把动态检索逻辑塞进去，会导致模板臃肿，而且每次调用都要全量加载检索逻辑，浪费上下文窗口；而封装成 Tool 后，AI 应用可以根据用户问题的语义自主判断是否需要检索，符合 RAG 的最佳实践------检索时机由 AI 应用动态决定，更灵活 $资料1$ 。如果业务方要求流程完全可控，不允许 AI 应用自主调用 Tool，就可以把检索逻辑放在 Host 层，在调用 Prompt 之前先完成检索，把检索到的内容作为参数传给 Prompt 模板，这样流程更可预测，但会损失一部分灵活性 $资料1$ 。这里的关键取舍是：灵活度 vs 可控性，面向内部用户、对灵活性要求高的场景用 AI 应用调用 Tool 的方案，面向外部用户、对流程合规性要求高的场景用 Host 预处理的方案。比如基于 MCP Python SDK 封装知识检索 Tool 时，仅需编写带类型标注的函数与文档字符串，无需手动处理 JSON-RPC 请求解析、参数校验与协议通信，SDK 会自动生成对应的输入 schema 与消息处理逻辑，示例参考如下：

python 复制代码

import asyncio
from mcp import Client
from server import mcp

async def main() -> None:
    async with Client(mcp) as client:
        result = await client.call_tool("knowledge_search", {"query": "MCP 安全边界设计"})
        print(result.structured_content)

这段代码既可以连接本地 stdio 启动的 Server，也可以直接替换为远程 HTTP 地址，不需要修改任何业务逻辑 $资料3$ 。

面试官追问：如果这套 Server 要远程部署给多个业务线的客户端调用，你怎么设计安全边界？比如用户调用一个「提交工单」的 Tool，怎么防止恶意参数、越权操作，还有敏感信息泄露？

候选人：结论是：从传输层、参数校验、授权、审计四个层面做全链路安全设计，同时严格区分可信输入和不可信输入。具体设计上： 1. 传输层：Streamable HTTP 传输时启用认证，比如 mTLS 或者 Bearer Token，每次请求都要校验客户端身份，不能因为是内部应用就默认可信 $资料1$ ； 2. 参数校验：Tool 的参数 schema 只做结构约束，比如参数类型、必填项，服务端还要对业务参数做合法性校验，比如提交工单的「所属部门」参数要和当前登录用户的部门一致，防止用户提交到其他部门的工单；所有 AI 应用传入的文本都要视为不可信输入，对文件路径、SQL 片段、Shell 参数做转义和约束，防止注入攻击 $资料1$ ； 3. 操作确认：高风险、不可逆的操作比如提交工单、删除记录，Tool 的返回要明确说明操作的影响，Host 层要在执行前要求用户二次确认 $资料1$ ； 4. 审计与脱敏：审计日志要记录用户ID、调用的 Tool 名称、关键资源范围、结果状态，对敏感字段比如用户手机号、工单内容做脱敏，不能把原始敏感信息放到日志、Tool 返回值或者 AI 应用的上下文中 $资料1$ 。这里最容易踩坑的点是很多开发者会把 AI 应用传入的参数当成可信输入，直接拼接到 SQL 或者 API 请求里，导致注入漏洞，所以所有外部输入都要做严格的校验和转义。另外如果是用 stdio 传输做本地调试，调试日志一定要写到标准错误输出，不能写到标准输出，否则会破坏 JSON-RPC 的消息格式，导致通信失败 $资料1$ 。

面试官追问：现在这套工作流上线后，业务方反馈有时候调用 Tool 超时，或者 Prompts 返回的内容不符合预期，你怎么设计可观测性和异常处理机制？

候选人：结论是：从协议层、服务端、Host 层三个层面做可观测，异常做分级处理，不同操作类型做不同的重试策略。具体设计上： 1. 协议层：利用 JSON-RPC 协议标准化的错误响应机制，Host 层可根据错误类型做差异化处理； 2. 服务端埋点：记录每个 Tool 的调用耗时、成功率、错误原因，Prompts 的调用次数、返回内容的关键指标，比如模板参数是否缺失、返回长度是否符合预期； 3. Host 层处理：对于无副作用的 Tool 比如知识检索，可配置有限重试，重试次数和超时时间需根据业务的 SLA 和压测结果确定，不能随意写死；对于有副作用的 Tool 比如提交工单，绝对不能自动重试，避免重复提交，要返回明确的错误信息，让用户确认是否手动重发 $资料1$ 。关键取舍是：重试策略要根据操作的风险来定，灵活度高的场景可以适当放宽重试限制，高风险场景要优先保证数据一致性，不能为了可用性牺牲正确性。

面试官追问：如果后续要给不同业务线定制不同的 Prompt 模板，同时复用底层的 Tools，你会怎么设计 Server 的代码结构，避免后续扩展的时候改 core 代码？

候选人：结论是：用三层分层设计，底层是通用 Tools 层，中间是 Prompt 模板层，上层是路由层，实现能力和配置的解耦。具体架构上： 1. 通用 Tools 层：封装所有业务线共用的有副作用操作，比如知识检索、工单提交、数据查询，所有业务线共用这层代码，不需要重复开发； 2. Prompt 模板层：用配置文件或者数据库存储不同业务线的 Prompt 模板，支持动态加载，模板里可以引用 Tools 的能力，通过参数传递动态内容； 3. 路由层：根据请求里的业务线标识，返回对应业务线的 Prompt 列表，把请求转发到对应的模板。如果后续某个业务线需要专属的 Tool，可以单独做 Tools 的分组，或者拆成独立的 MCP Server，通过 Server 集群的方式对外提供能力，避免单个 Server 过于臃肿 $资料1$ 。适用边界是：如果业务线的能力差异极小，用单个 Server + 模板配置的方式足够；如果差异极大，建议拆成多个 Server，通过服务发现的方式让 Host 按需调用。

面试官点评

考察点

本次面试围绕真实业务场景，考察了四个核心维度：1. MCP 三类能力（Tools、Resources、Prompts）的语义区分与选型能力 $资料1$ ；2. 远程部署场景下的安全边界设计 $资料1$ ；3. 异常处理与可观测性的工程化落地能力；4. 系统的可扩展性设计。

合格回答

能明确区分 Prompts 和 Tools 的适用场景，知道 JSON-RPC 是 MCP 的标准通信协议，了解安全校验的基本要求，能想到基础的错误处理和重试逻辑，给出的方案能满足基本业务需求。

加分项

能结合 RAG 的最佳实践设计检索逻辑 $资料1$ ，区分有副作用和无副作用操作的异常处理差异，给出分层解耦的扩展架构，还能提到敏感字段脱敏、审计日志、传输层认证、stdio 日志输出规范等容易被忽略的细节 $资料1$ ，说明候选人有实际的 MCP 工程落地经验。

总结

MCP 的能力选型核心是贴合语义：Prompts 适合模板化、可复用的工作流，Tools 适合 AI 应用自主调用的有副作用操作，静态只读内容更适合用 Resources 封装，避免能力错配 $资料1$ 。远程部署场景下安全是重中之重，不能默认请求可信，所有外部输入都要做严格校验 $资料1$ 。工程化设计时要优先考虑可扩展性和可观测性，避免把 MCP 当成简单的接口封装工具，要充分利用协议的标准能力降低开发成本。

参考资料

MCP 基础知识（内部检索资料）
Tools | Model Context Protocol Specification，https://modelcontextprotocol.io/specification/2026-07-28/server/tools
MCP Python SDK，https://github.com/modelcontextprotocol/python-sdk
Prompts | Model Context Protocol Specification，https://modelcontextprotocol.io/specification/2026-07-28/server/prompts