大厂 MCP 面试实录基于 Python SDK 构建可复用 Prompts 工作流与权限审计方案本文为一场围绕「团队沉淀可复用 MCP Prompts 工作流」场景的模拟面试复盘面向具备基础 Python 开发与 AI 应用集成经验的候选人。面试官候选人你好我们团队目前有多个业务线都在基于 MCP 构建 AI 工作流发现很多场景的 Prompt 模板是重复的比如代码审查、周报生成、合规检查想沉淀一套可复用的 MCP Prompts 能力要求符合最小权限原则同时有完整的审计日志你打算怎么设计这套方案候选人我的整体方案是基于 Python MCP SDK 构建独立的 MCP Server专门暴露预定义的 Prompts 能力配合服务端参数校验、分层权限控制和全链路审计日志埋点落地分为四步首先是能力梳理把重复的业务 Prompt 抽象成标准化的模板定义清晰的参数 schema其次是用 Python SDK 注册这些 Prompts在服务端做二次参数校验和权限拦截然后是埋点审计日志覆盖请求全链路最后是根据部署场景选择传输方式内部本地用 stdio跨团队远程用 Streamable HTTP 加认证。 选型依据是这些场景都是预定义的模板化工作流没有副作用符合 MCP 中 Prompts 的能力语义——Prompts 是模板化的消息或工作流由用户或模型显式选择比让模型自由组织 Prompt 更规范也方便统一管控。[资料1]面试官追问1你说选择 Prompts 能力而不是 Tool 或者 Resource能具体说下三者的差异和选型依据吗如果我把周报生成的模板做成 Resource 行不行候选人三者的选型核心是匹配能力语义 - Tools 是模型可调用的、有副作用的操作比如查询数据库、发送消息必须有明确的输入输出和副作用说明 - Resources 是只读的上下文数据比如文档、数据库查询结果由 URI 标识供应用直接读取 - Prompts 是模板化的指令集本身无副作用承载预定义的工作流逻辑。[资料1] 周报生成的场景是输入素材、输出生成后的周报本身不涉及数据修改或外部操作用 Prompts 最合适。如果做成 Resource 的话Resource 只能直接返回静态数据无法承载模板化的指令逻辑反而需要 Host 层额外处理模板拼接不符合 MCP 的能力边界。面试官追问2你提到用 Python MCP SDK 实现能说下具体的实现思路吗参数校验是怎么做的会不会只靠模型传入的参数候选人Python MCP SDK 支持通过装饰器快速注册 Prompts我们可以先定义每个 Prompt 的名称、描述和参数 schemaSDK 会自动做基础的参数结构校验但参数 schema 只是结构约束不能代替服务端校验所以我在 Handler 层会做二次校验比如检查参数长度、是否包含非法字符、业务参数是否合法。比如代码审查的 Prompt 要求传入的代码长度不能超过1万字符避免占用过多上下文同时如果参数里有 SQL 片段的话会做注入检测。 举个例子代码审查 Prompts 的注册伪代码如下# 伪代码基于 Python MCP SDK 注册 Prompts无版本依赖的通用接口设计 from mcp.server import Server from mcp.types import Prompt, PromptArgument app Server(reusable-prompts-server) # 注册代码审查 Prompt app.prompt( namecode_review, description对提交的代码片段进行标准化审查输出问题与优化建议, arguments[ PromptArgument(namecode, description待审查的代码内容, requiredTrue, typestring), PromptArgument(namelanguage, description代码编程语言, requiredTrue, typestring) ] ) async def code_review_handler(args: dict, current_user: User) - str: # 服务端二次校验防止模型传入非法内容 if len(args[code]) 10000: raise ValueError(代码长度超过最大限制) # 权限校验前置 if not has_permission(current_user, code_review, args.get(biz_line)): raise PermissionError(无权限执行该操作) # 审计日志埋点 audit_log( usercurrent_user.id, actioninvoke_prompt, prompt_namecode_review, paramsredact_sensitive(args), # 敏感字段脱敏 statusstart ) # 组装标准化 Prompt 模板 return f你是一位资深代码审查专家请对以下{args[language]}代码进行审查{args[code]}请输出1. 潜在问题 2. 优化建议 3. 安全风险 # 全局错误处理中间件 app.error_handler async def global_error_handler(e: Exception, request_id: str): audit_log( request_idrequest_id, statusfailed, errorstr(e) ) return {error: str(e), request_id: request_id}这里的所有接口都是 MCP Python SDK 的标准能力没有自定义的私有API。[资料2]面试官追问3最小权限原则你怎么落实如果不同业务线的用户调用同一个 Prompts怎么保证数据不越权候选人权限控制分两层 第一层是 Prompts 的调用权限不是所有用户都能调用所有 Prompts比如合规检查的 Prompt 只有合规部的用户能调用代码审查的只有研发线的用户能调用我们在服务端做权限拦截每次请求都要校验用户的角色和业务线权限不能只判断用户是否登录哪怕用户已经完成认证没有对应 Prompts 的调用权限也会直接拒绝。 第二层是关联能力的权限校验如果某个 Prompts 需要调用其他 Tool比如生成报告需要查询业务数据库的 Tool那这个 Tool 也要做权限拦截只能访问用户有权限的业务数据避免数据泄露。 另外如果 Prompts 执行过程中需要调用 LLM 完成生成还要遵循 MCP Sampling 规范保证高风险操作有人工在环用户有权拒绝采样请求。[资料1][资料4]面试官追问4如果出现异常情况比如参数非法、Tool 调用失败、模型返回异常你怎么处理审计日志要记录什么内容候选人异常处理遵循「早失败、快反馈」的原则 - 参数校验不通过的话直接返回错误信息给 Host不执行后续的 Prompt 逻辑同时在审计日志里记录请求ID、用户ID、调用的 Prompt 名称、非法参数脱敏后、错误原因、状态为失败 - 如果 Prompt 执行过程中关联的 Tool 调用失败会捕获异常返回友好的错误提示给模型同时记录 Tool 名称、失败原因、耗时 - 模型返回异常的话会记录模型错误码和原始返回方便后续排查。 审计日志的核心要素必须包含唯一请求ID贯穿全链路、操作人、操作时间、调用的 Prompt/Tool 名称、关键资源范围比如业务线、结果状态成功/失败、错误信息同时所有敏感字段比如用户输入的身份证号、密码都要脱敏凭据绝对不能出现在日志、Tool 返回值或模型上下文中。[资料1]面试官追问5如果要做远程多团队调用传输方式怎么选还有什么安全注意事项候选人如果是团队内部本地使用Host 在本机启动 MCP Server 子进程用 stdio 传输最方便性能也高这时候要注意调试日志不能写到标准输出要写到标准错误否则会破坏 JSON-RPC 的通信协议。 如果是跨团队或者多环境远程调用就用 Streamable HTTP 传输这时候需要额外加认证授权比如 OAuth2 或者 API 密钥还要做会话管理、限流和超时控制避免恶意请求或者服务雪崩。如果团队使用 Java 技术栈也可以参考 Spring AI MCP 提供的标准化安全能力实现授权逻辑。[资料1][资料3]面试官追问6这个方案有什么适用边界有没有容易踩坑的细节候选人适用边界很明确只适合承载预定义、无副作用的模板化工作流如果业务需要模型动态生成 Prompt 内容或者 Prompt 包含有副作用的操作比如修改数据、发送消息这个方案就不合适前者应该用 Tool 或者在 Host 层处理后者必须用 Tool 实现并加上用户确认环节。 容易踩坑的细节有两个一个是不要把有副作用的操作放到 Prompts 里比如不要在 Prompts 模板里写“执行删除操作”这类指令必须用 Tool 实现并且执行前向用户明确说明影响避免不可逆操作另一个是 stdio 传输的时候一定要把调试日志写到 stderr我之前见过有团队把日志打到 stdout导致 JSON-RPC 消息被破坏服务直接不可用。[资料1]面试官点评考察点对 MCP 三类能力的语义区分、Python MCP SDK 的实践能力、MCP 安全边界的理解、异常处理与可观测性设计、方案取舍能力。合格回答能清晰区分 Tools、Resources、Prompts 的适用场景选择 Prompts 承载预定义工作流知道服务端要做二次参数校验不能只依赖模型传入的参数有基础的审计日志意识能想到权限拦截。加分项能提到全链路请求ID、敏感字段脱敏、分层权限控制、传输方式的选型细节、stdio 的日志输出坑点以及对方案适用边界的清晰认知还能结合 MCP 的 Sampling 规范考虑模型调用的安全边界。总结这套方案的核心是遵循 MCP 的能力语义用 Prompts 承载预定义、无副作用的模板化工作流通过服务端校验、权限拦截和审计埋点满足安全和合规要求适合团队内部快速沉淀标准化的 AI 工作流。落地时需要注意不要强行用 Prompts 承载动态生成或有副作用的逻辑根据部署场景选择适配的传输方式同时做好异常场景的兜底日志、权限等规则的具体阈值需要根据业务 SLA、风险和压测结果确定不要硬套通用值。参考资料MCP 基础知识, https://modelcontextprotocol.io/specification/latestMCP Python SDK, https://github.com/modelcontextprotocol/python-sdkMCP Java SDK, https://github.com/modelcontextprotocol/java-sdkSampling, https://modelcontextprotocol.io/specification/2026-07-28/client/sampling