大厂 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_queryTool 的输入 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 调用我们可以把独立的查询操作比如查询用户基础信息、查询订单信息封装成不同的 ToolPrompts 模板里指引模型并行调用不需要串行等待能大幅降低流程耗时[资料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 负责封装动态的业务操作能力保证灵活性。设计过程中需要兼顾扩展性、安全、异常处理和可观测性根据部署场景选择合适的传输方式避免常见的踩坑点。参考资料MCP 基础知识Tools | https://modelcontextprotocol.io/specification/2026-07-28/server/toolsPrompts | https://modelcontextprotocol.io/specification/2026-07-28/server/promptsSampling | https://modelcontextprotocol.io/specification/2026-07-28/client/sampling