声明：本卷是本课程编写的原创教学模拟题，不是、也不冒充任何官方真题；未使用任何泄露材料。 题型结构（单选/多选/场景决策）参考官方公开的考试形式（Multiple-choice、Multiple-response、scenario；官方 VERIFIED 截至 2026-08-30），题目内容为课程原创。 对齐目标：CCAR-F 域分布（Agentic 27% / Claude Code 20% / Prompting & Structured Output 20% / Tool & MCP 18% / Context & Reliability 15%）。
🎯 学习重点：每题先圈出 Best/First/Most 与硬约束，再选唯一最佳而非仅“可用”的方案。
Q1. 一个客服工单分类任务：输入是结构化工单文本，输出是 12 个固定类别之一，业务规则稳定。架构师应选： A. Multi-agent system（coordinator + 分类 workers） B. 单次 LLM 调用的 workflow（prompt + structured output 约束类别） C. 开放式 agent loop（模型自主决定分类策略） D. Evaluator-optimizer 双 agent 循环
Q2. Agent loop 上生产前，以下哪项是准入门槛级的缺失？ A. 没有使用 subagent B. 没有 max iterations / 预算上限等 stopping conditions C. 没有接入 MCP D. 没有开启 streaming
Q3. 官方对 workflow 与 agent 的核心区分判据是： A. 是否使用工具 B. 任务路径/步数的可预测性（控制权在代码还是模型） C. 是否使用多个模型 D. 是否有用户界面
Q4. Multi-agent 架构的典型 token 代价与适用前提，正确的是： A. 代价更低；任何任务都该默认 multi-agent B. 代价约 15×；需开放式+可并行+超窗口+高价值四前提 C. 代价约 2×；仅需两个以上用户群体 D. 无额外代价；仅需更高档模型
Q5. Coordinator-subagent 模式中，subagent 完成任务后向主会话返回： A. 完整的原始上下文与全部工具输出 B. 摘要结果（context isolation 的实现） C. 对下一个 subagent 的控制指令 D. 只返回 stop_reason
Q6. 一个研究型任务需要浏览大量网页，路径不可预测。团队担心主会话上下文被污染。最佳做法： A. 把全部网页存进 CLAUDE.md B. 用只读 explore subagent 做大规模探索，主会话只收摘要 C. 无限调大主会话上下文窗口 D. 每 10 轮对话手动 /clear
Q7. Claude Code 中，CLAUDE.md 的正确定位是： A. 强制执行的配置文件（违反即阻断） B. 提供给模型的上下文/指令（强制要靠 deny 规则与 hooks） C. 权限白名单 D. 等价于 managed settings
Q8. 要确保「无论模型怎么决定，删除 /etc 下文件的命令永远被拦截」，正确的实现是： A. 在 CLAUDE.md 写「禁止删除系统文件」 B. 在 system prompt 里写禁令 C. permissions.deny 规则 + PreToolUse hook（Exit Code 2 阻断） D. 提醒模型谨慎操作
Q9. 关于 permission modes，正确的是： A. plan 是一个独立功能页面，与权限无关 B. plan 是 permission mode 之一：只读探索 + 产出计划供人审 C. bypassPermissions 下 deny 规则失效 D. acceptEdits 模式下所有 Bash 命令免询问
Q10. 组织要统一全公司的 Claude Code 安全红线（个人无法关闭），应配置在： A. 每个 CLAUDE.md 里 B. 组织 managed settings / managed policy（优先级最高、可锁定） C. 每人自己的 user settings D. 对话里口头约定
Q11. 旧教程说「创建 custom commands」——按当前（截至 2026-08-30）文档，正确认知是： A. custom commands 与 skills 是两套并行机制 B. custom commands 已并入 skills（二者等价，skills 是现行概念） C. custom commands 已删除且无替代 D. skills 只在 headless 模式可用
Q12. 无人值守的 CI 里跑 claude -p（headless），权限策略应该： A. 用 bypassPermissions 追求效率 B. 比交互模式更收紧：最小 allow + deny + hook 兜底 C. 不配置任何权限（默认即安全） D. 每次运行前人工确认
Q13. 结构化输出（structured output）的保证边界是： A. 保证输出既格式合法又语义正确 B. 只保证格式/结构合法（constrained decoding），语义正确要靠评估 C. 只在 temperature=0 时有效 D. 需要配合 prefill 才有效
Q14. 下游解析器屡屡收到非法 JSON。以下方案中最不可靠的是： A. JSON schema + structured output（constrained decoding） B. strict tool use（工具参数过 schema） C. 在 prompt 里写「务必输出合法 JSON」并祈祷 D. 校验失败后把错误信息拼回 prompt 做 repair retry
Q15. Few-shot 示例的常见错误用法是： A. 给 3–5 个示例 B. 全部示例同构（只有成功案例、同一格式），模型学到示例偏差 C. 示例覆盖边界情形 D. 示例与目标任务同域
Q16. 关于 prefill 与 extended thinking（截至 2026-08-30）： A. prefill 是约束格式的推荐手段 B. prefill 在 4.6+ 模型已弃用（返回 400）；现行方案是 structured output + adaptive thinking C. budget_tokens 是最新思考参数 D. extended thinking 与 adaptive thinking 完全等价
Q17. Message Batches API 的正确定位： A. 同步低延迟在线服务 B. 离线批量的成本杠杆（约半价、24h 窗口），且不支持 stream / fast mode C. 只能用于评估 D. 是 streaming 的替代升级
Q18. Long-running agent 会话中，模型行为开始漂移、早期约束被「遗忘」。最符合官方思想的缓解是： A. 换更大的模型 B. compaction / progressive summarization + 结构化笔记，关键约束放开头结尾 C. 把 temperature 调到 0 D. 每轮重复全部历史
Q19. 「Lost in the middle」效应对 prompt 设计的直接含义是： A. 关键信息与指令应避免埋在长上下文中部（开头结尾更可靠） B. 上下文越长越好 C. 中部的工具定义不需要优化 D. 只影响小模型
Q20. RAG 检索质量评估的正确顺序是： A. 先调 prompt，再看端到端人工感受 B. 先测检索层指标（recall@k / precision@k / MRR），检索层崩了调 prompt 无用 C. 直接上 reranker D. 只看最终答案正确率
Q21. 混合检索（hybrid retrieval）解决的核心问题是： A. 向量检索对精确 token（错误码/SKU/条款编号）的系统性盲区 B. 嵌入模型太贵 C. 分块不均匀 D. reranker 不支持中文
Q22. 多租户 SaaS 的 RAG，租户数据隔离的正确实现层是： A. system prompt 声明「只引用本租户文档」 B. 检索 pre-filter（按租户元数据过滤，由应用代码强制） C. 检索后过滤（post-filter） D. 让模型自行判断文档归属
Q23. MCP 三大原语与控制方的对应，正确的是： A. tools=应用驱动；resources=模型控制；prompts=host 控制 B. tools=模型控制；resources=应用驱动；prompts=用户控制 C. 三者都由模型控制 D. 三者都由 server 控制
Q24. MCP 架构中持有完整对话历史与编排权、并承载用户同意的是： A. Server B. Host C. 任意 Client D. Transport 层
Q25. 工具执行失败（如查询参数不合法）时，对模型侧的最优处理是： A. 抛异常并终止整个会话 B. 以 isError=true 的 structured error response 回传，让模型自我修正 C. 静默吞掉错误，只写日志 D. 立即转人工
Q26. MCP 部署中被规范明令禁止的反模式是： A. stdio transport B. token passthrough（server 把上游 token 原样转发下游） C. Origin 校验 D. progressive discovery
Q27. 团队给 agent 挂了 60 个 MCP 工具后，选择准确率下降、成本上升。官方推荐方向： A. 全部工具改名更短 B. progressive discovery / tool search：上下文只放工具目录，按需加载完整定义 C. 换更大上下文模型一劳永逸 D. 删掉一半业务功能
Q28. 收到 HTTP 429 且响应带 retry-after 头，正确动作是： A. 立即原样重试 B. 按 retry-after 指示等待后重试（配合指数退避 + jitter） C. 放弃请求并报障 D. 并发发起 5 个相同请求抢占配额
Q29. 与 spend limit（支出上限）触顶相关的 429，特征与对策是： A. 带 retry-after，等待即可 B. 通常无 retry-after，重试无效；需检查 error_code 并处理配额/预算 C. 只发生在免费层 D. 换模型即可绕过
Q30. 生产环境模型选用的基线策略是： A. 用 alias（别名）自动跟随最新版本 B. 锁定 pinned snapshot ID；升级走灰度 + 回归评估 C. 每天自动切到最新模型 D. 永远用最贵模型保平安
🎯 学习重点：逐项独立判定，并在提交前核对选中数量与题干完全一致。
Q31.（选 2）以下哪些属于「把 prompt 禁令当安全控制」的错误模式？ A. 在 system prompt 写「你不许访问客户数据」就认为访问控制完成 B. 用 permissions.deny 阻断危险命令 C. 在 RAG prompt 里写「请只引用本租户文档」作为租户隔离 D. 用 PreToolUse hook 校验参数并阻断
Q32.（选 2）Graceful degradation（优雅降级）的「三件套」包括： A. 降级响应显式声明 degraded 状态 B. 降级流量指标单独计数 C. 降级时静默假装一切正常 D. 具备可恢复切回机制
Q33.（选 3）Structured output（schema 约束）方案的正确认知包括： A. 消灭格式类错误（constrained decoding 在解码期禁止非法 token） B. 同时消灭语义错误 C. 语义正确性需由评估管线验证 D. 可与 repair retry 组合处理残余校验问题
Q34.（选 2）以下哪些场景适合 evaluator-optimizer 模式？ A. 翻译质量迭代（有清晰评估标准，人类反馈有效） B. 固定 12 类工单分类 C. 代码审查-修改循环（有明确验收标准） D. 一次性摘要生成
Q35.（选 3）升级人工（escalation）要做对的三件事： A. 坐席收到结构化上下文（原请求/已试路径/trace_id） B. 升级率纳入监控指标 C. 直接丢一句「处理一下这个」给坐席 D. 处置结果回写系统与评估集
Q36.（选 2）Prompt caching 命中率低的常见自身原因： A. 断点放在每轮变化的内容（时间戳/当次消息）之后或之上 B. 稳定的 system prompt + 工具定义构成前缀 C. 前缀内容跨请求保持不变 D. 消息顺序或前缀内容在轮次间频繁变动
🎯 学习重点：用四步法完成场景题，并为每个答案说出代价与改变条件。
Q37.【场景：客服助理的自动化边界】 Scenario：某 SaaS 公司的客服助理要自动处理退款申请。政策：金额 ≤ $100 且无风险信号 → 可自动执行；金额 > $200 或命中风险信号 → 必须人工审批。 Constraints：审计要求每笔退款可回放决策依据；工具面要最小化；模型输出只做「建议」，不做「授权」。 Options： A. 给 agent 一个通用 SQL 工具直接操作订单库，prompt 里写清金额规则 B. 退款执行走确定性代码：规则引擎判金额/风险 → 低风险自动执行、高风险进审批门；LLM 只负责生成建议与坐席交接摘要 C. 让模型每笔都输出「批准/拒绝」，应用无条件执行模型决定 D. 全部人工处理，不用 LLM
Q38.【场景：内部知识库问答】 Scenario：公司有 300 页支持政策手册（Markdown，结构良好，季度更新，旧版必须作废失效），要做一个面向 200 名内部坐席的问答机器人。坐席常问「年付客户的退款政策对 X 怎么说」这类带精确条款的问题。 Constraints：预算有限；答案必须可溯源（每条主张有引用）；手册总量约 15 万 token。 Options： A. 每次提问全量塞入手册 + prompt caching，回答带原文引用 B. 立刻建向量库 + embeddings + Top-K=20 检索 C. 只靠模型参数知识回答（不接手册） D. 向量+BM25 混合检索 + 元数据过滤（版本有效性）+ 引用
Q39.【场景：MCP 工具错误处理】 Scenario：你团队的 agent 通过 MCP 调用内部「工单查询」server。近期发现：传入无效工单号时 server 返回 JSON-RPC protocol error，agent 会话直接崩溃；而某些查询失败其实是「权限不足」这类可恢复错误。 Constraints：不能改 server 的业务逻辑；希望模型有机会自我修正（如改用正确格式重试）；架构上要区分错误类型。 Options： A. 把所有错误都当 protocol error 处理，快速失败 B. 业务类错误（参数无效/权限不足/无记录）以 isError=true 的 tool result 回传给模型并附可操作的错误说明；仅协议级失败走 JSON-RPC error C. 捕获所有错误后静默返回空结果 D. 每次错误都转人工坐席
Q40.【场景：agent 上下文膨胀】 Scenario：一个长时程 research agent 运行 40+ 分钟后回答质量下降：早期约束被忽略、工具输出把上下文塞满、成本超预算三倍。 Constraints：任务本身确实开放、需要持续探索；不能简单砍功能；团队已有结构化笔记的雏形。 Options： A. 换 1M token 窗口的旗舰模型并全量保留历史 B. 引入 compaction（旧工具结果清理 + 渐进式摘要）+ 结构化笔记持久化关键事实 + 把大块探索委派给 subagent（摘要回传） C. 每 20 轮硬截断历史（丢弃最旧一半） D. 把 max_tokens 调小限制输出
（卷一完） · 对答案：mock-exam-1-answers.md · 继续练：mock-exam-2.md
📚 目录