大厂 MCP 面试实录：基于 RAG 与 Docker 沉淀可复用 Prompts 工作流

本文为 MCP 技术岗模拟面试实录，围绕「为团队沉淀可复用 MCP Prompts 工作流」的业务场景展开，覆盖基础概念、技术选型、架构设计、安全与异常处理等核心考察点。

---

面试官：我们今天围绕一个实际业务场景展开：团队需要沉淀一套可复用的 MCP Prompts 工作流，要求支持跨项目调用、能根据用户需求自动匹配最合适的 Prompt 模板，还要保证安全性和可维护性。你先说说对这个需求的理解，以及你会怎么设计整体方案？

候选人：我的整体结论是分四层设计：Prompts 元数据管理层、RAG 语义召回层、MCP 能力封装层、Docker 部署层，各层分工明确。 首先，Prompts 元数据管理层负责沉淀所有可复用的 Prompt 模板，除了模板本身，还要存储适用场景、输入参数要求、使用示例、所属项目等元数据，这些元数据是后续召回的核心依据。 其次，RAG 语义召回层负责根据用户的需求描述，从存量 Prompts 中匹配最合适的模板，解决纯关键词检索无法覆盖同义表述、场景描述差异的问题。 第三，MCP 能力封装层把检索能力、Prompt 调用能力按照 MCP 协议标准封装，对外暴露统一的接口，供团队所有 AI 应用调用。MCP 采用客户端—服务端架构，Server 向 Client 暴露能力，通信使用 JSON-RPC 协议，三类常见能力为 Tools、Resources 和 Prompts，需要根据语义选择合适的能力封装[资料2]。 第四，Docker 部署层负责把整个服务打包成标准化镜像，解决环境一致性、跨项目部署、依赖隔离的问题，避免「本地能跑、线上崩了」的问题。

面试官：你提到了用 RAG 做 Prompt 匹配，为什么不直接用关键词检索？RAG 在这里的具体链路是怎么设计的？

候选人：纯关键词检索的短板很明显：比如用户说「帮我写一个用户投诉的处理回复」，和存量 Prompt 元数据里的「客服投诉响应话术模板」关键词重叠度很低，纯关键词很难召回，而 RAG 基于语义匹配就能解决这个问题。 RAG 的具体链路分三步：第一步是预处理，把所有 Prompt 的元数据按语义完整性切块，比如把「适用场景：电商平台用户投诉处理」「输入参数：投诉类型、用户等级、问题严重程度」这类独立语义块拆分，然后生成向量 embedding，存入向量数据库（比如 Chroma）；第二步是召回，用户输入需求后，先做混合查询，同时发起关键词检索和向量相似度检索，合并两路的结果提升召回率，这种混合查询方式相比单一检索能获得更高的召回效果[资料1]；第三步是重排，对合并后的结果做语义重排，把最匹配的前几个结果返回，同时保留来源元数据，方便后续溯源。RAG 链路最后会把少量相关片段与来源一起交给模型，切块时保留语义完整性，避免不相关内容占用大量上下文[资料2]。

面试官：你把 RAG 检索封装成了 MCP 的什么能力？为什么选这个而不是另外两个？如果模型自己乱调用这个能力或者传入恶意参数怎么办？

候选人：我选择封装成 MCP 的 Tool 能力，原因有三点：第一，Tool 是模型可以主动发起的操作，符合「用户提需求后自动匹配 Prompt」的场景，比 Prompts 能力（需要用户显式选择模板）更灵活；第二，Tool 支持定义输入输出 schema，可以约束用户输入的参数格式，比 Resources（只读静态资源，不支持主动检索逻辑）更合适，符合「根据语义选择能力，不要把只读资料强行设计成有副作用的 Tool」的原则[资料2]。 针对安全风险，我会做三层防控：第一，Tool 的参数 schema 只是结构约束，服务端还要额外校验参数，比如禁止传入路径遍历、SQL 注入类的恶意内容，把模型传入的所有文本都视为不可信输入[资料2]；第二，检索到的 Prompt 内容只是参考，不能覆盖 Host 端的系统规则，避免 Prompt 注入攻击；第三，加权限控制，比如只有特定项目的 AI 应用才能调用对应业务域的 Prompt 模板，所有调用都记录审计日志，包含调用方、时间、参数、返回结果，敏感字段脱敏[资料2]。

面试官：你提到用 Docker 做部署，具体是怎么做编排的？如果遇到容器内向量数据库连接失败、或者 Prompt 模板更新了需要怎么处理？

候选人：Docker 编排上，我会用 Docker Compose 定义三个核心服务：MCP Server 服务、Chroma 向量数据库服务、Prompts 元数据同步服务，三个服务在同一个容器网络内，通过服务名互相访问，避免硬编码 IP。Chroma 支持客户端-服务端模式，直接启动官方镜像即可使用[资料3]。 针对异常场景：第一，如果向量数据库连接失败，MCP Server 会捕获异常，返回明确的错误码和提示，不会崩溃，同时容器配置健康检查，如果连续失败会自动重启；第二，Prompt 模板更新后，元数据同步服务会定时把最新的元数据切块、生成 embedding 并增量更新到向量库，不需要重启 MCP Server 服务，实现热更新。如果是远程部署场景，MCP Server 会用 Streamable HTTP 传输协议，比 stdio 更适合远程调用，同时配置认证、限流和超时机制，避免被滥用，注意 stdio 传输时调试日志必须写到标准错误，不能写到标准输出，否则会破坏 JSON-RPC 通信[资料2]。

面试官：这个方案有什么适用边界？有没有什么容易踩坑的细节？

候选人：适用边界主要有两个：一是团队 Prompts 总量在万级以内，如果超过十万级，向量数据库需要做集群部署，Docker 编排也要对应调整；二是如果业务有强合规要求，Prompt 模板不能存在第三方服务，需要把 Chroma 私有化部署在内部服务器。 最容易踩坑的有三个细节：第一，Prompt 切块的时候不能破坏语义完整性，比如把一段完整的「输入参数说明」拆成两半，会导致召回准确率大幅下降；第二，如果是用 stdio 传输的 MCP Server，调试日志不能写到标准输出，会破坏 JSON-RPC 协议的通信，必须写到标准错误[资料2]；第三，不要把只读的 Prompts 元数据强行设计成有副作用的 Tool，要符合 MCP 的能力语义划分，避免模型误调用[资料2]。

面试官：你现场写一个最小可落地的示例代码，用我们刚才说的技术栈，注意不要编造不存在的 API。

候选人：好的，我用 MCP Python SDK 和 Chroma 的公开 API 写一个最小示例，基于官方公开的接口，没有虚构方法： 首先需要安装依赖：pip install mcp chromadb 核心代码如下：

import chromadb
from mcp.server import Server
from mcp.types import Tool, TextContent

# 初始化 Chroma 客户端，内存模式用于演示，生产环境可开启持久化
chroma_client = chromadb.Client()
prompt_collection = chroma_client.get_or_create_collection("team-prompts")

# 初始化 MCP Server，符合 Python SDK 的标准定义[资料4]
app = Server("prompt-retrieval-mcp-server")

# 定义检索 Prompt 的 Tool，输入为需求描述，输出为匹配的 Prompt 模板
@app.list_tools()
async def list_tools():
    return [
        Tool(
            name="retrieve_reusable_prompt",
            description="根据用户业务需求，检索团队沉淀的最匹配可复用 Prompt 模板",
            inputSchema={
                "type": "object",
                "properties": {
                    "query": {"type": "string", "description": "用户的自然语言需求描述"}
                },
                "required": ["query"]
            }
        )
    ]

# 实现 Tool 调用逻辑，这里省略 embedding 生成的具体实现，实际可接入团队内部的 embedding 模型
@app.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "retrieve_reusable_prompt":
        query = arguments["query"]
        # 调用 Chroma 的 query 接口做混合检索，返回 Top3 结果[资料3]
        results = prompt_collection.query(
            query_embeddings=[generate_embedding(query)], # generate_embedding 为外部传入的 embedding 生成方法
            n_results=3
        )
        # 返回结果和来源元数据，方便溯源
        return [TextContent(type="text", text=f"匹配到的 Prompt 模板：{results['documents']}，来源：{results['metadatas']}")]

Dockerfile 只需要把 Python 环境、依赖、代码打包成镜像即可，Docker Compose 中额外配置 Chroma 的官方镜像服务，就能完成整个服务的编排。

---

面试官点评

考察点

1. 对 MCP 三类核心能力（Tools、Resources、Prompts）的语义区分，能否根据业务场景选择最合适的能力封装；
2. RAG 技术在业务场景的落地能力，是否知道混合检索、重排、语义完整性等关键设计；
3. 对 MCP 安全边界的意识，是否知道不能信任模型输入、要避免 Prompt 注入、要做权限控制；
4. 对 Docker 部署的合理性，是否知道容器编排、健康检查、热更新等工程化细节。

合格回答

能清晰讲清四层架构的分工，知道 RAG 混合检索的优势，能区分 MCP 三类能力的适用场景，了解基础的 MCP 安全要求，能给出符合技术栈的示例代码。

加分项

能主动提到 Prompt 切块的语义完整性要求、stdio 传输的日志限制、Prompt 注入的防控、适用边界的判断，说明有实际的工程落地经验，而不是只会背概念。

---

总结

在这个业务场景下，RAG、MCP、Docker 三者的分工非常明确：RAG 负责解决 Prompt 模板的语义匹配问题，是核心的检索能力；MCP 负责把检索能力、Prompt 调用能力封装成标准化的接口，降低跨项目集成的成本；Docker 负责解决环境一致性、部署标准化的问题，保证服务可以稳定运行。三者不是强行拼接，而是各自解决业务场景中的核心痛点，最终实现可复用 Prompts 工作流的沉淀。

---

参考资料

1. Retrieval-augmented generation (RAG) in Azure AI Search, https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview
2. MCP 基础知识
3. Chroma: Open-source Vector Database, https://github.com/chroma-core/chroma
4. MCP Python SDK, https://github.com/modelcontextprotocol/python-sdk