架构决策训练 — 工具/MCP 类（EX09–EX16）

主题：接入方式（API or MCP）、原语选择（Tool or Resource）、控制权归属（Claude decides or application decides）、审批（automatic write or human approval）、重试幂等、工具设计。题目三要素在前，答案在文末。

EX09 — 集团 AI 平台接入 30+ 系统（★★☆）

核心张力：API or MCP?（依据：模块 06）

Scenario 大型集团的 AI 平台团队要支撑 12 个内部团队构建 agent 应用，都需要访问共同的后端系统：Jira、Confluence、Slack、Snowflake、内部 CRM、部署系统等 30+ 个。每个系统都有自己的认证与权限模型。平台团队希望「接一次，处处可用」，并能统一治理审计。

Constraints

• M 个应用团队 × N 个后端系统，直接集成的连接数是 M×N
• 后端系统的凭证与权限必须集中治理，不能分发给各应用
• 需要统一的审计与工具治理（哪些 agent 能用哪些工具）

Options A. 每个应用团队自己写集成代码（直连各系统 API） B. 平台团队为每个后端系统建 MCP server，应用侧作为 MCP client 接入（N 个 server，M 个 client） C. 平台团队写一个「万能网关」HTTP API，把 30 个系统全部包一层 REST D. 让各应用直接用各 SaaS 厂商自带的 agent 集成，平台不治理

EX10 — 创业公司的一个天气 API（★☆☆）

核心张力：API or MCP?

Scenario 三人创业公司做日程助手，唯一的外部依赖是天气 API：一个函数、三个参数（地点/日期/单位）。没有其他 agent 应用计划，没有多团队复用需求。

Constraints

• 单应用、单工具、参数简单
• 团队人力极少，交付速度至上
• 无跨团队治理需求

Options A. 直接写一个 client tool（应用内函数封装天气 API，定义为 Claude 的 tool） B. 自建 MCP server 包住天气 API，应用经 MCP 调用 C. 让 Claude 用 web_search server tool 搜天气 D. 接入第三方公共天气 MCP server

EX11 — 组织架构树与 wiki 库（★★☆）

核心张力：Tool or Resource?（依据：模块 06；MCP 2026-07-28 规范）

Scenario 你在为公司内部助手建 MCP server，要暴露两类内容：① 组织架构树——agent 需要在推理时按语义查询（「找负责 X 产品的 VP 是谁」）；② 1000 篇内部 wiki 文档——希望在会话开始时可列出/订阅其更新，由应用或用户决定把哪些装进上下文，而不是模型自主决定。

Constraints

• 组织架构查询需按语义/结构动态检索
• wiki 文档有稳定 URI，需要 listChanged/subscribe 式更新通知
• 控制权归属是设计核心：谁触发加载

Options A. 全部做成 MCP tools（model-controlled） B. 全部做成 MCP resources（application-driven） C. 组织架构做成 tool（语义查询），wiki 做成 resources + resource templates（URI 标识、可订阅） D. 组织架构做成 prompts 原语，wiki 做成 tool

EX12 — 退款流水线（★★☆）

核心张力：Claude decides or application decides?（依据：模块 04 §4/§6）

Scenario 电商退款流程已定型为固定四步：查订单 → 校验退款资格（规则明确）→ 执行退款（资金操作）→ 生成通知文案。步骤顺序永远不变，每步参数明确。少数订单会触发「异常分支」（规则冲突、历史特殊情况）需要灵活判断。

Constraints

• 流程步骤与顺序固定、可枚举
• 执行退款是不可逆资金操作
• 异常分支（约 5%）需要灵活推理
• 审计要求每步可追溯

Options A. 给 Claude 全套工具（tool_choice: auto），让它自主决定调什么、什么顺序 B. 固定 workflow：应用代码编排四步，关键校验与执行走确定性代码；Claude 用 tool_choice: {"type": "tool"} 被定向调用（做异常判断与文案生成），大额/异常走人审 C. 全确定性代码，Claude 完全不参与 D. 开放式 agent：Claude 拿全套工具自主循环直至完成

EX13 — CRM 批量修改与外发邮件（★★☆）

核心张力：automatic write or human approval?（依据：模块 04 §6）

Scenario 营销 agent 有两个写操作：① 批量更新 CRM 客户标签（可逆：有操作日志可回滚，但单次最多影响 5 万条记录）；② 给客户群发邮件（不可逆：发出无法撤回）。团队要决定哪些动作自动执行、哪些进人审队列。

Constraints

• ①可逆但量大、②不可逆
• 每天有数千次 ① 类操作，人审全部会淹没团队
• 邮件内容由模板 + 个性化生成，出错影响品牌
• 合规要求对外通信留档

Options A. 全部自动执行（信任模型 + 好的 prompt） B. 全部人审（安全至上） C. 分级：① 自动执行 + 批量限额 + 审计日志 + 异常暂停阈值；② 一律人审队列（批量小的场景允许抽样人审 + 发送限额灰度） D. ①人审、②自动（按操作频次定）

EX14 — 支付工具超时（★★★）

核心张力：retry, reconcile, or give up?（idempotency）（依据：模块 04 §13）

Scenario agent 的 charge_customer 工具调用支付网关，网关侧实际已扣款成功，但响应在网络上超时了。你的执行器现在收到的是 TimeoutError。用户在等结果，Claude 在等 tool_result。

Constraints

• 超时 ≠ 失败：扣款可能已成功（结果未知）
• 盲目重发 = 可能双重扣款
• 用户会话仍在进行，需要尽快给出结果
• 支付网关支持「按幂等键查询交易状态」接口

Options A. 立即原样重发支付请求（赌它失败了） B. 回传 is_error: true，内容写「支付失败」，让 Claude 决定 C. 先对账：用幂等键查询该笔交易状态——已成功则返回成功结果；未成功才带同一幂等键安全重试；仍不确定则回传带明确状态说明的 is_error D. 抛异常终止整个会话，转人工

EX15 — 参数错误率高的录入 agent（★★☆）

核心张力：strict tool use or prompt discipline?（依据：模块 04 §4、模块 05 §2.4）

Scenario 数据录入 agent 调用 create_ticket 工具，参数复杂（15 个字段、多层嵌套、很多可选）。上线后约 8% 的调用缺必填字段或类型错误，靠回传 is_error 让 Claude 自我修正，平均浪费 2.3 轮。

Constraints

• schema 中约 14 个字段是可选的
• 平台支持 strict tool use（strict: true），但单请求 strict 工具数上限 20、可选参数总数上限 24、union 类型参数上限 16
• agent 还有另外 6 个工具

Options A. 在工具 description 里更详细地写「务必填全字段」 B. 重构 + strict：schema 扁平化、能 required 的全改 required、拆分嵌套；create_ticket 标 strict: true，其余工具按需 C. 全部 7 个工具都标 strict: true D. 不用 strict，加一层本地校验 + 修复式重问回路

EX16 — 2MB 日志工具结果（★★☆）

核心张力：trim, summarize, or server-side processing?（依据：模块 04 §3）

Scenario 日志分析工具 fetch_logs 返回原始 JSON 日志，典型体量 2MB。全量回传 tool_result 后：上下文被淹没、每轮都在为它付 token、Claude 反而更容易漏关键行。而 agent 的任务是「找到 ERROR 相关的根因线索」，不同任务关注的字段不同。

Constraints

• 不同查询关心的字段/模式不同（无法预先固定一个裁剪集）
• 原始日志敏感（内网拓扑信息）
• 平台提供 code_execution server tool（代码在 Anthropic 侧沙箱执行）
• 延迟预算中等

Options A. 全量 2MB 回传，让 Claude 自己看 B. 工具侧裁剪为高信号摘要（按 ERROR 级别过滤 + 关键字段投影 + 语义化 ID），并支持结构化查询参数让 Claude 迭代缩小范围 C. 回传原始日志给 code_execution，让 Claude 写代码在沙箱里分析 D. 摘要 B + 对敏感日志走 C 前先脱敏（或 C 不可接受敏感数据出域时只用 B）

答案与解析

EX09 — Best choice: B

Why

• 连接数从 M×N 降为 M+N：12 应用团队不用各写 30 套集成，平台团队维护 30 个 server（模块 06 的核心经济学）。
• MCP 的 client-host-server 架构天然把凭证留在 server 侧：应用（client）不接触后端系统的密钥；per-request auth 还可让同一 server 按调用者返回不同工具集（来源: https://modelcontextprotocol.io/specification/2026-07-28/server/tools，访问于 2026-08-30）。
• 统一治理点：审计、限流、工具白名单都在 server 层做一次。

Why other choices are weaker

• A：M×N 重复建设，凭证分发到各应用（安全面扩大），治理碎片化——正是 MCP 要解决的问题。
• C：自造协议 = 重新发明 MCP 却失去生态（现成 client、规范化的错误语义、能力协商）；「万能网关」单体还带来单点故障与变更协调成本。
• D：放弃治理 = 放弃审计与权限控制，企业场景不可接受。

Tradeoffs

• 平台团队成为瓶颈：新系统接入排期、server 质量参差需要 SLO 管理。
• MCP server 的运维（部署、升级、安全加固）是持续性成本。

What would change the answer

• 若只有 1–2 个应用团队（M 很小）→ 直接集成的简单性胜出（见 EX10）。
• 若某系统已有官方 MCP server → 直接采用，不自建。

EX10 — Best choice: A

Why

• 单应用 + 单工具：MCP 的收益（复用、治理、生态）全部不存在，成本（server 部署、协议层）是纯开销。
• 一个 client tool 封装 API 调用是最短路径，行为完全在应用内可控（模块 04 的标准回路）。

Why other choices are weaker

• B：为三参数函数建 server 是负资产架构。
• C：web_search 拿到的是网页文本而非结构化天气数据，精度与时效都差，且引入间接注入面。
• D：引入外部依赖与信任面（第三方 server 的可用性/隐私），换不来任何收益。

Tradeoffs

• 若日后长出第二个应用要复用天气能力，需要小规模重构。

What would change the answer

• 应用数量增长（≥3 个复用方）或需要集中治理凭证 → 升级为 B（自建或采用现成 MCP server）。
• 若官方/可信方提供高质量 MCP server 且无敏感数据顾虑 → D 变得合理。

EX11 — Best choice: C

Why

• MCP 三原语的控制权是分界：tools = model-controlled（模型决定何时调用），resources = application-driven（应用决定加载什么），prompts = user-controlled（用户主动触发）（来源: https://modelcontextprotocol.io/specification/2026-07-28/server/tools 与 /server/resources，访问于 2026-08-30）。
• 组织架构「按语义查询」是模型的即席决策 → tool（模型在推理中决定查谁）。
• wiki「列出/订阅/由应用决定装什么」+ 稳定 URI + listChanged 更新通知 → resources + resource templates（URI 模板，RFC 6570）。

Why other choices are weaker

• A：wiki 全做成 tools 意味着 1000 篇文档的加载全靠模型自主调用——上下文被模型偏好而非应用策略控制，且失去 resources 的订阅/更新语义。
• B：组织架构做成 resource = 应用必须预判要哪部分架构树塞进上下文，而「找负责 X 的 VP」正是模型运行时才知道的即席需求。
• D：prompts 是用户触发的斜杠命令式交互原语，与两类需求都不匹配（它管理的是「用户发起的预设指令模板」，不是数据暴露）。

Tradeoffs

• 双原语并存增加 server 的接口设计面；文档里要写清「什么能力在哪个原语下」。
• wiki 若未来需要语义搜索（不只是 URI 定位），需增加一个 search tool——原语混用是常态，按「谁决定」逐能力判断。

What would change the answer

• 若 wiki 也要语义检索且由模型即席发起 → 为 wiki 增补 search tool（C 的扩展版）。
• 若组织架构只需静态快照进上下文 → 降级为 resource。

EX12 — Best choice: B

Why

• 步骤固定可枚举 = workflow 信号（模块 08 官方定义：预定义代码路径编排 LLM 调用）；确定性步骤（资格校验、资金操作）留在代码里，可测试、可审计、行为可复现。
• tool_choice: {"type": "tool", name} 定向调用 = 「Claude decides」被收窄为「application decides 何时用 Claude 的判断」——5% 异常分支才把判断权交给模型。
• 不可逆资金操作叠加审批/限额（模块 04 §6 人审判据：不可逆 + 高代价）。

Why other choices are weaker

• A：auto 模式下顺序不保证（模型可能跳步、改序），资金流程的确定性交给概率组件——审计与合规不可通过。
• C：浪费了 Claude 在异常分支与文案生成上的价值；异常订单全转人工则运营成本高。
• D：与 A 同病且更甚：开放式循环把不可逆操作暴露给全量路径不确定性。

Tradeoffs

• workflow 的分支逻辑要维护（新增异常类型改代码）。
• 定向调用（any/tool）会作废 messages 部分缓存 + 预填 assistant 行为（无自然语言解释）——流水线场景可接受（模块 04 §4 陷阱）。

What would change the answer

• 若流程开始开放化（步骤不可枚举、顺序取决于案情）→ agent 化（A/D）才值得评估，且资金操作仍须留在确定性执行器。
• 若异常分支比例升到 50%+ → 「workflow 为主」与「agent 为主+关键步代码门」的混合要重新设计边界。

EX13 — Best choice: C

Why

• 审批判据按风险分级（模块 04 §6）：①可逆 → 自动 + 审计 + 限额；②不可逆/对外 → 人审。人审是稀缺资源，只花在不可逆上。
• ①的防护组合：批量限额（单次上限）、异常暂停阈值（错误率超阈值自动停）、完整审计日志（谁/何时/改了什么/可回滚）。
• ②邮件：内容生成后进人审队列，合规留档在发送环节完成。

Why other choices are weaker

• A：prompt 约束不是强制（LLM 指令 ≠ 应用层强制）；批量误操作的爆炸半径（5 万条）与误发邮件的不可逆性都没有结构防护。
• B：数千次/天的可逆操作全人审 = 团队被淹没，实际后果必然是「盲目批量批准」，人审形同虚设——过度控制反而降低安全。
• D：频次高低与风险大小无关——高频可逆操作自动、低频不可逆操作人审，方向恰好相反。

Tradeoffs

• ①的自动执行仍可能批量出错（模型系统性误解标签规则）：限额与暂停阈值控制爆炸半径，不能归零。
• ②人审带来延迟与人力成本；抽样+灰度策略要在安全与效率间定量化。

What would change the answer

• 若①的操作实际不可逆（CRM 无回滚能力）→ 升级进人审或先补回滚能力。
• 若②有可靠的事前校验 + 事后撤回机制（部分邮件系统支持撤回）→ 可对人量小、模板成熟的邮件做限额自动化。

EX14 — Best choice: C

Why

• 超时 ≠ 失败：结果未知时的第一动作是对账（查询交易状态），不是重发（模块 04 §13）。
• 幂等键贯穿：创建支付时生成业务幂等键（如 订单ID:退款操作），查询与可能的重试都携带同一键——网关侧保证同键只执行一次副作用。
• 对账后三种出口：已成功 → 返回成功 tool_result；确认未成功 → 同键安全重试；仍不确定 → 回传 is_error: true 且内容写明「状态未知，已启动人工核对，请勿建议用户重复支付」——错误消息要可行动（模块 04 §5：别只回 failed）。

Why other choices are weaker

• A：无幂等键的原样重发 = 双重扣款的教科书事故；即使有幂等键，「先重发后查询」也比「先查询」多花一次可能无谓的调用。
• B：「支付失败」是错误信息——它骗了 Claude，Claude 会向用户道歉并可能再次发起支付（模型层重试），把事故放大。
• D：全量转人工是最贵路径，且用户当场拿不到任何反馈；只在 C 的「仍不确定」出口触发。

Tradeoffs

• 对账多一次网关调用延迟；幂等键的去重存储（键→结果，带 TTL）是新增基础设施。
• 「仍不确定」窗口期需要人工核对流程兜底（低频但必须有）。

What would change the answer

• 若网关不支持幂等查询 → 只能靠自建「操作意图日志」（写前记录、写后确认）实现同效果，复杂度上升。
• 若操作是只读的 → 超时直接退避重试即可，无此纠结（读操作天然幂等）。

EX15 — Best choice: B

Why

• strict tool use 的保证是结构性的：strict: true 下工具名与入参保证通过 schema 校验（constrained decoding，模块 05 §2）——把 8% 的参数错误从「概率问题」变成「不可能事件」。
• schema 重构本身就有独立收益：官方建议能 required 就别 optional（每个 optional 翻倍文法状态空间）、扁平化嵌套、拆分请求——很多「15 字段」其实是把多个逻辑操作塞进了一个工具（模块 04 §3 合并原则的反面：合并相关操作 ≠ 堆砌无关字段）。
• 复杂度预算下选择性 strict：create_ticket 是错误重灾区 → 标 strict；其余 6 个工具按实际需要（上限 20 个 strict 工具不是本例约束，可选参数 24 上限倒是逼你把 14 个 optional 砍掉大半）。

Why other choices are weaker

• A：description 写「务必填全」是软指令——模型「知道」仍会漏；这正是 strict 要消灭的失效模式。
• C：全量 strict 消耗复杂度预算（可选参数总数 24 上限）、拖慢文法编译，且大部分工具错误率本来就低——为不存在的问题付结构成本。
• D：校验+重问是 strict 不可用时的退级方案（旧模型/第三方平台），能收敛但保留着 2.3 轮的延迟与 token 成本——有硬保证可用时它就是次优。

Tradeoffs

• strict 的 schema 子集限制（无递归、数值约束等，模块 05 §2.4）：部分校验语义要移到应用执行器里做。
• required 化后，部分调用被迫显式传默认值——工具接口语义要重新设计（这通常是好事：隐式默认变显式）。

What would change the answer

• 目标平台/模型不支持 strict → D 成为正解（退级管线）。
• 若参数错误其实集中在个别字段 → 只重构该字段的 required/enum，无需全量 strict。

EX16 — Best choice: D

Why

• 两层拆解：默认路径（B）用工具侧裁剪——按查询参数（级别过滤、字段投影、时间窗、服务名）返回高信号结果 + 语义化 ID 供追问；这是官方「返回高信号内容」的直接应用（模块 04 §3）。
• 灵活分析路径（C）当任务真的需要在原始数据上写代码时（聚合、正则、跨字段关联），code_execution 让 Claude 用代码处理数据而不用把 2MB 塞上下文。
• 敏感数据约束决定 C 的可用性：原始日志出域（进 Anthropic 侧沙箱）若违反数据政策 → C 前必须脱敏或禁用，只用 B——所以正解是「B 为默认 + C 按数据分级与脱敏后启用」，即 D 的组合表述。

Why other choices are weaker

• A：全量回传 = 上下文被淹没、token 成本爆炸、LitM 让关键行更易被漏（模块 07 §15）；且敏感日志全文进对话上下文是最差的数据暴露面。
• B 单独：裁剪集固定会限制任务（本题明确「不同任务关注字段不同」），没有灵活分析出口。
• C 单独：每次都写代码分析 = 延迟高、且把敏感数据整体送出域；简单查询用不着。

Tradeoffs

• B 的查询参数设计是新的接口维护面（参数化裁剪本质上把「日志查询 DSL」暴露给模型——要防注入与滥用，限额）。
• C 的沙箱执行有安全边界假设（Anthropic 侧隔离），敏感数据场景需要数据分级策略支撑。

What would change the answer

• 日志完全不敏感且任务总是开放式分析 → C 为主、B 为辅。
• 日志高度敏感且不允许任何出域 → 只有 B；更进一步可本地预处理（关键词抽取后再回传）。