真实面经题目 · 原创解析
开发 MCP 服务时,如何设计 resources/tools/prompts、输入输出 schema、权限和可观测性?
这道题考察的是 MCP 服务的能力建模和治理能力,而不是会不会写一个 HTTP endpoint。好答案要从 resources、tools、prompts 三类能力暴露开始,定义清晰的输入输出 schema、权限和错误语义,再补上发现机制、版本兼容、超时重试、可观测性、回放和审计,保证 Agent 能安全、稳定、可追踪地使用 MCP 服务。
真实面经题目 · 原创解析
这道题考察的是 MCP 服务的能力建模和治理能力,而不是会不会写一个 HTTP endpoint。好答案要从 resources、tools、prompts 三类能力暴露开始,定义清晰的输入输出 schema、权限和错误语义,再补上发现机制、版本兼容、超时重试、可观测性、回放和审计,保证 Agent 能安全、稳定、可追踪地使用 MCP 服务。
开发 MCP 服务时,我会先做能力边界设计,而不是先写接口。resources 暴露可读取的上下文和数据对象,例如文档、配置、报表、日志片段,要关注 URI、分页、权限和内容大小;tools 暴露可执行动作,例如查询、创建、更新、计算,要定义输入 schema、输出 schema、错误码、超时、幂等和副作用;prompts 暴露可复用的提示模板或工作流入口,要说明变量、适用场景和版本。schema 要尽量结构化、稳定、可校验,返回里包含状态、数据、可重试错误和 trace id。权限上按用户、租户、资源和工具动作做鉴权,写入类工具要有确认、幂等键和审计。可观测性上要记录 list、read、call 的请求参数摘要、调用耗时、成功率、错误类型、token 或 payload 大小、trace id 和调用方身份,并支持 replay 和 audit。长期看,MCP 服务的质量取决于 discoverability、稳定契约、最小权限和可定位问题,而不是接口数量。
resources、tools、prompts 解决的是不同问题。resources 是可读上下文,适合文档、文件、配置、数据快照和日志;tools 是动作,适合查询、计算、写入和外部系统调用;prompts 是可复用模板,适合把稳定任务流程、变量和输出约束标准化。
resource 要有稳定 URI、类型、mime、大小限制、分页或范围读取、更新时间和权限范围。大文件或长日志不要一次性返回,应支持片段读取、摘要和引用。资源返回要避免夹带无关敏感信息,因为 Agent 常会把资源内容进一步送入模型上下文。
tool 要有明确名称、用途、何时使用、输入 JSON schema、返回 schema、错误码、超时、重试策略、幂等键和副作用描述。查询工具和写入工具应明显区分;有风险的写入动作最好支持 dry-run、确认步骤和可回滚或可查询结果。
prompt 不是随便存一段模板,而是给 Agent 一个稳定的任务入口。它应说明适用场景、变量 schema、输出格式、版本和依赖资源。模板更新要考虑兼容性,因为调用方可能已经把某个 prompt 的输出结构接入到下游流程。
输入输出 schema 应包含必填字段、类型、枚举、默认值、字段说明、边界限制和错误结构。返回结果最好分为 data、status、error、metadata 和 trace id。版本演进时保持向后兼容,废弃字段要有迁移期,避免 Agent 依赖的工具契约突然变化。
MCP 服务不能假设调用方可信。要按用户身份、租户、资源范围、工具动作和风险级别鉴权。读资源、查数据、写业务系统、发送通知应有不同权限。对高风险工具,还要记录操作者、审批或确认信息,并避免把服务级凭证直接暴露给模型。
错误不能只返回失败字符串。应区分参数错误、权限不足、资源不存在、限流、超时、下游不可用、冲突和不可重试业务错误。Agent 需要根据错误类型决定补参、重试、降级、追问用户还是停止。错误结构不稳定会让 Agent 产生错误恢复策略。
生产 MCP 服务要记录调用方、用户身份、工具名、资源 URI、参数摘要、结果大小、耗时、错误类型、trace id、幂等键和副作用结果。敏感参数要脱敏。通过 trace、指标和审计日志,才能定位是模型误选、schema 错误、权限拒绝还是下游服务故障。
服务应支持用历史调用记录做 replay,验证新版本 schema、权限和错误码是否兼容。发布前要用契约测试、权限测试、超时测试、幂等测试和负载测试覆盖常见路径。MCP 服务一旦被多个 Agent 使用,契约稳定性比接口实现细节更重要。
resource 主要是读取上下文或数据,强调 URI、权限、大小控制和可引用;tool 是执行动作,可能有参数校验、耗时、错误和副作用。能读的不要包装成写动作,有副作用的不要伪装成 resource。
工具名称和描述要说明适用场景、输入要求、返回内容和禁用边界;工具目录可以按领域、读写属性和风险等级打标签;客户端还可以先按意图和权限筛选候选工具,再暴露给模型。
写入工具要有最小权限、参数校验、幂等键、dry-run 或预览、用户确认、审计日志和结果查询。对不可逆操作,应限制暴露阶段,并要求明确确认状态,不能让模型凭自然语言猜测后直接执行。
新增可选字段通常安全;删除字段、改类型、改枚举或改错误结构都可能破坏调用方。应使用版本号、迁移期、契约测试和回放样本,确认老 Agent 在新服务上仍能工作,再逐步下线旧字段。
可以看工具发现次数、调用量、成功率、参数校验失败率、P50/P95 延迟、超时率、错误码分布、结果大小、重试率、幂等冲突、权限拒绝和高风险工具审计事件。
Agent 失败往往跨越模型、工具和下游系统。replay 能用历史调用复现契约和行为变化,audit 能回答谁在什么上下文下调用了哪个工具、产生了什么副作用,是生产治理的基础。