Mock Exam 01 · 答案册（Answer Key & Explanations）

配套 mock-01.md。每题给：答案 / 为什么对 / 为什么错（逐个干扰项）/ 考什么架构原则；场景题为全套格式（Best choice / Why / Why others are weaker / Tradeoffs / What would change the answer）。 原创教学题，非官方真题。技术原则出处以课程模块标注（M01–M13）。域权重与考试形式 = 官方 Exam Guide（VERIFIED，截至 2026-08-30）。

快速答案表

（MR = 多选题，答案见下一行）

多选：Q12 B/D · Q13 A/B/D · Q14 A/B/C · Q26 A/B · Q27 A/B/C · Q39 B/C/D · Q40 A/B · Q49 A/B · Q50 B/D · Q58 A/B/C · Q59 B/C · Q60 A/B/C

自评（课程推断）：≥42/60 达到约考参考线；<36 回模块复习。

Part I · Agentic Architecture & Orchestration

Q1. B —— 输入结构化、15 类固定枚举、规则稳定 = 路径完全可预测，是 workflow 的教科书场景：单次调用 + structured output（enum 约束）即可，可测试、可预算。 错项：A「为 agentic 而 agentic」——每个类别一个 worker 引入 15× 量级开销与不可预测性；C 开放式 loop 把控制权交给模型，恰是可预测任务最不需要的；D evaluator-optimizer 适合有清晰评估标准的迭代任务，分类一次即成。 考什么：workflow vs agent 判据——控制权位置与路径可预测性（M08；官方 Building Effective Agents）。

Q2. C —— agent loop 三步：gather context → take action → verify results，循环直到停止条件；模型在每轮用环境反馈调整下一步。 错项：A/D 是无观察的线性/缓存式流程，丢掉 verify 就丢掉了 agent 的自修正；B 是 RAG 单步管线，不是持续回路。 考什么：agent loop 的核心结构与 verify 步的地位（M08）。

Q3. D —— stop_reason: "tool_use" 表示模型请求执行工具：应用执行后必须把结果作为 tool_result 内容块回传，模型才能继续生成最终答案。 错项：A 混淆 end_turn（会话轮完成）；B 混淆 max_tokens（输出被截断）；C 丢弃工具调用等于中断任务。 考什么：Messages API 控制流与 stop_reason 语义（M02/M03；官方 CCAR-F 点名 control flow、stop_reason）。

Q4. B —— 无 stopping conditions（max iterations / 预算上限）的 agent 上生产 = 跑飞烧钱事故，属发布门槛级缺失（M08 Common Mistake #1）。 错项：A subagent 是优化项非门槛；C MCP 是集成选项；D streaming 是体验优化。 考什么：agent 可靠性的最低安全线。

Q5. A —— multi-agent ≈ 15× token 代价；四前提：开放式（open-ended）+ 可并行（parallelizable）+ 超出单窗口 + 单位价值高（M08）。 错项：B 颠倒默认关系——multi-agent 是最后手段；C/D 数字与条件均为编造。 考什么：multi-agent 的经济学与适用前提。

Q6. B —— coordinator-subagent 的核心收益是 context isolation：subagent 在独立窗口消化原始信息，向主会话回传摘要。 错项：A 违背隔离初衷（等于没隔离）；C subagent 不指挥兄弟节点，编排权在 coordinator；D 丢弃了工作成果。 考什么：官方 CCAR-F 指南点名的 coordinator-subagent 模式（Exam Guide 原文主题）。

Q7. A —— 按请求特征分流到不同处理路径（简单→便宜快通道，复杂→强模型）= routing。 错项：B chaining 是固定顺序的串联；C parallelization 是并发执行；D evaluator-optimizer 是生成-评估循环。 考什么：编排模式识别（M08；官方模式命名）。

Q8. D —— 步骤固定、顺序固定、中间产物明确 = prompt chaining，由确定性代码编排。 错项：A 引入不必要的多 agent 协商；B 开放式 loop 用于固定管线是过度设计；C 无中间校验，一步错步步错。 考什么：chaining 的适用判据（确定性序列 + 中间验证点）。

Q9. A —— 并行化的收益条件：子任务独立（无数据依赖），换取墙钟延迟下降或投票一致性。 错项：B 严格有序任务是 chaining 的场景；C 动态选工具是 agent 的事；D 并行化通常增加而非减少总 token。 考什么：parallelization 的适用前提。

Q10. C —— evaluator-optimizer 适合：有清晰可评估标准（rubric）、迭代能带来可测量提升的任务——文学翻译是官方风格示例。 错项：A/D 一次即成、无迭代空间；B 固定管线用 chaining。 考什么：evaluator-optimizer 的判据（生成-反馈闭环是否有明确评估信号）。

Q11. B —— PreToolUse hook 在工具执行前运行，可用非零 exit code 确定性阻断调用——这是「应用层强制」而非模型自觉（官方 CCAR-F 点名 Agent SDK hooks）。 错项：A 描述的是 PostToolUse；C 混淆 system prompt 改写；D 恰好相反——hooks 是强制点不是建议。 考什么：hooks 生命周期与「LLM 指令 ≠ 应用强制」原则（M09/M11）。

Q12. B、D —— B 满足开放式+超窗口（数十来源不可预测）；D 满足可并行+高价值（独立调查可合并）。 错项：A 固定 ETL 是 chaining/workflow 的典型场景；C 单次分类连 agent 都不需要。 考什么：multi-agent 四前提的应用（M08）。

Q13. A、B、D —— 官方 taxonomy 中 routing、prompt chaining、evaluator-optimizer 都是确定性 workflow（编排模式），不是把控制权交给模型的 agent。 错项：C「无界自主循环」正是 agent 的定义特征，不是编排模式。 考什么：workflow（编排模式）vs agent 的分类学边界（M08）。

Q14. A、B、C —— 迭代上限、token/预算上限、墙钟超时都是工程上可控的外部停止条件。 错项：D「模型自己觉得做完了」没有任何外部约束，恰是生产事故的来源——停止条件必须由代码持有。 考什么：stopping conditions 的设计原则：外部、可量化、可执行。

Q15. B

• Best choice: B——确定性 policy engine 把关执行（金额/风险规则→低风险自动执行、高风险进审批门），LLM 只产出建议与交接摘要。
• Why: 执行边界由代码强制，不依赖模型遵守；审计可回放（规则引擎日志+建议依据）；工具面最小（LLM 无直接数据库写权限）；模型输出保持 advisory。
• Why others are weaker: A 用 prompt 承载安全规则 = 软约束，且通用 SQL 工具是最大爆炸半径；C 模型输出即授权，违反「模型建议 ≠ 批准」；D 放弃自动化收益，未利用 LLM 任何价值。
• Tradeoffs: B 需要维护规则引擎与 LLM 建议层的接口；规则变更走代码发布（换来的是可审计）。
• What would change the answer: 若政策变为高度模糊、需逐案判断（无法写成规则），才考虑把更多判断交给模型——但执行门仍在代码层。

考什么：LLM instruction ≠ application enforcement + 审批门设计（M08/M11；官方 escalation/HITL 主题）。

Q16. C

• Best choice: C——把大规模只读探索委派给 explore subagent，主会话只收摘要，保持任务状态干净。
• Why: context isolation 恰好解决「原始网页内容污染主上下文」；主会话保留任务约束与最终答案生成。
• Why others are weaker: A CLAUDE.md 每会话自动加载且官方建议 ≤200 行，塞原始网页是滥用；B 更大窗口不解决 context rot（token 越多召回越差）且成本更高；D /clear 丢失任务状态等于重开。
• Tradeoffs: 摘要有信息损失，需要 subagent 提示中明确「摘要必须保留哪些字段」；多一层调用的复杂度。
• What would change the answer: 若探索量很小（几页文档），直接读入主会话更简单，无需 subagent。

考什么：context isolation 优先于压缩/扩窗（M08/M09；官方 coordinator-subagent）。

Part II · Claude Code Configuration & Workflows

Q17. C —— CLAUDE.md 是 context 不是 enforcement：它是给模型的指导；强制要靠 deny 规则与 hooks（M09 Common Mistake #1）。 错项：A 混淆「指导」与「强制」；B 权限体系在 settings 而非 CLAUDE.md；D managed settings 是另一层且优先级更高。 考什么：官方 CCAR-F 点名的 CLAUDE.md 定位。

Q18. A —— 配置层级 Managed policy → User → Project → Local，managed 最高且可锁定（组织红线所在）。 错项：B/C/D 优先级均低于 managed，冲突时被覆盖。 考什么：配置层级与优先级（M09；官方 CCAR-F 点名 CLAUDE.md hierarchy）。

Q19. D —— 「无论模型怎么决定都拦」的强制点在应用层：permissions.deny 规则（所有模式生效）+ PreToolUse hook（非零 exit code 阻断）。 错项：A/B 是软约束（模型可能不遵守）；C 依赖模型自觉无机制保证。 考什么：LLM instruction ≠ application enforcement（全课程第一原则，M09/M11）。

Q20. B —— plan 是一种 permission mode：只读探索 + 产出计划供人审，批准后才执行（官方 CCAR-F 点名 plan mode vs direct execution）。 错项：A 过时说法；C 恰好相反——deny 规则在所有模式（含 plan）生效；D acceptEdits 只免「编辑类」确认，不等于全放行 Bash。 考什么：permission modes 语义。

Q21. A —— deny 规则在所有 permission mode 下生效，包括 bypassPermissions——这是它与 allow 规则的关键差异（安全红线地位）。 错项：B 限定模式错误；C/D 把强制机制降级为软指导。 考什么：deny 的特殊地位（M09）。

Q22. C —— 组织红线落点：managed settings / managed policy，优先级最高、个人改不掉。 错项：A/B 个人或仓库层面可绕过；D 无强制力。 考什么：企业治理的配置层级。

Q23. B —— 截至 2026-08-30：custom commands 已并入 Skills，Skills 是现行概念。 错项：A 两套并行是过时认知；C 无替代错误；D Skills 不限于 headless。 考什么：过时术语/旧教程识别（官方要求按当前文档备考）。

Q24. D —— headless/CI 无人值守：权限应比交互更收紧——最小 allow-list + deny + hook 兜底；默认配置不等于安全。 错项：A bypassPermissions 在 CI 是重大风险；B 默认不等于安全；C headless 无法交互确认。 考什么：headless 模式的权限方向（M09）。

Q25. A —— subagent 的架构收益：独立上下文窗口 + 最小权限工具集——上下文隔离与权限收窄二合一。 错项：B 不改变模型能力；C 权限体系仍然必要；D 恰好相反——subagent 默认不共享主会话上下文。 考什么：subagent 的隔离设计（M09）。

Q26. A、B —— A 编码风格偏好 → CLAUDE.md 指导（正确匹配）；B 阻断 secrets 读取 → deny 规则（正确匹配，应用层强制）。 错项：C「never push to main」写进 CLAUDE.md 是软约束，需要 hook/deny 强制；D PII 脱敏靠 system prompt 请求 = 无强制。 考什么：指导（guidance）vs 强制（enforcement）的机制选择。

Q27. A、B、C —— 探索性大任务交 subagent（隔离）、CLAUDE.md 保持精简（官方建议 ~≤200 行）、长会话 /compact（接受有损）都是正当的 context 管理手段。 错项：D 把构建日志全量塞 CLAUDE.md 恰是反模式——每次会话都加载且迅速膨胀。 考什么：Claude Code 内的上下文管理实践（M09）。

Q28. B

• Best choice: B——managed settings 层 deny Read(./secrets/**) + PreToolUse hook（组织级、个人不可关）；高风险重构走 plan mode + 人审计划；onboarding 打包为 Skills 复用。
• Why: 三个需求分别落在正确的层：强制（managed deny + hook）、流程（plan mode 人审）、复用（Skills）；低风险仓库保持自治。
• Why others are weaker: A 全靠 CLAUDE.md 软约束，secrets 保护可被绕过；C bypassPermissions + 事后审计 = 事故先发生再发现；D 禁用工具损失最大且规则在 wiki 无强制力。
• Tradeoffs: managed policy 需要平台团队维护、有变更流程成本；hook 误报可能拖慢开发（要留豁免流程）。
• What would change the answer: 若无组织级管理能力（如个人使用），退而求其次用 project settings deny + 仓库级 hook，但「个人不可关」的要求就达不到。

考什么：配置层级综合应用 + plan mode + Skills（M09，官方 CCAR-F 域 2 核心）。

Part III · Prompt Engineering & Structured Output

Q29. D —— constrained decoding 在解码期禁止非法 token，保证格式合法；不保证语义——字段值可以格式正确但内容错误，语义要靠评估管线验证。 错项：A 越界承诺；B/C 与机制无关或贬低为 best-effort。 考什么：structured output 的能力边界（高频辨析，M05；官方 CCAR-F 点名 JSON schemas via tool_use）。

Q30. A —— 最可靠 = 让解码器不可能产出非法格式：schema 约束的 structured output 或 strict tool use。 错项：B prompt 指令是软约束、永远有漏网率；C prefill 已弃用（4.6+ 返回 400）；D 提高温度只会增加出错面。 考什么：软约束 vs 硬约束的排序（M05）。

Q31. A —— 「prompt 里写格式要求」没有机制保证，是最不可靠的选项。 错项：B/C 是硬保证；D 是无结构化输出环境下的标准补丁（把校验错误回喂模型）。 考什么：格式保证手段的可靠性排序。

Q32. C —— repair-retry 的机制：把校验器的错误信息拼回请求，让模型在已知错误的前提下修复上一次输出（官方 CCAR-F 点名 validation-retry loops）。 错项：A 丢输出无重试；B 重启会话过度；D temperature 与校验错误率无此因果。 考什么：validation-retry loop 的工作原理。

Q33. D —— few-shot 的典型错误：示例全同构、只有成功案例——模型学到的是示例的表面模式而非任务规律。 错项：A/B/C 都是正确做法（3–5 个、含边界情形、同域）。 考什么：few-shot 示例多样性与真实分布（M05；官方点名 few-shot）。

Q34. B —— 截至 2026-08-30：prefill 在新模型上已弃用（请求返回 400）；现行方案是 structured output + adaptive thinking。 错项：A/C 是被淘汰的做法；D prefill 本来就是格式手段。 考什么：弃用参数识别（考试爱出旧教程陷阱，M02/M05）。

Q35. D —— Message Batches = 离线批量成本杠杆：约半价、24 小时窗口、不支持 streaming（官方 CCAR-F 点名）。 错项：A 批量非低延迟；B 与 streaming 是两种场景；C 用途不限评估。 考什么：Batches 的定位与限制。

Q36. A —— 缓存命中的前提：稳定前缀（system prompt + 工具定义）跨请求字节级一致；易变内容放在后面。 错项：B 易变内容前置会破坏前缀命中；C 随机顺序保证不命中；D 结构恰恰是关键变量。 考什么：prompt caching 的前缀稳定性原理（M03）。

Q37. C —— XML 风格标签给模型无歧义的结构边界，区分指令/数据/示例，降低串扰。 错项：A 无加密作用；B token 照计费；D 与缓存无关。 考什么：prompt 结构化组织手段（M05）。

Q38. D —— schema 字段的自然语言描述让模型理解字段语义与使用时机，显著提升输出准确率。 错项：A 因小失大——几个 token 换准确率；B 模型确实读取描述；C 描述影响的是输出行为而非仅成本。 考什么：schema 设计质量（M05）。

Q39. B、C、D —— B 消灭格式错误（constrained decoding）；C 语义需评估管线；D 可与 repair-retry 组合处理残余校验问题。 错项：A structured output 不保证数值的事实准确性——格式合法 ≠ 内容正确。 考什么：structured output 三件事：格式硬保证、语义靠评估、残余靠重试。

Q40. A、B —— 夜间批量富集（10 万行、次日可用）与离线评估套件（1,500 例）都是非交互、可等 24h 的典型批量负载。 错项：C streaming 交互 chat 与 D 秒级支付授权都是延迟敏感场景，Batches 明确不支持流式且窗口 24h。 考什么：Batches 的适用场景判断。

Part IV · Tool Design & MCP Integration

Q41. A —— tools=模型控制（模型决定何时调用）、resources=应用驱动（应用决定加载什么）、prompts=用户控制（用户主动触发模板）（M06，官方 CCAR-F 点名 tool and resource design）。 错项：B 把前两者对调；C/D 「全部一类控制」抹掉了三原语的本质差异。 考什么：三大原语控制方（考试最爱）。

Q42. C —— host（宿主应用，如 Claude Code/IDE）持有完整对话历史、编排权与用户同意；client 只是 host 内与单个 server 的 1:1 连接器。 错项：A client 无全局视图；B transport 是管道无业务角色；D server 只暴露能力，不持有用户会话。 考什么：MCP 架构角色（host/client/server）与安全含义。

Q43. A —— 业务类失败（无效 ID、无记录、权限不足）→ tool result 带 isError: true + 可操作错误说明，模型可自我修正；JSON-RPC error 留给协议级失败（官方 CCAR-F 点名 structured error responses）。 错项：B 协议错误滥用会崩会话且剥夺修正机会；C 空成功结果让模型瞎猜；D 可恢复错误不该消耗人工。 考什么：业务错误 vs 协议错误的分流（M04/M06）。

Q44. B —— token passthrough（把上游 token 原样转发下游）被 MCP 规范明令禁止：绕过 audience 控制与审计链。 错项：A/C/D 都是正当机制（本地传输、防 DNS rebinding、工具治理）。 考什么：MCP 反模式识别（M06/M11）。

Q45. B —— 本地 HTTP server 防御 DNS rebinding 的官方建议：校验 Origin 头，拒绝非预期来源的跨站请求。 错项：A 0.0.0.0 无认证是扩大暴露；C 加长 token 不防 rebinding（请求来自「合法本地端口」）；D stdio 确实避开该攻击面，但「任何情况都安全」是过度承诺。 考什么：本地 MCP server 的网络安全（M06）。

Q46. C —— 工具膨胀的官方解法：progressive discovery / tool search——上下文只放工具目录，按需加载完整定义，治理选择准确率与成本。 错项：A 改名治标不治本；B 更大窗口不解决选择准确率且成本更高；D 砍业务功能是损失。 考什么：工具膨胀治理（M06/M09）。

Q47. A —— MCP 的核心价值：N 个工具/数据源 × M 个客户端的集成矩阵，用一套标准协议收敛为 N+M。 错项：B 协议不给模型加智能；C 不是永久取代 REST；D 权限治理仍需应用层做。 考什么：何时用 MCP vs 直接集成（M06；官方点名 server configuration）。

Q48. D —— ACI（Agent-Client Interface）投入：工具文档按 HCI 标准写，减少误用比 prompt 调优更便宜——官方经验中优化工具的时间常超过优化 prompt。 错项：A 数量不是质量；B 大模型同样吃工具文档质量；C 描述长不等于好——要的是「何时用/何时不用/约束」清楚。 考什么：工具设计的第一性原理：文档质量 > prompt 调优（M04/M06）。

Q49. A、B —— 只读参考数据 → resources（应用驱动加载）；改变状态的操作 → tools（模型控制调用）。 错项：C「全做成 tool」丢失控制方区分且增加误调用面；D resources 不执行写操作。 考什么：resources vs tools 的分工判据。

Q50. B、D —— 本地 server 用 stdio（进程通信、免网络暴露）；远程 server 用 Streamable HTTP。 错项：A stdio 不是为 WAN 设计的；C raw TCP 不是推荐默认。 考什么：MCP transport 选型（M06）。

Q51. B

• Best choice: B——把业务失败映射为 isError: true 的 tool result（附可操作说明：格式要求、可选队列），协议级失败保留 JSON-RPC error。
• Why: 模型获得自我修正所需的信息（这是可恢复错误的核心处理路径）；错误语义分层清晰（业务 vs 协议）；无静默失败。
• Why others are weaker: A 全部当协议错误 → 会话崩溃且模型无从修正；C 静默空结果 = 模型把「无记录」当成功继续推理；D 每个错误都转人工成本不可承受且剥夺模型修正机会。
• Tradeoffs: 需要在 server 错误映射层维护「错误→可操作文案」的表；部分错误（如权限）可能需要提示模型换路径而非重试同路径。
• What would change the answer: 若错误来自基础设施级故障（server 宕机、协议不兼容），才走 JSON-RPC error/熔断路径，而不是回传模型。

考什么：structured error responses 分层设计（M04/M06，官方 CCAR-F 点名）。

Part V · Context Management & Reliability

Q52. C —— 上下文窗口是工作记忆不是存储：token 越多context rot 越严重，召回与推理质量下降——「塞满窗口」是反模式（M01/M07）。 错项：A/B 把窗口当永久存储/不衰减缓存；D 数据库有查询保证，窗口没有。 考什么：窗口的本质与 context rot（官方 CCAR-F 点名 context window management）。

Q53. A —— lost in the middle：长上下文中部信息召回最差，开头结尾最可靠——关键指令与事实放开头/结尾。 错项：B 长度最大化恰是病因；C 与实证相反；D 位置有实证影响。 考什么：官方指南点名效应的设计含义（M01）。

Q54. D —— progressive summarization：周期性把较早的交互压缩为保留关键事实与约束的摘要，近期细节保持原样（官方 CCAR-F 点名）。 错项：A/B 走两个极端（不摘要/全量重复，后者加剧 rot）；C temperature 与遗忘无关。 考什么：长会话上下文管理的官方术语与机制。

Q55. B —— 升级人工的交接包：原请求 + 已尝试路径 + 相关状态 + trace ID——坐席可续作而非重启调查。 错项：A/C/D 都是「丢一句话」式反模式（升级率也会因坐席效率低而恶化）。 考什么：escalation 交接设计（官方 CCAR-F 点名 escalation/HITL）。

Q56. C —— provenance/attribution：每条实质性主张链接可检索来源（引用），决策链可审计——监管场景的硬要求（官方 CCAR-F 点名）。 错项：A/B 是形式标注不是溯源；D 与溯源无关且妨碍审计。 考什么：溯源与审计（M10/M12）。

Q57. A —— fallback chain 的触发条件（错误类型、延迟阈值、熔断计数）必须由应用代码持有——模型不该也不能决定「我该被换掉」。 错项：B 模型无自我降级视角且有激励偏差；C 厂商不知道你的 SLO；D 生产必有故障路径。 考什么：降级触发的确定性原则（M10）。

Q58. A、B、C —— 策展（只放相关材料）、JIT 检索（按需取）、结构化笔记（持久化关键事实、重载紧凑状态）都是对抗 context rot 的手段。 错项：D 全量历史是 rot 的直接成因。 考什么：上下文策展 > 塞满窗口（M07/M08）。

Q59. B、C —— 审批门放在不可逆/高影响动作上（B），并保持审批量低以防 approval fatigue（审批疲劳→橡皮图章）（C）。 错项：A 每句审批必然疲劳；D 日终批量批准等于没人真审。 考什么：HITL 设计的有效性条件（官方 CCAR-F 点名 escalation/HITL）。

Q60. A、B、C —— 指数退避+jitter、circuit breaker（熔断）、分层超时预算是三大标准可靠性模式。 错项：D 529 过载时加倍并发重试是雪崩配方——过载信号要求退避降载。 考什么：生产可靠性模式组合（M03/M10）。

（Mock 01 答案册完） · 回做：mock-01.md · 下一套：mock-02.md