AI面试八股文-14_14-MCP-Skill-Function Calling

pdf版下载链：https://pan.quark.cn/s/9cc742e9c2a8

14 MCP、Agent Skills 与 Function Calling：协议、工具与安全

更新： 2026-10-12

难度： ⭐⭐⭐⭐⭐

考点： MCP 2026-07-28、Agent Skills、Function Calling、长任务、授权、沙箱与企业治理

口径说明：本文以 MCP 2026-07-28 正式规范为准。产品命令、SDK API 和 Registry 条目变化快，面试前应再次核对官方文档。

📋 目录

MCP 基础与架构
Server 与 Client 工程
MCP、Function Calling 与 Agent Skills
权限、安全与企业治理
长任务、扩展和生态
官方来源

一、MCP 基础概念

Q1: 什么是 MCP（Model Context Protocol）？为什么 AI 工程师需要掌握？

MCP 是 AI 应用连接外部数据、工具和工作流的开放协议。它基于 JSON-RPC 2.0，把 Host、Client、Server 之间的能力发现、调用和生命周期标准化。

它解决的是"连接层"问题，而不是替代模型推理、业务编排或权限系统：

text 复制代码

用户 → Host/Agent → MCP Client ⇄ MCP Server → 业务 API / 数据 / 工具

面试重点：

工具实现一次，可被多个兼容 Host 复用。
Client 和 Server 在初始化时协商协议版本与能力，不能假设对端支持全部特性。
MCP 只定义交互协议；业务权限、数据治理、沙箱和审计仍需应用实现。
截至 2026-10-12，正式规范版本为 2026-07-28。

Q2: MCP 的核心原语有哪些？谁控制它们？

Server 侧三个核心原语：

原语	控制方	用途
Tools	模型选择、Host 执行策略约束	执行动作或查询
Resources	应用选择	以 URI 暴露上下文和数据
Prompts	用户选择	可复用交互模板

还要知道：

Elicitation：Server 在处理请求时要求补充用户输入。
Tasks：异步长任务扩展，不属于核心原语。
Skills over MCP、MCP Apps：可选扩展，必须显式协商支持。
Roots、Sampling、Logging 在 2026-07-28 中已进入 Deprecated；新实现不应继续依赖。

Q3: MCP 的 Host、Client、Server、Transport 如何协同？

Host：面向用户的 AI 应用，负责模型、权限、上下文与 UI。
Client：Host 内与某个 Server 建立会话的协议组件。
Server：声明并实现 tools/resources/prompts。
Transport：承载 JSON-RPC 消息。

标准传输：

stdio：Host 启动本地子进程，按行传输 JSON-RPC。
Streamable HTTP：每条消息向单一 MCP endpoint 发送 POST，响应为 JSON 或请求级 SSE。

HTTP+SSE 已废弃；2026-07-28 还移除了旧 Streamable HTTP 的 SSE 重放语义。断线后应把未完成请求视为失败，并用新 request ID 重发可安全重试的操作，不能假设 Last-Event-ID 恢复。

Q4: MCP Server 有哪些类型？如何选？

按信任边界分比按"官方/社区"分更有价值：

类型	适用场景	关键控制
本地 stdio	文件、代码、开发工具	工作目录限制、进程权限
企业远程 Server	内部 API、数据平台	OAuth、租户隔离、审计
SaaS 远程 Server	第三方服务	数据处理条款、最小 scope
聚合 Gateway	多 Server 治理	身份传播、策略、路由、可观测

不要把 Registry 中"可发现"误当作"已审计"。引入第三方 Server 前应检查发布者、源码、依赖、权限、更新策略和数据流向。

二、MCP Server 开发实战

Q5: 如何用 Python 开发 MCP Server？

生产实现建议使用官方 Python SDK 当前稳定线，并按 SDK v2 文档编写或迁移。核心步骤：

定义 tool/resource/prompt 及 JSON Schema。
在 handler 内做业务鉴权、输入校验、超时和错误映射。
本地优先用 stdio；远程部署用 Streamable HTTP。
用 Inspector、契约测试和真实 Client 验证能力协商。
固定 SDK 版本，升级时跑协议与回归测试。

示意代码只表达边界，不绑定易变 API：

python 复制代码

def search_orders(user_id: str, limit: int = 20) -> list[dict]:
    if not 1 <= limit <= 100:
        raise ValueError("limit out of range")
    # 身份从可信执行上下文取得，不能相信模型传入的 user_id 即有权限
    authorize(current_principal(), "orders:read", user_id)
    return db.query(
        "SELECT id, status FROM orders WHERE user_id = ? LIMIT ?",
        (user_id, limit),
    )

Q6: MCP Server 如何做认证、授权和安全控制？

要区分：

认证：调用者是谁。
授权：该身份能对哪个资源执行什么动作。
用户确认：当前高风险动作是否得到用户明确同意。

远程 HTTP 授权遵循 MCP Authorization：OAuth 体系、Protected Resource Metadata、资源指示符和 audience 校验。Server 必须只接受签发给自己的 token，禁止把 Client token 原样透传给下游 API。

stdio 不等于"天然安全"：本地子进程继承用户权限，仍需限制目录、环境变量、网络、子进程和密钥读取。

Q7: 如何在 Claude Code、Cursor、Copilot 或自研 Host 中配置 MCP？

稳定回答应讲配置模型，不背易变菜单：

json 复制代码

{
  "mcpServers": {
    "example": {
      "command": "python",
      "args": ["server.py"],
      "env": {
        "TOKEN": "${ENV_TOKEN}"
      }
    }
  }
}

或远程 Server：

json 复制代码

{
  "mcpServers": {
    "example": {
      "url": "https://mcp.example.com/mcp"
    }
  }
}

检查点：作用域是个人、项目还是组织；配置是否会提交；密钥是否来自 secret store；Client 是否支持目标扩展；远程 URL 是否走 OAuth。具体路径和命令以各产品官方文档为准。

Q8: 大型工具结果和长输出应该怎么处理？

不要依赖未经官方确认的"500K 永续化"或私有 resultSizeLimit 字段。通用做法：

工具返回摘要、分页游标、artifact URI，而不是把全量日志塞进上下文。
大对象放对象存储或 Resource，返回校验和、MIME、大小与权限信息。
限制单次输出、分页大小和总预算。
长处理使用 Tasks 扩展；短请求用 progress、timeout 和 cancellation。
对模型上下文另做截断、压缩和引用，不把传输成功等同于模型能有效使用。

三、MCP vs Function Calling vs Agent Skills

Q9: MCP 和 Function Calling 有什么区别？

维度	Function Calling	MCP
层级	模型/API 输出工具名和参数	Host 与工具服务的连接协议
发现	应用把 schema 交给模型	Client 从 Server 列举能力
执行	应用代码负责	MCP Client/Server 交换协议消息
复用	通常绑定单个应用	可跨兼容 Host 复用

二者经常一起使用：Host 把 MCP tool schema 暴露给模型，模型生成 tool call，Host 再通过 MCP 调用 Server。

Q10: MCP 和 OpenAI Tools/Responses API 有什么关系？

OpenAI Function Calling 的稳定主线是 Responses API 的工具调用循环：

text 复制代码

定义 tools → 模型返回 function_call → 应用校验并执行
→ 把 function_call_output 回传 → 模型继续或结束

应开启 strict: true，对象 schema 设置 additionalProperties: false，并按严格模式要求声明字段。Schema 合规不代表业务安全，仍需做授权、幂等、限额和输出校验。

MCP 负责外部工具的协议化接入；Responses/Agents SDK 负责模型调用与编排。不要把某厂商 API 能力误称为 MCP 的一部分。

Q11: 企业 MCP 安全应该分哪几层？

身份层：OAuth、audience、scope、租户身份。
协议层：版本与 capability 校验、schema、大小、超时、取消。
策略层：allow/ask/deny、风险分级、人工审批。
执行层：OS/容器沙箱、只读挂载、无网默认、资源配额。
数据层：脱敏、最小披露、租户过滤、保留期。
供应链层：版本锁定、签名、SBOM、来源审查。
审计层：trace、身份、工具、参数摘要、结果状态和审批证据。

Prompt、tool description 和 annotations 都是提示信息，不是强制安全边界。

Q12: 企业如何规模化部署 MCP？

推荐分层：

text 复制代码

AI Host
  → 身份与策略层
  → MCP Gateway / Registry
  → 独立信任域中的 Servers
  → 业务 API / 数据源

Gateway 可统一认证、路由、速率限制和审计，但不能掩盖身份。必须明确 end-user identity、workload identity、下游凭证和租户如何传播。对写操作配置幂等键、审批和补偿；对长任务持久化状态、TTL 和取消。

Q13: 截至 2026-10-12，MCP 规范有哪些关键变化？

以 2026-07-28 为准：

引入 Active / Deprecated / Removed 生命周期和最短弃用窗口。
Streamable HTTP 简化为单 endpoint 的 POST；长期变更通知走 subscriptions/listen。
HTTP+SSE 为 Deprecated。
Tasks 移到官方扩展 io.modelcontextprotocol/tasks，支持 polling、mid-flight input 和 durable handle。
引入 Multi Round-Trip Requests：需要更多输入时返回 InputRequiredResult，Client 重试原请求并提供 input responses。
Roots、Sampling、Logging 已 Deprecated；迁移到显式参数/Resource、直接模型 API 和 OpenTelemetry。
官方扩展包括 Tasks、Skills over MCP、MCP Apps。

Q14: 如何发现和评估 MCP Server？

优先使用官方 Registry 和组织私有 Registry；社区目录只用于发现候选。

评估清单：

发布者与仓库是否可验证。
支持的协议版本、传输和扩展。
工具权限是否最小，写操作是否显式。
OAuth、租户隔离、日志、数据保留。
依赖锁定、漏洞响应、版本迁移。
是否有契约测试、健康检查和卸载路径。

四、安全与权限管理

Q15: 面试中如何回答 "MCP Top 10" 类问题？

不要背未经核验的年份、下载量或编号。以官方规范和威胁模型回答更稳：

凭证泄露与 token passthrough。
confused deputy 与错误 consent。
OAuth discovery SSRF。
工具投毒、描述投毒和供应链风险。
越权、scope creep 与租户数据泄露。
命令/SQL/路径注入。
无边界执行、无限重试和成本攻击。
审计不足与不可追责。

防御落点是最小权限、token audience、per-client consent、egress 控制、沙箱、审批、版本锁定和可观测。

Q16: Agent 安全和传统 Web 安全的差异是什么？

传统 Web 应用主要执行显式代码路径；Agent 会把不可信自然语言、检索内容和工具结果纳入决策。因此"数据可能变成指令"，需要额外治理：

给内容标记来源和信任级别。
不让模型决定自己的权限。
工具参数与业务对象再次鉴权。
高风险动作必须可预览、可审批、可回滚。
限制步数、时间、Token、费用和并发。
用恶意网页、仓库指令、假工具描述做红队 eval。

Q17: Tasks 扩展如何处理长任务？

2026-07-28 中 Tasks 是官方、可选扩展 io.modelcontextprotocol/tasks，不是早期 SEP 编号即可代表的稳定核心能力。

典型流程：

text 复制代码

tools/call → 返回 task handle
tasks/get → 轮询状态
tasks/update → 提供任务中途需要的输入
tasks/cancel → 请求取消

设计要点：任务 ID 高熵并绑定授权上下文；状态持久化；结果 TTL；幂等；轮询退避；取消语义；任务输入与输出审计。不能让模型凭空维护 job ID。

Q18: Confused Deputy、Token Passthrough、SSRF 如何防？

Confused Deputy：代理第三方 OAuth 时做 per-client consent，精确匹配 redirect URI，state 短期且单次使用。
Token Passthrough：校验 issuer、audience、scope、resource；下游调用使用单独获取的下游 token。
SSRF：OAuth 元数据和跳转 URL 要求 HTTPS，解析并阻断私网/链路本地/云元数据地址，每次 redirect 重验，生产环境经 egress proxy。

这些是 MCP 官方 Authorization 与 Security Best Practices 明确覆盖的风险。

Q19: 企业 Readiness 应关注什么？

不是等待"协议替你解决一切"，而是验证：

身份：用户、Client、workload、Server 是否可区分。
策略：scope、资源级授权、审批能否统一。
生命周期：版本、弃用、回滚、Server 下线。
可观测：OpenTelemetry trace、指标、审计关联。
可靠性：超时、取消、重试、幂等、Tasks 恢复。
配置：组织策略能否覆盖本地个人配置。
数据：区域、保留、脱敏、租户隔离。

Q20: MCP Sampling 现在应该怎么回答？

Sampling 曾允许 Server 请求 Client 代调模型，并可携带工具。它在 2026-07-28 已 Deprecated，新实现应直接集成模型提供商 API。

面试回答应体现迁移意识：

旧系统仍需在弃用窗口内兼容和测试。
新系统把模型调用放入明确的 Agent/服务层。
保留审批、预算、模型路由、trace 和数据策略。
不再把 Sampling 当作未来架构的核心卖点。

Q21: MCP Client 类型和 capability negotiation 应如何理解？

"Internal/External Client"不是规范定义的两种 Client 类型。更稳的区分是本地 stdio Client、远程 HTTP Client、Gateway/聚合 Client。

无论形态如何，都必须：

初始化并协商 protocol version。
只使用双方声明的 capability/extension。
对 deprecated feature 做迁移和兼容策略。
为每次请求设置 timeout、cancellation 和 trace。

Q22: MCP Authorization Flow 如何工作？

高层流程：

Client 请求受保护资源，Server 返回 challenge。
Client 读取 OAuth Protected Resource Metadata，发现授权服务器和所需 scope。
Client 走授权码 + PKCE 等安全流程，并用 resource indicator 指定目标 Server。
Server 校验 token 的 issuer、audience/resource、有效期和 scope。
遇到 insufficient_scope 时，由 Client 决定是否做 step-up authorization。

DPoP 可作为更强的 sender-constrained token 机制，但不能把"可选安全扩展"说成所有 MCP 调用都强制使用。

五、发现、Skills 与工程边界

Q23: "MCP Server Card" 是正式能力吗？

不能把早期工作组或提案直接说成已发布标准。当前能力发现主要依靠初始化后的 tools/resources/prompts 列表、Registry 元数据及扩展协商。

如果需要组织级"Server Card"，可自定义元数据描述版本、owner、数据分类、权限和 SLA，但必须明确这是治理层约定，不是 MCP 核心规范。面试中应先说清标准状态，再讲自建方案。

Q24: MCP Triggers / Events 是正式原语吗？

MCP 核心没有一个可任意主动触发 Agent 的通用 @mcp.trigger 装饰器。2026-07-28 的长期变更通知通过订阅能力与 subscriptions/listen；业务事件通常由 webhook、队列、调度器触发 Host，再由 Host 调用 MCP。

推荐架构：

text 复制代码

业务事件 → Queue/Webhook → Orchestrator/Agent → MCP tool

这样事件身份、重放、幂等、死信和审批由成熟基础设施承担。

Q25: MCP Registry 是什么？

官方 MCP Registry 是 Server 的发现索引，不是可信执行沙箱，也不等同于 npm/PyPI 的统一包托管。

企业应在官方/私有 Registry 之上增加：

allowlist、owner、风险级别和数据分类；
发布签名、依赖扫描与版本固定；
审批、灰度、撤回和应急下线；
Client 策略和使用审计。

不要使用未经官方文档确认的发布命令示例。

Q26: Agent Skills、Skills over MCP 和 MCP Tool 有什么区别？

概念	本质	何时加载
Agent Skill	`SKILL.md` + 可选 scripts/references/assets 的可复用工作流	渐进披露
MCP Tool	可调用的远程/本地执行能力	Server 列表发现
Skills over MCP	通过 MCP 发现和消费结构化 Skill 的官方可选扩展	双方协商

Agent Skills 开放规范要求 SKILL.md 至少包含 name 和 description。启动时只加载元数据，匹配任务后加载正文，需要时再读资源。Skill 是"怎么做"，Tool 是"能执行什么"；Skill 中的脚本也必须受权限和沙箱约束。

Q27: 什么情况下不应该使用 MCP？

单应用调用一个固定 API，直接 SDK/HTTP 更简单。
高频低延迟数据面或大规模流处理。
强一致分布式事务。
一次性脚本。
团队无法承担 Server 生命周期与安全治理。
工具只能在已有服务内部使用，没有跨 Host 复用价值。

判断标准：标准化与复用收益，是否大于新增协议、部署和治理成本。

Q28: MCP 有哪些官方 SDK？如何选？

截至 2026-10-12，官方 SDK 页面列出 TypeScript、Python、C#、Go、Rust、Ruby、Java、Swift、PHP、Kotlin，并按完整度与维护承诺分 Tier。Tier 会变化，不能把"十种"永久写死。

选型顺序：

团队主语言与运行时。
当前 spec 与所需扩展支持。
SDK Tier、维护活跃度和迁移成本。
并发、部署、可观测和依赖治理。

Q29: 官方 reference servers 应如何使用？

Reference server 的价值是学习协议和做兼容测试，不代表生产可直接信任。Sequential Thinking、Memory、Everything、Fetch 等名称不能按"2026 新增官方产品"背诵。

生产选择应从官方 Registry 当前条目出发，并验证：

是否仍维护、发布者是谁；
权限与网络边界；
数据是否离开组织；
是否支持目标 spec；
是否有安全审计和替代/下线路径。

高频面试话术

MCP 是连接协议，Function Calling 是模型/API 的工具调用机制，Agent Skill 是按需加载的可复用工作流。生产系统通常三者组合：Skill 规定流程，模型生成严格 schema 的调用，MCP 连接工具；权限、沙箱、审批和审计由 Host 与企业治理层强制执行。
我不会把 roadmap、SEP 或社区插件当成正式规范。当前以 MCP 2026-07-28 为准：Streamable HTTP 是远程主线，HTTP+SSE、Roots、Sampling、Logging 已弃用；长任务走 Tasks 扩展，Skills over MCP 也是显式协商的扩展。