模块 06 — 架构师问答题（含 2 道场景决策题）

先自己答，再对照讲解。讲解后附来源。

Q1. 用你自己的话定义 MCP 的三方角色，并说明为什么 client 与 server 是 1:1。

讲解要点：宿主 (Host) 是 AI 应用本体（编排、权限、同意、上下文聚合）；客户端 (Client) 是 host 内的连接器，只与一个 server 通信；服务器 (Server) 通过原语暴露能力。1:1 的意义：每个 client 维护自己 server 的安全边界，host 通过隔离多个 client 实现「server 互相看不见、也看不到完整对话」的隔离原则。 来源: https://modelcontextprotocol.io/specification/2026-07-28/architecture（访问于 2026-08-30）

Q2. tools / resources / prompts 三大原语分别由谁控制？为什么这个区分重要？

讲解要点：Tools = 模型控制 (model-controlled)（模型自主发现并调用）；Resources = 应用驱动 (application-driven)（host 决定如何取用上下文）；Prompts = 用户控制 (user-controlled)（用户显式选择，常做斜杠命令；内容由 server 定义）。重要性：控制方决定了原语的暴露面与安全模型——tool 是模型可触发的行动路径（要人在回路），resource 是数据面（要同意与隐私控制），prompt 是用户界面。把只读数据做成 tool 会扩大模型的行动面；把行动做成 resource 模型就不会调。 来源: https://modelcontextprotocol.io/specification/2026-07-28/server/tools、/server/resources、/server/prompts（访问于 2026-08-30）

Q3. stdio 与 Streamable HTTP 各适合什么部署形态？各自的代表性安全动作是什么？

讲解要点：stdio 适合本地开发工具（host 拉起子进程，标准流通信，零网络面；凭证从环境取，不应走 OAuth）；Streamable HTTP 适合远程共享/企业集中部署（单 MCP endpoint 接 POST，响应为 JSON 或请求级 SSE；走 OAuth 2.1 子集）。安全动作：stdio——只装可信 server（本地进程=本机权限）；HTTP——必须校验 Origin 头防 DNS rebinding、本地只绑 127.0.0.1、实现认证。加分点：2026-07-28 版删除了 GET 流端点与协议级会话。 来源: https://modelcontextprotocol.io/specification/2026-07-28/basic/transports、/basic/transports/streamable-http、/basic/authorization（访问于 2026-08-30）

Q4. 截至 2026-08-30，MCP 规范的 Modern 与 Legacy 时代划分是什么？为什么旧教程里的 initialize 握手会「过时但不错误」？

讲解要点：Modern = 2026-07-28 及以后：无状态、每请求 _meta 携带版本与能力、server/discover 可选发现、server 不再主动发 JSON-RPC 请求；Legacy = 2025-11-25 及以前：initialize 握手、连接级会话、server 可发起 sampling 等请求。规范要求 dual-era 实现按兼容矩阵互操作（探测时代、必要时回退），所以旧资料描述的是 Legacy 行为，仍然有效但必须标注年代。 来源: https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning（访问于 2026-08-30）

Q5. 工具规模上去之后上下文会发生什么？官方给出的治理路径是什么？

讲解要点：全量注入工具定义会吃掉大块窗口（官方数据点：上百工具 ~150k tokens）并降低工具选择准确率（30–50 个以上明显下降）。治理：渐进式发现 (progressive discovery) 的 catalog → inspect → execute 三层模式 + 检索策略（关键词/embedding/子代理/混合），切换阈值建议窗口的 1%–5%；Anthropic 生态可用原生 tool search tool（defer_loading: true，regex/BM25 两种）；再往上是动态 server 管理（按需连接/断开 server）。必须强调反向结论：小规模全量注入完全合理，不要过度工程（示例 03 的第一个场景就是证据）。 来源: https://modelcontextprotocol.io/docs/2026-07-28/develop/clients/client-best-practices、https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool（访问于 2026-08-30）

Q6. MCP 的工具错误处理与普通 API 错误处理有什么本质不同？

讲解要点：tools/call 的业务错误是结果的一部分——server 抛 ToolError，client 收到 is_error=True + 可读错误文本进 content，模型能读到错误并自我修正（对应模块 04/05 的修复式重试）；协议级错误才是 JSON-RPC error / 传输异常。host 的消费顺序：先查 is_error 再信任结构化结果。示例 02 已实跑验证该语义。 来源: https://modelcontextprotocol.io/specification/2026-07-28/server/tools、https://py.sdk.modelcontextprotocol.io/client/（访问于 2026-08-30）

Q7. 列出至少四个官方 Security Best Practices 点名的攻击，各给一个缓解。

讲解要点（任四即可）：Confused Deputy（proxy 静态 client ID + 动态注册 + consent cookie 跳过同意 → per-client consent）；Token Passthrough（原样转发上游 token，被授权规范禁止 → 校验 audience/换发 token）；SSRF（server 拉取可被指向内网 → 出网白名单）；State Handle Hijacking（句柄可猜测 → 不可预测 + 绑定会话）；Local Server Compromise（本地进程全权限 → 供应链信任 + 最小权限）；OAuth URL 校验 / localhost 重定向伪装 / Mix-Up（严格 issuer 与 redirect 校验、state/nonce）；scope 最小化。 来源: https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices（访问于 2026-08-30）

场景决策题（Scenario Decision）

S1. 企业知识助手：内部工具的接入方式

Scenario：你在为一家 2000 人的公司做企业知识助手（Claude API + 自研 host）。需要接入：Confluence（现成 MCP server）、内部工单系统（有 REST API）、销售数据库（Postgres）。工具总量预计 60+，且公司另有两个团队想在各自的 Claude Code / 内部 agent 里复用这些集成。 Constraints：三个消费方（你的助手 + 两个团队）；工具数会持续增长；平台团队愿意维护 server；数据含客户 PII，需要 per-user 权限。 Options：A) 全部写进助手代码里直接调 REST；B) 每个系统立一个 MCP server，统一工具发现与授权；C) 混合：工单直连 REST，Confluence/DB 走 MCP。 Best choice：B。 Why：多消费方复用 + 60+ 工具 + 持续增长，正是 MCP 的适用区（标准化发现、生态现成 server、运行时 tools/list）；PII 的 per-user 授权可以在 server 侧按请求凭证做 scope 过滤（规范允许工具集随请求授权不同）。 Why others are weaker：A 把集成锁死在一个应用里，两个团队要重写三遍；60+ 工具注入还要自己做 progressive discovery，且无复用。C 看似折中，但工单系统恰恰是其他团队也要用的——拆成两条集成路径反而多维护一套。 Tradeoffs：引入协议层与 server 运维（平台团队成本）；60+ 工具必须配 tool search / progressive discovery 治理上下文；每个 server 成为新的信任边界要过安全评审。 What would change the answer：如果只有你这一个消费方、工具 <10 个、延迟极度敏感——A（直接 API）反而对；如果工单系统只被你的助手用且调用模式固定——C 的混合成立。

S2. 交易系统的行情接入

Scenario：高频交易公司的 Claude 内部分析助手需要实时行情数据（内部低延迟行情 API，P99 < 50ms）+ 一个「生成合规报告」能力（内部 LLM 管线，慢、低频）。 Constraints：行情链路有严格延迟预算与既有熔断/重试基建；合规报告低频、由分析师显式触发；两个能力都只被这一个助手消费。 Options：A) 两个能力都包成 MCP server；B) 行情直接 API 集成（应用内工具，模块 04 模式），合规报告做成 MCP server；C) 全部直接 API。 Best choice：B。 Why：行情走直接集成——延迟敏感、调用模式固定、单消费方、已有可靠性基建，MCP 协议层是纯开销；合规报告适合 MCP 化——低频、显式触发（可做成 prompt/tool）、且未来其他 host（如 Claude Code）可能复用。 Why others are weaker：A 给延迟关键路径加了一层协议封装与进程/网络跳数，还把既有熔断重试逻辑搬到 server 里重来一遍；C 让合规报告失去标准化暴露与复用可能性，但若确认永无第二个消费方，C 也完全成立（见下）。 Tradeoffs：B 是两条集成范式并存——团队要同时掌握两套（但每套都用在正确的地方）；A 换取的是架构统一性，付出的是延迟与基建重复；C 最省事但封闭。 What would change the answer：如果行情 API 调用模式开始多样化（模型需要探索式查询多个行情工具），或第二个消费方出现——行情也该 MCP 化；如果合规报告确定永远单消费方——C 变成最佳。